{"id":21539,"date":"2026-09-19T08:33:36","date_gmt":"2026-09-19T06:33:36","guid":{"rendered":"https:\/\/webhosting.de\/mariadb-flush-methoden-innodb-fsync-performance-guide-buffer\/"},"modified":"2026-09-19T08:33:36","modified_gmt":"2026-09-19T06:33:36","slug":"mariadb-flush-methoden-innodb-fsync-prestatiegids-buffer","status":"publish","type":"post","link":"https:\/\/webhosting.de\/nl\/mariadb-flush-methoden-innodb-fsync-performance-guide-buffer\/","title":{"rendered":"Vergelijking van MariaDB-flush-methoden: innodb flush optimaal instellen"},"content":{"rendered":"<p>Ik vergelijk de belangrijkste methoden voor <strong>MariaDB Flush<\/strong> en laat zien hoe ik innodb flush zo instel dat de schrijflatentie afneemt en de gegevens veilig blijven. De nadruk ligt op de opties van `innodb_flush_method`, de duurzaamheidsregelaar `innodb_flush_log_at_trx_commit` en zinvolle waarden voor `Dirty Pages` en I\/O-capaciteit op HDD, SSD en NVMe.<\/p>\n\n<h2>Centrale punten<\/h2>\n\n<ul>\n  <li><strong>innodb_flush_method<\/strong> bepaalt hoe InnoDB met de cache van het besturingssysteem omgaat en dubbele caching voorkomt.<\/li>\n  <li><strong>innodb_flush_log_at_trx_commit<\/strong> bepaalt de houdbaarheid ten opzichte van de latentie per commit.<\/li>\n  <li><strong>Vuile pagina's<\/strong> en de I\/O-capaciteit zorgen ervoor dat schrijfsnelheden worden afgevlakt en voorkomen dat er een stortvloed aan flush-verzoeken ontstaat.<\/li>\n  <li><strong>Flush-buren<\/strong> maakt een onderscheid tussen strategie\u00ebn die zijn geoptimaliseerd voor HDD\u2019s en strategie\u00ebn die zijn geoptimaliseerd voor SSD\u2019s\/NVMe.<\/li>\n  <li><strong>Cloud-configuraties<\/strong> vereisen O_DIRECT, een passende IOPS-limiet en een degelijke monitoring.<\/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-flush-0123.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Wat houdt innodb_flush_method concreet in?<\/h2>\n\n<p>Ik kies voor de <strong>Flush-methode<\/strong> afhankelijk van de manier waarop InnoDB samenwerkt met de cache van het besturingssysteem. Met <strong>fsync<\/strong> De gegevens komen eerst in de cache van het besturingssysteem terecht en worden vervolgens via fsync definitief opgeslagen; dit kan leiden tot dubbele caching. Als ik O_DIRECT instel, omzeilt InnoDB grotendeels de paginacache, wat RAM bespaart en op SSD\/NVMe bijna altijd voordelen oplevert. O_DSYNC maakt gebruik van write-through en vermindert buffering, wat in bepaalde combinaties zinvol kan zijn. O_DIRECT_NO_FSYNC bouwt voort op O_DIRECT en past het synchronisatiegedrag aan, wat een sterke optie is op betrouwbare hardware met een eigen beveiligingsmechanisme.<\/p>\n\n<h3>Typische waarden en versies<\/h3>\n\n<p>Vanaf MariaDB 10.6 is <strong>O_DIRECT<\/strong> vaak de standaardinstelling, omdat dit dubbele caching voorkomt. In oudere versies is <strong>fsync<\/strong>, wat voor HDD-configuraties nog acceptabel kan zijn. Vanaf versie 11.0 regelen andere variabelen, zoals `innodb_data_file_buffering` en `innodb_log_file_buffering`, de details van de buffering. In de praktijk blijft innodb_flush_method de belangrijkste instelling die ik als eerste controleer. Daarna schaven we aan de gedetailleerde parameters totdat de latentie daalt en de doorvoer constant blijft.<\/p>\n\n<h2>innodb_flush_log_at_trx_commit doelgericht inzetten<\/h2>\n\n<p>Ik beschouw <strong>Duurzaamheid<\/strong> en latentie worden apart behandeld, omdat innodb_flush_log_at_trx_commit beide bepaalt. De waarde 1 schrijft en voert fsync uit bij elke commit, wat maximale veiligheid biedt, maar trage schijven sterk vertraagt. Waarde 2 schrijft bij een commit naar de OS-cache en voert ongeveer \u00e9\u00e9n keer per seconde een fsync uit; dit verlaagt de latentie, maar brengt bij een stroomstoring het risico op maximaal \u00e9\u00e9n seconde gegevensverlies met zich mee. Waarde 0 verplaatst logschrijfbewerkingen volledig naar een frequentie van \u00e9\u00e9n keer per seconde en levert de hoogste schrijfprestaties met het grootste risico. Wie daarnaast let op de binlog-strategie, stemt commit-latenties slim af op de replicatie-eisen; details over de wisselwerking leg ik hier uit: <a href=\"https:\/\/webhosting.de\/nl\/mariadb-binaire-logbestanden-prestaties-logica\/\">Binaire logbestanden<\/a>.<\/p>\n\n<h2>Page-flushing en dirty pages beheren<\/h2>\n\n<p>Ik schat het aandeel van de <strong>Vuile pagina's<\/strong> zodat de schrijfsnelheden constant blijven. Daarom stel ik innodb_max_dirty_pages_pct op een gematigde waarde in, zodat er geen plotselinge flush-pieken ontstaan. De waarden innodb_io_capacity en innodb_io_capacity_max stem ik af op de werkelijke IOPS van de opslag: laag voor HDD, hoger voor SSD\/NVMe. Een goed geconfigureerde page-cleaner-thread schrijft vanuit LRU-perspectief tijdig terug, voordat pagina\u2019s worden verdrongen. Meer informatie over het fijnafstemmen van threads en zinvolle statistieken beschrijf ik hier: <a href=\"https:\/\/webhosting.de\/nl\/mariadb-paginareiniger-threads-database\/\">Page-Cleaner-threads<\/a>.<\/p>\n\n<h2>Flush-Neighbors: HDD versus SSD\/NVMe<\/h2>\n\n<p>Met <strong>innodb_flush_neighbors<\/strong> Ik gebruik HDD-vriendelijke schrijfpatronen of schakel deze uit. Op HDD\u2019s zorgt het gelijktijdig schrijven van aangrenzende pagina\u2019s voor meer effici\u00ebntie, omdat de kop minder vaak hoeft te springen. Op SSD\/NVMe is de locatie op het medium nauwelijks relevant; daar veroorzaakt het gelijktijdig schrijven onnodige schrijfbewerkingen. Voor HDD stel ik meestal de waarde 1 in, voor SSD\/NVMe de waarde 0. Zo verminder ik overbodige schrijfbewerkingen en verleng ik de levensduur van snelle schijven.<\/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_flush_vergleich_7643.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>De kosten van fsync begrijpen en beperken<\/h2>\n\n<p>Ik meet de <strong>fsync<\/strong>-Latentie, omdat elke milliseconde commits vertraagt. Werkbelastingen met veel schrijfbewerkingen besteden anders een groot deel van de tijd aan het wachten op bevestiging van de opslagmedia. Met `innodb_flush_log_at_trx_commit=2` of `0` verminder ik het aantal kostbare synchronisaties aanzienlijk. O_DIRECT of O_DIRECT_NO_FSYNC helpt om dubbele caching te voorkomen en I\/O-paden te vereenvoudigen. Op trage hardware boek ik vaak merkbare winst als ik de synchronisatiefrequentie, de flush-methode en het aandeel \u2018dirty pages\u2019 gezamenlijk bekijk.<\/p>\n\n<h2>Aanbevolen startwaarden per opslagmedium<\/h2>\n\n<p>Ik begin met zinvolle <strong>Basislijn<\/strong>-waarden en pas deze vervolgens aan op basis van meetwaarden. De tabel geeft richtlijnen voor typische configuraties en workloads. Doorslaggevend zijn de werkelijke IOPS, latenties en het aandeel schrijvende transacties. Na de eerste run controleer ik het percentage \u2018dirty pages\u2019, de commit-latentie en het aantal fsync-aanroepen. Vervolgens verfijn ik de instellingen stapsgewijs totdat het profiel stabiel en constant blijft.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Medium<\/th>\n      <th>innodb_flush_method<\/th>\n      <th>innodb_flush_log_at_trx_commit<\/th>\n      <th>innodb_io_capacity<\/th>\n      <th>innodb_flush_neighbors<\/th>\n      <th>Opmerkingen<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>HDD<\/td>\n      <td>fsync of O_DIRECT<\/td>\n      <td>1 (kritisch) \/ 2 (balans)<\/td>\n      <td>200\u2013400<\/td>\n      <td>1<\/td>\n      <td>Meer latentie per <strong>Commit<\/strong>, continu doorspoelen is belangrijk<\/td>\n    <\/tr>\n    <tr>\n      <td>SSD<\/td>\n      <td>O_DIRECT<\/td>\n      <td>1 (kritisch) \/ 2 (balans)<\/td>\n      <td>1000\u20132000<\/td>\n      <td>0<\/td>\n      <td>Dubbele caching vermijden, het aantal \u2018dirty pages\u2019 binnen de perken houden<\/td>\n    <\/tr>\n    <tr>\n      <td>NVMe<\/td>\n      <td>O_DIRECT of O_DIRECT_NO_FSYNC<\/td>\n      <td>1 (kritiek) \/ 2 (balans) \/ 0 (speciaal geval)<\/td>\n      <td>2000\u20138000+<\/td>\n      <td>0<\/td>\n      <td>Zeer laag <strong>Latency<\/strong>, Kies de synchronisatiefrequentie zorgvuldig<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Ik houd daarbij rekening met de InnoDB <strong>Doublewrite-buffer<\/strong>, die gegevensbeschadiging bij crashes vermindert, maar extra schrijfbewerkingen veroorzaakt; ik vat de achtergronden en afstemmingsopties hier kort samen: <a href=\"https:\/\/webhosting.de\/nl\/innodb-doublewrite-buffer-beveiliging-prestatieoptimalisatie-focus\/\">Doublewrite-buffer<\/a>. In omgevingen waar veel wordt geschreven, voer ik metingen uit met en zonder doublewrite-effecten voordat ik beslissingen neem. Bij kritieke systemen heeft integriteit voorrang boven een maximale schrijfsnelheid. Test- of analyseomgevingen mogen wat agressiever zijn. Ik onderbouw mijn beslissingen altijd met herhaalbare benchmarks.<\/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-flush-methoden-vergleich-5876.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Cloud- en containeromgevingen<\/h2>\n\n<p>Ik vermijd dubbele <strong>Pagina cache<\/strong>, omdat het RAM daar schaars is; O_DIRECT is daarom vaak een goede keuze. Ik stem de innodb_io_capacity af op de IOPS-limieten van het volume, zodat ik geen beperkingen activeer. De bufferpool moet binnen de Cgroup-limiet blijven, anders dreigen OOM-kills. Persistente volumes zijn verplicht, omdat tijdelijke opslag geen duurzaamheid biedt. In zeer elastische opstellingen beperk ik te veel gelijktijdige verbindingen en maak ik weloverwogen gebruik van de threadpool.<\/p>\n\n<h2>Instellingen voor back-up en flushing<\/h2>\n\n<p>Ik controleer of back-uptools hun eigen <strong>Doorspoelen<\/strong>-Gebruik de instellingen. mariadb-backup kan innodb_flush_method anders instellen om een consistent beeld te krijgen. Als de back-up- en serverparameters niet op elkaar zijn afgestemd, ontstaan er onnodige I\/O-pieken. Tijdens geplande back-ups regel ik de I\/O-capaciteit zorgvuldig, zodat lees- en schrijfpaden schoon blijven. Na afloop controleer ik de latenties en het percentage \u2018dirty pages\u2019 om neveneffecten uit te sluiten.<\/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-flush-optimal-3435.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Stapsgewijze tuning in de praktijk<\/h2>\n\n<p>Ik begin met een <strong>Inventaris<\/strong>: Opslagtype, werkelijke IOPS, latentie en doorvoersnelheid. Vervolgens stel ik de grootte van de bufferpool in, afgestemd op het beschikbare RAM of de Cgroup-limiet. Daarna kies ik de flush-methode (HDD: fsync\/O_DIRECT; SSD\/NVMe: O_DIRECT of O_DIRECT_NO_FSYNC). Voor de betrouwbaarheid stel ik innodb_flush_log_at_trx_commit in op 1 voor kritieke gegevens of op 2 als een verlies van \u00e9\u00e9n seconde acceptabel is. Tot slot stel ik innodb_io_capacity en innodb_max_dirty_pages_pct zo in dat het flushen soepel en continu verloopt, en controleer ik de statistieken regelmatig.<\/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-flush-vergleich-8243.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>De grootte van het redo-log en de checkpoints correct afstemmen<\/h2>\n\n<p>Ik voorkom flush-pieken door de <strong>Redo-logs<\/strong> de juiste grootte kiezen. Te kleine logbestanden dwingen InnoDB tot frequente checkpoints; dit leidt tot backpressure en schommelingen in de latentie. Met grotere logbestanden zorg ik voor een gelijkmatiger verloop van de checkpoints, omdat er meer wijzigingsgegevens kunnen worden gebufferd voordat ze naar de gegevensbestanden moeten worden geschreven. Daarbij houd ik rekening met twee beperkingen: ten eerste de beschikbare I\/O-capaciteit (een grote buffer biedt geen bescherming tegen te trage schijven), ten tweede de crash-recovery-tijd, die toeneemt bij zeer grote redo-logs. Bij schrijfintensieve workloads stel ik de loggrootte zo in dat typische piekbelastingen binnen het logbudget worden opgevangen, zonder dat de hersteltijd onredelijk toeneemt.<\/p>\n\n<p>Ter fine-tuning houd ik de statistieken bij met betrekking tot de \u201echeckpoint age\u201c en de verhouding tussen de log-write-rate en de flush-rate van de gegevenspagina\u2019s. Als de checkpoints herhaaldelijk de bovengrens bereiken, schaal ik ofwel de loggrootte op of verhoog ik voorzichtig de I\/O-capaciteit voor de page-cleaner. Het doel is een soepele, continue voortgang van de checkpoints zonder gedwongen acties.<\/p>\n\n<h2>Adaptieve spoeling en drempelwaarden<\/h2>\n\n<p>De adaptieve mechanismen van InnoDB helpen bij het flushen van de huidige <strong>Schrijfsnelheid<\/strong> aan te passen. Ik let erop dat de LWM-drempel (Low Watermark) voor Dirty Pages niet te laag is, zodat de Page-Cleaner niet voortdurend \u201eop het randje\u201c werkt. Tegelijkertijd vermijd ik maximumwaarden die tot te agressieve bulk-flushes leiden. In de praktijk controleer ik of de verhouding tussen \u201enieuwe dirty pages per seconde\u201c en \u201eflush-IOPS\u201c op de lange termijn stabiel blijft. Als de bufferpool constant boven de doelwaarde vervuilt, verhoog ik innodb_io_capacity stapsgewijs of verlaag ik de doelwaarden voor dirty pages.<\/p>\n\n<p>Op NVMe-configuraties kan ik de Page-Cleaner meer speelruimte geven, omdat de apparaten ook onder belasting korte latenties behouden. Op HDD\u2019s werk ik met conservatievere drempelwaarden en beperk ik sterke schommelingen om door zoekbewegingen veroorzaakte latentiepieken te voorkomen. De interactie met <strong>innodb_flush_neighbors<\/strong> Ik maak hier doelgericht gebruik van: HDD profiteert van de fysieke nabijheid, flash niet.<\/p>\n\n<h2>Binlog en Group-Commit in combinatie<\/h2>\n\n<p>Wie replicatie toepast, houdt daar rekening mee <strong>Commit-logboek<\/strong> over Redo-Log en Binary Log. Ik stel de flush-frequenties zo in dat Group-Commit van kracht is: veel kleine transacties moeten gezamenlijk worden geflushed, in plaats van elke commit afzonderlijk te synchroniseren. Hierbij past innodb_flush_log_at_trx_commit=1 voor maximale duurzaamheid of 2 voor lagere latentie. Tegelijkertijd stel ik het binlog-synchronisatiemechanisme zo in dat het past bij het doelsysteem. Een lage synchronisatiefrequentie verlaagt de kosten per commit, maar kan bij crashes leiden tot meer verlies van binlog-gegevens. In omgevingen met een hoge schrijfsnelheid en een aanvaardbare vertraging tussen master en replica accepteer ik een gematigde ontkoppeling van de binlog-synchronisaties om de latentie te verlagen. De overkoepelende logica en afwegingen behandel ik in het artikel over <a href=\"https:\/\/webhosting.de\/nl\/mariadb-binaire-logbestanden-prestaties-logica\/\">Binaire logbestanden<\/a> en pas ze vervolgens aan het specifieke flush-profiel aan.<\/p>\n\n<h2>Bestandssysteem, schrijfcache en beveiliging tegen stroomuitval<\/h2>\n\n<p>Ik beoordeel de <strong>Eigenschappen van het geheugen en de controller<\/strong> v\u00f3\u00f3r het tunen. Apparaten met <em>Bescherming tegen stroomuitval<\/em> (PLP) kunnen veilig gebruikmaken van schrijfcaches; zonder PLP bestaat het risico dat schrijfbewerkingen die als bevestigd zijn gemeld, bij een stroomstoring verloren gaan. In dergelijke gevallen ben ik wat voorzichtiger: fsync-paden blijven verplicht, en ik gebruik O_DIRECT_NO_FSYNC alleen op hardware met betrouwbare beveiliging. Op Linux-bestandssystemen zoals ext4 of XFS worden de beveiligingen standaard als actief beschouwd; ik schakel ze niet lichtvaardig uit, maar stem de afstemming af op de bestaande garanties. Op ZFS houd ik bovendien rekening met het eigen intent-log en de caching-strategie\u00ebn; afhankelijk van de opstelling loont het de moeite om een afzonderlijk afgestemde strategie te hanteren, die ook double-caching minimaliseert.<\/p>\n\n<p>Voor consistente prestaties controleer ik bovendien de uitlijning (bijv. 4K-pagina\u2019s bij SSD\u2019s) en de afstemming van de wachtrijdiepte. Korte, deterministische latenties zijn voor commit-paden vaak belangrijker dan maximale IOPS in synthetische benchmarks. Daarom test ik met realistische blokken en concurrentieniveaus in plaats van alleen met piekworkloads.<\/p>\n\n<h2>Meetmethodiek: statistieken, status en diagnose<\/h2>\n\n<p>Ik regel de afstelling via <strong>harde meetwaarden<\/strong> in plaats van gevoel. Tot mijn standaardindicatoren behoren:<\/p>\n<ul>\n  <li>Commit-latentie (p50\/p95\/p99) tijdens piekbelasting<\/li>\n  <li>fsync-latentie en -snelheid voor log- en gegevensbestanden<\/li>\n  <li>Het aandeel van \u2018dirty pages\u2019 in de loop van de tijd en de variatie daarin<\/li>\n  <li>Voortgang van de checkpoint en verhouding tussen log-schrijfsnelheid en flush-snelheid<\/li>\n  <li>Page-Cleaner-achterstand (zijn er voortdurend openstaande flushes?)<\/li>\n<\/ul>\n<p>Ik gebruik hiervoor de statusuitvoer van InnoDB en breng deze in verband met OS-statistieken (iostat, vmstat). Ik let met name op de schijflatentie in milliseconden, de verdeling tussen lees- en schrijfbewerkingen en het aandeel synchrone bewerkingen. Om reproduceerbare tests te garanderen, varieer ik doelgericht slechts \u00e9\u00e9n parameter per stap en registreer ik het resultaat over langere intervallen, zodat uitschieters geen doorslaggevende rol spelen.<\/p>\n\n<h2>Veelvoorkomende anti-patronen en tegenmaatregelen<\/h2>\n\n<ul>\n  <li>Te kleine redo-logs: dit leidt tot frequente checkpoints. Oplossing: vergroot de loggrootte en pas de I\/O-capaciteit voor het flushing aan.<\/li>\n  <li>Het percentage \u2018dirty pages\u2019 is blijvend te hoog: de Page Cleaner raakt overbelast en er dreigen \u2018flush-stormen\u2019. Oplossing: verlaag innodb_max_dirty_pages_pct en verhoog io_capacity.<\/li>\n  <li>O_DIRECT zonder monitoring: voorkomt weliswaar dubbele caching, maar kan bij een verkeerde I\/O-capaciteit tot pieken leiden. Oplossing: nauwgezette monitoring en het afstemmen van de capaciteitswaarden op de werkelijke IOPS.<\/li>\n  <li>Ongeschikte Flush-Neighbors op SSD\/NVMe: dit zorgt voor extra werk zonder dat het iets oplevert. Oplossing: stel innodb_flush_neighbors=0 in.<\/li>\n  <li>Commit-synchronisaties op trage opslagmedia: elke transactie brengt de fsync-kosten met zich mee. Oplossing: Group-Commit bevorderen, eventueel innodb_flush_log_at_trx_commit=2 (na afweging van de risico\u2019s).<\/li>\n  <li>Container zonder RAM-buffer: bufferpool te groot, dreigende OOM. Oplossing: pas de bufferpool strikt aan de Cgroup-limieten aan en houd de druk in de gaten.<\/li>\n<\/ul>\n\n<h2>Rekening houden met shutdown- en herstelprocessen<\/h2>\n\n<p>Ik ben van plan om te bekijken hoe instellingen van invloed zijn op <strong>Uitschakeling<\/strong> en <strong>Herstel na een crash<\/strong> gevolgen hebben. Een snelle, nette afsluiting verkort de hersteltijden, omdat er minder redo\u2019s hoeven te worden toegepast. Zeer grote redo-logs bevorderen rustige checkpoints, maar verlengen het inhaalproces in geval van een fout. Voor productieve systemen zoek ik een evenwicht waarbij ik enerzijds geen flush-pieken in de dagelijkse gang van zaken veroorzaak en anderzijds in het ergste geval geen buitensporig lang herstel hoef te accepteren. Daarbij houd ik vanaf het begin rekening met onderhoudsvensters en back-ups.<\/p>\n\n<h2>Praktische tips voor typische workloads<\/h2>\n\n<ul>\n  <li>OLTP met veel kleine commits op SSD\/NVMe: O_DIRECT, innodb_flush_log_at_trx_commit=1 of 2, afhankelijk van de duurzaamheid, innodb_io_capacity bij voorkeur hoog, Dirty-Pages matig, Flush-Neighbors=0. Maak actief gebruik van Binlog-Group-Commit.<\/li>\n  <li>Batch-import met veel schrijfbewerkingen: verhoog tijdelijk de doelwaarde voor \u2018dirty pages\u2019 enigszins, vergroot de I\/O-capaciteit en zet deze na voltooiing weer terug. Stel, indien de houdbaarheid acceptabel is, tijdelijk innodb_flush_log_at_trx_commit=2 in.<\/li>\n  <li>Op HDD gebaseerde legacy-systemen: conservatieve I\/O-capaciteit, Flush-Neighbors=1, innodb_flush_method=fsync of O_DIRECT, afhankelijk van de druk op het RAM-geheugen. Besteed bijzondere aandacht aan continu flushing om zoekstormen te voorkomen.<\/li>\n  <li>Cloud-volumes met IOPS-budget: innodb_io_capacity strikt koppelen aan de gegarandeerde limiet, pieken vermijden, O_DIRECT gebruiken om RAM te besparen. Bij creditsystemen (burst-I\/O) werk ik met pacing, zodat het budget niet in \u00e9\u00e9n keer wordt opgebruikt.<\/li>\n<\/ul>\n\n<h2>Controlelijst voor probleemoplossing<\/h2>\n\n<ul>\n  <li>Lange p95-commit-vertragingen? Controleer de fsync-duur, schakel Group Commit in en verlaag indien nodig de flush-frequentie (na afweging van de risico\u2019s).<\/li>\n  <li>Grote variatie in het percentage \u2018dirty pages\u2019? Stel io_capacity\/io_capacity_max nauwkeurig af en controleer de drempelwaarden voor adaptief flushing.<\/li>\n  <li>Plotselinge pieken in de latentie bij back-ups? Synchroniseer de parameters van de back-uptool en de serverwaarden, en pas de I\/O-beperking tijdelijk aan.<\/li>\n  <li>Loopt Replica achter? Beoordeel de Binlog-flush-strategie, synchronisatiefrequenties en netwerklatentie gezamenlijk; te agressieve synchronisaties remmen de master af.<\/li>\n  <li>RAM-belasting na overstap naar O_DIRECT? De balans tussen de bufferpool en de OS-cache opnieuw afstemmen; O_DIRECT vermindert de OS-cache, maar kan van invloed zijn op de paginacache van de applicatie.<\/li>\n<\/ul>\n\n<h2>Korte samenvatting<\/h2>\n\n<p>Ik organiseer de <strong>Flush-strategie<\/strong> altijd afhankelijk van de hardware en de doelstellingen op het gebied van duurzaamheid. O_DIRECT voorkomt dubbele caching en levert op SSD\/NVMe doorgaans de beste resultaten op. De instelling `innodb_flush_log_at_trx_commit` bepaalt de snelheid per commit en het risico bij een stroomstoring. Zorgvuldig gekozen waarden voor Dirty Pages, I\/O-capaciteit en Flush-Neighbors zorgen voor gelijkmatige schrijfsnelheden. Wie bovendien de fsync-kosten meet en zich aan cloudlimieten houdt, zorgt ervoor dat MariaDB betrouwbaar op snelheid draait, zonder in te boeten aan veiligheid.<\/p>","protected":false},"excerpt":{"rendered":"<p>Leer hoe je MariaDB-flush-methoden en innodb flush optimaal configureert met O_DIRECT, fsync en innodb_flush_log_at_trx_commit. Deze handleiding laat je zien hoe je op een praktische manier database-tuning kunt toepassen voor HDD-, SSD- en cloudomgevingen, met de nadruk op prestaties en gegevensbeveiliging.<\/p>","protected":false},"author":1,"featured_media":21532,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-21539","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":"66","_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 Flush","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":"21532","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/21539","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/comments?post=21539"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/21539\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media\/21532"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media?parent=21539"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/categories?post=21539"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/tags?post=21539"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}