Como atualizar os clusters de banco de dados de Amazon Aurora MySQL

O Amazon Aurora disponibiliza novas versões do mecanismo de banco de dados do PostgreSQL em Regiões da AWS somente após testes extensivos. Você poderá atualizar seus clusters de banco de dados do Aurora PostgreSQL para a nova versão quando ela estiver disponível em sua região.

Dependendo da versão do Aurora PostgreSQL em que seu cluster de banco de dados está em execução no momento, uma atualização para a nova versão é secundária ou principal. Por exemplo, a atualização de um cluster de banco de dados do Aurora PostgreSQL 11.15 para o Aurora PostgreSQL 13.6 é uma atualização da versão principal. Por exemplo, a atualização de um cluster de banco de dados do Aurora PostgreSQL 11.15 para o Aurora PostgreSQL 13.6 é uma atualização da versão secundária. Nos tópicos a seguir, você encontrará informações sobre como realizar os dois tipos de atualizações.

Sumário

• Visão geral dos processos de atualização do Aurora PostgreSQL
• Obter uma lista de versões disponíveis em sua Região da AWS
• Como realizar uma atualização de versão principal
  • Testar um upgrade de cluster de banco de dados de produção para uma nova versão principal
  • Atualizar o mecanismo do Aurora PostgreSQL para uma nova versão principal
    • Atualizações principais de bancos de dados globais
• Antes de realizar um upgrade da versão secundária
• Como realizar atualizações de versão secundária e aplicar patches
  • Atualizações de versões secundárias e patches com tempo de inatividade zero
  • Atualizar o mecanismo do Aurora PostgreSQL para uma nova versão secundária
• Atualizar extensões do PostgreSQL
• Técnica alternativa de atualização azul-verde

Visão geral dos processos de atualização do Aurora PostgreSQL

As diferenças entre atualizações de versão principal e secundária são as seguintes:

Patches e atualizações de versões secundárias

Patches e atualizações de versões secundárias incluem somente alterações compatíveis com versões anteriores das aplicações existentes. Patches e atualizações de versões secundárias ficam disponíveis para você somente depois que o Aurora PostgreSQL os testa e os aprova.

Atualizações de versões secundárias podem ser aplicadas automaticamente pelo Aurora. Quando você cria um cluster de banco de dados PostgreSQL do Aurora, a opção Enable minor version upgrade (Ativar atualização de versão secundária) é pré-selecionada. A menos que você desative essa opção, as atualizações de versões secundárias serão aplicadas automaticamente durante a janela de manutenção agendada. Para obter mais informações sobre a opção de atualização automática de versão secundária (AmVU) e como modificar o cluster de banco de dados do Aurora para usá-lo, consulte Atualizações da versão secundária automáticas para clusters de banco de dados do Aurora.

Se a opção de atualização automática de versão secundária não estiver definida para seu cluster de banco de dados do Aurora PostgreSQL, o Aurora PostgreSQL não será atualizado automaticamente para a nova versão secundária. Em vez disso, quando uma nova versão secundária é lançada em sua Região da AWS e o cluster de banco de dados do Aurora PostgreSQL está executando uma versão secundária mais antiga, o Aurora solicita a atualização. Ele faz isso adicionando uma recomendação às tarefas de manutenção do cluster.

Os patches não são considerados atualizações e não são aplicados automaticamente. O Aurora PostgreSQL solicita que você aplique todos os patches adicionando uma recomendação às tarefas de manutenção do cluster de banco de dados do Aurora PostgreSQL. Para ter mais informações, consulte Como realizar atualizações de versão secundária e aplicar patches.

nota

Patches que resolvem problemas de segurança ou outros problemas críticos também são adicionados como tarefas de manutenção. No entanto, esses patches são necessários. Aplique patches de segurança ao cluster de banco de dados do Aurora PostgreSQL quando eles estiverem disponíveis em suas tarefas de manutenção pendentes.

O processo de atualização envolve a possibilidade de breves interrupções à medida que cada instância no cluster é atualizada para a nova versão. No entanto, após o Aurora PostgreSQL 14.3.3, 13.7.3, 12.11.3, 11.16.3, 10.21.3, bem como outras versões posteriores dessas versões secundárias e principais mais recentes, o processo de atualização usa o recurso ZDP (zero-downtime patch). Esse recurso minimiza as interrupções e, na maioria dos casos, as elimina completamente. Para ter mais informações, consulte Atualizações de versões secundárias e patches com tempo de inatividade zero.

nota

O ZDP não é compatível nos seguintes casos:

• Quando os clusters de banco de dados do Aurora PostgreSQL são configurados como o Aurora Serverless v1.

• Quando os clusters de banco de dados do Aurora PostgreSQL são configurados como um banco de dados global do Aurora nas Regiões da AWS secundárias.

• Durante o upgrade das instâncias de leitura no banco de dados global do Aurora.

• Durante os patches e atualizações do sistema operacional.

O ZDP não é compatível com clusters de banco de dados do Aurora PostgreSQL que são configurados como Aurora Serverless v2.

Atualizações da versão principal

Ao contrário de atualizações e patches de versões secundárias, o Aurora PostgreSQL não tem uma opção automática de atualização de versão principal. Novas versões principais do PostgreSQL podem conter alterações de banco de dados incompatíveis com versões anteriores das aplicações existentes. A nova funcionalidade pode fazer com que suas aplicações existentes parem de funcionar corretamente.

Para evitar problemas, é altamente recomendável seguir o processo descrito em Testar um upgrade de cluster de banco de dados de produção para uma nova versão principal antes de atualizar as instâncias de banco de dados em seus clusters de banco de dados do Aurora PostgreSQL. Primeiro, verifique se suas aplicações podem ser executadas na nova versão seguindo esse procedimento. Depois, você pode atualizar manualmente o cluster de banco de dados do Aurora PostgreSQL para a nova versão.

O processo de upgrade envolve a possibilidade de uma breve interrupção quando todas as instâncias no cluster são atualizadas para a nova versão. O processo de planejamento preliminar também leva tempo. Recomendamos que você sempre execute tarefas de atualização durante a janela de manutenção do cluster ou quando as operações forem mínimas. Para ter mais informações, consulte Como realizar uma atualização de versão principal.

nota

