Garantir que os bancos de dados de clientes estejam sempre disponíveis é uma das coisas mais importantes que fazemos na Lakebase. Projetamos o sistema com redundância em todos os níveis, fazendo failover e recuperando automaticamente seu banco de dados em caso de falhas de {hardware} ou software program.
Em um sistema de grande escala, tal falhas não planejadas são uma expectativa estatística, mas para um banco de dados particular person, não são que freqüente. Para um banco de dados particular person, manutenção planejada tende a causar mais interrupções na carga de trabalho. Afinal, um banco de dados típico recebe patches com mais frequência do que apresenta falhas de {hardware}.
Hoje, quase todos os provedores de banco de dados operam com janelas de manutenção: períodos em que seu banco de dados corta todas as conexões ativas e é atualizado e reiniciado em um processo que pode levar de alguns segundos a minutos. Enquanto Lakebase permite que você agendar atualizações no momento preferrred para você, ainda é uma breve interrupção quando isso acontece.
Achamos que podemos fazer melhor. Esta postagem do weblog é a primeira de uma série sobre como estamos aproveitando o arquitetura da base do lago para eliminar totalmente o impacto da manutenção planejada. Nosso objetivo: tornar as atualizações de versão e patches de segurança completamente imperceptíveis.
Neste submit, vamos cobrir pré-aquecimento: uma técnica que evita qualquer degradação de desempenho após a reinicialização do banco de dados. Em postagens futuras, discutiremos melhorias no próprio processo de failover e otimizações adicionais que nos aproximam da aplicação de patches sem tempo de inatividade actual.
O problema com reinicializações a frio
O desafio de reiniciar o PostgreSQL é que os caches na memória (especificamente o cache do buffer e cache de arquivo native) estão perdidos. Embora o banco de dados volte a ficar on-line muito rapidamente (1 segundo @ P99), a carga de trabalho pode sofrer uma lentidão nos primeiros minutos após a reinicialização – vimos uma redução de aproximadamente 70% no TPS do pgbench. Isso se deve a uma baixa taxa de acertos do cache enquanto os dados são lidos do armazenamento e o cache aquece. Embora isso possa parecer apenas um problema de desempenho, pode ser um problema de disponibilidade se a desaceleração for grave o suficiente para que o banco de dados não consiga acompanhar a carga de trabalho e ocorram tempos limite.
Existem técnicas para resolver isso no Postgres: pg_prewarm pode ser usado para aquecer caches de buffer. No entanto, isso funciona depois uma reinicialização quando a carga de trabalho já estiver afetada. A replicação de streaming pode ser usada para configurar uma réplica, que pode ser pré-aquecida antes de fazer failover (promovendo-a para primária). No entanto, isto requer a criação de uma réplica completa e a orquestração cuidadosa do pré-aquecimento antes do failover.
Pré-aquecimento na arquitetura Lakebase
No arquitetura da base do lagocombinamos nós de computação elásticos e sem estado com armazenamento desagregado e compartilhado. Os nós de computação empregar caches locais para oferecer desempenho máximo sem sacrificar as propriedades sem servidor. Embora o cache enfrente os mesmos problemas de inicialização a frio descritos acima, temos mais opções com a arquitetura Lakebase.
Como as réplicas de computação Postgres do Lakebase não têm estado, podemos aumentá-las e diminuí-las sob demanda. Utilizamos isso e combinamos com pré-aquecimento automático em reinicializações planejadas para minimizar o impacto no desempenho da carga de trabalho. É assim que funciona:
- Uma nova versão da imagem de computação Postgres do Lakebase fica disponível. Você recebe uma notificação e pode agendar a reinicialização para um horário que seja adequado para você.
- Pouco antes do horário programado, nosso plano de controle inicia uma nova computação do Postgres em segundo plano. Você não vê e não é cobrado por isso. A carga de trabalho do primário atual não é afetada.
- Uma lista de páginas no cache do primário atual é enviada para o novo cálculo. A nova computação carrega essas páginas no cache do nosso nível de armazenamento compartilhado sem afetar o primário.
- A nova computação assina o WAL (log write-ahead) para manter seu cache atualizado. Para maior eficiência, ao contrário de uma réplica regular do Postgres, ele pode ignorar todos os registros WAL que não afetam seu cache. Obtém o WAL do nosso Guardiõesnão colocando nenhuma carga adicional na computação primária.
- Quando o pré-aquecimento é concluído, desligamos rapidamente o antigo primário, promovemos o novo cálculo para primário e o ligamos. A promoção usa o padrão pg_promote do OSS Postgres e não reinicia o servidor de banco de dados.
Antes:
Depois:
Com a arquitetura lakebase, você obtém isso sem custo adicional, sem pagar por réplicas adicionais. A partir de hoje, todas as reinicializações planejadas de endpoints de leitura/gravação são realizadas dessa maneira, sem que você exact fazer nada. Em breve iremos estendê-lo também para endpoints somente leitura.
Resultados
Para medir o impacto dos caches frios, executamos 10 GB pgbench (fator de escala 670) em um banco de dados enquanto o reiniciamos – primeiro com pré-aquecimento ativado, então sem pré-aquecimento. O primeiro gráfico mostra uma carga de trabalho somente leitura (pgbench “somente seleção”), enquanto o segundo mostra uma carga de trabalho de leitura e gravação (pgbench “atualização simples”).
Em ambos os casos, vemos que o rendimento se recupera quase instantaneamente com o pré-aquecimento. Sem pré-aquecimento, a recuperação é muito mais lenta enquanto o cache frio está aquecendo. A diferença é maior para a carga de trabalho somente leitura porque o pré-aquecimento melhora a taxa de acertos do cache, o que ajuda proporcionalmente mais nas leituras do que nas gravações.