{"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-methods-innodb-fsync-performance-guide-buffer","status":"publish","type":"post","link":"https:\/\/webhosting.de\/en\/mariadb-flush-methoden-innodb-fsync-performance-guide-buffer\/","title":{"rendered":"Comparing MariaDB Flush Methods: Optimizing the INNODB FLUSH Setting"},"content":{"rendered":"<p>I'm comparing the most important methods for <strong>MariaDB Flush<\/strong> and show how to configure `innodb_flush` to reduce write latency while ensuring data remains safe. The focus is on the options for `innodb_flush_method`, the durability control `innodb_flush_log_at_trx_commit`, and appropriate values for dirty pages and I\/O capacity on HDDs, SSDs, and NVMe drives.<\/p>\n\n<h2>Key points<\/h2>\n\n<ul>\n  <li><strong>innodb_flush_method<\/strong> Determines how InnoDB interacts with the OS cache and prevents double caching.<\/li>\n  <li><strong>innodb_flush_log_at_trx_commit<\/strong> Controls durability versus latency per commit.<\/li>\n  <li><strong>Dirty Pages<\/strong> and I\/O capacity smooth out write rates and prevent flush storms.<\/li>\n  <li><strong>Flush Neighbors<\/strong> distinguishes between strategies optimized for HDDs and those optimized for SSDs\/NVMe.<\/li>\n  <li><strong>Cloud Setups<\/strong> require O_DIRECT, an appropriate IOPS limit, and proper 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>What exactly does `innodb_flush_method` mean?<\/h2>\n\n<p>I choose the <strong>Flush Method<\/strong> depending on how InnoDB interacts with the operating system cache. With <strong>fsync<\/strong> Data is first stored in the OS cache and then permanently written via `fsync`; this can lead to double caching. If I set `O_DIRECT`, InnoDB largely bypasses the page cache, which saves RAM and almost always helps on SSD\/NVMe drives. O_DSYNC uses write-through and reduces buffering, which can be useful in specific scenarios. O_DIRECT_NO_FSYNC builds on O_DIRECT and adjusts the sync behavior, making it a strong option on reliable hardware with its own protection mechanisms.<\/p>\n\n<h3>Typical Values and Versions<\/h3>\n\n<p>Starting with MariaDB 10.6, <strong>O_DIRECT<\/strong> is often the default setting because it prevents double caching. In older versions, <strong>fsync<\/strong>, which may still be acceptable for HDD setups. Starting with version 11.0, additional variables such as `innodb_data_file_buffering` and `innodb_log_file_buffering` control the details of buffering. In practice, `innodb_flush_method` remains the key parameter that I check first. After that, I fine-tune the detailed parameters until latencies decrease and throughput remains constant.<\/p>\n\n<h2>Using `innodb_flush_log_at_trx_commit` Strategically<\/h2>\n\n<p>I consider <strong>Durability<\/strong> and latency are separate, because `innodb_flush_log_at_trx_commit` determines both. A value of 1 writes and performs an `fsync` on every commit, which offers maximum reliability but significantly slows down slow disks. A value of 2 writes to the OS cache upon commit and performs an fsync approximately once per second; this reduces latency but risks up to one second of data loss in the event of a power outage. A value of 0 defers log writes entirely to once per second and delivers the highest write performance with the greatest risk. If you also pay attention to the binlog strategy, you can intelligently align commit latencies with replication requirements; I explain the details of how these interact here: <a href=\"https:\/\/webhosting.de\/en\/mariadb-binary-logs-performance-logic\/\">Binary Logs<\/a>.<\/p>\n\n<h2>Controlling Page Flushing and Dirty Pages<\/h2>\n\n<p>I believe the percentage of the <strong>Dirty Pages<\/strong> so that write rates remain consistent. To achieve this, I set `innodb_max_dirty_pages_pct` to a moderate value to prevent sudden flush storms. I set the values for `innodb_io_capacity` and `innodb_io_capacity_max` based on the actual IOPS of the storage: low for HDDs, higher for SSDs\/NVMe. A well-configured page cleaner thread writes back in a timely manner from an LRU perspective, before pages are evicted. I describe more about thread fine-tuning and useful metrics here: <a href=\"https:\/\/webhosting.de\/en\/mariadb-page-cleaner-threads-database\/\">Page Cleaner Threads<\/a>.<\/p>\n\n<h2>Flush Neighbors: HDD vs. SSD\/NVMe<\/h2>\n\n<p>With <strong>innodb_flush_neighbors<\/strong> I either use HDD-friendly write patterns or disable them. On HDDs, writing adjacent pages together improves efficiency because the read\/write head doesn't have to move as much. On SSDs\/NVMe drives, the location on the storage medium is hardly relevant; there, sequential writing generates unnecessary write operations. For HDDs, I usually set the value to 1; for SSDs\/NVMe, I set it to 0. This way, I reduce unnecessary write operations and extend the lifespan of faster drives.<\/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>Understanding and Limiting fsync Costs<\/h2>\n\n<p>I measure the <strong>fsync<\/strong>-Latency, because every millisecond slows down commits. Otherwise, write-heavy workloads spend a large portion of their time waiting for confirmation from the storage device. By setting `innodb_flush_log_at_trx_commit=2` or `0`, I significantly reduce the number of costly syncs. O_DIRECT or O_DIRECT_NO_FSYNC helps prevent double caching and simplifies I\/O paths. On slower hardware, I often see noticeable performance gains when I consider the sync frequency, flush method, and dirty page quota together.<\/p>\n\n<h2>Recommended Initial Values by Storage Medium<\/h2>\n\n<p>I'll start with some useful <strong>Baseline<\/strong>-Set the values and then adjust them based on measured data. The table provides guidelines for typical setups and workloads. The key factors are actual IOPS, latencies, and the percentage of write transactions. After the first run, I check the dirty page ratio, commit latency, and number of fsync calls. I then fine-tune the settings incrementally until the profile remains clean and consistent.<\/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>Notes<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>HDD<\/td>\n      <td>fsync or O_DIRECT<\/td>\n      <td>1 (critical) \/ 2 (balance)<\/td>\n      <td>200\u2013400<\/td>\n      <td>1<\/td>\n      <td>More latency per <strong>Commit<\/strong>, continuous flushing is important<\/td>\n    <\/tr>\n    <tr>\n      <td>SSD<\/td>\n      <td>O_DIRECT<\/td>\n      <td>1 (critical) \/ 2 (balance)<\/td>\n      <td>1000\u20132000<\/td>\n      <td>0<\/td>\n      <td>Avoid double caching; keep the number of dirty pages to a minimum<\/td>\n    <\/tr>\n    <tr>\n      <td>NVMe<\/td>\n      <td>O_DIRECT or O_DIRECT_NO_FSYNC<\/td>\n      <td>1 (critical) \/ 2 (balanced) \/ 0 (special case)<\/td>\n      <td>2000\u20138000+<\/td>\n      <td>0<\/td>\n      <td>Very low <strong>Latency<\/strong>, Choose the sync frequency carefully<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>In this regard, I refer to InnoDB <strong>Double-write buffer<\/strong>, which reduces data corruption during crashes but generates additional writes; I'll summarize the background and tuning options briefly here: <a href=\"https:\/\/webhosting.de\/en\/innodb-double-write-buffer-security-performance-and-tuning-focus\/\">Double-write buffer<\/a>. In write-intensive environments, I measure performance with and without double-write effects before making any decisions. Critical systems prioritize data integrity over maximum write rates. Test or analytics setups can be more aggressive. I always validate my decisions with repeatable 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 and container environments<\/h2>\n\n<p>I avoid duplicates <strong>Page cache<\/strong>, because RAM is limited there; O_DIRECT is therefore often a good fit. I set `innodb_io_capacity` based on the volume\u2019s IOPS limits so as not to trigger throttling. The buffer pool must fit within the cgroup limit; otherwise, there\u2019s a risk of OOM kills. Persistent volumes are mandatory, since ephemeral storage offers no durability. In highly elastic setups, I limit the number of concurrent connections and use the thread pool judiciously.<\/p>\n\n<h2>Backup and Flush Settings<\/h2>\n\n<p>I'm checking to see if backup tools have their own <strong>Flush<\/strong>-Use settings. `mariadb-backup` can set `innodb_flush_method` to a different value to ensure a consistent view. If backup and server parameters do not match, unnecessary I\/O spikes occur. During scheduled backups, I carefully manage I\/O capacity to ensure that read\/write paths remain unimpeded. After the backup runs, I check latencies and dirty page ratios to rule out any side effects.<\/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>Step-by-Step Tuning in Practice<\/h2>\n\n<p>I start with a <strong>Inventory<\/strong>: Storage type, actual IOPS, latencies, and throughput. Next, I set the buffer pool size to match the available RAM or the cgroup limit. Then I select the flush method (HDD: fsync\/O_DIRECT; SSD\/NVMe: O_DIRECT or O_DIRECT_NO_FSYNC). For durability, I set innodb_flush_log_at_trx_commit to 1 for critical data or 2 if a one-second loss is acceptable. Finally, I adjust innodb_io_capacity and innodb_max_dirty_pages_pct so that flushing runs smoothly and consistently, and I monitor the metrics regularly.<\/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>Properly Sizing the Redo Log and Checkpoints<\/h2>\n\n<p>I prevent flush peaks by <strong>Redo Logs<\/strong> size them appropriately. Logs that are too small force InnoDB to perform frequent checkpoints, resulting in backpressure and erratic latencies. With larger log files, I smooth out the checkpoint process because more change data can be buffered before it is forced to be written to the data files. In doing so, I keep two limits in mind: first, the available I\/O capacity (a large buffer does not protect against disks that are too slow); second, the crash recovery time, which increases with very large redo logs. In write-intensive workloads, I set the log size so that typical load spikes are absorbed within the log budget without causing recovery time to increase unreasonably.<\/p>\n\n<p>To fine-tune the system, I monitor the \u201echeckpoint age\u201c metrics and the relationship between the log write rate and the flush rate of the data pages. If checkpoints repeatedly hit the upper limit, I either scale the log size or carefully increase the I\/O capacity for the page cleaner. The goal is smooth, continuous checkpoint progress without forced actions.<\/p>\n\n<h2>Adaptive Flushing and Threshold Values<\/h2>\n\n<p>InnoDB's adaptive mechanisms help ensure that flushing occurs at the appropriate time <strong>Writing Speed<\/strong> adjust. I make sure the LWM (Low Watermark) threshold for dirty pages isn\u2019t set too low, so that the page cleaner isn\u2019t constantly operating \u201eon the edge.\u201c At the same time, I avoid maximum values that lead to overly aggressive bulk flushes. In practice, I check whether the ratio of \u201enew dirty pages per second\u201c to \u201eflush IOPS\u201c remains stable over the long term. If the buffer pool consistently exceeds the target, I gradually increase innodb_io_capacity or reduce the dirty page targets.<\/p>\n\n<p>On NVMe setups, I can give the page cleaner more leeway because the devices maintain low latencies even under load. On HDDs, I use more conservative thresholds and limit large fluctuations to avoid seek-related latency spikes. The interaction with <strong>innodb_flush_neighbors<\/strong> I use them strategically: HDDs benefit from spatial proximity, while flash memory does not.<\/p>\n\n<h2>Binlog and Group Commit Working Together<\/h2>\n\n<p>Anyone who uses replication takes this into account <strong>Commit Log<\/strong> About the redo log and binary log. I configure the flush frequencies so that group commit takes effect: Many small transactions should be flushed together, rather than synchronizing each commit individually. To achieve this, I set `innodb_flush_log_at_trx_commit` to 1 for maximum durability or to 2 for lower latency. At the same time, I configure the binlog sync mechanism to suit the target system. A low sync frequency reduces the cost per commit but can result in greater binlog loss in the event of a crash. In environments with high write rates and tolerable delays between the master and replica, I accept a moderate decoupling of binlog syncs to reduce latency. I discuss the overarching logic and trade-offs in the post on <a href=\"https:\/\/webhosting.de\/en\/mariadb-binary-logs-performance-logic\/\">Binary Logs<\/a> and then adjust it to fit the specific flush profile.<\/p>\n\n<h2>File System, Write Cache, and Power Failure Protection<\/h2>\n\n<p>I rate the <strong>Memory and Controller Properties<\/strong> Before tuning. Devices with <em>Power loss protection<\/em> (PLP) can safely use write caches; without PLP, there is a risk that writes reported as confirmed will be lost in the event of a power failure. In such cases, I take a more conservative approach: fsync paths remain mandatory, and I only use O_DIRECT_NO_FSYNC on hardware with reliable protection. On Linux file systems such as ext4 or XFS, these safeguards are enabled by default; I do not disable them lightly, but rather tailor my tuning around the existing guarantees. On ZFS, I also take into account its own intent log and caching strategies; depending on the setup, it may be worthwhile to implement a separately tuned strategy that also minimizes double caching.<\/p>\n\n<p>To ensure consistent performance, I also check alignments (e.g., 4K pages on SSDs) and negotiate the queue depth. Short, deterministic latencies are often more important for commit paths than maximum IOPS in synthetic benchmarks. That\u2019s why I test with realistic blocks and concurrency levels rather than just peak workloads.<\/p>\n\n<h2>Measurement Methodology: Metrics, Status, and Diagnosis<\/h2>\n\n<p>I control the tuning via <strong>hard data<\/strong> rather than intuition. My standard indicators include:<\/p>\n<ul>\n  <li>Commit Latency (p50\/p95\/p99) During Peak Loads<\/li>\n  <li>fsync Latency and Rate for Log and Data Files<\/li>\n  <li>Proportion of \"Dirty Pages\" Over Time and Its Variance<\/li>\n  <li>Checkpoint Progress and the Ratio of Log Write Rate to Flush Rate<\/li>\n  <li>Page Cleaner Backlog (Are there consistently pending flushes?)<\/li>\n<\/ul>\n<p>To do this, I examine the InnoDB status output and correlate it with OS metrics (iostat, vmstat). Specifically, I monitor disk latency in milliseconds, the distribution of reads and writes, and the proportion of synchronous operations. To ensure reproducible tests, I deliberately vary only one parameter per step and log the results over extended intervals so that outliers do not dominate the data.<\/p>\n\n<h2>Common Anti-Patterns and Countermeasures<\/h2>\n\n<ul>\n  <li>Redo logs that are too small: leads to frequent checkpoints. Solution: Increase the log size and adjust the I\/O capacity for flushing.<\/li>\n  <li>Dirty pages consistently too high: Page Cleaner is overwhelmed, and flush storms are imminent. Countermeasure: Lower innodb_max_dirty_pages_pct and increase io_capacity.<\/li>\n  <li>O_DIRECT without monitoring: While this prevents double caching, it can lead to bursts if the I\/O capacity is set incorrectly. Countermeasure: Closely monitor performance and align capacity values with actual IOPS.<\/li>\n  <li>Inappropriate flush neighbors on SSD\/NVMe: create unnecessary work without any benefit. Solution: Set `innodb_flush_neighbors=0`.<\/li>\n  <li>Commit syncs on slow storage: every transaction incurs the fsync cost. Countermeasure: Encourage group commits; if necessary, set `innodb_flush_log_at_trx_commit=2` (after weighing the risks).<\/li>\n  <li>Containers without a RAM buffer: Buffer pool is too large, risk of OOM. Countermeasure: Strictly align the buffer pool with Cgroup limits and monitor pressure.<\/li>\n<\/ul>\n\n<h2>Consider Shutdown and Recovery Paths<\/h2>\n\n<p>I'm planning how settings affect <strong>Shutdown<\/strong> and <strong>Crash Recovery<\/strong> impact. A quick, clean shutdown reduces recovery times because fewer redo logs need to be applied. Very large redo logs facilitate smooth checkpoints but prolong the catch-up process in the event of a failure. For production systems, I strike a balance so that, on the one hand, I don\u2019t create flush storms during day-to-day operations, and on the other hand, I don\u2019t have to accept an excessively long recovery time in the worst-case scenario. I take maintenance windows and backups into account from the very beginning.<\/p>\n\n<h2>Practical Solutions for Typical Workloads<\/h2>\n\n<ul>\n  <li>OLTP with many small commits on SSD\/NVMe: O_DIRECT, innodb_flush_log_at_trx_commit=1 or 2 depending on durability, innodb_io_capacity set fairly high, dirty pages set to moderate, Flush-Neighbors=0. Actively use binlog group commit.<\/li>\n  <li>Write-intensive batch import: temporarily increase the dirty page target slightly, boost I\/O capacity, and revert the settings once the process is complete. If durability is acceptable, temporarily set `innodb_flush_log_at_trx_commit=2`.<\/li>\n  <li>Legacy systems based on HDDs: conservative I\/O capacity, Flush-Neighbors=1, innodb_flush_method=fsync or O_DIRECT depending on RAM pressure. Pay special attention to continuous flushing to avoid seek storms.<\/li>\n  <li>Cloud volumes with an IOPS budget: Set `innodb_io_capacity` strictly to the guaranteed limit, avoid bursts, and use `O_DIRECT` to conserve RAM. For credit-based systems (burst I\/O), I use pacing to prevent the budget from being exhausted all at once.<\/li>\n<\/ul>\n\n<h2>Troubleshooting checklist<\/h2>\n\n<ul>\n  <li>Long P95 commit latencies? Check the fsync duration, enable group commit, and, if necessary, reduce the flush frequency (after weighing the risks).<\/li>\n  <li>High variance in the dirty page percentage? Fine-tune io_capacity\/io_capacity_max; check adaptive flushing thresholds.<\/li>\n  <li>Sudden latency spikes during backups? Synchronize backup tool parameters and server values; temporarily adjust the I\/O throttling.<\/li>\n  <li>Is the replica lagging behind? Evaluate the binlog flush strategy, sync frequencies, and network latency together; syncs that are too aggressive slow down the master.<\/li>\n  <li>RAM pressure after switching to O_DIRECT? Re-evaluate the balance between the buffer pool and the OS cache; O_DIRECT reduces the OS cache but may affect the application page cache.<\/li>\n<\/ul>\n\n<h2>Brief summary<\/h2>\n\n<p>I arrange the <strong>Flush Strategy<\/strong> always depends on the hardware and durability goals. O_DIRECT prevents double caching and usually delivers the best results on SSD\/NVMe. The innodb_flush_log_at_trx_commit setting determines the speed per commit and the risk in the event of a power outage. Carefully selected values for dirty pages, I\/O capacity, and flush neighbors keep write rates consistent. By additionally measuring fsync overhead and adhering to cloud limits, you can reliably optimize MariaDB\u2019s performance without sacrificing security.<\/p>","protected":false},"excerpt":{"rendered":"<p>Learn how to optimally configure MariaDB flush methods and `innodb_flush` using `O_DIRECT`, `fsync`, and `innodb_flush_log_at_trx_commit`. This guide provides practical database tuning tips for HDD, SSD, and cloud environments, with a focus on performance and data security.<\/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":"69","_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\/en\/wp-json\/wp\/v2\/posts\/21539","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/comments?post=21539"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/21539\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media\/21532"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media?parent=21539"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/categories?post=21539"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/tags?post=21539"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}