Tanto as atualizações de versões secundárias quanto as atualizações de versões principais podem envolver breves interrupções. Por esse motivo, recomendamos que você execute ou programe atualizações durante sua janela de manutenção ou durante outros períodos de baixa utilização.

Os clusters de banco de dados do Aurora PostgreSQL ocasionalmente exigem atualizações do sistema operacional. Essas atualizações às vezes incluem uma versão mais recente da biblioteca glibc. Durante essas atualizações, recomendamos que você siga as diretrizes descritas em Agrupamentos compatíveis com Aurora PostgreSQL.

Obter uma lista de versões disponíveis em sua Região da AWS

Você pode obter uma lista de todas as versões do mecanismo disponíveis como destinos de upgrade para seu cluster de banco de dados do Aurora PostgreSQL consultando sua Região da AWS usando o comando describe-db-engine-version da AWS CLI conforme mostrado a seguir.

Para Linux, macOS ou Unix:

aws rds describe-db-engine-versions \
  --engine aurora-postgresql \
  --engine-version version-number \
  --query 'DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}' \
  --output text

Para Windows:

aws rds describe-db-engine-versions ^
  --engine aurora-postgresql ^
  --engine-version version-number ^
  --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" ^
  --output text

Por exemplo, para identificar os destinos de upgrade válidos para um cluster de banco de dados do Aurora PostgreSQL versão 12.10, execute o seguinte comando da AWS CLI:

Para Linux, macOS ou Unix:

aws rds describe-db-engine-versions \
  --engine aurora-postgresql \
  --engine-version 12.10 \
  --query 'DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}' \
  --output text

Para Windows:

aws rds describe-db-engine-versions ^
  --engine aurora-postgresql ^
  --engine-version 12.10 ^
  --query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" ^
  --output text

Nesta tabela, você pode encontrar os upgrades desejados de versões primárias e secundárias disponíveis para várias versões de banco de dados do Aurora PostgreSQL.

Versão de origem atual	Destinos de atualização
16.1	16.2
15.6	16.2
15.5	16.2	16.1	15.6
15.4	16.2	16.1	15.6	15.5
15.3	16.2	16.1	15.6	15.5	15.4
15.2	16.2	16.1	15.6	15.5	15.4	15.3
14.11	16.2	15.6
14.10	16.2	16.1	15.6	15.5
14.9	16.2	16.1	15.6	15.5	15.4	14.11	14.10
14.8	16.2	16.1	15.6	15.5	15.4	15.3	15.2	14.11	14.10	14.9
14.7	16.2	16.1	15.6	15.5	15.4	15.3	15.2	14.11	14.10	14.9	14.8
14.6	16.2	16.1	15.6	15.5	15.4	15.3	15.2	14.11	14.10	14.9	14.8	14.7
14.5	16.2	16.1	15.6	15.5	15.4	15.3	15.2	14.11	14.10	14.9	14.8	14.7	14.6
14.4	16.2	16.1	15.6	15.5	15.4	15.3	15.2	14.11	14.10	14.9	14.8	14.7	14.6	14.5
14.3	16.2	16.1	15.6	15.5	15.4	15.3	15.2	14.11	14.10	14.9	14.8	14.7	14.6	14.5	14.4
13.14	16.2	15.6	14.11
13.13	16.2	16.1	15.6	15.5	14.11	14.10
13.12	16.2	16.1	15.6	15.5	15.4	14.11	14.10	14.9
13.11	16.2	16.1	15.6	15.5	15.4	15.3	14.11	14.10	14.9	14.8
13.10	16.2	16.1	15.6	15.5	15.4	15.3	15.2	14.11	14.10	14.9	14.8	14.7	13.14	13.13	13.12	13.11
13.9	16.2	16.1	15.6	15.5	15.4	15.3	15.2	14.11	14.10	14.9	14.8	14.7	14.6	13.14	13.11	13.10
13.8	16.2	16.1	15.6	15.5	15.4	15.3	15.2	14.11	14.10	14.9	14.8	14.7	14.6	14.5	13.14	13.13	13.12	13.11	13.10	13.9
13.7	16.2	16.1	15.6	15.5	15.4	15.3	15.2	14.11	14.10	14.9	14.8	14.7	14.6	14.5	14.4	14.3	13.14	13.13	13.12	13.11	13.10	13.9	13.8
12.18	16.2	15.6	14.11	13.14
12.17	16.2	16.1	15.6	15.5	14.11	14.10	13.13
12.16	16.2	16.1	15.6	15.5	15.4	14.11	14.10	14.9	13.14	13.13	13.12
12.15	16.2	16.1	15.6	15.5	15.4	15.3	14.11	14.10	14.9	14.8	13.14	13.13	13.12	13.11
12.14	16.2	16.1	15.6	15.5	15.5	15.4	15.3	15.2	14.11	14.10	14.9	14.8	14.7	13.14	13.13	13.12	13.11	13.10	12.15
12.13	16.2	16.1	15.6	15.5	15.4	15.3	15.2	14.11	14.10	14.9	14.8	14.7	14.6	13.14	13.13	13.12	13.11	13.10	13.9	12.17	12.16	12.15	12.14
12.12	16.2	16.1	15.6	15.5	15.4	15.3	15.2	14.11	14.10	14.9	14.8	14.7	14.6	14.5	13.14	13.13	13.12	13.11	13.10	13.9	12.17	12.16	12.15	13.8	12.15	12.14	12.13
12.11	16.2	16.1	15.6	15.5	15.4	15.3	15.2	14.11	14.10	14.9	14.8	14.7	14.5	14.4	14.3	13.14	13.13	13.12	13.11	13.10	13.9	13.8	13.7	12.15	12.14	12.13	12.12
12.9	16.2	16.1	15.6	15.5	15.4	15.3	15.2	14.11	14.10	14.9	14.8	14.7	13.14	13.13	13.12	13.11	13.10	13.9	13.8	13.7	12.17	12.16	12.15	12.14	12.13	12.12	12.11
11.21	16.2	16.1	15.6	15.5	15.4	14.11	14.10	14.9	13.14	13.13	13.12	12.17	12.16
11.9	16.2	16.1	15.6	15.5	15.4	15.3	15.2	14.11	14.10	14.9	14.8	14.7	14.6	13.14	13.13	13.12	13.11	13.10	13.9	12.17	12.16	12.15	12.14	12.13	12.12	12.11	12.09	11.21

