O PostgreSQL 9.6 acaba de ser lançado e a maioria dos usuários do postgres começará a se perguntar como atualizar para a nova versão principal. Este post tem a intenção de mostrar diferentes procedimentos para atualizar seu servidor PostgreSQL.
A atualização para uma nova versão principal é uma tarefa que possui uma alta proporção de preparação em relação ao tempo total de execução. Especificamente ao pular uma versão no meio, por exemplo, quando você pula da versão 9.3 para a versão 9.5.
Lançamentos pontuais
Por outro lado, as atualizações de lançamento pontual não precisam de tanta preparação. Geralmente, o único requisito é que o serviço postgres seja reiniciado. Não há alterações na estrutura de dados subjacente, portanto, não há necessidade de despejar e restaurar. Na pior das hipóteses, pode ser necessário recriar alguns de seus índices depois de concluir a atualização da versão pontual.
É muito sábio ficar sempre na versão mais recente, para que você não tropece em um bug conhecido (e provavelmente corrigido). Isso significa que, assim que a versão mais recente for lançada, agende um horário para a atualização o mais rápido possível.
Atualização de versão principal
Ao realizar tarefas complexas como esta, é bom considerar todas as opções possíveis para alcançar o resultado final.
Para atualizações de versão principais, há três caminhos possíveis que você pode seguir:
- Atualize a restauração de um dump lógico
- Atualização física
- Atualização on-line
Deixe-me explicar cada um em detalhes:
1) Atualize a restauração de um dump lógico
Essa é a maneira mais simples de atualizar a estrutura de dados do cluster.
Para resumir, o processo aqui requer um dump lógico usando pg_dump da versão antiga e pg_restore em um cluster limpo criado com a versão recém-instalada.
Os principais pontos a favor da utilização deste caminho são:
- É o mais testado
- A compatibilidade remonta às versões 7.0 para que você possa atualizar da 7.x para uma das versões recentes
Razões pelas quais você deve evitar usar esta opção:
- O tempo de inatividade total em bancos de dados grandes pode ser um problema, pois você precisa parar de gravar conexões antes de começar a executar o pg_dump;
- Se houver muitos objetos grandes no banco de dados, o pg_dump será lento. Mesmo ao fazê-lo em paralelo. A restauração será ainda mais lenta que o pg_dump quando muitos objetos grandes forem armazenados no banco de dados;
- Requer espaço duplo em disco ou a remoção do cluster antigo antes da restauração;
Em servidores com vários núcleos de CPU, é possível executar o pg_dump em paralelo usando o formato de diretório. Assim que terminar, restaure em paralelo também, usando a opção -j tanto no pg_dump quanto no pg_restore. Mas você não pode iniciar o processo de restauração até que todo o despejo seja concluído.
2) Atualização física
Esse tipo de atualização está disponível desde a versão 9.0 para realizar atualizações in-loco de versões tão antigas quanto 8.3. Eles são chamados de “in-place” porque são feitos no mesmo servidor e, de preferência, no mesmo diretório de dados.
Vantagens deste tipo de atualizações:
- Você não precisa de espaço para outra cópia do cluster.
- O tempo de inatividade é muito menor em comparação com o uso do pg_dump.
Existem algumas desvantagens:
- Depois de iniciar a nova versão do PostgreSQL, não há como voltar para a versão antiga (o cluster funcionará apenas com a nova versão a partir daí).
- As estatísticas são zeradas após a atualização, portanto, logo após iniciar a nova versão do PostgreSQL, uma análise de todo o cluster deve ser executada.
- Muitos bugs foram encontrados nos últimos anos em relação ao pg_upgrade, o que torna alguns administradores de banco de dados relutantes em usar esse método para atualização.
- Algumas pessoas tiveram problemas ao pular uma versão principal, por exemplo, ao passar da versão 9.2 para a versão 9.4.
- Com catálogos grandes, ele terá um desempenho ruim (clusters com muitos bancos de dados ou bancos de dados com muitos milhares de objetos).
Você também pode executar pg_upgrade sem a opção –link (neste caso, pg_upgrade irá gerar uma segunda cópia no disco do seu cluster) para que você possa voltar para a versão antiga. Mas você perderá as duas vantagens listadas acima.
3) Atualização on-line
O procedimento a seguir para este método seria assim:
- Instale as duas versões para que elas funcionem em paralelo. Isso pode ser feito no mesmo servidor ou usando dois servidores físicos.
- Crie uma cópia inicial e replique as alterações a partir do momento em que você iniciou a cópia no nó de origem (isso seria semelhante a um pg_dump inicial).
- Continue replicando logicamente as alterações até que o atraso esteja próximo de zero.
- Reencaminhe as informações de conexão do servidor de aplicativos para se conectar ao novo servidor.
Esse tipo de atualização está disponível desde que surgiram as primeiras soluções de replicação baseadas em gatilho. Em outras palavras, desde que Slony-I estava por perto.
As soluções de replicação baseadas em gatilhos não se importam com a versão que você tem de um lado ou do outro, pois copia as alterações usando comandos SQL suportados.
As ferramentas de replicação baseadas em gatilho recomendadas, na ordem em que aparecem, são:
- skytools:PgQ + londiste
- Slony-I
Esta deve ser a forma preferida de atualização. Vejamos as vantagens de usar este método:
- Zero tempo de inatividade!
- Ótimo também para atualizar para um hardware mais recente.
- Teste on-line do cluster com a nova versão (consultas somente leitura, ou você pode acabar com conflitos).
- Reduz drasticamente todos os inchaços de tabelas e índices.
Existem algumas desvantagens:
- Ele precisa de espaço de armazenamento duplo, pois precisa armazenar uma segunda cópia de seus dados.
- Como é baseado em gatilhos, o sistema precisa gravar cada alteração duas vezes, o que significa que haverá mais E/S de disco no servidor de origem (versão antiga do cluster).
- Todas as tabelas precisam ter uma chave primária, para que a ferramenta de replicação possa individualizar as tuplas que são atualizadas ou excluídas
- Ele não replica tabelas de catálogo, portanto, não replicará objetos grandes.
- O uso básico não abrange alterações de esquema. Isso pode ser feito, mas não de forma transparente.
Uma nova fronteira com pglogical
Desde o PostgreSQL 9.4 temos decodificação lógica dos logs de transações. Isso significa que agora podemos decodificar as transações do WAL e manipular a saída.
Um novo mundo de possibilidades apareceu no campo da replicação. Os gatilhos não são mais necessários para realizar a replicação lógica!
Isso basicamente significa que você não precisa mais salvar uma cópia separada de todas as inserções, atualizações e exclusões usando gatilhos. Você pode apenas obter essas operações de manipulação de dados dos logs de transações, decodificando-os. Então, é a ferramenta que você está usando que tem que manipular a saída e enviá-la para o nó downstream inscrito. Neste caso, essa ferramenta é pglogical.
Então, o que isso tudo significa?
Bem, se você estiver em uma versão 9.4 ou 9.5 do PostgreSQL e quiser atualizar para 9.6, você pode realizar uma atualização online como a detalhada acima, mas usando pglogical em vez de uma das soluções de replicação baseadas em gatilho.
Não entrarei em detalhes, pois existem outros blogs sobre esse tópico em particular, como este escrito por Petr Jelinek:Pacotes PGLogical 1.1 para PostgreSQL 9.6beta1
Conclusões
Dependendo do esquema do seu banco de dados, do tamanho dos dados, possível janela de tempo de inatividade, versão da instalação atual do PostgreSQL, você pode escolher uma opção em vez de outra ou o que for melhor.
- Se seu banco de dados for pequeno e houver uma janela de manutenção adequada que você possa usar, você pode optar por executar um pg_dump e um pg_restore. Dependendo do tamanho do conjunto de dados, há um ponto em que a opção não é mais viável.
- Se você tiver um banco de dados grande (várias centenas de GBs ou até TBs de dados), precisará procurar outras opções, como uma atualização in-loco com pg_upgrade ou uma atualização online.
- Se estiver atualizando da versão 8.3 ou superior para qualquer versão 9.x, você pode usar pg_upgrade.
- Para versões anteriores à 8.3, você terá que optar por uma das soluções de replicação lógica, como londiste ou slony.
- Se em um banco de dados 9.4 ou 9.5, é melhor usar o pglogical.
Lembre-se sempre que para replicação lógica as tabelas precisam ter uma Chave Primária.
Com o pglogical, essa regra não é tão rígida:você pode replicar tabelas somente de inserção. Mas para atualização e exclusões, ainda é obrigatório ter uma Chave Primária ou uma IDENTIDADE DE REPLICA na tabela.
Se precisar de ajuda para atualizar seu banco de dados PostgreSQL, você pode verificar os
serviços de atualização do 2ndQuadrant.
