Melhores práticas para atualizar versões principais e secundárias do Amazon RDS PostgreSQL

• O que acontece durante as atualizações de versões principais e secundárias
• Problemas comuns que ocorrem durante os upgrades
• Entendendo o recurso do RDS “Atualização automatizada de versões secundárias”
• Preparando-se para uma atualização

Atualizações de versões principais e secundárias

Começando com o PostgreSQL 10, um aumento no primeiro dígito do número da sua versão indica uma versão nova e maior, por exemplo, da versão 10 para a versão 11. O segundo dígito indica uma versão secundária, por exemplo, da versão 10.4 à 10.9. Antes do PostgreSQL 10, o segundo dígito também podia indicar uma versão principal, como da versão 9.5 à 9.6, enquanto um terceiro dígito indicava uma versão secundária, por exemplo, da versão 9.6.5 à 9.6.10.

Versões menores corrigem vulnerabilidades de segurança, bugs de funcionalidade e geralmente não adicionam novos recursos. As versões secundárias nunca alteram o formato de armazenamento interno e são sempre compatíveis com versões secundárias anteriores e posteriores do mesmo número de versão principal. Por exemplo, a versão 10.4 é compatível com a versão 10.1 e a versão 10.6. Da mesma forma, a versão 9.5.3 é compatível com as versões 9.5.0, 9.5.1 e 9.5.6. Para atualizar entre versões compatíveis, o RDS substitui os arquivos binários enquanto o servidor está inativo e os reinicia. O diretório de dados permanece inalterado. É por isso que as atualizações menores são mais rápidas do que as atualizações principais.

Nas versões mais antigas do PostgreSQL, o formato interno das tabelas do sistema, dos arquivos de dados e do formato interno de armazenamento de dados também muda. Isso complica as atualizações. O RDS usa a ferramenta PostgreSQL pg_upgrade para realizar grandes atualizações.

Nas principais atualizações de versões, o RDS executa as seguintes etapas:

1. Faça uma captura instantânea antes da atualização. Esse instantâneo pode ser usado para abortar (reverter) o processo e retornar à versão anterior posteriormente, se necessário.
2. Interrompe a instância do PostgreSQL e a prepara para uma atualização.
3. Use a ferramenta pg_upgrade para executar a tarefa de upgrade na instância.
4. Faça outro instantâneo após a atualização e ajuste as configurações de rede.

Quando o RDS inicia a Etapa 1, a instância muda seu status de Disponível (Available) para Atualização (Upgrading).  Após a Etapa 4, o status da instância retorna para Disponível (Available).

A tabela a seguir resume as diferenças mais significativas entre as etapas envolvidas nas atualizações de versões principais e secundárias:

Problemas comuns que ocorrem durante uma atualização

Às vezes, a atualização do RDS PostgreSQL apresenta alguns problemas. Esses problemas estão relacionados a tipos de dados e objetos de banco de dados não suportados. O log de eventos no banco de dados pg_upgrade.log contém detalhes desses problemas. Alguns dos problemas são mencionados abaixo:

INCOMPATIBLE_PARAMETER

Esse erro ocorre se um parâmetro relacionado à memória, como shared_buffer ou work_memory, foi definido como muito grande e causou um erro no script pg_upgrade. Para corrigir o problema, você deve reduzir os valores e tentar a atualização novamente.

STORAGE_FULL

Ao executar o script pg_upgrade, a instância pode ficar sem espaço em disco. Isso faz com que o script falhe. É exibida uma mensagem de erro semelhante à seguinte:

pg_restore: [archiver (db)] Error while PROCESSING TOC: 
pg_restore: [archiver (db)] could not execute query: ERROR: could not create file "base/12345/12345678": No space left on device 

Para resolver esse problema, ao realizar a atualização, certifique-se de que a instância tenha espaço de armazenamento livre suficiente, dependendo do número de bancos de dados e arquivos de dados.

Logical replication slots

Se o banco de dados estiver usando “slots de replicação lógica”, a atualização da versão principal falhará e mostrará a seguinte mensagem:

