mysqlbinlog - Online în cloud

PROGRAM:

NUME

mysqlbinlog - utilitar pentru procesarea fișierelor jurnal binare

REZUMAT

mysqlbinlog [Opțiuni] fișier jurnal ...

DESCRIERE

Jurnalul binar al serverului constă din fișiere care conțin „evenimente” care descriu modificări
la conținutul bazei de date. Serverul scrie aceste fișiere în format binar. Pentru a-și afișa
conținut în format text, utilizați mysqlbinlog utilitate. De asemenea, puteți utiliza mysqlbinlog la
afișează conținutul fișierelor jurnal de releu scrise de un server slave într-o configurare de replicare
deoarece jurnalele releu au același format ca și jurnalele binare. Jurnalul binar și jurnalul de releu sunt
discutat în continuare în Secțiunea 5.2.4, „Jurnalul binar” și Secțiunea 17.2.2, „Replicare
Jurnalele de releu și stare”.

invoca mysqlbinlog asa:

coajă> mysqlbinlog [Opțiuni] fișier jurnal ...

De exemplu, pentru a afișa conținutul fișierului jurnal binar numit binlog.000003, utilizați acest
comanda:

coajă> mysqlbinlog binlog.0000003

Ieșirea include evenimentele conținute în binlog.000003. Pentru înregistrarea bazată pe declarații, eveniment
informațiile includ instrucțiunea SQL, ID-ul serverului pe care a fost executat,
marca temporală când a fost executată instrucțiunea, cât timp a durat și așa mai departe. Pentru
Înregistrare bazată pe rânduri, evenimentul indică o schimbare de rând mai degrabă decât o instrucțiune SQL. Vedea
Secțiunea 17.1.2, „Formate de replicare”, pentru informații despre modurile de înregistrare.

Evenimentele sunt precedate de comentarii de antet care oferă informații suplimentare. De exemplu:

# la 141
#100309 9:28:36 ID server 123 end_log_pos 245
Interogare thread_id=3350 exec_time=11 error_code=0

În prima linie, numărul care urmează la indică decalajul fișierului sau începutul
poziția, a evenimentului în fișierul jurnal binar.

Al doilea rând începe cu o dată și o oră care indică când a început declarația pe
serverul de unde a avut originea evenimentul. Pentru replicare, acest marcaj temporal este propagat către slave
servere. server id este valoarea server_id a serverului de unde a apărut evenimentul.
end_log_pos indică unde începe următorul eveniment (adică este poziția finală a fișierului
eveniment curent + 1). thread_id indică ce fir a executat evenimentul. exec_time este
timpul petrecut executând evenimentul, pe un server master. Pe un sclav, este diferența
a timpului de sfârșit de execuție pe slave minus timpul de execuție de început pe master.
Diferența servește ca un indicator al cât de multă replicare rămâne în urma masterului.
error_code indică rezultatul executării evenimentului. Zero înseamnă că nicio eroare
a avut loc.

notițe
Când se utilizează grupuri de evenimente, decalajele de fișiere ale evenimentelor pot fi grupate împreună și
comentariile evenimentelor pot fi grupate. Nu confunda aceste evenimente grupate cu
offset-uri de fișiere goale.

Ieșirea din mysqlbinlog poate fi re-executat (de exemplu, folosindu-l ca intrare pentru
MySQL) pentru a reface declarațiile din jurnal. Acest lucru este util pentru operațiunile de recuperare după a
blocarea serverului. Pentru alte exemple de utilizare, consultați discuția de mai târziu în această secțiune și în
Secțiunea 7.5, „Recuperare punct în timp (incrementală) folosind jurnalul binar”.

În mod normal, folosești mysqlbinlog pentru a citi fișierele jurnal binare direct și a le aplica la
server local MySQL. De asemenea, este posibil să citiți jurnalele binare de pe un server la distanță folosind
il --read-of-remote-server opțiune. Pentru a citi jurnalele binare de la distanță, parametrul de conexiune
pot fi date opțiuni pentru a indica modul de conectare la server. Aceste opțiuni sunt --gazdă,
--parola, --port, --protocol, --priză și --utilizator; sunt ignorate cu excepția cazului în care dvs
folosiți și --read-of-remote-server opțiune.

mysqlbinlog acceptă următoarele opțiuni, care pot fi specificate pe linia de comandă sau
în grupurile [mysqlbinlog] și [client] ale unui fișier de opțiuni. Pentru informații despre opțiune
fișierele utilizate de programele MySQL, consultați Secțiunea 4.2.6, „Utilizarea fișierelor de opțiuni”.

· --Ajutor, -?

Afișați un mesaj de ajutor și ieșiți.

· --base64-output=valoare

Această opțiune determină când evenimentele ar trebui să fie afișate codificate ca șiruri de caractere de bază 64
folosind instrucțiuni BINLOG. Opțiunea are aceste valori permise (nu țin cont de minuscule și minuscule):

· AUTO ("automat") sau UNSPEC ("nespecificat") afișează instrucțiunile BINLOG
automat atunci când este necesar (adică pentru evenimente de descriere a formatului și rând
evenimente). Daca nu --base64-ieșire este dată opțiunea, efectul este același ca
--base64-output=AUTO.

notițe
Afișarea automată BINLOG este singurul comportament sigur dacă intenționați să utilizați
ieșire din mysqlbinlog pentru a reexecuta conținutul fișierului jurnal binar. Cealaltă variantă
valorile sunt destinate numai pentru depanare sau testare, deoarece pot
produce ieșire care nu include toate evenimentele în formă executabilă.

· NU face NICIODATĂ să nu fie afișate instrucțiunile BINLOG. mysqlbinlog iese cu o
eroare dacă este găsit un eveniment de rând care trebuie afișat folosind BINLOG.

· DECODE-ROWS specifică pentru mysqlbinlog că intenționați ca evenimentele rând să fie decodificate
și afișat ca instrucțiuni SQL comentate prin specificarea de asemenea a --verbos opțiune.
Ca NEVER, DECODE-ROWS suprimă afișarea instrucțiunilor BINLOG, dar spre deosebire de NEVER,
nu iese cu o eroare dacă este găsit un eveniment de rând.

Pentru exemple care arată efectul --base64-ieșire si --verbos eveniment pe rând
ieșire, consultați secțiunea numită „MYSQLBINLOG ROW EVENT DISPLAY”.

· --bind-address=adresa IP

Pe un computer care are mai multe interfețe de rețea, utilizați această opțiune pentru a selecta care
interfață de utilizat pentru conectarea la serverul MySQL.

Această opțiune este acceptată începând cu MySQL 5.6.1.

· --binlog-row-event-max-size=N

┌────────────────────┬──────────────────────────── ──────────────┐
│Linie de comanda Format │ --binlog-row-event-max-size=# │
├────────────────────┼──────────────────────────── ──────────────┤
│ │ permis Valori │
│ ├───────────────────┬───────────────────────────
│ │ Platformă Pic Mărimea │ 64 │
│ ├───────────────────┼────────────────────────────
│ │ Tip │ numeric │
│ ├───────────────────┼────────────────────────────
│ │ Mod implicit │ 4294967040 │
│ ├───────────────────┼────────────────────────────
│ │ Min Valoare │ 256 │
│ ├───────────────────┼────────────────────────────
│ │ max Valoare │ 18446744073709547520 │
└────────────────────┴───────────────────┴──────── ──────────────┘
Specificați dimensiunea maximă a unui eveniment de jurnal binar pe rând, în octeți. Rândurile sunt grupate
în evenimente mai mici decât această dimensiune, dacă este posibil. Valoarea ar trebui să fie un multiplu de 256.
Valoarea implicită este de 4 GB.

· --character-sets-dir=cale

Directorul în care sunt instalate seturile de caractere. Consultați Secțiunea 10.5, „Setul de caractere
Configurare”.

· --connection-server-id=server_id