Para qualquer versão que você esteja considerando, verifique sempre a disponibilidade da classe de instância de banco de dados do cluster. Por exemplo, o db.r4 não é compatível com o Aurora PostgreSQL 13. Se seu cluster de banco de dados do Aurora PostgreSQL atualmente usa uma classe de instância db.r4, você precisará mover para db.r5 antes de tentar realizar a atualização. Para ter mais informações sobre classes de instância de banco de dados, incluindo quais são baseadas em Graviton2 e quais são baseadas em Intel, consulte Classes de instância de banco de dados Aurora.

Como realizar uma atualização de versão principal

As atualizações da versão principal podem conter alterações de banco de dados incompatíveis com as versões anteriores do banco de dados. A nova funcionalidade em uma nova versão pode fazer com que suas aplicações existentes parem de funcionar corretamente. Para evitar problemas, o Amazon Aurora não aplica atualizações da versão principal automaticamente. Em vez disso, recomendamos planejar cuidadosamente uma atualização de versão principal seguindo estas etapas:

1. Escolha na lista de destinos disponíveis a versão principal desejada das listadas para sua versão na tabela. Você pode obter uma lista precisa de versões disponíveis em suaRegião da AWS para sua versão atual usando a AWS CLI. Para obter detalhes, consulte Obter uma lista de versões disponíveis em sua Região da AWS.

2. Verifique se suas aplicações funcionam conforme o esperado em uma implantação de avaliação da nova versão. Para obter informações sobre o processo completo, consulte Testar um upgrade de cluster de banco de dados de produção para uma nova versão principal.

3. Depois de verificar se suas aplicações funcionam conforme o esperado na implantação de avaliação, você pode atualizar seu cluster. Para obter detalhes, consulte Atualizar o mecanismo do Aurora PostgreSQL para uma nova versão principal.

nota

Você pode realizar uma atualização da versão principal de versões 13 do Babelfish para Aurora PostgreSQL a partir da 13.6 para versões 14 do Aurora PostgreSQL a partir da 14.6. As versões 13.4 e 13.5 do Babelfish para Aurora PostgreSQL não oferecem suporte a atualizações da versão principal.

Você pode obter uma lista das versões do mecanismo disponíveis como destinos de upgrade da versão principal para seu cluster de banco de dados do Aurora PostgreSQL consultando sua Região da AWS usando o comando describe-db-engine-version da AWS CLI conforme mostrado a seguir.

Para Linux, macOS ou Unix:

aws rds describe-db-engine-versions \
  --engine aurora-postgresql \
  --engine-version version-number \
  --query 'DBEngineVersions[].ValidUpgradeTarget[?IsMajorVersionUpgrade == `true`].{EngineVersion:EngineVersion}' \
  --output text

Para Windows:

aws rds describe-db-engine-versions ^
  --engine aurora-postgresql ^
  --engine-version version-number ^
  --query "DBEngineVersions[].ValidUpgradeTarget[?IsMajorVersionUpgrade == `true`].{EngineVersion:EngineVersion}" ^
  --output text

Em alguns casos, a versão para a qual você deseja atualizar não é um destino para sua versão atual. Nesses casos, use as informações na versions table para realizar atualizações de versões secundárias até que o cluster esteja em uma versão que tenha o destino escolhido em sua linha de destinos.

Testar um upgrade de cluster de banco de dados de produção para uma nova versão principal

Toda nova versão principal inclui melhorias no otimizador de consulta projetadas para aprimorar a performance. No entanto, sua workload pode incluir consultas que resultem em um plano de performance inferior na nova versão. É por isso que recomendamos que você teste e avalie a performance antes de atualizar na produção. Você pode gerenciar a estabilidade do plano de consulta entre versões usando a extensão Query Plan Management (QPM), conforme detalhado em Garantir a estabilidade do plano após a atualização da versão principal.

Antes de atualizar os clusters de banco de dados do Aurora PostgreSQL de produção para uma nova versão principal, é altamente recomendável que você teste a atualização para verificar se todas as suas aplicações funcionam corretamente:

1. Tenha um grupo de parâmetros compatível com a versão pronto para uso.

   Se você estiver usando um grupo de parâmetros de instância de banco de dados ou de cluster de banco de dados personalizado, poderá escolher entre duas opções:

   1. Especifique a instância de banco de dados padrão, o grupo de parâmetros do cluster de banco de dados, ou ambos, para a nova versão do mecanismo do banco de dados.

   2. Crie seu próprio grupo de parâmetros personalizado para a nova versão do mecanismo de banco de dados.

   Se você associar um novo grupo de parâmetros da instância de banco de dados ou do cluster de banco de dados como parte da solicitação da atualização, certifique-se de reiniciar o banco de dados após a atualização ser concluída para aplicar os parâmetros. Se uma instância de banco de dados precisar ser reinicializada para aplicar as alterações de grupo de parâmetros, o status do grupo de parâmetros da instância mostrará pending-reboot. Você pode visualizar o status do grupo de parâmetros de uma instância no console ou usando um comando da CLI, como describe-db-instances ou describe-db-clusters

2. Verifique o uso sem suporte:

   • Confirme ou reverta todas as transações preparadas abertas antes de tentar uma atualização. Você pode usar a consulta a seguir para verificar se não há transações preparadas abertas na sua instância.

     SELECT count(*) FROM pg_catalog.pg_prepared_xacts;

   • Remova todos os usos dos tipos de dados reg* antes de tentar fazer uma atualização. Exceto por regtype e regclass, você não pode atualizar os tipos de dados reg*. O utilitário pg_upgrade (usado pelo Amazon Aurora para fazer a atualização) não pode persistir esse tipo de dados. Para saber mais sobre esse utilitário, consulte pg_upgrade na documentação do PostgreSQL.

     Para verificar se não há nenhum uso de tipos de dados reg* sem suporte, use a consulta a seguir para cada banco de dados.

     SELECT count(*) FROM pg_catalog.pg_class c, pg_catalog.pg_namespace n, pg_catalog.pg_attribute a 
       WHERE c.oid = a.attrelid 
           AND NOT a.attisdropped 
           AND a.atttypid IN ('pg_catalog.regproc'::pg_catalog.regtype, 
                              'pg_catalog.regprocedure'::pg_catalog.regtype, 
                              'pg_catalog.regoper'::pg_catalog.regtype, 
                              'pg_catalog.regoperator'::pg_catalog.regtype, 
                              'pg_catalog.regconfig'::pg_catalog.regtype, 
                              'pg_catalog.regdictionary'::pg_catalog.regtype) 
           AND c.relnamespace = n.oid 
           AND n.nspname NOT IN ('pg_catalog', 'information_schema');

   • Se você estiver atualizando do Aurora PostgreSQL versão 10.18 ou posterior e tiver a extensão pgRouting instalada, remova essa extensão antes de atualizar para a versão 12.4 ou posterior.

     Se você estiver fazendo upgrade do Aurora PostgreSQL versão 10.x com a extensão pg_repack versão 1.4.3 instalada, remova essa extensão antes de fazer upgrade para qualquer versão superior.