PreUpgrade checks failed: The instance could not be upgraded because one or more databases have logical replication slots. Please drop all logical replication slots and try again.

Para resolver o problema, interrompa qualquer tarefa de DMS ou de replicação lógica em execução e remova todos os slots de replicação lógica existentes. Execute as seguintes instruções SQL:

SELECT * FROM pg_replication_slots;
SELECT pg_drop_replication_slot(slot_name);

Release date dependency

Se a data de lançamento da versão de destino for anterior à data de lançamento da versão atual, você não poderá atualizar a instância. É exibida uma mensagem de erro semelhante à seguinte:

Cannot upgrade postgres from 9.5.12 to 9.6.6 (Service: AmazonRDS; Status Code: 400; Error Code: InvalidParameterCombination; Request ID: 12345ab-12345ab-12345-ab)

No exemplo acima, a data de lançamento da versão 9.5.12 é 1º de março de 2018, enquanto a data de lançamento da versão 9.6.6 é 9 de novembro de 2017. Para corrigir esse problema, verifique as notas oficiais de lançamento do PostgreSQL para saber a data de lançamento e pesquise a versão secundária mais recente disponível.

Master user name

Se o nome de usuário master começar com pg_, a atualização falhará e a seguinte mensagem de erro será exibida:

PreUpgrade checks failed: The instance could not be upgraded because one or more role names start with 'pg_'. Please rename all roles with names that start with 'pg_' and try again

Para resolver esse problema, crie outro usuário com participação na função rds_superuser. Você também deve entrar em contato com o suporte técnico da AWS para atualizar esse usuário como o novo usuário principal.

Entendendo o recurso “Atualização automatizada de versões menores”

Você pode configurar sua instância PostgreSQL do RDS com a opção “Atualização automática de versão secundária”, que permite realizar uma pequena atualização automaticamente toda vez que o RDS disponibiliza uma versão para atualizações. Por exemplo, se sua instância PostgreSQL do RDS estiver atualmente na versão 10.5 e você habilitar atualizações automáticas de versões secundárias, ela será atualizada automaticamente para a versão 10.6 durante o próximo período de manutenção. A instância do RDS não será atualizada automaticamente para nenhuma versão secundária subsequente, a menos que o RDS a disponibilize para essa finalidade.

Nem todas as versões secundárias estão disponíveis para atualizações automáticas. Para encontrar as versões disponíveis para atualizações automáticas, insira o seguinte comando da AWS CLI:

[ec2-user@ip- ~]$ aws rds describe-db-engine-versions --engine postgres | grep -A 1 AutoUpgrade| grep -A 2 true |grep PostgreSQL | sort --unique | sed -e 's/"Description": "//g' | sed -e 's/",//g'
PostgreSQL 10.6-R1
PostgreSQL 9.4.20-R1
PostgreSQL 9.5.15-R1
PostgreSQL 9.6.11-R1

Preparando uma atualização de versão secundária

Para uma atualização de versão secundária, conclua as seguintes etapas primeiro:

1. Revise as notas oficiais da versão do PostgreSQL que você planeja instalar para entender as mudanças introduzidas na nova versão.
2. Procure a próxima versão secundária apropriada, dependendo do caminho de atualização. Você pode usar um comando da AWS CLI para pesquisar versões secundárias disponíveis do PostgreSQL a partir do RDS. Por exemplo, para pesquisar versões secundárias superiores de uma instância que está atualmente na versão 9.5.12, insira o seguinte comando da AWS CLI:

   [ec2-user@ip-~]$ aws rds describe-db-engine-versions --engine postgres --engine-version 9.5.12 | grep -A 500 "ValidUpgradeTarget"| grep "EngineVersion"| grep 9.5| sed -e 's/"//g' |sed -e 's/EngineVersion: /PostgreSQL /g'
   PostgreSQL 9.5.13
   PostgreSQL 9.5.14
   PostgreSQL 9.5.15
   PostgreSQL 9.5.16
   PostgreSQL 9.5.18
   PostgreSQL 9.5.19 

