mariadb-binlog(1): Skillnad mellan sidversioner
Hoppa till navigering
Hoppa till sök
Admin (diskussion | bidrag) |
Admin (diskussion | bidrag) |
||
| Rad 762: | Rad 762: | ||
== MARIADB-BINLOG VISNING AV RADHÄNDELSER == | == MARIADB-BINLOG VISNING AV RADHÄNDELSER == | ||
Följande exempel illustrerar hur mariadb-binlog visar radhändelser som | Följande exempel illustrerar hur mariadb-binlog visar radhändelser som | ||
anger dataändringar. Dessa motsvarar händelser med typkoderna | anger dataändringar. Dessa motsvarar händelser med typkoderna | ||
| Rad 967: | Rad 966: | ||
alternativet --base64-output=NEVER användas för att förhindra att | alternativet --base64-output=NEVER användas för att förhindra att | ||
detta huvud skrivs ut. | detta huvud skrivs ut. | ||
== UPPHOVSRÄTT == | == UPPHOVSRÄTT == | ||
Versionen från 18 april 2026 kl. 11.36
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.