3. Verifique os bancos de dados do modelo 1 e do modelo 0.

   Para uma atualização bem-sucedida, os bancos de dados do modelo 1 e do modelo 0 devem existir e devem ser listados como um modelo. Para conferir isso, use o seguinte comando:

   SELECT datname, datistemplate FROM pg_database; 
                           
   datname    | datistemplate
   -----------+---------------
   template0  | t
   rdsadmin   | f
   template1  | t
   postgres   | f
   

   Na saída do comando, o valor datistemplate dos bancos de dados do modelo 1 e do modelo 0 deve ser t.

4. Descarte slots de replicação lógica.

   O processo de upgrade não poderá continuar se o cluster de banco de dados do Aurora PostgreSQL estiver usando qualquer slot de replicação lógica. Os slots de replicação lógica são normalmente usados para tarefas de migração de dados de curto prazo, como a migração de dados usando o AWS DMS, ou para replicar tabelas do banco de dados para data lakes, ferramentas de BI ou outros destinos. Antes de atualizar, certifique-se de saber a finalidade de qualquer slot de replicação lógica existente e confirme se não há problema em excluí-los. Você pode verificar os slots de replicação lógica usando a seguinte consulta:

   SELECT * FROM pg_replication_slots;

   Se os slots de replicação lógica ainda estiverem sendo usados, você não deve excluí-los e não poderá continuar com a atualização. No entanto, se os slots de replicação lógica não forem necessários, você poderá excluí-los usando o seguinte SQL:

   SELECT pg_drop_replication_slot(slot_name);

   Os cenários de replicação lógica que usam a extensão pglogical também precisam ter slots retirados do nó do editor para uma atualização bem-sucedida da versão principal nesse nó. No entanto, você pode reiniciar o processo de replicação a partir do nó do assinante após a atualização. Para ter mais informações, consulte Restabelecer a replicação lógica após uma atualização principal.

5. Execute um backup.

   O processo de atualização cria um snapshot do cluster de banco de dados durante a atualização. Se você também quiser realizar um backup manual antes do processo de atualização, consulte Criar um snapshot de cluster de banco de dados para obter mais informações.

6. Atualize determinadas extensões para a versão mais recente disponível antes de executar a atualização da versão principal. As extensões a serem atualizadas incluem as seguintes:

   • pgRouting

   • postgis_raster

   • postgis_tiger_geocoder

   • postgis_topology

   • address_standardizer

   • address_standardizer_data_us

   Execute o comando a seguir para cada extensão instalada.

   ALTER EXTENSION PostgreSQL-extension UPDATE TO 'new-version';

   Para ter mais informações, consulte Atualizar extensões do PostgreSQL. Para saber mais sobre como fazer upgrade do PostGIS, consulte Etapa 6: Atualize a extensão PostGIS.

7. Se você estiver atualizando para a versão 11.x, descarte as extensões não compatíveis antes de executar a atualização da versão principal. As extensões a serem descartadas incluem:

   • chkpass

   • tsearch2

8. Descarte os tipos de dados unknown de acordo com a versão de destino.

   O PostgreSQL versão 10 não dá suporte ao tipo de dados unknown. Se um banco de dados versão 9.6 utilizar o tipo de dados unknown, uma atualização para uma versão 10 exibirá uma mensagem de erro como a seguinte:

   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."

   Para localizar o tipo de dados unknown no banco de dados a fim de remover coluna incorreta ou alterar para um tipo de dados compatível, use o código SQL a seguir para cada banco de dados.

   SELECT n.nspname, c.relname, a.attname
       FROM pg_catalog.pg_class c,
       pg_catalog.pg_namespace n,
       pg_catalog.pg_attribute a
       WHERE c.oid = a.attrelid AND NOT a.attisdropped AND
       a.atttypid = 'pg_catalog.unknown'::pg_catalog.regtype AND
       c.relkind IN ('r','m','c') AND
       c.relnamespace = n.oid AND
       n.nspname !~ '^pg_temp_' AND
       n.nspname !~ '^pg_toast_temp_' AND n.nspname NOT IN ('pg_catalog', 'information_schema');

9. Execute uma simulação de atualização.

   É altamente recomendável testar uma atualização da versão principal em uma cópia do seu banco de dados de produção antes de fazer a atualização no banco de dados de produção. Você pode monitorar os planos de execução na instância de teste duplicada para detectar possíveis regressões do plano de execução e avaliar sua performance. Para criar uma instância de teste duplicada, restaure o banco de dados a partir de um snapshot recente ou clone o banco de dados. Para ter mais informações, consulte Restauração a partir de um snapshot ou Clonar um volume para um cluster de banco de dados do Amazon Aurora.

   Para ter mais informações, consulte Atualizar o mecanismo do Aurora PostgreSQL para uma nova versão principal.

10. Atualize sua instância de produção.

    Se a simulação da atualização da versão principal for bem-sucedida, você será capaz de atualizar seu banco de dados de produção com segurança. Para ter mais informações, consulte Atualizar o mecanismo do Aurora PostgreSQL para uma nova versão principal.

    nota

    Durante o processo de upgrade, o Aurora PostgreSQL gerará um snapshot do cluster de banco de dados se o período de retenção de backup for maior que 0. Não é possível fazer uma restauração a um ponto anterior no tempo do cluster durante esse processo. Posteriormente, você pode fazer uma restauração a um ponto anterior no tempo (para momentos antes da atualização) e depois da conclusão do snapshot automático da sua instância. No entanto, não é possível fazer uma restauração a um ponto anterior no tempo para uma versão secundária anterior.

    Para obter informações sobre uma atualização em andamento, você pode usar o Amazon RDS para visualizar dois logs que são produzidos pelo utilitário pg_upgrade. Esses logs são pg_upgrade_internal.log e pg_upgrade_server.log. O Amazon Aurora acrescenta a data e a hora ao nome de arquivo desses logs. Você pode visualizar esses logs como visualiza qualquer outro log. Para ter mais informações, consulte Monitorar arquivos de log do Amazon Aurora.