3. Teste aplicativos com a carga de trabalho típica na nova versão secundária para calcular as interrupções e o desempenho esperados. Para testar a atualização, tire um instantâneo da instância de produção, restaure-a em um ambiente de teste e atualize-a para a nova versão secundária. Para limitar as chances de uma interrupção durante o upgrade, feche todas as conexões existentes e tire um instantâneo manual antes de executar o upgrade, para que o instantâneo de pré-atualização seja mais rápido. Você também pode usar réplicas de leitura para minimizar a interrupção durante uma pequena atualização de versão. Para fazer isso, você deve criar uma réplica de leitura e aplicar a pequena atualização à réplica. Depois que a réplica estiver sincronizada com a instância de origem, promova-a como instância primária e direcione o aplicativo para a nova instância.

Preparando-se para uma grande atualização de versão

Para uma atualização de versão principal, conclua as seguintes etapas primeiro:

1. Revise as notas oficiais da versão do PostgreSQL que você planeja instalar para entender as mudanças introduzidas na nova versão.
2. Procure a próxima versão principal apropriada, dependendo do caminho de atualização. Por exemplo, para pesquisar versões principais superiores de uma instância que está atualmente na versão 9.6.12, insira o seguinte comando da AWS CLI:

   [ec2-user@ip-~]$ aws rds describe-db-engine-versions --engine postgres --engine-version 9.6.12 | grep -A 200 "ValidUpgradeTarget"|grep "EngineVersion"| sed -e 's/"//g' |sed -e 's/EngineVersion: /PostgreSQL /g'
   PostgreSQL 9.6.14
   PostgreSQL 9.6.15
   PostgreSQL 10.7
   PostgreSQL 10.9
   PostgreSQL 10.10
   PostgreSQL 11.2

   O RDS PostgreSQL agora suporta a atualização de várias versões principais em uma única etapa.

3. Exclua qualquer VIEW com base nos catálogos do sistema da versão de destino. Por exemplo, um VIEW que depende de pg_stat_activity não pode ser atualizado de 9.5 para 9.6 porque a coluna de espera foi substituída por wait_event_type e wait_event.
4. Exclua qualquer tipo de dados unknown, dependendo da versão de destino escolhida. Por exemplo, a versão 10 deixou de oferecer suporte ao tipo de dados unknown. Um tipo de dados unknownna versão 9.6 não pode ser atualizado da versão 9.6 para a 10.6 e mostra a seguinte mensagem de erro:

   Database instance is in a state that cannot be upgraded: PreUpgrade checks failed: The instance could not be upgraded because the 'unknown' data type is used in user tables. Please remove all usages of the 'unknown' data type and try again." Below are some of the customer cases

   Você pode pesquisar o tipo de dados unknown em seu banco de dados e excluir a coluna ou alterar o tipo de dados para um tipo compatível executando a seguinte instrução SQL:

   SELECT DISTINCT data_type FROM information_schema.columns where data_type ilike 'unknown';

5. Crie uma nova instância RDS da versão principal de destino e execute pg_dump/ pg_restore para copiar dados da versão inferior para a versão superior.
   Como parte da atualização da versão principal, o programa pg_upgrade copia os arquivos de dados e restaura as alterações necessárias para dar suporte à nova versão. Essa etapa evita os problemas mencionados anteriormente.
   Durante esse teste, se você encontrar algum erro, a atualização provavelmente encontrará os mesmos erros. Para ter uma atualização sem problemas, você precisa resolver esses problemas. Crie uma nova instância RDS da versão de destino maior e execute pg_dump/ pg_restore para copiar os dados da versão inferior para a versão superior. Como parte da atualização, o programa pg_upgrade copia os arquivos de dados e restaura as alterações necessárias para dar suporte à nova versão. Essa etapa evita os problemas mencionados acima. Durante esse teste, se você encontrar algum erro, a atualização provavelmente encontrará os mesmos erros. Para que a atualização ocorra sem problemas, você deve resolver qualquer problema que tenha surgido nessa restauração.