Această opțiune este folosită pentru a testa un server MySQL pentru suport pentru BINLOG_DUMP_NON_BLOCK
steag de conexiune, care a fost eliminat din greșeală în MySQL 5.6.5 și restaurat în MySQL
5.6.20 (Eroare #18000079, Eroare #71178). Nu este necesar pentru funcționarea normală.

Valorile implicite efective și minime pentru această opțiune depind de dacă mysqlbinlog
rulează în modul de blocare sau în modul neblocant. Cand mysqlbinlog este rulat în blocare
modul, valoarea implicită (și minimă) este 1; atunci când rulează în modul neblocant, implicit
(și valoarea minimă) este 0.

Această opțiune a fost adăugată în MySQL 5.6.20.

· --database=db_name, -d db_name

Această opțiune provoacă mysqlbinlog pentru a scoate intrări din jurnalul binar (numai jurnalul local)
care apar în timp ce db_name a fost selectată ca bază de date implicită de către USE.

--Bază de date opțiune pentru mysqlbinlog este similară cu --binlog-do-db opțiune pentru
mysqld, dar poate fi folosit pentru a specifica o singură bază de date. Dacă --Bază de date este dat multiplu
ori, se folosește doar ultima instanță.

Efectele acestei opțiuni depind de înregistrarea bazată pe instrucțiuni sau pe rânduri
format este în uz, în același mod în care efectele --binlog-do-db depinde dacă
Înregistrarea bazată pe instrucțiuni sau pe rânduri este în uz.

Bazat pe declarații logare. --Bază de date opțiunea funcționează după cum urmează:

· In timp ce db_name este baza de date implicită, instrucțiunile sunt scoase indiferent dacă se modifică
mese în db_name sau o altă bază de date.

· Dacă nu db_name este selectată ca bază de date implicită, instrucțiunile nu sunt afișate,
chiar dacă modifică tabelele în db_name.

· Există o excepție pentru CREATE DATABASE, ALTER DATABASE și DROP DATABASE. The
baza de date fiind creată, alterat, or scăzut este considerat a fi implicit
baza de date atunci când se determină dacă să scoată declarația.

Să presupunem că jurnalul binar a fost creat prin executarea acestor instrucțiuni folosind
înregistrare bazată pe declarații:

INSERT INTO test.t1 (i) VALORI(100);
INSERT INTO db2.t2 (j) VALORI(200);
test USE;
INSERT INTO test.t1 (i) VALORI(101);
INSERT INTO t1 (i) VALORI(102);
INSERT INTO db2.t2 (j) VALORI(201);
UTILIZAȚI db2;
INSERT INTO test.t1 (i) VALORI(103);
INSERT INTO db2.t2 (j) VALORI(202);
INSERT INTO t2 (j) VALORI(203);

mysqlbinlog --database=test nu scoate primele două instrucțiuni INSERT deoarece
nu există o bază de date implicită. Emite cele trei instrucțiuni INSERT după USE
test, dar nu cele trei instrucțiuni INSERT care urmează după USE db2.

mysqlbinlog --database=db2 nu scoate primele două instrucțiuni INSERT deoarece
nu există o bază de date implicită. Nu scoate cele trei instrucțiuni INSERT care urmează
USE testează, dar scoate cele trei instrucțiuni INSERT după USE db2.

Bazat pe rânduri logare. mysqlbinlog scoate numai intrări care modifică tabelele cărora le aparțin
db_name. Baza de date implicită nu are niciun efect asupra acestui lucru. Să presupunem că jurnalul binar doar
descris a fost creat folosind înregistrarea bazată pe rând, mai degrabă decât înregistrarea bazată pe instrucțiuni.
mysqlbinlog --database=test scoate numai acele intrări care modifică t1 în test
baza de date, indiferent dacă USE a fost emisă sau care este baza de date implicită. În cazul în care o
serverul rulează cu binlog_format setat la MIXED și doriți să fie posibil
utilizare mysqlbinlog cu --Bază de date opțiunea, trebuie să vă asigurați că tabelele care sunt
modificate sunt în baza de date selectată de USE. (În special, nu există o bază de date încrucișată
ar trebui folosite actualizări.)

Înainte de MySQL 5.6.10, --Bază de date opțiunea nu a funcționat corect cu un jurnal scris
de un server MySQL activat cu GTID. (Eroare #15912728)

· --debug[=opțiuni_debug], -# [opțiuni_debug]

Scrieți un jurnal de depanare. Un tipic opțiuni_debug șirul este d:t:o,nume de fișier. Implicit
este d:t:o,/tmp/mysqlbinlog.trace.

· --verificare-depanare

Imprimați câteva informații de depanare când programul se închide.

· --debug-info

Imprimați informații de depanare și statistici de utilizare a memoriei și a procesorului atunci când programul
iesirile.

· --default-auth=conecteaza

Pluginul de autentificare pe partea clientului de utilizat. Consultați Secțiunea 6.3.7, „Conectabil
Autentificare".

Această opțiune a fost adăugată în MySQL 5.6.2.

· --defaults-extra-file=nume de fișier

Citiți acest fișier de opțiuni după fișierul de opțiuni global, dar (pe Unix) înainte de utilizator
fișier de opțiuni. Dacă fișierul nu există sau este inaccesibil în alt mod, apare o eroare.
nume de fișier este interpretat relativ la directorul curent dacă este dat ca o cale relativă
nume, mai degrabă decât un nume complet de cale.

· --defaults-file=nume de fișier

Utilizați numai fișierul de opțiuni dat. Dacă fișierul nu există sau este altfel
inaccesibil, apare o eroare. nume de fișier este interpretată relativ la curent
director dacă este dat ca un nume de cale relativă, mai degrabă decât un nume de cale completă.

· --defaults-group-sufx=str

Citiți nu numai grupurile obișnuite de opțiuni, ci și grupurile cu numele obișnuite și a
sufix de str. De exemplu, mysqlbinlog citește în mod normal [client] și [mysqlbinlog]
grupuri. Dacă --defaults-group-suffix=_altele este dată opțiunea, mysqlbinlog citeste de asemenea
grupurile [client_other] și [mysqlbinlog_other].

· --disable-log-bin, -D

Dezactivați înregistrarea binară. Acest lucru este util pentru a evita o buclă nesfârșită dacă utilizați
--la-ultimul-log opțiunea și trimit rezultatul către același server MySQL. Această opțiune
De asemenea, este util la restaurarea după o blocare pentru a evita duplicarea declarațiilor dvs
s-au autentificat.

Această opțiune necesită să aveți privilegiul SUPER. Cauzează mysqlbinlog la
includeți o instrucțiune SET sql_log_bin = 0 în ieșirea sa pentru a dezactiva înregistrarea binară a
ieșire rămasă. Declarația SET este ineficientă dacă nu aveți SUPER
privilegiu.

· --exclude-gtids=gtid_set

Nu afișați niciunul dintre grupurile enumerate în gtid_set. Adăugat în MySQL 5.6.5.

· --forța-dacă-deschis, -F

Citiți fișierele jurnal binare chiar dacă sunt deschise sau nu au fost închise corect.

· --forța-citire, -f

Cu această opțiune, dacă mysqlbinlog citește un eveniment de jurnal binar pe care nu îl recunoaște,
imprimă un avertisment, ignoră evenimentul și continuă. Fără această opțiune,
mysqlbinlog se oprește dacă citește un astfel de eveniment.

· --hexdump, -H

Afișați un dump hexadecimal al comentariilor de jurnal, așa cum este descris în secțiunea numită
„FORMAT DUMP HEX MYSQLBINLOG”. Ieșirea hexagonală poate fi utilă pentru replicare
depanare.

· --gazdă=nume_gazdă, -h nume_gazdă

Obțineți jurnalul binar de la serverul MySQL de pe gazda dată.

· --include-gtids=gtid_set

Afișați numai grupurile enumerate în gtid_set. Adăugat în MySQL 5.6.5.

· --local-load=cale, -l cale

Pregătiți fișierele temporare locale pentru LOAD DATA INFILE în directorul specificat.

Important
Aceste fișiere temporare nu sunt eliminate automat de mysqlbinlog sau orice altceva
Programul MySQL.

· --login-path=nume

Citiți opțiunile din calea de conectare numită în fișierul de conectare .mylogin.cnf. O „cale de conectare”
este un grup de opțiuni care permite doar un set limitat de opțiuni: gazdă, utilizator și
parola. Gândiți-vă la o cale de conectare ca la un set de valori care indică gazda serverului și
acreditările pentru autentificarea cu serverul. Pentru a crea fișierul cale de conectare, utilizați
il mysql_config_editor utilitate. Vedea mysql_config_editor(1). Această opțiune a fost adăugată în
MySQL 5.6.6.

· --no-defaults

Nu citiți niciun fișier de opțiuni. Dacă pornirea programului eșuează din cauza citirii unor opțiuni necunoscute
dintr-un fișier de opțiuni, --no-defaults pot fi folosite pentru a preveni citirea acestora.

Excepția este că fișierul .mylogin.cnf, dacă există, este citit în toate cazurile. Acest
permite ca parolele să fie specificate într-un mod mai sigur decât pe linia de comandă chiar și atunci când
--no-defaults este folosit. (.mylogin.cnf este creat de mysql_config_editor utilitate.
Vedea mysql_config_editor(1).)

· --offset=N, -o N

Sari peste primul N intrări în jurnal.

· --parola[=parola], -p[parola]

Parola de utilizat la conectarea la server. Dacă utilizați formularul de opțiune scurtă
(-p), tu nu poti au un spațiu între opțiune și parolă. Dacă omiteți
parola valoare în urma --parola or -p opțiune pe linia de comandă, mysqlbinlog
solicită unul.

Specificarea unei parole pe linia de comandă ar trebui considerată nesigură. Vedea
Secțiunea 6.1.2.1, „Instrucțiuni pentru utilizatorul final pentru securitatea parolei”. Puteți folosi o opțiune
fișier pentru a evita darea parolei pe linia de comandă.

· --plugin-dir=cale

Directorul în care să căutați pluginuri. Poate fi necesar să specificați această opțiune
dacă --default-auth opțiunea este folosită pentru a specifica un plugin de autentificare dar
mysqlbinlog nu o gaseste. Consultați Secțiunea 6.3.7, „Autentificare conectabilă”.

Această opțiune a fost adăugată în MySQL 5.6.2.

· --port=port_num, -P port_num

Numărul portului TCP/IP de utilizat pentru conectarea la un server la distanță.

· --print-defaults

Tipăriți numele programului și toate opțiunile pe care le primește din fișierele de opțiuni.

· --protocol={TCP|SOCKET|PIPE|MEMORY}

Protocolul de conectare de utilizat pentru conectarea la server. Este util atunci când
în mod normal, alți parametri de conexiune ar determina utilizarea unui alt protocol decât cel
una pe care o vrei. Pentru detalii despre valorile permise, consultați Secțiunea 4.2.2, „Conectarea la
serverul MySQL”.

· --brut

În mod implicit, mysqlbinlog citește fișiere jurnal binare și scrie evenimente în format text. The
--brut optiunea spune mysqlbinlog pentru a le scrie în formatul lor binar original. Utilizarea lui
cere asta --read-of-remote-server de asemenea, pentru că fișierele sunt solicitate
de pe un server. mysqlbinlog scrie un fișier de ieșire pentru fiecare fișier citit de pe server.
--brut opțiunea poate fi folosită pentru a face o copie de rezervă a jurnalului binar al unui server. Cu
--stop-niciodata opțiunea, backup-ul este „în direct”, deoarece mysqlbinlog rămâne conectat la
Server. În mod implicit, fișierele de ieșire sunt scrise în directorul curent cu același
nume ca fișierele jurnal originale. Numele fișierelor de ieșire pot fi modificate folosind
--fișier-rezultat opțiune. Pentru mai multe informații, consultați secțiunea numită „UTILIZAREA MYSQLBINLOG
PENTRU A FACE BACKUP FIȘIERELOR Jurnal binare”.

Această opțiune a fost adăugată în MySQL 5.6.0.

· --read-from-remote-master=tip

Citiți jurnalele binare de pe un server MySQL cu COM_BINLOG_DUMP sau COM_BINLOG_DUMP_GTID
comenzi setând valoarea opțiunii fie la BINLOG-DUMP-NON-GTIDS fie
BINLOG-DUMP-GTIDS, respectiv. Dacă --read-from-remote-master=BINLOG-DUMP-GTIDS is
combinate cu --exclude-gtids, tranzacțiile pot fi filtrate pe master,
evitând traficul inutil de rețea.

Vezi si descrierea pt --read-of-remote-server.

Această opțiune a fost adăugată în MySQL 5.6.5.

· --read-of-remote-server, -R

Citiți jurnalul binar de pe un server MySQL, în loc să citiți un fișier jurnal local. Orice
opțiunile parametrilor de conexiune sunt ignorate dacă nu este dată și această opțiune. Aceste
opțiunile sunt --gazdă, --parola, --port, --protocol, --priză și --utilizator.

Această opțiune necesită ca serverul de la distanță să ruleze. Funcționează numai pentru jurnalul binar
fișiere de pe serverul de la distanță, nu fișiere jurnal de retransmisie.

Începând cu MySQL 5.6.5, această opțiune este ca
--read-from-remote-master=BINLOG-DUMP-NON-GTIDS.

· --result-file=nume, -r nume

Fara --brut opțiunea, această opțiune indică fișierul la care mysqlbinlog scrie
ieșire text. Cu --brut, mysqlbinlog scrie un fișier binar de ieșire pentru fiecare fișier jurnal
transferate de pe server, scriindu-le implicit în directorul curent folosind
aceleași nume ca fișierul jurnal original. În acest caz, --fișier-rezultat valoarea opțiunii
este tratat ca un prefix care modifică numele fișierelor de ieșire.

· --secure-auth

Nu trimiteți parole la server în format vechi (pre-4.1). Acest lucru previne conexiunile
cu excepția serverelor care utilizează formatul de parolă mai nou. Această opțiune este activată de
Mod implicit; utilizare --skip-secure-auth pentru a-l dezactiva. Această opțiune a fost adăugată în MySQL 5.6.17.

notițe
Parolele care folosesc metoda hashing pre-4.1 sunt mai puțin sigure decât parolele care
utilizați metoda nativă de hashing a parolei și ar trebui evitată. Parole anterioare 4.1
sunt depreciate și suportul pentru ele va fi eliminat într-o viitoare versiune MySQL. Pentru
instrucțiuni de actualizare a contului, consultați Secțiunea 6.3.8.3, „Migrarea de la pre-4.1
Hashing parole și plugin-ul mysql_old_password”.

· --server-id=id

Afișează numai acele evenimente create de server care au ID-ul de server dat.

· --server-id-bits=N

Folosiți doar primul N biți din server_id pentru a identifica serverul. Dacă jurnalul binar
a fost scris de a mysqld cu server-id-bits setați la mai puțin de 32 și datele utilizatorului stocate
în partea cea mai semnificativă, alergarea mysqlbinlog cu --server-id-bits setat la 32
permite vizualizarea acestor date.

Această opțiune este acceptată numai de versiunile de mysqlbinlog furnizat împreună cu MySQL
Distribuție în cluster sau construit din sursele MySQL Cluster.

· --set-charset=nume_set de caractere

Adăugați un SET NUME nume_set de caractere instrucțiune la ieșire pentru a specifica setul de caractere la
să fie utilizat pentru procesarea fișierelor jurnal.

· --shared-memory-base-name=nume

Pe Windows, numele memoriei partajate de utilizat, pentru conexiunile realizate folosind memoria partajată
un server local. Valoarea implicită este MYSQL. Numele memoriei partajate face distincție între majuscule și minuscule.

Serverul trebuie pornit cu --memorie partajată opțiunea de a activa memoria partajată
conexiunile.

· --forma scurta, -s

Afișați numai declarațiile conținute în jurnal, fără informații suplimentare sau
evenimente bazate pe rânduri. Acesta este doar pentru testare și nu trebuie utilizat în producție
sisteme.

· --skip-gtids[=(adevărat|fals)]

Nu afișați niciun GTID în ieșire. Acest lucru este necesar atunci când scrieți într-un fișier dump
dintr-unul sau mai multe jurnale binare care conțin GTID-uri, așa cum se arată în acest exemplu:

coajă> mysqlbinlog --skip-gtids binlog.000001 > /tmp/dump.sql
coajă> mysqlbinlog --skip-gtids binlog.000002 >> /tmp/dump.sql
coajă> MySQL -u rădăcină -p -e "sursă /tmp/dump.sql"

Utilizarea acestei opțiuni nu este recomandată în mod normal în producție.

Această opțiune a fost adăugată în MySQL 5.6.5.

· --socket=cale, -S cale

Pentru conexiunile la localhost, fișierul socket Unix de utilizat sau, pe Windows, numele lui
conducta numită de utilizat.

· --start-datetime=datetime

Începeți să citiți jurnalul binar la primul eveniment care are o marca temporală egală cu sau mai târziu
decât datetime argument. The datetime valoarea este relativă la fusul orar local activat
mașina pe care alergi mysqlbinlog. Valoarea ar trebui să fie într-un format acceptat pentru
tipurile de date DATETIME sau TIMESTAMP. De exemplu:

coajă> mysqlbinlog --start-datetime="2005-12-25 11:25:56" binlog.000003

Această opțiune este utilă pentru recuperarea la un moment dat. Consultați Secțiunea 7.3, „Exemplu de backup și
Strategia de recuperare”.

· --start-position=N, -j N

Începeți să citiți jurnalul binar la primul eveniment care are o poziție egală sau mai mare
decât N. Această opțiune se aplică primului fișier jurnal numit pe linia de comandă.

Această opțiune este utilă pentru recuperarea la un moment dat. Consultați Secțiunea 7.3, „Exemplu de backup și
Strategia de recuperare”.

· --stop-datetime=datetime

Opriți citirea jurnalului binar la primul eveniment care are un marcaj de timp egal cu sau mai târziu
decât datetime argument. Această opțiune este utilă pentru recuperarea la un moment dat. Vezi
descrierea --start-datetime opțiune pentru informații despre datetime valoare.

Această opțiune este utilă pentru recuperarea la un moment dat. Consultați Secțiunea 7.3, „Exemplu de backup și
Strategia de recuperare”.

· --stop-niciodata

Această opțiune este folosită cu --read-of-remote-server. Spune mysqlbinlog a rămâne
conectat la server. In caz contrar mysqlbinlog iese când a fost ultimul fișier jurnal
transferat de pe server. --stop-niciodata implică --la-ultimul-log, deci doar primul
fișierul jurnal de transferat trebuie să fie numit pe linia de comandă.

--stop-niciodata este folosit în mod obișnuit cu --brut pentru a face o copie de rezervă a jurnalului binar live, dar și
poate fi folosit fără --brut pentru a menține o afișare text continuă a evenimentelor din jurnal ca
serverul le generează.

Această opțiune a fost adăugată în MySQL 5.6.0.

· --stop-never-slave-server-id=id

cu --stop-niciodata, mysqlbinlog raportează un ID de server de 65535 când se conectează la
Server. --stop-never-slave-server-id specifică în mod explicit ID-ul serverului de raportat. Aceasta
poate fi folosit pentru a evita un conflict cu ID-ul unui server slave sau al altuia mysqlbinlog
proces. Consultați secțiunea numită „SPECIFICAREA ID-ULUI SERVERULUI MYSQLBINLOG”.

Această opțiune a fost adăugată în MySQL 5.6.0.

· --stop-position=N

Opriți citirea jurnalului binar la primul eveniment care are o poziție egală sau mai mare
decât N. Această opțiune se aplică ultimului fișier jurnal numit pe linia de comandă.

Această opțiune este utilă pentru recuperarea la un moment dat. Consultați Secțiunea 7.3, „Exemplu de backup și
Strategia de recuperare”.

· --la-ultimul-log, -t

Nu vă opriți la sfârșitul jurnalului binar solicitat de la un server MySQL, ci mai degrabă
continuați tipărirea până la sfârșitul ultimului jurnal binar. Dacă trimiteți rezultatul către
același server MySQL, acest lucru poate duce la o buclă fără sfârșit. Această opțiune necesită
--read-of-remote-server.

· --utilizator=nume de utilizator, -u nume de utilizator

Numele de utilizator MySQL de utilizat atunci când vă conectați la un server la distanță.

· --verbos, -v

Reconstituiți evenimentele rând și afișați-le ca instrucțiuni SQL comentate. Dacă această opțiune este
dat de două ori, rezultatul include comentarii pentru a indica tipurile de date coloane și unele
metadate.

Pentru exemple care arată efectul --base64-ieșire si --verbos eveniment pe rând
ieșire, consultați secțiunea numită „MYSQLBINLOG ROW EVENT DISPLAY”.

· --verify-binlog-checksum, -c

Verificați sumele de verificare în fișierele jurnal binare. Această opțiune a fost adăugată în MySQL 5.6.1.

· --versiune, -V

Afișați informații despre versiune și ieșiți.

Înainte de MySQL 5.6.11, mysqlbinlog numărul de versiune afișat a fost 3.3. În MySQL 5.6.11
iar mai târziu, acesta este 3.4. (Eroare #15894381, Eroare #67643)

De asemenea, puteți seta următoarea variabilă folosind --var_name=valoare sintaxă:

· limita_fișiere_deschise

Specificați numărul de descriptori de fișier deschis de rezervat.

Puteți conducta ieșirea din mysqlbinlog în MySQL client pentru a executa evenimentele
conținute în jurnalul binar. Această tehnică este folosită pentru a vă recupera după un accident atunci când aveți
o copie de rezervă veche (consultați Secțiunea 7.5, „Recuperare punct în timp (incrementală) folosind codul binar
Buturuga"). De exemplu:

coajă> mysqlbinlog binlog.000001 | MySQL -u rădăcină -p

Sau:

coajă> mysqlbinlog binlog.[0-9]* | MySQL -u rădăcină -p

Dacă declaraţiile produse de mysqlbinlog poate conține valori BLOB, acestea pot cauza
probleme când MySQL le prelucrează. În acest caz, invocați MySQL cu --modul-binar
opțiune.

De asemenea, puteți redirecționa rezultatul mysqlbinlog în schimb într-un fișier text, dacă este necesar
modificați mai întâi jurnalul de instrucțiuni (de exemplu, pentru a elimina instrucțiunile pe care nu doriți să le faceți
executa din anumite motive). După editarea fișierului, executați instrucțiunile pe care le conține
utilizându-l ca intrare în MySQL program:

coajă> mysqlbinlog binlog.000001 > tmpfile
coajă>... edita tmpfile ...
coajă> MySQL -u rădăcină -p < tmpfile

Cand mysqlbinlog este invocat cu --poziție-de-pornire opțiunea, afișează numai acelea
evenimente cu un offset în jurnalul binar mai mare sau egal cu o anumită poziție (the
poziţia dată trebuie să se potrivească cu începutul unui eveniment). Are și opțiuni de oprire și pornire
când vede un eveniment cu o dată și o oră date. Acest lucru vă permite să efectuați
recuperare punct-in-time folosind --stop-datetime opțiune (pentru a putea spune, de exemplu,
„Îmi înaintează bazele de date la cum au fost astăzi la 10:30”).

Dacă aveți mai mult de un jurnal binar de executat pe serverul MySQL, metoda sigură este să
procesează-le pe toate folosind o singură conexiune la server. Iată un exemplu care
demonstrează ce poate fi nesigur:

coajă> mysqlbinlog binlog.000001 | MySQL -u rădăcină -p # PERICOL!!
coajă> mysqlbinlog binlog.000002 | MySQL -u rădăcină -p # PERICOL!!

Procesarea jurnalelor binare în acest fel, folosind mai multe conexiuni la server, cauzează probleme
dacă primul fișier jurnal conține o instrucțiune CREATE TEMPORARY TABLE și al doilea jurnal
conține o instrucțiune care utilizează tabelul temporar. Când primul MySQL proces
se încheie, serverul renunță la tabelul temporar. Când al doilea MySQL încercări de proces
pentru a utiliza tabelul, serverul raportează „tabel necunoscut”.

Pentru a evita astfel de probleme, utilizați a singur MySQL proces pentru a executa conținutul tuturor
jurnalele binare pe care doriți să le procesați. Iată o modalitate de a face acest lucru:

coajă> mysqlbinlog binlog.000001 binlog.000002 | MySQL -u rădăcină -p

O altă abordare este să scrieți toate jurnalele într-un singur fișier și apoi să procesați fișierul:

coajă> mysqlbinlog binlog.000001 > /tmp/statements.sql
coajă> mysqlbinlog binlog.000002 >> /tmp/statements.sql
coajă> MySQL -u rădăcină -p -e "sursă /tmp/statements.sql"

mysqlbinlog poate produce o ieșire care reproduce o operațiune LOAD DATA INFILE fără
fișierul de date original. mysqlbinlog copiază datele într-un fișier temporar și scrie un LOAD
Declarație DATA LOCAL INFILE care se referă la fișier. Locația implicită a directorului
unde sunt scrise aceste fișiere este specific sistemului. Pentru a specifica un director în mod explicit, utilizați
il --încărcare-locală opțiune.

pentru că mysqlbinlog convertește instrucțiunile LOAD DATA INFILE în LOAD DATA LOCAL INFILE
instrucțiuni (adică adaugă LOCAL), atât clientul, cât și serverul pentru care utilizați
procesează instrucțiunile trebuie să fie configurate cu capacitatea LOCAL activată. Vedea
Secțiunea 6.1.6, „Probleme de securitate cu LOAD DATA LOCAL”.

avertizare
Fișierele temporare create pentru instrucțiunile LOAD DATA LOCAL sunt nu în mod automat
șterse deoarece sunt necesare până când executați efectiv acele instrucțiuni. Tu
ar trebui să ștergeți singur fișierele temporare după ce nu mai aveți nevoie de jurnalul de declarații.
Fișierele pot fi găsite în directorul de fișiere temporare și au nume precum
nume_fișier_original-#-#.

MYSQLBINLOG HEX DUMP FORMAT

--hexdump cauzele opțiunii mysqlbinlog pentru a produce un dump hexadecimal al conținutului jurnalului binar:

coajă> mysqlbinlog --hexdump master-bin.000001

Ieșirea hexadecimală constă din linii de comentarii care încep cu #, astfel încât rezultatul ar putea arăta ca
asta pentru comanda anterioară:

/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
# la 4
#051024 17:24:13 ID server 1 end_log_pos 98
# Poziție Tip marcaj de timp ID-ul principal Dimensiune Steaguri de poziția principală
# 00000004 9d fc 5c 43 0f 01 00 00 00 5e 00 00 00 62 00 00 00 00 00
# 00000017 04 00 35 2e 30 2e 31 35 2d 64 65 62 75 67 2d 6c |...5.0.15.debug.l|
# 00000027 6f 67 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |og..............|
# 00000037 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
# 00000047 00 00 00 00 9d fc 5c 43 13 38 0d 00 08 00 12 00 |.......C.8......|
# 00000057 04 04 04 04 12 00 00 4b 00 04 1a |.......K...|
# Start: binlog v 4, server v 5.0.15-debug-log creat 051024 17:24:13
# la pornire
ROLLBACK;

Ieșirea Hex dump conține în prezent elementele din următoarea listă. Acest format este
pot fi modificate. (Pentru mai multe informații despre formatul jurnalului binar, consultați MySQL Internele:
Binar Log[1].

· Poziție: Poziția octetului în fișierul jurnal.

· Timpul: marcajul de timp al evenimentului. În exemplul prezentat, „9d fc 5c 43” este
reprezentarea lui „051024 17:24:13” în hexazecimal.

· Tip: codul tipului de eveniment. În exemplul prezentat, „0f” indică a
FORMAT_DESCRIPTION_EVENT. Următorul tabel listează codurile de tip posibile.

┌─────┬──────────────────────────┬──────────────── ──────────────────────┐
│Tip │ Nume │ Sens │
├─────┼──────────────────────────┼──────────────── ──────────────────────┤
│00 │ UNKNOWN_EVENT │ Acest eveniment nu ar trebui niciodată │
│ │ │ fi prezent în jurnal. │
├─────┼──────────────────────────┼──────────────── ──────────────────────┤
│01 │ START_EVENT_V3 │ Aceasta indică începutul │
│ │ │ a unui fișier jurnal scris de │
│ │ │ MySQL 4 sau o versiune anterioară. │
├─────┼──────────────────────────┼──────────────── ──────────────────────┤
│02 │ QUERY_EVENT │ Cel mai frecvent tip de │
│ │ │ evenimente. Acestea conțin │
│ │ │ instrucțiuni executate pe │
│ │ │ cel │
│ │ │ maestru. │
├─────┼──────────────────────────┼──────────────── ──────────────────────┤
│03 │ STOP_EVENT │ Indică faptul că masterul are │
│ │ │ oprit. │
├─────┼──────────────────────────┼──────────────── ──────────────────────┤
│04 │ ROTATE_EVENT │ Scris când masterul │
│ │ │ comută la un nou fișier jurnal. │
├─────┼──────────────────────────┼──────────────── ──────────────────────┤
│05 │ INTVAR_EVENT │ Folosit pentru AUTO_INCREMENT │
│ │ │ sau când │
│ │ │ LAST_INSERT_ID() │
│ │ │ funcția │
│ │ │ este folosit în enunț. │
├─────┼──────────────────────────┼──────────────── ──────────────────────┤
│06 │ LOAD_EVENT │ Folosit pentru LOAD DATE │
│ │ │ INFILE în MySQL │
│ │ │ 3.23. │
├─────┼──────────────────────────┼──────────────── ──────────────────────┤
│07 │ SLAVE_EVENT │ Rezervat pentru utilizare ulterioară. │
├─────┼──────────────────────────┼──────────────── ──────────────────────┤
│08 │ CREATE_FILE_EVENT │ Folosit pentru LOAD DATE │
│ │ │ INFILE │
│ │ │ afirmații. Aceasta indică │
│ │ │ începutul lui │
│ │ │ executarea unei astfel de declarații. A │
│ │ │ temporar │
│ │ │ fișierul este creat │
│ │ │ pe sclav. Folosit numai în MySQL 4. │
├─────┼──────────────────────────┼──────────────── ──────────────────────┤
│09 │ APPEND_BLOCK_EVENT │ Conține date pentru utilizare într-un │
│ │ │ ÎNCĂRCARE DATE │
│ │ │ INFILE │
│ │ │ afirmație. Datele sunt stocate în │
│ │ │ temporar │
│ │ │ fișier pe sclav. │
├─────┼──────────────────────────┼──────────────── ──────────────────────┤
│0a │ EXEC_LOAD_EVENT │ Folosit pentru LOAD DATE │
│ │ │ INFILE │
│ │ │ afirmații. Conținutul │
│ │ │ fișier temporar │
│ │ │ este stocat în tabelul pe slave. │
│ │ │ Folosit în MySQL 4 │
numai │ │ │. │
├─────┼──────────────────────────┼──────────────── ──────────────────────┤
│0b │ DELETE_FILE_EVENT │ Derularea unei date LOAD │
│ │ │ INFILE │
│ │ │ afirmație. Fișierul temporar │
│ │ │ ar trebui să fie │
│ │ │ șters pe slave. │
├─────┼──────────────────────────┼──────────────── ──────────────────────┤
│0c │ NEW_LOAD_EVENT │ Folosit pentru LOAD DATE │
│ │ │ INFILE în MySQL │
│ │ │ 4 și anterioare. │
├─────┼──────────────────────────┼──────────────── ──────────────────────┤
│0d │ RAND_EVENT │ Folosit pentru a trimite informații despre │
│ │ │ valori aleatorii dacă │
│ │ │ Funcția RAND() │
│ │ │ este │
│ │ │ folosit în │
│ │ │ afirmație. │
├─────┼──────────────────────────┼──────────────── ──────────────────────┤
│0e │ USER_VAR_EVENT │ Folosit pentru a replica variabilele utilizatorului. │
├─────┼──────────────────────────┼──────────────── ──────────────────────┤
│0f │ FORMAT_DESCRIPTION_EVENT │ Aceasta indică începutul unui jurnal │
│ │ │ fișier scris de MySQL 5 sau mai recent. │
├─────┼──────────────────────────┼──────────────── ──────────────────────┤
│10 │ XID_EVENT │ Eveniment care indică comiterea unui XA │
│ │ │ tranzacție. │
├─────┼──────────────────────────┼──────────────── ──────────────────────┤
│11 │ BEGIN_LOAD_QUERY_EVENT │ Folosit pentru ÎNCĂRCARE DATE │
│ │ │ INFILE │
│ │ │ instrucțiuni în MySQL 5 și versiuni ulterioare. │
├─────┼──────────────────────────┼──────────────── ──────────────────────┤
│12 │ EXECUTE_LOAD_QUERY_EVENT │ Folosit pentru LOAD DATE │
│ │ │ INFILE │
│ │ │ instrucțiuni în MySQL 5 și versiuni ulterioare. │
├─────┼──────────────────────────┼──────────────── ──────────────────────┤
│13 │ TABLE_MAP_EVENT │ Informații despre un tabel │
│ │ │ definiție. Folosit în MySQL 5.1.5 și │
│ │ │ mai târziu. │
├─────┼──────────────────────────┼──────────────── ──────────────────────┤
│14 │ PRE_GA_WRITE_ROWS_EVENT │ Date de rând pentru un singur tabel care │
│ │ │ ar trebui creat. Folosit în MySQL │
│ │ │ 5.1.5 │
│ │ │ până la 5.1.17. │
├─────┼──────────────────────────┼──────────────── ──────────────────────┤
│15 │ PRE_GA_UPDATE_ROWS_EVENT │ Date de rând pentru un singur tabel care │
│ │ │ trebuie actualizat. Folosit în MySQL │
│ │ │ 5.1.5 până la 5.1.17. │
├─────┼──────────────────────────┼──────────────── ──────────────────────┤
│16 │ PRE_GA_DELETE_ROWS_EVENT │ Date de rând pentru un singur tabel care │
│ │ │ ar trebui șters. Folosit în MySQL │
│ │ │ 5.1.5 │
│ │ │ până la 5.1.17. │
├─────┼──────────────────────────┼──────────────── ──────────────────────┤
│17 │ WRITE_ROWS_EVENT │ Date de rând pentru un singur tabel care │
│ │ │ ar trebui creat. Folosit în MySQL │
│ │ │ 5.1.18 │
│ │ │ și mai târziu. │
├─────┼──────────────────────────┼──────────────── ──────────────────────┤
│18 │ UPDATE_ROWS_EVENT │ Date de rând pentru un singur tabel care │
│ │ │ trebuie actualizat. Folosit în MySQL │
│ │ │ 5.1.18 și │
│ │ │ mai târziu. │
├─────┼──────────────────────────┼──────────────── ──────────────────────┤
│19 │ DELETE_ROWS_EVENT │ Date de rând pentru un singur tabel care │
│ │ │ ar trebui șters. Folosit în MySQL │
│ │ │ 5.1.18 │
│ │ │ și mai târziu. │
├─────┼──────────────────────────┼──────────────── ──────────────────────┤
│1a │ INCIDENT_EVENT │ Ceva ieșit din comun │
│ │ │ sa întâmplat. Adăugat în MySQL 5.1.18. │
└─────┴──────────────────────────┴──────────────── ──────────────────────┘

· Master ID: ID-ul serverului master care a creat evenimentul.

· Dimensiune: dimensiunea în octeți a evenimentului.

· Master Pos: Poziția următorului eveniment în fișierul jurnal principal original.

· Steaguri: 16 steaguri. În prezent, sunt utilizate următoarele steaguri. Celelalte sunt rezervate pentru
utilizare viitoare.

┌─────┬─────────────────────────────┬───────────── ────────────────────────────────────
│Pavilion │ Nume │ Sens │
├─────┼─────────────────────────────┼───────────── ─────────────────────────────────────
│01 │ LOG_EVENT_BINLOG_IN_USE_F │ Fișierul jurnal corect │
│ │ │ închis. (Folosit numai în │
│ │ │ FORMAT_DESCRIPTION_EVENT.) │
│ │ │ Dacă │
│ │ │ aceasta │
│ │ │ este setat (dacă │
│ │ │ steaguri sunt, de exemplu, │
│ │ │ '01 │
│ │ │ 00') într-un │
│ │ │ FORMAT_DESCRIPTION_EVENT, │
│ │ │ bușteanul │
│ │ │ dosar │
│ │ │ nu a fost corect │
│ │ │ închis. Cel mai probabil │
│ │ │ aceasta │
│ │ │ este din cauza unui maestru │
│ │ │ accident (de exemplu, din cauza │
│ │ │ până la │
│ │ │ pană de curent). │
├─────┼─────────────────────────────┼───────────── ─────────────────────────────────────
│02 │ │ Rezervat pentru utilizare ulterioară. │
├─────┼─────────────────────────────┼───────────── ─────────────────────────────────────
│04 │ LOG_EVENT_THREAD_SPECIFIC_F │ Setați dacă evenimentul depinde de │
│ │ │ conexiunea în care a fost executată (pentru │
│ │ │ exemplu, '04 00'), pentru │
│ │ │ exemplu, │
│ │ │ dacă evenimentul folosește │
│ │ │ tabele temporare. │
├─────┼─────────────────────────────┼───────────── ─────────────────────────────────────
│08 │ LOG_EVENT_SUPPRESS_USE_F │ Setat în anumite circumstanțe când evenimentul este │
│ │ │ nu depinde de implicit │
│ │ │ baza de date. │
└─────┴─────────────────────────────┴───────────── ────────────────────────────────────

MYSQLBINLOG RÂND EVENIMENT DISPLAY

Următoarele exemple ilustrează cum mysqlbinlog afișează evenimente de rând care specifică date
modificari. Acestea corespund evenimentelor cu WRITE_ROWS_EVENT, UPDATE_ROWS_EVENT,
și codurile de tip DELETE_ROWS_EVENT. The --base64-output=DECODARE-RÂNDURI si --verbos Opțiuni
poate fi folosit pentru a afecta ieșirea evenimentului de rând.

Să presupunem că serverul utilizează înregistrarea binară bazată pe rânduri și că executați
următoarea succesiune de afirmații:

CREATE TABLE t
(
id INT NU NULL,
nume VARCHAR(20) NU NUL,
data DATE NULL
) MOTOR = InnoDB;
ÎNCEPE TRANZACȚIA;
INSERT INTO t VALUES(1, „măr”, NULL);
UPDATE t SET nume = 'pere', data = '2009-01-01' WHERE id = 1;
DELETE FROM t WHERE id = 1;
COMITIA;

În mod implicit, mysqlbinlog afișează evenimente de rând codificate ca șiruri de caractere de bază 64 folosind BINLOG
declarații. Omitând liniile străine, ieșirea pentru evenimentele rând produse de
secvența de declarații anterioară arată astfel:

coajă> mysqlbinlog fișier jurnal
...
# la 218
#080828 15:03:08 ID server 1 end_log_pos 258 Write_rows: ID tabel 17 flags: STMT_END_F
BINLOG '
fAS3SBMBAAAALAAAANoAAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=
fAS3SBcBAAAAKAAAAAIBAAAQABEAAAAAAAEAA//8AQAAAAVhcHBsZQ==
'/*!*/;
...
# la 302
#080828 15:03:08 server id 1 end_log_pos 356 Update_rows: ID tabel 17 flags: STMT_END_F
BINLOG '
fAS3SBMBAAAALAAAAC4BAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=
fAS3SBgBAAAANgAAAGQBAAAQABEAAAAAAAEAA////AEAAAAFYXBwbGX4AQAAAARwZWFyIbIP
'/*!*/;
...
# la 400
#080828 15:03:08 server id 1 end_log_pos 442 Delete_rows: ID tabel 17 flags: STMT_END_F
BINLOG '
fAS3SBMBAAAALAAAAJABAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=
fAS3SBkBAAAAKgAAALoBAAAQABEAAAAAAAEAA//4AQAAAARwZWFyIbIP
'/*!*/;

Pentru a vedea evenimentele de rând ca comentarii sub formă de instrucțiuni „pseudo-SQL”, rulați mysqlbinlog
cu --verbos or -v opțiune. Ieșirea va conține linii care încep cu ###:

coajă> mysqlbinlog -v fișier jurnal
...
# la 218
#080828 15:03:08 ID server 1 end_log_pos 258 Write_rows: ID tabel 17 flags: STMT_END_F
BINLOG '
fAS3SBMBAAAALAAAANoAAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=
fAS3SBcBAAAAKAAAAAIBAAAQABEAAAAAAAEAA//8AQAAAAVhcHBsZQ==
'/*!*/;
### INSERT INTO test.t
### A STABILIT
### @1=1
### @2='măr'
### @3=NULL
...
# la 302
#080828 15:03:08 server id 1 end_log_pos 356 Update_rows: ID tabel 17 flags: STMT_END_F
BINLOG '
fAS3SBMBAAAALAAAAC4BAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=
fAS3SBgBAAAANgAAAGQBAAAQABEAAAAAAAEAA////AEAAAAFYXBwbGX4AQAAAARwZWFyIbIP
'/*!*/;
### UPDATE test.t
### UNDE
### @1=1
### @2='măr'
### @3=NULL
### A STABILIT
### @1=1
### @2='pară'
### @3='2009:01:01'
...
# la 400
#080828 15:03:08 server id 1 end_log_pos 442 Delete_rows: ID tabel 17 flags: STMT_END_F
BINLOG '
fAS3SBMBAAAALAAAAJABAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=
fAS3SBkBAAAAKgAAALoBAAAQABEAAAAAAAEAA//4AQAAAARwZWFyIbIP
'/*!*/;
### DELETE FROM test.t
### UNDE
### @1=1
### @2='pară'
### @3='2009:01:01'

Specifica --verbos or -v de două ori pentru a afișa și tipurile de date și unele metadate pentru fiecare
coloană. Rezultatul va conține un comentariu suplimentar după fiecare modificare a coloanei:

coajă> mysqlbinlog -vv fișier jurnal
...
# la 218
#080828 15:03:08 ID server 1 end_log_pos 258 Write_rows: ID tabel 17 flags: STMT_END_F
BINLOG '
fAS3SBMBAAAALAAAANoAAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=
fAS3SBcBAAAAKAAAAAIBAAAQABEAAAAAAAEAA//8AQAAAAVhcHBsZQ==
'/*!*/;
### INSERT INTO test.t
### A STABILIT
### @1=1 /* INT meta=0 nullable=0 is_null=0 */
### @2='măr' /* VARSTRING(20) meta=20 nullable=0 is_null=0 */
### @3=NULL /* VARSTRING(20) meta=0 nullable=1 is_null=1 */
...
# la 302
#080828 15:03:08 server id 1 end_log_pos 356 Update_rows: ID tabel 17 flags: STMT_END_F
BINLOG '
fAS3SBMBAAAALAAAAC4BAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=
fAS3SBgBAAAANgAAAGQBAAAQABEAAAAAAAEAA////AEAAAAFYXBwbGX4AQAAAARwZWFyIbIP
'/*!*/;
### UPDATE test.t
### UNDE
### @1=1 /* INT meta=0 nullable=0 is_null=0 */
### @2='măr' /* VARSTRING(20) meta=20 nullable=0 is_null=0 */
### @3=NULL /* VARSTRING(20) meta=0 nullable=1 is_null=1 */
### A STABILIT
### @1=1 /* INT meta=0 nullable=0 is_null=0 */
### @2='pară' /* VARSTRING(20) meta=20 nullable=0 is_null=0 */
### @3='2009:01:01' /* DATE meta=0 nullable=1 is_null=0 */
...
# la 400
#080828 15:03:08 server id 1 end_log_pos 442 Delete_rows: ID tabel 17 flags: STMT_END_F
BINLOG '
fAS3SBMBAAAALAAAAJABAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ=
fAS3SBkBAAAAKgAAALoBAAAQABEAAAAAAAEAA//4AQAAAARwZWFyIbIP
'/*!*/;
### DELETE FROM test.t
### UNDE
### @1=1 /* INT meta=0 nullable=0 is_null=0 */
### @2='pară' /* VARSTRING(20) meta=20 nullable=0 is_null=0 */
### @3='2009:01:01' /* DATE meta=0 nullable=1 is_null=0 */

Poți spune mysqlbinlog pentru a suprima instrucțiunile BINLOG pentru evenimente de rând utilizând
--base64-output=DECODARE-RÂNDURI opțiune. Aceasta este similară cu --base64-output=NICIODATĂ dar nu
ieșiți cu o eroare dacă este găsit un eveniment de rând. Combinația de --base64-output=DECODARE-RÂNDURI
si --verbos oferă o modalitate convenabilă de a vedea evenimentele rând numai ca instrucțiuni SQL:

coajă> mysqlbinlog -v --base64-output=DECODARE-RÂNDURI fișier jurnal
...
# la 218
#080828 15:03:08 ID server 1 end_log_pos 258 Write_rows: ID tabel 17 flags: STMT_END_F
### INSERT INTO test.t
### A STABILIT
### @1=1
### @2='măr'
### @3=NULL
...
# la 302
#080828 15:03:08 server id 1 end_log_pos 356 Update_rows: ID tabel 17 flags: STMT_END_F
### UPDATE test.t
### UNDE
### @1=1
### @2='măr'
### @3=NULL
### A STABILIT
### @1=1
### @2='pară'
### @3='2009:01:01'
...
# la 400
#080828 15:03:08 server id 1 end_log_pos 442 Delete_rows: ID tabel 17 flags: STMT_END_F
### DELETE FROM test.t
### UNDE
### @1=1
### @2='pară'
### @3='2009:01:01'

notițe
Nu ar trebui să suprimați instrucțiunile BINLOG dacă intenționați să le executați din nou mysqlbinlog
ieșire.

Instrucțiunile SQL produse de --verbos pentru că evenimentele de rând sunt mult mai lizibile decât cele
instrucțiunile BINLOG corespunzătoare. Cu toate acestea, ele nu corespund exact cu originalul
Instrucțiuni SQL care au generat evenimentele. Se aplică următoarele limitări:

· Numele coloanelor originale se pierd și se înlocuiesc cu @N, În cazul în care N este un număr de coloană.

· Informațiile setului de caractere nu sunt disponibile în jurnalul binar, care afectează șirul
afișare coloane:

· Nu există nicio distincție între șirul binar și nebinar corespunzător
tipuri (BINARY și CHAR, VARBINARY și VARCHAR, BLOB și TEXT). Ieșirea folosește a
tipul de date STRING pentru șiruri de lungime fixă ​​și VARSTRING pentru șiruri de lungime variabilă
siruri de caractere.

· Pentru seturile de caractere multiocteți, numărul maxim de octeți per caracter nu este
prezent în jurnalul binar, astfel încât lungimea tipurilor de șir este afișată în octeți
mai degrabă decât în ​​personaje. De exemplu, STRING(4) va fi folosit ca tip de date
pentru valorile din oricare dintre aceste tipuri de coloane:

REZERVOR(4) SET DE CARACTERE latin1
REZERVOR(2) SET DE CARACTERE ucs2

· Datorită formatului de stocare pentru evenimente de tip UPDATE_ROWS_EVENT, instrucțiuni UPDATE
sunt afișate cu clauza WHERE precedând clauza SET.

Interpretarea corectă a evenimentelor rând necesită informațiile din descrierea formatului
eveniment la începutul jurnalului binar. pentru că mysqlbinlog nu stie dinainte
dacă restul jurnalului conține evenimente de rând, în mod implicit afișează formatul
descriere eveniment folosind o instrucțiune BINLOG în partea inițială a ieșirii.

Dacă se știe că jurnalul binar nu conține niciun eveniment care necesită o instrucțiune BINLOG (care
este, fără evenimente rând), the --base64-output=NICIODATĂ opțiunea poate fi folosită pentru a preveni acest antet
din a fi scris.

UTILIZAREA MYSQLBINLOG LA ÎNAPOI UP BINAR LOG DOSARE

În mod implicit, mysqlbinlog citește fișierele jurnal binare și le afișează conținutul în format text.
Acest lucru vă permite să examinați mai ușor evenimentele din fișiere și să le executați din nou
(de exemplu, folosind ieșirea ca intrare pentru MySQL). mysqlbinlog poate citi fișierele jurnal
direct din sistemul de fișiere local sau, cu --read-of-remote-server opțiune, se poate
conectați-vă la un server și solicitați conținutul jurnalului binar de la acel server. mysqlbinlog scrie
ieșire text la ieșirea sa standard sau la fișierul numit ca valoare a
--result-file=nume de fișier opțiune dacă acea opțiune este dată.

Începând cu MySQL 5.6, mysqlbinlog poate citi fișiere jurnal binare și poate scrie fișiere noi care conțin
același conținut – adică în format binar, mai degrabă decât în ​​format text. Această capacitate permite
puteți face cu ușurință o copie de rezervă a unui jurnal binar în formatul său original. mysqlbinlog poate face o statică
copie de rezervă, realizarea de copii de rezervă a unui set de fișiere jurnal și oprirea la sfârșitul ultimului fișier
atins. De asemenea, poate face o copie de rezervă continuă („live”), rămânând conectat la server
când ajunge la sfârșitul ultimului fișier jurnal și continuă să copieze evenimente noi așa cum sunt
generate. În funcționarea de rezervă continuă, mysqlbinlog rulează până la sfârșitul conexiunii (pentru
de exemplu, când serverul iese) sau mysqlbinlog este terminat cu forța. Când conexiunea
se termină, mysqlbinlog nu așteaptă și reîncercă conexiunea, spre deosebire de o replicare slave
Server. Pentru a continua o copie de rezervă în timp real după ce serverul a fost repornit, trebuie, de asemenea
reîncepe mysqlbinlog.

Copierea de rezervă a jurnalului binar necesită invocarea mysqlbinlog cu cel putin doua variante:

· --read-of-remote-server (Sau -R) opțiunea spune mysqlbinlog pentru a se conecta la un server
și solicitați jurnalul său binar. (Acest lucru este similar cu un server de replicare slave care se conectează
la serverul său principal.)

· --brut optiunea spune mysqlbinlog pentru a scrie ieșire brută (binară), nu ieșire text.

Împreuna cu --read-of-remote-server, este obișnuit să specificați alte opțiuni: --gazdă
indică unde rulează serverul și poate fi necesar să specificați și opțiunile de conectare
precum --utilizator si --parola.

Câteva alte opțiuni sunt utile împreună cu --brut:

· --stop-niciodata: Rămâneți conectat la server după ce ajungeți la sfârșitul ultimului fișier jurnal
și continuă să citești evenimente noi.

· --stop-never-slave-server-id=id: ID-ul serverului care mysqlbinlog rapoarte către server
cand --stop-niciodata este folosit. Valoarea implicită este 65535. Aceasta poate fi folosită pentru a evita un conflict
cu ID-ul unui server slave sau al altuia mysqlbinlog proces. Vezi secțiunea numită
„SPECIFICAREA ID-ULUI SERVERULUI MYSQLBINLOG”.

· --fișier-rezultat: Un prefix pentru numele fișierelor de ieșire, așa cum este descris mai târziu.

Pentru a face copii de rezervă ale fișierelor jurnal binare ale unui server cu mysqlbinlog, trebuie să specificați nume de fișiere care
există de fapt pe server. Dacă nu cunoașteți numele, conectați-vă la server și utilizați
instrucțiunea SHOW BINARY LOGS pentru a vedea numele curente. Să presupunem că afirmația
produce această ieșire:

mysql> SHOW BINAR busteni;
+---------------+-----------+
| Nume_log | Dimensiune_fișier |
+---------------+-----------+
| binlog.000130 | 27459 |
| binlog.000131 | 13719 |
| binlog.000132 | 43268 |
+---------------+-----------+

Cu aceste informații, puteți utiliza mysqlbinlog pentru a face backup jurnalului binar la curent
director, după cum urmează (introduceți fiecare comandă pe o singură linie):

· Pentru a face o copie de rezervă statică a binlog.000130 prin binlog.000132, utilizați oricare dintre acestea
comenzi:

mysqlbinlog --read-from-remote-server --host=nume_gazdă --brut
binlog.000130 binlog.000131 binlog.000132
mysqlbinlog --read-from-remote-server --host=nume_gazdă --brut
--to-last-log binlog.000130

Prima comandă specifică fiecare nume de fișier în mod explicit. Al doilea numeste doar pe
primul fișier și utilizări --la-ultimul-log să-l citesc pe ultimul. O diferență între acestea
comenzi este că dacă serverul se întâmplă să deschidă binlog.000133 înainte mysqlbinlog
ajunge la sfârșitul binlog.000132, prima comandă nu o va citi, ci a doua
comanda va.

· Pentru a face o copie de rezervă live în care mysqlbinlog începe cu binlog.000130 pentru a copia existente
fișiere jurnal, apoi rămâne conectat pentru a copia evenimente noi pe măsură ce serverul le generează:

mysqlbinlog --read-from-remote-server --host=nume_gazdă --brut
--stop-never binlog.000130

cu --stop-niciodata, nu este necesar să se precizeze --la-ultimul-log să citesc până la ultimul
fișier jurnal deoarece această opțiune este implicită.
Numire fișier de ieșire.PP Fără --brut, mysqlbinlog produce text și
--fișier-rezultat opțiunea, dacă este dată, specifică numele fișierului unic la care se iese toate
este scris. Cu --brut, mysqlbinlog scrie un fișier binar de ieșire pentru fiecare fișier jurnal
transferat de pe server. În mod implicit, mysqlbinlog scrie fișierele în curent
director cu aceleași nume ca fișierele jurnal originale. Pentru a modifica numele fișierelor de ieșire,
utilizați --fișier-rezultat opțiune. În legătură cu --brut, --fișier-rezultat valoarea opțiunii este
tratat ca un prefix care modifică numele fișierelor de ieșire.

Să presupunem că un server are în prezent fișiere jurnal binare denumite binlog.000999 și mai sus. daca tu
utilizare mysqlbinlog --brut pentru a face copii de rezervă ale fișierelor, --fișier-rezultat opțiunea produce fișierul de ieșire
nume așa cum se arată în tabelul următor. Puteți scrie fișierele într-un anumit director prin
începutul --fișier-rezultat valoare cu calea directorului. Dacă --fișier-rezultat valoare
constă doar dintr-un nume de director, valoarea trebuie să se termine cu separatorul de cale
caracter. Fișierele de ieșire sunt suprascrise dacă există.

┌─────────────────────┬─────────────────────────── ─┐
│--fișier-rezultat Opțiunea │ producție Fișier Alte denumiri │
├─────────────────────┼─────────────────────────── ─┤
│--result-file=x │ xbinlog.000999 și mai sus │
├─────────────────────┼─────────────────────────── ─┤
│--result-file=/ tmp / │ /tmp/binlog.000999 și mai sus │
├─────────────────────┼─────────────────────────── ─┤
│--result-file=/tmp/x │ /tmp/xbinlog.000999 și mai sus │
└─────────────────────┴─────────────────────────── ─┘
Exemplu: mysqldump + mysqlbinlog pentru Backup și Restore.PP Următorul exemplu descrie
un scenariu simplu care arată cum se utilizează mysqldump si mysqlbinlog împreună pentru a face rezervă a
datele serverului și jurnalul binar și cum să utilizați copia de rezervă pentru a restabili serverul în cazul pierderii datelor
apare. Exemplul presupune că serverul rulează pe gazdă nume_gazdă și primul ei
fișierul jurnal binar se numește binlog.000999. Introduceți fiecare comandă pe o singură linie.

Utilizare mysqlbinlog pentru a face o copie de rezervă continuă a jurnalului binar:

mysqlbinlog --read-from-remote-server --host=nume_gazdă --brut
--stop-never binlog.000999

Utilizare mysqldump pentru a crea un fișier dump ca un instantaneu al datelor serverului. Utilizare
--toate-bazele de date, --evenimente și --rutine pentru a face backup pentru toate datele și --master-data=2 la
includeți coordonatele curente ale jurnalului binar în fișierul dump.

mysqldump --host=nume_gazdă --all-databases --events --routines --master-data=2> dump_file

Executați mysqldump comanda periodic pentru a crea instantanee mai noi, după cum doriți.

Dacă are loc pierderea datelor (de exemplu, dacă serverul se blochează), utilizați cel mai recent fișier de descărcare pentru
restaurați datele:

mysql --host=nume_gazdă -u rădăcină -p dump_file

Apoi utilizați backup-ul jurnalului binar pentru a reexecuta evenimentele care au fost scrise după
coordonatele enumerate în fișierul dump. Să presupunem că coordonatele din fișier arată ca
acest:

-- SCHIMBĂ MASTER ÎN MASTER_LOG_FILE='binlog.001002', MASTER_LOG_POS=27284;

Dacă cel mai recent fișier jurnal de rezervă este numit binlog.001004, reexecuți evenimentele jurnal
asa:

mysqlbinlog --start-position=27284 binlog.001002 binlog.001003 binlog.001004
| mysql --host=nume_gazdă -u rădăcină -p

S-ar putea să vi se pară mai ușor să copiați fișierele de rezervă (fișier dump și fișiere jurnal binare) în fișierul
server gazdă pentru a facilita efectuarea operației de restaurare sau dacă MySQL nu permite
acces root de la distanță.

SPECIFICAREA THE MYSQLBINLOG SERVER ID

Când este invocat cu --read-of-remote-server opțiune, mysqlbinlog se conectează la un MySQL
server, specifică un ID de server pentru a se identifica și solicită fișiere jurnal binare de la
Server. Poți să folosești mysqlbinlog pentru a solicita fișiere jurnal de la un server în mai multe moduri:

· Specificați un set de fișiere denumit explicit: Pentru fiecare fișier, mysqlbinlog conectează și
emite o comandă de dump Binlog. Serverul trimite fișierul și se deconectează. Există unul
conexiune per fișier.

· Specificați fișierul de început și --la-ultimul-log: mysqlbinlog se conectează și emite un Binlog
comanda dump pentru toate fișierele. Serverul trimite toate fișierele și se deconectează.

· Specificați fișierul de început și --stop-niciodata (Ceea ce implică --la-ultimul-log): mysqlbinlog
se conectează și emite o comandă de descărcare Binlog pentru toate fișierele. Serverul trimite toate fișierele,
dar nu se deconectează după trimiterea ultimului.

cu --read-of-remote-server numai, mysqlbinlog se conectează folosind un ID de server de 0, care
spune serverului să se deconecteze după trimiterea ultimului fișier jurnal solicitat.

cu --read-of-remote-server si --stop-niciodata, mysqlbinlog se conectează folosind o valoare diferită de zero
ID-ul serverului, astfel încât serverul să nu se deconecteze după trimiterea ultimului fișier jurnal. Server-ul
ID-ul este 65535 în mod implicit, dar acesta poate fi schimbat cu --stop-never-slave-server-id.

Astfel, pentru primele două moduri de solicitare a fișierelor, serverul se deconectează deoarece
mysqlbinlog specifică un ID de server de 0. Nu se deconectează dacă --stop-niciodata este dată
deoarece mysqlbinlog specifică un ID de server diferit de zero.

DREPTURI DE AUTOR

Copyright © 1997, 2014, Oracle și/sau afiliații săi. Toate drepturile rezervate.

Această documentație este software gratuit; îl puteți redistribui și/sau modifica numai sub
termenii Licenței Publice Generale GNU publicate de Free Software Foundation;
versiunea 2 a licenței.

Această documentație este distribuită în speranța că va fi utilă, dar FĂRĂ NICIUN
GARANȚIE; fără măcar garanția implicită de VANTABILITATE sau ADECUARE PENTRU UN ANUMIT
SCOP. Consultați Licența publică generală GNU pentru mai multe detalii.

Ar fi trebuit să primiți o copie a licenței publice generale GNU împreună cu programul;
dacă nu, scrieți la Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
Boston, MA 02110-1301 SUA sau vezi http://www.gnu.org/licenses/.

NOTE

1. MySQL Internals: Jurnalul binar
http://dev.mysql.com/doc/internals/en/binary-log.html

Utilizați mysqlbinlog online folosind serviciile onworks.net