{"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-metody-flush-innodb-fsync-przewodnik-po-wydajnosci-bufor","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pl\/mariadb-flush-methoden-innodb-fsync-performance-guide-buffer\/","title":{"rendered":"Por\u00f3wnanie metod flush w MariaDB: optymalne skonfigurowanie innodb flush"},"content":{"rendered":"<p>Por\u00f3wnuj\u0119 najwa\u017cniejsze metody dotycz\u0105ce <strong>MariaDB \u2013 operacja flush<\/strong> i poka\u017c\u0119, jak skonfigurowa\u0107 opcj\u0119 `innodb_flush`, aby zmniejszy\u0107 op\u00f3\u017anienie zapisu i zapewni\u0107 bezpiecze\u0144stwo danych. Skupimy si\u0119 na opcjach `innodb_flush_method`, parametrze trwa\u0142o\u015bci `innodb_flush_log_at_trx_commit`, a tak\u017ce na rozs\u0105dnych warto\u015bciach dla `Dirty Pages` oraz przepustowo\u015bci wej\u015bcia\/wyj\u015bcia na dyskach HDD, SSD i NVMe.<\/p>\n\n<h2>Punkty centralne<\/h2>\n\n<ul>\n  <li><strong>innodb_flush_method<\/strong> okre\u015bla, w jaki spos\u00f3b InnoDB wsp\u00f3\u0142pracuje z pami\u0119ci\u0105 podr\u0119czn\u0105 systemu operacyjnego i zapobiega podw\u00f3jnemu buforowaniu.<\/li>\n  <li><strong>innodb_flush_log_at_trx_commit<\/strong> okre\u015bla stosunek trwa\u0142o\u015bci do op\u00f3\u017anienia na jedno zatwierdzenie.<\/li>\n  <li><strong>Brudne strony<\/strong> a przepustowo\u015b\u0107 wej\u015bcia\/wyj\u015bcia wyr\u00f3wnuje szybko\u015b\u0107 zapisu i zapobiega nadmiernym obci\u0105\u017ceniom zwi\u0105zanym z operacjami flush.<\/li>\n  <li><strong>S\u0105siedzi typu flush<\/strong> rozr\u00f3\u017cnia strategie zoptymalizowane pod k\u0105tem dysk\u00f3w HDD od strategii zoptymalizowanych pod k\u0105tem dysk\u00f3w SSD\/NVMe.<\/li>\n  <li><strong>Konfiguracje w chmurze<\/strong> wymagaj\u0105 O_DIRECT, odpowiedniego limitu IOPS oraz sprawnego monitorowania.<\/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>Co konkretnie oznacza innodb_flush_method?<\/h2>\n\n<p>Wybieram <strong>Metoda Flush<\/strong> zale\u017cy od tego, w jaki spos\u00f3b InnoDB wsp\u00f3\u0142pracuje z pami\u0119ci\u0105 podr\u0119czn\u0105 systemu operacyjnego. Z <strong>fsync<\/strong> Dane trafiaj\u0105 najpierw do pami\u0119ci podr\u0119cznej systemu operacyjnego, a nast\u0119pnie s\u0105 trwale zapisywane za pomoc\u0105 fsync; mo\u017ce to prowadzi\u0107 do podw\u00f3jnego buforowania. Je\u015bli ustawi\u0119 O_DIRECT, InnoDB w znacznym stopniu omija pami\u0119\u0107 podr\u0119czn\u0105 stron, co oszcz\u0119dza pami\u0119\u0107 RAM i prawie zawsze przynosi korzy\u015bci w przypadku dysk\u00f3w SSD\/NVMe. O_DSYNC wykorzystuje tryb Write-Through i ogranicza buforowanie, co w okre\u015blonych konfiguracjach mo\u017ce by\u0107 przydatne. O_DIRECT_NO_FSYNC opiera si\u0119 na O_DIRECT i dostosowuje zachowanie synchronizacji, co stanowi doskona\u0142\u0105 opcj\u0119 w przypadku niezawodnego sprz\u0119tu wyposa\u017conego we w\u0142asny mechanizm zabezpieczaj\u0105cy.<\/p>\n\n<h3>Typowe warto\u015bci i wersje<\/h3>\n\n<p>Pocz\u0105wszy od wersji MariaDB 10.6 <strong>O_DIRECT<\/strong> cz\u0119sto jest to ustawienie domy\u015blne, poniewa\u017c pozwala unikn\u0105\u0107 podw\u00f3jnego buforowania. W starszych wersjach dominuje <strong>fsync<\/strong>, co w przypadku konfiguracji z dyskami HDD mo\u017ce by\u0107 jeszcze do przyj\u0119cia. Od wersji 11.0 dalsze zmienne, takie jak innodb_data_file_buffering i innodb_log_file_buffering, reguluj\u0105 szczeg\u00f3\u0142y buforowania. W praktyce innodb_flush_method pozostaje kluczowym parametrem, kt\u00f3ry sprawdzam w pierwszej kolejno\u015bci. Nast\u0119pnie dopracowuj\u0119 parametry szczeg\u00f3\u0142owe, a\u017c op\u00f3\u017anienia spadn\u0105, a przepustowo\u015b\u0107 pozostanie sta\u0142a.<\/p>\n\n<h2>Celowe wykorzystanie opcji `innodb_flush_log_at_trx_commit`<\/h2>\n\n<p>Rozwa\u017cam <strong>Trwa\u0142o\u015b\u0107<\/strong> oraz op\u00f3\u017anienie, poniewa\u017c parametr innodb_flush_log_at_trx_commit okre\u015bla obie te warto\u015bci. Warto\u015b\u0107 1 powoduje zapis i wykonanie fsync przy ka\u017cdym zatwierdzeniu (commit), co zapewnia maksymalne bezpiecze\u0144stwo, ale znacznie spowalnia dzia\u0142anie wolnych dysk\u00f3w. Warto\u015b\u0107 2 zapisuje dane w pami\u0119ci podr\u0119cznej systemu operacyjnego przy zatwierdzeniu transakcji i wykonuje fsync mniej wi\u0119cej raz na sekund\u0119; zmniejsza to op\u00f3\u017anienie, ale w przypadku awarii zasilania grozi utrat\u0105 danych trwaj\u0105c\u0105 do jednej sekundy. Warto\u015b\u0107 0 ca\u0142kowicie przesuwa operacje zapisu dziennika do cyklu sekundowego i zapewnia najwy\u017csz\u0105 wydajno\u015b\u0107 zapisu przy najwi\u0119kszym ryzyku. Kto dodatkowo zwraca uwag\u0119 na strategi\u0119 binlog, m\u0105drze dostosowuje op\u00f3\u017anienia zatwierdzania do wymaga\u0144 replikacji; szczeg\u00f3\u0142y dotycz\u0105ce tej interakcji wyja\u015bniam tutaj: <a href=\"https:\/\/webhosting.de\/pl\/logi-binarne-mariadb-logika-dzialania\/\">Dzienniki binarne<\/a>.<\/p>\n\n<h2>Zarz\u0105dzanie opr\u00f3\u017cnianiem stron i stronami brudnymi<\/h2>\n\n<p>Uwa\u017cam, \u017ce odsetek <strong>Brudne strony<\/strong> tak, aby szybko\u015b\u0107 zapisu pozostawa\u0142a sta\u0142a. W tym celu ustawiam umiarkowan\u0105 warto\u015b\u0107 parametru innodb_max_dirty_pages_pct, aby unikn\u0105\u0107 nag\u0142ych szczyt\u00f3w operacji flush. Warto\u015bci innodb_io_capacity i innodb_io_capacity_max dostosowuj\u0119 do rzeczywistej liczby operacji IOPS pami\u0119ci: niskie dla dysk\u00f3w HDD, wy\u017csze dla dysk\u00f3w SSD\/NVMe. Dobrze skonfigurowany w\u0105tek czyszcz\u0105cy strony zapisuje dane z punktu widzenia algorytmu LRU w odpowiednim czasie, zanim strony zostan\u0105 wypchni\u0119te. Wi\u0119cej informacji na temat precyzyjnej regulacji w\u0105tk\u00f3w oraz przydatnych wska\u017anik\u00f3w opisuj\u0119 tutaj: <a href=\"https:\/\/webhosting.de\/pl\/mariadb-czyszczenie-stron-watki-baza-danych\/\">W\u0105tki dotycz\u0105ce narz\u0119dzia Page Cleaner<\/a>.<\/p>\n\n<h2>S\u0105siednie sektory: HDD a SSD\/NVMe<\/h2>\n\n<p>Z <strong>innodb_flush_neighbors<\/strong> Stosuj\u0119 wzorce zapisu przyjazne dla dysk\u00f3w HDD lub je wy\u0142\u0105czam. W przypadku dysk\u00f3w HDD zapis s\u0105siednich stron zwi\u0119ksza wydajno\u015b\u0107, poniewa\u017c g\u0142owica musi mniej cz\u0119sto si\u0119 przemieszcza\u0107. W przypadku dysk\u00f3w SSD\/NVMe po\u0142o\u017cenie na no\u015bniku nie ma praktycznie \u017cadnego znaczenia, a zapis r\u00f3wnoleg\u0142y generuje tam niepotrzebne operacje zapisu. Dla dysk\u00f3w HDD zazwyczaj ustawiam warto\u015b\u0107 1, a dla dysk\u00f3w SSD\/NVMe \u2013 0. W ten spos\u00f3b ograniczam zb\u0119dne operacje zapisu i przed\u0142u\u017cam \u017cywotno\u015b\u0107 szybszych dysk\u00f3w.<\/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>Zrozumienie i ograniczenie koszt\u00f3w fsync<\/h2>\n\n<p>Mierz\u0119 <strong>fsync<\/strong>-Op\u00f3\u017anienia, poniewa\u017c ka\u017cda milisekunda spowalnia operacje zatwierdzania. W przeciwnym razie obci\u0105\u017cenia wymagaj\u0105ce intensywnego zapisu sp\u0119dzaj\u0105 znaczn\u0105 cz\u0119\u015b\u0107 czasu na oczekiwaniu na potwierdzenie z no\u015bnika danych. Ustawiaj\u0105c innodb_flush_log_at_trx_commit=2 lub 0, znacznie zmniejszam liczb\u0119 kosztownych synchronizacji. O_DIRECT lub O_DIRECT_NO_FSYNC pomaga unikn\u0105\u0107 podw\u00f3jnego buforowania i upro\u015bci\u0107 \u015bcie\u017cki wej\u015bcia\/wyj\u015bcia. Na wolnym sprz\u0119cie cz\u0119sto odczuwam wymiern\u0105 popraw\u0119, gdy wsp\u00f3lnie analizuj\u0119 cz\u0119stotliwo\u015b\u0107 synchronizacji, metod\u0119 opr\u00f3\u017cniania bufora oraz wska\u017anik brudnych stron.<\/p>\n\n<h2>Zalecane warto\u015bci pocz\u0105tkowe w zale\u017cno\u015bci od no\u015bnika danych<\/h2>\n\n<p>Zaczn\u0119 od sensownych <strong>Linia bazowa<\/strong>-Warto\u015bci, a nast\u0119pnie dostosowuj\u0119 je na podstawie wynik\u00f3w pomiar\u00f3w. Tabela zawiera wskaz\u00f3wki dotycz\u0105ce typowych konfiguracji i obci\u0105\u017ce\u0144. Decyduj\u0105ce znaczenie maj\u0105 rzeczywiste warto\u015bci IOPS, op\u00f3\u017anienia oraz odsetek transakcji zapisu. Po pierwszym przebiegu sprawdzam wska\u017anik brudnych stron, op\u00f3\u017anienie zatwierdzania oraz liczb\u0119 wywo\u0142a\u0144 fsync. Nast\u0119pnie stopniowo dopracowuj\u0119 ustawienia, a\u017c profil b\u0119dzie czysty i stabilny.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>\u015aredni<\/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>Uwagi<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>HDD<\/td>\n      <td>fsync lub O_DIRECT<\/td>\n      <td>1 (krytyczny) \/ 2 (r\u00f3wnowaga)<\/td>\n      <td>200\u2013400<\/td>\n      <td>1<\/td>\n      <td>Wi\u0119ksze op\u00f3\u017anienie na <strong>Zobowi\u0105zanie<\/strong>, wa\u017cne jest ci\u0105g\u0142e przep\u0142ukiwanie<\/td>\n    <\/tr>\n    <tr>\n      <td>SSD<\/td>\n      <td>O_DIRECT<\/td>\n      <td>1 (krytyczny) \/ 2 (r\u00f3wnowaga)<\/td>\n      <td>1000\u20132000<\/td>\n      <td>0<\/td>\n      <td>Unika\u0107 podw\u00f3jnego buforowania, utrzymywa\u0107 umiarkowan\u0105 liczb\u0119 stron \u201ebrudnych\u201d<\/td>\n    <\/tr>\n    <tr>\n      <td>NVMe<\/td>\n      <td>O_DIRECT lub O_DIRECT_NO_FSYNC<\/td>\n      <td>1 (krytyczny) \/ 2 (r\u00f3wnowaga) \/ 0 (przypadek szczeg\u00f3lny)<\/td>\n      <td>2000\u20138000+<\/td>\n      <td>0<\/td>\n      <td>Bardzo niski <strong>Op\u00f3\u017anienie<\/strong>, Nale\u017cy starannie dobra\u0107 cz\u0119stotliwo\u015b\u0107 synchronizacji<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>W tym kontek\u015bcie zwracam uwag\u0119 na InnoDB <strong>Bufor podw\u00f3jnego zapisu<\/strong>, kt\u00f3ry ogranicza uszkodzenia danych w przypadku awarii, ale generuje dodatkowe operacje zapisu; poni\u017cej zwi\u0119\u017ale podsumowuj\u0119 przyczyny tego zjawiska oraz opcje optymalizacji: <a href=\"https:\/\/webhosting.de\/pl\/innodb-bufor-podwojnego-zapisu-bezpieczenstwo-optymalizacja-wydajnosci-glowny-temat\/\">Bufor podw\u00f3jnego zapisu<\/a>. W \u015brodowiskach, w kt\u00f3rych dominuj\u0105 operacje zapisu, przed podj\u0119ciem decyzji przeprowadzam pomiary zar\u00f3wno z uwzgl\u0119dnieniem efektu podw\u00f3jnego zapisu, jak i bez niego. W systemach krytycznych integralno\u015b\u0107 danych ma pierwsze\u0144stwo przed maksymaln\u0105 szybko\u015bci\u0105 zapisu. Konfiguracje testowe lub analityczne mog\u0105 by\u0107 bardziej agresywne. Swoje decyzje zawsze popieram powtarzalnymi testami por\u00f3wnawczymi.<\/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>\u015arodowiska chmurowe i kontenerowe<\/h2>\n\n<p>Unikam powt\u00f3rze\u0144 <strong>Pami\u0119\u0107 podr\u0119czna strony<\/strong>, poniewa\u017c pami\u0119\u0107 RAM jest tam ograniczona; dlatego O_DIRECT cz\u0119sto sprawdza si\u0119 dobrze. Parametr innodb_io_capacity dostosowuj\u0119 do limit\u00f3w IOPS woluminu, aby nie spowodowa\u0107 ograniczenia przepustowo\u015bci. Pula bufor\u00f3w musi by\u0107 dostosowana do limitu Cgroup, w przeciwnym razie grozi to zabiciem proces\u00f3w z powodu braku pami\u0119ci (OOM). Woluminy trwa\u0142e s\u0105 obowi\u0105zkowe, poniewa\u017c pami\u0119\u0107 efemeryczna nie zapewnia trwa\u0142o\u015bci danych. W bardzo elastycznych konfiguracjach ograniczam zbyt du\u017c\u0105 liczb\u0119 jednoczesnych po\u0142\u0105cze\u0144 i rozwa\u017cnie wykorzystuj\u0119 pul\u0119 w\u0105tk\u00f3w.<\/p>\n\n<h2>Ustawienia tworzenia kopii zapasowych i czyszczenia pami\u0119ci<\/h2>\n\n<p>Sprawdzam, czy narz\u0119dzia do tworzenia kopii zapasowych posiadaj\u0105 w\u0142asne <strong>Sp\u0142ukiwanie<\/strong>-Skorzystaj z ustawie\u0144. Narz\u0119dzie `mariadb-backup` mo\u017ce ustawi\u0107 parametr `innodb_flush_method` na inn\u0105 warto\u015b\u0107, aby zapewni\u0107 sp\u00f3jno\u015b\u0107 danych. Je\u015bli parametry kopii zapasowej i serwera nie s\u0105 ze sob\u0105 zgodne, powstaj\u0105 niepotrzebne skoki obci\u0105\u017cenia wej\u015bcia\/wyj\u015bcia. Podczas planowanych kopii zapasowych ostro\u017cnie reguluj\u0119 przepustowo\u015b\u0107 operacji wej\u015bcia\/wyj\u015bcia, aby \u015bcie\u017cki odczytu i zapisu pozosta\u0142y czyste. Po zako\u0144czeniu procesu sprawdzam op\u00f3\u017anienia i odsetek brudnych stron, aby wykluczy\u0107 efekty uboczne.<\/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>Tuning krok po kroku w praktyce<\/h2>\n\n<p>Zaczynam od <strong>Inwentaryzacja<\/strong>: typ pami\u0119ci, rzeczywista liczba IOPS, op\u00f3\u017anienia i przepustowo\u015b\u0107. Nast\u0119pnie ustalam rozmiar puli bufor\u00f3w, dostosowuj\u0105c go do dost\u0119pnej pami\u0119ci RAM lub limitu Cgroup. Potem wybieram metod\u0119 fluszowania (HDD: fsync\/O_DIRECT; SSD\/NVMe: O_DIRECT lub O_DIRECT_NO_FSYNC). W celu zapewnienia trwa\u0142o\u015bci ustawiam parametr innodb_flush_log_at_trx_commit na 1 dla danych krytycznych lub na 2, je\u015bli dopuszczalna jest utrata jednej sekundy. Na koniec dostosowuj\u0119 parametry innodb_io_capacity i innodb_max_dirty_pages_pct tak, aby operacje flushing przebiega\u0142y p\u0142ynnie i stabilnie, oraz regularnie monitoruj\u0119 wska\u017aniki.<\/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>Prawid\u0142owe okre\u015blenie rozmiaru dziennika ponownego wykonania (redo log) i punkt\u00f3w kontrolnych<\/h2>\n\n<p>Zapobiegam powstawaniu szczyt\u00f3w przep\u0142ywu poprzez <strong>Dzienniki ponownego wykonania<\/strong> dopasowa\u0107 ich rozmiar. Zbyt ma\u0142e pliki dziennika zmuszaj\u0105 InnoDB do cz\u0119stych punkt\u00f3w kontrolnych; skutkiem tego jest przeci\u0105\u017cenie zwrotne i niestabilne op\u00f3\u017anienia. Dzi\u0119ki wi\u0119kszym plikom dziennika wyr\u00f3wnuj\u0119 przebieg punkt\u00f3w kontrolnych, poniewa\u017c mo\u017cna buforowa\u0107 wi\u0119cej danych zmian, zanim b\u0119d\u0105 one musia\u0142y zosta\u0107 przeniesione do plik\u00f3w danych. Bior\u0119 przy tym pod uwag\u0119 dwa ograniczenia: po pierwsze dost\u0119pn\u0105 przepustowo\u015b\u0107 wej\u015bcia\/wyj\u015bcia (du\u017cy bufor nie chroni przed zbyt wolnymi dyskami), a po drugie czas odzyskiwania po awarii, kt\u00f3ry wyd\u0142u\u017ca si\u0119 przy bardzo du\u017cych dziennikach redo. W przypadku obci\u0105\u017ce\u0144 wymagaj\u0105cych intensywnego zapisu ustalam rozmiar dziennika tak, aby typowe szczyty obci\u0105\u017cenia by\u0142y absorbowane w ramach bud\u017cetu dziennika bez nieuzasadnionego wyd\u0142u\u017cania czasu odzyskiwania.<\/p>\n\n<p>W celu precyzyjnego dostrojenia obserwuj\u0119 wska\u017aniki dotycz\u0105ce \u201echeckpoint age\u201c oraz zale\u017cno\u015b\u0107 mi\u0119dzy szybko\u015bci\u0105 zapisu do dziennika a szybko\u015bci\u0105 opr\u00f3\u017cniania stron danych. Je\u015bli punkty kontrolne wielokrotnie osi\u0105gaj\u0105 g\u00f3rn\u0105 granic\u0119, zwi\u0119kszam rozmiar dziennika lub ostro\u017cnie zwi\u0119kszam przepustowo\u015b\u0107 operacji wej\u015bcia\/wyj\u015bcia dla modu\u0142u czyszcz\u0105cego strony. Celem jest p\u0142ynny, ci\u0105g\u0142y post\u0119p tworzenia punkt\u00f3w kontrolnych bez konieczno\u015bci podejmowania dzia\u0142a\u0144 wymuszonych.<\/p>\n\n<h2>Adaptacyjne p\u0142ukanie i warto\u015bci progowe<\/h2>\n\n<p>Mechanizmy adaptacyjne InnoDB pomagaj\u0105 w opr\u00f3\u017cnianiu bie\u017c\u0105cej <strong>Szybko\u015b\u0107 zapisu<\/strong> dostosowa\u0107. Dbam o to, aby pr\u00f3g LWM (Low Watermark) dla brudnych stron nie by\u0142 zbyt niski, tak aby modu\u0142 czyszcz\u0105cy strony nie dzia\u0142a\u0142 nieustannie \u201ena granicy\u201c. Jednocze\u015bnie unikam warto\u015bci maksymalnych, kt\u00f3re prowadz\u0105 do zbyt agresywnych operacji zbiorczego opr\u00f3\u017cniania. W praktyce sprawdzam, czy stosunek \u201enowych brudnych stron na sekund\u0119\u201c do \u201eIOPS operacji flush\u201c pozostaje stabilny w d\u0142u\u017cszej perspektywie. Je\u015bli pula bufor\u00f3w stale przekracza docelowy poziom zanieczyszczenia, stopniowo zwi\u0119kszam warto\u015b\u0107 innodb_io_capacity lub zmniejszam docelowe warto\u015bci brudnych stron.<\/p>\n\n<p>W konfiguracjach NVMe mog\u0119 da\u0107 programowi Page-Cleaner wi\u0119ksz\u0105 swobod\u0119 dzia\u0142ania, poniewa\u017c urz\u0105dzenia te utrzymuj\u0105 kr\u00f3tkie op\u00f3\u017anienia nawet pod obci\u0105\u017ceniem. W przypadku dysk\u00f3w HDD stosuj\u0119 bardziej konserwatywne progi i ograniczam gwa\u0142towne wahania, aby unikn\u0105\u0107 skok\u00f3w op\u00f3\u017anie\u0144 spowodowanych poszukiwaniem danych. Wsp\u00f3\u0142dzia\u0142anie z <strong>innodb_flush_neighbors<\/strong> Wykorzystuj\u0119 to w spos\u00f3b celowy: dysk twardy korzysta z blisko\u015bci fizycznej, a pami\u0119\u0107 flash \u2013 nie.<\/p>\n\n<h2>Wsp\u00f3\u0142dzia\u0142anie funkcji binlog i Group-Commit<\/h2>\n\n<p>Ka\u017cdy, kto korzysta z replikacji, bierze to pod uwag\u0119 <strong>Protok\u00f3\u0142 zatwierdze\u0144<\/strong> O dzienniku Redo i dzienniku binarnym. Konfiguruj\u0119 cz\u0119stotliwo\u015bci opr\u00f3\u017cniania tak, aby dzia\u0142a\u0142o Group-Commit: wiele ma\u0142ych transakcji powinno by\u0107 opr\u00f3\u017cnianych zbiorczo, zamiast synchronizowa\u0107 ka\u017cde zatwierdzenie osobno. W tym celu stosuj\u0119 ustawienie innodb_flush_log_at_trx_commit=1 dla maksymalnej trwa\u0142o\u015bci lub 2 dla mniejszej latencji. R\u00f3wnolegle dostosowuj\u0119 mechanizm synchronizacji dziennika binarnego tak, aby by\u0142 dostosowany do systemu docelowego. Niska cz\u0119stotliwo\u015b\u0107 synchronizacji zmniejsza koszty na jedno zatwierdzenie, ale w przypadku awarii mo\u017ce oznacza\u0107 wi\u0119ksz\u0105 utrat\u0119 danych z dziennika binarnego. W \u015brodowiskach o wysokiej cz\u0119stotliwo\u015bci zapisu i akceptowalnym op\u00f3\u017anieniu mi\u0119dzy serwerem g\u0142\u00f3wnym a replik\u0105 akceptuj\u0119 umiarkowane rozdzielenie synchronizacji dziennik\u00f3w binarnych w celu zmniejszenia op\u00f3\u017anie\u0144. Og\u00f3ln\u0105 logik\u0119 i kompromisy om\u00f3wi\u0142em w artykule na temat <a href=\"https:\/\/webhosting.de\/pl\/logi-binarne-mariadb-logika-dzialania\/\">Dzienniki binarne<\/a> i nast\u0119pnie dostosowuj\u0119 je do konkretnego profilu Flush.<\/p>\n\n<h2>System plik\u00f3w, pami\u0119\u0107 podr\u0119czna zapisu i zabezpieczenie przed awari\u0105 zasilania<\/h2>\n\n<p>Oceniam <strong>W\u0142a\u015bciwo\u015bci pami\u0119ci i kontrolera<\/strong> przed tuningiem. Urz\u0105dzenia z <em>Ochrona przed utrat\u0105 zasilania<\/em> (PLP) mog\u0105 bezpiecznie korzysta\u0107 z pami\u0119ci podr\u0119cznej zapisu; bez PLP istnieje ryzyko, \u017ce operacje zapisu zg\u0142oszone jako potwierdzone zostan\u0105 utracone w przypadku awarii zasilania. W takich przypadkach zachowuj\u0119 wi\u0119ksz\u0105 ostro\u017cno\u015b\u0107: \u015bcie\u017cki fsync pozostaj\u0105 obowi\u0105zkowe, a opcj\u0119 O_DIRECT_NO_FSYNC stosuj\u0119 wy\u0142\u0105cznie na sprz\u0119cie z niezawodnym zabezpieczeniem. W systemach plik\u00f3w Linuksa, takich jak ext4 czy XFS, bariery te s\u0105 domy\u015blnie aktywne; nie wy\u0142\u0105czam ich lekkomy\u015blnie, lecz dostosowuj\u0119 ustawienia w oparciu o istniej\u0105ce gwarancje. W przypadku systemu plik\u00f3w ZFS dodatkowo bior\u0119 pod uwag\u0119 jego w\u0142asny dziennik intencji (Intent Log) oraz strategie buforowania; w zale\u017cno\u015bci od konfiguracji warto zastosowa\u0107 oddzielnie dostosowan\u0105 strategi\u0119, kt\u00f3ra minimalizuje r\u00f3wnie\u017c podw\u00f3jne buforowanie.<\/p>\n\n<p>Aby zapewni\u0107 sta\u0142\u0105 wydajno\u015b\u0107, sprawdzam r\u00f3wnie\u017c wyr\u00f3wnanie (np. strony 4K w przypadku dysk\u00f3w SSD) oraz negocjowanie g\u0142\u0119boko\u015bci kolejki. Kr\u00f3tkie, deterministyczne op\u00f3\u017anienia s\u0105 cz\u0119sto wa\u017cniejsze dla \u015bcie\u017cek zatwierdzania ni\u017c maksymalna liczba operacji IOPS w syntetycznych testach por\u00f3wnawczych. Dlatego przeprowadzam testy z wykorzystaniem realistycznych blok\u00f3w danych i poziom\u00f3w wsp\u00f3\u0142bie\u017cno\u015bci, a nie wy\u0142\u0105cznie przy szczytowych obci\u0105\u017ceniach.<\/p>\n\n<h2>Metodologia pomiaru: wska\u017aniki, stan i diagnoza<\/h2>\n\n<p>Steruj\u0119 tuningiem za pomoc\u0105 <strong>rzeczywiste warto\u015bci pomiarowe<\/strong> zamiast emocji. Do moich standardowych wska\u017anik\u00f3w nale\u017c\u0105:<\/p>\n<ul>\n  <li>Op\u00f3\u017anienie zatwierdzania (p50\/p95\/p99) podczas szczyt\u00f3w obci\u0105\u017cenia<\/li>\n  <li>Op\u00f3\u017anienie i szybko\u015b\u0107 operacji fsync dla plik\u00f3w dziennika i plik\u00f3w danych<\/li>\n  <li>Udzia\u0142 stron z nieodpowiedni\u0105 tre\u015bci\u0105 w czasie oraz jego zmienno\u015b\u0107<\/li>\n  <li>Post\u0119p w punktach kontrolnych oraz stosunek szybko\u015bci zapisu do dziennika do szybko\u015bci opr\u00f3\u017cniania<\/li>\n  <li>Zaleg\u0142o\u015bci w czyszczeniu stron (czy stale wyst\u0119puj\u0105 zaleg\u0142e operacje czyszczenia?)<\/li>\n<\/ul>\n<p>W tym celu analizuj\u0119 dane dotycz\u0105ce stanu InnoDB i koreluj\u0119 je z wska\u017anikami systemu operacyjnego (iostat, vmstat). Zwracam szczeg\u00f3ln\u0105 uwag\u0119 na op\u00f3\u017anienia dyskowe w milisekundach, rozk\u0142ad operacji na odczyty i zapisy oraz odsetek operacji synchronicznych. Aby zapewni\u0107 powtarzalno\u015b\u0107 test\u00f3w, w ka\u017cdym etapie celowo zmieniam tylko jeden parametr i rejestruj\u0119 wyniki w d\u0142u\u017cszych odst\u0119pach czasu, tak aby warto\u015bci odstaj\u0105ce nie dominowa\u0142y w wynikach.<\/p>\n\n<h2>Typowe antywzorce i sposoby ich przeciwdzia\u0142ania<\/h2>\n\n<ul>\n  <li>Zbyt ma\u0142e pliki dziennika Redo: powoduje cz\u0119ste tworzenie punkt\u00f3w kontrolnych. \u015arodek zaradczy: zwi\u0119kszy\u0107 rozmiar pliku dziennika i dostosowa\u0107 przepustowo\u015b\u0107 operacji wej\u015bcia\/wyj\u015bcia dla operacji flushingu.<\/li>\n  <li>Odsetek brudnych stron jest stale zbyt wysoki: modu\u0142 Page-Cleaner jest przeci\u0105\u017cony, grozi zalew operacji flush. \u015arodek zaradczy: obni\u017cy\u0107 warto\u015b\u0107 innodb_max_dirty_pages_pct i zwi\u0119kszy\u0107 warto\u015b\u0107 io_capacity.<\/li>\n  <li>O_DIRECT bez monitorowania: cho\u0107 zapobiega podw\u00f3jnemu buforowaniu, to przy niew\u0142a\u015bciwej wydajno\u015bci wej\u015bcia\/wyj\u015bcia mo\u017ce prowadzi\u0107 do wyst\u0105pienia skok\u00f3w obci\u0105\u017cenia. \u015arodek zaradczy: \u015bcis\u0142e monitorowanie i dostosowanie warto\u015bci wydajno\u015bci do rzeczywistej liczby operacji IOPS.<\/li>\n  <li>Niew\u0142a\u015bciwe ustawienie opcji \u201eFlush Neighbors\u201d na dyskach SSD\/NVMe: powoduje zb\u0119dn\u0105 prac\u0119 bez korzy\u015bci. Rozwi\u0105zanie: ustawi\u0107 innodb_flush_neighbors=0.<\/li>\n  <li>Synchronizacja commit\u00f3w na wolnych no\u015bnikach: ka\u017cda transakcja wi\u0105\u017ce si\u0119 z kosztem operacji fsync. \u015arodek zaradczy: promowanie group-commit, w razie potrzeby ustawienie innodb_flush_log_at_trx_commit=2 (po rozwa\u017ceniu ryzyka).<\/li>\n  <li>Kontener bez bufora pami\u0119ci RAM: pula bufor\u00f3w jest zbyt du\u017ca, grozi wyst\u0105pieniem b\u0142\u0119du OOM. \u015arodek zaradczy: \u015bci\u015ble dostosowa\u0107 pul\u0119 bufor\u00f3w do limit\u00f3w Cgroup i monitorowa\u0107 wska\u017anik Pressure.<\/li>\n<\/ul>\n\n<h2>Uwzgl\u0119dnienie \u015bcie\u017cek wy\u0142\u0105czania i przywracania systemu<\/h2>\n\n<p>Planuj\u0119, w jaki spos\u00f3b ustawienia wp\u0142ywaj\u0105 na <strong>Wy\u0142\u0105czenie<\/strong> oraz <strong>Odzyskiwanie po awarii<\/strong> wp\u0142ywa\u0107. Szybkie i poprawne wy\u0142\u0105czenie systemu skraca czas przywracania, poniewa\u017c trzeba zastosowa\u0107 mniej operacji \u201eredo\u201d. Bardzo du\u017ce dzienniki \u201eredo\u201d sprzyjaj\u0105 spokojnym punktom kontrolnym, ale w razie b\u0142\u0119du wyd\u0142u\u017caj\u0105 czas nadrabiania zaleg\u0142o\u015bci. W przypadku system\u00f3w produkcyjnych wybieram tak\u0105 r\u00f3wnowag\u0119, aby z jednej strony nie powodowa\u0107 nadmiernej liczby operacji flush w codziennej eksploatacji, a z drugiej strony nie musie\u0107 godzi\u0107 si\u0119 na zbyt d\u0142ugie odzyskiwanie danych w najgorszym scenariuszu. Od samego pocz\u0105tku uwzgl\u0119dniam przy tym okna serwisowe i kopie zapasowe.<\/p>\n\n<h2>Praktyczne rozwi\u0105zania dla typowych obci\u0105\u017ce\u0144<\/h2>\n\n<ul>\n  <li>OLTP z wieloma ma\u0142ymi operacjami commit na dyskach SSD\/NVMe: O_DIRECT, innodb_flush_log_at_trx_commit=1 lub 2 w zale\u017cno\u015bci od trwa\u0142o\u015bci, innodb_io_capacity raczej wysokie, Dirty-Pages umiarkowane, Flush-Neighbors=0. Aktywne wykorzystywanie grupowego zatwierdzania plik\u00f3w binlog.<\/li>\n  <li>Import wsadowy wymagaj\u0105cy intensywnej operacji zapisu: tymczasowo nieco zwi\u0119kszy\u0107 docelow\u0105 liczb\u0119 brudnych stron, podnie\u015b\u0107 przepustowo\u015b\u0107 operacji wej\u015bcia\/wyj\u015bcia, a po zako\u0144czeniu przywr\u00f3ci\u0107 poprzednie ustawienia. Je\u015bli poziom trwa\u0142o\u015bci jest akceptowalny, tymczasowo ustawi\u0107 innodb_flush_log_at_trx_commit=2.<\/li>\n  <li>Starsze systemy oparte na dyskach twardych (HDD): konserwatywna przepustowo\u015b\u0107 wej\u015bcia\/wyj\u015bcia, Flush-Neighbors=1, innodb_flush_method=fsync lub O_DIRECT w zale\u017cno\u015bci od obci\u0105\u017cenia pami\u0119ci RAM. Nale\u017cy zwr\u00f3ci\u0107 szczeg\u00f3ln\u0105 uwag\u0119 na ci\u0105g\u0142e opr\u00f3\u017cnianie pami\u0119ci, aby unikn\u0105\u0107 burz operacji wyszukiwania.<\/li>\n  <li>Woluminy w chmurze z limitem IOPS: \u015bci\u015ble dostosowa\u0107 warto\u015b\u0107 `innodb_io_capacity` do gwarantowanego limitu, unika\u0107 skok\u00f3w obci\u0105\u017cenia, wykorzystywa\u0107 `O_DIRECT` w celu oszcz\u0119dzania pami\u0119ci RAM. W przypadku system\u00f3w opartych na kredytach (Burst-I\/O) stosuj\u0119 regulacj\u0119 tempa (pacing), aby bud\u017cet nie zosta\u0142 wyczerpany nagle.<\/li>\n<\/ul>\n\n<h2>Lista kontrolna rozwi\u0105zywania problem\u00f3w<\/h2>\n\n<ul>\n  <li>D\u0142ugie op\u00f3\u017anienia w zatwierdzaniu w p95? Sprawd\u017a czas trwania operacji fsync, w\u0142\u0105cz funkcj\u0119 Group-Commit, w razie potrzeby zmniejsz cz\u0119stotliwo\u015b\u0107 operacji flush (po rozwa\u017ceniu ryzyka).<\/li>\n  <li>Du\u017ca zmienno\u015b\u0107 odsetka stron brudnych? Dokonaj precyzyjnej regulacji parametr\u00f3w io_capacity\/io_capacity_max i sprawd\u017a progi adaptacyjnego opr\u00f3\u017cniania.<\/li>\n  <li>Nag\u0142e skoki op\u00f3\u017anie\u0144 podczas tworzenia kopii zapasowych? Zsynchronizuj parametry narz\u0119dzia do tworzenia kopii zapasowych z warto\u015bciami serwera, tymczasowo dostosuj ograniczenie operacji wej\u015bcia\/wyj\u015bcia.<\/li>\n  <li>Replika pozostaje w tyle? Nale\u017cy wsp\u00f3lnie oceni\u0107 strategi\u0119 opr\u00f3\u017cniania pliku binlog, cz\u0119stotliwo\u015bci synchronizacji oraz op\u00f3\u017anienia sieciowe; zbyt agresywne synchronizacje spowalniaj\u0105 serwer g\u0142\u00f3wny.<\/li>\n  <li>Obci\u0105\u017cenie pami\u0119ci RAM po przej\u015bciu na O_DIRECT? Nale\u017cy ponownie wyregulowa\u0107 r\u00f3wnowag\u0119 mi\u0119dzy pul\u0105 bufor\u00f3w a pami\u0119ci\u0105 podr\u0119czn\u0105 systemu operacyjnego; O_DIRECT zmniejsza pami\u0119\u0107 podr\u0119czn\u0105 systemu operacyjnego, ale mo\u017ce mie\u0107 wp\u0142yw na pami\u0119\u0107 podr\u0119czn\u0105 stron aplikacji.<\/li>\n<\/ul>\n\n<h2>Kr\u00f3tkie podsumowanie<\/h2>\n\n<p>Organizuj\u0119 <strong>Strategia \u201eFlush\u201d<\/strong> zawsze zale\u017cy od sprz\u0119tu i cel\u00f3w dotycz\u0105cych trwa\u0142o\u015bci. O_DIRECT zapobiega podw\u00f3jnemu buforowaniu i zazwyczaj zapewnia najlepsze wyniki na dyskach SSD\/NVMe. Parametr innodb_flush_log_at_trx_commit decyduje o tempie na jedno zatwierdzenie (commit) oraz o ryzyku w przypadku awarii zasilania. Odpowiednio dobrane warto\u015bci dla parametr\u00f3w Dirty Pages, I\/O-Kapazit\u00e4t i Flush-Neighbors zapewniaj\u0105 r\u00f3wnomiern\u0105 szybko\u015b\u0107 zapisu. Kto dodatkowo mierzy koszty operacji fsync i przestrzega limit\u00f3w chmury, ten niezawodnie zapewnia MariaDB odpowiedni\u0105 szybko\u015b\u0107 bez po\u015bwi\u0119cania bezpiecze\u0144stwa.<\/p>","protected":false},"excerpt":{"rendered":"<p>Dowiedz si\u0119, jak optymalnie skonfigurowa\u0107 metody flush w MariaDB oraz innodb flush z wykorzystaniem O_DIRECT, fsync i innodb_flush_log_at_trx_commit. W tym przewodniku znajdziesz praktyczne wskaz\u00f3wki dotycz\u0105ce optymalizacji baz danych w \u015brodowiskach z dyskami HDD, SSD oraz w chmurze, ze szczeg\u00f3lnym uwzgl\u0119dnieniem wydajno\u015bci i bezpiecze\u0144stwa danych.<\/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":"62","_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\/pl\/wp-json\/wp\/v2\/posts\/21539","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/comments?post=21539"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/posts\/21539\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/media\/21532"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/media?parent=21539"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/categories?post=21539"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/tags?post=21539"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}