Na semana passada, estive no Nordic PGDay 2018 e tive algumas conversas sobre a ferramenta que escrevi, a saber, pglupgrade , para automatizar as atualizações da versão principal do PostgreSQL em uma configuração de cluster de replicação. Fiquei muito feliz por ter sido ouvido e algumas outras pessoas em diferentes comunidades dando palestras em encontros e outras conferências sobre atualizações de tempo de inatividade quase zero usando replicação lógica. Dado que há uma palestra que dei no PGDAY'17 Rússia, PGConf.EU 2017 em Varsóvia e por último no FOSDEM PGDay 2018 em Bruxelas, achei melhor criar um post no blog para manter esta apresentação disponível para as pessoas que pudessem não comparecer a nenhuma das conferências mencionadas. Se você quiser falar diretamente e pular a leitura desta postagem do blog, aqui está o link:Atualizações automatizadas de tempo de inatividade quase zero de clusters PostgreSQL na nuvem
A principal motivação por trás do desenvolvimento desta ferramenta foi propor uma solução para minimizar o tempo de inatividade durante grandes atualizações de versão que infelizmente afetam quase todos que usam o PostgreSQL. Atualmente, não temos uma ferramenta que permita aos usuários do PostgreSQL atualizar seus bancos de dados sem tempo de inatividade e é claramente um ponto problemático para muitos usuários, especialmente empresas. E, se quisermos resolver o problema de atualização, devemos pensar em mais de um servidor (será referido como um cluster a partir de agora), simplesmente porque muitas pessoas não usam mais apenas um servidor de banco de dados. O cenário mais comum é ter a configuração de replicação de streaming físico para fins de alta disponibilidade ou dimensionar as consultas de leitura.
Atualizações de banco de dados
Antes de mergulhar na solução, vamos discutir um pouco sobre como as atualizações de banco de dados funcionam em geral. Existem quatro abordagens principais possíveis para atualizações de banco de dados:
- A primeira abordagem seria que os bancos de dados mantivessem seu formato de armazenamento igual ou pelo menos compatível entre as versões. No entanto, isso é difícil de garantir a longo prazo, pois novos recursos podem exigir alterações na forma como os dados são armazenados ou adicionar mais informações de metadados para funcionar corretamente. Além disso, o desempenho geralmente é aprimorado com a otimização das estruturas de dados.
- A segunda abordagem é fazer uma cópia lógica (dump) do servidor antigo e carregá-la no novo servidor. Essa é a abordagem mais tradicional que exige que o servidor antigo não receba atualizações durante o processo e resulta em tempos de inatividade prolongados de horas ou mesmo dias em grandes bancos de dados.
- A terceira opção é converter dados do formato antigo para o novo. Isso pode ser feito em tempo real enquanto o novo sistema está em execução, mas incorre em penalidade de desempenho que é difícil de prever, pois depende dos padrões de acesso aos dados, ou pode ser feito offline enquanto os servidores estão inativos, novamente incorrendo em prolongado inatividade (embora geralmente mais curto que o segundo método).
- O quarto método é usar o dump lógico para salvar e restaurar o banco de dados enquanto captura as alterações que ocorrem nesse meio tempo e replicá-los logicamente para o novo banco de dados assim que a restauração inicial for concluída. Esse método requer a orquestração de vários componentes, mas também diminui o tempo que o banco de dados não pode responder às consultas.
Métodos de atualização no PostgreSQL
As atualizações do PostgreSQL podem ser combinadas com os quatro métodos listados acima. Por exemplo, as versões secundárias do PostgreSQL, que não contêm novos recursos, mas apenas correções, não alteram o formato de dados existente e se encaixam na primeira abordagem. Para a segunda abordagem, o PostgreSQL fornece ferramentas chamadas pg_dump e pg_restore que fazem o backup e a restauração lógicos. Há também a ferramenta pg_upgrade (era um módulo contrib e movido para a árvore principal no PostgreSQL 9.5) que faz a conversão offline (os servidores não estão rodando) do diretório de dados antigo para o novo, que pode se encaixar na terceira opção. Para a quarta abordagem, existem soluções baseadas em gatilhos de terceiros, como o Slony, para atualização, mas elas têm algumas ressalvas que abordaremos mais tarde.
Os métodos tradicionais de atualização podem apenas atualize o servidor primário enquanto os servidores de réplica precisam ser reconstruídos posteriormente (conversão offline) . Isso leva a problemas adicionais com a disponibilidade e a capacidade do cluster, aumentando efetivamente o tempo de inatividade percebido do banco de dados do ponto de vista de aplicativos e usuários. Replicação lógica permite replicação enquanto o sistema está em funcionamento e o esforço de teste pode ser tratado nesse meio tempo (conversão on-line) .
Existem diferentes métodos de atualização aplicáveis a diferentes ambientes. Por exemplo, pg_dump permite a atualização de versões muito antigas (ou seja, 7.0) para lançamentos recentes, então se você estiver executando uma versão antiga do PostgreSQL, o melhor método é usar pg_dump/restore (e melhor fazê-lo agora!). Se a sua versão do PostgreSQL for 8.4 e posterior você pode usar pg_upgrade . Se você estiver usando o PostgreSQL 9.4 e posterior isso significa que você tem "Decodificação lógica" no núcleo e você pode usar o pglogical extensão como meio de atualização. Finalmente, se você estiver usando o PostgreSQL 10 , você terá a chance de atualizar seu banco de dados para PostgreSQL 11 e posterior (assim que estiverem disponíveis) usando "Replicação lógica" no núcleo (yay!).
Replicação lógica para atualizações
Onde está a ideia de atualizar o PostgreSQL usando a replicação lógica vem de?Claramente, pglógico não reivindica a finalidade de atualização abertamente como pg_upgrade faz (este foi um argumento contra o pglogical na festa da conferência ), mas isso não significa que não podemos usar a ferramenta para atualizações. De fato, quando o pglogical foi projetado, atualizações de tempo de inatividade quase zero foram consideradas como um dos casos de uso esperados pelos desenvolvedores da extensão.
Ao contrário da replicação física, que captura alterações nos dados brutos em disco, a replicação lógica captura as alterações lógicas nos registros individuais no banco de dados e as replica. Os registros lógicos funcionam nas principais versões , portanto, a replicação lógica pode ser usada para atualizar de um lançamento para outro. A ideia de usar a replicação lógica como meio de atualização de versão está longe de ser nova, as ferramentas de replicação baseadas em trigger vêm fazendo atualizações de forma lógica capturando e enviando as alterações por meio de triggers (porque triggers podem funcionar independentemente das versões do banco de dados também! ).
Se você pode usar soluções de replicação baseadas em gatilho para atualizações com tempo de inatividade mínimo, por que preferir a replicação lógica? Em um mecanismo baseado em gatilhos, todas as alterações são capturadas usando gatilhos e gravadas em tabelas de filas. Esse procedimento duplica as operações de gravação, duplica os arquivos de log e torna o sistema mais lento, pois todas as alterações precisam ser gravadas duas vezes; resultando em mais E/S de disco e carga no servidor de origem. Em contraste, a replicação lógica no núcleo (o mesmo vale para a extensão pglogical) é construída sobre a decodificação lógica. A decodificação lógica é um mecanismo que extrai informações de arquivos WAL em alterações lógicas (INSERT/UPDATE/DELETE). Como os dados do mecanismo WAL são usados para decodificar os logs de transações, não há sem amplificação de gravação como no caso de soluções de replicação baseadas em gatilhos, portanto, esse método tem um desempenho melhor . Como resultado, as soluções baseadas em decodificação lógica simplesmente têm um impacto menor no sistema do que as soluções baseadas em trigger.
Conclusão
Nesta postagem introdutória, quero dar uma ideia de por que devemos considerar o uso da replicação lógica para obter o mínimo de tempo de inatividade durante as principais atualizações de versão. Continuaremos com os detalhes da arquitetura e implementação da ferramenta no próximo post.