11. Atualizar extensões do PostgreSQL. O processo de atualização do PostgreSQL não atualiza nenhuma extensão do PostgreSQL. Para ter mais informações, consulte Atualizar extensões do PostgreSQL.

Após a conclusão da atualização da versão principal, recomendamos o seguinte:

• Execute a operação ANALYZE para atualizar a tabela pg_statistic. Você deve fazer isso para cada banco de dados em todas as suas instâncias de banco de dados PostgreSQL. As estatísticas do otimizador não são transferidas durante uma atualização de versão principal, portanto, você precisa gerar novamente todas as estatísticas para evitar problemas de performance. Execute o comando sem nenhum parâmetro para gerar estatísticas para todas as tabelas regulares no banco de dados atual da seguinte forma:

  ANALYZE VERBOSE;

  O sinalizador VERBOSE é opcional, mas usá-lo mostra o progresso. Para obter mais informações, consulte ANALYZE na documentação do PostgreSQL.

  nota

  Execute ANALYZE em seu sistema após a atualização para evitar problemas de performance.

• Se você atualizou para o PostgreSQL versão 10, execute REINDEX em todos os índices de hash que tiver. Os índices de hash foram alterados na versão 10 e devem ser recriados. Para localizar índices de hash inválidos, execute o SQL a seguir para cada banco de dados que contém índices de hash.

  SELECT idx.indrelid::regclass AS table_name, 
     idx.indexrelid::regclass AS index_name 
  FROM pg_catalog.pg_index idx
     JOIN pg_catalog.pg_class cls ON cls.oid = idx.indexrelid 
     JOIN pg_catalog.pg_am am ON am.oid = cls.relam 
  WHERE am.amname = 'hash' 
  AND NOT idx.indisvalid;

• Recomendamos testar a aplicação no banco de dados atualizado com uma workload semelhante para verificar se tudo funciona como esperado. Verificada a atualização, é possível excluir essa instância de teste.

Atualizar o mecanismo do Aurora PostgreSQL para uma nova versão principal

Quando você inicia o processo de atualização para uma nova versão principal, o Aurora PostgreSQL tira um snapshot do cluster de banco de dados do Aurora antes de fazer qualquer alteração no cluster. Esse snapshot é criado apenas para atualizações de versão principal, não para atualizações de versão secundária. Quando o processo de atualização for concluído, você poderá encontrar esse snapshot entre os snapshots manuais listados em Snapshots no console do RDS. O nome do snapshot inclui preupgrade como prefixo, o nome do cluster de banco de dados do Aurora PostgreSQL, a versão de origem, a versão de destino e a data e o carimbo de data e hora, conforme mostrado no exemplo a seguir.

preupgrade-docs-lab-apg-global-db-12-8-to-13-6-2022-05-19-00-19

Após a conclusão da atualização, você poderá usar o snapshot que o Aurora criou e armazenou na sua lista de snapshots manuais para restaurar o cluster de banco de dados para sua versão anterior, se necessário.

dica

Em geral, os snapshots fornecem várias maneiras de restaurar seu cluster de banco de dados do Aurora para vários pontos no tempo. Para saber mais, consulte Restauração de um snapshot de um cluster de banco de dados e Restaurar um cluster de banco de dados para um horário especificado. No entanto, o Aurora PostgreSQL não oferece suporte ao uso de um snapshot para restaurar uma versão secundária anterior.

Durante o processo de atualização da versão principal, o Aurora aloca um volume e clona o cluster de banco de dados Aurora PostgreSQL de origem. Se a atualização falhar por qualquer motivo, o Aurora PostgreSQL usará o clone para reverter a atualização. Depois que mais de 15 clones de um volume de origem são alocados, os clones subsequentes se tornam cópias completas e levam mais tempo. Isso pode fazer com que o processo de atualização demore mais tempo. Se o Aurora PostgreSQL reverter a atualização, lembre-se de que:

• Você poderá ver entradas de faturamento e métricas do volume original e do volume clonado alocados durante a atualização. O Aurora PostgreSQL limpará o volume extra depois que a janela de retenção do backup do cluster for superior ao tempo da atualização.

• A próxima cópia do snapshot de região cruzada desse cluster será uma cópia completa em vez de uma cópia incremental.

Para atualizar com segurança as instâncias de banco de dados que compõem o cluster, o Aurora PostgreSQL usa o utilitário pg_upgrade. Após a conclusão da atualização do gravador, cada instância do leitor passa por uma breve interrupção durante a atualização para a nova versão principal. Para saber mais sobre esse utilitário do PostgreSQL, consulte pg_upgrade na documentação do PostgreSQL.

Você pode atualizar o cluster de banco de dados do Aurora PostgreSQL para uma nova versão usando o AWS Management Console, a AWS CLI ou a API do RDS.

Console

Como atualizar a versão do mecanismo de um cluster de banco de dados

1. Faça login no AWS Management Console e abra o console do Amazon RDS em https://console.aws.amazon.com/rds/.

2. No painel de navegação, escolha Databases (Bancos de dados) e o cluster de banco de dados que você deseja atualizar.

3. Selecione Modify. A página Modify DB cluster (Modificar cluster de banco de dados) é exibida.

4. Em Engine version (Versão do mecanismo), escolha a nova versão.

5. Escolha Continue (Continuar) e verifique o resumo de modificações.

6. Para aplicar as alterações imediatamente, escolha Apply immediately. Escolher essa opção pode causar uma interrupção em alguns casos. Para ter mais informações, consulte Modificar um cluster de bancos de dados Amazon Aurora.

7. Na página de confirmação, revise suas alterações. Se estiverem corretas, escolha Modify cluster (Modificar cluster) para salvar suas alterações.

   Ou selecione Back (Voltar) para editar as alterações ou Cancel (Cancelar) para cancelar as alterações.

AWS CLI

Para atualizar a versão de mecanismo de um cluster de banco de dados, use o comando modify-db-cluster da AWS CLI. Especifique os seguintes parâmetros:

