{"id":21299,"date":"2026-09-11T15:08:03","date_gmt":"2026-09-11T13:08:03","guid":{"rendered":"https:\/\/webhosting.de\/mariadb-binary-logs-performance-logik\/"},"modified":"2026-09-11T15:08:03","modified_gmt":"2026-09-11T13:08:03","slug":"mariadb-binaerloggar-prestanda-logik","status":"publish","type":"post","link":"https:\/\/webhosting.de\/sv\/mariadb-binary-logs-performance-logik\/","title":{"rendered":"MariaDB:s bin\u00e4rloggar: uppbyggnad, anv\u00e4ndning och prestanda"},"content":{"rendered":"<p><strong>MariaDB:s bin\u00e4ra loggar<\/strong> registrerar varje skrivoperation och styr replikering, \u00e5terst\u00e4llning och granskning i produktionsinstanser. Jag visar hur uppbyggnad, format och nya InnoDB-binloggar samverkar, var de ger f\u00f6rdelar och vilka inst\u00e4llningar som p\u00e5verkar prestandan i verkliga arbetsbelastningar.<\/p>\n\n<h2>Centrala punkter<\/h2>\n<ul>\n  <li><strong>Struktur<\/strong>: Filer, index, h\u00e4ndelser; utmatning i klartext via mariadb-binlog<\/li>\n  <li><strong>Format<\/strong>: Statement, Row, Mixed \u2013 v\u00e4lj efter arbetsbelastningen<\/li>\n  <li><strong>Replikering<\/strong>: Beakta position kontra GTID och kompatibilitet<\/li>\n  <li><strong>Prestanda<\/strong>: Group Commit, flush-strategier, lagrings-I\/O<\/li>\n  <li><strong>Administration<\/strong>: Rotation, lagring, analys och fels\u00f6kning<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb-binarylogs-1293.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Uppbyggnad: filer, index och h\u00e4ndelser<\/h2>\n\n<p>En binlog best\u00e5r av binlog-filer och ett index som h\u00e5ller reda p\u00e5 ordningen och m\u00f6jligg\u00f6r selektiv l\u00e4sning; detta <strong>Indexfil<\/strong> g\u00f6r hanteringen planerbar. Varje fil lagrar h\u00e4ndelser som avspeglar DML och DDL, inklusive transaktionsgr\u00e4nser och metadata per h\u00e4ndelse. Jag l\u00e4ser ut denna information vid behov med <strong>mariadb-binlog<\/strong> och f\u00e5r d\u00e4rmed l\u00e4ttanalyserbar klartext. Binloggarna f\u00f6rblir bin\u00e4ra, s\u00e5 att skrivprestanda och lagringsbehov f\u00f6rblir effektiva i den dagliga driften. Viktigt: Jag kontrollerar regelbundet h\u00e4ndelsetyperna, eftersom de avsl\u00f6jar om det aktiva loggningsformatet passar den aktuella belastningen.<\/p>\n\n<h2>Binlog-format: Statement, Row, Mixed<\/h2>\n\n<p>MariaDB st\u00f6der statement-, row- och mixed-logging, och jag v\u00e4ljer beroende p\u00e5 skrivm\u00f6nstret; detta <strong>Format<\/strong> styr filstorlek, replikeringss\u00e4kerhet och n\u00e4tverksbehov. Statement lagrar SQL-satsen, \u00e4r ofta mer kompakt men kan leda till avvikelser vid icke-deterministiska funktioner. Row loggar de ber\u00f6rda raderna och h\u00e5ller replikerna mycket n\u00e4ra originalet, men genererar st\u00f6rre loggvolymer. Mixed v\u00e4ljer dynamiskt och f\u00f6rs\u00f6ker hitta den b\u00e4sta avv\u00e4gningen mellan noggrannhet och volym. F\u00f6r konsekvent replikering f\u00f6redrar jag Row eller Mixed i k\u00e4nsliga system och kontrollerar d\u00e4refter latensen.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th><strong>Format<\/strong><\/th>\n      <th><strong>Minne<\/strong><\/th>\n      <th><strong>Noggrannhet<\/strong><\/th>\n      <th><strong>Typisk anv\u00e4ndning<\/strong><\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Uttalande<\/td>\n      <td>L\u00e5g<\/td>\n      <td>Medel (beroende p\u00e5 funktioner\/utl\u00f6sare)<\/td>\n      <td>M\u00e5nga rader per sats, l\u00e5g n\u00e4tbelastning<\/td>\n    <\/tr>\n    <tr>\n      <td>Rad<\/td>\n      <td>H\u00f6gre<\/td>\n      <td>H\u00f6g (radbaserad, deterministisk)<\/td>\n      <td>K\u00e4nsliga uppgifter, heterogen replikering<\/td>\n    <\/tr>\n    <tr>\n      <td>Blandad<\/td>\n      <td>Medium<\/td>\n      <td>H\u00f6g (beroende p\u00e5 situationen)<\/td>\n      <td>Blandade arbetsbelastningar \u2013 standard i m\u00e5nga installationer<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>InnoDB-baserade binloggar fr\u00e5n och med version 12.3<\/h2>\n\n<p>Fr\u00e5n och med version 12.3 kan MariaDB spara binlog-h\u00e4ndelser i InnoDB-hanterade filer med fil\u00e4ndelsen .ibb, vilket underl\u00e4ttar integrationen med <strong>InnoDB<\/strong> \u00f6kad. Jag drar nytta av en t\u00e4t integrering med redo-loggar och en f\u00f6renklad \u00e5terst\u00e4llningsprocess vid krasch. \u00d6verheaden f\u00f6r tv\u00e5fas-commit mellan lagringsmotorn och den klassiska binloggen minskar d\u00e4rmed m\u00e4rkbart. S\u00e4rskilt vid h\u00f6g skrivbelastning minskar detta antalet n\u00f6dv\u00e4ndiga flushar och stabiliserar commit-tiderna under press. Innan bytet testar jag dock verktyg, \u00f6vervakning och s\u00e4kerhetskopieringsprocesser, eftersom driftsmodellen f\u00f6r\u00e4ndrar vissa arbetsfl\u00f6den j\u00e4mf\u00f6rt med klassiska filer.<\/p>\n\n<h2>Replikering: Position, GTID och konsistens<\/h2>\n\n<p>Vid replikering l\u00e4ser en replik binlog-h\u00e4ndelserna fr\u00e5n prim\u00e4rservern och genomf\u00f6r dem i samma ordning, s\u00e5 att jag f\u00e5r en konsekvent <strong>Uppgifter<\/strong> \u00f6ver flera noder. Vanligtvis sp\u00e5rar jag filnamn och position; med GTID f\u00f6renklas hanteringen av failover och \u00e5terupptagningen efter avbrott. I blandade MariaDB\/MySQL-milj\u00f6er \u00e4r jag uppm\u00e4rksam p\u00e5 skillnader i GTID:er och tolkning av h\u00e4ndelser. F\u00f6r klusteromfattande tillg\u00e4nglighet planerar jag topologier medvetet och tittar g\u00e4rna p\u00e5 \u00f6versk\u00e5dliga sammanfattningar som <a href=\"https:\/\/webhosting.de\/sv\/databasreplikering-topologier-webbhotell-klusterkonfiguration-skalning-databas\/\">Replikering av databas<\/a>. Viktigt: Jag dokumenterar replikeringsf\u00f6nstren och s\u00e4kerhetskopierar binlog-historiken s\u00e5 att ingen replik \u201esv\u00e4lter\u201c och d\u00e4rmed m\u00e5ste startas om.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb_binarylogs_meeting_3748.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>N\u00e4r bin\u00e4rloggar ger st\u00f6rst nytta<\/h2>\n\n<p>Jag anv\u00e4nder binloggar n\u00e4r jag vill sp\u00e5ra \u00e4ndringar, \u00e5terst\u00e4lla dem eller \u00f6verf\u00f6ra dem till flera servrar; dessa <strong>\u00d6ppenhet<\/strong> f\u00f6rb\u00e4ttrar driften och efterlevnaden. Typiska scenarier \u00e4r h\u00f6g tillg\u00e4nglighet med repliker, \u00e5terst\u00e4llning till en viss tidpunkt efter felaktig hantering och forensiska analyser. F\u00f6r webbutiker med h\u00f6g skrivaktivitet s\u00e4kerhetskopierar jag binloggar med korta intervall och planerar lagringstiden utifr\u00e5n RPO\/RTO-kraven. Inf\u00f6r revisioner exporterar jag specifika tidsperioder via mariadb-binlog och granskar DDL-h\u00e4ndelser separat. Den som f\u00f6rdjupar sig i prestandaanalyser kan utvinna v\u00e4rdefull information om \u201dhot tables\u201d och l\u00e5sm\u00f6nster ur h\u00e4ndelserna.<\/p>\n\n<h2>S\u00e4kerhetskopiering och \u00e5terst\u00e4llning till en viss tidpunkt med binloggar<\/h2>\n\n<p>F\u00f6r en exakt \u00e5terst\u00e4llning kombinerar jag en konsistent fullst\u00e4ndig s\u00e4kerhetskopia med de efterf\u00f6ljande binloggarna; dessa <strong>Kombination<\/strong> s\u00e4kerst\u00e4ller tillst\u00e5ndet fram till strax f\u00f6re incidenten. Arbetsfl\u00f6det \u00e4r tydligt: skapa en s\u00e4kerhetskopia, fastst\u00e4ll tidpunkten f\u00f6r felet och importera sedan binloggarna fram till den sekunden. Jag testar processen regelbundet i separata instanser f\u00f6r att undvika \u00f6verraskningar i en akut situation. Den som vill f\u00f6rdjupa sig i transaktioner och \u00e5terst\u00e4llningsstrategier hittar bakgrundsinformation om <a href=\"https:\/\/webhosting.de\/sv\/databasens-transaktionsloggar-aterstaellningsprocesser-databasskydd-saeker\/\">Transaktionsloggar och \u00e5terst\u00e4llning<\/a>. Se till att ta h\u00e4nsyn till binlog-formatet och SQL_MODE vid importen, s\u00e5 att funktioner och triggare reagerar p\u00e5 samma s\u00e4tt.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb-binary-logs-performance-8472.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Effekter p\u00e5 prestanda och overhead<\/h2>\n\n<p>Aktiv bin\u00e4r loggning medf\u00f6r extra skrivarbetet, vilket jag alltid r\u00e4knar med n\u00e4r jag planerar f\u00f6r latensbudgetar; detta <strong>\u00d6vertid<\/strong> varierar beroende p\u00e5 lagringsmedel, format och transaktionsstorlek. Group Commit sammanf\u00f6r flera transaktioner per flush och minskar I\/O per commit. F\u00e4rre men st\u00f6rre I\/O-operationer \u00f6kar ofta genomstr\u00f6mningen, s\u00e5 l\u00e4nge lagringsstacken h\u00e4nger med. Var uppm\u00e4rksam p\u00e5 synkroniseringsstrategier som sync_binlog och OS-cache-beteende, eftersom f\u00f6r strikta flush-inst\u00e4llningar bromsar systemet. Om du observerar latens vid replikering b\u00f6r du optimera kontinuerligt mot <a href=\"https:\/\/webhosting.de\/sv\/mysql-replikeringsfoerdroejning-hostingoptimering-serverfoerdroejning\/\">Replikationsf\u00f6rdr\u00f6jning<\/a> och m\u00e4ter f\u00f6r\u00e4ndringar p\u00e5 ett m\u00e5linriktat s\u00e4tt.<\/p>\n\n<h2>Group Commit- och Flush-strategier<\/h2>\n\n<p>Jag st\u00e4ller in Group Commit s\u00e5 att skrivbelastningen kommer i v\u00e5gor och lagringssystemet fungerar effektivt; detta <strong>Tuning<\/strong> har ofta st\u00f6rre effekt \u00e4n CPU-optimering. Parametrar som binlog_group_commit_sync_delay och antalet buffrade h\u00e4ndelser styr tidsf\u00f6nstret f\u00f6r sammanf\u00f6ring. InnoDB-alternativ som innodb_flush_log_at_trx_commit och valet av filsystem avg\u00f6r hur kostsam en t\u00f6mning blir. P\u00e5 SSD\/NVMe med write-back-cache kan jag v\u00e5ga anv\u00e4nda n\u00e5got st\u00f6rre buffertar, medan jag p\u00e5 l\u00e5ngsam n\u00e4tverkslagring helst h\u00e5ller mig konservativ. F\u00f6r kontrollm\u00e4tningar varierar jag endast en parameter per testk\u00f6rning och h\u00e5ller transaktionsstorlekarna konstanta.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/TechOfficeMariaDBNight_8491.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Val av format och arbetsbelastningsm\u00f6nster<\/h2>\n\n<p>Jag v\u00e4ljer \u201dStatement\u201d n\u00e4r ett f\u00e5tal satser p\u00e5verkar v\u00e4ldigt m\u00e5nga rader och f\u00f6rblir deterministiska; detta <strong>Beteende<\/strong> sparar n\u00e4tverksresurser och lagringsutrymme. Vid anv\u00e4ndning av triggare, UUID:er, NOW() eller RAND() st\u00e4ller jag in Row s\u00e5 att replikerna n\u00e5r exakt samma tillst\u00e5nd. Mixed passar bra f\u00f6r blandade m\u00f6nster d\u00e4r vissa satser \u00e4ndrar m\u00e5nga rader medan andra endast g\u00f6r punktvisa \u00e4ndringar. F\u00f6r ETL-jobb med bulk-inserts \u00f6vertygar \u201dStatement\u201d ofta genom sm\u00e5 loggar; vid event sourcing-m\u00f6nster vinner \u201dRow\u201d genom exakta rad\u00e4ndringar. Efter varje omst\u00e4llning observerar jag filstorlek, till\u00e4mpningstid p\u00e5 replikerna och eventuella f\u00f6rdr\u00f6jningar.<\/p>\n\n<h2>Styra loggrotation och lagring<\/h2>\n\n<p>F\u00f6r att loggarna inte ska bli f\u00f6r omfattande roterar jag dem aktivt och fastst\u00e4ller en lagringstid; denna <strong>Disciplin<\/strong> sparar lagringsutrymme och h\u00e5ller \u00e5terst\u00e4llningskedjorna intakta. Med FLUSH BINARY LOGS skapar jag nya filer, medan Purge-kommandon rensar bort gamla artefakter. Tidsbaserade inst\u00e4llningar som binlog_expire_logs_seconds underl\u00e4ttar automatisk underh\u00e5ll. Viktigt: Jag raderar ingenting s\u00e5 l\u00e4nge en replik eventuellt fortfarande beh\u00f6ver filerna. Vid flaskhalsar flyttar jag binloggar till snabbare lagringsutrymme eller separerar data- och loggvolymer.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb_logs_desk_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Fels\u00f6kning med mariadb-binlog<\/h2>\n\n<p>Om replikeringen avstannar l\u00e4ser jag ut de ber\u00f6rda h\u00e4ndelserna med mariadb-binlog och kontrollerar tidsst\u00e4mplar, XID:er och fel; dessa <strong>Analys<\/strong> visar ofta bristande DDL-beh\u00f6righeter eller icke-deterministiska funktioner. Jag j\u00e4mf\u00f6r GTID-tillst\u00e5nd eller filterregler f\u00f6r att hitta blockerande satser. Vid dubbla nycklar kan jag snabbt avg\u00f6ra om ett nytt f\u00f6rs\u00f6k eller ett filter l\u00f6ser problemet. Jag uppt\u00e4cker luckor i kedjan genom hopp i indexet eller ov\u00e4ntade filnamn. D\u00e4refter anpassar jag filter och format s\u00e5 att f\u00f6ljdproblem inte uppst\u00e5r \u00f6verhuvudtaget.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/mariadb-performance-log-8274.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Praktisk guide: Inst\u00e4llningar efter m\u00e5l<\/h2>\n\n<p>Jag b\u00f6rjar med blandad loggning och m\u00e4ter om storleken och replikeringstiden st\u00e4mmer; dessa <strong>Baslinje<\/strong> ger en r\u00e4ttvis j\u00e4mf\u00f6relsegrund. Om latensen \u00f6kar vid commit kontrollerar jag f\u00f6rst Group-Commit-parametrarna och synkroniseringspolicyn. Om minnesbehovet \u00f6kar f\u00f6r mycket testar jag satser i deterministiska batcher eller arkiverar binloggarna tidigare. Vid h\u00f6g avbrottsk\u00e4nslighet tittar jag p\u00e5 de InnoDB-baserade binloggarna, eftersom f\u00e4rre flushar h\u00e5ller commit-tiden mer stabil. Jag dokumenterar kort varje \u00e4ndring s\u00e5 att senare m\u00e4tningar f\u00f6rblir tydligt tillskrivna.<\/p>\n\n<h2>S\u00e4kerhet och efterlevnad: kryptering, \u00e5tkomst, integritet<\/h2>\n<p>Jag s\u00e4kerhetskopierar binloggar p\u00e5 samma s\u00e4tt som produktionsdata: endast beh\u00f6riga konton f\u00e5r l\u00e4sbeh\u00f6righet till filsystemet, och jag aktiverar \u2013 beroende p\u00e5 version \u2013 kryptering av binloggarna. P\u00e5 s\u00e5 s\u00e4tt f\u00f6rblir data skyddade \u00e4ven n\u00e4r de \u00e4r inaktiva, \u00e4ven om s\u00e4kerhetskopiorna sparas p\u00e5 externa lagringsmedier. Dessutom st\u00e4ller jag in <strong>binlog_checksumma<\/strong> (oftast CRC32) f\u00f6r att kontrollera integriteten vid \u00f6verf\u00f6ringen. Den som behandlar personuppgifter fastst\u00e4ller lagringstider i raderingskonceptet och kontrollerar regelbundet om rotationen faktiskt uppfyller dessa krav. F\u00f6r revisioner har jag en definierad exportv\u00e4g d\u00e4r jag extraherar relevanta tidsintervall fr\u00e5n binloggarna och lagrar dem p\u00e5 ett revisionss\u00e4kert s\u00e4tt.<\/p>\n\n<h2>Parallell replikering och justering av appliceraren<\/h2>\n<p>F\u00f6r snabbare bearbetning p\u00e5 repliker anv\u00e4nder jag parallell replikering. I MariaDB styr jag detta fr\u00e4mst via <strong>slave_parallel_threads<\/strong> och l\u00e4get <strong>slave_parallel_mode<\/strong> (konservativt kontra optimistiskt). Fler Applier-tr\u00e5dar \u00e4r s\u00e4rskilt till hj\u00e4lp vid oberoende transaktioner eller separata <em>domain_id<\/em>\u2011omr\u00e5den i GTID:er. Jag \u00f6vervakar samtidigt konfliktfrekvensen och deadlocks: om de \u00f6kar minskar jag antalet tr\u00e5dar eller v\u00e4ljer ett mer konservativt l\u00e4ge. P\u00e5 lagringssidan kr\u00e4ver parallell till\u00e4mpning tillr\u00e4cklig IOPS-reserv, annars flyttas flaskhalsen bara fr\u00e5n n\u00e4tverket till h\u00e5rddiskarna. Viktigt: Antalet till\u00e4mpare har ingen inverkan om binloggen huvudsakligen inneh\u00e5ller stora enskilda transaktioner som \u00e4nd\u00e5 m\u00e5ste bearbetas seriellt.<\/p>\n\n<h2>Filterregler, GTID:er och blandade milj\u00f6er<\/h2>\n<p>Med <strong>binlog_do_db<\/strong> och <strong>binlog_ignore_db<\/strong> Jag minskar loggvolymen redan p\u00e5 prim\u00e4rservern och begr\u00e4nsar till\u00e4mpningsomf\u00e5nget med replikeringsfilter p\u00e5 replikerna. Vid satsloggning ser jag till att den aktuella databasen \u00e4r korrekt inst\u00e4lld, annars fungerar filtren inte som f\u00f6rv\u00e4ntat. I GTID-konfigurationer dokumenterar jag <em>domain_id<\/em>\u2011Anv\u00e4ndning (specifikt f\u00f6r MariaDB), s\u00e5 att replikering fr\u00e5n flera k\u00e4llor f\u00f6rblir kontrollerad. I blandade MariaDB\/MySQL-milj\u00f6er kontrollerar jag i f\u00f6rv\u00e4g h\u00e4ndelsekompatibilitet och GTID-dialekter; Skillnader finns inte bara i syntaxen, utan \u00e4ven i detaljbeteendet (t.ex. trigger-semantik, radbild). Jag planerar d\u00e4rf\u00f6r migreringar med testk\u00f6rningar som skickar verkliga produktionsh\u00e4ndelser genom m\u00e5lstacken.<\/p>\n\n<h2>DDL-h\u00e4ndelser, \u00e4ndringar online och l\u00e5sningar<\/h2>\n<p>DDL skriver ocks\u00e5 till binloggen och kan binda repliker under l\u00e5ng tid \u2013 s\u00e4rskilt vid schemab\u00e4ndringar i stora tabeller. N\u00e4r det \u00e4r m\u00f6jligt anv\u00e4nder jag online-uppdateringar med minimal l\u00e5sning och tidsbegr\u00e4nsar riskfyllda operationer till underh\u00e5llsf\u00f6nster. Jag \u00f6vervakar metadatasp\u00e4rrar (MDL) och kontrollerar om DDL-h\u00e4ndelser p\u00e5 repliker blockerar andra satser p\u00e5 grund av filter eller ordningsf\u00f6ljd. Innan st\u00f6rre ombyggnader roterar jag binloggen medvetet f\u00f6r att f\u00e5 en tydlig avgr\u00e4nsning f\u00f6r s\u00e4kerhetskopiering eller \u00e5terst\u00e4llning. Vid revisioner skiljer jag p\u00e5 DDL- och DML-analyser, eftersom schemab\u00e4ndringar ofta \u00e4r orsaken till data som till synes \u201esaknas\u201c, men som i sj\u00e4lva verket bara har migrerats till nya strukturer.<\/p>\n\n<h2>Finjustera Row\u2011Image, cacheminnen och minnesbehov<\/h2>\n<p>I radl\u00e4get begr\u00e4nsar jag volymen med <strong>binlog_row_image<\/strong> (beroende p\u00e5 version: FULL eller MINIMAL). MINIMAL utel\u00e4mnar of\u00f6r\u00e4ndrade kolumner och sparar betydligt med utrymme utan att \u00e4ventyra replikeringen. Dessutom kalibrerar jag <strong>binlog_cache_size<\/strong> och den maximala cache-storleken, s\u00e5 att stora transaktioner s\u00e4llan beh\u00f6ver avledas till disken. Jag \u00f6vervakar m\u00e4tv\u00e4rden som binlog-cache-hits och -spills f\u00f6r att st\u00e4lla in storleksinst\u00e4llningarna p\u00e5 ett realistiskt s\u00e4tt. Vid stora BLOB-\/TEXT-f\u00e4lt planerar jag buffertar och n\u00e4tverk noggrant och kontrollerar om en satsv\u00e4g l\u00e4mpar sig f\u00f6r massimporter, f\u00f6r att h\u00e5lla binloggen \u00f6versk\u00e5dlig.<\/p>\n\n<h2>\u00d6vervakning, larm och handb\u00f6cker<\/h2>\n<p>F\u00f6r kontinuerlig drift beh\u00f6ver jag tydliga signaler: Jag \u00f6vervakar den aktuella <strong>Binlog-position<\/strong>, <strong>Skrivna byte<\/strong>, antalet \u00f6ppna filer, den \u00e5terst\u00e5ende lokala tiden fram till <strong>Utg\u00e5ngsdatum<\/strong>\u2011tr\u00f6skelv\u00e4rde samt replikeringsnyckeltal s\u00e5som <strong>Sekunder_bakom<\/strong> och Applier-felkoder. N\u00e4r backloggarna p\u00e5 replikerna v\u00e4xer kontrollerar jag f\u00f6rst n\u00e4tverket, sedan I\/O och till sist Applier-tr\u00e5darna. I runbooks dokumenterar jag: hur jag roterar p\u00e5 ett korrekt s\u00e4tt, vad jag kontrollerar f\u00f6re en rensning (SHOW SLAVE\/REPLICA STATUS), hur jag startar om en replik (backup + startposition\/GTID) och hur jag i n\u00f6dfall importerar binloggar exakt fram till \u00f6nskad tidsst\u00e4mpel. Dessa checklistor sparar v\u00e4rdefulla minuter i stressiga situationer.<\/p>\n\n<h2>Lagringslayout, filsystem och drift<\/h2>\n<p>Binloggar konkurrerar om I\/O-resurser med data- och redo-loggar. D\u00e4rf\u00f6r placerar jag dem p\u00e5 en egen volym, m\u00e4ter burst-prestanda och aktiverar skrivbarri\u00e4rer anpassade efter filsystemet. P\u00e5 NVMe skalar genomstr\u00f6mningen bra med st\u00f6rre Group Commit-f\u00f6nster; p\u00e5 n\u00e4tverkslagring begr\u00e4nsar jag parallella fl\u00f6den f\u00f6r att undvika latensspikar. Jag h\u00e5ller filstorleken per binlog moderat s\u00e5 att rensning och \u00f6verf\u00f6ringar inte tar f\u00f6r l\u00e5ng tid, och kontrollerar regelbundet att indexet \u00e4r konsistent. Vid patchning eller uppgradering roterar jag i f\u00f6rv\u00e4g, s\u00e4kerhetskopierar indexet och ser till att \u00f6vervaknings- och s\u00e4kerhetskopieringsagenterna registrerar den nya loggen korrekt.<\/p>\n\n<h2>Kompatibilitet och versionsbyte<\/h2>\n<p>Inte alla versioner anv\u00e4nder exakt samma \u201eordf\u00f6rr\u00e5d\u201c f\u00f6r binlog. Innan jag uppgraderar kontrollerar jag om repliker av \u00e4ldre generation kan l\u00e4sa h\u00e4ndelseupps\u00e4ttningen, eller om replikerna m\u00e5ste uppdateras f\u00f6rst och sedan prim\u00e4rservern. Det finns \u00e4ven skillnader n\u00e4r det g\u00e4ller parameternamn: Beroende p\u00e5 version hittar jag till exempel <strong>binlog_group_commit_sync_delay<\/strong> eller motsvarande v\u00e4ntetidsparametrar (<em>binlog_commit_wait_*<\/em>) samt n\u00e5got avvikande standardv\u00e4rden f\u00f6r kontrollsummor eller radbilder. Jag planerar d\u00e4rf\u00f6r att ta fram en kompatibilitetsmatris och testa failover och PITR med verkliga binloggar fr\u00e5n produktionsmilj\u00f6n. N\u00e4r de InnoDB-baserade binloggarna inf\u00f6rs kommer jag dessutom att kontrollera hur \u00e5terst\u00e4llningsverktyg och s\u00e4kerhetskopior hanterar formatet, och jag har en reservl\u00f6sning redo f\u00f6r \u00f6verg\u00e5ngsperioden.<\/p>\n\n<h2>Felm\u00f6nster fr\u00e5n praktiken och snabba l\u00f6sningar<\/h2>\n<p>Ett vanligt problem \u00e4r f\u00f6r\u00e5ldrade replikeringsfilter som pl\u00f6tsligt utesluter hela tabeller efter schema\u00e4ndringar. D\u00e4rf\u00f6r kontrollerar jag filtren efter varje release. Ett andra m\u00f6nster: replikeringsf\u00f6rdr\u00f6jning p\u00e5 grund av f\u00f6r sm\u00e5 binlog-cacher vid stora transaktioner \u2013 h\u00e4r hj\u00e4lper det att \u00f6ka cache-storlekarna eller dela upp transaktionen. F\u00f6r det tredje: ov\u00e4ntat stora binloggar efter aktivering av triggare; i radl\u00e4ge \u00f6kar jag d\u00e5 ofta effektiviteten med MINIMAL-Row-Image och s\u00e4tter upp dedikerade underh\u00e5llsf\u00f6nster f\u00f6r mass\u00e4ndringar. Och n\u00e4r bekr\u00e4ftelserna varierar j\u00e4mf\u00f6r jag synkroniseringspolicyn (sync_binlog, innodb_flush_log_at_trx_commit) med den faktiska t\u00f6mningsfrekvensen under drift.<\/p>\n\n<h2>Kortfattat sammanfattat<\/h2>\n\n<p>Binloggar strukturerar \u00e4ndringar, m\u00f6jligg\u00f6r replikering och s\u00e4kerst\u00e4ller \u00e5terst\u00e4llbarheten; dessa <strong>Funktion<\/strong> g\u00f6r dem till den centrala styrmekanismen i MariaDB. Jag v\u00e4ljer format utifr\u00e5n arbetsbelastningen, h\u00e5ller koll p\u00e5 Group Commit och justerar flush-strategierna med omd\u00f6me. F\u00f6r \u00e5terst\u00e4llning kombinerar jag fullst\u00e4ndig s\u00e4kerhetskopiering och binloggar och ser till att lagringen \u00e4r fullst\u00e4ndig. Jag planerar replikeringen tydligt, \u00f6vervakar f\u00f6rdr\u00f6jningen och justerar filtren innan pressade situationer uppst\u00e5r. Den som har f\u00f6rst\u00e5tt uppbyggnad, anv\u00e4ndning och prestandahandtag kan driva MariaDB p\u00e5 ett mer tillf\u00f6rlitligt s\u00e4tt och med en tydligare bild av riskerna.<\/p>","protected":false},"excerpt":{"rendered":"<p>MariaDB:s bin\u00e4rloggar f\u00f6rklarade: Uppbyggnad, anv\u00e4ndning, replikering och prestanda sammanfattade p\u00e5 ett l\u00e4ttf\u00f6rst\u00e5eligt s\u00e4tt.<\/p>","protected":false},"author":1,"featured_media":21292,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-21299","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-datenbanken-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"30","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"MariaDB Binary Logs","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"21292","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts\/21299","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/comments?post=21299"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts\/21299\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media\/21292"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media?parent=21299"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/categories?post=21299"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/tags?post=21299"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}