{"id":21119,"date":"2026-08-28T18:18:54","date_gmt":"2026-08-28T16:18:54","guid":{"rendered":"https:\/\/webhosting.de\/mariadb-undo-logs-administrator-guide-technik\/"},"modified":"2026-08-28T18:18:54","modified_gmt":"2026-08-28T16:18:54","slug":"mariadb-undo-logs-administrators-guide-technical","status":"publish","type":"post","link":"https:\/\/webhosting.de\/en\/mariadb-undo-logs-administrator-guide-technik\/","title":{"rendered":"MariaDB Undo Logs: Background Information for Administrators"},"content":{"rendered":"<p><strong>MariaDB Undo<\/strong> controls how InnoDB stores old row versions, performs rollbacks safely, and provides consistent read views while write operations are in progress. I\u2019ll show how undo logs interact with the history list and purge, why long transactions tie up memory, and how I manage the growth of the <strong>Undo<\/strong>-Monitor these areas.<\/p>\n\n<h2>Key points<\/h2>\n\n<ul>\n  <li><strong>MVCC<\/strong> and consistent reads: Undo saves old versions; readers are not blocked.<\/li>\n  <li><strong>History List<\/strong>: Commits add to the history; purge removes entries.<\/li>\n  <li><strong>Long transactions<\/strong>: Runs on older versions, uses more memory, and has higher latencies.<\/li>\n  <li><strong>Configuration<\/strong>: Undo tablespaces, purge threads, and truncate operations control growth.<\/li>\n  <li><strong>Monitoring<\/strong>: Check the history length, transaction age, and undo sizes early on.<\/li>\n<\/ul>\n\n<h2>How Undo Logs Enable MVCC<\/h2>\n\n<p>I'll start with the core: Every change writes the previous version of the line to the <strong>Undo<\/strong>-Log, so that a consistent snapshot remains valid. Readers access the appropriate older version, while writers store new data and update indexes; this ensures that <strong>Parallelism<\/strong> high. Rows chain to their predecessors until `Purge` is allowed to delete them. Without this chain, rollbacks would be missing and read views would fail. This is exactly where `Undo` bridges the gap between transaction safety, isolation, and reliable read access.<\/p>\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\/08\/mariadb-serverraum-admin-5847.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Internal Structure of the Undo Logs<\/h2>\n\n<p>Under the hood, I mainly distinguish between two types of undo operations: <em>Insert-Undo<\/em> and <em>Update Undo<\/em>. Insert-Undo allows you to undo insertions that have not yet been committed. Update-Undo preserves older versions in the event of changes or delete marks so that snapshots continue to function. InnoDB initially marks deleted rows only as removed (Delete Mark) and delays their actual removal until no snapshot can see them anymore. This separation is crucial: rollbacks require precise previous states, while consistent readers must find a version that logically matches their starting point. For this reason, rows internally reference the previous version, and indexes carry additional information so that `Purge` can later cleanly update index entries.<\/p>\n\n<h2>History List, Purge, and Storage<\/h2>\n\n<p>After each commit, historical changes are stored in the global <strong>History<\/strong> A list that the Purge thread processes asynchronously. If Purge can't keep up, this list grows and artificially keeps old row versions alive. This results in more read operations, more I\/O, and larger undo tablespaces. In such situations, I always check isolation levels and open snapshots, because an unfavorable <a href=\"https:\/\/webhosting.de\/en\/mysql-isolation-level-hosting-server-consistency-transactions\/\">Choosing Insulation<\/a> extends the lifespan of older versions. By considering purge rate, history length, and active transactions together, you can identify bottlenecks early and curb memory drift before it becomes critical.<\/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\/08\/mariadb_undo_logs_meeting_2387.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Purge Mechanism and Tuning Options<\/h2>\n\n<p>Purge is running <em>best effort<\/em>: It collects entries from the history list that can be cleaned up, permanently removes delete marks, updates secondary indexes, and frees up undo regions. In systems with a high rate of changes, I scale the <strong>Parallelism<\/strong> (e.g., using multiple Purge workers) and adjust the batching strategy so that Purge runs steadily but not aggressively. Rules of thumb:<\/p>\n<ul>\n  <li>Short, consistent batches instead of infrequent large runs\u2014this smooths out I\/O and checkpoints.<\/li>\n  <li>Don't pit \"purge\" against memory or log flushing: Both approaches need to keep up.<\/li>\n  <li>I'll resolve the long snapshots first before increasing the batch sizes any further\u2014otherwise, the effect will be lost.<\/li>\n<\/ul>\n<p>Important: Purge is not a substitute for good transaction discipline. Even with high concurrency, Undo remains locked as long as old snapshots exist. I therefore monitor both Purge progress and transaction age together, and adjust the workload if Purge consistently lags behind.<\/p>\n\n<h2>Configuring Undo Tablespaces<\/h2>\n\n<p>Depending on the setup, undo information can be stored in the system tablespace or in separate <strong>Undo<\/strong>-tablespaces. I like to isolate the undo log to better control growth and I\/O. Many installations allow for dynamic growth, sometimes including the release of space via TRUNCATE. That sounds convenient, but it increases the need for monitoring because long snapshots prevent rapid shrinkage. I choose the storage location, size, and purge parallelism so that change rates and time windows in day-to-day operations are properly accommodated and <strong>Restoration<\/strong> does not suffer.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Setting<\/th>\n      <th>Effect<\/th>\n      <th>Note<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>innodb_undo_directory<\/td>\n      <td>Location for <strong>Undo<\/strong>-files<\/td>\n      <td>Separate Data Storage Decouples I\/O<\/td>\n    <\/tr>\n    <tr>\n      <td>innodb_purge_threads<\/td>\n      <td>More <strong>Purge<\/strong>-Mining worker<\/td>\n      <td>Increase when the rate of change is high<\/td>\n    <\/tr>\n    <tr>\n      <td>innodb_undo_log_truncate<\/td>\n      <td>Reclaims unused space<\/td>\n      <td>Only effective if \"History\" is empty<\/td>\n    <\/tr>\n    <tr>\n      <td>innodb_max_undo_log_size<\/td>\n      <td>Threshold for growth<\/td>\n      <td>Availability varies by version<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Memory Layout and File System Considerations<\/h2>\n\n<p>I prefer to place separate undo tablespaces on fast SSDs, isolated from data and log I\/O. If the file system supports TRIM\/Discard, a TRUNCATE operation can physically return storage space to the operating system. Nevertheless, I plan using conservative upper limits because space release isn\u2019t guaranteed as long as snapshots bind undo. Compression at the file system level is also only worthwhile if there\u2019s CPU headroom and write patterns don\u2019t cause fragmentation. It remains important to monitor latency spikes: If the Undo stream grows on a heavily loaded disk, write amplification and checkpoint pressure gradually worsen.<\/p>\n\n<h2>Monitoring and diagnosis<\/h2>\n\n<p>I regularly check the size of the <strong>Undo<\/strong>-tablespaces, the history list length, and the age of open transactions. SHOW ENGINE InnoDB STATUS, Performance Schema, and Information Schema provide clear indicators. If undo areas are growing while the purge is not reducing them significantly, I first terminate old sessions. I also check for locks, because unnecessary <a href=\"https:\/\/webhosting.de\/en\/database-row-locking-mysql-concurrency-optimization-performance-locks\/\">Row Locks<\/a> Extend transactions and snapshots. Reviewing these metrics daily helps prevent sudden I\/O spikes and shortens paths in the <strong>Memory<\/strong>.<\/p>\n\n<h2>Performance Implications of Long Transactions<\/h2>\n\n<p>Handling Long Read or Write Transactions <strong>Versions<\/strong> even if they are logically obsolete. This bloats the Undo log, increases scan sizes, and puts more pressure on the cache. I minimize these effects by using shorter batches, consistently committing, and setting session timeouts. Reports that take hours to run perform better in smaller windows or against replicas. By disabling autocommit, streamlining query plans, and closing idle transactions, you free up the purge process and relieve the <strong>Instance<\/strong>.<\/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\/08\/mariadb-undo-logs-insight-4723.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Rollback Segments and Concurrency<\/h2>\n\n<p>Undo entries are stored in <em>Rollback segments<\/em>, which, so to speak, provide slots for concurrently active changes. Many concurrent writers benefit from having sufficient rollback segments, because inserts and updates then have to share their undo chains less frequently. I monitor waiting patterns for rollback resources and increase their number where the version and distribution allow it. Symptoms of insufficient parallelism include unexpected wait times during otherwise short update phases or highly fluctuating write latencies under load. More segments distribute the load, but they do not override the basic rule: Long snapshots trump any amount of tuning.<\/p>\n\n<h2>Insulation Levels in Detail<\/h2>\n\n<p>The <a href=\"https:\/\/webhosting.de\/en\/mysql-isolation-level-hosting-server-consistency-transactions\/\">Isolation Level<\/a> determines how long undo versions remain relevant. In REPEATABLE READ, a transaction maintains its initial snapshot for its entire duration; thus, undo versions can potentially remain locked for a very long time. In READ COMMITTED, view windows are created for each statement; this significantly shortens the lifetime of old versions in many workloads. SELECT \u2026 FOR UPDATE and LOCK IN SHARE MODE acquire locks and alter the concurrency profile\u2014useful for preventing lost updates, but critical for undo if readers remain open for too long. I therefore use READ COMMITTED specifically where reports or API reads require consistent but non-transactional views, and stick with REPEATABLE READ when business logic requires it.<\/p>\n\n<h2>Recovery and Startup Scenarios<\/h2>\n\n<p>When it starts up, InnoDB uses the <strong>Undo<\/strong>-Information needed to cleanly roll back incomplete transactions. This ensures consistent views before new clients begin working. In special cases, there are startup modes that skip checks, but I only use them in emergencies. Simply speeding up the process without diagnostics backfires, because integrity takes priority. Keeping an eye on recovery time and undo sizes helps you make better decisions about maintenance windows and <strong>Risk<\/strong>.<\/p>\n\n<h2>Best Practices for Administration<\/h2>\n\n<p>I keep transactions short, commit frequently, and avoid endless read sessions so that <strong>Purge<\/strong> has free rein. I break down larger bulk changes into carefully sized batches so that the history list doesn't grow. I scale purge threads based on the rate of change and adapt the undo layout to the storage hardware. In addition, I document business processes that require long snapshots and deliberately plan time windows. This keeps undo usage predictable and the <strong>Latency<\/strong> low.<\/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\/08\/mdb_undologs_tech_office_3821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Workload Patterns and Tuning<\/h2>\n\n<p>E-commerce, reporting, and content management systems bring about many changes and require a disciplined approach <strong>Transactions<\/strong>. I set conservative timeouts for readers, optimize indexes for precise updates, and limit batch sizes. When write load is high, I increase purge parallelism and regulate checkpoint pressure. I also check the write rate in relation to <a href=\"https:\/\/webhosting.de\/en\/database-transaction-logs-recovery-processes-database-protection-secure\/\">Transaction Logs and Recovery<\/a>, so that crash recovery remains predictable. This interaction keeps the undo volume predictable and protects the <strong>Consistency<\/strong>.<\/p>\n\n<h2>Backups and Replication<\/h2>\n\n<p>Logical backups with consistent snapshots inevitably extend the lifespan of old versions\u2014the undo log grows until the backup is complete. I schedule such runs outside of peak-load windows, throttle concurrent writers, and ensure sufficient purge capacity. Physical backups can reduce the undo load, but they do not eliminate the need for careful snapshot management. On replicas, I prefer to run reports in READ COMMITTED mode and terminate long-running idle transactions so that SQL Apply does not fall behind. If a replica falls behind, the undo load increases there as well, because catching up on numerous deletes and updates generates a wave of history that the purge process must first work through.<\/p>\n\n<h2>Runbook: Quickly Stop Undo Growth<\/h2>\n\n<ul>\n  <li>Identify active long-running processes: Check for open transactions and sessions with large result sets.<\/li>\n  <li>Consistently terminate idle transactions: Check for autocommit; close any forgotten cursors.<\/li>\n  <li>Increase purge capacity: Activate additional workers and moderately increase batch sizes.<\/li>\n  <li>Smoothing out writer spikes: Limit batch sizes, implement micro-commits.<\/li>\n  <li>Take Advantage of Maintenance Windows: Schedule large-scale deletions and updates during predictable time slots.<\/li>\n  <li>After stabilization: Allow \"Undo-Truncate\" until the filesystem size matches the requirements again.<\/li>\n<\/ul>\n\n<h2>Capacity Planning for Undo<\/h2>\n\n<p>I calculate the undo requirement conservatively based on the change rate, average row size, and maximum snapshot window. A simple approximation: change events per second \u00d7 average payload \u00d7 planned snapshot window in seconds. Include a safety margin for indexes and metadata. This rule of thumb gives you a sense of worst-case requirements and protects against surprises during reporting, backups, or migration runs. <em>at the same time<\/em> Take snapshots. In growing systems, I check quarterly to see if changes in workload (new features, more mobile clients, higher peaks) are affecting demand.<\/p>\n\n<h2>Special Cases: Temporary Tables and DDL<\/h2>\n\n<p>Temporary InnoDB tables use their own areas; changes to them place less of a burden on the regular undo log, but can still generate I\/O during large sorts or joins. DDL operations such as ALTER TABLE often generate massive waves of changes\u2014I break them down into incremental steps as needed and schedule them during quiet periods. Here, too, the rule applies: Short, clean transactions are better than risky shortcuts. If a DDL run aborts, Undo helps restore the system to a consistent state; however, this requires sufficient memory and time, which I plan for in advance.<\/p>\n\n<h2>Example: Measuring Impact<\/h2>\n\n<p>I'll start with a baseline snapshot of the undo size, which <strong>History<\/strong>-length and the average transaction duration. I then make targeted changes, such as increasing the number of purge threads or reducing batch sizes. I then compare the metrics until undo growth and latencies settle into a healthy balance. If I encounter outliers, I examine query plans and session lists to identify stuck readers. This iterative process delivers quick results without <strong>Availability<\/strong> to jeopardize.<\/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\/08\/mariadb_undo_logs_9876.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Common Misconceptions<\/h2>\n\n<p>A commit does not immediately delete old versions; <strong>Purge<\/strong> Decide later. Truncate options do not solve a fundamental design problem when transactions live too long. Large undo files do not necessarily indicate corruption; often, a single session is causing the blockage. While readers rarely block writers, inappropriate queries indirectly prolong the duration of snapshots. Those who correct these errors make better decisions and reduce <strong>Downtimes<\/strong>.<\/p>\n\n<h2>Summary for those in a hurry<\/h2>\n\n<p>Maintain undo logs <strong>Past<\/strong> tangible, so that InnoDB safely rolls back transactions and readers see consistent views. I control growth by streamlining transactions, configuring purge threads appropriately, and strategically placing undo tablespaces. Monitoring the history length, undo sizes, and transaction ages reveals trends early on. When anomalies arise, I examine workload, locks, and sessions rather than just addressing the symptoms. Those who maintain this routine ensure performance, consistency, and <strong>restart<\/strong> reliably under control.<\/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\/08\/mariadb-undo-logs-4982.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>","protected":false},"excerpt":{"rendered":"<p>MariaDB Undo Logs Explained: InnoDB Internals, Rollback, MVCC, and Admin Tips for Performance and Stability.<\/p>","protected":false},"author":1,"featured_media":21112,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-21119","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":"144","_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 Undo","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":"21112","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/21119","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=21119"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/21119\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media\/21112"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media?parent=21119"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/categories?post=21119"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/tags?post=21119"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}