• --db-cluster-identifier: o nome do cluster de banco de dados.

• --engine-version: o número da versão do mecanismo de banco de dados para a qual será feita a atualização. Para obter informações sobre versões de mecanismo válidas, use o comando AWS CLI describe-db-engine-versions.

• --allow-major-version-upgrade: um sinalizador obrigatório quando o parâmetro --engine-version for uma versão principal diferente da versão principal atual do cluster de banco de dados.

• --no-apply-immediately: aplica as alterações durante a próxima janela de manutenção. Para aplicar as alterações imediatamente, use --apply-immediately.

exemplo

Para Linux, macOS ou Unix:

aws rds modify-db-cluster \
    --db-cluster-identifier mydbcluster \
    --engine-version new_version \
    --allow-major-version-upgrade \
    --no-apply-immediately

Para Windows:

aws rds modify-db-cluster ^
    --db-cluster-identifier mydbcluster ^
    --engine-version new_version ^
    --allow-major-version-upgrade ^
    --no-apply-immediately

API do RDS

Para atualizar a versão do mecanismo de um cluster de banco de dados, use a operação ModifyDBCluster. Especifique os seguintes parâmetros:

• DBClusterIdentifier: o nome do cluster de banco de dados. Por exemplo mydbcluster.

• EngineVersion: o número da versão do mecanismo de banco de dados para a qual será feita a atualização. Para obter informações sobre versões de mecanismo válidas, use a operação DescribeDBEngineVersions.

• AllowMajorVersionUpgrade: um sinalizador obrigatório quando o parâmetro EngineVersion for uma versão principal diferente da versão principal atual do cluster de banco de dados.

• ApplyImmediately: se deseja ou não aplicar as alterações imediatamente ou durante a próxima janela de manutenção. Para aplicar as alterações imediatamente, defina o valor como true. Para aplicar alterações durante a próxima janela de manutenção, defina o valor como false.

Atualizações principais de bancos de dados globais

Para um cluster de banco de dados global do Aurora, o processo de atualização atualiza simultaneamente todos os clusters de banco de dados que compõem seu banco de dados global do Aurora. Ele faz isso para garantir que cada um execute a mesma versão do Aurora PostgreSQL. Isso também garante que todas as alterações nas tabelas do sistema, em formatos de arquivo de dados, etc. sejam replicadas automaticamente para todos os clusters secundários.

Para atualizar um cluster de banco de dados global para uma nova versão principal do Aurora PostgreSQL, recomendamos que você teste suas aplicações na versão atualizada, conforme detalhado em Testar um upgrade de cluster de banco de dados de produção para uma nova versão principal. Prepare as configurações do grupo de parâmetros de cluster de banco de dados e do grupo de parâmetros de banco de dados para cada Região da AWS em seu banco de dados global do Aurora antes da atualização, conforme detalhado em step 1. do Testar um upgrade de cluster de banco de dados de produção para uma nova versão principal.

Se o cluster de banco de dados global do Aurora PostgreSQL tiver um objetivo de ponto de recuperação (RPO) definido para o parâmetro rds.global_db_rpo, redefina o parâmetro antes de atualizar. O processo de atualização da versão principal não funcionará se o RPO estiver ativado. Por padrão, esse parâmetro permanece desativado. Para ter mais informações sobre bancos de dados globais e RPO do Aurora PostgreSQL, consulte Gerenciamento de RPOs para bancos de dados globais baseados em Aurora PostgreSQL–.

Se você confirmar que suas aplicações podem ser executadas conforme o esperado na implantação de avaliação da nova versão, poderá iniciar o processo de atualização. Para fazer isto, consulte Atualizar o mecanismo do Aurora PostgreSQL para uma nova versão principal. Escolha o item de nível superior na lista Databases (Bancos de dados) no console do RDS, Global database (Banco de dados global), conforme mostrado na imagem a seguir.

Como em qualquer modificação, você pode confirmar que deseja que o processo prossiga quando solicitado.

Em vez de usar o console, você pode iniciar o processo de atualização usando a AWS CLI ou a API do RDS. Assim como no console, você trabalha no cluster de banco de dados global do Aurora, não em seus componentes, da seguinte forma:

• Use o comando modify-global-cluster AWS CLI para iniciar a atualização de seu banco de dados global do Aurora usando a AWS CLI.

• Use a API ModificyGlobalCluster para iniciar a atualização.

Antes de realizar um upgrade da versão secundária

Recomendamos que você execute as seguintes ações para reduzir o tempo de inatividade durante um upgrade de versão secundária:

• A manutenção do cluster de banco de dados do Aurora deve ser realizada durante um período de baixo tráfego. Use o Insights de Performance para identificar esses períodos a fim de configurar as janelas de manutenção corretamente. Consulte mais informações sobre o Insights de Performance em Monitoring DB load with Performance Insights on Amazon RDS. Consulte mais informações sobre a janela de manutenção do cluster de banco de dados em Ajustar a janela de manutenção do cluster de banco de dados preferencial.

• Use SDKs da AWS compatíveis com oscilações e recuos exponenciais como uma prática recomendada. Consulte mais informações em Exponential Backoff And Jitter.

Como realizar atualizações de versão secundária e aplicar patches

Patches e atualizações de versões secundárias ficam disponíveis em Regiões da AWS somente após testes rigorosos. Antes de lançar atualizações e patches, o Aurora PostgreSQL testa para garantir que problemas de segurança conhecidos, bugs e outros problemas que surgem após o lançamento da versão secundária da comunidade não interrompam a estabilidade geral da frota do Aurora PostgreSQL.

À medida que o Aurora PostgreSQL disponibiliza novas versões secundárias, as instâncias que compõem o cluster de banco de dados do Aurora PostgreSQL podem ser atualizadas automaticamente durante a janela de manutenção especificada. Para que isso aconteça, o cluster de banco de dados do Aurora PostgreSQL deve ter a opção Enable auto minor version upgrade (Ativar atualização automática da versão secundária) ativada. Todas as instâncias de banco de dados que compõem o cluster de banco de dados do Aurora PostgreSQL devem ter a opção de atualização automática de versão secundária (AmVU) ativada para que a atualização secundária seja aplicada em todo o cluster.

dica

