Nos últimos dois meses, tenho trabalhado na atualização online de bancos de dados muito grandes como parte do projeto AXLE e gostaria de compartilhar meus pensamentos sobre o tópico e o progresso que fizemos recentemente.

Antes de ingressar no 2ndQuadrant, eu trabalhava no Skype, onde a empresa não permitia uma janela de manutenção para nossos bancos de dados. Isso significava que nenhum tempo de inatividade era permitido para implantações, atualizações, etc. Esse tipo de regra faz com que você mude a maneira como faz as coisas. A maioria das mudanças são pequenas, você não faz nenhum bloqueio pesado, você tem réplicas para permitir failover rápido. Mas enquanto você pode tornar seus lançamentos pequenos e sem bloqueios, o que acontece quando você precisa fazer uma atualização de versão principal do banco de dados PostgreSQL?


Você pode estar em uma situação diferente, pois a maioria das empresas tem uma janela de atualização e, portanto, você pode ter algum tempo de inatividade durante a atualização. Isso, porém, traz dois problemas. Por um lado, nenhuma empresa realmente gosta dos tempos de inatividade, mesmo que sejam permitidos. E, mais importante, uma vez que seu banco de dados cresce além de gigabytes em tamanho para a faixa de terabytes ou centenas de terabytes, o tempo de inatividade pode levar dias ou até semanas e ninguém pode se dar ao luxo de interromper suas operações por tanto tempo. O resultado é que muitas empresas muitas vezes ignoram atualizações importantes, tornando a próxima ainda mais dolorosa. E os desenvolvedores estão perdendo novos recursos, melhorias de desempenho. Eles (as empresas) às vezes até correm o risco de executar uma versão do PostgreSQL que não é mais suportada e tem problemas de segurança ou corrupção de dados conhecidos. Nos parágrafos a seguir, falarei um pouco sobre meu trabalho em tornar as atualizações menos demoradas e, como resultado, menos dolorosas e, espero, mais frequentes.

Deixe-me começar com um pouco de história primeiro. Antes do PostgreSQL 9.0, a única maneira de fazer uma atualização de versão principal era executar pg_dump e restaurar o dump em uma instância executando uma versão mais recente do PostgreSQL. Esse método exigia que a estrutura e todos os dados fossem lidos do banco de dados e gravados em um arquivo. Em seguida, leia o arquivo e insira em um novo banco de dados, os índices devem ser reconstruídos, etc.

Como você pode imaginar, esse processo pode levar algum tempo. Melhorias no desempenho foram feitas na versão 8.4 para pg_restore com a opção -j adicionada onde você pode especificar quantos trabalhos paralelos devem ser executados. Isso torna possível restaurar várias tabelas (índices, etc.) em paralelo, tornando o processo de restauração mais rápido para dumps de formato personalizado. A versão 9.3 adicionou opção semelhante ao pg_dump, melhorando ainda mais o desempenho. Mas dada a rapidez com que os volumes de dados estão crescendo, a paralelização em si não é suficiente para obter qualquer ganho sério no tempo necessário para a atualização.

Então, no PostgreSQL 9.0, chegou um utilitário chamado pg_upgrade. O Pg_upgrade despeja apenas as estruturas e as restaura no novo cluster. Mas ele copia os arquivos de dados como estão no disco, o que é muito mais rápido do que despejá-los em formato lógico e reinserir. Isso é bom o suficiente para bancos de dados pequenos porque significa um tempo de inatividade na faixa de minutos ou horas, um tempo aceitável para muitos cenários. Há também o modo de link que apenas cria links físicos (pontos de junção no Windows), o que torna esse processo ainda mais rápido. Mas, do meu ponto de vista pessoal, é muito perigoso executar essa configuração em um servidor mestre de produção. Vou explicar brevemente o porquê. Se algo der errado, assim que você iniciar o novo servidor que foi atualizado usando o modo de link, de repente você fica sem banco de dados de produção e precisa fazer failover ou, pior, restaurar a partir do backup. Isso significa que você não apenas falhou na atualização, mas acabou causando tempo de inatividade adicional! Boa sorte para obter aprovação na próxima vez.

