mariadb-binlog(1)
mariadb-binlog(1)
NAMN
mariadb-binlog - verktyg för att bearbeta binärloggfiler (mariadb- binlog är nu en symbolisk länk till mariadb-binlog)
SYNOPSIS
mariadb-binlog [alternativ] loggfil ...
BESKRIVNING
Serverns binärlogg består av filer som innehåller ”händelser” som beskriver ändringar i databasinnehåll. Servern skriver dessa filer i binärt format. För att visa deras innehåll i textformat använder du verktyget mariadb-binlog. Du kan också använda mariadb-binlog för att visa innehållet i relay-loggfiler som skrivs av en slavserver i en replikeringsmiljö, eftersom relay-loggar har samma format som binärloggar.
Anropa mariadb-binlog så här:
shell> mariadb-binlog [alternativ] loggfil ...
Till exempel, för att visa innehållet i binärloggfilen med namnet binlog.000003, använd detta kommando:
shell> mariadb-binlog binlog.0000003
Utdata innehåller händelserna i binlog.000003. För satsbaserad loggning innehåller händelseinformation SQL-satsen, ID:t för servern där den kördes, tidsstämpeln när satsen kördes, hur lång tid den tog, och så vidare. För radbaserad loggning anger händelsen en radändring snarare än en SQL-sats.
Händelser föregås av rubrikkommentarer som ger ytterligare information. Till exempel:
# at 141
#100309 9:28:36 server id 123 end_log_pos 245
Query thread_id=3350 exec_time=11 error_code=0
På första raden anger talet efter at startpositionen för händelsen i binärloggfilen.
Den andra raden börjar med datum och tid som anger när satsen startade på servern där händelsen uppstod. Vid replikering propagieras denna tidsstämpel till slavservrar. server id är värdet på server_id för den server där händelsen uppstod. end_log_pos anger var nästa händelse börjar (det vill säga, det är slutpositionen för den aktuella händelsen + 1). thread_id anger vilken tråd som körde händelsen. exec_time är tiden som gick åt för att köra händelsen på en master- server. På en slav är det skillnaden mellan sluttiden för körningen på slaven och starttiden för körningen på mastern. Skillnaden fungerar som en indikator på hur mycket replikeringen ligger efter mastern. error_code anger resultatet av att köra händelsen. Noll betyder att inget fel inträffade.
Utdata från mariadb-binlog kan köras igen (till exempel genom att använda den som indata till mariadb) för att utföra satserna i loggen på nytt. Detta är användbart vid återställning efter en serverkrasch. För fler användningsexempel, se diskussionen längre fram i detta avsnitt.
Normalt använder du mariadb-binlog för att läsa binärloggfiler direkt och applicera dem på den lokala MariaDB-servern. Det är också möjligt att läsa binärloggar från en fjärrserver med alternativet --read-from-remote-server. För att läsa binärloggar från fjärrserver kan anslutningsparametrar anges för att visa hur anslutningen ska göras. Dessa alternativ är --host, --password, --port, --protocol, --socket och --user; de ignoreras om du inte också använder alternativet --read-from-remote-server.
mariadb-binlog stöder följande alternativ, som kan anges på kommandoraden eller i alternativgrupperna [mariadb-binlog] och [client].
• --help, -?
Visa en hjälptext och avsluta.
• --base64-output=värde
Detta alternativ avgör när händelser ska visas kodade som base64- strängar med BINLOG-satser. Alternativet har följande tillåtna värden (skiftlägesokänsligt):
• AUTO ("automatic") eller UNSPEC ("unspecified") visar BINLOG-
satser automatiskt när det behövs (det vill säga för format-
descriptionshändelser och radhändelser). Detta är standard om
inget alternativ för --base64-output anges.
Observera
Automatisk BINLOG-visning är det enda säkra beteendet om
du tänker använda utdata från mariadb-binlog för att köra
om innehållet i binärloggfiler. De andra alternativvärdena
är endast avsedda för felsökning eller test, eftersom de
kan ge utdata som inte inkluderar alla händelser i
körbart format.
• NEVER gör att BINLOG-satser inte visas.
mariadb-binlog avslutas med fel om en radhändelse hittas som
måste visas med BINLOG.
• DECODE-ROWS anger för mariadb-binlog att du avser att
radhändelser ska avkodas och visas som kommenterade SQL-
satser genom att du också anger alternativet --verbose.
Precis som NEVER undertrycker DECODE-ROWS visning av
BINLOG-satser, men till skillnad från NEVER avslutas det
inte med fel om en radhändelse hittas.
--base64-output kan anges som --base64-output eller
--skip-base64-output (med betydelsen AUTO eller NEVER).
För exempel som visar effekten av --base64-output och
--verbose på utdata för radhändelser, se avsnittet
“MARIADB-BINLOG VISNING AV RADHÄNDELSER”.
• --binlog-row-event-max-size=path
Katalogen där teckenuppsättningar är installerade.
• --character-sets-dir=path
Katalogen där teckenuppsättningar är installerade.
• --database=db_name, -d db_name
Detta alternativ gör att mariadb-binlog skriver ut poster från binärloggen (endast lokal logg) som inträffar medan db_name har valts som standarddatabas genom USE.
Alternativet --database för mariadb-binlog liknar alternativet --binlog-do-db för mariadbd, men kan bara användas för att ange en databas. Om --database anges flera gånger används endast den sista förekomsten.
Effekten av detta alternativ beror på om satsbaserat eller radbaserat loggningsformat används, på samma sätt som effekten av --binlog-do-db beror på om satsbaserat eller radbaserat loggning används.
Satsbaserad loggning. Alternativet --database fungerar så här:
• Medan db_name är standarddatabas skrivs satser ut oavsett om
de ändrar tabeller i db_name eller i en annan databas.
• Om db_name inte är vald som standarddatabas skrivs satser inte
ut, även om de ändrar tabeller i db_name.
• Det finns ett undantag för CREATE DATABASE, ALTER DATABASE
och DROP DATABASE. Den databas som skapas, ändras eller tas
bort betraktas som standarddatabas när det avgörs om satsen
ska skrivas ut.
Anta att binärloggen skapades genom att köra följande satser
med satsbaserad loggning:
INSERT INTO test.t1 (i) VALUES(100);
INSERT INTO db2.t2 (j) VALUES(200);
USE test;
INSERT INTO test.t1 (i) VALUES(101);
INSERT INTO t1 (i) VALUES(102);
INSERT INTO db2.t2 (j) VALUES(201);
USE db2;
INSERT INTO test.t1 (i) VALUES(103);
INSERT INTO db2.t2 (j) VALUES(202);
INSERT INTO t2 (j) VALUES(203);
mariadb-binlog --database=test skriver inte ut de två första
INSERT-satserna eftersom det inte finns någon standarddatabas.
Den skriver ut de tre INSERT-satserna efter USE test, men inte
de tre INSERT-satserna efter USE db2.
mariadb-binlog --database=db2 skriver inte ut de två första
INSERT-satserna eftersom det inte finns någon standarddatabas.
Den skriver inte ut de tre INSERT-satserna efter USE test, men
skriver ut de tre INSERT-satserna efter USE db2.
Radbaserad loggning. mariadb-binlog skriver bara ut poster som
ändrar tabeller som tillhör db_name. Standarddatabasen har
ingen effekt på detta. Anta att binärloggen som just
beskrevs skapades med radbaserad loggning i stället för
satsbaserad loggning. mariadb-binlog --database=test skriver
bara ut de poster som ändrar t1 i databasen test, oavsett om
USE användes eller vilken standarddatabas som är vald. Om en
server kör med binlog_format satt till MIXED och du vill att
det ska vara möjligt att använda mariadb-binlog med
alternativet --database, måste du säkerställa att tabeller
som ändras ligger i databasen som valts av USE. (I synnerhet
bör inga uppdateringar över databaser användas.)
Observera
Detta alternativ fungerade inte korrekt för mariadb-
binlog med radbaserad loggning före MySQL 5.1.37.
• --debug[=debug_options], -# [debug_options]
Skriv en felsökningslogg. En typisk sträng för debug_options är 'd:t:o,file_name'. Standardvärdet är 'd:t:o,/tmp/mariadb- binlog.trace'.
• --debug-check
Skriv ut viss felsökningsinformation när programmet avslutas.
• --debug-info
Skriv ut felsökningsinformation samt statistik över minnes- och CPU-användning när programmet avslutas.
• --defaults-extra-file=name
Läs den här filen efter att de globala filerna har lästs.
• --defaults-file=name
Läs endast standardalternativ från den angivna filen.
• --default-auth=name
Standardplugin för klientautentisering att använda.
• --disable-log-bin, -D
Inaktivera binär loggning. Detta är användbart för att undvika en oändlig loop om du använder alternativet --to-last-log och skickar utdata till samma MariaDB-server. Detta alternativ är också användbart vid återställning efter en krasch för att undvika duplicering av satser som du redan har loggat.
Detta alternativ kräver att du har privilegiet SUPER. Det gör att mariadb-binlog inkluderar en sats av typen SET sql_log_bin = 0 i sin utdata för att stänga av binär loggning för återstående utdata. SET-satsen är verkningslös om du inte har privilegiet SUPER.
• --flashback, -B
Stöd för flashback-läge.
• --force-if-open
Tvinga om binärloggen inte stängdes korrekt. Standard är på; använd --skip-force-if-open för att inaktivera.
• --force-read, -f
Med detta alternativ, om mariadb-binlog läser en binärlogghändelse som den inte känner igen, skrivs en varning ut, händelsen ignoreras och läsningen fortsätter. Utan detta alternativ stannar mariadb-binlog om den läser en sådan händelse.
• --hexdump, -H
Visa en hexadump av loggen i kommentarer, enligt beskrivningen i avsnittet “MARIADB-BINLOG HEXDUMP-FORMAT”. Hex-utdata kan vara användbara vid felsökning av replikering.
• --host=host_name, -h host_name
Hämta binärloggen från MariaDB-servern på den angivna värden.
• --local-load=path, -l path
Förbered lokala temporära filer för LOAD DATA INFILE i den angivna katalogen.
• --no-defaults
Läs inga standardalternativ från någon alternativfil.
• --offset=N, -o N
Hoppa över de första N posterna i loggen.
• --open-files-limit=NUM
Sätter variabeln open_files_limit, som används för att reservera filbeskrivare för mariadb-binlog.
• --password[=password], -p[password]
Lösenordet som ska användas vid anslutning till servern. Om du använder den korta formen (-p) kan du inte ha ett mellanslag mellan alternativet och lösenordet. Om du utelämnar värdet för password efter alternativet --password eller -p på kommandoraden, frågar mariadb-binlog efter det.
Att ange ett lösenord på kommandoraden bör betraktas som osäkert. Du kan använda en alternativfil för att undvika att ge lösenordet på kommandoraden.
• --plugin-dir=dir_name
Katalog för pluginer på klientsidan.
• --print-defaults
Skriv ut programmets argumentlista från alla alternativfiler och avsluta.
• --port=port_num, -P port_num
TCP/IP-portnumret som ska användas för anslutning till en fjärrserver, eller 0 för standard enligt följande ordning: my.cnf, $MYSQL_TCP_PORT, /etc/services, inbyggd standard (3306). Tvingar --protocol=tcp när det anges på kommandoraden utan andra anslutningsegenskaper.
• --protocol={TCP|SOCKET|PIPE|MEMORY}
Vilket anslutningsprotokoll som ska användas för att ansluta till servern. Detta är användbart när andra anslutningsparametrar normalt skulle orsaka att ett annat protokoll används än det du vill ha.
• --raw
Kräver -R. Skriv ut rå binärloggdata i stället för SQL-satser. Utdatafiler namnges efter serverloggar.
• --read-from-remote-server, -R
Läs binärloggen från en MariaDB-server i stället för att läsa en lokal loggfil. Alla anslutningsparametrar ignoreras om inte detta alternativ också anges. Dessa alternativ är --host, --password, --port, --protocol, --socket och --user.
Detta alternativ kräver att fjärrservern är igång. Det fungerar bara för binärloggfiler på fjärrservern, inte relay-loggfiler.
• --result-file=name, -r name
Skicka utdata till den angivna filen. Med --raw är detta ett prefix för filnamnen.
• --rewrite-db=name, -r name
Uppdaterar till en databas med ett annat namn än originalet. Exempel: rewrite-db='from->to'. För händelser som binärloggas som satser innebär omskrivning av databasen att en sats standard- databas ändras från db1 till db2. Ingen satsanalys eller omskriv- ning av något slag görs, det vill säga om man uttryckligen anger "db1.tbl" i satsen så ändras inte den förekomsten till "db2.tbl". Radbaserade händelser skrivs om korrekt så att de använder det nya databasnamnet. Filtrering (till exempel med --database=name) sker efter att databasomskrivningarna har utförts. Om du använder detta alternativ på kommandoraden och ">" har särskild betydelse för din kommandotolk, citera värdet (t.ex. --rewrite- db="oldname->newname").
• --server-id=id
Visa endast de händelser som skapats av servern med det angivna server-ID:t.
• --set-charset=charset_name
Lägg till en SET NAMES charset_name-sats i utdata för att ange vilken teckenuppsättning som ska användas vid behandling av loggfiler.
• --short-form, -s
Visa bara satserna som finns i loggen, ingen extra information och inga radbaserade händelser. Detta är endast för test och bör inte användas i produktionssystem. Om du vill undertrycka base64- utdata, överväg att använda --base64-output=never i stället.
• --socket=path, -S path
För anslutningar till localhost, Unix-socketfilen som ska användas, eller på Windows namnet på det namngivna röret som ska användas. Tvingar --protocol=socket när det anges på kommandoraden utan andra anslutningsegenskaper; på Windows tvingar det --protocol=pipe.
• --start-datetime=datetime
Börja läsa binärloggen vid den första händelsen som har en tidsstämpel lika med eller senare än argumentet datetime. Värdet datetime är relativt den lokala tidszonen på den maskin där du kör mariadb-binlog. Värdet ska vara i ett format som accepteras för datatyperna DATETIME eller TIMESTAMP. Till exempel:
shell> mariadb-binlog --start-datetime="2014-12-25 11:25:56" binlog.000003
Detta alternativ är användbart för punkt-i-tid-återställning.
• --start-position=N, -j N
Börja läsa binärloggen vid N. Typen kan antingen vara ett positivt heltal eller en GTID-lista. När ett positivt heltal används gäller värdet endast för den första binärloggen som skickas på kommandoraden, och den första händelsen som har en position lika med eller större än N skrivs ut. I GTID-läge kan flera GTID:er skickas som en kommaseparerad lista, där var och en måste ha ett unikt domän-ID. Listan representerar det GTID-binärloggstillstånd som klienten (en annan "replika"-server) känner till. Därför är varje GTID exklusiv; endast händelser efter ett visst sekvens- nummer skrivs ut så att användare kan ta emot händelser efter sitt nuvarande tillstånd.
Detta alternativ är användbart för punkt-i-tid-återställning.
• --gtid-strict-mode
Bearbeta binärloggen enligt specifikationen för gtid-strict-mode. Start- och stopp-positionerna verifieras så att de uppfyller jämförelsevillkoret start < stop. Sekvensnummer i varje GTID-domän måste bestå av monotont ökande sekvenser.
• --stop-datetime=datetime
Sluta läsa binärloggen vid den första händelsen som har en tidsstämpel lika med eller senare än argumentet datetime. Detta alternativ är användbart för punkt-i-tid-återställning. Se beskrivningen av alternativet --start-datetime för information om värdet datetime.
Detta alternativ är användbart för punkt-i-tid-återställning.
• --stop-never
Vänta på mer data från servern i stället för att stanna vid slutet av den sista loggen. Innebär --to-last-log.
• --stop-never-slave-server-id
Det slave server_id som används för --read-from-remote-server --stop-never.
• --stop-position=N
Sluta läsa binärloggen vid den första händelsen som har en position lika med eller större än N. Typen kan antingen vara ett positivt heltal eller en GTID-lista. När ett positivt heltal används gäller värdet endast för den sista loggfilen som anges på kommandoraden. I GTID-läge kan flera GTID:er skickas som en kommaseparerad lista, där var och en måste ha ett unikt domän-ID. Varje GTID är inkluderande; endast händelser upp till de angivna sekvensnumren skrivs ut.
Detta alternativ är användbart för punkt-i-tid-återställning.
• --table, -T
Lista poster endast för denna tabell (endast lokal logg).
• --to-last-log, -t
Stanna inte vid slutet av den begärda binärloggen från en MariaDB-server, utan fortsätt i stället skriva ut till slutet av den sista binärloggen. Om du skickar utdata till samma MariaDB- server kan detta leda till en oändlig loop, så detta alternativ kräver --read-from-remote-server.
• --user=user_name, -u user_name
MariaDB-användarnamnet som ska användas vid anslutning till en fjärrserver.
• --verbose, -v
Återskapa radhändelser och visa dem som kommenterade SQL-satser. Om detta alternativ anges två gånger innehåller utdata kommentarer som anger kolumndatatyper och viss metadata. Om det anges tre gånger innehåller utdata diagnostiska varningar om händelse- integritet innan programmet avslutas.
För exempel som visar effekten av --base64-output och --verbose på utdata för radhändelser, se avsnittet “MARIADB-BINLOG VISNING AV RADHÄNDELSER”.
• --version, -V
Visa versionsinformation och avsluta.
Du kan också sätta följande variabel med syntaxen --var_name=value:
• open_files_limit
Ange antalet öppna filbeskrivare som ska reserveras.
Du kan skicka utdata från mariadb-binlog till klienten mariadb för att köra de händelser som finns i binärloggen. Denna teknik används för återställning efter en krasch när du har en gammal säkerhetskopia. Till exempel:
shell> mariadb-binlog binlog.000001 | mariadb -u root -p
Eller:
shell> mariadb-binlog binlog.[0-9]* | mariadb -u root -p
Du kan också omdirigera utdata från mariadb-binlog till en textfil om du först behöver ändra satsloggen (till exempel för att ta bort satser som du av någon anledning inte vill köra). Efter att ha redigerat filen, kör satserna den innehåller genom att använda den som indata till programmet mariadb:
shell> mariadb-binlog binlog.000001 > tmpfile shell> ... edit tmpfile ... shell> mariadb -u root -p < tmpfile
När mariadb-binlog anropas med alternativet --start-position visar den bara de händelser vars offset i binärloggen är större än eller lika med en given position (den givna positionen måste matcha starten på en händelse). Den har också alternativ för att stanna och starta när den ser en händelse med ett visst datum och tid. Detta gör att du kan utföra punkt-i-tid-återställning med alternativet --stop-datetime (så att du till exempel kan säga ”rulla fram mina databaser till hur de var idag klockan 10:30”).
Om du har mer än en binärlogg att köra på MariaDB-servern är den säkra metoden att bearbeta dem alla med en enda anslutning till servern. Här är ett exempel som visar vad som kan vara osäkert:
shell> mariadb-binlog binlog.000001 | mariadb -u root -p # FARA!! shell> mariadb-binlog binlog.000002 | mariadb -u root -p # FARA!!
Att bearbeta binärloggar på detta sätt med olika anslutningar till servern orsakar problem om den första loggfilen innehåller en CREATE TEMPORARY TABLE-sats och den andra loggen innehåller en sats som använder den temporära tabellen. När den första mariadb-processen avslutas släpper servern den temporära tabellen. När den andra mariadb-processen försöker använda tabellen rapporterar servern “unknown table”.
För att undvika problem som detta, använd en enda mariadb-process för att köra innehållet i alla binärloggar som du vill bearbeta. Här är ett sätt att göra det:
shell> mariadb-binlog binlog.000001 binlog.000002 | mariadb -u root -p
Ett annat tillvägagångssätt är att skriva alla loggar till en enda fil och sedan bearbeta den filen:
shell> mariadb-binlog binlog.000001 > /tmp/statements.sql shell> mariadb-binlog binlog.000002 >> /tmp/statements.sql shell> mariadb -u root -p -e "source /tmp/statements.sql"
mariadb-binlog kan producera utdata som återskapar en LOAD DATA INFILE-operation utan den ursprungliga datafilen. mariadb-binlog kopierar data till en temporär fil och skriver en LOAD DATA LOCAL INFILE-sats som refererar till filen. Standardplatsen för katalogen där dessa filer skrivs är systemspecifik. För att uttryckligen ange en katalog, använd alternativet --local-load.
Eftersom mariadb-binlog konverterar LOAD DATA INFILE-satser till LOAD DATA LOCAL INFILE-satser (det vill säga den lägger till LOCAL), måste både klienten och servern som du använder för att bearbeta satserna vara konfigurerade med LOCAL-funktionen aktiverad.
Varning
De temporära filer som skapas för LOAD DATA LOCAL-satser tas inte bort automatiskt eftersom de behövs tills du faktiskt kör dessa satser. Du bör själv ta bort de temporära filerna när du inte längre behöver satsloggen. Filerna finns i katalogen för temporära filer och har namn som original_file_name-#-#.
MARIADB-BINLOG HEXDUMP-FORMAT
Alternativet --hexdump gör att mariadb-binlog producerar en hexadump av innehållet i binärloggen:
shell> mariadb-binlog --hexdump master-bin.000001
Hex-utdata består av kommentarsrader som börjar med #, så utdata kan se ut så här för kommandot ovan:
/*!40019 SET @@session.max_delayed_threads=0*/; /*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/; # at 4 #051024 17:24:13 server id 1 end_log_pos 98 # Position Timestamp Type Master ID Size Master Pos Flags # 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 created 051024 17:24:13 # at startup ROLLBACK;
Hexdump-utdata innehåller för närvarande elementen i följande lista. Detta format kan komma att ändras. (För mer information om binärloggsformat, se http://forge.mysql.com/wiki/MySQL_Internals_Binary_Log.)
• Position: Bytepositionen i loggfilen.
• Timestamp: Händelsens tidsstämpel. I exemplet ovan är '9d fc 5c
43' den hexadecimala representationen av '051024 17:24:13'.
• Type: Händelsetypkoden. I exemplet ovan anger '0f' en
FORMAT_DESCRIPTION_EVENT. Följande tabell listar möjliga typkoder. ┌──────┬──────────────────────────┬──────────────────────────────┐ │ Typ │ Namn │ Betydelse │ ├──────┼──────────────────────────┼──────────────────────────────┤ │ 00 │ UNKNOWN_EVENT │ Denna händelse ska aldrig │ │ │ │ finnas i loggen. │ ├──────┼──────────────────────────┼──────────────────────────────┤ │ 01 │ START_EVENT_V3 │ Anger början på en loggfil │ │ │ │ skriven av MySQL 4 eller │ │ │ │ tidigare. │ ├──────┼──────────────────────────┼──────────────────────────────┤ │ 02 │ QUERY_EVENT │ Den vanligaste typen av │ │ │ │ händelser. Dessa innehåller │ │ │ │ satser som körts på mastern. │ ├──────┼──────────────────────────┼──────────────────────────────┤ │ 03 │ STOP_EVENT │ Anger att mastern har │ │ │ │ stannat. │ ├──────┼──────────────────────────┼──────────────────────────────┤ │ 04 │ ROTATE_EVENT │ Skrivs när mastern växlar │ │ │ │ till en ny loggfil. │ ├──────┼──────────────────────────┼──────────────────────────────┤ │ 05 │ INTVAR_EVENT │ Används för AUTO_INCREMENT- │ │ │ │ värden eller när funktionen │ │ │ │ LAST_INSERT_ID() används i │ │ │ │ satsen. │ ├──────┼──────────────────────────┼──────────────────────────────┤ │ 06 │ LOAD_EVENT │ Används för LOAD DATA │ │ │ │ INFILE i MySQL 3.23. │ ├──────┼──────────────────────────┼──────────────────────────────┤ │ 07 │ SLAVE_EVENT │ Reserverad för framtida │ │ │ │ användning. │ ├──────┼──────────────────────────┼──────────────────────────────┤ │ 08 │ CREATE_FILE_EVENT │ Används för LOAD DATA │ │ │ │ INFILE-satser. Anger början │ │ │ │ på körningen av en sådan │ │ │ │ sats. En temporär fil │ │ │ │ skapas på slaven. Används │ │ │ │ endast i MySQL 4. │ ├──────┼──────────────────────────┼──────────────────────────────┤ │ 09 │ APPEND_BLOCK_EVENT │ Innehåller data för │ │ │ │ användning i en LOAD DATA │ │ │ │ INFILE-sats. Datan lagras i │ │ │ │ den temporära filen på │ │ │ │ slaven. │ ├──────┼──────────────────────────┼──────────────────────────────┤ │ 0a │ EXEC_LOAD_EVENT │ Används för LOAD DATA │ │ │ │ INFILE-satser. Innehållet i │ │ │ │ den temporära filen lagras i │ │ │ │ tabellen på slaven. Används │ │ │ │ endast i MySQL 4. │ ├──────┼──────────────────────────┼──────────────────────────────┤ │ 0b │ DELETE_FILE_EVENT │ Återställning av en LOAD │ │ │ │ DATA INFILE-sats. Den │ │ │ │ temporära filen ska tas bort │ │ │ │ på slaven. │ ├──────┼──────────────────────────┼──────────────────────────────┤ │ 0c │ NEW_LOAD_EVENT │ Används för LOAD DATA │ │ │ │ INFILE i MySQL 4 och │ │ │ │ tidigare. │ ├──────┼──────────────────────────┼──────────────────────────────┤ │ 0d │ RAND_EVENT │ Används för att skicka │ │ │ │ information om slumpvärden │ │ │ │ om funktionen RAND() │ │ │ │ används i satsen. │ ├──────┼──────────────────────────┼──────────────────────────────┤ │ 0e │ USER_VAR_EVENT │ Används för att replikera │ │ │ │ användarvariabler. │ ├──────┼──────────────────────────┼──────────────────────────────┤ │ 0f │ FORMAT_DESCRIPTION_EVENT │ Anger början på en loggfil │ │ │ │ skriven av MySQL 5 eller │ │ │ │ senare. │ ├──────┼──────────────────────────┼──────────────────────────────┤ │ 10 │ XID_EVENT │ Händelse som anger commit av │ │ │ │ en XA-transaktion. │ ├──────┼──────────────────────────┼──────────────────────────────┤ │ 11 │ BEGIN_LOAD_QUERY_EVENT │ Används för LOAD DATA │ │ │ │ INFILE-satser i MySQL 5 och │ │ │ │ senare. │ ├──────┼──────────────────────────┼──────────────────────────────┤ │ 12 │ EXECUTE_LOAD_QUERY_EVENT │ Används för LOAD DATA │ │ │ │ INFILE-satser i MySQL 5 och │ │ │ │ senare. │ ├──────┼──────────────────────────┼──────────────────────────────┤ │ 13 │ TABLE_MAP_EVENT │ Information om en tabell- │ │ │ │ definition. Används i │ │ │ │ MySQL 5.1.5 och senare. │ ├──────┼──────────────────────────┼──────────────────────────────┤ │ 14 │ PRE_GA_WRITE_ROWS_EVENT │ Raddata för en enskild │ │ │ │ tabell som ska skapas. │ │ │ │ Används i MySQL 5.1.5 till │ │ │ │ 5.1.17. │ ├──────┼──────────────────────────┼──────────────────────────────┤ │ 15 │ PRE_GA_UPDATE_ROWS_EVENT │ Raddata för en enskild │ │ │ │ tabell som måste uppdateras. │ │ │ │ Används i MySQL 5.1.5 till │ │ │ │ 5.1.17. │ ├──────┼──────────────────────────┼──────────────────────────────┤ │ 16 │ PRE_GA_DELETE_ROWS_EVENT │ Raddata för en enskild │ │ │ │ tabell som ska tas bort. │ │ │ │ Används i MySQL 5.1.5 till │ │ │ │ 5.1.17. │ ├──────┼──────────────────────────┼──────────────────────────────┤ │ 17 │ WRITE_ROWS_EVENT │ Raddata för en enskild │ │ │ │ tabell som ska skapas. │ │ │ │ Används i MySQL 5.1.18 och │ │ │ │ senare. │ ├──────┼──────────────────────────┼──────────────────────────────┤ │ 18 │ UPDATE_ROWS_EVENT │ Raddata för en enskild │ │ │ │ tabell som måste uppdateras. │ │ │ │ Används i MySQL 5.1.18 och │ │ │ │ senare. │ ├──────┼──────────────────────────┼──────────────────────────────┤ │ 19 │ DELETE_ROWS_EVENT │ Raddata för en enskild │ │ │ │ tabell som ska tas bort. │ │ │ │ Används i MySQL 5.1.18 och │ │ │ │ senare. │ ├──────┼──────────────────────────┼──────────────────────────────┤ │ 1a │ INCIDENT_EVENT │ Något ovanligt inträffade. │ │ │ │ Tillagt i MySQL 5.1.18. │ └──────┴──────────────────────────┴──────────────────────────────┘
• Master ID: Server-ID för den master som skapade händelsen.
• Size: Storleken i byte för händelsen.
• Master Pos: Positionen för nästa händelse i den ursprungliga
masterloggfilen.
• Flags: 16 flaggor. För närvarande används följande flaggor. De
övriga är reserverade för framtida användning. ┌──────┬─────────────────────────────┬──────────────────────────────┐ │ Flag │ Namn │ Betydelse │ ├──────┼─────────────────────────────┼──────────────────────────────┤ │ 01 │ LOG_EVENT_BINLOG_IN_USE_F │ Loggfilen stängdes korrekt. │ │ │ │ (Används endast i │ │ │ │ FORMAT_DESCRIPTION_EVENT.) │ │ │ │ Om denna flagga är satt │ │ │ │ (om flaggorna till exempel │ │ │ │ är '01 00') i en │ │ │ │ FORMAT_DESCRIPTION_EVENT, │ │ │ │ har loggfilen inte stängts │ │ │ │ korrekt. Troligast beror │ │ │ │ detta på en masterkrasch │ │ │ │ (t.ex. strömavbrott). │ ├──────┼─────────────────────────────┼──────────────────────────────┤ │ 02 │ │ Reserverad för framtida │ │ │ │ användning. │ ├──────┼─────────────────────────────┼──────────────────────────────┤ │ 04 │ LOG_EVENT_THREAD_SPECIFIC_F │ Satt om händelsen beror på │ │ │ │ den anslutning där den │ │ │ │ kördes (t.ex. '04 00'), │ │ │ │ till exempel om händelsen │ │ │ │ använder temporära tabeller.│ ├──────┼─────────────────────────────┼──────────────────────────────┤ │ 08 │ LOG_EVENT_SUPPRESS_USE_F │ Satt i vissa fall när │ │ │ │ händelsen inte beror på │ │ │ │ standarddatabasen. │ └──────┴─────────────────────────────┴──────────────────────────────┘
MARIADB-BINLOG VISNING AV RADHÄNDELSER
Följande exempel illustrerar hur mariadb-binlog visar radhändelser som anger dataändringar. Dessa motsvarar händelser med typkoderna WRITE_ROWS_EVENT, UPDATE_ROWS_EVENT och DELETE_ROWS_EVENT. Alternativen --base64-output=DECODE-ROWS och --verbose kan användas för att påverka utdata för radhändelser.
Anta att servern använder radbaserad binärloggning och att du kör följande sekvens av satser:
CREATE TABLE t
(
id INT NOT NULL,
name VARCHAR(20) NOT NULL,
date DATE NULL
) ENGINE = InnoDB;
START TRANSACTION;
INSERT INTO t VALUES(1, 'apple', NULL);
UPDATE t SET name = 'pear', date = '2009-01-01' WHERE id = 1;
DELETE FROM t WHERE id = 1;
COMMIT;
Som standard visar mariadb-binlog radhändelser kodade som base64- strängar med BINLOG-satser. Om man utelämnar ovidkommande rader ser utdata för radhändelserna som produceras av satssekvensen ovan ut så här:
shell> mariadb-binlog log_file ... # at 218 #080828 15:03:08 server id 1 end_log_pos 258 Write_rows: table id 17 flags: STMT_END_F BINLOG 'fAS3SBMBAAAALAAAANoAAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ= fAS3SBcBAAAAKAAAAAIBAAAQABEAAAAAAAEAA//8AQAAAAVhcHBsZQ=='/*!*/; ... # at 302 #080828 15:03:08 server id 1 end_log_pos 356 Update_rows: table id 17 flags: STMT_END_F BINLOG 'fAS3SBMBAAAALAAAAC4BAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ= fAS3SBgBAAAANgAAAGQBAAAQABEAAAAAAAEAA////AEAAAAFYXBwbGX4AQAAAARwZWFyIbIP'/*!*/; ... # at 400 #080828 15:03:08 server id 1 end_log_pos 442 Delete_rows: table id 17 flags: STMT_END_F BINLOG 'fAS3SBMBAAAALAAAAJABAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ= fAS3SBkBAAAAKgAAALoBAAAQABEAAAAAAAEAA//4AQAAAARwZWFyIbIP'/*!*/;
För att se radhändelserna som kommentarer i form av “pseudo-SQL”- satser, kör mariadb-binlog med alternativet --verbose eller -v. Utdata kommer då att innehålla rader som börjar med ###:
shell> mariadb-binlog -v log_file ... # at 218 #080828 15:03:08 server id 1 end_log_pos 258 Write_rows: table id 17 flags: STMT_END_F BINLOG 'fAS3SBMBAAAALAAAANoAAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ= fAS3SBcBAAAAKAAAAAIBAAAQABEAAAAAAAEAA//8AQAAAAVhcHBsZQ=='/*!*/; ### INSERT INTO test.t ### SET ### @1=1 ### @2='apple' ### @3=NULL ... # at 302 #080828 15:03:08 server id 1 end_log_pos 356 Update_rows: table id 17 flags: STMT_END_F BINLOG 'fAS3SBMBAAAALAAAAC4BAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ= fAS3SBgBAAAANgAAAGQBAAAQABEAAAAAAAEAA////AEAAAAFYXBwbGX4AQAAAARwZWFyIbIP'/*!*/; ### UPDATE test.t ### WHERE ### @1=1 ### @2='apple' ### @3=NULL ### SET ### @1=1 ### @2='pear' ### @3='2009:01:01' ... # at 400 #080828 15:03:08 server id 1 end_log_pos 442 Delete_rows: table id 17 flags: STMT_END_F BINLOG 'fAS3SBMBAAAALAAAAJABAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ= fAS3SBkBAAAAKgAAALoBAAAQABEAAAAAAAEAA//4AQAAAARwZWFyIbIP'/*!*/; ### DELETE FROM test.t ### WHERE ### @1=1 ### @2='pear' ### @3='2009:01:01'
Ange --verbose eller -v två gånger för att också visa datatyper och viss metadata för varje kolumn. Utdata kommer då att innehålla en ytterligare kommentar efter varje kolumnändring:
shell> mariadb-binlog -vv log_file ... # at 218 #080828 15:03:08 server id 1 end_log_pos 258 Write_rows: table id 17 flags: STMT_END_F BINLOG 'fAS3SBMBAAAALAAAANoAAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ= fAS3SBcBAAAAKAAAAAIBAAAQABEAAAAAAAEAA//8AQAAAAVhcHBsZQ=='/*!*/; ### INSERT INTO test.t ### SET ### @1=1 /* INT meta=0 nullable=0 is_null=0 */ ### @2='apple' /* VARSTRING(20) meta=20 nullable=0 is_null=0 */ ### @3=NULL /* VARSTRING(20) meta=0 nullable=1 is_null=1 */ ... # at 302 #080828 15:03:08 server id 1 end_log_pos 356 Update_rows: table id 17 flags: STMT_END_F BINLOG 'fAS3SBMBAAAALAAAAC4BAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ= fAS3SBgBAAAANgAAAGQBAAAQABEAAAAAAAEAA////AEAAAAFYXBwbGX4AQAAAARwZWFyIbIP'/*!*/; ### UPDATE test.t ### WHERE ### @1=1 /* INT meta=0 nullable=0 is_null=0 */ ### @2='apple' /* VARSTRING(20) meta=20 nullable=0 is_null=0 */ ### @3=NULL /* VARSTRING(20) meta=0 nullable=1 is_null=1 */ ### SET ### @1=1 /* INT meta=0 nullable=0 is_null=0 */ ### @2='pear' /* VARSTRING(20) meta=20 nullable=0 is_null=0 */ ### @3='2009:01:01' /* DATE meta=0 nullable=1 is_null=0 */ ... # at 400 #080828 15:03:08 server id 1 end_log_pos 442 Delete_rows: table id 17 flags: STMT_END_F BINLOG 'fAS3SBMBAAAALAAAAJABAAAAABEAAAAAAAAABHRlc3QAAXQAAwMPCgIUAAQ= fAS3SBkBAAAAKgAAALoBAAAQABEAAAAAAAEAA//4AQAAAARwZWFyIbIP'/*!*/; ### DELETE FROM test.t ### WHERE ### @1=1 /* INT meta=0 nullable=0 is_null=0 */ ### @2='pear' /* VARSTRING(20) meta=20 nullable=0 is_null=0 */ ### @3='2009:01:01' /* DATE meta=0 nullable=1 is_null=0 */
Du kan be mariadb-binlog att undertrycka BINLOG-satserna för radhändelser genom att använda alternativet --base64-output=DECODE-ROWS. Detta liknar --base64-output=NEVER men avslutas inte med fel om en radhändelse hittas. Kombinationen av --base64-output=DECODE-ROWS och --verbose ger ett bekvämt sätt att se radhändelser endast som SQL-satser:
shell> mariadb-binlog -v --base64-output=DECODE-ROWS log_file ... # at 218 #080828 15:03:08 server id 1 end_log_pos 258 Write_rows: table id 17 flags: STMT_END_F ### INSERT INTO test.t ### SET ### @1=1 ### @2='apple' ### @3=NULL ... # at 302 #080828 15:03:08 server id 1 end_log_pos 356 Update_rows: table id 17 flags: STMT_END_F ### UPDATE test.t ### WHERE ### @1=1 ### @2='apple' ### @3=NULL ### SET ### @1=1 ### @2='pear' ### @3='2009:01:01' ... # at 400 #080828 15:03:08 server id 1 end_log_pos 442 Delete_rows: table id 17 flags: STMT_END_F ### DELETE FROM test.t ### WHERE ### @1=1 ### @2='pear' ### @3='2009:01:01'
Observera
Du bör inte undertrycka BINLOG-satser om du tänker köra om utdata från mariadb-binlog.
SQL-satserna som produceras av --verbose för radhändelser är mycket mer läsbara än motsvarande BINLOG-satser. De motsvarar dock inte exakt de ursprungliga SQL-satser som genererade händelserna. Följande begränsningar gäller:
• De ursprungliga kolumnnamnen går förlorade och ersätts med @N, där
N är ett kolumnnummer.
• Information om teckenuppsättning finns inte tillgänglig i
binärloggen, vilket påverkar visning av strängkolumner:
• Ingen skillnad görs mellan motsvarande binära och icke-binäre
strängtyper (BINARY och CHAR, VARBINARY och VARCHAR, BLOB och
TEXT). Utdata använder datatypen STRING för strängar med fast
längd och VARSTRING för strängar med variabel längd.
• För flerbytes-teckenuppsättningar finns det maximala antalet
byte per tecken inte i binärloggen, så längden för
strängtyper visas i byte snarare än i tecken. Till exempel
kommer STRING(4) att användas som datatyp för värden från
någon av dessa kolumntyper:
CHAR(4) CHARACTER SET latin1
CHAR(2) CHARACTER SET ucs2
• På grund av lagringsformatet för händelser av typen
UPDATE_ROWS_EVENT visas UPDATE-satser med WHERE-klausulen
före SET-klausulen.
Korrekt tolkning av radhändelser kräver informationen från formatbeskrivningshändelsen i början av binärloggen. Eftersom mariadb-binlog inte i förväg vet om resten av loggen innehåller radhändelser, visar den som standard formatbeskrivningshändelsen med en BINLOG-sats i början av utdata.
Om binärloggen är känd för att inte innehålla några händelser som kräver en BINLOG-sats (det vill säga inga radhändelser), kan alternativet --base64-output=NEVER användas för att förhindra att detta huvud skrivs ut.
UPPHOVSRÄTT
Copyright 2007-2008 MySQL AB, 2008-2010 Sun Microsystems, Inc., 2010-2025 MariaDB Foundation
Denna dokumentation är fri programvara; du kan vidaredistribuera den och/eller ändra den endast enligt villkoren i GNU General Public License såsom publicerad av Free Software Foundation; version 2 av licensen.
Denna dokumentation distribueras i hopp om att den ska vara användbar, men UTAN NÅGON GARANTI; utan ens underförstådd garanti om SÄLJBARHET eller LÄMPLIGHET FÖR ETT VISST ÄNDAMÅL. Se GNU General Public License för mer information.
Du bör ha fått en kopia av GNU General Public License tillsammans med programmet; om inte, skriv till Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1335 USA eller se http://www.gnu.org/licenses/.
ANMÄRKNINGAR
1. Bug#42941 http://bugs.mysql.com/bug.php?id=42941
SE ÄVEN
För mer information, se MariaDB Knowledge Base, tillgänglig online på https://mariadb.com/kb/
FÖRFATTARE
MariaDB Foundation (http://www.mariadb.org/).
KOLOFON
Denna sida är en del av projektet MariaDB (MariaDB-databasserver). Information om projektet finns på ⟨http://mariadb.org/⟩. Om du har en felrapport för denna manualsida, se ⟨https://mariadb.com/kb/en/mariadb/reporting-bugs/⟩. Denna sida hämtades från projektets uppströms Git-arkiv ⟨https://github.com/MariaDB/server⟩ den 2026-01-16. (Vid den tidpunkten var datumet för den senaste commit som hittades i arkivet 2026-01-16.) Om du upptäcker renderingsproblem i denna HTML-version av sidan, eller om du tror att det finns en bättre eller mer uppdaterad källa för sidan, eller om du har korrigeringar eller förbättringar av informationen i denna KOLOFON (som inte är en del av den ursprungliga manualsidan), skicka e-post till man-pages@man7.org
MariaDB 11.8 5 mars 2025 MARIADB-BINLOG(1)
Sidslut
Orginalhemsidan på Engelska https://man7.org/linux/man-pages/man1/mariadb-binlog.1.html
Det här är en maskinöversättning av Linux man sidor till svenska. Om du hittar fel är vi tacksamma om du rapporterar dem via formuläret som finns på
https://www.linux.se/kontaka-linux-se/
Tack till PC Service som har sponsrat Linux.se med webbhotell.