Verifique se a opção Enable auto minor version upgrade (Ativar atualização automática da versão secundária) está ativada para todas as instâncias de banco de dados do PostgreSQL que compõem seu cluster de banco de dados do Aurora PostgreSQL. Essa opção deve estar ativada para que todas as instâncias no cluster de banco de dados funcionem. Para obter informações sobre como definir a configuração Upgrade automático de versões secundárias e como ela funciona quando aplicada nos níveis de cluster e instância, consulte  Atualizações da versão secundária automáticas para clusters de banco de dados do Aurora.

Você pode conferir o valor da opção Enable auto minor version upgrade (Ativar atualização automática da versão secundária) para todos os clusters de banco de dados do Aurora PostgreSQL usando o comando describe-db-instances da AWS CLI com a consulta a seguir.

aws rds describe-db-instances \
  --query '*[].{DBClusterIdentifier:DBClusterIdentifier,DBInstanceIdentifier:DBInstanceIdentifier,AutoMinorVersionUpgrade:AutoMinorVersionUpgrade}'

Essa consulta retorna uma lista de todos os clusters de banco de dados do Aurora e de suas instâncias com um valor true ou false para o status da configuração AutoMinorVersionUpgrade. O comando conforme mostrado pressupõe que você tenha a AWS CLIconfigurada para almejar sua Região da AWS padrão.

Para obter mais informações sobre a opção AmVU e como modificar o cluster de banco de dados do Aurora para usá-la, consulte Atualizações da versão secundária automáticas para clusters de banco de dados do Aurora.

Você pode atualizar seus clusters de banco de dados do Aurora PostgreSQL para novas versões secundárias respondendo a tarefas de manutenção ou modificando o cluster para usar a nova versão.

Você pode identificar todas as atualizações ou patches disponíveis para seus clusters de banco de dados do Aurora PostgreSQL usando o console do RDS e abrindo o menu Recommendations (Recomendações). Nesse menu, é possível encontrar uma lista de vários problemas de manutenção, como Old minor versions (Versões secundárias antigas). Dependendo do ambiente de produção, você pode optar por programar (Schedule) a atualização ou tomar medidas imediatas, escolhendo Apply now (Aplicar agora), conforme mostrado a seguir.

Para saber mais sobre como manter um cluster de banco de dados do Aurora, inclusive como aplicar manualmente patches e atualizações de versões secundárias, consulte Manutenção de um cluster de banco de dados do Amazon Aurora.

Atualizações de versões secundárias e patches com tempo de inatividade zero

A atualização de um cluster de banco de dados do Aurora PostgreSQL envolve a possibilidade de uma interrupção. Durante o processo de atualização, o banco de dados é desligado à medida que está sendo atualizado. Se você iniciar a atualização enquanto o banco de dados estiver ocupado, perderá todas as conexões e transações que o cluster de banco de dados está processando. Se você esperar até que o banco de dados fique ocioso para realizar a atualização, talvez seja necessário esperar muito tempo.

O recurso ZDP (zero-time patch) melhora o processo de atualização. Com o ZDP, atualizações de versões menores e patches podem ser aplicados com impacto mínimo no cluster de banco de dados do Aurora PostgreSQL. O ZDP é usado ao aplicar patches ou atualizações de versões secundárias mais recentes para o Aurora PostgreSQL e outras versões posteriores dessas versões secundárias e principais mais recentes. Ou seja, a atualização para novas versões secundárias de qualquer uma dessas versões em diante usa o ZDP.

A tabela a seguir mostra as versões do Aurora PostgreSQL e as classes de instâncias de banco de dados em que o ZDP está disponível:

Version (Versão)	Classes de instância db.r*	Classes de instância db.t*	Classes de instância db.x*	Classe de instância db.serverless
10.21.0 e versões 10.21 posteriores	Sim	Sim	Sim	N/D
11.16.0 e versões 11.16 posteriores	Sim	Sim	Sim	N/D
11.17 e versões posteriores	Sim	Sim	Sim	N/D
12.11.0 e versões 12.11 posteriores	Sim	Sim	Sim	N/D
12.12 e versões posteriores	Sim	Sim	Sim	N/D
13.7.0 e versões 13.7 posteriores	Sim	Sim	Sim	N/D
13.08 e versões posteriores	Sim	Sim	Sim	Sim
14.3.1 e versões 14.3 posteriores	Sim	Sim	Sim	N/D
14.4.0 e versões 14.4 posteriores	Sim	Sim	Sim	N/D
14.5 e versões posteriores	Sim	Sim	Sim	Sim
15.3 e versões posteriores	Sim	Sim	Sim	Sim

O ZDP funciona preservando as conexões atuais do cliente com seu cluster de banco de dados Aurora PostgreSQL durante todo o processo de atualização do Aurora PostgreSQL. No entanto, nos seguintes casos, as conexões serão interrompidas para que o ZDP seja concluído:

• Consultas ou transações de longa execução estão em andamento.

• As instruções Data Definition Language (DDL) estão em execução.

• As tabelas temporárias ou bloqueios de tabela estão em uso.

• Todas as sessões estão sendo ouvidas nos canais de notificação.

• Um cursor no status “'WITH HOLD” está em uso.

• As conexões TLSv1.3 ou TLSv1.1 estão em uso.

Durante o processo de upgrade usando o recurso ZDP, o mecanismo de banco de dados procura um ponto tranquilo para pausar todas as novas transações. Essa ação protege o banco de dados durante patches e upgrades. Para garantir que suas aplicações funcionem sem problemas com transações pausadas, recomendamos integrar a lógica de novas tentativas em seu código. Essa abordagem garante que o sistema consiga gerenciar qualquer breve tempo de inatividade sem falhas e possa tentar realizar novamente as novas transações depois do upgrade.

Quando o recurso ZDP é concluído com êxito, as sessões da aplicação são preservadas, exceto aquelas com conexões descartadas, e o mecanismo de banco de dados é reiniciado enquanto o upgrade ainda está em andamento. Embora a reinicialização do mecanismo de banco de dados possa causar uma queda temporária no throughput, em geral, ela dura apenas alguns segundos ou, no máximo, cerca de um minuto.

Em alguns casos, a aplicação de patch de tempo de inatividade zero (ZDP) pode não ter êxito. Por exemplo, as alterações de parâmetros no estado pending no cluster de banco de dados do Aurora PostgreSQL ou em suas instâncias interferem no ZDP.

