{"id":21633,"date":"2026-09-21T22:06:16","date_gmt":"2026-09-21T20:06:16","guid":{"rendered":"https:\/\/webhosting.de\/?p=21633"},"modified":"2026-09-21T22:06:19","modified_gmt":"2026-09-21T20:06:19","slug":"understanding-the-redis-replication-backlog","status":"publish","type":"post","link":"https:\/\/webhosting.de\/en\/redis-replication-backlog-verstehen\/","title":{"rendered":"Understanding the Redis Replication Backlog: PSYNC, Size, and HA Limits"},"content":{"rendered":"<div class=\"wh-article wh-editorial-21633\" data-editorial-words=\"2240\" style=\"max-width:820px;margin:0 auto;color:#243447;font-size:19px;line-height:1.8;overflow-wrap:anywhere;\"><p class=\"wh-lead\" style=\"margin:0 0 25px;font-size:21px;line-height:1.75;color:#243447;\">The <strong style=\"font-weight:700;color:#153e50;\">Redis Replication Backlog<\/strong> helps determine whether, after a connection failure, a replica will only retrieve missing changes or receive the entire dataset again. By sizing the buffer based on the actual replication volume, you can avoid unnecessary full synchronizations. However, this also requires that the replication history, storage budget, and operational workflows align: A large backlog is no substitute for persistence or a robust failover strategy. <\/p><nav aria-label=\"Contents of this article\" class=\"wh-toc\" style=\"margin:30px 0 42px;padding:24px;border:1px solid #dbe5eb;border-radius:18px;background:#f5f9fb;box-shadow:0 8px 24px rgba(15,35,55,.06);\"><p style=\"margin:0 0 14px;font-size:13px;font-weight:700;letter-spacing:.08em;text-transform:uppercase;color:#426477;\">Go directly to the section<\/p><div style=\"display:flex;flex-wrap:wrap;gap:10px;\"><a href=\"#grundprinzip\" style=\"display:block;flex:1 1 235px;min-width:0;padding:12px 15px;border:1px solid #d5e3e8;border-radius:10px;background:#fff;color:#174a60;text-decoration:none;font-size:15px;font-weight:600;line-height:1.45;\">What the Backlog Actually Stores<\/a>\n<a href=\"#psync\" style=\"display:block;flex:1 1 235px;min-width:0;padding:12px 15px;border:1px solid #d5e3e8;border-radius:10px;background:#fff;color:#174a60;text-decoration:none;font-size:15px;font-weight:600;line-height:1.45;\">When PSYNC Is Sufficient and When a Full Resync Is Necessary<\/a>\n<a href=\"#replikationsrate\" style=\"display:block;flex:1 1 235px;min-width:0;padding:12px 15px;border:1px solid #d5e3e8;border-radius:10px;background:#fff;color:#174a60;text-decoration:none;font-size:15px;font-weight:600;line-height:1.45;\">Measure the replication rate instead of estimating the database size<\/a>\n<a href=\"#dimensionierung\" style=\"display:block;flex:1 1 235px;min-width:0;padding:12px 15px;border:1px solid #d5e3e8;border-radius:10px;background:#fff;color:#174a60;text-decoration:none;font-size:15px;font-weight:600;line-height:1.45;\">Calculate the backlog size in a transparent manner<\/a>\n<a href=\"#konfiguration\" style=\"display:block;flex:1 1 235px;min-width:0;padding:12px 15px;border:1px solid #d5e3e8;border-radius:10px;background:#fff;color:#174a60;text-decoration:none;font-size:15px;font-weight:600;line-height:1.45;\">How to Change Redis Configuration in a Clear and Controlled Way<\/a>\n<a href=\"#monitoring\" style=\"display:block;flex:1 1 235px;min-width:0;padding:12px 15px;border:1px solid #d5e3e8;border-radius:10px;background:#fff;color:#174a60;text-decoration:none;font-size:15px;font-weight:600;line-height:1.45;\">Monitoring: Which Values Go Together<\/a>\n<a href=\"#speicherbudget\" style=\"display:block;flex:1 1 235px;min-width:0;padding:12px 15px;border:1px solid #d5e3e8;border-radius:10px;background:#fff;color:#174a60;text-decoration:none;font-size:15px;font-weight:600;line-height:1.45;\">Understanding Storage Budgets and Slow Replicas<\/a>\n<a href=\"#hochverfuegbarkeit\" style=\"display:block;flex:1 1 235px;min-width:0;padding:12px 15px;border:1px solid #d5e3e8;border-radius:10px;background:#fff;color:#174a60;text-decoration:none;font-size:15px;font-weight:600;line-height:1.45;\">Why a large backlog does not guarantee high availability<\/a>\n<a href=\"#praxis\" style=\"display:block;flex:1 1 235px;min-width:0;padding:12px 15px;border:1px solid #d5e3e8;border-radius:10px;background:#fff;color:#174a60;text-decoration:none;font-size:15px;font-weight:600;line-height:1.45;\">Test changes and narrow down recurring issues<\/a><\/div><\/nav><h2 id=\"grundprinzip\" style=\"margin:44px 0 18px;color:#132a3b;font-size:28px;line-height:1.3;letter-spacing:-.02em;scroll-margin-top:110px;\">What the Backlog Actually Stores<\/h2><p style=\"margin:0 0 22px;\">At <strong style=\"font-weight:700;color:#153e50;\">Redis Replication<\/strong> The primary processes changes to the data set and transmits a continuous stream of commands to its replicas. This includes not only values written directly by clients; expired or overwritten keys can also trigger changes that must be propagated. The backlog keeps a limited, recent subset of this replication stream in memory. Therefore, it does not contain an additional complete copy of the database, nor is it an archive of write operations of any age. <\/p><p style=\"margin:0 0 22px;\">During normal operation, the replicas follow the current data stream. If a connection is interrupted, the history on the primary continues to grow. After reconnection, the replica attempts to resume from where it left off. The key factor here is whether the required bytes are still available. If that is the case and the replication history matches, Redis can fill in the gap. The data already present on the replica does not need to be completely replaced for this to happen. <\/p><p style=\"margin:0 0 22px;\">The benefits are particularly evident during brief network outages, connection switches, and scheduled maintenance. A full synchronization of a large dataset consumes transmission capacity and computing power; depending on the configuration, additional storage and media loads may also arise. The backlog can reduce this effort, but it cannot account for every type of interruption. A process restart or a changed history requires a different approach than a briefly disconnected TCP connection. <\/p><h2 id=\"psync\" style=\"margin:44px 0 18px;color:#132a3b;font-size:28px;line-height:1.3;letter-spacing:-.02em;scroll-margin-top:110px;\">When PSYNC Is Sufficient and When a Full Resync Is Necessary<\/h2><p style=\"margin:0 0 22px;\">A <strong style=\"font-weight:700;color:#153e50;\">Partial resynchronization with PSYNC<\/strong> requires two related pieces of information: the replication ID and the offset. The ID identifies a specific data history. The offset describes a byte position within the replication stream. Therefore, two offsets of the same size from different histories are not automatically comparable. Conversely, a small backlog within the same history may already lie outside the available backlog if its capacity is limited.  <\/p><p style=\"margin:0 0 22px;\">Simply put, when the Replica reconnects, it reports how far it has progressed. The Primary checks whether it can provide the data needed next. If the history is unknown or the required section is missing, a <strong style=\"font-weight:700;color:#153e50;\">Full Resync<\/strong> required. In this process, the replica receives a complete dataset and then the changes that occurred during the synchronization. Depending on the configuration, the transfer can take place with or without an intermediate RDB step to a storage medium.  <\/p><p style=\"margin:0 0 22px;\">After a failover, a full resync is not always unavoidable. A promoted replica can also retain the previous replication ID and its valid offset range. This allows additional replicas to resume from the known history under the right conditions. However, this does not provide any guarantee for planning purposes: The relevant range must still be available, and the actual reconnection must match the stored IDs.  <\/p><div aria-label=\"Reconnecting a Replica: Possible Outcomes\" class=\"wh-table-scroll\" role=\"region\" style=\"margin:30px 0 36px;overflow-x:auto;border:1px solid #dce5eb;border-radius:16px;box-shadow:0 12px 30px rgba(22,43,61,.09);background:#fff;\" tabindex=\"0\"><table style=\"width:100%;min-width:620px;border-collapse:collapse;margin:0;font-size:15px;line-height:1.65;\"><caption style=\"padding:18px 22px;text-align:left;font-size:16px;font-weight:700;color:#163649;background:#eef5f8;\">Reconnecting a Replica: Possible Outcomes<\/caption><thead><tr><th scope=\"col\" style=\"padding:16px 20px;text-align:left;background:#163648;color:#fff;border:0;font-size:14px;font-weight:650;\">Situation<\/th><th scope=\"col\" style=\"padding:16px 20px;text-align:left;background:#163648;color:#fff;border:0;font-size:14px;font-weight:650;\">Prerequisite<\/th><th scope=\"col\" style=\"padding:16px 20px;text-align:left;background:#163648;color:#fff;border:0;font-size:14px;font-weight:650;\">Result<\/th><\/tr><\/thead><tbody><tr><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">A brief interruption<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">Matching history; required bytes still available<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">PSYNC can only make up for the missing replication data.<\/td><\/tr><tr><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">Oldest required bytes overwritten<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">The requested range is outside the available history<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">A complete recalibration instead of a partial resumption.<\/td><\/tr><tr><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">Unknown replication history<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">The replication ID is not recognized as valid<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">A larger backlog alone won't solve the problem.<\/td><\/tr><tr><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">Failover with a Known Predecessor ID<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">Stored secondary ID, valid offset range, and sufficient history<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">Partial resynchronization may still be possible.<\/td><\/tr><tr><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">Backlog released after all replicas were separated<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">TTL has expired; no usable history remains<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">Reconnecting at a later time requires a full synchronization.<\/td><\/tr><\/tbody><\/table><\/div><figure class=\"wh-figure wp-block-image size-large\" style=\"margin:32px 0 40px;\"><img loading=\"lazy\" alt=\"A limited window in the data stream shows which missing replication data is still available after an interruption.\" class=\"wp-image-21638\" decoding=\"async\" height=\"1024\" sizes=\"auto, (max-width: 820px) 100vw, 820px\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/redis-psync-historienfenster-21633.webp\" srcset=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/redis-psync-historienfenster-21633-300x200.webp 300w, https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/redis-psync-historienfenster-21633-768x512.webp 768w, https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/redis-psync-historienfenster-21633-1024x683.webp 1024w, https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/redis-psync-historienfenster-21633.webp 1536w\" style=\"display:block;width:100%;height:auto;border-radius:16px;border:1px solid #e1e8ed;box-shadow:0 12px 30px rgba(23,43,62,.09);\" width=\"1536\"\/><figcaption style=\"margin-top:12px;font-size:14px;line-height:1.6;color:#607381;\">Schematic illustration: PSYNC can only connect to a compatible replication history that is still available.<\/figcaption><\/figure><h2 id=\"replikationsrate\" style=\"margin:44px 0 18px;color:#132a3b;font-size:28px;line-height:1.3;letter-spacing:-.02em;scroll-margin-top:110px;\">Measure the replication rate instead of estimating the database size<\/h2><p style=\"margin:0 0 22px;\">The sheer size of the dataset is enough to <strong style=\"font-weight:700;color:#153e50;\">Backlog Sizing<\/strong> That's not the case. A large database that is primarily read-intensive can generate very little replication traffic. In contrast, a small cache with frequently changing values and many expiration events can continuously transfer significant amounts of data. Even a fixed number of operations per second does not adequately describe the required storage: small key changes and large value overwrites do not result in the same number of bytes.  <\/p><p style=\"margin:0 0 22px;\">A practical approximation can be derived from the rate of increase over time of <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">master_repl_offset<\/code>. Record the value twice on the same primary and divide the difference by the number of seconds that have elapsed. Be sure to check the replication ID as well. After a role change or a restart, do not simply subtract two unrelated measurement points from each other. Furthermore, a single measurement interval provides only an average rate within that interval, not a permanently guaranteed upper limit.  <\/p><p style=\"margin:0 0 22px;\">The following query reads diagnostic information. It does not modify any Redis configuration. Run it with the connection and authentication options required for your environment. The call shown below uses the default connection from <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">redis-cli<\/code>; a different host, port, or TLS connection must be explicitly configured.  <\/p><div class=\"wh-code-window\" data-no-translation=\"\" style=\"margin:26px 0 30px;border:1px solid #233c4e;border-radius:14px;overflow:hidden;background:#132432;box-shadow:0 12px 26px rgba(10,25,38,.14);\"><div data-no-translation=\"\" style=\"padding:11px 18px;background:#1e3546;color:#dcecf4;font-size:13px;font-weight:600;letter-spacing:.02em;\">Terminal &#183; Replikationsstatus lesen<\/div><pre class=\"EnlighterJSRAW\" data-enlighter-language=\"shell\" data-enlighter-linenumbers=\"false\" data-enlighter-theme=\"enlighter\" data-enlighter-title=\"Terminal &#183; Replikationsstatus lesen\" data-no-translation=\"\" style=\"margin:0;padding:20px 22px;overflow-x:auto;white-space:pre;color:#e2edf5;background:#132432;font-size:14px;line-height:1.8;tab-size:4;\">redis-cli INFO replication<\/pre><\/div><p style=\"margin:0 0 22px;\">Monitor across different load phases, such as during normal daily operations, during imports, and during major cache refreshes. Document both typical rates and brief spikes. If many changes occur due to expiring keys, the internal article provides further insight into this topic. <a href=\"https:\/\/webhosting.de\/en\/analyze-and-optimize-redis-key-expiration-and-cache-performance\/\">Analyzing Redis Key Expiration<\/a>. This connection is important for planning because not every relevant writing prompt arises directly from a new user request.  <\/p><h2 id=\"dimensionierung\" style=\"margin:44px 0 18px;color:#132a3b;font-size:28px;line-height:1.3;letter-spacing:-.02em;scroll-margin-top:110px;\">Calculate the backlog size in a transparent manner<\/h2><p style=\"margin:0 0 22px;\">As <strong style=\"font-weight:700;color:#153e50;\">Planning Approximation<\/strong> You can multiply the relevant replication rate by the duration of the interruption to be bridged and then add a reasonable buffer. The duration should not only account for the actual network outage. Detection, reconnection attempts, and restoring the connection path can also take time. What constitutes an appropriate buffer depends on observed fluctuations and the desired operational goal, not on a universal percentage. <\/p><p style=\"margin:0 0 22px;\">Here is a deliberately simplified calculation example: For a given load phase, assume 12 MiB per second. The connection could be down for 90 seconds; an additional 30 seconds are factored in as a time buffer. This results in <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">12 MiB\/s &#215; 120 s = 1.440 MiB<\/code>, or about 1.41 GiB. These numbers are estimates provided for illustrative purposes only and do not represent a Redis benchmark. Before deploying in production, they must be replaced with actual measurements from your application. <\/p><figure class=\"wh-chart\"><figcaption>Backlog requirement assuming 12 MiB\/s<\/figcaption><p class=\"wh-chart-unit\" style=\"margin:0 0 22px;\">MiB<\/p><div class=\"wh-chart-bars\"><div class=\"wh-chart-row\"><span class=\"wh-chart-label\">30 seconds<\/span><span aria-hidden=\"true\" class=\"wh-chart-track\"><span class=\"wh-chart-bar\" style=\"width:16.6667%\"><\/span><\/span><span class=\"wh-chart-number\">360<\/span><\/div><div class=\"wh-chart-row\"><span class=\"wh-chart-label\">60 seconds<\/span><span aria-hidden=\"true\" class=\"wh-chart-track\"><span class=\"wh-chart-bar\" style=\"width:33.3333%\"><\/span><\/span><span class=\"wh-chart-number\">720<\/span><\/div><div class=\"wh-chart-row\"><span class=\"wh-chart-label\">120 seconds<\/span><span aria-hidden=\"true\" class=\"wh-chart-track\"><span class=\"wh-chart-bar\" style=\"width:66.6667%\"><\/span><\/span><span class=\"wh-chart-number\">1440<\/span><\/div><div class=\"wh-chart-row\"><span class=\"wh-chart-label\">180 seconds<\/span><span aria-hidden=\"true\" class=\"wh-chart-track\"><span class=\"wh-chart-bar\" style=\"width:100.0000%\"><\/span><\/span><span class=\"wh-chart-number\">2160<\/span><\/div><\/div><p style=\"margin:0 0 22px;\">Illustrative calculation example, not a measurement: Requirement = assumed 12 MiB\/s \u00d7 selected total duration. The 120 seconds in the text example include 90 seconds of downtime and 30 seconds of buffer time. No additional buffers are included here.<\/p><details><summary>Data Table for the Chart<\/summary><table><thead><tr><th scope=\"col\">Entry<\/th><th scope=\"col\">MiB<\/th><\/tr><\/thead><tbody><tr><td>30 seconds<\/td><td>360<\/td><\/tr><tr><td>60 seconds<\/td><td>720<\/td><\/tr><tr><td>120 seconds<\/td><td>1440<\/td><\/tr><tr><td>180 seconds<\/td><td>2160<\/td><\/tr><\/tbody><\/table><\/details><\/figure><p style=\"margin:0 0 22px;\">The reverse calculation helps in assessing an existing buffer. A fully filled backlog of 256 MiB corresponds, at a constant rate of 12 MiB per second, to approximately 21 seconds of history. At 2 MiB per second, it would be approximately 128 seconds. In a real-world application, however, the rates fluctuate. Such a range is therefore a snapshot and does not guarantee that every disruption of this duration can be partially synchronized. <\/p><figure class=\"wh-figure wp-block-image size-large\" style=\"margin:32px 0 40px;\"><img loading=\"lazy\" alt=\"Two history windows of equal size, with data streams of different densities, illustrate the impact of the replication rate.\" class=\"wp-image-21639\" decoding=\"async\" height=\"1024\" sizes=\"auto, (max-width: 820px) 100vw, 820px\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/redis-backlog-replikationsrate-reichweite-21633.webp\" srcset=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/redis-backlog-replikationsrate-reichweite-21633-300x200.webp 300w, https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/redis-backlog-replikationsrate-reichweite-21633-768x512.webp 768w, https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/redis-backlog-replikationsrate-reichweite-21633-1024x683.webp 1024w, https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/redis-backlog-replikationsrate-reichweite-21633.webp 1536w\" style=\"display:block;width:100%;height:auto;border-radius:16px;border:1px solid #e1e8ed;box-shadow:0 12px 30px rgba(23,43,62,.09);\" width=\"1536\"\/><figcaption style=\"margin-top:12px;font-size:14px;line-height:1.6;color:#607381;\">Conceptual illustration: For the same buffer size, a larger replication stream reduces the temporal reach.<\/figcaption><\/figure><p style=\"margin:0 0 22px;\">Also check whether the replica can catch up faster after reconnecting than new changes occur. Increasing the history does not resolve a persistently slow network or a persistently overloaded receiver. If the backlog persists or continues to grow, the cause must be investigated. Otherwise, simply allocating more storage will merely postpone the problem and may put the entire system under storage pressure. <\/p><h2 id=\"konfiguration\" style=\"margin:44px 0 18px;color:#132a3b;font-size:28px;line-height:1.3;letter-spacing:-.02em;scroll-margin-top:110px;\">How to Change Redis Configuration in a Clear and Controlled Way<\/h2><p style=\"margin:0 0 22px;\">The Parameters <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">repl-backlog-size<\/code> and <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">repl-backlog-ttl<\/code> control different things. The first describes the intended backlog size. The second determines, on the primary, after how long without connected replicas the backlog can be released. It is <strong style=\"font-weight:700;color:#153e50;\">No maximum interruption duration for PSYNC<\/strong>. As long as the buffer is overwritten or some other requirement is not met, a long TTL alone is not enough.   <\/p><p style=\"margin:0 0 22px;\">The following lines are commented-out defaults from the Redis 7.2.0 configuration template. The comment characters have been intentionally left in place. Simply copying these lines will not enable any settings; furthermore, the values listed are not general capacity recommendations for production systems.   <\/p><div class=\"wh-code-window\" data-no-translation=\"\" style=\"margin:26px 0 30px;border:1px solid #233c4e;border-radius:14px;overflow:hidden;background:#132432;box-shadow:0 12px 26px rgba(10,25,38,.14);\"><div data-no-translation=\"\" style=\"padding:11px 18px;background:#1e3546;color:#dcecf4;font-size:13px;font-weight:600;letter-spacing:.02em;\">redis.conf &#183; auskommentierte Vorlage<\/div><pre class=\"EnlighterJSRAW\" data-enlighter-language=\"generic\" data-enlighter-linenumbers=\"false\" data-enlighter-theme=\"enlighter\" data-enlighter-title=\"redis.conf &#183; auskommentierte Vorlage\" data-no-translation=\"\" style=\"margin:0;padding:20px 22px;overflow-x:auto;white-space:pre;color:#e2edf5;background:#132432;font-size:14px;line-height:1.8;tab-size:4;\"># Redis 7.2.0: auskommentierte Vorgaben aus redis.conf\n# repl-backlog-size 1mb\n# repl-backlog-ttl 3600<\/pre><\/div><p style=\"margin:0 0 22px;\">With <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">repl-backlog-ttl 0<\/code> Time-controlled release is disabled after all replicas have been disconnected. This does not preserve an unlimited history: The existing buffer can still be overwritten by new replication data. Furthermore, this does not ensure persistence across arbitrary process restarts. Therefore, carefully evaluate whether the additional memory consumption is appropriate given the expected reconnection behavior.   <\/p><p style=\"margin:0 0 22px;\">Before making a change, you should check the actual values in effect and clarify the deployment process. A container environment variable, a managed configuration file, and a setting changed at runtime are not the same thing. If an instance is recreated later, only the adjustments made at runtime may be lost. The following queries are read-only; however, they still require the appropriate access permissions.   <\/p><div class=\"wh-code-window\" data-no-translation=\"\" style=\"margin:26px 0 30px;border:1px solid #233c4e;border-radius:14px;overflow:hidden;background:#132432;box-shadow:0 12px 26px rgba(10,25,38,.14);\"><div data-no-translation=\"\" style=\"padding:11px 18px;background:#1e3546;color:#dcecf4;font-size:13px;font-weight:600;letter-spacing:.02em;\">Terminal &#183; aktive Einstellungen abfragen<\/div><pre class=\"EnlighterJSRAW\" data-enlighter-language=\"shell\" data-enlighter-linenumbers=\"false\" data-enlighter-theme=\"enlighter\" data-enlighter-title=\"Terminal &#183; aktive Einstellungen abfragen\" data-no-translation=\"\" style=\"margin:0;padding:20px 22px;overflow-x:auto;white-space:pre;color:#e2edf5;background:#132432;font-size:14px;line-height:1.8;tab-size:4;\">redis-cli CONFIG GET repl-backlog-size\nredis-cli CONFIG GET repl-backlog-ttl<\/pre><\/div><p style=\"margin:0 0 22px;\">With Managed Redis, the provider can restrict access to <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">CONFIG<\/code> restrict or manage settings through a dedicated interface. This is not a reason to bypass security measures. In that case, use the approved management channels and document the selected size along with the underlying replication volume. The change plan should also include the previous values and a realistic fallback plan.   <\/p><h2 id=\"monitoring\" style=\"margin:44px 0 18px;color:#132a3b;font-size:28px;line-height:1.3;letter-spacing:-.02em;scroll-margin-top:110px;\">Monitoring: Which Values Go Together<\/h2><p style=\"margin:0 0 22px;\">For the <strong style=\"font-weight:700;color:#153e50;\">Monitoring Redis Replication<\/strong> A single green connection status is not enough. A link may be reconnected while the replica is still catching up or is in the process of loading a complete data set. Conversely, a brief connection interruption does not necessarily have to be critical if the history and catch-up capacity are sufficient. Therefore, evaluate the connection, synchronization status, offset trend, and available history together. <\/p><div aria-label=\"Redis Monitoring: Interpreting Values in Context\" class=\"wh-table-scroll\" role=\"region\" style=\"margin:30px 0 36px;overflow-x:auto;border:1px solid #dce5eb;border-radius:16px;box-shadow:0 12px 30px rgba(22,43,61,.09);background:#fff;\" tabindex=\"0\"><table style=\"width:100%;min-width:620px;border-collapse:collapse;margin:0;font-size:15px;line-height:1.65;\"><caption style=\"padding:18px 22px;text-align:left;font-size:16px;font-weight:700;color:#163649;background:#eef5f8;\">Redis Monitoring: Interpreting Values in Context<\/caption><thead><tr><th scope=\"col\" style=\"padding:16px 20px;text-align:left;background:#163648;color:#fff;border:0;font-size:14px;font-weight:650;\">Field<\/th><th scope=\"col\" style=\"padding:16px 20px;text-align:left;background:#163648;color:#fff;border:0;font-size:14px;font-weight:650;\">Meaning<\/th><th scope=\"col\" style=\"padding:16px 20px;text-align:left;background:#163648;color:#fff;border:0;font-size:14px;font-weight:650;\">What to Look For<\/th><\/tr><\/thead><tbody><tr><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">master_replid \/ master_repl_offset<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">History ID and current byte offset on the primary<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">Compare data points only within the same history.<\/td><\/tr><tr><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">repl_backlog_active<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">Whether the replication backlog is currently active<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">A configured value alone does not mean that historical data is available.<\/td><\/tr><tr><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">repl_backlog_first_byte_offset<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">Offset of the first byte still stored<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">The data required for the replica must fit within the available space.<\/td><\/tr><tr><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">repl_backlog_histlen \/ repl_backlog_size<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">Existing history length and configured size<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">A newly created buffer does not have to be completely filled yet.<\/td><\/tr><tr><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">master_link_status \/ master_sync_in_progress<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">Connection and Ongoing Synchronization from the Replica's Perspective<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">The mere fact that a link is available again does not in itself prove that the comparison has been completed.<\/td><\/tr><tr><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">slave_repl_offset<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">Replication Progress on a Replica<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">Take note of the timeline and the related history.<\/td><\/tr><\/tbody><\/table><\/div><p style=\"margin:0 0 22px;\">The fields of a <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">INFO<\/code>-Responses may vary between Redis versions and between primary and replica nodes. Therefore, any evaluation should explicitly handle missing fields rather than silently interpreting them as null or as an error-free state. The labels <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">master<\/code> and <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">slave<\/code> For compatibility reasons, they continue to appear in field names; they must not be freely translated in the executable code. <\/p><p style=\"margin:0 0 22px;\">The internal guidelines are used to interpret the backlog <a href=\"https:\/\/webhosting.de\/en\/redis-replication-offset-analysis-data-consistency-cluster\/\">Analyzing the Redis Replication Offset<\/a> a useful addition. In your ongoing monitoring, you should look at historical trends, not just two manually recorded numbers. A widening gap requires a different response than a gap that is steadily narrowing after a brief outage. <\/p><p style=\"margin:0 0 22px;\">Meaningful alerts are based on your operational goals: How long can a replica remain unreachable? How quickly must it catch up? What frequency of full synchronizations is considered unusual? Rigid thresholds that don\u2019t take load profiles and data volumes into account often lead to unnecessary alerts or fail to detect actual performance degradation. In addition to replication metrics, keep an eye on RAM usage, network utilization, and indications of process restarts. <\/p><h2 id=\"speicherbudget\" style=\"margin:44px 0 18px;color:#132a3b;font-size:28px;line-height:1.3;letter-spacing:-.02em;scroll-margin-top:110px;\">Understanding Storage Budgets and Slow Replicas<\/h2><p style=\"margin:0 0 22px;\">The backlog is only part of the overall <strong style=\"font-weight:700;color:#153e50;\">Redis Storage Requirements<\/strong>. In addition, there are data sets, administrative structures, client buffers, and\u2014depending on the operational state\u2014additional memory during persistence or synchronization operations. Therefore, do not allocate the entire available RAM for user data plus a precisely calculated backlog. The necessary reserve must be determined based on the specific environment and the peak loads that occur there.  <\/p><p style=\"margin:0 0 22px;\">Since Redis 7.0, the replica buffer and replication backlog share memory. The INFO documentation therefore notes, among other things, that <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">mem_clients_slaves<\/code> can be zero if the replica buffers do not exceed the backlog allocation. This does not mean, however, that replication does not consume memory. Consider the values specified for this purpose, such as <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">mem_replication_backlog<\/code> and <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">mem_total_replication_buffers<\/code> Keep the context in mind and don't blindly add overlapping quantities.  <\/p><p style=\"margin:0 0 22px;\">A common diagnostic mistake is to assume that every failed synchronization is caused by a large backlog. Slow replicas, limited network bandwidth, or exceeded output buffer limits may have other causes. The parameter <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">client-output-buffer-limit replica<\/code> applies to the client class in question and must not be confused with <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">repl-backlog-size<\/code> be treated as equivalent. Before changing limits, review logs, version documentation, and the expected impact on other connections.  <\/p><h2 id=\"hochverfuegbarkeit\" style=\"margin:44px 0 18px;color:#132a3b;font-size:28px;line-height:1.3;letter-spacing:-.02em;scroll-margin-top:110px;\">Why a large backlog does not guarantee high availability<\/h2><p style=\"margin:0 0 22px;\">The backlog improves reconnection but does not make the default asynchronous replication lossless. A primary may have already acknowledged a write operation to the client before a replica has processed it. If the primary fails during this period, the operation in question may not be present on the replacement system selected later. The buffer size alone does not eliminate this <strong style=\"font-weight:700;color:#153e50;\">Risk of Data Loss During Failover<\/strong> not.   <\/p><p style=\"margin:0 0 22px;\">Also <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">WAIT<\/code> does not transform a Redis topology into a system with guaranteed strong consistency. The command can wait for acknowledgments from replicas; actual data safety continues to depend on other factors, particularly persistence and failover behavior. Similarly, <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">min-replicas-to-write<\/code> and <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">min-replicas-max-lag<\/code> under their respective conditions, accept new write operations without automatically and permanently saving each individual operation across multiple instances.   <\/p><aside class=\"wh-callout wh-callout-warning\" style=\"margin:28px 0;padding:24px 27px;background:#fff7eb;border:1px solid #ecd7b6;border-left:4px solid #bd8738;border-radius:12px;box-shadow:0 5px 18px rgba(45,36,20,.05);\"><p class=\"wh-callout-title\" style=\"margin:0 0 22px;\">Replication is not a backup<\/p><p style=\"margin:0 0 22px;\">If a primary instance restarts automatically with an empty dataset and no persistence, its replicas may inherit this empty state. A large backlog does not prevent this scenario. Therefore, ensure that restart, persistence, and recovery are handled together; a replica alone is not a substitute for an independently usable data backup.  <\/p><\/aside><p style=\"margin:0 0 22px;\">For <strong style=\"font-weight:700;color:#153e50;\">High Availability<\/strong> You therefore need a comprehensive plan that addresses the following: acceptable data loss, permissible downtime, persistence, fault detection, selection of the new primary, and recovery. Sentinel or Redis Cluster can handle tasks other than those of the backlog. Simply increasing the size of a buffer while leaving all other assumptions unchanged does not result in a robust recovery plan.   <\/p><h2 id=\"praxis\" style=\"margin:44px 0 18px;color:#132a3b;font-size:28px;line-height:1.3;letter-spacing:-.02em;scroll-margin-top:110px;\">Test changes and narrow down recurring issues<\/h2><p style=\"margin:0 0 22px;\">Start a controlled test in an isolated environment with a comparable Redis version and a predictable write load. Before the interruption, record the replication IDs, offsets, backlog, and memory usage. Then simulate a limited connection interruption without making any unchecked changes to production firewalls or processes. After reconnection, observe whether partial or complete synchronization occurs and how long it takes to catch up.  <\/p><p style=\"margin:0 0 22px;\">For each test, change only one relevant variable at a time, if possible. If the backlog, write load, and network conditions all change at the same time, it becomes nearly impossible to pinpoint the cause of the effect. Repeat the test with different interruption durations and different load phases. This way, a single successful reconnection can be used to form a reliable assessment of the system\u2019s behavior. The observed limits should be documented, without inferring from them a guarantee for every future disruption.  <\/p><p style=\"margin:0 0 22px;\">If full resyncs occur repeatedly, first check whether the history is compatible at all. Next, check the remaining bytes, the time without a replica, indications of restarts, and the actual catch-up speed. A buffer that is too small is a possible cause, but not the only one. It is particularly important to distinguish between a single, prolonged gap and a replica that consistently falls behind, even when a connection is active.  <\/p><p style=\"margin:0 0 22px;\">Ultimately, the correct configuration is the one that covers your defined downtime window under realistic load conditions while leaving enough memory for the rest of the operation. Keep a record of the measurement basis, configuration source, and test date together. After major changes to write behavior, topology, or the Redis version, the sizing should be reevaluated. This ensures that the backlog remains a well-founded operational decision rather than a figure adopted once and for all.  <\/p><section class=\"wh-sources\" style=\"margin-top:50px;padding-top:25px;border-top:1px solid #dce6eb;font-size:14px;color:#607381;\"><h2>Sources and Current State of Knowledge<\/h2><p style=\"margin:0 0 22px;\">Status of the research: <time datetime=\"2026-09-21\">2026-09-21<\/time><\/p><p style=\"margin:0 0 22px;\">Configuration examples are based on the stable Redis tag 7.2.0, not on the \"unstable\" development branch. According to the INFO documentation, the shared memory allocation described here applies starting with Redis 7.0. The general mechanisms refer to Redis Open Source; no Redis software or cloud default values are carried over. Documentation last updated: September 21, 2026. No Redis lab tests were conducted in-house.<\/p><div class=\"wh-source-lines\" style=\"display:grid;gap:8px;\"><span class=\"wh-source-url\" data-no-translation=\"\" dir=\"ltr\" style=\"display:block;overflow-wrap:anywhere;font-size:12px;line-height:1.55;color:#627583;\">https:\/\/redis.io\/docs\/latest\/operate\/oss_and_stack\/management\/replication\/<\/span><span class=\"wh-source-url\" data-no-translation=\"\" dir=\"ltr\" style=\"display:block;overflow-wrap:anywhere;font-size:12px;line-height:1.55;color:#627583;\">https:\/\/redis.io\/docs\/latest\/commands\/psync\/<\/span><span class=\"wh-source-url\" data-no-translation=\"\" dir=\"ltr\" style=\"display:block;overflow-wrap:anywhere;font-size:12px;line-height:1.55;color:#627583;\">https:\/\/raw.githubusercontent.com\/redis\/redis\/7.2.0\/redis.conf<\/span><span class=\"wh-source-url\" data-no-translation=\"\" dir=\"ltr\" style=\"display:block;overflow-wrap:anywhere;font-size:12px;line-height:1.55;color:#627583;\">https:\/\/redis.io\/docs\/latest\/commands\/info\/<\/span><span class=\"wh-source-url\" data-no-translation=\"\" dir=\"ltr\" style=\"display:block;overflow-wrap:anywhere;font-size:12px;line-height:1.55;color:#627583;\">https:\/\/redis.io\/docs\/latest\/commands\/config-get\/<\/span><span class=\"wh-source-url\" data-no-translation=\"\" dir=\"ltr\" style=\"display:block;overflow-wrap:anywhere;font-size:12px;line-height:1.55;color:#627583;\">https:\/\/redis.io\/docs\/latest\/operate\/oss_and_stack\/management\/config\/<\/span><span class=\"wh-source-url\" data-no-translation=\"\" dir=\"ltr\" style=\"display:block;overflow-wrap:anywhere;font-size:12px;line-height:1.55;color:#627583;\">https:\/\/redis.io\/docs\/latest\/commands\/wait\/<\/span><span class=\"wh-source-url\" data-no-translation=\"\" dir=\"ltr\" style=\"display:block;overflow-wrap:anywhere;font-size:12px;line-height:1.55;color:#627583;\">https:\/\/redis.io\/docs\/latest\/operate\/oss_and_stack\/management\/sentinel\/<\/span><span class=\"wh-source-url\" data-no-translation=\"\" dir=\"ltr\" style=\"display:block;overflow-wrap:anywhere;font-size:12px;line-height:1.55;color:#627583;\">https:\/\/redis.io\/docs\/latest\/operate\/oss_and_stack\/management\/admin\/<\/span><\/div><\/section><\/div>","protected":false},"excerpt":{"rendered":"<p>The Redis replication backlog maintains a limited subset of the replication stream. After brief connection interruptions, it often allows for a PSYNC instead of a full resync, but it is not a substitute for persistent data storage or a well-designed high-availability strategy.<\/p>","protected":false},"author":1,"featured_media":21637,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-21633","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-datenbanken-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"surfer_file_name":null,"surfer_file_original_url":null,"_wp_attachment_image_alt":null,"litespeed-optimize-set":null,"litespeed-optimize-size":null,"_oembed_b5e1eb923ad3b086e579b1befcd4075c":null,"_elementor_source_image_hash":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,"_source_url":null,"_elementor_migrations_state_8b2d":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":"781","_wh_make_key":"wh_a781989536a2355a2fb50457d779faf2","rank_math_internal_links_processed":"1","_wh_make_topic":"Redis Replication Backlog verstehen","_wh_make_input_keywords":["redis backlog","redis replication","high availability"],"_wh_make_config":{"research_model":"gpt-5.6-terra","writer_model":"gpt-5.6-terra","review_model":"gpt-5.6-sol","image_model":"gpt-image-2.5-flare","image_quality":"medium","image_format":"prefer_avif","final_status":"draft","charts_enabled":true},"_wh_make_links":{"I1":{"id":"I1","post_id":21475,"url":"https:\/\/webhosting.de\/redis-replication-offset-analyse-datenkonsistenz-cluster\/","title":"Understanding and Analyzing Redis Replication Offsets for High Data Consistency","excerpt":"I\u2019ll show you how I specifically read and analyze the Redis offset and use it to ensure high data consistency. This allows me to detect replication gaps early, assess failover risks, and reliably keep production clusters in sync. Key Points The following key points provide a targeted introduction to the topic, terminology, and practical implementation. The offset measures the progress of the replication stream byte by byte. Lag is the difference between `master_repl_offset` and `slave_repl_offset`. ID+Offset identifies an exact data version for partial syncs. Backlog prevents full syncs during brief connection interruptions. Monitoring with INFO\/cluster metrics controls alerting and failover. What does the Redis replication offset mean? The replication offset is a continuous 64-bit counter that tracks every byte stream transferred between the primary and the replica. I use it to determine how far the replication has progressed and whether a replica still has work to do. The `master_repl_offset` on the primary increases with every newly generated byte, while the replica increments its own counter as soon as it has applied commands. Differences result in a lag in bytes and indicate whether the replica is falling behind. This simple yet effective mechanism makes the offset the key metric for synchronization, failure analysis, and clean failover decisions. Reading Offsets: Using `INFO replication` Correctly I almost always begin my diagnosis with `INFO replication` because the command provides the relevant fields in a compact format. On the primary, I check `master_repl_offset` as well as the status of connected replicas, including their offsets. On a replica, I also check `master_link_status` and synchronization statuses to identify ongoing full syncs or partial syncs. For a more in-depth analysis, I rely on structured output and correlate offsets with CPU, I\/O, and network metrics. This guide provides me with a thorough introduction to the command: Redis INFO for Monitoring. Replication ID + Offset: Unique Data Version To identify a unique version, I use the combination of the Replication ID and the offset. The ID marks a history, while the offset marks a position within the"},"I2":{"id":"I2","post_id":21597,"url":"https:\/\/webhosting.de\/redis-key-expiration-performance-analysieren-optimieren-cache\/","title":"Analyzing and Optimizing Redis Key Expiration Performance","excerpt":"I analyze Redis key expiration performance in a targeted manner and optimize it using clear, measurable steps. This allows me to reduce latency, smooth out load spikes, and keep memory usage under control without compromising throughput. Key Points: I summarize the most important aspects of expiration performance so that beginners can get started right away and advanced users can fine-tune their systems effectively. The following key points address the most effective tuning parameters and highlight where typical bottlenecks occur. I focus on TTL strategies, active and passive cleanup, and eviction behavior. In addition, I outline monitoring metrics that reveal problems early on. This allows performance to be systematically evaluated and managed over the long term. Lazy vs. Active Expiration: Understanding and Measuring Interactions TTL Variance: Offsets vs. Simultaneous Expiration hz Tuning: Balancing the Frequency of Background Cycles Eviction Policy: allkeys-lru vs. volatile variants Monitoring: Observing expiration, eviction, and latency values I rely on consistent TTLs, adaptive purging, and clear thresholds. This way, I spread out expiration times, prevent unnecessary evictions, and reliably keep response times low. In addition, I use metrics that immediately signal unusual phases and enable precise countermeasures. Redis Key Expiration: How It Works and Its Impact on Latency Redis combines lazy and active expiration to balance high performance with limited CPU load. With lazy expiration, the server deletes keys only when they are accessed and the TTL has expired. This eliminates the need for additional background operations on data that is read regularly anyway. Active expiration complements this model with short, frequent scans of expiring keys to remove forgotten entries. This architecture keeps latency low and frees up memory without requiring expensive, continuous scans. Noticeable latency occurs primarily when a very large number of entries expire within a short time window. In such cases, Redis allocates more CPU resources to active cleanup, which temporarily reduces the capacity available for client operations. Additional memory pressure v"},"I3":{"id":"I3","post_id":21547,"url":"https:\/\/webhosting.de\/redis-expire-strategien-grosse-cache-systeme-cache-architektur\/","title":"Redis Expire Strategies for Large Cache Systems: A Practical Guide to Performance Optimization","excerpt":"Without well-planned Redis expiration strategies, large cache clusters quickly lead to memory bottlenecks and fluctuating latencies; I\u2019ll show you how to combine TTL, eviction, and invalidation to prevent load spikes. I\u2019ll provide concrete best practices for key design, expiration times, and monitoring that work reliably in production environments. Key points: Consistently understand and configure the separation of expiration and eviction; set TTL everywhere; and combine jitter with \u201eThundering Herd\u201c invalidation: Delete-on-write, tags, versioning; consciously choose an eviction policy and test it with `maxmemory`; focus monitoring on expired\/evicted keys, hit rate, and latencies; Expiration vs. Eviction: How Redis Deletes In my planning, I always make a clear distinction between expiration and eviction because both processes serve different purposes. Expiration removes keys when their TTL expires, while eviction only takes effect when the configured memory limit is exhausted. With lazy expiration, Redis checks whether a key has expired on every access and also actively cleans up randomly selected entries at regular intervals. This hybrid approach prevents timer overhead per key and keeps administrative overhead low. Those who understand this mechanism can precisely control how much \u201cdead\u201d memory is tolerated in the short term without causing unexpected cache misses. TTL Design: Times, Jitter, and Tiering I assign a TTL to every cache key, even when I use explicit invalidation, because an expiration time serves as an important safety net. For user-facing data, I often start with 5\u201315 minutes, but adjust the interval based on the frequency of changes and tolerance for stale reads. Sessions are given short durations, product details tend to have longer ones, and configurations have even more leeway; this way, I spread the risk and smooth out the load. Additionally, I add a slight jitter, such as \u00b110 %, to prevent thousands of keys from expiring simultaneously. In multi-tier caches, I have the app cache operate in seconds, Redis work in minutes to hours, and upstream tiers persist longer to avoid costly rebuilds. Explicit invalidation without side effects T"}},"_wh_make_stage":"pruefung","_wh_make_research_date":"2026-09-21","_wh_make_sitemap_info":{"index":"https:\/\/webhosting.de\/sitemap_index.xml","sitemaps":["https:\/\/webhosting.de\/post-sitemap1.xml","https:\/\/webhosting.de\/post-sitemap2.xml","https:\/\/webhosting.de\/post-sitemap3.xml","https:\/\/webhosting.de\/post-sitemap4.xml"],"url_count":3091,"fetched_at":"2026-09-21T16:17:16+00:00","selected_ids":[21475,21597,21547]},"_wh_make_draft_hash":"cdd03f169db2ce62837f8c9e05cbc557528cf04eb9858b9669fb83ad3a8cf0e1","_wh_make_work":null,"_wh_make_research":"## Recherchebriefing: Redis Replication Backlog verstehen  \n**Kategorie:** Datenbanken \u00b7 **Recherchezeitpunkt:** 21. September 2026  \n**Keywords:** \u201eredis backlog\u201c, \u201eredis replication\u201c, \u201ehigh availability\u201c \u2013 alle drei passen fachlich direkt. Der Fokus sollte klar auf **Redis Open Source** liegen; Redis Software\/Cloud verwendet teils abweichende, shardbezogene Backlog-Mechanismen und Defaultwerte.\n\n### Leserfrage\n**Was speichert der Redis Replication Backlog, wann erm\u00f6glicht er eine partielle Resynchronisierung (PSYNC), wie wird seine Gr\u00f6\u00dfe sinnvoll bestimmt \u2013 und weshalb ist er ein HA-Baustein, aber keine Garantie gegen Datenverlust?**\n\n---\n\n## Gesicherte Aussagen\n\n1. **Der Replication Backlog ist ein Speicherpuffer f\u00fcr den Replikationsdatenstrom, nicht eine zweite Datenbankkopie.**  \n   Ein Primary erzeugt einen Replikationsstrom aus Datensatz\u00e4nderungen. Rei\u00dft die Verbindung zu einer Replica ab, kann diese beim Wiederverbinden \u00fcber `PSYNC` ihre bekannte Replikations-ID und ihren zuletzt verarbeiteten Offset mitteilen. Liegt der fehlende Abschnitt noch im Backlog und ist die Replikationshistorie g\u00fcltig, liefert Redis nur die fehlenden Daten nach (*partial resynchronization*). Andernfalls erfolgt ein Full Resync: Snapshot erzeugen, RDB \u00fcbertragen, danach zwischengespeicherte \u00c4nderungen nachliefern. ([redis.io](https:\/\/redis.io\/docs\/latest\/operate\/oss_and_stack\/management\/replication\/))\n\n2. **Der entscheidende Grenzwert ist nicht eine \u201emaximale Ausfallzeit\u201c an sich, sondern die w\u00e4hrend des Ausfalls erzeugte Menge des Replikationsstroms.**  \n   `repl-backlog-size` begrenzt die vorgehaltene Datenmenge. Ein gr\u00f6\u00dferer Backlog kann eine l\u00e4ngere oder schreibintensivere Unterbrechung \u00fcberbr\u00fccken; ist der erforderliche Offset \u00e4lter als `repl_backlog_first_byte_offset`, ist PSYNC nicht mehr m\u00f6glich. Redis dokumentiert daf\u00fcr die Statusfelder `repl_backlog_size`, `repl_backlog_first_byte_offset` und `repl_backlog_histlen`. ([redis.io](https:\/\/redis.io\/docs\/latest\/commands\/info\/))\n\n3. **Replikations-ID und Offset geh\u00f6ren zusammen.**  \n   Der Offset steigt f\u00fcr jedes Byte des Replikationsstroms, auch wenn gerade keine Replica verbunden ist. Erst das Paar aus Replikations-ID und Offset kennzeichnet einen konkreten Stand einer Datenhistorie. Nach einem Failover bewahrt eine bef\u00f6rderte Replica zus\u00e4tzlich die vorherige ID als sekund\u00e4re ID auf. Das kann partielle Synchronisationen weiterer Replicas nach dem Failover erm\u00f6glichen. ([redis.io](https:\/\/redis.io\/docs\/latest\/operate\/oss_and_stack\/management\/replication\/))\n\n4. **Redis-Replikation ist standardm\u00e4\u00dfig asynchron; der Backlog macht daraus keine synchrone oder strikt konsistente Replikation.**  \n   Ein Backlog senkt vor allem die Wahrscheinlichkeit teurer Full Resyncs nach kurzzeitigen Unterbrechungen. Datenverlust bei Primary-Ausfall bleibt grunds\u00e4tzlich m\u00f6glich. `WAIT` kann Best\u00e4tigungen von Replicas anfordern, schafft aber laut Redis keine CP- bzw. Strong-Consistency-Garantie. F\u00fcr eine begrenzte Annahme von Writes lassen sich au\u00dferdem `min-replicas-to-write` und `min-replicas-max-lag` einsetzen; auch diese Einstellung garantiert nicht, dass die geforderte Zahl von Replicas den konkreten Write dauerhaft \u00fcbernommen hat. ([redis.io](https:\/\/redis.io\/docs\/latest\/operate\/oss_and_stack\/management\/replication\/?utm_source=openai))\n\n5. **Die Beispielkonfiguration nennt f\u00fcr OSS einen Backlog von 1 MiB und eine TTL von 3.600 Sekunden \u2013 das sind nicht automatisch passende Produktionswerte.**  \n   Der Backlog wird laut Beispielkonfiguration auf einem Primary erst angelegt, wenn mindestens eine Replica verbunden ist. Nach Trennung der letzten Replica wird er nach `repl-backlog-ttl` freigegeben; `0` bedeutet, ihn nicht automatisch freizugeben. Replicas geben den Backlog laut Konfigurationskommentar nicht per TTL frei, weil sie sp\u00e4ter zum Primary bef\u00f6rdert werden k\u00f6nnten. Die offizielle Betriebsdokumentation empfiehlt nur qualitativ einen \u201enicht trivialen\u201c Backlog proportional zum Speicherbedarf \u2013 keine allgemeine Formel oder universelle Prozentzahl f\u00fcr Redis OSS. ([github.com](https:\/\/github.com\/redis\/redis\/blob\/unstable\/redis.conf))\n\n---\n\n## Vergleichstabelle als Datenbasis\n\n| Aspekt | Redis Open Source | Redis Software (Dokumentation 7.8) | Redaktionelle Einordnung |\n|---|---|---|---|\n| Einheit des Backlogs | Pro Redis-Instanz \/ Replikationsstrom | Pro Shard | Nicht vermischen: Architektur und Stellgr\u00f6\u00dfen unterscheiden sich. |\n| Konfiguration | `repl-backlog-size`, `repl-backlog-ttl` in `redis.conf` | `rladmin tune db \u2026 repl_backlog \u2026` bzw. `auto` | OSS-Konfigurationsbeispiele sind nicht auf Redis Software \u00fcbertragbar. |\n| Dokumentierter Default | Beispielwert: `1mb`; als auskommentierte Vorlage | `auto`: 1 % der DB-Gr\u00f6\u00dfe \/ Shardzahl, min. 1 MB, max. 250 MB pro Shard | Die 1-%-Regel gilt **nicht** als OSS-Empfehlung. |\n| Zweck | PSYNC nach kurzzeitiger Unterbrechung | Synchronisierung von Primary- und Replica-Shards | In beiden F\u00e4llen: Full Syncs vermeiden bzw. reduzieren. |\n| HA-Aussage | Asynchrone Replikation, keine automatische Konsistenzgarantie | Produkt-\/Plattformfunktion mit eigener Steuerung | Backlog ist nur ein Element eines HA-Konzepts. |\n\nOSS-Details und Konfigurationssemantik: ([github.com](https:\/\/github.com\/redis\/redis\/blob\/unstable\/redis.conf)) Redis-Software-Angaben, ausdr\u00fccklich versionsgebunden an die 7.8-Dokumentation: ([redis.io](https:\/\/redis.io\/docs\/latest\/operate\/rs\/7.8\/databases\/durability-ha\/replication\/?utm_source=openai))\n\n---\n\n## Belegtes Konfigurations- und Beobachtungsbeispiel\n\n```conf\n# redis.conf \u2013 Beispielwerte aus der mitgelieferten Konfigurationsvorlage\nrepl-backlog-size 1mb\nrepl-backlog-ttl 3600\n```\n\nDiese Werte sind **Vorlagenwerte**, keine Kapazit\u00e4tsempfehlung. `repl-backlog-ttl 0` verhindert die automatische Freigabe nach dem Verlust aller Replicas. ([github.com](https:\/\/github.com\/redis\/redis\/blob\/unstable\/redis.conf))\n\nF\u00fcr das Monitoring ist die belastbare Basis:\n\n```text\nINFO replication\n```\n\nRelevante Felder:  \n- `master_repl_offset`: aktueller Offset des Primary,  \n- `repl_backlog_first_byte_offset`: \u00e4ltester noch vorgehaltener Byte-Offset,  \n- `repl_backlog_histlen`: aktuell bef\u00fcllte Historienl\u00e4nge,  \n- `repl_backlog_size`: konfigurierte Backlog-Gr\u00f6\u00dfe,  \n- auf einer Replica: `master_link_status`, `slave_repl_offset` und bei Unterbrechung `master_link_down_since_seconds`. ([redis.io](https:\/\/redis.io\/docs\/latest\/commands\/info\/))\n\n---\n\n## Rechenbeispiel \u2013 als Planungsn\u00e4herung, nicht als Redis-Garantie\n\n**Annahme:** Der Replikationsstrom erzeugt im beobachteten Spitzenzeitraum durchschnittlich 12 MiB\/s. Eine Replica soll einen Netzwerkausfall von 90 Sekunden \u00fcberstehen; zus\u00e4tzlich werden 30 Sekunden Sicherheitsreserve eingeplant.\n\n\\[\n\\text{Backlog} \\ge 12\\ \\text{MiB\/s} \\times (90 + 30)\\ \\text{s} = 1{.}440\\ \\text{MiB}\n\\]\n\n**Ergebnis:** Mindestens rund **1,41 GiB** Backlog, zuz\u00fcglich einer betrieblich festzulegenden Reserve f\u00fcr Messungenauigkeit und Lastspitzen. Entscheidend ist, die Rate aus tats\u00e4chlich beobachteten Offsets \u00fcber Zeit abzuleiten, nicht aus Client-Operationen pro Sekunde: Replikationsdaten sind byteorientiert und Befehlsgr\u00f6\u00dfe, Werte, TTL-\/L\u00f6schoperationen sowie Pipelines beeinflussen das Volumen.\n\n---\n\n## Technische Stolperstellen\n\n- **Backlog \u2260 Replica-Output-Buffer.** W\u00e4hrend eines Full Sync kann die Replica den Replikationsstrom zus\u00e4tzlich puffern; `replica-full-sync-buffer-limit` und auf der Primary-Seite `client-output-buffer-limit replica` sind getrennte Schutzmechanismen. Ein gr\u00f6\u00dferer Backlog l\u00f6st kein Speicherproblem eines langsamen oder beim Full Sync \u00fcberforderten Replica-Knotens. ([github.com](https:\/\/github.com\/redis\/redis\/blob\/unstable\/redis.conf))  \n- **Full Resync ist teuer:** Er umfasst RDB-Erzeugung\/-Transfer und kann bei schreibintensiven Instanzen zus\u00e4tzlichen Speicherbedarf verursachen. Redis weist allgemein darauf hin, dass RDB-Save oder AOF-Rewrite in Write-lastigen Szenarien bis zu etwa dem Doppelten des regul\u00e4r genutzten Speichers beanspruchen kann; dies ist bei Kapazit\u00e4tsplanung von Replikation relevant. ([redis.io](https:\/\/redis.io\/docs\/latest\/operate\/oss_and_stack\/management\/admin\/))  \n- **Keine Replica verbunden:** In OSS wird der Backlog erst bei mindestens einer verbundenen Replica angelegt. Nach Ablauf der TTL ohne Replicas fehlt somit Historie f\u00fcr eine sp\u00e4tere PSYNC-Anfrage. ([github.com](https:\/\/github.com\/redis\/redis\/blob\/unstable\/redis.conf))  \n- **Failover und Neustarts:** Redis 4.0+ unterst\u00fctzt Partial Sync nach Failover mithilfe der zweiten Replikations-ID. Ein sauber per `SHUTDOWN` mit RDB beendeter Replica-Neustart kann ebenfalls PSYNC beg\u00fcnstigen; ein Neustart \u00fcber AOF kann dies laut Redis nicht. ([redis.io](https:\/\/redis.io\/docs\/latest\/operate\/oss_and_stack\/management\/replication\/))  \n- **Memory Budget:** Seit Redis 7.0 teilen Replica-Buffer und Backlog Speicher; deshalb kann `mem_clients_slaves` trotz vorhandener Replicas null anzeigen. F\u00fcr die Gesamtbetrachtung sind auch `mem_replication_backlog` und `mem_total_replication_buffers` relevant. ([redis.io](https:\/\/redis.io\/docs\/latest\/commands\/info\/))\n\n---\n\n## Chart-Vorschlag\n**Kein Chart** f\u00fcr eine pauschale Gr\u00f6\u00dfenempfehlung: Es existiert f\u00fcr Redis OSS keine belastbare, universelle Prozentregel. Sinnvoll w\u00e4re allenfalls eine installationsspezifische Zeitreihe \u201eReplikationsrate in MiB\/s\u201c gegen \u201eBacklog-Reichweite in Sekunden\u201c, sofern eigene Messdaten aus `master_repl_offset` vorliegen.\n\n## Offene Unsicherheiten\n- Die Dokumentation beschreibt aktuelle Redis-OSS-Funktionen, benennt aber keine feste Redis-Releaseversion f\u00fcr jede Konfigurationszeile; das konsultierte `redis.conf` stammt aus dem **unstable**-Branch und darf daher nur als aktuelle Vorlage, nicht als r\u00fcckwirkender Versionsbeleg verwendet werden.  \n- F\u00fcr eine konkrete Sollgr\u00f6\u00dfe fehlen Angaben zu Redis-Version, Write-Volumen in Bytes, maximal tolerierter Netzunterbrechung, Anzahl\/Topologie der Replicas, Persistence-Modus und verf\u00fcgbarem RAM.  \n- Falls der Beitrag Redis Cluster, Sentinel oder Managed-Angebote behandeln soll, m\u00fcssen deren Failover- und Backlog-Eigenschaften getrennt recherchiert werden; sie sind nicht identisch mit dem OSS-Primary\/Replica-Grundmodell.","_wh_make_sources":{"S1":{"id":"S1","url":"https:\/\/redis.io\/docs\/latest\/operate\/oss_and_stack\/management\/replication\/","title":"Redis Replication | Docs"},"S2":{"id":"S2","url":"https:\/\/redis.io\/docs\/latest\/commands\/info\/","title":"INFO | Docs"},"S3":{"id":"S3","url":"https:\/\/redis.io\/docs\/latest\/operate\/oss_and_stack\/management\/replication\/?utm_source=openai","title":"Redis Replication | Docs"},"S4":{"id":"S4","url":"https:\/\/github.com\/redis\/redis\/blob\/unstable\/redis.conf","title":"redis\/redis.conf in unstable \u00b7 redis\/redis \u00b7 GitHub"},"S5":{"id":"S5","url":"https:\/\/redis.io\/docs\/latest\/operate\/rs\/7.8\/databases\/durability-ha\/replication\/?utm_source=openai","title":"Database replication | Docs"},"S6":{"id":"S6","url":"https:\/\/redis.io\/docs\/latest\/operate\/oss_and_stack\/management\/admin\/","title":"Redis Administration | Docs"}},"_wh_make_usage":{"research":{"input_tokens":33913,"output_tokens":2950,"response_id":"resp_05ee82f48a6cf6a8016ab1588e2d0887d2ade8a873a2317cd3","model":"gpt-5.6-terra","search_calls":4},"writer":{"input_tokens":6454,"output_tokens":4402,"response_id":"resp_0bb89d09c2020060016ab158bbc8b887d2a0f30d74eb8a02e2","model":"gpt-5.6-terra","search_calls":0},"review":{"input_tokens":38942,"output_tokens":1614,"response_id":"resp_03de38f1242fe83b016ab158f85b3487d29cb99dc36fa7d399","model":"gpt-5.6-sol","search_calls":3}},"_wh_make_last_error":null,"_wh_make_write_intent":null,"_wh_make_design_version":"2.0.4","rank_math_title":"Redis Replication Backlog verstehen und richtig planen","_wh_make_doc":{"title":"Understanding the Redis Replication Backlog: PSYNC, Size, and HA Limits","slug":"understanding-the-redis-replication-backlog","excerpt":"The Redis replication backlog maintains a limited subset of the replication stream. After brief connection interruptions, it often allows for a PSYNC instead of a full resync, but it is not a substitute for persistent data storage or a well-designed high-availability strategy.","seo":{"title":"Understanding the Redis Replication Backlog and Planning for It Properly","description":"Learn what the Redis replication backlog stores, how PSYNC works, how to plan for its size, and what limitations apply to high availability.","focus_keyword":"Redis Replication Backlog"},"lead":[{"kind":"text","text":"Der Redis Replication Backlog ist ein begrenzter Speicherpuffer f\u00fcr bereits erzeugte Replikationsdaten. Kann eine Replica nach einer Unterbrechung an ihrer bekannten Replikationshistorie und ihrem Offset ankn\u00fcpfen, erh\u00e4lt sie \u00fcber PSYNC nur die fehlenden Bytes statt eines vollst\u00e4ndigen Neuabgleichs. ","ref":""},{"kind":"citation","text":"","ref":"S1"},{"kind":"text","text":"Das reduziert Full Resyncs, macht die standardm\u00e4\u00dfig asynchrone Redis-Replikation aber weder synchron noch verlustfrei bei einem Primary-Ausfall. ","ref":""},{"kind":"citation","text":"","ref":"S3"}],"sections":[{"id":"grundprinzip","heading":"Was der Backlog speichert \u2013 und was nicht","blocks":[{"type":"paragraph","runs":[{"kind":"text","text":"Ein Redis Primary erzeugt aus \u00c4nderungen einen fortlaufenden Replikationsstrom. Der Replication Backlog bewahrt davon einen begrenzten j\u00fcngeren Abschnitt im Speicher auf. Er ist damit kein zweiter Datensatzbestand, kein Snapshot und kein Ersatz f\u00fcr RDB- oder AOF-Persistenz. Sein Zweck ist eng umrissen: Eine getrennte Replica soll eine kurzzeitige L\u00fccke im Datenstrom schlie\u00dfen k\u00f6nnen. ","ref":""},{"kind":"citation","text":"","ref":"S1"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Entscheidend ist das Paar aus Replikations-ID und Offset. Die ID kennzeichnet eine Datenhistorie, der Offset eine Position darin. Der Offset w\u00e4chst byteweise mit dem Replikationsstrom \u2013 auch dann, wenn aktuell keine Replica verbunden ist. Eine Replica meldet bei der Wiederverbindung ihre bekannte ID und ihren zuletzt verarbeiteten Offset. Stimmen Historie und verf\u00fcgbarer Bereich \u00fcberein, kann der Primary die fehlenden Daten nachreichen. ","ref":""},{"kind":"citation","text":"","ref":"S1"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Der praktische Unterschied ist erheblich: Bei einer partiellen Resynchronisierung bleibt der Nachholvorgang auf die L\u00fccke begrenzt. Ist die L\u00fccke nicht mehr im Backlog oder passt die Historie nicht, folgt ein Full Resync. Dann erstellt beziehungsweise liefert Redis einen RDB-Snapshot und \u00fcbertr\u00e4gt anschlie\u00dfend \u00c4nderungen, die w\u00e4hrenddessen angefallen sind. ","ref":""},{"kind":"citation","text":"","ref":"S1"}]}]},{"id":"psync-grenze","heading":"Wann PSYNC funktioniert und wann ein Full Resync n\u00f6tig wird","blocks":[{"type":"paragraph","runs":[{"kind":"text","text":"Die zentrale Frage lautet nicht: \u201eWie viele Sekunden darf die Replica ausfallen?\u201c Sondern: \u201eWie viele Bytes des Replikationsstroms entstehen w\u00e4hrend dieser Unterbrechung?\u201c Ein Backlog mit 256 MiB kann bei geringer Schreibrate lange reichen und bei hoher Schreibrate sehr schnell \u00fcberschrieben sein. Redis verwirft die \u00e4ltesten Bytes, sobald neuer Replikationsstrom den konfigurierten Speicherbereich f\u00fcllt.","ref":""},{"kind":"citation","text":"","ref":"S2"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Auf dem Primary beschreibt ","ref":""},{"kind":"code","text":"repl_backlog_first_byte_offset","ref":""},{"kind":"text","text":" den \u00e4ltesten noch verf\u00fcgbaren Offset. Fordert eine Replica einen \u00e4lteren Stand an, liegt ihre L\u00fccke au\u00dferhalb der Historie: PSYNC kann nicht greifen. ","ref":""},{"kind":"code","text":"repl_backlog_histlen","ref":""},{"kind":"text","text":" zeigt dagegen, wie viele historische Bytes derzeit tats\u00e4chlich im Backlog liegen; ","ref":""},{"kind":"code","text":"repl_backlog_size","ref":""},{"kind":"text","text":" ist die konfigurierte Obergrenze. ","ref":""},{"kind":"citation","text":"","ref":"S2"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Nach einem Failover ist die Lage nicht zwangsl\u00e4ufig verloren. Eine zur Primary bef\u00f6rderte Replica beh\u00e4lt zus\u00e4tzlich die vorherige Replikations-ID als sekund\u00e4re ID. Dadurch k\u00f6nnen andere Replicas unter bestimmten Bedingungen auch nach dem Rollenwechsel partiell synchronisieren. Redis dokumentiert diese F\u00e4higkeit f\u00fcr Redis 4.0 und neuer; sie ersetzt jedoch keine Pr\u00fcfung des tats\u00e4chlichen Backlog-Bereichs und der Topologie. ","ref":""},{"kind":"citation","text":"","ref":"S1"}]},{"type":"table","caption":"Entscheidungslogik f\u00fcr die Wiederanbindung einer Redis-Replica","headers":["Situation","ID und Offset","Ergebnis","Betriebliche Folge"],"rows":[["Kurze Unterbrechung, fehlende Bytes liegen noch im Backlog","Historie g\u00fcltig, Offset abgedeckt","Partielle Resynchronisierung per PSYNC","Nur die L\u00fccke wird \u00fcbertragen"],["Unterbrechung oder Schreibrate \u00fcbersteigt die Backlog-Reichweite","Angeforderter Offset \u00e4lter als der erste Backlog-Offset","Full Resync","RDB-Transfer und Nachlieferung laufender \u00c4nderungen"],["Failover mit weiter nutzbarer Vorg\u00e4ngerhistorie","Sekund\u00e4re Replikations-ID kann passen","PSYNC kann m\u00f6glich sein","Abh\u00e4ngig von Historie und vorgehaltenem Bereich"],["Keine Replica \u00fcber l\u00e4ngere Zeit und Backlog-TTL abgelaufen","Kein nutzbarer Backlog vorhanden","Sp\u00e4tere Replica ben\u00f6tigt Full Resync","Historie wurde automatisch freigegeben"]],"source_ids":["S1","S2","S4"]}]},{"id":"groesse-planen","heading":"Backlog-Gr\u00f6\u00dfe aus der Replikationsrate ableiten","blocks":[{"type":"paragraph","runs":[{"kind":"text","text":"F\u00fcr Redis Open Source gibt es keine belastbare allgemeine Prozentregel bezogen auf die Datenbankgr\u00f6\u00dfe. Plane deshalb nicht mit Operationen pro Sekunde, sondern mit dem beobachteten Bytezuwachs des Replikationsstroms. Befehlsgr\u00f6\u00dfe, Wertgr\u00f6\u00dfen, L\u00f6schungen, TTL-bezogene \u00c4nderungen und Pipelines beeinflussen diese Rate. Zwei Anwendungen mit gleicher Request-Zahl k\u00f6nnen daher deutlich unterschiedliche Backlog-Anforderungen haben.","ref":""}]},{"type":"paragraph","runs":[{"kind":"text","text":"Eine brauchbare Planungsn\u00e4herung lautet: ben\u00f6tigter Backlog mindestens gleich Spitzenrate des Replikationsstroms mal maximal zu \u00fcberbr\u00fcckende Unterbrechung plus Sicherheitsreserve. Miss dazu auf dem Primary wiederholt ","ref":""},{"kind":"code","text":"master_repl_offset","ref":""},{"kind":"text","text":" und teile die Offset-Differenz durch das Zeitintervall. Die INFO-Ausgabe liefert au\u00dferdem die Backlog-Grenzen und auf einer Replica Link-Status sowie deren Offset. ","ref":""},{"kind":"citation","text":"","ref":"S2"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Beispiel: Im beobachteten Spitzenzeitraum entstehen durchschnittlich 12 MiB pro Sekunde. Eine Replica soll 90 Sekunden Netzunterbrechung und zus\u00e4tzlich 30 Sekunden Reserve \u00fcberbr\u00fccken. Die Rechnung lautet ","ref":""},{"kind":"code","text":"12 MiB\/s \u00d7 (90 s + 30 s) = 1.440 MiB","ref":""},{"kind":"text","text":". Das entspricht rund 1,41 GiB. Dieser Wert ist kein Redis-Versprechen, sondern ein Startwert f\u00fcr Kapazit\u00e4tsplanung. Lastspitzen, l\u00e4ngere St\u00f6rungen und Messungenauigkeit brauchen zus\u00e4tzliche, lokal begr\u00fcndete Reserve.","ref":""}]},{"type":"paragraph","runs":[{"kind":"text","text":"Der Speicherbedarf muss in das gesamte RAM-Budget passen. Seit Redis 7.0 teilen sich Replica-Buffer und Backlog Speicher; deshalb kann ","ref":""},{"kind":"code","text":"mem_clients_slaves","ref":""},{"kind":"text","text":" trotz verbundener Replicas null sein. F\u00fcr die Gesamtbetrachtung sind insbesondere ","ref":""},{"kind":"code","text":"mem_replication_backlog","ref":""},{"kind":"text","text":" und ","ref":""},{"kind":"code","text":"mem_total_replication_buffers","ref":""},{"kind":"text","text":" relevant. ","ref":""},{"kind":"citation","text":"","ref":"S2"}]}]},{"id":"konfiguration","heading":"Konfiguration: Vorlage verstehen, nicht blind \u00fcbernehmen","blocks":[{"type":"paragraph","runs":[{"kind":"text","text":"Die mitgelieferte Redis-Konfigurationsvorlage enth\u00e4lt folgende Werte. Sie sind Beispielwerte und keine pauschale Produktionsdimensionierung. ","ref":""},{"kind":"citation","text":"","ref":"S4"}]},{"type":"code","language":"conf","code":"# redis.conf \u2013 Beispielwerte aus der mitgelieferten Konfigurationsvorlage\nrepl-backlog-size 1mb\nrepl-backlog-ttl 3600","source_ids":["S4"]},{"type":"paragraph","runs":[{"kind":"text","text":"In Redis OSS wird der Backlog erst angelegt, wenn mindestens eine Replica verbunden ist. Trennt sich die letzte Replica, gibt ","ref":""},{"kind":"code","text":"repl-backlog-ttl","ref":""},{"kind":"text","text":" an, wann Redis ihn freigibt. Der Wert ","ref":""},{"kind":"code","text":"0","ref":""},{"kind":"text","text":" verhindert diese automatische Freigabe. Das kann sinnvoll sein, wenn eine sp\u00e4ter wiederkehrende Replica m\u00f6glichst noch PSYNC nutzen soll, kostet aber dauerhaft Speicher. Replicas selbst geben ihren Backlog laut Konfigurationskommentar nicht per TTL frei, weil sie sp\u00e4ter Primary werden k\u00f6nnten. ","ref":""},{"kind":"citation","text":"","ref":"S4"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Redis Software darf hier nicht mit Redis OSS gleichgesetzt werden. In der Redis-Software-Dokumentation 7.8 wird der Backlog pro Shard behandelt und kann \u00fcber Plattformbefehle oder automatisch eingestellt werden; die dort dokumentierte Auto-Regel ist keine Empfehlung f\u00fcr OSS. Wer beide Produkte betreibt, sollte Konfiguration, Einheit und Defaultwerte strikt getrennt dokumentieren. ","ref":""},{"kind":"citation","text":"","ref":"S5"}]}]},{"id":"monitoring-und-grenzen","heading":"Monitoring und die Grenzen f\u00fcr High Availability","blocks":[{"type":"paragraph","runs":[{"kind":"text","text":"Beginne die Diagnose mit folgendem Befehl:","ref":""}]},{"type":"code","language":"text","code":"INFO replication","source_ids":["S2"]},{"type":"paragraph","runs":[{"kind":"text","text":"Auf dem Primary pr\u00fcfst du ","ref":""},{"kind":"code","text":"master_repl_offset","ref":""},{"kind":"text","text":", ","ref":""},{"kind":"code","text":"repl_backlog_first_byte_offset","ref":""},{"kind":"text","text":", ","ref":""},{"kind":"code","text":"repl_backlog_histlen","ref":""},{"kind":"text","text":" und ","ref":""},{"kind":"code","text":"repl_backlog_size","ref":""},{"kind":"text","text":". Auf einer Replica sind ","ref":""},{"kind":"code","text":"master_link_status","ref":""},{"kind":"text","text":", ","ref":""},{"kind":"code","text":"slave_repl_offset","ref":""},{"kind":"text","text":" sowie bei Unterbrechungen ","ref":""},{"kind":"code","text":"master_link_down_since_seconds","ref":""},{"kind":"text","text":" aufschlussreich. Alarmiere nicht nur bei einem getrennten Link, sondern auch, wenn die gesch\u00e4tzte Backlog-Reichweite kleiner wird als die realistische Wiederherstellungszeit. ","ref":""},{"kind":"citation","text":"","ref":"S2"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Ein gr\u00f6\u00dferer Backlog l\u00f6st keine Probleme mit langsamen Replicas w\u00e4hrend eines Full Resync. Daf\u00fcr existieren getrennte Schutzmechanismen: ","ref":""},{"kind":"code","text":"replica-full-sync-buffer-limit","ref":""},{"kind":"text","text":" begrenzt den Puffer auf Replica-Seite, ","ref":""},{"kind":"code","text":"client-output-buffer-limit replica","ref":""},{"kind":"text","text":" betrifft den Replica-Client-Output-Buffer auf dem Primary. Diese Werte und der Backlog erf\u00fcllen unterschiedliche Aufgaben und m\u00fcssen gemeinsam in die Speicherplanung einflie\u00dfen. ","ref":""},{"kind":"citation","text":"","ref":"S4"}]},{"type":"paragraph","runs":[{"kind":"text","text":"F\u00fcr High Availability ist der Backlog daher ein Verf\u00fcgbarkeitsbaustein: Er verringert nach kurzen Fehlern die Wahrscheinlichkeit kostspieliger Full Resyncs. Replikation bleibt jedoch standardm\u00e4\u00dfig asynchron. Bei einem Primary-Ausfall k\u00f6nnen best\u00e4tigte Client-Schreibvorg\u00e4nge fehlen, die noch nicht auf einer Replica angekommen sind. ","ref":""},{"kind":"citation","text":"","ref":"S3"},{"kind":"text","text":" ","ref":""},{"kind":"code","text":"WAIT","ref":""},{"kind":"text","text":" kann Replica-Best\u00e4tigungen anfordern, liefert laut Redis aber keine starke Konsistenzgarantie. ","ref":""},{"kind":"citation","text":"","ref":"S3"}]},{"type":"paragraph","runs":[{"kind":"text","text":"Auch ","ref":""},{"kind":"code","text":"min-replicas-to-write","ref":""},{"kind":"text","text":" und ","ref":""},{"kind":"code","text":"min-replicas-max-lag","ref":""},{"kind":"text","text":" begrenzen unter bestimmten Bedingungen die Annahme neuer Writes, garantieren aber nicht, dass die geforderte Zahl von Replicas einen konkreten Write dauerhaft \u00fcbernommen hat. Erg\u00e4nze den Backlog deshalb um passende Failover-Abl\u00e4ufe, Persistenz, getestete Wiederherstellung und ein klares Datenverlustziel. F\u00fcr die praktische Auswertung von Offsets kann auch der interne Leitfaden ","ref":""},{"kind":"internal_link","text":"Redis Replication Offset analysieren","ref":"I1"},{"kind":"text","text":" weiterhelfen.","ref":""}]}]}],"images":{"hero":{"prompt":"Editoriale, realistische technische Illustration f\u00fcr einen Fachartikel: ein Redis-Primary als zentraler Knoten links sendet einen leuchtenden Datenstrom zu zwei Replica-Knoten rechts. Im Datenstrom befindet sich ein deutlich erkennbarer ringf\u00f6rmiger Pufferspeicher, der j\u00fcngere Datenabschnitte h\u00e4lt; eine kurz getrennte Verbindung zu einer Replica wird wieder geschlossen und der fehlende Abschnitt flie\u00dft nach. Dunkler, ruhiger Serverraum-Hintergrund, klare r\u00e4umliche Trennung der Komponenten, Rot- und warme Akzentfarben, keine Markenlogos. Keine W\u00f6rter, Zahlen, Labels, Diagrammlegenden oder UI-Screenshots.","alt":"Illustration eines Primary mit ringf\u00f6rmigem Replikationspuffer und zwei wieder angebundenen Redis-Replicas.","caption":"Illustrative Darstellung: Der Backlog h\u00e4lt einen j\u00fcngeren Abschnitt des Replikationsstroms f\u00fcr wiederkehrende Replicas vor.","filename_base":"redis-backlog-psync","section_id":"","after_block":0},"detail1":{"prompt":"Klare konzeptionelle Illustration einer horizontalen Zeitachse f\u00fcr Redis-Replikation: links ein \u00e4lterer, verblassender Datenstrom, in der Mitte ein begrenzter ringf\u00f6rmiger Speicherbereich mit sichtbaren j\u00fcngeren Datenpaketen, rechts neue Datenpakete. Eine Replica-Verbindung setzt an einer Position innerhalb des Ringbereichs wieder ein, eine zweite gestrichelte Verbindung versucht weit links au\u00dferhalb des Ringbereichs anzusetzen und wird in einen vollst\u00e4ndigen Datentransfer \u00fcbergeleitet. Visuell intuitiv, technische Vektor-\u00c4sthetik, keine Beschriftungen, W\u00f6rter, Zahlen, Legenden oder Marken.","alt":"Zeitachsenillustration mit verf\u00fcgbarem Backlog-Bereich und einer zu alten Replikationsl\u00fccke.","caption":"Illustrative Darstellung: Ob PSYNC gelingt, h\u00e4ngt davon ab, ob der ben\u00f6tigte Offset noch im vorgehaltenen Bereich liegt.","filename_base":"redis-psync-offset-range","section_id":"psync-grenze","after_block":2},"detail2":{"prompt":"Technische konzeptionelle Illustration zur Speicherkapazit\u00e4tsplanung: ein Server-Speichercontainer ist in mehrere farbige, unterschiedlich gro\u00dfe Bereiche gegliedert, darunter ein wachsender Replikationspuffer und getrennte Puffer f\u00fcr Replica-Daten. Daneben flie\u00dft ein variabler Strom aus Datenpaketen in den Replikationspuffer; eine kurze Unterbrechung wird durch den gespeicherten Abschnitt \u00fcberbr\u00fcckt. Fokus auf Verh\u00e4ltnis von Datenrate, Unterbrechungsdauer und RAM-Budget, ohne exakte Messskalen. Sachliche isometrische Vektorillustration, keine W\u00f6rter, Zahlen, Labels, Legenden, Logos oder erfundene Dashboards.","alt":"Illustration eines Server-Speicherbudgets mit Replikationsbacklog und getrennten Replica-Puffern.","caption":"Illustrative Darstellung: Die Backlog-Gr\u00f6\u00dfe wird aus Datenrate und gew\u00fcnschter \u00dcberbr\u00fcckungszeit geplant und dem RAM-Budget gegen\u00fcbergestellt.","filename_base":"redis-backlog-memory-budget","section_id":"groesse-planen","after_block":3}},"chart":null,"social":{"facebook":"Redis Backlog richtig planen: Wann PSYNC gelingt und warum der Puffer keine Datenverlustgarantie ist.","instagram":"PSYNC statt Full Resync: So h\u00e4ngt die Redis-Backlog-Gr\u00f6\u00dfe von Byte-Rate und Ausfallzeit ab.","tiktok":"Redis Backlog erkl\u00e4rt: Warum Sekunden allein nicht entscheiden, ob PSYNC funktioniert.","youtube":"Redis Replication Backlog: PSYNC, Dimensionierung und Grenzen f\u00fcr HA verst\u00e4ndlich erkl\u00e4rt.","threads":"Der Redis Backlog puffert Replikationsbytes, nicht deine Datenbank. Entscheidend sind Offset, Historie und Schreibrate.","x":"Redis Replication Backlog: PSYNC klappt nur, wenn ID, Offset und vorgehaltener Bytebereich zusammenpassen. Gr\u00f6\u00dfe nach Replikationsrate und \u00dcberbr\u00fcckungszeit planen \u2013 nicht nach pauschalen Prozentwerten."},"avatar_script":"Der Redis Replication Backlog ist ein Speicherpuffer f\u00fcr einen begrenzten Teil des Replikationsstroms. F\u00e4llt die Verbindung einer Replica kurz aus, kann sie ihre Replikations-ID und ihren letzten Offset melden. Liegen die fehlenden Bytes noch im Backlog, liefert Redis sie per PSYNC nach. Andernfalls ist ein Full Resync mit RDB-\u00dcbertragung erforderlich. F\u00fcr die Gr\u00f6\u00dfe z\u00e4hlt nicht nur die Dauer einer Unterbrechung, sondern vor allem die dabei erzeugte Datenmenge. Miss deshalb den Offset-Zuwachs \u00fcber die Zeit und plane Reserve ein. Der Backlog reduziert teure Neuabgleiche, macht die asynchrone Replikation aber nicht verlustfrei. Pr\u00fcfe zus\u00e4tzlich Speicherbudget, Replica-Buffer, Persistenz und Failover-Abl\u00e4ufe.","version_note":"Behandelt Redis Open Source; die Unterschiede zu Redis Software beziehen sich ausdr\u00fccklich auf die Dokumentation f\u00fcr Version 7.8. Die Failover-bezogene zweite Replikations-ID wird f\u00fcr Redis 4.0 und neuer erw\u00e4hnt; die gemeinsame Speicherbetrachtung von Backlog und Replica-Buffer f\u00fcr Redis 7.0 und neuer."},"_wh_make_word_report":{"words":1011,"min":2000,"max":3000,"target":2500,"ok":false,"missing":989,"excess":0,"lead_words":55,"section_words":{"grundprinzip":166,"psync-grenze":256,"groesse-planen":192,"konfiguration":136,"monitoring-und-grenzen":206}},"_wh_make_review":{"verdict":"needs_review","issues":["Abschnitt \u201emonitoring-und-grenzen\u201c, Block 4: Die Aussage stellt `replica-full-sync-buffer-limit` als allgemein verf\u00fcgbaren Redis-OSS-Schutzmechanismus dar. Die zugeordnete Quelle S4 verweist jedoch auf den unversionierten Entwicklungszweig `unstable`; die Direktive ist dort belegt, aber damit nicht automatisch f\u00fcr alle vom Artikel abgedeckten Redis-Versionen. Korrekturrichtung: eine konkrete unterst\u00fctzte Redis-Version beziehungsweise einen stabilen Release-Beleg nennen oder die Direktive aus dem versions\u00fcbergreifenden Text entfernen und nur `client-output-buffer-limit replica` allgemein behandeln.","Abschnitt \u201ekonfiguration\u201c, Bl\u00f6cke 1\u20132: Der Text bezeichnet `repl-backlog-size 1mb` und `repl-backlog-ttl 3600` als Werte der mitgelieferten Vorlage, w\u00e4hrend S4 beide Zeilen auskommentiert zeigt. Der Codeblock stellt sie dagegen als aktive Konfiguration dar. Korrekturrichtung: die Kommentarzeichen aus der Vorlage \u00fcbernehmen oder ausdr\u00fccklich kennzeichnen, dass die Zeilen zur Demonstration aktiviert wurden. Au\u00dferdem sollte f\u00fcr produktbezogene Versionsaussagen statt des beweglichen `unstable`-Branches ein passender stabiler Release- oder Tag-Beleg verwendet werden.","Bild \u201edetail2\u201c zum Abschnitt \u201egroesse-planen\u201c: Prompt und Alt-Text visualisieren Backlog und Replica-Puffer als getrennte Speicherbereiche. Das kann der unmittelbar davor erl\u00e4uterten Redis-7.0+-Eigenschaft widersprechen, nach der Replica-Buffer Speicher mit dem Replication Backlog teilen. Korrekturrichtung: einen gemeinsam genutzten Replikationsspeicherbereich mit logisch unterscheidbaren Belegungen darstellen oder die Illustration ausdr\u00fccklich als versionsunabh\u00e4ngiges, rein logisches Modell kennzeichnen.","Artikelweite Versionsabgrenzung: Der Beitrag beansprucht Redis Open Source allgemein, kombiniert aber stabile, seit Redis 4.0 beziehungsweise 7.0 dokumentierte Eigenschaften mit einer Direktive aus `unstable`. Die `version_note` erw\u00e4hnt diese Einschr\u00e4nkung nicht. Korrekturrichtung: getesteten beziehungsweise dokumentierten Versionsbereich festlegen und entwicklungszweigspezifische Funktionen gesondert markieren. Die \u00fcbrigen Kernaussagen zu PSYNC, ID und Offset, Backlog-Feldern, asynchroner Replikation sowie Redis Software 7.8 werden von den gepr\u00fcften Quellen gest\u00fctzt; das Rechenbeispiel 1.440 MiB \u2248 1,41 GiB ist korrekt und als Planungsn\u00e4herung gekennzeichnet."],"checked_source_ids":["S1","S2","S3","S4","S5"],"summary":"Automatische Pr\u00fcfung: Die fachliche Kerndarstellung und die Gr\u00f6\u00dfenrechnung sind \u00fcberwiegend schl\u00fcssig. \u00dcberarbeitet werden m\u00fcssen vor allem die nicht versionsgebundene Verwendung einer nur \u00fcber `unstable` belegten Direktive, die Darstellung auskommentierter Vorlagenwerte als aktive Konfiguration und die missverst\u00e4ndliche Speicherillustration. Dieses Ergebnis ist keine Garantie auf Fehlerfreiheit."},"_wh_make_review_doc_hash":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,"inline_featured_image":null,"_yoast_wpseo_linkdex":null,"_eael_widget_elements":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_trp_translated_slug_en_us":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_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_wh_make_writer_raw":"{\"title\":\"Redis Replication Backlog verstehen: PSYNC, Gr\u00f6\u00dfe und HA-Grenzen\",\"slug\":\"redis-replication-backlog-verstehen\",\"excerpt\":\"Der Redis Replication Backlog h\u00e4lt einen begrenzten Ausschnitt des Replikationsstroms vor. Er erm\u00f6glicht nach kurzen Verbindungsabbr\u00fcchen oft PSYNC statt Full Resync, ersetzt aber weder persistente Datenhaltung noch ein durchdachtes Hochverf\u00fcgbarkeitskonzept.\",\"seo\":{\"title\":\"Redis Replication Backlog verstehen und richtig planen\",\"description\":\"Erfahre, was der Redis Replication Backlog speichert, wie PSYNC funktioniert, wie du die Gr\u00f6\u00dfe planst und welche Grenzen f\u00fcr High Availability gelten.\",\"focus_keyword\":\"Redis Replication Backlog\"},\"lead\":[{\"kind\":\"text\",\"text\":\"Der Redis Replication Backlog ist ein begrenzter Speicherpuffer f\u00fcr bereits erzeugte Replikationsdaten. Kann eine Replica nach einer Unterbrechung an ihrer bekannten Replikationshistorie und ihrem Offset ankn\u00fcpfen, erh\u00e4lt sie \u00fcber PSYNC nur die fehlenden Bytes statt eines vollst\u00e4ndigen Neuabgleichs. \" ,\"ref\":\"\"},{\"kind\":\"citation\",\"text\":\"\",\"ref\":\"S1\"},{\"kind\":\"text\",\"text\":\"Das reduziert Full Resyncs, macht die standardm\u00e4\u00dfig asynchrone Redis-Replikation aber weder synchron noch verlustfrei bei einem Primary-Ausfall. \",\"ref\":\"\"},{\"kind\":\"citation\",\"text\":\"\",\"ref\":\"S3\"}],\"sections\":[{\"id\":\"grundprinzip\",\"heading\":\"Was der Backlog speichert \u2013 und was nicht\",\"blocks\":[{\"type\":\"paragraph\",\"runs\":[{\"kind\":\"text\",\"text\":\"Ein Redis Primary erzeugt aus \u00c4nderungen einen fortlaufenden Replikationsstrom. Der Replication Backlog bewahrt davon einen begrenzten j\u00fcngeren Abschnitt im Speicher auf. Er ist damit kein zweiter Datensatzbestand, kein Snapshot und kein Ersatz f\u00fcr RDB- oder AOF-Persistenz. Sein Zweck ist eng umrissen: Eine getrennte Replica soll eine kurzzeitige L\u00fccke im Datenstrom schlie\u00dfen k\u00f6nnen. \",\"ref\":\"\"},{\"kind\":\"citation\",\"text\":\"\",\"ref\":\"S1\"}]},{\"type\":\"paragraph\",\"runs\":[{\"kind\":\"text\",\"text\":\"Entscheidend ist das Paar aus Replikations-ID und Offset. Die ID kennzeichnet eine Datenhistorie, der Offset eine Position darin. Der Offset w\u00e4chst byteweise mit dem Replikationsstrom \u2013 auch dann, wenn aktuell keine Replica verbunden ist. Eine Replica meldet bei der Wiederverbindung ihre bekannte ID und ihren zuletzt verarbeiteten Offset. Stimmen Historie und verf\u00fcgbarer Bereich \u00fcberein, kann der Primary die fehlenden Daten nachreichen. \",\"ref\":\"\"},{\"kind\":\"citation\",\"text\":\"\",\"ref\":\"S1\"}]},{\"type\":\"paragraph\",\"runs\":[{\"kind\":\"text\",\"text\":\"Der praktische Unterschied ist erheblich: Bei einer partiellen Resynchronisierung bleibt der Nachholvorgang auf die L\u00fccke begrenzt. Ist die L\u00fccke nicht mehr im Backlog oder passt die Historie nicht, folgt ein Full Resync. Dann erstellt beziehungsweise liefert Redis einen RDB-Snapshot und \u00fcbertr\u00e4gt anschlie\u00dfend \u00c4nderungen, die w\u00e4hrenddessen angefallen sind. \",\"ref\":\"\"},{\"kind\":\"citation\",\"text\":\"\",\"ref\":\"S1\"}]}]},{\"id\":\"psync-grenze\",\"heading\":\"Wann PSYNC funktioniert und wann ein Full Resync n\u00f6tig wird\",\"blocks\":[{\"type\":\"paragraph\",\"runs\":[{\"kind\":\"text\",\"text\":\"Die zentrale Frage lautet nicht: \u201eWie viele Sekunden darf die Replica ausfallen?\u201c Sondern: \u201eWie viele Bytes des Replikationsstroms entstehen w\u00e4hrend dieser Unterbrechung?\u201c Ein Backlog mit 256 MiB kann bei geringer Schreibrate lange reichen und bei hoher Schreibrate sehr schnell \u00fcberschrieben sein. Redis verwirft die \u00e4ltesten Bytes, sobald neuer Replikationsstrom den konfigurierten Speicherbereich f\u00fcllt.\",\"ref\":\"\"},{\"kind\":\"citation\",\"text\":\"\",\"ref\":\"S2\"}]},{\"type\":\"paragraph\",\"runs\":[{\"kind\":\"text\",\"text\":\"Auf dem Primary beschreibt \",\"ref\":\"\"},{\"kind\":\"code\",\"text\":\"repl_backlog_first_byte_offset\",\"ref\":\"\"},{\"kind\":\"text\",\"text\":\" den \u00e4ltesten noch verf\u00fcgbaren Offset. Fordert eine Replica einen \u00e4lteren Stand an, liegt ihre L\u00fccke au\u00dferhalb der Historie: PSYNC kann nicht greifen. \",\"ref\":\"\"},{\"kind\":\"code\",\"text\":\"repl_backlog_histlen\",\"ref\":\"\"},{\"kind\":\"text\",\"text\":\" zeigt dagegen, wie viele historische Bytes derzeit tats\u00e4chlich im Backlog liegen; \",\"ref\":\"\"},{\"kind\":\"code\",\"text\":\"repl_backlog_size\",\"ref\":\"\"},{\"kind\":\"text\",\"text\":\" ist die konfigurierte Obergrenze. \",\"ref\":\"\"},{\"kind\":\"citation\",\"text\":\"\",\"ref\":\"S2\"}]},{\"type\":\"paragraph\",\"runs\":[{\"kind\":\"text\",\"text\":\"Nach einem Failover ist die Lage nicht zwangsl\u00e4ufig verloren. Eine zur Primary bef\u00f6rderte Replica beh\u00e4lt zus\u00e4tzlich die vorherige Replikations-ID als sekund\u00e4re ID. Dadurch k\u00f6nnen andere Replicas unter bestimmten Bedingungen auch nach dem Rollenwechsel partiell synchronisieren. Redis dokumentiert diese F\u00e4higkeit f\u00fcr Redis 4.0 und neuer; sie ersetzt jedoch keine Pr\u00fcfung des tats\u00e4chlichen Backlog-Bereichs und der Topologie. \",\"ref\":\"\"},{\"kind\":\"citation\",\"text\":\"\",\"ref\":\"S1\"}]},{\"type\":\"table\",\"caption\":\"Entscheidungslogik f\u00fcr die Wiederanbindung einer Redis-Replica\",\"headers\":[\"Situation\",\"ID und Offset\",\"Ergebnis\",\"Betriebliche Folge\"],\"rows\":[[\"Kurze Unterbrechung, fehlende Bytes liegen noch im Backlog\",\"Historie g\u00fcltig, Offset abgedeckt\",\"Partielle Resynchronisierung per PSYNC\",\"Nur die L\u00fccke wird \u00fcbertragen\"],[\"Unterbrechung oder Schreibrate \u00fcbersteigt die Backlog-Reichweite\",\"Angeforderter Offset \u00e4lter als der erste Backlog-Offset\",\"Full Resync\",\"RDB-Transfer und Nachlieferung laufender \u00c4nderungen\"],[\"Failover mit weiter nutzbarer Vorg\u00e4ngerhistorie\",\"Sekund\u00e4re Replikations-ID kann passen\",\"PSYNC kann m\u00f6glich sein\",\"Abh\u00e4ngig von Historie und vorgehaltenem Bereich\"],[\"Keine Replica \u00fcber l\u00e4ngere Zeit und Backlog-TTL abgelaufen\",\"Kein nutzbarer Backlog vorhanden\",\"Sp\u00e4tere Replica ben\u00f6tigt Full Resync\",\"Historie wurde automatisch freigegeben\"]],\"source_ids\":[\"S1\",\"S2\",\"S4\"]}]},{\"id\":\"groesse-planen\",\"heading\":\"Backlog-Gr\u00f6\u00dfe aus der Replikationsrate ableiten\",\"blocks\":[{\"type\":\"paragraph\",\"runs\":[{\"kind\":\"text\",\"text\":\"F\u00fcr Redis Open Source gibt es keine belastbare allgemeine Prozentregel bezogen auf die Datenbankgr\u00f6\u00dfe. Plane deshalb nicht mit Operationen pro Sekunde, sondern mit dem beobachteten Bytezuwachs des Replikationsstroms. Befehlsgr\u00f6\u00dfe, Wertgr\u00f6\u00dfen, L\u00f6schungen, TTL-bezogene \u00c4nderungen und Pipelines beeinflussen diese Rate. Zwei Anwendungen mit gleicher Request-Zahl k\u00f6nnen daher deutlich unterschiedliche Backlog-Anforderungen haben.\",\"ref\":\"\"}]},{\"type\":\"paragraph\",\"runs\":[{\"kind\":\"text\",\"text\":\"Eine brauchbare Planungsn\u00e4herung lautet: ben\u00f6tigter Backlog mindestens gleich Spitzenrate des Replikationsstroms mal maximal zu \u00fcberbr\u00fcckende Unterbrechung plus Sicherheitsreserve. Miss dazu auf dem Primary wiederholt \",\"ref\":\"\"},{\"kind\":\"code\",\"text\":\"master_repl_offset\",\"ref\":\"\"},{\"kind\":\"text\",\"text\":\" und teile die Offset-Differenz durch das Zeitintervall. Die INFO-Ausgabe liefert au\u00dferdem die Backlog-Grenzen und auf einer Replica Link-Status sowie deren Offset. \",\"ref\":\"\"},{\"kind\":\"citation\",\"text\":\"\",\"ref\":\"S2\"}]},{\"type\":\"paragraph\",\"runs\":[{\"kind\":\"text\",\"text\":\"Beispiel: Im beobachteten Spitzenzeitraum entstehen durchschnittlich 12 MiB pro Sekunde. Eine Replica soll 90 Sekunden Netzunterbrechung und zus\u00e4tzlich 30 Sekunden Reserve \u00fcberbr\u00fccken. Die Rechnung lautet \",\"ref\":\"\"},{\"kind\":\"code\",\"text\":\"12 MiB\/s \u00d7 (90 s + 30 s) = 1.440 MiB\",\"ref\":\"\"},{\"kind\":\"text\",\"text\":\". Das entspricht rund 1,41 GiB. Dieser Wert ist kein Redis-Versprechen, sondern ein Startwert f\u00fcr Kapazit\u00e4tsplanung. Lastspitzen, l\u00e4ngere St\u00f6rungen und Messungenauigkeit brauchen zus\u00e4tzliche, lokal begr\u00fcndete Reserve.\",\"ref\":\"\"}]},{\"type\":\"paragraph\",\"runs\":[{\"kind\":\"text\",\"text\":\"Der Speicherbedarf muss in das gesamte RAM-Budget passen. Seit Redis 7.0 teilen sich Replica-Buffer und Backlog Speicher; deshalb kann \",\"ref\":\"\"},{\"kind\":\"code\",\"text\":\"mem_clients_slaves\",\"ref\":\"\"},{\"kind\":\"text\",\"text\":\" trotz verbundener Replicas null sein. F\u00fcr die Gesamtbetrachtung sind insbesondere \",\"ref\":\"\"},{\"kind\":\"code\",\"text\":\"mem_replication_backlog\",\"ref\":\"\"},{\"kind\":\"text\",\"text\":\" und \",\"ref\":\"\"},{\"kind\":\"code\",\"text\":\"mem_total_replication_buffers\",\"ref\":\"\"},{\"kind\":\"text\",\"text\":\" relevant. \",\"ref\":\"\"},{\"kind\":\"citation\",\"text\":\"\",\"ref\":\"S2\"}]}]},{\"id\":\"konfiguration\",\"heading\":\"Konfiguration: Vorlage verstehen, nicht blind \u00fcbernehmen\",\"blocks\":[{\"type\":\"paragraph\",\"runs\":[{\"kind\":\"text\",\"text\":\"Die mitgelieferte Redis-Konfigurationsvorlage enth\u00e4lt folgende Werte. Sie sind Beispielwerte und keine pauschale Produktionsdimensionierung. \",\"ref\":\"\"},{\"kind\":\"citation\",\"text\":\"\",\"ref\":\"S4\"}]},{\"type\":\"code\",\"language\":\"conf\",\"code\":\"# redis.conf \u2013 Beispielwerte aus der mitgelieferten Konfigurationsvorlage\\nrepl-backlog-size 1mb\\nrepl-backlog-ttl 3600\",\"source_ids\":[\"S4\"]},{\"type\":\"paragraph\",\"runs\":[{\"kind\":\"text\",\"text\":\"In Redis OSS wird der Backlog erst angelegt, wenn mindestens eine Replica verbunden ist. Trennt sich die letzte Replica, gibt \",\"ref\":\"\"},{\"kind\":\"code\",\"text\":\"repl-backlog-ttl\",\"ref\":\"\"},{\"kind\":\"text\",\"text\":\" an, wann Redis ihn freigibt. Der Wert \",\"ref\":\"\"},{\"kind\":\"code\",\"text\":\"0\",\"ref\":\"\"},{\"kind\":\"text\",\"text\":\" verhindert diese automatische Freigabe. Das kann sinnvoll sein, wenn eine sp\u00e4ter wiederkehrende Replica m\u00f6glichst noch PSYNC nutzen soll, kostet aber dauerhaft Speicher. Replicas selbst geben ihren Backlog laut Konfigurationskommentar nicht per TTL frei, weil sie sp\u00e4ter Primary werden k\u00f6nnten. \",\"ref\":\"\"},{\"kind\":\"citation\",\"text\":\"\",\"ref\":\"S4\"}]},{\"type\":\"paragraph\",\"runs\":[{\"kind\":\"text\",\"text\":\"Redis Software darf hier nicht mit Redis OSS gleichgesetzt werden. In der Redis-Software-Dokumentation 7.8 wird der Backlog pro Shard behandelt und kann \u00fcber Plattformbefehle oder automatisch eingestellt werden; die dort dokumentierte Auto-Regel ist keine Empfehlung f\u00fcr OSS. Wer beide Produkte betreibt, sollte Konfiguration, Einheit und Defaultwerte strikt getrennt dokumentieren. \",\"ref\":\"\"},{\"kind\":\"citation\",\"text\":\"\",\"ref\":\"S5\"}]}]},{\"id\":\"monitoring-und-grenzen\",\"heading\":\"Monitoring und die Grenzen f\u00fcr High Availability\",\"blocks\":[{\"type\":\"paragraph\",\"runs\":[{\"kind\":\"text\",\"text\":\"Beginne die Diagnose mit folgendem Befehl:\",\"ref\":\"\"}]},{\"type\":\"code\",\"language\":\"text\",\"code\":\"INFO replication\",\"source_ids\":[\"S2\"]},{\"type\":\"paragraph\",\"runs\":[{\"kind\":\"text\",\"text\":\"Auf dem Primary pr\u00fcfst du \",\"ref\":\"\"},{\"kind\":\"code\",\"text\":\"master_repl_offset\",\"ref\":\"\"},{\"kind\":\"text\",\"text\":\", \",\"ref\":\"\"},{\"kind\":\"code\",\"text\":\"repl_backlog_first_byte_offset\",\"ref\":\"\"},{\"kind\":\"text\",\"text\":\", \",\"ref\":\"\"},{\"kind\":\"code\",\"text\":\"repl_backlog_histlen\",\"ref\":\"\"},{\"kind\":\"text\",\"text\":\" und \",\"ref\":\"\"},{\"kind\":\"code\",\"text\":\"repl_backlog_size\",\"ref\":\"\"},{\"kind\":\"text\",\"text\":\". Auf einer Replica sind \",\"ref\":\"\"},{\"kind\":\"code\",\"text\":\"master_link_status\",\"ref\":\"\"},{\"kind\":\"text\",\"text\":\", \",\"ref\":\"\"},{\"kind\":\"code\",\"text\":\"slave_repl_offset\",\"ref\":\"\"},{\"kind\":\"text\",\"text\":\" sowie bei Unterbrechungen \",\"ref\":\"\"},{\"kind\":\"code\",\"text\":\"master_link_down_since_seconds\",\"ref\":\"\"},{\"kind\":\"text\",\"text\":\" aufschlussreich. Alarmiere nicht nur bei einem getrennten Link, sondern auch, wenn die gesch\u00e4tzte Backlog-Reichweite kleiner wird als die realistische Wiederherstellungszeit. \",\"ref\":\"\"},{\"kind\":\"citation\",\"text\":\"\",\"ref\":\"S2\"}]},{\"type\":\"paragraph\",\"runs\":[{\"kind\":\"text\",\"text\":\"Ein gr\u00f6\u00dferer Backlog l\u00f6st keine Probleme mit langsamen Replicas w\u00e4hrend eines Full Resync. Daf\u00fcr existieren getrennte Schutzmechanismen: \",\"ref\":\"\"},{\"kind\":\"code\",\"text\":\"replica-full-sync-buffer-limit\",\"ref\":\"\"},{\"kind\":\"text\",\"text\":\" begrenzt den Puffer auf Replica-Seite, \",\"ref\":\"\"},{\"kind\":\"code\",\"text\":\"client-output-buffer-limit replica\",\"ref\":\"\"},{\"kind\":\"text\",\"text\":\" betrifft den Replica-Client-Output-Buffer auf dem Primary. Diese Werte und der Backlog erf\u00fcllen unterschiedliche Aufgaben und m\u00fcssen gemeinsam in die Speicherplanung einflie\u00dfen. \",\"ref\":\"\"},{\"kind\":\"citation\",\"text\":\"\",\"ref\":\"S4\"}]},{\"type\":\"paragraph\",\"runs\":[{\"kind\":\"text\",\"text\":\"F\u00fcr High Availability ist der Backlog daher ein Verf\u00fcgbarkeitsbaustein: Er verringert nach kurzen Fehlern die Wahrscheinlichkeit kostspieliger Full Resyncs. Replikation bleibt jedoch standardm\u00e4\u00dfig asynchron. Bei einem Primary-Ausfall k\u00f6nnen best\u00e4tigte Client-Schreibvorg\u00e4nge fehlen, die noch nicht auf einer Replica angekommen sind. \",\"ref\":\"\"},{\"kind\":\"citation\",\"text\":\"\",\"ref\":\"S3\"},{\"kind\":\"text\",\"text\":\" \",\"ref\":\"\"},{\"kind\":\"code\",\"text\":\"WAIT\",\"ref\":\"\"},{\"kind\":\"text\",\"text\":\" kann Replica-Best\u00e4tigungen anfordern, liefert laut Redis aber keine starke Konsistenzgarantie. \",\"ref\":\"\"},{\"kind\":\"citation\",\"text\":\"\",\"ref\":\"S3\"}]},{\"type\":\"paragraph\",\"runs\":[{\"kind\":\"text\",\"text\":\"Auch \",\"ref\":\"\"},{\"kind\":\"code\",\"text\":\"min-replicas-to-write\",\"ref\":\"\"},{\"kind\":\"text\",\"text\":\" und \",\"ref\":\"\"},{\"kind\":\"code\",\"text\":\"min-replicas-max-lag\",\"ref\":\"\"},{\"kind\":\"text\",\"text\":\" begrenzen unter bestimmten Bedingungen die Annahme neuer Writes, garantieren aber nicht, dass die geforderte Zahl von Replicas einen konkreten Write dauerhaft \u00fcbernommen hat. Erg\u00e4nze den Backlog deshalb um passende Failover-Abl\u00e4ufe, Persistenz, getestete Wiederherstellung und ein klares Datenverlustziel. F\u00fcr die praktische Auswertung von Offsets kann auch der interne Leitfaden \",\"ref\":\"\"},{\"kind\":\"internal_link\",\"text\":\"Redis Replication Offset analysieren\",\"ref\":\"I1\"},{\"kind\":\"text\",\"text\":\" weiterhelfen.\",\"ref\":\"\"}]}]}],\"images\":{\"hero\":{\"prompt\":\"Editoriale, realistische technische Illustration f\u00fcr einen Fachartikel: ein Redis-Primary als zentraler Knoten links sendet einen leuchtenden Datenstrom zu zwei Replica-Knoten rechts. Im Datenstrom befindet sich ein deutlich erkennbarer ringf\u00f6rmiger Pufferspeicher, der j\u00fcngere Datenabschnitte h\u00e4lt; eine kurz getrennte Verbindung zu einer Replica wird wieder geschlossen und der fehlende Abschnitt flie\u00dft nach. Dunkler, ruhiger Serverraum-Hintergrund, klare r\u00e4umliche Trennung der Komponenten, Rot- und warme Akzentfarben, keine Markenlogos. Keine W\u00f6rter, Zahlen, Labels, Diagrammlegenden oder UI-Screenshots.\",\"alt\":\"Illustration eines Primary mit ringf\u00f6rmigem Replikationspuffer und zwei wieder angebundenen Redis-Replicas.\",\"caption\":\"Illustrative Darstellung: Der Backlog h\u00e4lt einen j\u00fcngeren Abschnitt des Replikationsstroms f\u00fcr wiederkehrende Replicas vor.\",\"filename_base\":\"redis-backlog-psync\",\"section_id\":\"\",\"after_block\":0},\"detail1\":{\"prompt\":\"Klare konzeptionelle Illustration einer horizontalen Zeitachse f\u00fcr Redis-Replikation: links ein \u00e4lterer, verblassender Datenstrom, in der Mitte ein begrenzter ringf\u00f6rmiger Speicherbereich mit sichtbaren j\u00fcngeren Datenpaketen, rechts neue Datenpakete. Eine Replica-Verbindung setzt an einer Position innerhalb des Ringbereichs wieder ein, eine zweite gestrichelte Verbindung versucht weit links au\u00dferhalb des Ringbereichs anzusetzen und wird in einen vollst\u00e4ndigen Datentransfer \u00fcbergeleitet. Visuell intuitiv, technische Vektor-\u00c4sthetik, keine Beschriftungen, W\u00f6rter, Zahlen, Legenden oder Marken.\",\"alt\":\"Zeitachsenillustration mit verf\u00fcgbarem Backlog-Bereich und einer zu alten Replikationsl\u00fccke.\",\"caption\":\"Illustrative Darstellung: Ob PSYNC gelingt, h\u00e4ngt davon ab, ob der ben\u00f6tigte Offset noch im vorgehaltenen Bereich liegt.\",\"filename_base\":\"redis-psync-offset-range\",\"section_id\":\"psync-grenze\",\"after_block\":2},\"detail2\":{\"prompt\":\"Technische konzeptionelle Illustration zur Speicherkapazit\u00e4tsplanung: ein Server-Speichercontainer ist in mehrere farbige, unterschiedlich gro\u00dfe Bereiche gegliedert, darunter ein wachsender Replikationspuffer und getrennte Puffer f\u00fcr Replica-Daten. Daneben flie\u00dft ein variabler Strom aus Datenpaketen in den Replikationspuffer; eine kurze Unterbrechung wird durch den gespeicherten Abschnitt \u00fcberbr\u00fcckt. Fokus auf Verh\u00e4ltnis von Datenrate, Unterbrechungsdauer und RAM-Budget, ohne exakte Messskalen. Sachliche isometrische Vektorillustration, keine W\u00f6rter, Zahlen, Labels, Legenden, Logos oder erfundene Dashboards.\",\"alt\":\"Illustration eines Server-Speicherbudgets mit Replikationsbacklog und getrennten Replica-Puffern.\",\"caption\":\"Illustrative Darstellung: Die Backlog-Gr\u00f6\u00dfe wird aus Datenrate und gew\u00fcnschter \u00dcberbr\u00fcckungszeit geplant und dem RAM-Budget gegen\u00fcbergestellt.\",\"filename_base\":\"redis-backlog-memory-budget\",\"section_id\":\"groesse-planen\",\"after_block\":3}},\"chart\":null,\"social\":{\"facebook\":\"Redis Backlog richtig planen: Wann PSYNC gelingt und warum der Puffer keine Datenverlustgarantie ist.\",\"instagram\":\"PSYNC statt Full Resync: So h\u00e4ngt die Redis-Backlog-Gr\u00f6\u00dfe von Byte-Rate und Ausfallzeit ab.\",\"tiktok\":\"Redis Backlog erkl\u00e4rt: Warum Sekunden allein nicht entscheiden, ob PSYNC funktioniert.\",\"youtube\":\"Redis Replication Backlog: PSYNC, Dimensionierung und Grenzen f\u00fcr HA verst\u00e4ndlich erkl\u00e4rt.\",\"threads\":\"Der Redis Backlog puffert Replikationsbytes, nicht deine Datenbank. Entscheidend sind Offset, Historie und Schreibrate.\",\"x\":\"Redis Replication Backlog: PSYNC klappt nur, wenn ID, Offset und vorgehaltener Bytebereich zusammenpassen. Gr\u00f6\u00dfe nach Replikationsrate und \u00dcberbr\u00fcckungszeit planen \u2013 nicht nach pauschalen Prozentwerten.\"},\"avatar_script\":\"Der Redis Replication Backlog ist ein Speicherpuffer f\u00fcr einen begrenzten Teil des Replikationsstroms. F\u00e4llt die Verbindung einer Replica kurz aus, kann sie ihre Replikations-ID und ihren letzten Offset melden. Liegen die fehlenden Bytes noch im Backlog, liefert Redis sie per PSYNC nach. Andernfalls ist ein Full Resync mit RDB-\u00dcbertragung erforderlich. F\u00fcr die Gr\u00f6\u00dfe z\u00e4hlt nicht nur die Dauer einer Unterbrechung, sondern vor allem die dabei erzeugte Datenmenge. Miss deshalb den Offset-Zuwachs \u00fcber die Zeit und plane Reserve ein. Der Backlog reduziert teure Neuabgleiche, macht die asynchrone Replikation aber nicht verlustfrei. Pr\u00fcfe zus\u00e4tzlich Speicherbudget, Replica-Buffer, Persistenz und Failover-Abl\u00e4ufe.\",\"version_note\":\"Behandelt Redis Open Source; die Unterschiede zu Redis Software beziehen sich ausdr\u00fccklich auf die Dokumentation f\u00fcr Version 7.8. Die Failover-bezogene zweite Replikations-ID wird f\u00fcr Redis 4.0 und neuer erw\u00e4hnt; die gemeinsame Speicherbetrachtung von Backlog und Replica-Buffer f\u00fcr Redis 7.0 und neuer.\"}","_wh_make_design_backup_204":{"post_content":"<!-- wp:html -->\n<div class=\"wh-article\"><p class=\"wh-lead\">Der Redis Replication Backlog ist ein begrenzter Speicherpuffer f\u00fcr bereits erzeugte Replikationsdaten. Kann eine Replica nach einer Unterbrechung an ihrer bekannten Replikationshistorie und ihrem Offset ankn\u00fcpfen, erh\u00e4lt sie \u00fcber PSYNC nur die fehlenden Bytes statt eines vollst\u00e4ndigen Neuabgleichs. <sup class=\"wh-source-ref\"><a href=\"#wh-source-S1\">[S1]<\/a><\/sup>Das reduziert Full Resyncs, macht die standardm\u00e4\u00dfig asynchrone Redis-Replikation aber weder synchron noch verlustfrei bei einem Primary-Ausfall. <sup class=\"wh-source-ref\"><a href=\"#wh-source-S3\">[S3]<\/a><\/sup><\/p><h2 id=\"grundprinzip\">Was der Backlog speichert \u2013 und was nicht<\/h2><p>Ein Redis Primary erzeugt aus \u00c4nderungen einen fortlaufenden Replikationsstrom. Der Replication Backlog bewahrt davon einen begrenzten j\u00fcngeren Abschnitt im Speicher auf. Er ist damit kein zweiter Datensatzbestand, kein Snapshot und kein Ersatz f\u00fcr RDB- oder AOF-Persistenz. Sein Zweck ist eng umrissen: Eine getrennte Replica soll eine kurzzeitige L\u00fccke im Datenstrom schlie\u00dfen k\u00f6nnen. <sup class=\"wh-source-ref\"><a href=\"#wh-source-S1\">[S1]<\/a><\/sup><\/p><p>Entscheidend ist das Paar aus Replikations-ID und Offset. Die ID kennzeichnet eine Datenhistorie, der Offset eine Position darin. Der Offset w\u00e4chst byteweise mit dem Replikationsstrom \u2013 auch dann, wenn aktuell keine Replica verbunden ist. Eine Replica meldet bei der Wiederverbindung ihre bekannte ID und ihren zuletzt verarbeiteten Offset. Stimmen Historie und verf\u00fcgbarer Bereich \u00fcberein, kann der Primary die fehlenden Daten nachreichen. <sup class=\"wh-source-ref\"><a href=\"#wh-source-S1\">[S1]<\/a><\/sup><\/p><p>Der praktische Unterschied ist erheblich: Bei einer partiellen Resynchronisierung bleibt der Nachholvorgang auf die L\u00fccke begrenzt. Ist die L\u00fccke nicht mehr im Backlog oder passt die Historie nicht, folgt ein Full Resync. Dann erstellt beziehungsweise liefert Redis einen RDB-Snapshot und \u00fcbertr\u00e4gt anschlie\u00dfend \u00c4nderungen, die w\u00e4hrenddessen angefallen sind. <sup class=\"wh-source-ref\"><a href=\"#wh-source-S1\">[S1]<\/a><\/sup><\/p><h2 id=\"psync-grenze\">Wann PSYNC funktioniert und wann ein Full Resync n\u00f6tig wird<\/h2><p>Die zentrale Frage lautet nicht: \u201eWie viele Sekunden darf die Replica ausfallen?\u201c Sondern: \u201eWie viele Bytes des Replikationsstroms entstehen w\u00e4hrend dieser Unterbrechung?\u201c Ein Backlog mit 256 MiB kann bei geringer Schreibrate lange reichen und bei hoher Schreibrate sehr schnell \u00fcberschrieben sein. Redis verwirft die \u00e4ltesten Bytes, sobald neuer Replikationsstrom den konfigurierten Speicherbereich f\u00fcllt.<sup class=\"wh-source-ref\"><a href=\"#wh-source-S2\">[S2]<\/a><\/sup><\/p><p>Auf dem Primary beschreibt <code data-no-translation>repl_backlog_first_byte_offset<\/code> den \u00e4ltesten noch verf\u00fcgbaren Offset. Fordert eine Replica einen \u00e4lteren Stand an, liegt ihre L\u00fccke au\u00dferhalb der Historie: PSYNC kann nicht greifen. <code data-no-translation>repl_backlog_histlen<\/code> zeigt dagegen, wie viele historische Bytes derzeit tats\u00e4chlich im Backlog liegen; <code data-no-translation>repl_backlog_size<\/code> ist die konfigurierte Obergrenze. <sup class=\"wh-source-ref\"><a href=\"#wh-source-S2\">[S2]<\/a><\/sup><\/p><p>Nach einem Failover ist die Lage nicht zwangsl\u00e4ufig verloren. Eine zur Primary bef\u00f6rderte Replica beh\u00e4lt zus\u00e4tzlich die vorherige Replikations-ID als sekund\u00e4re ID. Dadurch k\u00f6nnen andere Replicas unter bestimmten Bedingungen auch nach dem Rollenwechsel partiell synchronisieren. Redis dokumentiert diese F\u00e4higkeit f\u00fcr Redis 4.0 und neuer; sie ersetzt jedoch keine Pr\u00fcfung des tats\u00e4chlichen Backlog-Bereichs und der Topologie. <sup class=\"wh-source-ref\"><a href=\"#wh-source-S1\">[S1]<\/a><\/sup><\/p><div class=\"wh-table-scroll\" tabindex=\"0\"><table><caption>Entscheidungslogik f\u00fcr die Wiederanbindung einer Redis-Replica<\/caption><thead><tr><th scope=\"col\">Situation<\/th><th scope=\"col\">ID und Offset<\/th><th scope=\"col\">Ergebnis<\/th><th scope=\"col\">Betriebliche Folge<\/th><\/tr><\/thead><tbody><tr><td>Kurze Unterbrechung, fehlende Bytes liegen noch im Backlog<\/td><td>Historie g\u00fcltig, Offset abgedeckt<\/td><td>Partielle Resynchronisierung per PSYNC<\/td><td>Nur die L\u00fccke wird \u00fcbertragen<\/td><\/tr><tr><td>Unterbrechung oder Schreibrate \u00fcbersteigt die Backlog-Reichweite<\/td><td>Angeforderter Offset \u00e4lter als der erste Backlog-Offset<\/td><td>Full Resync<\/td><td>RDB-Transfer und Nachlieferung laufender \u00c4nderungen<\/td><\/tr><tr><td>Failover mit weiter nutzbarer Vorg\u00e4ngerhistorie<\/td><td>Sekund\u00e4re Replikations-ID kann passen<\/td><td>PSYNC kann m\u00f6glich sein<\/td><td>Abh\u00e4ngig von Historie und vorgehaltenem Bereich<\/td><\/tr><tr><td>Keine Replica \u00fcber l\u00e4ngere Zeit und Backlog-TTL abgelaufen<\/td><td>Kein nutzbarer Backlog vorhanden<\/td><td>Sp\u00e4tere Replica ben\u00f6tigt Full Resync<\/td><td>Historie wurde automatisch freigegeben<\/td><\/tr><\/tbody><\/table><\/div><sup class=\"wh-source-ref\"><a href=\"#wh-source-S1\">[S1]<\/a><\/sup><sup class=\"wh-source-ref\"><a href=\"#wh-source-S2\">[S2]<\/a><\/sup><sup class=\"wh-source-ref\"><a href=\"#wh-source-S4\">[S4]<\/a><\/sup><h2 id=\"groesse-planen\">Backlog-Gr\u00f6\u00dfe aus der Replikationsrate ableiten<\/h2><p>F\u00fcr Redis Open Source gibt es keine belastbare allgemeine Prozentregel bezogen auf die Datenbankgr\u00f6\u00dfe. Plane deshalb nicht mit Operationen pro Sekunde, sondern mit dem beobachteten Bytezuwachs des Replikationsstroms. Befehlsgr\u00f6\u00dfe, Wertgr\u00f6\u00dfen, L\u00f6schungen, TTL-bezogene \u00c4nderungen und Pipelines beeinflussen diese Rate. Zwei Anwendungen mit gleicher Request-Zahl k\u00f6nnen daher deutlich unterschiedliche Backlog-Anforderungen haben.<\/p><p>Eine brauchbare Planungsn\u00e4herung lautet: ben\u00f6tigter Backlog mindestens gleich Spitzenrate des Replikationsstroms mal maximal zu \u00fcberbr\u00fcckende Unterbrechung plus Sicherheitsreserve. Miss dazu auf dem Primary wiederholt <code data-no-translation>master_repl_offset<\/code> und teile die Offset-Differenz durch das Zeitintervall. Die INFO-Ausgabe liefert au\u00dferdem die Backlog-Grenzen und auf einer Replica Link-Status sowie deren Offset. <sup class=\"wh-source-ref\"><a href=\"#wh-source-S2\">[S2]<\/a><\/sup><\/p><p>Beispiel: Im beobachteten Spitzenzeitraum entstehen durchschnittlich 12 MiB pro Sekunde. Eine Replica soll 90 Sekunden Netzunterbrechung und zus\u00e4tzlich 30 Sekunden Reserve \u00fcberbr\u00fccken. Die Rechnung lautet <code data-no-translation>12 MiB\/s \u00d7 (90 s + 30 s) = 1.440 MiB<\/code>. Das entspricht rund 1,41 GiB. Dieser Wert ist kein Redis-Versprechen, sondern ein Startwert f\u00fcr Kapazit\u00e4tsplanung. Lastspitzen, l\u00e4ngere St\u00f6rungen und Messungenauigkeit brauchen zus\u00e4tzliche, lokal begr\u00fcndete Reserve.<\/p><p>Der Speicherbedarf muss in das gesamte RAM-Budget passen. Seit Redis 7.0 teilen sich Replica-Buffer und Backlog Speicher; deshalb kann <code data-no-translation>mem_clients_slaves<\/code> trotz verbundener Replicas null sein. F\u00fcr die Gesamtbetrachtung sind insbesondere <code data-no-translation>mem_replication_backlog<\/code> und <code data-no-translation>mem_total_replication_buffers<\/code> relevant. <sup class=\"wh-source-ref\"><a href=\"#wh-source-S2\">[S2]<\/a><\/sup><\/p><h2 id=\"konfiguration\">Konfiguration: Vorlage verstehen, nicht blind \u00fcbernehmen<\/h2><p>Die mitgelieferte Redis-Konfigurationsvorlage enth\u00e4lt folgende Werte. Sie sind Beispielwerte und keine pauschale Produktionsdimensionierung. <sup class=\"wh-source-ref\"><a href=\"#wh-source-S4\">[S4]<\/a><\/sup><\/p><pre class=\"wh-code\" data-no-translation><code class=\"language-conf\"># redis.conf \u2013 Beispielwerte aus der mitgelieferten Konfigurationsvorlage\nrepl-backlog-size 1mb\nrepl-backlog-ttl 3600<\/code><\/pre><sup class=\"wh-source-ref\"><a href=\"#wh-source-S4\">[S4]<\/a><\/sup><p>In Redis OSS wird der Backlog erst angelegt, wenn mindestens eine Replica verbunden ist. Trennt sich die letzte Replica, gibt <code data-no-translation>repl-backlog-ttl<\/code> an, wann Redis ihn freigibt. Der Wert <code data-no-translation>0<\/code> verhindert diese automatische Freigabe. Das kann sinnvoll sein, wenn eine sp\u00e4ter wiederkehrende Replica m\u00f6glichst noch PSYNC nutzen soll, kostet aber dauerhaft Speicher. Replicas selbst geben ihren Backlog laut Konfigurationskommentar nicht per TTL frei, weil sie sp\u00e4ter Primary werden k\u00f6nnten. <sup class=\"wh-source-ref\"><a href=\"#wh-source-S4\">[S4]<\/a><\/sup><\/p><p>Redis Software darf hier nicht mit Redis OSS gleichgesetzt werden. In der Redis-Software-Dokumentation 7.8 wird der Backlog pro Shard behandelt und kann \u00fcber Plattformbefehle oder automatisch eingestellt werden; die dort dokumentierte Auto-Regel ist keine Empfehlung f\u00fcr OSS. Wer beide Produkte betreibt, sollte Konfiguration, Einheit und Defaultwerte strikt getrennt dokumentieren. <sup class=\"wh-source-ref\"><a href=\"#wh-source-S5\">[S5]<\/a><\/sup><\/p><h2 id=\"monitoring-und-grenzen\">Monitoring und die Grenzen f\u00fcr High Availability<\/h2><p>Beginne die Diagnose mit folgendem Befehl:<\/p><pre class=\"wh-code\" data-no-translation><code class=\"language-text\">INFO replication<\/code><\/pre><sup class=\"wh-source-ref\"><a href=\"#wh-source-S2\">[S2]<\/a><\/sup><p>Auf dem Primary pr\u00fcfst du <code data-no-translation>master_repl_offset<\/code>, <code data-no-translation>repl_backlog_first_byte_offset<\/code>, <code data-no-translation>repl_backlog_histlen<\/code> und <code data-no-translation>repl_backlog_size<\/code>. Auf einer Replica sind <code data-no-translation>master_link_status<\/code>, <code data-no-translation>slave_repl_offset<\/code> sowie bei Unterbrechungen <code data-no-translation>master_link_down_since_seconds<\/code> aufschlussreich. Alarmiere nicht nur bei einem getrennten Link, sondern auch, wenn die gesch\u00e4tzte Backlog-Reichweite kleiner wird als die realistische Wiederherstellungszeit. <sup class=\"wh-source-ref\"><a href=\"#wh-source-S2\">[S2]<\/a><\/sup><\/p><p>Ein gr\u00f6\u00dferer Backlog l\u00f6st keine Probleme mit langsamen Replicas w\u00e4hrend eines Full Resync. Daf\u00fcr existieren getrennte Schutzmechanismen: <code data-no-translation>replica-full-sync-buffer-limit<\/code> begrenzt den Puffer auf Replica-Seite, <code data-no-translation>client-output-buffer-limit replica<\/code> betrifft den Replica-Client-Output-Buffer auf dem Primary. Diese Werte und der Backlog erf\u00fcllen unterschiedliche Aufgaben und m\u00fcssen gemeinsam in die Speicherplanung einflie\u00dfen. <sup class=\"wh-source-ref\"><a href=\"#wh-source-S4\">[S4]<\/a><\/sup><\/p><p>F\u00fcr High Availability ist der Backlog daher ein Verf\u00fcgbarkeitsbaustein: Er verringert nach kurzen Fehlern die Wahrscheinlichkeit kostspieliger Full Resyncs. Replikation bleibt jedoch standardm\u00e4\u00dfig asynchron. Bei einem Primary-Ausfall k\u00f6nnen best\u00e4tigte Client-Schreibvorg\u00e4nge fehlen, die noch nicht auf einer Replica angekommen sind. <sup class=\"wh-source-ref\"><a href=\"#wh-source-S3\">[S3]<\/a><\/sup> <code data-no-translation>WAIT<\/code> kann Replica-Best\u00e4tigungen anfordern, liefert laut Redis aber keine starke Konsistenzgarantie. <sup class=\"wh-source-ref\"><a href=\"#wh-source-S3\">[S3]<\/a><\/sup><\/p><p>Auch <code data-no-translation>min-replicas-to-write<\/code> und <code data-no-translation>min-replicas-max-lag<\/code> begrenzen unter bestimmten Bedingungen die Annahme neuer Writes, garantieren aber nicht, dass die geforderte Zahl von Replicas einen konkreten Write dauerhaft \u00fcbernommen hat. Erg\u00e4nze den Backlog deshalb um passende Failover-Abl\u00e4ufe, Persistenz, getestete Wiederherstellung und ein klares Datenverlustziel. F\u00fcr die praktische Auswertung von Offsets kann auch der interne Leitfaden <a href=\"https:\/\/webhosting.de\/redis-replication-offset-analyse-datenkonsistenz-cluster\/\">Redis Replication Offset analysieren<\/a> weiterhelfen.<\/p><section class=\"wh-sources\"><h2>Quellen und fachlicher Stand<\/h2><p>Recherche-Stand: <time datetime=\"2026-09-21\">2026-09-21<\/time><\/p><p>Behandelt Redis Open Source; die Unterschiede zu Redis Software beziehen sich ausdr\u00fccklich auf die Dokumentation f\u00fcr Version 7.8. Die Failover-bezogene zweite Replikations-ID wird f\u00fcr Redis 4.0 und neuer erw\u00e4hnt; die gemeinsame Speicherbetrachtung von Backlog und Replica-Buffer f\u00fcr Redis 7.0 und neuer.<\/p><ul><li id=\"wh-source-S1\">[S1] <a href=\"https:\/\/redis.io\/docs\/latest\/operate\/oss_and_stack\/management\/replication\/\" rel=\"noopener\">Redis replication | Docs<\/a><\/li><li id=\"wh-source-S3\">[S3] <a href=\"https:\/\/redis.io\/docs\/latest\/operate\/oss_and_stack\/management\/replication\/?utm_source=openai\" rel=\"noopener\">Redis replication | Docs<\/a><\/li><li id=\"wh-source-S2\">[S2] <a href=\"https:\/\/redis.io\/docs\/latest\/commands\/info\/\" rel=\"noopener\">INFO | Docs<\/a><\/li><li id=\"wh-source-S4\">[S4] <a href=\"https:\/\/github.com\/redis\/redis\/blob\/unstable\/redis.conf\" rel=\"noopener\">redis\/redis.conf at unstable \u00b7 redis\/redis \u00b7 GitHub<\/a><\/li><li id=\"wh-source-S5\">[S5] <a href=\"https:\/\/redis.io\/docs\/latest\/operate\/rs\/7.8\/databases\/durability-ha\/replication\/?utm_source=openai\" rel=\"noopener\">Database replication | Docs<\/a><\/li><\/ul><\/section><\/div>\n<!-- \/wp:html -->","draft_hash":"20de282ac96cd1ec48634882871b2d6afea498967024969c8e6059074271ce5e","created_at":"2026-09-21T18:27:55+00:00","helper_version":"2.0.4"},"_wp_desired_post_slug":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":"1","_edit_lock":"1790049167:1","_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":"464","_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,"_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":"73","rank_math_contentai_score":null,"ilj_limitincominglinks":"","ilj_maxincominglinks":"1","ilj_limitoutgoinglinks":"","ilj_maxoutgoinglinks":"1","ilj_limitlinksperparagraph":"","ilj_linksperparagraph":"1","ilj_blacklistdefinition":[],"ilj_linkdefinition":[],"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"Redis Replication Backlog","rank_math_og_content_image":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":"21637","_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":"Erfahre, was der Redis Replication Backlog speichert, wie PSYNC funktioniert, wie du die Gr\u00f6\u00dfe planst und welche Grenzen f\u00fcr High Availability gelten.","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/21633","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=21633"}],"version-history":[{"count":5,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/21633\/revisions"}],"predecessor-version":[{"id":21642,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/21633\/revisions\/21642"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media\/21637"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media?parent=21633"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/categories?post=21633"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/tags?post=21633"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}