6. Feche todas as conexões existentes e tire um instantâneo manual antes da atualização. Como parte de uma atualização de versão principal, um instantâneo é tirado durante o processo. Como os instantâneos do EBS são sempre incrementais, tirar um instantâneo antes do upgrade reduz o tempo off-line. Você pode usar o comando AWS CLIcreate-db-snapshot para tirar um instantâneo da instância do RDS.
7. Tenha um grupo de parâmetros pronto para uso pela nova instância atualizada do PostgreSQL do RDS. Se você estiver usando um grupo de parâmetros personalizado, precisará de um novo grupo de parâmetros para a versão de destino. Para aplicar o grupo de parâmetros personalizados, você deve reiniciar a instância.
8. Atualize suas extensões do PostgreSQL com o comando SQL ALTER EXTENSION UPDATE.
   Uma atualização para uma versão principal do PostgreSQL não atualiza as extensões. A instrução SQL incluída abaixo atualiza as extensões PostGIS da versão 9.4 para 9.5 do PostgreSQL:

   ALTER EXTENSION POSTGIS UPDATE TO '2.2.5';

9. Durante uma grande atualização de versão, o Amazon RDS também atualiza todas as réplicas de leitura na região junto com a instância principal do banco de dados.
10. Se necessário, realize o armazenamento escalável para obter 15%-20% de armazenamento gratuito para uma versão principal. Como alternativa, habilite o escalonamento automático do RDS Storage para mitigar quaisquer problemas de espaço imprevistos. Se necessário, aumente o armazenamento da instância RDS para obter o armazenamento disponível em 15 a 20%, o mínimo recomendado para uma atualização de versão principal. Você também pode ativar a escalabilidade automática do armazenamento no RDS para mitigar problemas de espaço imprevistos.
11. Interrompa qualquer tarefa do DMS que dependa da instância do RDS que você está atualizando definindo o parâmetro rds.logical_replication como 0.
    Quando a atualização estiver concluída, atualize a tabela pg_statistics statistics executando o comando SQL ANALYZE em todos os bancos de dados do usuário. Uma atualização de versão principal não move o conteúdo da tabela  pg_statistics para a nova versão. Ignorar essa etapa pode causar lentidão nas consultas SQL.
    Você também pode realizar um teste de atualização antes de atualizar os bancos de dados de produção. Você pode restaurar um instantâneo da instância de produção e realizar um teste. Considere testar o aplicativo no banco de dados atualizado com uma carga de trabalho semelhante para verificar se tudo está funcionando conforme o esperado. Depois que a atualização for verificada, você poderá excluir essa instância de teste. A configuração Multi-AZ não ajuda a evitar uma interrupção (tempo off-line) durante a atualização de um mecanismo de banco de dados. O Multi-AZ reduz o tempo off-line ao mudar de instância para outro nível de computação, mas como mudanças no nível de armazenamento são necessárias durante a atualização do mecanismo de banco de dados, as duas instâncias são atualizadas ao mesmo tempo. Se seu banco de dados estiver vulnerável a uma interrupção, você pode usar o AWS DMS, a replicação lógica ou a extensão pglogical para configurar a replicação entre duas instâncias principais diferentes. Quando as duas instâncias estiverem sincronizadas, desconecte os aplicativos e direcione os aplicativos para a nova instância mestre do RDS. Você também pode alterar o nome da instância na mesma região e na mesma conta da AWS para que seus aplicativos não precisem de alterações.

Resumo

A AWS continua trabalhando para tornar sua experiência de atualização de banco de dados mais confiável e ágil. As atualizações de versão no RDS PostgreSQL permitem alta segurança de dados, novos recursos e melhor desempenho. Embora o RDS gerencie atualizações menores e maiores com um único clique, é sua responsabilidade estar ciente das mudanças esperadas em suas cargas de trabalho, das interrupções que ocorrem e testar os aplicativos na versão de destino.

Os seguintes recursos relacionados ajudam você a entender melhor a atualização do RDS PostgreSQL:

• Atualizando o PostgreSQL com o Amazon RDS
• Atualização automática de versões secundárias do RDS PostgreSQL