Você pode encontrar métricas e eventos para operações do ZDP na página Events (Eventos) no console. Os eventos incluem o início da atualização do ZDP e a conclusão da atualização. Nesse caso, é possível descobrir quanto tempo o processo demorou e o número de conexões preservadas e descartadas que ocorreram durante a reinicialização. É possível localizar detalhes no log de erros do banco de dados.

Atualizar o mecanismo do Aurora PostgreSQL para uma nova versão secundária

Você pode atualizar o cluster de banco de dados do Aurora PostgreSQL para uma nova versão secundária usando o console, a AWS CLI ou a API do RDS. Antes de realizar o upgrade, recomendamos seguir as mesmas práticas recomendadas para atualizações de versão principais. Assim como nas novas versões principais, as novas versões secundárias também podem ter melhorias no otimizador, como correções, que podem causar regressões no plano de consulta. Para garantir a estabilidade do plano, recomendamos usar a extensão Query Plan Management (QPM) conforme detalhado em Garantir a estabilidade do plano após a atualização da versão principal.

Console

Como atualizar o mecanismo de seu cluster de banco de dados do Aurora PostgreSQL

1. Faça login no AWS Management Console e abra o console do Amazon RDS em https://console.aws.amazon.com/rds/.

2. No painel de navegação, escolha Databases (Bancos de dados) e o cluster de banco de dados que você deseja atualizar.

3. Selecione Modify. A página Modify DB cluster (Modificar cluster de banco de dados) é exibida.

4. Em Engine version (Versão do mecanismo), escolha a nova versão.

5. Escolha Continue (Continuar) e verifique o resumo de modificações.

6. Para aplicar as alterações imediatamente, escolha Apply immediately. Escolher essa opção pode causar uma interrupção em alguns casos. Para ter mais informações, consulte Modificar um cluster de bancos de dados Amazon Aurora.

7. Na página de confirmação, revise suas alterações. Se estiverem corretas, escolha Modify cluster (Modificar cluster) para salvar suas alterações.

   Ou selecione Back (Voltar) para editar as alterações ou Cancel (Cancelar) para cancelar as alterações.

AWS CLI

Para atualizar a versão do mecanismo de um cluster de banco de dados, use o comando modify-db-cluster da AWS CLI com os seguintes parâmetros:

• --db-cluster-identifier: o nome de seu cluster de banco de dados do Aurora PostgreSQL.

• --engine-version: o número da versão do mecanismo de banco de dados para a qual será feita a atualização. Para obter informações sobre versões de mecanismo válidas, use o comando AWS CLI describe-db-engine-versions.

• --no-apply-immediately: aplica as alterações durante a próxima janela de manutenção. Para aplicar as alterações imediatamente, use --apply-immediately.

Para Linux, macOS ou Unix:

aws rds modify-db-cluster \
    --db-cluster-identifier mydbcluster \
    --engine-version new_version \
    --no-apply-immediately

Para Windows:

aws rds modify-db-cluster ^
    --db-cluster-identifier mydbcluster ^
    --engine-version new_version ^
    --no-apply-immediately

API do RDS

Para atualizar a versão do mecanismo de um cluster de banco de dados, use a operação ModifyDBCluster. Especifique os seguintes parâmetros:

• DBClusterIdentifier: o nome do cluster de banco de dados. Por exemplo mydbcluster.

• EngineVersion: o número da versão do mecanismo de banco de dados para a qual será feita a atualização. Para obter informações sobre versões de mecanismo válidas, use a operação DescribeDBEngineVersions.

• ApplyImmediately: se deseja ou não aplicar as alterações imediatamente ou durante a próxima janela de manutenção. Para aplicar as alterações imediatamente, defina o valor como true. Para aplicar alterações durante a próxima janela de manutenção, defina o valor como false.

Atualizar extensões do PostgreSQL

A atualização do cluster de banco de dados do Aurora PostgreSQL para uma nova versão principal ou secundária não atualiza as extensões do PostgreSQL simultaneamente. Para a maioria das extensões, você atualiza a extensão após a conclusão da atualização da versão principal ou secundária. No entanto, em alguns casos, você atualiza a extensão antes de atualizar o mecanismo de banco de dados do Aurora PostgreSQL. Para ter mais informações, consulte list of extensions to update em Testar um upgrade de cluster de banco de dados de produção para uma nova versão principal.

A instalação das extensões do PostgreSQL exigem privilégios de rds_superuser. Normalmente, um rds_superuser delega permissões por extensões específicas para usuários relevantes (perfis), para facilitar o gerenciamento de uma determinada extensão. Isso significa que a tarefa de atualizar todas as extensões do cluster de banco de dados do Aurora PostgreSQL pode envolver muitos usuários (perfis) diferentes. Tenha isso em mente principalmente se você quiser automatizar o processo de atualização usando scripts. Para ter mais informações sobre privilégios e funções do PostgreSQL, consulte Segurança com o Amazon Aurora PostgreSQL.

nota

Para obter informações sobre como atualizar a extensão PostGIS, consulte Gerenciar dados espaciais com a extensão PostGIS (Etapa 6: Atualize a extensão PostGIS).

Para atualizar a extensão pg_repack, solte a extensão e crie a nova versão na instância de banco de dados atualizada. Para obter mais informações, consulte a instalação do pg_repack na documentação do pg_repack.

Para atualizar uma extensão após uma atualização de mecanismo, use o comando ALTER EXTENSION UPDATE.

ALTER EXTENSION extension_name UPDATE TO 'new_version';

Para listar as extensões instaladas no momento, use o catálogo pg_extension do PostgreSQL no comando a seguir.

SELECT * FROM pg_extension;

Para visualizar uma lista das versões de extensão específicas disponíveis para a instalação, use a visualização pg_available_extension_versions do PostgreSQL no comando a seguir.

SELECT * FROM pg_available_extension_versions;

Técnica alternativa de atualização azul-verde

Em algumas situações, a prioridade é executar um switchover imediato do cluster antigo para um atualizado. Nessas situações, você pode seguir um processo de várias etapas que executa clusters antigos e novos lado a lado. Nesse caso, você replica dados do cluster antigo para o novo até que esteja pronto para que o novo cluster assuma o controle. Para obter detalhes, consulte Usar implantações azul/verde do Amazon RDS para atualizações de banco de dados.