{"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":"compreender-o-backlog-de-replicacao-do-redis","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/redis-replication-backlog-verstehen\/","title":{"rendered":"Compreender o backlog de replica\u00e7\u00e3o do Redis: PSYNC, tamanho e limites de alta disponibilidade"},"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;\">O <strong style=\"font-weight:700;color:#153e50;\">Atraso na replica\u00e7\u00e3o do Redis<\/strong> determina, entre outros fatores, se, ap\u00f3s uma interrup\u00e7\u00e3o da liga\u00e7\u00e3o, uma r\u00e9plica deve apenas recuperar as altera\u00e7\u00f5es em falta ou se deve receber novamente todo o conjunto de dados. Quem dimensionar o buffer de acordo com o volume real de replica\u00e7\u00e3o pode evitar sincroniza\u00e7\u00f5es completas desnecess\u00e1rias. Para tal, por\u00e9m, o hist\u00f3rico de replica\u00e7\u00e3o, o or\u00e7amento de armazenamento e os processos operacionais t\u00eam de estar em sintonia: um grande atraso n\u00e3o substitui nem a persist\u00eancia nem um conceito de failover robusto. <\/p><nav aria-label=\"Conte\u00fado deste artigo\" 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;\">Ir diretamente para a sec\u00e7\u00e3o<\/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;\">O que o backlog realmente armazena<\/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;\">Quando basta o PSYNC e quando \u00e9 necess\u00e1ria uma ressincroniza\u00e7\u00e3o completa<\/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;\">Medir a taxa de replica\u00e7\u00e3o em vez de estimar o tamanho da base de dados<\/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;\">Calcular de forma compreens\u00edvel a dimens\u00e3o da carteira de encomendas<\/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;\">Alterar a configura\u00e7\u00e3o do Redis de forma compreens\u00edvel e controlada<\/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;\">Monitoriza\u00e7\u00e3o: Que valores est\u00e3o relacionados entre si<\/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;\">Como avaliar corretamente o or\u00e7amento de armazenamento e as r\u00e9plicas lentas<\/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;\">Por que raz\u00e3o um grande volume de trabalho em atraso ainda n\u00e3o garante uma elevada disponibilidade<\/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;\">Testar altera\u00e7\u00f5es e identificar problemas recorrentes<\/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;\">O que o backlog realmente armazena<\/h2><p style=\"margin:0 0 22px;\">Em <strong style=\"font-weight:700;color:#153e50;\">Replica\u00e7\u00e3o do Redis<\/strong> O servidor prim\u00e1rio processa as altera\u00e7\u00f5es na base de dados e transmite um fluxo cont\u00ednuo de comandos \u00e0s suas r\u00e9plicas. Isto n\u00e3o inclui apenas os valores gravados diretamente pelos clientes. Tamb\u00e9m as chaves expiradas ou substitu\u00eddas podem desencadear altera\u00e7\u00f5es que t\u00eam de ser transmitidas. O backlog mant\u00e9m na mem\u00f3ria uma amostra limitada e recente desse fluxo de replica\u00e7\u00e3o. Por isso, n\u00e3o cont\u00e9m nenhuma c\u00f3pia completa adicional da base de dados, nem constitui um arquivo de opera\u00e7\u00f5es de grava\u00e7\u00e3o de qualquer idade. <\/p><p style=\"margin:0 0 22px;\">Em condi\u00e7\u00f5es normais de funcionamento, as r\u00e9plicas acompanham o fluxo de dados. Se uma liga\u00e7\u00e3o for interrompida, o hist\u00f3rico continua a crescer no prim\u00e1rio. Ap\u00f3s o restabelecimento da liga\u00e7\u00e3o, a r\u00e9plica tenta retomar a partir do ponto em que se encontrava. O fator decisivo \u00e9, ent\u00e3o, se os bytes necess\u00e1rios ainda se encontram armazenados. Se for esse o caso e o hist\u00f3rico de replica\u00e7\u00e3o corresponder, o Redis pode preencher a lacuna. Para tal, n\u00e3o \u00e9 necess\u00e1rio substituir na totalidade os dados j\u00e1 existentes na r\u00e9plica. <\/p><p style=\"margin:0 0 22px;\">A vantagem reside especialmente em pequenas falhas de rede, mudan\u00e7as de liga\u00e7\u00e3o e trabalhos de manuten\u00e7\u00e3o programados. Uma sincroniza\u00e7\u00e3o completa de um grande conjunto de dados exige capacidade de transmiss\u00e3o e pot\u00eancia de computa\u00e7\u00e3o; dependendo da configura\u00e7\u00e3o, acrescentam-se ainda outras cargas sobre a mem\u00f3ria e os suportes de dados. O backlog pode reduzir este esfor\u00e7o, mas n\u00e3o consegue compensar todos os tipos de interrup\u00e7\u00e3o. Um rein\u00edcio do processo ou uma altera\u00e7\u00e3o no hist\u00f3rico requer uma abordagem diferente daquela aplicada a uma liga\u00e7\u00e3o TCP que tenha estado temporariamente interrompida. <\/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;\">Quando basta o PSYNC e quando \u00e9 necess\u00e1ria uma ressincroniza\u00e7\u00e3o completa<\/h2><p style=\"margin:0 0 22px;\">A <strong style=\"font-weight:700;color:#153e50;\">ressincroniza\u00e7\u00e3o parcial com PSYNC<\/strong> requer dois dados interligados: o ID de replica\u00e7\u00e3o e o deslocamento. O ID identifica um determinado hist\u00f3rico de dados. O deslocamento descreve uma posi\u00e7\u00e3o em bytes dentro do fluxo de replica\u00e7\u00e3o. Por isso, dois offsets de igual tamanho, provenientes de hist\u00f3ricos diferentes, n\u00e3o s\u00e3o automaticamente compar\u00e1veis. Por outro lado, um pequeno atraso no mesmo hist\u00f3rico pode j\u00e1 estar fora do backlog dispon\u00edvel, caso a capacidade deste seja limitada.  <\/p><p style=\"margin:0 0 22px;\">Em termos simples, quando se restabelece a liga\u00e7\u00e3o, a r\u00e9plica indica at\u00e9 que ponto chegou. O prim\u00e1rio verifica se consegue fornecer os dados necess\u00e1rios a seguir. Se o hist\u00f3rico for desconhecido ou se faltar a sec\u00e7\u00e3o necess\u00e1ria, \u00e9 gerado um <strong style=\"font-weight:700;color:#153e50;\">Sincroniza\u00e7\u00e3o completa<\/strong> necess\u00e1rio. Nesse processo, a r\u00e9plica recebe um conjunto completo de dados e, posteriormente, as altera\u00e7\u00f5es ocorridas durante a sincroniza\u00e7\u00e3o. A transfer\u00eancia pode ser efetuada, dependendo da configura\u00e7\u00e3o, com uma etapa interm\u00e9dia no RDB para um suporte de dados ou sem essa etapa interm\u00e9dia.  <\/p><p style=\"margin:0 0 22px;\">Ap\u00f3s um failover, uma ressincroniza\u00e7\u00e3o completa n\u00e3o \u00e9 inevit\u00e1vel em todos os casos. Uma r\u00e9plica promovida pode, al\u00e9m disso, memorizar o ID de replica\u00e7\u00e3o anterior e o seu intervalo de deslocamento v\u00e1lido. Desta forma, outras r\u00e9plicas podem, sob condi\u00e7\u00f5es adequadas, ligar-se ao hist\u00f3rico conhecido. No entanto, isto n\u00e3o constitui qualquer garantia para efeitos de planeamento: o intervalo relevante tem de continuar dispon\u00edvel e a reconex\u00e3o concreta tem de corresponder aos IDs guardados.  <\/p><div aria-label=\"Reconex\u00e3o de uma r\u00e9plica: resultados poss\u00edveis\" 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;\">Reconex\u00e3o de uma r\u00e9plica: resultados poss\u00edveis<\/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;\">Situa\u00e7\u00e3o<\/th><th scope=\"col\" style=\"padding:16px 20px;text-align:left;background:#163648;color:#fff;border:0;font-size:14px;font-weight:650;\">Pr\u00e9-requisito<\/th><th scope=\"col\" style=\"padding:16px 20px;text-align:left;background:#163648;color:#fff;border:0;font-size:14px;font-weight:650;\">Resultado<\/th><\/tr><\/thead><tbody><tr><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">Breve interrup\u00e7\u00e3o<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">Hist\u00f3rico adequado; os bytes necess\u00e1rios ainda est\u00e3o dispon\u00edveis<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">O PSYNC s\u00f3 pode fornecer os dados de replica\u00e7\u00e3o em falta.<\/td><\/tr><tr><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">Os bytes mais antigos necess\u00e1rios foram sobrescritos<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">O intervalo solicitado est\u00e1 fora do hist\u00f3rico dispon\u00edvel<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">Um reajustamento completo em vez de uma retoma parcial.<\/td><\/tr><tr><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">Hist\u00f3rico de replica\u00e7\u00e3o desconhecido<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">O ID de replica\u00e7\u00e3o n\u00e3o \u00e9 reconhecido como v\u00e1lido<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">Um volume de trabalho em atraso maior, por si s\u00f3, n\u00e3o resolve o problema.<\/td><\/tr><tr><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">Failover com ID do antecessor conhecido<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">ID secund\u00e1rio guardado, intervalo de desvio v\u00e1lido e hist\u00f3rico suficiente<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">A ressincroniza\u00e7\u00e3o parcial pode continuar a ser poss\u00edvel.<\/td><\/tr><tr><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">Backlog libertado ap\u00f3s a separa\u00e7\u00e3o de todas as r\u00e9plicas<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">O TTL expirou; n\u00e3o resta qualquer hist\u00f3rico utiliz\u00e1vel<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">A reconex\u00e3o posterior requer uma sincroniza\u00e7\u00e3o completa.<\/td><\/tr><\/tbody><\/table><\/div><figure class=\"wh-figure wp-block-image size-large\" style=\"margin:32px 0 40px;\"><img loading=\"lazy\" alt=\"Uma janela limitada no fluxo de dados indica quais os dados de replica\u00e7\u00e3o em falta que ainda est\u00e3o dispon\u00edveis ap\u00f3s uma interrup\u00e7\u00e3o.\" 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;\">Ilustra\u00e7\u00e3o esquem\u00e1tica: o PSYNC s\u00f3 pode ligar-se a um hist\u00f3rico de replica\u00e7\u00e3o compat\u00edvel e ainda dispon\u00edvel.<\/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;\">Medir a taxa de replica\u00e7\u00e3o em vez de estimar o tamanho da base de dados<\/h2><p style=\"margin:0 0 22px;\">A mera dimens\u00e3o do conjunto de dados \u00e9 suficiente para <strong style=\"font-weight:700;color:#153e50;\">Dimensionamento da carteira de trabalhos<\/strong> n\u00e3o \u00e9 suficiente. Uma base de dados grande, na qual predominam as opera\u00e7\u00f5es de leitura, pode gerar pouco tr\u00e1fego de replica\u00e7\u00e3o. Por outro lado, uma cache pequena com valores que mudam frequentemente e muitos eventos de expira\u00e7\u00e3o pode transmitir continuamente volumes consider\u00e1veis de dados. Mesmo um n\u00famero fixo de opera\u00e7\u00f5es por segundo descreve de forma insuficiente a mem\u00f3ria necess\u00e1ria: pequenas altera\u00e7\u00f5es de chaves e grandes substitui\u00e7\u00f5es de valores n\u00e3o resultam no mesmo volume de bytes.  <\/p><p style=\"margin:0 0 22px;\">Uma aproxima\u00e7\u00e3o \u00fatil na pr\u00e1tica resulta do aumento ao longo do tempo de <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>. Regista o valor duas vezes no mesmo servidor prim\u00e1rio e divide a diferen\u00e7a pelos segundos decorridos. Verifica tamb\u00e9m o ID de replica\u00e7\u00e3o. Ap\u00f3s uma troca de fun\u00e7\u00f5es ou um rein\u00edcio, n\u00e3o deves simplesmente subtrair dois pontos de medi\u00e7\u00e3o n\u00e3o relacionados entre si. Al\u00e9m disso, um \u00fanico intervalo de medi\u00e7\u00e3o fornece apenas uma taxa m\u00e9dia dentro desse intervalo, e n\u00e3o um limite m\u00e1ximo garantido de forma permanente.  <\/p><p style=\"margin:0 0 22px;\">A consulta seguinte l\u00ea informa\u00e7\u00f5es de diagn\u00f3stico. N\u00e3o altera a configura\u00e7\u00e3o do Redis. Execute-a com as op\u00e7\u00f5es de liga\u00e7\u00e3o e autentica\u00e7\u00e3o necess\u00e1rias no seu ambiente. A chamada apresentada abaixo utiliza a liga\u00e7\u00e3o padr\u00e3o de <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">redis-cli<\/code>; \u00e9 necess\u00e1rio definir expressamente outro servidor, porta ou acesso TLS.  <\/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;\">Fa\u00e7a medi\u00e7\u00f5es ao longo de diferentes fases de carga, por exemplo, durante o funcionamento normal do dia-a-dia, nas importa\u00e7\u00f5es e durante renova\u00e7\u00f5es de cache de grande dimens\u00e3o. Registe tanto as taxas t\u00edpicas como os picos de curta dura\u00e7\u00e3o. Se ocorrerem muitas altera\u00e7\u00f5es devido ao vencimento de chaves, o artigo interno pode servir como aprofundamento do tema <a href=\"https:\/\/webhosting.de\/pt\/analisar-e-otimizar-o-desempenho-da-expiracao-de-chaves-do-redis-e-da-cache\/\">Analisar a expira\u00e7\u00e3o das chaves do Redis<\/a>. Esta rela\u00e7\u00e3o \u00e9 importante para o planeamento, porque nem todos os impulsos de escrita relevantes resultam diretamente de um novo pedido do utilizador.  <\/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;\">Calcular de forma compreens\u00edvel a dimens\u00e3o da carteira de encomendas<\/h2><p style=\"margin:0 0 22px;\">Como <strong style=\"font-weight:700;color:#153e50;\">Abordagem de planeamento<\/strong> podes multiplicar a taxa de replica\u00e7\u00e3o relevante pela dura\u00e7\u00e3o da interrup\u00e7\u00e3o a contornar e, em seguida, acrescentar uma reserva justificada. A dura\u00e7\u00e3o n\u00e3o deve ter em conta apenas a interrup\u00e7\u00e3o da rede propriamente dita. A dete\u00e7\u00e3o, as tentativas de restabelecimento da liga\u00e7\u00e3o e a recupera\u00e7\u00e3o do caminho de liga\u00e7\u00e3o tamb\u00e9m podem demorar algum tempo. A reserva adequada depende das flutua\u00e7\u00f5es observadas e do objetivo operacional pretendido, e n\u00e3o de uma percentagem universal. <\/p><p style=\"margin:0 0 22px;\">Um exemplo de c\u00e1lculo deliberadamente simplificado: para uma fase de carga em an\u00e1lise, considera-se 12 MiB por segundo. A liga\u00e7\u00e3o poder\u00e1 estar indispon\u00edvel durante 90 segundos; prev\u00eaem-se mais 30 segundos como reserva de tempo. Da\u00ed resulta que <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>, ou seja, cerca de 1,41 GiB. Estes n\u00fameros s\u00e3o valores estimados para fins ilustrativos e n\u00e3o constituem um teste de desempenho do Redis. Antes de uma implementa\u00e7\u00e3o em produ\u00e7\u00e3o, devem ser substitu\u00eddos por valores medidos na tua aplica\u00e7\u00e3o. <\/p><figure class=\"wh-chart\"><figcaption>Necessidade de backlog com base numa estimativa de 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 segundos<\/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 segundos<\/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 segundos<\/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 segundos<\/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;\">Exemplo de c\u00e1lculo ilustrativo, n\u00e3o se trata de uma medi\u00e7\u00e3o: necessidade = 12 MiB\/s (valor hipot\u00e9tico) \u00d7 dura\u00e7\u00e3o total selecionada. Os 120 segundos mencionados no exemplo do texto incluem 90 segundos de interrup\u00e7\u00e3o e 30 segundos de reserva de tempo. N\u00e3o est\u00e3o aqui inclu\u00eddas outras reservas.<\/p><details><summary>Tabela de dados relativa ao gr\u00e1fico<\/summary><table><thead><tr><th scope=\"col\">Entrada<\/th><th scope=\"col\">MiB<\/th><\/tr><\/thead><tbody><tr><td>30 segundos<\/td><td>360<\/td><\/tr><tr><td>60 segundos<\/td><td>720<\/td><\/tr><tr><td>120 segundos<\/td><td>1440<\/td><\/tr><tr><td>180 segundos<\/td><td>2160<\/td><\/tr><\/tbody><\/table><\/details><\/figure><p style=\"margin:0 0 22px;\">O c\u00e1lculo inverso ajuda a avaliar um buffer existente. Um backlog totalmente preenchido com 256 MiB corresponde, matematicamente, a cerca de 21 segundos de hist\u00f3rico, mantendo-se uma taxa constante de 12 MiB por segundo. A uma taxa de 2 MiB por segundo, seriam cerca de 128 segundos. No entanto, numa aplica\u00e7\u00e3o real, as taxas variam. Por isso, tal estimativa \u00e9 apenas um instant\u00e2neo e n\u00e3o constitui uma garantia de que qualquer falha com essa dura\u00e7\u00e3o possa ser parcialmente sincronizada. <\/p><figure class=\"wh-figure wp-block-image size-large\" style=\"margin:32px 0 40px;\"><img loading=\"lazy\" alt=\"Duas janelas de hist\u00f3rico de igual tamanho, com fluxos de dados de densidade diferente, ilustram a influ\u00eancia da taxa de replica\u00e7\u00e3o.\" 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;\">Ilustra\u00e7\u00e3o conceptual: com o mesmo tamanho de buffer, um fluxo de replica\u00e7\u00e3o maior reduz o alcance temporal.<\/figcaption><\/figure><p style=\"margin:0 0 22px;\">Verifica tamb\u00e9m se, ap\u00f3s restabelecer a liga\u00e7\u00e3o, a r\u00e9plica consegue recuperar o atraso mais rapidamente do que as novas altera\u00e7\u00f5es surgem. A elimina\u00e7\u00e3o de mais hist\u00f3rico n\u00e3o resolve nem o problema de uma rede permanentemente lenta nem o de um destinat\u00e1rio permanentemente sobrecarregado. Se o atraso persistir ou continuar a aumentar, \u00e9 necess\u00e1rio investigar a causa. Caso contr\u00e1rio, prever cada vez mais espa\u00e7o de armazenamento apenas adia o problema e pode colocar todo o sistema sob press\u00e3o de espa\u00e7o de armazenamento. <\/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;\">Alterar a configura\u00e7\u00e3o do Redis de forma compreens\u00edvel e controlada<\/h2><p style=\"margin:0 0 22px;\">Os par\u00e2metros <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> e <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> controlam aspetos diferentes. O primeiro descreve o tamanho previsto do backlog. O segundo determina, no servidor prim\u00e1rio, ap\u00f3s quanto tempo sem r\u00e9plicas ligadas \u00e9 que o backlog pode ser libertado. \u00c9 <strong style=\"font-weight:700;color:#153e50;\">N\u00e3o existe um tempo m\u00e1ximo de interrup\u00e7\u00e3o para o PSYNC<\/strong>. Enquanto o buffer for sobrescrito ou faltar outro pr\u00e9-requisito, um TTL longo, por si s\u00f3, n\u00e3o resolve o problema.   <\/p><p style=\"margin:0 0 22px;\">As linhas seguintes s\u00e3o defini\u00e7\u00f5es comentadas retiradas do modelo de configura\u00e7\u00e3o do Redis 7.2.0. Os s\u00edmbolos de coment\u00e1rio foram mantidos intencionalmente. A simples c\u00f3pia destas linhas n\u00e3o ativa quaisquer defini\u00e7\u00f5es; al\u00e9m disso, os valores mencionados n\u00e3o constituem uma recomenda\u00e7\u00e3o geral de capacidade para sistemas em produ\u00e7\u00e3o.   <\/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;\">Com <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> A liberta\u00e7\u00e3o temporizada \u00e9 desativada ap\u00f3s a desconex\u00e3o de todas as r\u00e9plicas. Isto n\u00e3o conserva um hist\u00f3rico ilimitado: o buffer existente pode continuar a ser substitu\u00eddo por novos dados de replica\u00e7\u00e3o. Al\u00e9m disso, isto n\u00e3o garante a persist\u00eancia ap\u00f3s quaisquer rein\u00edcios do processo. Por isso, avalie cuidadosamente se o consumo adicional de mem\u00f3ria se adequa ao comportamento de reconex\u00e3o esperado.   <\/p><p style=\"margin:0 0 22px;\">Antes de efetuar qualquer altera\u00e7\u00e3o, deve verificar os valores efetivamente em vigor e esclarecer o procedimento de implementa\u00e7\u00e3o. Uma vari\u00e1vel de ambiente do contentor, um ficheiro de configura\u00e7\u00e3o gerido e uma defini\u00e7\u00e3o alterada em tempo de execu\u00e7\u00e3o n\u00e3o s\u00e3o a mesma coisa. Se uma inst\u00e2ncia for recriada posteriormente, apenas as altera\u00e7\u00f5es efetuadas em tempo de execu\u00e7\u00e3o poder\u00e3o ser perdidas. As consultas seguintes s\u00e3o de leitura; no entanto, requerem os direitos de acesso adequados.   <\/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;\">No caso do Managed Redis, o fornecedor pode restringir o acesso a <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">CONFIG<\/code> limitar ou gerir as defini\u00e7\u00f5es atrav\u00e9s de uma interface pr\u00f3pria. Isso n\u00e3o \u00e9 motivo para contornar os mecanismos de prote\u00e7\u00e3o. Nesse caso, utilize os canais de gest\u00e3o autorizados e documente o tamanho selecionado, juntamente com o volume de replica\u00e7\u00e3o subjacente. No plano de altera\u00e7\u00e3o, devem tamb\u00e9m ser registados os valores atuais e um plano de revers\u00e3o realista.   <\/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;\">Monitoriza\u00e7\u00e3o: Que valores est\u00e3o relacionados entre si<\/h2><p style=\"margin:0 0 22px;\">Para a <strong style=\"font-weight:700;color:#153e50;\">Monitoriza\u00e7\u00e3o da replica\u00e7\u00e3o do Redis<\/strong> Um \u00fanico estado de liga\u00e7\u00e3o verde n\u00e3o \u00e9 suficiente. Uma liga\u00e7\u00e3o pode estar restabelecida enquanto a r\u00e9plica ainda est\u00e1 a recuperar o atraso ou a carregar um conjunto completo de dados. Por outro lado, uma breve interrup\u00e7\u00e3o da liga\u00e7\u00e3o n\u00e3o tem de ser imediatamente cr\u00edtica, se o hist\u00f3rico e a capacidade de recupera\u00e7\u00e3o forem suficientes. Por isso, avalie em conjunto a liga\u00e7\u00e3o, o estado de sincroniza\u00e7\u00e3o, a evolu\u00e7\u00e3o do desfasamento e o hist\u00f3rico dispon\u00edvel. <\/p><div aria-label=\"Monitoriza\u00e7\u00e3o do Redis: interpretar os valores no seu contexto\" 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;\">Monitoriza\u00e7\u00e3o do Redis: interpretar os valores no seu contexto<\/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;\">Campo<\/th><th scope=\"col\" style=\"padding:16px 20px;text-align:left;background:#163648;color:#fff;border:0;font-size:14px;font-weight:650;\">Significado<\/th><th scope=\"col\" style=\"padding:16px 20px;text-align:left;background:#163648;color:#fff;border:0;font-size:14px;font-weight:650;\">O que deves ter em aten\u00e7\u00e3o<\/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;\">Identidade do hist\u00f3rico e deslocamento atual em bytes no disco principal<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">Comparar apenas os pontos de medi\u00e7\u00e3o que se encontram na mesma s\u00e9rie hist\u00f3rica.<\/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;\">Se a lista de pend\u00eancias de replica\u00e7\u00e3o est\u00e1 atualmente ativa<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">Um valor configurado, por si s\u00f3, n\u00e3o significa necessariamente que exista um hist\u00f3rico dispon\u00edvel.<\/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;\">Deslocamento do primeiro byte ainda guardado<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">Os dados necess\u00e1rios para a r\u00e9plica t\u00eam de corresponder ao espa\u00e7o dispon\u00edvel.<\/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;\">Dura\u00e7\u00e3o do hist\u00f3rico existente e tamanho configurado<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">Um buffer rec\u00e9m-criado n\u00e3o tem de estar ainda totalmente preenchido.<\/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;\">Liga\u00e7\u00e3o e sincroniza\u00e7\u00e3o cont\u00ednua do ponto de vista da r\u00e9plica<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#ffffff;color:#294354;\">O simples facto de um link estar novamente dispon\u00edvel n\u00e3o significa, por si s\u00f3, que a compara\u00e7\u00e3o tenha sido conclu\u00edda.<\/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;\">Progresso da replica\u00e7\u00e3o numa r\u00e9plica<\/td><td style=\"padding:17px 20px;vertical-align:top;border:0;border-bottom:1px solid #e5edf1;background:#f5f9fb;color:#294354;\">Ter em conta a evolu\u00e7\u00e3o ao longo do tempo e o hist\u00f3rico correspondente.<\/td><\/tr><\/tbody><\/table><\/div><p style=\"margin:0 0 22px;\">Os campos de uma <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">INFO<\/code>-As respostas podem variar entre vers\u00f5es do Redis e entre o servidor principal e a r\u00e9plica. Por isso, uma an\u00e1lise deve tratar explicitamente os campos em falta, em vez de os interpretar tacitamente como nulos ou como um estado sem erros. Tamb\u00e9m as designa\u00e7\u00f5es <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">master<\/code> e <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">slave<\/code> continuam a aparecer nos nomes dos campos por motivos de compatibilidade; n\u00e3o devem ser traduzidos livremente no c\u00f3digo execut\u00e1vel. <\/p><p style=\"margin:0 0 22px;\">Para a interpreta\u00e7\u00e3o do atraso, deve consultar-se o guia interno <a href=\"https:\/\/webhosting.de\/pt\/redis-deslocamento-de-replicacao-analise-consistencia-de-dados-cluster\/\">Analisar o deslocamento de replica\u00e7\u00e3o do Redis<\/a> um complemento adequado. No acompanhamento cont\u00ednuo, deves ter em conta os padr\u00f5es hist\u00f3ricos, e n\u00e3o apenas dois valores lidos manualmente. Uma dist\u00e2ncia crescente exige uma rea\u00e7\u00e3o diferente daquela necess\u00e1ria quando a diferen\u00e7a vai diminuindo constantemente ap\u00f3s uma breve interrup\u00e7\u00e3o. <\/p><p style=\"margin:0 0 22px;\">Os alarmes \u00fateis orientam-se pelos teus objetivos operacionais: durante quanto tempo \u00e9 que uma r\u00e9plica pode ficar inacess\u00edvel? Com que rapidez \u00e9 que ela tem de recuperar o atraso? Que frequ\u00eancia de sincroniza\u00e7\u00f5es completas \u00e9 considerada invulgar? Limites r\u00edgidos, sem ter em conta o perfil de carga e o volume de dados, conduzem frequentemente a notifica\u00e7\u00f5es desnecess\u00e1rias ou fazem com que se ignorem deteriora\u00e7\u00f5es reais. Al\u00e9m das m\u00e9tricas de replica\u00e7\u00e3o, mant\u00e9m tamb\u00e9m sob vigil\u00e2ncia a utiliza\u00e7\u00e3o da RAM, a utiliza\u00e7\u00e3o da rede e os ind\u00edcios de rein\u00edcios de processos. <\/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;\">Como avaliar corretamente o or\u00e7amento de armazenamento e as r\u00e9plicas lentas<\/h2><p style=\"margin:0 0 22px;\">A carteira de encomendas \u00e9 apenas uma parte do total <strong style=\"font-weight:700;color:#153e50;\">Necessidades de mem\u00f3ria do Redis<\/strong>. A isto acrescentam-se o conjunto de dados, as estruturas administrativas, os buffers do cliente e, dependendo do estado de funcionamento, mem\u00f3ria adicional durante os processos de persist\u00eancia ou sincroniza\u00e7\u00e3o. Por isso, n\u00e3o reserve toda a mem\u00f3ria de trabalho dispon\u00edvel para dados \u00fateis e para um backlog calculado com exatid\u00e3o. A reserva necess\u00e1ria deve ser determinada com base no ambiente espec\u00edfico e nos picos de carga que a\u00ed ocorrem.  <\/p><p style=\"margin:0 0 22px;\">Desde o Redis 7.0 que o Replica Buffer e o Replication Backlog partilham mem\u00f3ria. Por isso, a documenta\u00e7\u00e3o INFO refere, entre outras coisas, que <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> pode ser nulo se os buffers de r\u00e9plica n\u00e3o excederem a ocupa\u00e7\u00e3o do backlog. Isso n\u00e3o significa, contudo, que a replica\u00e7\u00e3o n\u00e3o ocupe mem\u00f3ria. Considere os valores previstos para esse efeito, tais como <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> e <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> no contexto e n\u00e3o some cegamente valores que se sobrep\u00f5em.  <\/p><p style=\"margin:0 0 22px;\">Um erro de diagn\u00f3stico frequente consiste em atribuir cada sincroniza\u00e7\u00e3o interrompida a um atraso acumulado significativo. R\u00e9plicas lentas, largura de banda de rede limitada ou limites do buffer de sa\u00edda excedidos podem ter outras causas. O par\u00e2metro <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> refere-se \u00e0 classe de cliente em quest\u00e3o e n\u00e3o deve ser confundida com <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> ser equiparados. Antes de alterar os limites, verifica os registos, a documenta\u00e7\u00e3o da vers\u00e3o e os impactos previs\u00edveis noutras liga\u00e7\u00f5es.  <\/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;\">Por que raz\u00e3o um grande volume de trabalho em atraso ainda n\u00e3o garante uma elevada disponibilidade<\/h2><p style=\"margin:0 0 22px;\">O backlog melhora a reconex\u00e3o, mas n\u00e3o torna a replica\u00e7\u00e3o, que \u00e9 ass\u00edncrona por predefini\u00e7\u00e3o, isenta de perdas. Um servidor prim\u00e1rio pode j\u00e1 ter confirmado uma opera\u00e7\u00e3o de grava\u00e7\u00e3o ao cliente antes de uma r\u00e9plica a ter processado. Se o servidor prim\u00e1rio falhar durante esse per\u00edodo, \u00e9 poss\u00edvel que a opera\u00e7\u00e3o em quest\u00e3o n\u00e3o esteja presente no sistema substituto selecionado posteriormente. O tamanho do buffer, por si s\u00f3, n\u00e3o resolve este problema <strong style=\"font-weight:700;color:#153e50;\">Risco de perda de dados durante o failover<\/strong> n\u00e3o.   <\/p><p style=\"margin:0 0 22px;\">Tamb\u00e9m <code data-no-translation=\"\" style=\"font-size:.86em;background:#edf3f6;border-radius:5px;padding:2px 5px;color:#17485d;overflow-wrap:anywhere;\">WAIT<\/code> n\u00e3o transforma uma topologia Redis num sistema com consist\u00eancia forte garantida. O comando pode aguardar confirma\u00e7\u00f5es das r\u00e9plicas; a seguran\u00e7a efetiva dos dados continua a depender de outras circunst\u00e2ncias, nomeadamente do comportamento de persist\u00eancia e de failover. Da mesma forma, limitam <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> e <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> aceitar novas opera\u00e7\u00f5es de grava\u00e7\u00e3o, de acordo com as respetivas condi\u00e7\u00f5es, sem guardar automaticamente e de forma permanente cada opera\u00e7\u00e3o individual em v\u00e1rias inst\u00e2ncias.   <\/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;\">A replica\u00e7\u00e3o n\u00e3o \u00e9 um c\u00f3pia de seguran\u00e7a<\/p><p style=\"margin:0 0 22px;\">Se um servidor prim\u00e1rio sem persist\u00eancia reiniciar automaticamente com uma base de dados vazia, as suas r\u00e9plicas podem herdar esse estado vazio. Um grande volume de trabalho em atraso n\u00e3o impede este cen\u00e1rio. Por isso, garanta em conjunto o rein\u00edcio, a persist\u00eancia e a recupera\u00e7\u00e3o; uma r\u00e9plica, por si s\u00f3, n\u00e3o substitui uma c\u00f3pia de seguran\u00e7a que possa ser utilizada de forma independente.  <\/p><\/aside><p style=\"margin:0 0 22px;\">Para <strong style=\"font-weight:700;color:#153e50;\">Alta disponibilidade<\/strong> Por isso, \u00e9 necess\u00e1ria uma decis\u00e3o coerente: perda de dados toler\u00e1vel, tempo de inatividade admiss\u00edvel, persist\u00eancia, dete\u00e7\u00e3o de falhas, sele\u00e7\u00e3o do novo prim\u00e1rio e recupera\u00e7\u00e3o. O Sentinel ou o Redis Cluster podem assumir outras tarefas al\u00e9m do backlog. Quem se limita a aumentar o tamanho de um buffer e mant\u00e9m todas as restantes premissas inalteradas ainda n\u00e3o disp\u00f5e de um plano de rein\u00edcio fi\u00e1vel.   <\/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;\">Testar altera\u00e7\u00f5es e identificar problemas recorrentes<\/h2><p style=\"margin:0 0 22px;\">Inicie um teste controlado num ambiente isolado com uma vers\u00e3o compar\u00e1vel do Redis e uma carga de escrita previs\u00edvel. Registe os IDs de replica\u00e7\u00e3o, os offsets, o volume de trabalho em atraso e o consumo de mem\u00f3ria antes da interrup\u00e7\u00e3o. Em seguida, simule uma interrup\u00e7\u00e3o limitada da liga\u00e7\u00e3o, sem alterar firewalls ou processos de produ\u00e7\u00e3o sem verifica\u00e7\u00e3o pr\u00e9via. Ap\u00f3s o restabelecimento da liga\u00e7\u00e3o, observe se ocorre uma sincroniza\u00e7\u00e3o parcial ou total e quanto tempo demora a recupera\u00e7\u00e3o.  <\/p><p style=\"margin:0 0 22px;\">Altere, sempre que poss\u00edvel, apenas uma vari\u00e1vel relevante por teste. Se o backlog, a carga de escrita e as condi\u00e7\u00f5es da rede mudarem simultaneamente, ser\u00e1 dif\u00edcil determinar a causa do efeito. Repita o teste com diferentes dura\u00e7\u00f5es de interrup\u00e7\u00e3o e diferentes fases de carga. Desta forma, uma \u00fanica reconex\u00e3o bem-sucedida transforma-se numa avalia\u00e7\u00e3o compreens\u00edvel do comportamento. Os limites observados devem ser documentados, sem que se deduza disso uma garantia para qualquer falha futura.  <\/p><p style=\"margin:0 0 22px;\">Em caso de ressincroniza\u00e7\u00f5es completas repetidas, verifica-se primeiro se o hist\u00f3rico \u00e9, de todo, compat\u00edvel. Em seguida, analisam-se os bytes ainda pendentes, o tempo sem r\u00e9plica, as indica\u00e7\u00f5es de rein\u00edcios e a velocidade real de recupera\u00e7\u00e3o. Um buffer demasiado pequeno \u00e9 uma causa poss\u00edvel, mas n\u00e3o a \u00fanica. \u00c9 particularmente importante distinguir entre uma lacuna pontual demasiado longa e uma r\u00e9plica que fica permanentemente atrasada, mesmo com liga\u00e7\u00e3o ativa.  <\/p><p style=\"margin:0 0 22px;\">A configura\u00e7\u00e3o correta \u00e9, em \u00faltima an\u00e1lise, aquela que cobre a janela de falha que definiste com uma carga realista e deixa mem\u00f3ria suficiente para o restante funcionamento. Regista em conjunto a base de medi\u00e7\u00e3o, a fonte de configura\u00e7\u00e3o e a data da verifica\u00e7\u00e3o. Ap\u00f3s altera\u00e7\u00f5es significativas no comportamento de escrita, na topologia ou na vers\u00e3o do Redis, o dimensionamento deve ser novamente revisto. Desta forma, o backlog continua a ser uma decis\u00e3o operacional fundamentada, em vez de um valor simplesmente adotado.  <\/p><section class=\"wh-sources\" style=\"margin-top:50px;padding-top:25px;border-top:1px solid #dce6eb;font-size:14px;color:#607381;\"><h2>Fontes e estado atual dos conhecimentos<\/h2><p style=\"margin:0 0 22px;\">Estado da pesquisa: <time datetime=\"2026-09-21\">2026-09-21<\/time><\/p><p style=\"margin:0 0 22px;\">Os exemplos de configura\u00e7\u00e3o est\u00e3o organizados com base na vers\u00e3o est\u00e1vel do Redis 7.2.0, e n\u00e3o na ramifica\u00e7\u00e3o de desenvolvimento \u00abunstable\u00bb. A aloca\u00e7\u00e3o de mem\u00f3ria partilhada descrita aplica-se, de acordo com a documenta\u00e7\u00e3o INFO, a partir do Redis 7.0. Os mecanismos gerais referem-se ao Redis Open Source; n\u00e3o s\u00e3o reproduzidos os valores predefinidos do software Redis ou da nuvem. Data de atualiza\u00e7\u00e3o da documenta\u00e7\u00e3o: 21 de setembro de 2026. N\u00e3o foram realizados testes laboratoriais do Redis.<\/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>A fila de replica\u00e7\u00e3o do Redis mant\u00e9m uma amostra limitada do fluxo de replica\u00e7\u00e3o. Ap\u00f3s breves interrup\u00e7\u00f5es de liga\u00e7\u00e3o, permite frequentemente a utiliza\u00e7\u00e3o de PSYNC em vez de uma ressincroniza\u00e7\u00e3o completa, mas n\u00e3o substitui nem o armazenamento persistente de dados nem um conceito bem concebido de alta disponibilidade.<\/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":"Compreender e analisar o deslocamento de replica\u00e7\u00e3o do Redis para garantir uma elevada consist\u00eancia dos dados","excerpt":"Vou mostrar como leio e analiso o offset do Redis de forma espec\u00edfica e como o utilizo para garantir uma elevada consist\u00eancia dos dados. Desta forma, consigo detetar precocemente lacunas na replica\u00e7\u00e3o, avaliar os riscos de failover e manter os clusters produtivos sincronizados de forma fi\u00e1vel. Pontos-chave As seguintes ideias-chave constituem uma introdu\u00e7\u00e3o espec\u00edfica ao tema, \u00e0 terminologia e \u00e0 aplica\u00e7\u00e3o pr\u00e1tica. O offset mede o progresso do fluxo de replica\u00e7\u00e3o, byte a byte. O lag \u00e9 a diferen\u00e7a entre o master_repl_offset e o slave_repl_offset. O ID+offset identifica uma vers\u00e3o exata dos dados para sincroniza\u00e7\u00f5es parciais. O backlog protege contra sincroniza\u00e7\u00f5es completas em caso de breves interrup\u00e7\u00f5es de liga\u00e7\u00e3o. A monitoriza\u00e7\u00e3o com m\u00e9tricas INFO\/Cluster controla os alertas e o failover. O que significa o offset de replica\u00e7\u00e3o do Redis? O offset de replica\u00e7\u00e3o \u00e9 um contador cont\u00ednuo de 64 bits que reflete cada fluxo de bytes transmitido entre o prim\u00e1rio e a r\u00e9plica. A partir dele, consigo determinar at\u00e9 que ponto a replica\u00e7\u00e3o avan\u00e7ou e se uma r\u00e9plica ainda tem trabalho pendente. O `master_repl_offset` no prim\u00e1rio aumenta com cada byte rec\u00e9m-gerado, enquanto a r\u00e9plica aumenta o seu pr\u00f3prio contador assim que aplica os comandos. As diferen\u00e7as resultam num atraso em bytes e indicam se a r\u00e9plica est\u00e1 atrasada. Esta sem\u00e2ntica simples, mas eficaz, torna o deslocamento o valor central para a sincroniza\u00e7\u00e3o, a an\u00e1lise de falhas e decis\u00f5es de failover bem fundamentadas. Ler os offsets: utilizar corretamente o comando INFO replication Quase sempre come\u00e7o o diagn\u00f3stico com o comando INFO replication, porque este fornece os campos relevantes de forma compacta. No prim\u00e1rio, verifico o master_repl_offset, bem como o estado das r\u00e9plicas ligadas, incluindo os respetivos offsets. Numa r\u00e9plica, verifico adicionalmente o `master_link_status` e os estados de sincroniza\u00e7\u00e3o, para identificar sincroniza\u00e7\u00f5es completas ou parciais em curso. Para uma an\u00e1lise mais aprofundada, recorro a sa\u00eddas estruturadas e correlaciono os offsets com valores de CPU, E\/S e rede. Este guia fornece-me uma introdu\u00e7\u00e3o aprofundada ao comando: Redis INFO para monitoriza\u00e7\u00e3o. ID de replica\u00e7\u00e3o + deslocamento: vers\u00e3o \u00fanica dos dados Para obter uma vers\u00e3o \u00fanica, utilizo a combina\u00e7\u00e3o da ID de replica\u00e7\u00e3o e do deslocamento. A ID identifica um hist\u00f3rico, enquanto o deslocamento indica uma posi\u00e7\u00e3o dentro do"},"I2":{"id":"I2","post_id":21597,"url":"https:\/\/webhosting.de\/redis-key-expiration-performance-analysieren-optimieren-cache\/","title":"Analisar e otimizar o desempenho da expira\u00e7\u00e3o de chaves do Redis","excerpt":"Analiso de forma espec\u00edfica o desempenho da expira\u00e7\u00e3o de chaves do Redis e otimizo-o atrav\u00e9s de passos claros e mensur\u00e1veis. Desta forma, reduzo a lat\u00eancia, suavizo os picos de carga e mantenho o consumo de mem\u00f3ria sob controlo, sem comprometer o d\u00e9bito. Pontos-chave Resumo os aspetos mais importantes relativos ao desempenho da expira\u00e7\u00e3o, de forma a que os principiantes possam come\u00e7ar imediatamente e os utilizadores avan\u00e7ados possam otimizar de forma espec\u00edfica. Os pontos-chave seguintes abordam os par\u00e2metros de ajuste mais eficazes e mostram onde surgem os estrangulamentos t\u00edpicos. Para tal, concentro-me nas estrat\u00e9gias de TTL, na limpeza ativa e passiva, bem como no comportamento de evic\u00e7\u00e3o. Al\u00e9m disso, estabele\u00e7o indicadores de monitoriza\u00e7\u00e3o que permitem detetar problemas numa fase precoce. Desta forma, \u00e9 poss\u00edvel avaliar sistematicamente o desempenho e control\u00e1-lo de forma sustent\u00e1vel. Expira\u00e7\u00e3o \u00ablazy\u00bb vs. \u00abativa\u00bb: compreender e medir a intera\u00e7\u00e3o Dispers\u00e3o de TTL: desfasamentos contra expira\u00e7\u00f5es simult\u00e2neas Ajuste de hz: Equilibrar a frequ\u00eancia dos ciclos em segundo plano Pol\u00edtica de evic\u00e7\u00e3o: allkeys-lru vs. variantes volatile Monitoriza\u00e7\u00e3o: observar valores de expira\u00e7\u00e3o, evic\u00e7\u00e3o e lat\u00eancia Aposto em TTLs consistentes, limpeza adaptativa e limites claros. Desta forma, distribuo os momentos de expira\u00e7\u00e3o, evito evic\u00e7\u00f5es desnecess\u00e1rias e mantenho os tempos de resposta fiavelmente baixos. Al\u00e9m disso, utilizo m\u00e9tricas que sinalizam imediatamente fases suspeitas e permitem tomar contramedidas precisas. Expira\u00e7\u00e3o de chaves no Redis: funcionamento e impacto na lat\u00eancia O Redis combina a expira\u00e7\u00e3o \u00ablazy\u00bb e a \u00abactive\u00bb para aliar um elevado desempenho a uma carga limitada da CPU. Na expira\u00e7\u00e3o \u00ablazy\u00bb, o servidor s\u00f3 elimina as chaves no momento do acesso, quando o TTL expirou. Desta forma, n\u00e3o s\u00e3o necess\u00e1rias opera\u00e7\u00f5es adicionais em segundo plano para dados que, de qualquer forma, s\u00e3o lidos regularmente. A expira\u00e7\u00e3o ativa complementa o modelo atrav\u00e9s de verifica\u00e7\u00f5es curtas e frequentes das chaves que est\u00e3o a expirar, para remover entradas esquecidas. Esta arquitetura mant\u00e9m as lat\u00eancias baixas e liberta mem\u00f3ria sem necessidade de verifica\u00e7\u00f5es permanentes e dispendiosas. Surge uma lat\u00eancia percet\u00edvel sobretudo quando um grande n\u00famero de entradas expira num intervalo de tempo curto. Nesse caso, o Redis investe mais CPU na limpeza ativa, o que reduz temporariamente a capacidade para opera\u00e7\u00f5es do cliente. Press\u00e3o adicional na mem\u00f3ria v"},"I3":{"id":"I3","post_id":21547,"url":"https:\/\/webhosting.de\/redis-expire-strategien-grosse-cache-systeme-cache-architektur\/","title":"Estrat\u00e9gias de expira\u00e7\u00e3o do Redis para grandes sistemas de cache: guia pr\u00e1tico para a otimiza\u00e7\u00e3o do desempenho","excerpt":"Sem estrat\u00e9gias planeadas de expira\u00e7\u00e3o do Redis, os grandes clusters de cache levam rapidamente a estrangulamentos de mem\u00f3ria e lat\u00eancias vari\u00e1veis; vou mostrar-te como combinar o TTL, a evic\u00e7\u00e3o e a invalida\u00e7\u00e3o de forma a evitar picos de carga. Apresento melhores pr\u00e1ticas concretas para o desenho de chaves, tempos de validade e monitoriza\u00e7\u00e3o, que funcionam de forma fi\u00e1vel em instala\u00e7\u00f5es em produ\u00e7\u00e3o. Pontos-chave: compreender e configurar de forma consistente a separa\u00e7\u00e3o entre expira\u00e7\u00e3o e evic\u00e7\u00e3o; definir TTL em todos os casos, al\u00e9m de combinar jitter com a invalida\u00e7\u00e3o contra o \u201eThundering Herd\u201c: Delete-on-write, tags, versionamento Escolher conscientemente a pol\u00edtica de evic\u00e7\u00e3o e test\u00e1-la com maxmemory Orientar a monitoriza\u00e7\u00e3o para chaves expiradas\/evictadas, taxa de acertos e lat\u00eancias Expira\u00e7\u00e3o vs. evic\u00e7\u00e3o: Como o Redis elimina Na minha planea\u00e7\u00e3o, fa\u00e7o sempre uma distin\u00e7\u00e3o clara entre expira\u00e7\u00e3o e evic\u00e7\u00e3o, porque ambos os processos t\u00eam objetivos diferentes. A expira\u00e7\u00e3o remove as chaves ap\u00f3s o TTL expirar, enquanto a evic\u00e7\u00e3o s\u00f3 entra em a\u00e7\u00e3o quando o limite de mem\u00f3ria configurado \u00e9 esgotado. O Redis verifica, em cada acesso, atrav\u00e9s da \u00abLazy Expiration\u00bb, se uma chave est\u00e1 vencida e, al\u00e9m disso, limpa ativamente, a intervalos regulares, entradas selecionadas aleatoriamente. Este m\u00e9todo misto evita a sobrecarga do temporizador por chave e mant\u00e9m o esfor\u00e7o administrativo reduzido. Quem compreende este mecanismo consegue controlar de forma espec\u00edfica a quantidade de mem\u00f3ria \u00abinativa\u00bb que \u00e9 tolerada a curto prazo, sem provocar falhas inesperadas no cache. Conce\u00e7\u00e3o do TTL: tempos, jitter e hierarquiza\u00e7\u00e3o Atribuo um TTL a cada chave de cache, mesmo quando utilizo a invalida\u00e7\u00e3o expl\u00edcita, pois um tempo de expira\u00e7\u00e3o constitui uma importante rede de seguran\u00e7a. Para dados pr\u00f3ximos do utilizador, come\u00e7o frequentemente com 5 a 15 minutos, mas ajusto o intervalo de acordo com a frequ\u00eancia de altera\u00e7\u00f5es e a toler\u00e2ncia a leituras obsoletas. As sess\u00f5es recebem tempos de validade curtos, os detalhes dos produtos tendem a ter tempos mais longos e as configura\u00e7\u00f5es t\u00eam ainda mais margem; assim, distribuo o risco e suavizo a carga. Al\u00e9m disso, adiciono um ligeiro jitter, cerca de \u00b110 %, para que milhares de chaves n\u00e3o expirem simultaneamente. Em caches multicamadas, fa\u00e7o com que a mem\u00f3ria da aplica\u00e7\u00e3o funcione em segundos, o Redis em minutos a horas e os n\u00edveis a montante tenham dura\u00e7\u00f5es mais longas, para evitar reconstru\u00e7\u00f5es dispendiosas. Invalida\u00e7\u00e3o expl\u00edcita sem efeitos colaterais 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":"Replica\u00e7\u00e3o do Redis | Documenta\u00e7\u00e3o"},"S2":{"id":"S2","url":"https:\/\/redis.io\/docs\/latest\/commands\/info\/","title":"INFORMA\u00c7\u00d5ES | Documentos"},"S3":{"id":"S3","url":"https:\/\/redis.io\/docs\/latest\/operate\/oss_and_stack\/management\/replication\/?utm_source=openai","title":"Replica\u00e7\u00e3o do Redis | Documenta\u00e7\u00e3o"},"S4":{"id":"S4","url":"https:\/\/github.com\/redis\/redis\/blob\/unstable\/redis.conf","title":"redis\/redis.conf na inst\u00e1vel \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":"Replica\u00e7\u00e3o de bases de dados | Documenta\u00e7\u00e3o"},"S6":{"id":"S6","url":"https:\/\/redis.io\/docs\/latest\/operate\/oss_and_stack\/management\/admin\/","title":"Administra\u00e7\u00e3o do Redis | Documenta\u00e7\u00e3o"}},"_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":"Compreender o backlog de replica\u00e7\u00e3o do Redis: PSYNC, tamanho e limites de alta disponibilidade","slug":"compreender-o-backlog-de-replicacao-do-redis","excerpt":"A fila de replica\u00e7\u00e3o do Redis mant\u00e9m uma amostra limitada do fluxo de replica\u00e7\u00e3o. Ap\u00f3s breves interrup\u00e7\u00f5es de liga\u00e7\u00e3o, permite frequentemente a utiliza\u00e7\u00e3o de PSYNC em vez de uma ressincroniza\u00e7\u00e3o completa, mas n\u00e3o substitui nem o armazenamento persistente de dados nem um conceito bem concebido de alta disponibilidade.","seo":{"title":"Compreender e planear adequadamente a fila de replica\u00e7\u00e3o do Redis","description":"Descubra o que o Redis Replication Backlog armazena, como funciona o PSYNC, como planear o tamanho e quais s\u00e3o os limites aplic\u00e1veis \u00e0 alta disponibilidade.","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\/pt\/wp-json\/wp\/v2\/posts\/21633","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/comments?post=21633"}],"version-history":[{"count":5,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21633\/revisions"}],"predecessor-version":[{"id":21642,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21633\/revisions\/21642"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/21637"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=21633"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=21633"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=21633"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}