Atualizar um Amazon Aurora Global Database - Amazon Aurora

Atualizar um Amazon Aurora Global Database

A atualização de um Aurora Global Database segue os mesmos procedimentos que a atualização de clusters de banco de dados Aurora. No entanto, veja a seguir algumas diferenças importantes a serem observadas antes de iniciar o processo.

Recomendamos que você atualize os clusters de banco de dados primário e secundário para a mesma versão. Você só poderá realizar um failover gerenciado de banco de dados entre regiões em um banco de dados global do Aurora se os clusters de banco de dados primário e secundário tiverem as mesmas versões principal, secundária e nível de patch do mecanismo. No entanto, os níveis de patch podem ser diferentes, dependendo da versão secundária do mecanismo. Para ter mais informações, consulte Compatibilidade em nível de patch para transições e failovers gerenciados entre regiões.

Atualizações de versão principal

Quando você executa uma atualização de versão principal de um banco de dados Amazon Aurora global, você atualiza o cluster de banco de dados global em vez dos clusters individuais que ele contém.

Para saber como atualizar um banco de dados Aurora PostgreSQL global para uma versão principal superior, consulte Atualizações principais de bancos de dados globais.

nota

Com um banco de dados global Aurora baseado no Aurora PostgreSQL, você não poderá executar uma atualização de versão principal do mecanismo de banco de dados Aurora se o recurso do objetivo de ponto de recuperação (RPO) estiver ativado. Para ter mais informações sobre o recurso RPO, consulte Gerenciamento de RPOs para bancos de dados globais baseados em Aurora PostgreSQL–.

Para saber como atualizar um banco de dados Aurora MySQL global para uma versão principal superior, consulte Principais atualizações no local para bancos de dados globais.

nota

Com um banco de dados Aurora global baseado no Aurora MySQL, você não poderá executar uma atualização no local do Aurora MySQL versão 2 para a versão 3 se o parâmetro lower_case_table_names estiver ativado.

Para realizar uma atualização de versão principal para o Aurora MySQL versão 3 enquanto usa lower_case_table_names, use o seguinte processo:

  1. Remova todas as regiões secundárias do cluster global. Siga as etapas em Remover um cluster de um banco de dados global do Amazon Aurora.

  2. Atualize a versão do mecanismo da região primária para o Aurora MySQL versão 3. Siga as etapas em Como realizar uma atualização local.

  3. Adicione regiões secundárias ao cluster global. Siga as etapas em Adicionar uma Região da AWS a um Amazon Aurora Global Database.

Você também pode usar o método de restauração de snapshot. Para ter mais informações, consulte Restauração de um snapshot de um cluster de banco de dados.

Atualizações de versões secundárias

Em uma atualização secundária em um Aurora Global Database, você atualiza todos os clusters secundários antes de atualizar o cluster principal.

Para saber como atualizar um banco de dados Aurora PostgreSQL global para uma versão secundária superior, consulte Como realizar atualizações de versão secundária e aplicar patches. Para saber como atualizar um banco de dados Aurora MySQL global para uma versão secundária superior, consulte Atualizar o Aurora MySQL modificando a versão do mecanismo.

Antes de realizar a atualização, revise as seguintes considerações:

  • O upgrade da versão secundária de um cluster secundário não afeta de forma alguma a disponibilidade ou o uso do cluster primário.

  • Um cluster secundário deve ter pelo menos uma instância de banco de dados para executar uma atualização secundária.

  • Se você atualizar um banco de dados global do Aurora MySQL para uma versão 2.11.*, deverá atualizar os clusters de banco de dados primário e secundário para exatamente a mesma versão, inclusive o nível de patch.

  • Para comportar transições e failovers gerenciados entre regiões, você deve atualizar os clusters de banco de dados primário e secundário para exatamente a mesma versão, incluindo o nível do patch, dependendo da versão do mecanismo. Para ter mais informações, consulte Compatibilidade em nível de patch para transições e failovers gerenciados entre regiões.

Compatibilidade em nível de patch para transições e failovers gerenciados entre regiões

Ao atualizar o banco de dados global do Aurora para uma das versões secundárias do mecanismo, você pode realizar transições ou failovers gerenciados entre regiões mesmo se os níveis de patch dos clusters de banco de dados primário e secundário forem diferentes. Para versões secundárias do mecanismo anteriores às desta lista, você deve atualizar os clusters de banco de dados primário e secundário para os mesmos níveis principal, secundário e de patch a fim de realizar transições ou failovers gerenciados entre regiões. Revise as informações da versão e as notas na tabela a seguir.

nota

Para failovers manuais entre regiões, você pode realizar o processo de failover desde que o cluster de banco de dados secundário de destino esteja executando a mesma versão de mecanismo principal e secundária do cluster de banco de dados primário. Nesse caso, os níveis de patch não precisam ser iguais.

Mecanismo do banco de dados Versões secundárias do mecanismo Observações

Aurora MySQL

Sem versões secundárias

Com todas as versões secundárias, só será possível realizar transições ou failovers gerenciados entre regiões se os níveis de patch dos clusters de banco de dados primário e secundário forem os mesmos.

Aurora PostgreSQL

  • Versão 14.5 ou versões secundárias superiores

  • Versão 13.8 ou versões secundárias superiores

  • Versão 12.12 ou versões secundárias superiores

  • Versão 11.17 ou versões secundárias superiores

Com as versões secundárias do mecanismo listadas na coluna anterior, você pode realizar transições ou failovers gerenciados entre regiões de um cluster de banco de dados primário com um nível de patch para um cluster de banco de dados secundário com um nível de patch diferente.

Com todas as versões secundárias anteriores a essas, só será possível realizar transições ou failovers gerenciados entre regiões se os níveis de patch dos clusters de banco de dados primário e secundário forem os mesmos.