Agora, muitas pessoas que não podem arcar com longos períodos de inatividade para atualizações usam as soluções de replicação baseadas em gatilho, como Slony ou Londiste, para fazer a atualização. Essa é uma boa solução porque você pode replicar seus dados enquanto o servidor original está em execução e, em seguida, alternar com o mínimo de tempo de inatividade. Na prática, porém, existem vários problemas. Uma delas é que as soluções baseadas em gatilho geralmente são difíceis de configurar, especialmente se você estiver fazendo isso apenas uma vez a cada dois anos e apenas para fazer a atualização. Também é fácil perder uma tabela ou adicionar tabelas na ordem errada e, portanto, não obter a cópia completa. Testemunhei isso na prática e as pessoas que estavam fazendo a atualização estavam trabalhando diariamente com a replicação baseada em gatilho . Outro problema é que as soluções baseadas em gatilho adicionam uma carga considerável no banco de dados de origem, às vezes impossibilitando a atualização devido à sobrecarga do servidor de banco de dados quando a replicação é ativada. E por último, mas não menos importante, pode levar muito tempo para que a replicação baseada em gatilho realmente mova os dados para o novo servidor. Na última ocasião em que estive envolvido com um projeto de atualização, a solução baseada em gatilho levou cerca de um mês para copiar o banco de dados e acompanhar as alterações. Sim, um mês.

Com o PostgreSQL 9.4 chega o recurso de decodificação lógica que oferece um novo começo para projetar uma nova e melhor solução de problemas de atualização online. O que fizemos, como parte do projeto AXLE, foi criar uma ferramenta que combina a decodificação lógica com as técnicas descritas acima. A solução resolve a maioria dos problemas das abordagens anteriores. A extensão PostgreSQL de replicação unidirecional (UDR para abreviar) faz a replicação lógica usando a decodificação lógica do log de gravação antecipada (WAL). Graças a isso, o impacto no servidor mestre é quase igual ao da replicação de streaming físico, portanto, a carga adicional causada pela atualização contínua é mínima no sistema em execução. Também fornece ferramentas para inicializar novos nós, usando backup físico e lógico. Você pode até mesmo transformar a espera física existente em espera UDR. E por ser um sistema de replicação lógica, é possível projetá-lo de uma forma que suporte a replicação entre versões.

O que tudo isso significa é que agora podemos usar UDR em combinação com pg_upgrade para fazer uma atualização online da versão principal do PostgreSQL com tempo de inatividade mínimo, em curto espaço de tempo absoluto e com impacto mínimo no sistema em execução.

Um exemplo de como isso pode parecer na prática:

• Faça o pg_basebackup da instância existente.
• Configure a replicação UDR entre a instância original e aquela criada pelo basebackup.
• Pg_atualize a nova instância.
• Deixe o UDR reproduzir as alterações que aconteceram nesse meio tempo.
• Mude o tráfego para a nova instância.

Para obter instruções mais detalhadas, consulte o guia UDR Online Upgrade no wiki do PostgreSQL. As fontes UDR estão disponíveis no repositório 2ndquadrant_bdr no servidor git PostgreSQL (bdr-plugin/next branch).

Por fim, como o UDR não é apenas uma ferramenta de atualização online, mas também uma solução de replicação, ele pode ser usado para suas necessidades normais de replicação, em vez da replicação de streaming físico. Além disso, oferece várias vantagens, como a capacidade de criar tabelas temporárias, replicar de vários bancos de dados OLTP em um banco de dados de big data warehouse ou replicar apenas parte do banco de dados.

Minha esperança é que esse esforço signifique que as considerações de tempo de inatividade não sejam mais um problema quando se trata de atualizar do PostgreSQL 9.4 e superior para uma nova versão principal.

A pesquisa que levou a esses resultados recebeu financiamento do Sétimo Programa-Quadro da União Europeia (FP7/2007-2013) sob o contrato de doação n° 318633.