Realizar a atualização da versão principal de um cluster de bancos de dados do Amazon Aurora MySQL - Amazon Aurora
Fazer upgrade do Aurora MySQL 2.x para 3.xFazer upgrade do Aurora MySQL 1.x para 2.xPlanejando uma atualização de versão principal para um cluster de Aurora MySQLProcesso de atualização da versão principal de Aurora MySQLComo funciona a atualização da versão principal no local Aurora MySQLComo realizar uma atualização localComo as atualizações locais afetam os grupos de parâmetros de um clusterAlterações nas propriedades do cluster entre as versões do Aurora MySQLPrincipais atualizações no local para bancos de dados globaisApós a atualizaçãoSolução de problemas para atualização no local de Aurora MySQLTutorial de atualização no local de Aurora MySQLTécnica alternativa de atualização azul-verde

Realizar a atualização da versão principal de um cluster de bancos de dados do Amazon Aurora MySQL

Em um número de versão do Aurora MySQL, como 2.08.1, o 2 representa a versão principal. O Aurora MySQL versão 1 é compatível com o MySQL 5.6. O Aurora MySQL versão 2 é compatível com o MySQL 5.7. O Aurora MySQL versão 3 é compatível com o MySQL 8.0.

A atualização entre versões principais requer planejamento e teste mais extensos do que para uma versão secundária. O processo pode levar um tempo relevante. Após a conclusão da atualização, também pode ser necessário fazer um trabalho de acompanhamento. Por exemplo, isso pode ocorrer devido a diferenças na compatibilidade de SQL ou da forma que determinados recursos relacionados ao MySQL funcionam. Ou isso pode ocorrer devido às diferentes configurações de parâmetros entre as versões antiga e nova.

Fazer upgrade do Aurora MySQL 2.x para 3.x

Se você tiver um cluster compatível com o MySQL 5.7 e quiser atualizá-lo para um cluster compatível com o MySQL 8.0, você poderá realizar um processo de atualização no próprio cluster. Esse tipo de atualização é uma atualização in-loco, em comparação com as atualizações que você faz criando um novo cluster. Esta técnica mantém o mesmo endpoint e outras características do cluster. A atualização é relativamente rápida porque não requer a cópia de todos os seus dados para um novo volume de cluster. Essa estabilidade ajuda a minimizar quaisquer alterações de configuração em seus aplicativos. Ele também ajuda a reduzir a quantidade de testes para o cluster atualizado. Isso ocorre porque o número de instâncias de banco de dados e suas classes de instância permanecem iguais.

O mecanismo de atualização no local envolve encerrar o cluster de banco de dados enquanto a operação é realizada. O Aurora executa um desligamento limpo e conclui as operações pendentes, como reverter transação e desfazer limpeza. Para obter mais informações, consulte Como funciona a atualização da versão principal no local Aurora MySQL.

A atualização no local é conveniente, porque é simples de executar e minimiza as alterações de configuração para aplicações associadas. Por exemplo, uma atualização no local preserva os endpoints e o conjunto de instâncias de banco de dados para o cluster. No entanto, o tempo necessário para uma atualização local pode variar dependendo das propriedades do esquema e a ocupação do cluster. Portanto, dependendo das necessidades de seu cluster, talvez você queira escolher entre as várias técnicas de atualização. Isso inclui atualização no local e restauração de snapshot, descritos em Restauração de um snapshot de um cluster de banco de dados. Eles também incluem outras técnicas de atualização, como a descrita em Técnica alternativa de atualização azul-verde.

Para obter informações gerais sobre o Aurora MySQL versão 3 e os novos recursos, consulte Aurora MySQL versão 3 compatível com o MySQL 8.0. Para obter detalhes sobre o planejamento de uma atualização, consulte Planejamento do upgrade para o Aurora MySQL versão 3 e Fazer upgrade para o Aurora MySQL versão 3.

dica

Quando você faz upgrade da versão principal do cluster de 2.x para 3.x, o cluster original e o atualizado usam o mesmo valor de aurora-mysql para o atributo engine.

Fazer upgrade do Aurora MySQL 1.x para 2.x

Atualizar a versão principal de 1.x para 2.x altera o atributo engine do cluster de aurora para aurora-mysql. Certifique-se de atualizar qualquer automação AWS CLI ou API que você usa com este cluster para contabilizar o valor engine alterado.

Se você tiver um cluster compatível com o MySQL 5.6 e quiser atualizá-lo para um cluster compatível com o MySQL 5.7, você poderá realizar um processo de atualização no próprio cluster. Esse tipo de atualização é uma atualização in-loco, em comparação com as atualizações que você faz criando um novo cluster. Esta técnica mantém o mesmo endpoint e outras características do cluster. A atualização é relativamente rápida porque não requer a cópia de todos os seus dados para um novo volume de cluster. Essa estabilidade ajuda a minimizar quaisquer alterações de configuração em seus aplicativos. Ele também ajuda a reduzir a quantidade de testes para o cluster atualizado. Isso ocorre porque o número de instâncias de banco de dados e suas classes de instância permanecem iguais.

O mecanismo de atualização no local envolve encerrar o cluster de banco de dados enquanto a operação é realizada. O Aurora executa um desligamento limpo e conclui as operações pendentes, como reverter transação e desfazer limpeza.

A atualização no local é conveniente, porque é simples de executar e minimiza as alterações de configuração para aplicações associadas. Por exemplo, uma atualização no local preserva os endpoints e o conjunto de instâncias de banco de dados para o cluster. No entanto, o tempo necessário para uma atualização local pode variar dependendo das propriedades do esquema e a ocupação do cluster. Assim, dependendo das necessidades do cluster, você pode escolher entre atualização no local, restauração de snapshot conforme descrito em Restauração de um snapshot de um cluster de banco de dados ou outras técnicas de atualização, como descrito em Técnica alternativa de atualização azul-verde.

Se o cluster estiver executando uma versão inferior a 1.22.3, a atualização poderá demorar mais tempo. O motivo disso é porque o Aurora MySQL executa automaticamente uma atualização para 1.22.3 como primeiro passo. Para minimizar o tempo de inatividade durante a atualização da versão principal, você pode fazer uma atualização de versão secundária inicial para Aurora MySQL 1.22.3 antecipadamente.

Planejando uma atualização de versão principal para um cluster de Aurora MySQL

Para garantir que suas aplicações e procedimentos administrativos funcionem sem problemas após a atualização de um cluster entre versões principais, faça um planejamento e preparação antecipados. Para visualizar os tipos de código de gerenciamento para atualizar seus scripts da AWS CLI ou aplicações com base na API do RDS, consulte Como as atualizações locais afetam os grupos de parâmetros de um cluster. Também consulte Alterações nas propriedades do cluster entre as versões do Aurora MySQL.

Para saber os tipos de problema que você pode encontrar durante a atualização, consulte Solução de problemas para atualização no local de Aurora MySQL. Para problemas que levem mais tempo para atualização, você pode testar essas condições com antecedência e corrigi-las.

Você pode conferir a compatibilidade da aplicação, a performance, procedimentos de manutenção e considerações semelhantes para o cluster atualizado. Para fazer isso, você pode realizar uma simulação da atualização antes do procedimento real. Esta técnica pode ser especialmente útil para clusters de produção. Aqui, é importante minimizar o tempo de inatividade e ter o cluster atualizado pronto para funcionar assim que a atualização for concluída.

Use as seguintes etapas:

  1. Crie um clone do cluster original. Siga o procedimento em Clonar um volume para um cluster de banco de dados do Amazon Aurora.

  2. Configure um conjunto semelhante de instâncias de banco de dados de gravador e leitor como no cluster original.

  3. Execute uma atualização no local do cluster clonado. Siga o procedimento em Como realizar uma atualização local.

    Inicie a atualização imediatamente após criar o clone. Dessa forma, o volume do cluster ainda é idêntico ao estado do cluster original. Se o clone ficar ocioso antes de fazer a atualização, Aurora executa processos de limpeza do banco de dados em segundo plano. Nesse caso, a atualização do clone não é uma simulação precisa de atualizar o cluster original.

  4. Teste a compatibilidade de aplicações, performance, procedimentos de administração e assim por diante usando o cluster clonado.

  5. Se você encontrar algum problema, ajuste seus planos de atualização para contabilizá-los. Por exemplo, adapte qualquer código de aplicação para ser compatível com o conjunto de recursos da versão posterior. Faça uma estimativa da atualização que provavelmente demorará com base na quantidade de dados no cluster. Você também pode optar por agendar a atualização para um momento em que o cluster não está ocupado.

  6. Quando suas aplicações e workloads funcionarem corretamente com o cluster de teste, você poderá realizar a atualização no local para o cluster de produção.

  7. Trabalhe para minimizar o tempo de inatividade total do cluster durante uma atualização de versão principal. Para fazer isso, a workload no cluster deve ser baixa ou zero no momento da atualização. Em particular, certifique-se de que não há transações de longa duração em andamento quando iniciar a atualização.

Para obter informações sobre a atualização para o Aurora MySQL versão 3, consulte Planejamento do upgrade para o Aurora MySQL versão 3.

Processo de atualização da versão principal de Aurora MySQL

Nem todos os tipos ou versões de clusters do Aurora MySQL podem usar o mecanismo de atualização local. Você pode aprender o caminho de atualização apropriado para cada cluster de Aurora MySQL com base na tabela a seguir.

Tipo de cluster de banco de dados de Aurora MySQL Pode usar a atualização no local? Ação

Cluster provisionado do Aurora MySQL, 1.22.3 ou posterior

Sim

Esse é o caminho de atualização mais rápido. O Aurora não precisa executar uma atualização intermediária antes.

Cluster do Aurora MySQL provisionado, inferior a 1.22.3

Sim

Se o cluster estiver executando uma versão inferior a Aurora MySQL 1.22.3, a atualização poderá demorar mais tempo. O motivo disso é porque o Aurora MySQL executa automaticamente uma atualização para 1.22.3 como primeiro passo. Para minimizar o tempo de inatividade durante a atualização da versão principal, você pode fazer uma atualização de versão secundária inicial para Aurora MySQL 1.22.3 antecipadamente.

Cluster provisionado do Aurora MySQL, 2.0 ou posterior

Sim

A atualização no local é compatível com clusters do Aurora MySQL compatíveis com 5.7.

Para obter informações sobre o upgrade para o Aurora MySQL versão 3, consulte Planejamento do upgrade para o Aurora MySQL versão 3 e Fazer upgrade para o Aurora MySQL versão 3.

Cluster provisionado do Aurora MySQL, 3.1.0 ou posterior

N/D

Use um procedimento de atualização de versão secundária para atualizar entre as versões 3 do Aurora MySQL.

Aurora Serverless v1Cluster do

Sim

Você pode realizar uma atualização de uma versão do Aurora Serverless v1 compatível com o MySQL 5.6 para uma compatível com o MySQL 5.7 executando uma atualização no local. Para obter mais informações, consulte Modificar um cluster de banco de dados do Aurora Serverless v1.

Aurora Serverless v2Cluster do

N/D

 Atualmente, o Aurora Serverless v2 só é compatível com o Aurora MySQL na versão 3.

Cluster em um banco de dados Aurora global

Talvez

Para atualizar o Aurora MySQL versão 1 para a versão 2, siga o procedimento para fazer uma atualização no local para clusters em um banco de dados global do Aurora. Execute a atualização no cluster primário no banco de dados global. O Aurora atualiza automaticamente todos os clusters secundários no banco de dados global ao mesmo tempo. Se você usar AWS CLI ou a API do RDS, chame o comando modify-global-cluster ou a operação ModifyGlobalCluster em vez de modify-db-cluster ou ModifyDBCluster.

Para atualizar um banco de dados global do Aurora MySQL versão 2 para a versão 3, use o método de restauração de snapshot. Para obter mais informações, consulte Restauração de um snapshot de um cluster de banco de dados.

Clusters de vários mestres

Não

Atualmente, a replicação de vários mestres não está disponível para clusters compatíveis com o Aurora MySQL 5.7. Você também não pode atualizar um cluster de vários mestres realizando uma restauração de snapshot.

Para mover seus dados de um cluster de vários mestres para um cluster compatível com Aurora MySQL 5.7 ou compatível com 8.0, use um despejo lógico. É possível produzir um despejo lógico com uma ferramenta, como o AWS Database Migration Service (AWS DMS) ou o comando mysqldump.

Cluster de consulta paralela

Sim

Se você tiver um cluster de consulta paralela existente usando uma Aurora MySQL versão mais antiga, atualize o cluster para Aurora MySQL 1.23 primeiro. Siga o procedimento em Considerações sobre atualização para consultas paralelas.

Você faz algumas alterações nos parâmetros de configuração para reabilitar a consulta paralela após esse upgrade inicial. Em seguida, você pode executar uma atualização no local. Nesse caso, escolha 2.09.1 ou superior para a Aurora MySQL versão.

Cluster que é o destino da replicação de log binário

Talvez

Se a replicação de log binário for de um cluster de Aurora MySQL compatível com 5.6, você pode executar uma atualização no local. Você não pode executar a atualização se a replicação de log binário for de um MySQL do RDS ou de uma instância de banco de dados MySQL local. Nesse caso, você pode atualizar usando o mecanismo de recuperação de snapshot.

Cluster com zero instâncias de banco de dados

Não

Com a AWS CLI ou a API do RDS, você pode criar um cluster de Aurora MySQL sem nenhuma instância de banco de dados anexa. Da mesma forma, você também pode remover todas as instâncias de banco de dados de um cluster do Aurora MySQL, deixando os dados no volume do cluster intactos. Embora um cluster tenha zero instâncias de banco de dados, você não pode executar uma atualização no local.

O mecanismo de atualização requer uma instância de gravador no cluster para realizar conversões nas tabelas do sistema, arquivos de dados e assim por diante. Nesse caso, use a AWS CLI ou a API do RDS para criar uma instância de gravador para o cluster. Em seguida, você pode executar uma atualização no local.

Cluster com retrocesso habilitado

Sim

Você pode executar uma atualização no local para um cluster de Aurora MySQL que usa o recurso de retrocesso. No entanto, após a atualização, você não pode retroceder o cluster para um momento anterior à atualização.

Como funciona a atualização da versão principal no local Aurora MySQL

Aurora MySQL executa uma atualização de versão principal como um processo de vários estágios. Você pode verificar o status atual de uma atualização. Algumas das etapas de atualização também fornecem informações sobre o progresso. Conforme cada etapa começa, Aurora MySQL registra um evento. Você pode analisar eventos conforme ocorrem na página Events (Eventos) no console do RDS. Para obter mais informações sobre como trabalhar com eventos, consulte Trabalhar com a notificação de eventos do Amazon RDS.

Importante

Uma vez que o processo começa, é executado até que a atualização seja bem-sucedida ou ocorra uma falha. Você não pode cancelar a atualização enquanto está em andamento. Se houver falha na atualização, Aurora retorna todas as alterações e seu cluster tem a mesma versão do mecanismo, metadados e outros como anteriormente.

O processo de atualização consiste em três etapas:

  1. Aurora executa uma série de verificações antes de iniciar o processo de atualização. Seu cluster continua em execução enquanto Aurora faz essas verificações. Por exemplo, o cluster não pode ter nenhuma transação XA no estado preparado ou estar processando qualquer instrução DDL (Data Definition Language, linguagem de definição de dados). Por exemplo, você pode precisar desligar aplicativos que estão enviando alguns tipos de instruções SQL. Ou você pode simplesmente esperar até que algumas instruções de longa duração sejam concluídas. Em seguida, tente a atualização novamente. Algumas verificações testam condições que não impedem a atualização, mas podem fazer a atualização demorar muito tempo.

    Se Aurora detectar que quaisquer condições necessárias não foram atendidas, altere as condições identificadas nos detalhes do evento. Siga as orientações em Solução de problemas para atualização no local de Aurora MySQL. Se Aurora detectar condições que podem causar uma atualização lenta, planeje monitorar a atualização durante um período prolongado.

  2. Aurora torna o cluster offline. Em seguida, Aurora executa um conjunto semelhante de testes como no estágio anterior, para confirmar que não surgiram novos problemas durante o processo de desligamento. Se nesse momento o Aurora detectar condições que impediriam o upgrade, o Aurora cancelará o upgrade e colocará o cluster de volta online. Neste caso, confirme quando as condições já não se aplicam e comece a atualização novamente.

  3. Aurora cria um snapshot do volume do cluster. Suponha que você descubra compatibilidade ou outros tipos de problemas após a conclusão da atualização. Ou suponha que você deseja realizar testes usando os clusters original e atualizado. Nesses casos, você pode restaurar a partir deste snapshot para criar um novo cluster com a versão original do mecanismo e os dados originais.

    dica

    Este snapshot é um snapshot manual. No entanto, Aurora pode criar e continuar com o processo de atualização, mesmo que você tenha atingido sua cota para snapshots manuais. Este snapshot permanece estável até que você o exclua. Depois de concluir todos os testes após a atualização, você pode excluir esse snapshot para minimizar as cobranças de armazenamento.

  4. Aurora clona o volume do cluster. A clonagem é uma operação rápida que não envolve copiar os dados reais da tabela. Se Aurora encontrar um problema durante a atualização, retornará para os dados originais do volume de cluster clonado e coloca o cluster novamente online. O volume clonado temporário durante a atualização não está sujeito ao limite usual do número de clones para um único volume de cluster.

  5. Aurora executa um desligamento limpo para a instância de banco de dados do gravador. Durante o desligamento limpo, os eventos de progresso são registrados a cada 15 minutos para as seguintes operações. Você pode analisar eventos conforme ocorrem na página Events (Eventos) no console do RDS.

    • Aurora limpa os registros de desfazer para versões antigas de linhas.

    • Aurora reverte quaisquer transações não confirmadas.

  6. Aurora atualiza a versão do mecanismo na instância de banco de dados do gravador:

    • Aurora instala o binário para a nova versão do mecanismo na instância de banco de dados do gravador.

    • Aurora usa a instância de banco de dados do gravador para atualizar seus dados para o formato compatível com o MySQL 5.7. Durante esse estágio, Aurora modifica as tabelas do sistema e executa outras conversões que afetam os dados no volume do cluster. Em particular, Aurora atualiza os metadados de partição nas tabelas do sistema para serem compatíveis com o formato de partição MySQL 5.7. Esse estágio pode levar muito tempo se as tabelas em seu cluster tiverem muitas partições.

      Se algum erro ocorrer durante este estágio, você pode encontrar os detalhes nos logs de erros do MySQL. Depois de iniciar esse estágio, se o processo de atualização falhar por qualquer motivo, Aurora restaura os dados originais do volume de cluster clonado.

  7. Aurora atualiza a versão do mecanismo nas instâncias de banco de dados do leitor.

  8. O processo de atualização está concluído. O Aurora registra um evento final para indicar que o processo de atualização foi concluído corretamente. Agora seu cluster de banco de dados está executando a nova versão principal.

Como realizar uma atualização local

Recomendamos revisar o material de base em Como funciona a atualização da versão principal no local Aurora MySQL.

Execute qualquer planejamento e teste de pré-atualização, conforme descrito a seguir:

Para atualizar a versão principal de um cluster de bancos de dados Aurora MySQL

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

  2. Se você usou um grupo de parâmetros personalizado com o cluster de banco de dados original, crie um grupo de parâmetros correspondente compatível com a nova versão principal. Faça todos os ajustes necessários aos parâmetros de configuração nesse novo grupo de parâmetro. Para obter mais informações, consulte Como as atualizações locais afetam os grupos de parâmetros de um cluster.

  3. No painel de navegação, escolha Databases (Bancos de dados).

  4. Na lista, escolha o cluster de banco de dados que deseja modificar.

  5. Selecione Modify.

  6. Em Version (Versão), selecione uma versão principal do Aurora MySQL. Recomendamos usar a versão secundária mais recente da versão principal.

    Atualização no local de um cluster de banco de dados do Aurora MySQL da versão 2 para a versão 3

  7. Escolha Continue.

  8. Na próxima página, especifique quando executar a atualização. Escolha During the next scheduled maintenance window (Durante a próxima janela de manutenção programada) ou Immediately (Imediatamente).

  9. (Opcional) Examine periodicamente a página Events (Eventos) no console do RDS durante a atualização. Isso ajuda você a monitorar o progresso da atualização e identificar quaisquer problemas. Se a atualização encontrar quaisquer problemas, consulte Solução de problemas para atualização no local de Aurora MySQL para as etapas a serem realizadas.

  10. Se você criou um grupo de parâmetros no início deste procedimento, associe o grupo de parâmetros personalizado ao cluster atualizado. Para obter mais informações, consulte Como as atualizações locais afetam os grupos de parâmetros de um cluster.

    nota

    A execução desta etapa exige que você reinicie o cluster novamente para aplicar o novo grupo de parâmetro.

  11. (Opcional) Depois de concluir qualquer teste pós-atualização, exclua o snapshot manual que Aurora criado no início da atualização.

Para atualizar a versão principal de um cluster de bancos de dados Aurora MySQL, use o comando da AWS CLI modify-db-cluster com os seguintes parâmetros obrigatórios:

  • --db-cluster-identifier

  • --engine aurora-mysql

  • --engine-version

  • --allow-major-version-upgrade

  • --apply-immediately ou --no-apply-immediately

Se o cluster usar quaisquer grupos de parâmetros personalizados, inclua também uma ou ambas as opções a seguir:

  • --db-cluster-parameter-group-name, se o cluster usar um grupo de parâmetros de cluster personalizado

  • --db-instance-parameter-group-name, se alguma instância no cluster usar um grupo de parâmetro de banco de dados personalizado

O exemplo a seguir atualiza o cluster de banco de dados do sample-cluster para a Aurora MySQL versão 2.10.2. A atualização acontece imediatamente, em vez de aguardar a próxima janela de manutenção.

exemplo

Para Linux, macOS ou Unix:

aws rds modify-db-cluster \
          --db-cluster-identifier sample-cluster \
          --engine aurora-mysql \
          --engine-version 5.7.mysql_aurora.2.10.2 \
          --allow-major-version-upgrade \
          --apply-immediately

Para Windows:

aws rds modify-db-cluster ^
          --db-cluster-identifier sample-cluster ^
          --engine aurora-mysql ^
          --engine-version 5.7.mysql_aurora.2.10.2 ^
          --allow-major-version-upgrade ^
          --apply-immediately

Você pode combinar outros comandos CLI com modify-db-cluster para criar um processo completo automatizado para executar e verificar atualizações. Para obter mais informações e exemplos, consulte Tutorial de atualização no local de Aurora MySQL.

nota

Se o cluster fizer parte de um banco de dados Aurora global, o procedimento de atualização local será ligeiramente diferente. Você chama a operação de comando modify-global-cluster em vez de modify-db-cluster. Para obter mais informações, consulte Principais atualizações no local para bancos de dados globais.

Para atualizar a versão principal de um cluster de banco de dados do Aurora MySQL, use a operação ModifyDBCluster da API do RDS com os seguintes parâmetros necessários:

  • DBClusterIdentifier

  • Engine

  • EngineVersion

  • AllowMajorVersionUpgrade

  • ApplyImmediately (definido como true ou false)

nota

Se o cluster fizer parte de um banco de dados Aurora global, o procedimento de atualização local será ligeiramente diferente. Você chama a operação ModifyGlobalCluster em vez de ModifyDBCluster. Para obter mais informações, consulte Principais atualizações no local para bancos de dados globais.

Como as atualizações locais afetam os grupos de parâmetros de um cluster

Grupos de parâmetros do Aurora têm diferentes conjuntos de configurações para clusters que são compatíveis com o MySQL 5.6, 5.7 ou 8.0. Quando você realiza uma atualização no local, o cluster atualizado e todas as instâncias devem usar grupos de parâmetros de instância e cluster correspondentes:

  • Seu cluster e suas instâncias podem usar os grupos de parâmetros padrão compatíveis com 5.6. Em caso afirmativo, o cluster atualizado e a instância iniciarão com os grupos de parâmetros padrão compatíveis com 5.7. Se o cluster e as instâncias usarem quaisquer grupos de parâmetros personalizados, crie grupos de parâmetros correspondentes ou compatíveis com 5.7. Além disso, especifique-os durante o processo de atualização.

  • Seu cluster e suas instâncias podem usar os grupos de parâmetros padrão compatíveis com 5.7. Em caso afirmativo, o cluster atualizado e a instância iniciarão com os grupos de parâmetros padrão compatíveis com 8.0. Se o cluster e as instâncias usarem quaisquer grupos de parâmetros personalizados, crie grupos de parâmetros correspondentes ou compatíveis com 8.0. Além disso, especifique-os durante o processo de atualização.

Importante

Se você especificar qualquer grupo de parâmetros personalizado durante o processo de atualização, será necessário reinicializar manualmente o cluster após a conclusão da atualização. Isso faz com que o cluster comece a usar suas configurações de parâmetros personalizadas.

Alterações nas propriedades do cluster entre as versões do Aurora MySQL

Para clusters compatíveis com o MySQL 5.6, o valor que você usa para o parâmetro engine em comandosAWS CLI ou operações de API do RDS é aurora. Para clusters compatíveis com MySQL 5.7 ou compatíveis com MySQL 8.0, o valor correspondente é aurora-mysql. Ao realizar a atualização do Aurora MySQL versão 1 para a versão 2 ou 3, altere todas as aplicações ou scripts utilizados para configurar ou gerenciar clusters e instâncias de bancos de dados do Aurora MySQL.

Além disso, altere seu código que manipula grupos de parâmetros para explicar o fato de que os nomes dos grupos de parâmetros padrão são diferentes para os clusters compatíveis com 5.6, 5.7 e 8.0. O nome do grupo de parâmetros padrão para clusters de Aurora MySQL versão 1 é default.aurora5.6. Os nomes dos grupos de parâmetros correspondentes para clusters do Aurora MySQL versão 2 e 3 são default.aurora-mysql5.7 e default.aurora-mysql8.0.

Por exemplo, você pode ter um código como abaixo que se aplica ao cluster antes de uma atualização.

# Add a new DB instance to a MySQL 5.6–compatible cluster.
aws rds create-db-instance --db-instance-identifier instance-2020-04-28-6889 --db-cluster-identifier cluster-2020-04-28-2690 \
  --db-instance-class db.t2.small --engine aurora --region us-east-1

# Find the Aurora MySQL v1.x versions available for minor version upgrades and patching.
aws rds describe-orderable-db-instance-options --engine aurora --region us-east-1 \
  --query 'OrderableDBInstanceOptions[].{EngineVersion:EngineVersion}' --output text

# Check the default parameter values for MySQL 5.6–compatible clusters.
aws rds describe-db-parameters --db-parameter-group-name default.aurora5.6 --region us-east-1

Depois de atualizar a versão principal do cluster, altere esse código da seguinte forma.

# Add a new DB instance to a MySQL 5.7–compatible cluster.
aws rds create-db-instance --db-instance-identifier instance-2020-04-28-3333 --db-cluster-identifier cluster-2020-04-28-2690 \
  --db-instance-class db.t2.small --engine aurora-mysql --region us-east-1

# Find the Aurora MySQL v2.x versions available for minor version upgrades and patching.
aws rds describe-orderable-db-instance-options --engine aurora-mysql --region us-east-1 \
  --query 'OrderableDBInstanceOptions[].{EngineVersion:EngineVersion}' --output text

# Check the default parameter values for MySQL 5.7–compatible clusters.
aws rds describe-db-parameters --db-parameter-group-name default.aurora-mysql5.7 --region us-east-1

Principais atualizações no local para bancos de dados globais

Para um Aurora Global Database, você atualiza o cluster de banco de dados global. O Aurora atualiza automaticamente todos os clusters ao mesmo tempo e garante que todos eles executem a mesma versão do mecanismo. Esse requisito ocorre porque todas as alterações nas tabelas do sistema, formatos de arquivo de dados e outros são replicadas automaticamente para todos os clusters secundários.

Siga as instruções em Como funciona a atualização da versão principal no local Aurora MySQL. Quando você especificar o que deve ser atualizado, escolha o cluster de banco de dados global em vez de um dos clusters que ele contém.

nota

Você não pode usar o método de atualização no local para atualizar o mecanismo de banco de dados do Aurora MySQL da versão 2 para a 3. Use o método de restauração de snapshot. Para obter mais informações, consulte Restauração de um snapshot de um cluster de banco de dados.

Se você usar o AWS Management Console, escolha o item com a função Global database (Banco de dados global).

Atualizar o cluster de banco de dados global

Se você usar a AWS CLI ou a API do RDS, inicie o processo de atualização chamando o comando modify-global-cluster ou a operação ModifyGlobalCluster. Você usa um desses em vez de modify-db-cluster ou ModifyDBCluster.

nota

Você não pode especificar um grupo de parâmetros personalizado para o cluster de banco de dados global enquanto estiver realizando uma atualização de versão principal desse banco de dados global do Aurora. Crie seus grupos de parâmetros personalizados em cada região do cluster global. Depois, aplique-os manualmente aos clusters regionais após a atualização.

Após a atualização

Se o cluster que você atualizou tiver o recurso de retrocesso ativado, você não poderá retroceder o cluster atualizado para antes da atualização.

Solução de problemas para atualização no local de Aurora MySQL

Use as dicas a seguir para ajudar a solucionar problemas com as atualizações no local do Aurora MySQL. Estas dicas não se aplicam a clusters de banco de dados do Aurora Serverless.

Motivo para a atualização no local ser cancelada ou lenta Efeito Solução para permitir que a atualização no local seja concluída dentro da janela de manutenção
Cluster tem transações XA no estado preparado Aurora cancela a atualização. Confirmar ou reverter todas as transações XA preparadas.
O cluster está processando qualquer instrução DDL (Data Definition Language) Aurora cancela a atualização. Considere esperar e executar a atualização depois que todas as instruções DDL estiverem concluídas.
Cluster tem alterações não confirmadas para muitas linhas A atualização pode levar muito tempo.

O processo de atualização reverte as alterações não confirmadas. O indicador para esta condição é o valor de TRX_ROWS_MODIFIED na tabela INFORMATION_SCHEMA.INNODB_TRX.

Considere executar a atualização somente depois que todas as grandes transações forem confirmadas ou revertidas.
Cluster tem um número elevado de registros para desfazer A atualização pode levar muito tempo.

Mesmo que as transações não confirmadas não afetem um grande número de linhas, podem envolver um grande volume de dados. Por exemplo, você pode inserir BLOBs grandes. O Aurora não detecta nem gera automaticamente um evento para esse tipo de atividade de transação. O indicador para esta condição é o comprimento da lista de histórico. O processo de atualização reverte as alterações não confirmadas.

Considere executar a atualização somente após o comprimento da lista de histórico diminuir.
O cluster está no processo de confirmação de uma grande transação de log binário A atualização pode levar muito tempo.

O processo de atualização aguarda até que as alterações de log binário sejam aplicadas. Mais transações ou instruções DDL podem começar durante esse período, retardando ainda mais o processo de atualização.

Agende o processo de atualização quando o cluster não estiver ocupado gerando alterações de replicação de log binário. O Aurora não detecta nem gera automaticamente um evento para esta condição.

Você pode usar as etapas a seguir para executar suas próprias verificações para algumas das condições na tabela anterior. Dessa forma, você pode agendar a atualização em um momento em que você sabe que o banco de dados está em um estado onde a atualização pode ser concluída com sucesso e rapidamente.

  • Você pode verificar se há transações XA abertas executando a instrução XA RECOVER. Você pode então confirmar ou reverter as transações XA antes de iniciar a atualização.

  • Você pode verificar se há instruções DDL executando uma instrução SHOW PROCESSLIST e procurando CREATE, DROP, ALTER, RENAME e TRUNCATE na saída. Permita que todas as instruções DDL terminem antes de iniciar a atualização.

  • Você pode verificar o número total de linhas não confirmadas consultando a tabela INFORMATION_SCHEMA.INNODB_TRX. A tabela contém uma linha para cada transação. A coluna TRX_ROWS_MODIFIED contém o número de linhas modificadas ou inseridas pela transação.

  • Você pode verificar o comprimento da lista de histórico do InnoDB executando a instrução SHOW ENGINE INNODB STATUS SQL e procurando o History list length na saída. Você também pode verificar o valor diretamente executando a seguinte consulta: 

    SELECT count FROM information_schema.innodb_metrics WHERE name = 'trx_rseg_history_len';

    O comprimento da lista de histórico corresponde à quantidade de informações desfeitas armazenadas pelo banco de dados para implementar o controle de simultaneidade de várias versões (MVCC).

Tutorial de atualização no local de Aurora MySQL

Os exemplos do Linux a seguir mostram como você pode executar as etapas gerais do procedimento de atualização no local usando AWS CLI.

Este primeiro exemplo cria um cluster de banco de dados de Aurora que está executando uma versão 1.x de Aurora MySQL. O cluster inclui uma instância de banco de dados de gravador e uma instância de banco de dados de leitor. O comando wait db-instance-available pausa até que a instância de banco de dados do gravador esteja disponível. Esse é o ponto em que o cluster está pronto para ser atualizado. 

$ aws rds create-db-cluster --db-cluster-identifier cluster-56-2020-11-17-3824 --engine aurora \
  --db-cluster-version 5.6.mysql_aurora.1.22.3
...
$ aws rds create-db-instance --db-instance-identifier instance-2020-11-17-7832 \
  --db-cluster-identifier cluster-56-2020-11-17-3824 --db-instance-class db.t2.medium --engine aurora
...
$ aws rds wait db-instance-available --db-instance-identifier instance-2020-11-17-7832 --region us-east-1

As versões 2.x do Aurora MySQL para as quais é possível atualizar o cluster depender da versão 1.x em que o cluster está sendo executado no momento e da região da AWS em que o cluster está localizado. O primeiro comando com --output text apenas mostra a versão de destino disponível. O segundo comando mostra a saída JSON completa da resposta. Nessa resposta, você pode ver detalhes, como o valor aurora-mysql que você usa para o parâmetro engine. Você também pode ver o fato de que atualizar para 2.07.3 representa uma atualização de versão principal. 

$ aws rds describe-db-clusters --db-cluster-identifier cluster-56-2020-11-17-9355 \
  --query '*[].{EngineVersion:EngineVersion}' --output text
5.6.mysql_aurora.1.22.3

$ aws rds describe-db-engine-versions --engine aurora --engine-version 5.6.mysql_aurora.1.22.3 \
  --query '*[].[ValidUpgradeTarget]'
[
    [
        [
            {
                "Engine": "aurora-mysql",
                "EngineVersion": "5.7.mysql_aurora.2.07.3",
                "Description": "Aurora (MySQL 5.7) 2.07.3",
                "AutoUpgrade": false,
                "IsMajorVersionUpgrade": true
            }
        ]
    ]
]

Este exemplo mostra que, se você inserir um número de versão de destino que não seja um destino de atualização válido para o cluster, o Aurora não realizará a atualização. O Aurora também não realiza uma atualização de versão principal, a menos que você inclua o parâmetro --allow-major-version-upgrade. Dessa forma, você não pode executar acidentalmente uma atualização que precise exigir testes e alterações amplas no código do aplicativo. 

$ aws rds modify-db-cluster --db-cluster-identifier cluster-56-2020-11-17-9355 \
  --engine-version 5.7.mysql_aurora.2.04.9 --region us-east-1 --apply-immediately
An error occurred (InvalidParameterCombination) when calling the ModifyDBCluster operation: Cannot find upgrade target from 5.6.mysql_aurora.1.22.3 with requested version 5.7.mysql_aurora.2.04.9.

$ aws rds modify-db-cluster --db-cluster-identifier cluster-56-2020-11-17-9355 \
  --engine-version 5.7.mysql_aurora.2.09.0 --region us-east-1 --apply-immediately
An error occurred (InvalidParameterCombination) when calling the ModifyDBCluster operation: The AllowMajorVersionUpgrade flag must be present when upgrading to a new major version.

$ aws rds modify-db-cluster --db-cluster-identifier cluster-56-2020-11-17-9355 \
  --engine-version 5.7.mysql_aurora.2.09.0 --region us-east-1 --apply-immediately --allow-major-version-upgrade
{
  "DBClusterIdentifier": "cluster-56-2020-11-17-9355",
  "Status": "available",
  "Engine": "aurora",
  "EngineVersion": "5.6.mysql_aurora.1.22.3"
}

Demora alguns momentos para que o status do cluster e das instâncias de banco de dados associadas mudem para upgrading. Os números de versão para as instâncias de cluster e banco de dados só mudam quando a atualização for concluída. Novamente, você pode usar o comando wait db-instance-available para que a instância de banco de dados do gravador aguarde até que a atualização seja concluída antes de prosseguir. 

$ aws rds describe-db-clusters --db-cluster-identifier cluster-56-2020-11-17-9355 \
  --query '*[].[Status,EngineVersion]' --output text
upgrading 5.6.mysql_aurora.1.22.3

$ aws rds describe-db-instances --db-instance-identifier instance-2020-11-17-5158 \
  --query '*[].{DBInstanceIdentifier:DBInstanceIdentifier,DBInstanceStatus:DBInstanceStatus} | [0]'
{
    "DBInstanceIdentifier": "instance-2020-11-17-5158",
    "DBInstanceStatus": "upgrading"
}

$ aws rds wait db-instance-available --db-instance-identifier instance-2020-11-17-5158

Neste ponto, o número da versão para o cluster corresponde ao que foi especificado para a atualização. 

$ aws rds describe-db-clusters --region us-east-1 --db-cluster-identifier cluster-56-2020-11-17-9355 \
  --query '*[].[EngineVersion]' --output text
5.7.mysql_aurora.2.09.0

O exemplo anterior fez uma atualização imediata especificando o parâmetro --apply-immediately. Para que a atualização aconteça em um momento conveniente quando o cluster não estiver ocupado, você pode especificar o parâmetro --no-apply-immediately. Isso faz com que a atualização inicie durante a próxima janela de manutenção para o cluster. A janela de manutenção define o período durante o qual as operações de manutenção podem ser iniciadas. Uma operação de longa duração pode não ser concluída durante a janela de manutenção. Assim, você não precisa definir uma janela de manutenção maior mesmo se esperar que a atualização possa levar muito tempo.

O exemplo a seguir atualiza um cluster que está executando inicialmente a Aurora MySQL versão 1.22.2. Na saída describe-db-engine-versions, os valores False e True representam a propriedade IsMajorVersionUpgrade. A partir da versão 1.22.2, é possível atualizar para algumas outras versões 1.*. Essas atualizações não são consideradas atualizações de versão principais e, portanto, não exigem uma atualização no local. A atualização no local só está disponível para atualizações nas versões 2.07 e 2.09 que são mostradas na lista. 

$ aws rds describe-db-clusters --region us-east-1 --db-cluster-identifier cluster-56-2020-11-17-3824 \
  --query '*[].{EngineVersion:EngineVersion}' --output text
5.6.mysql_aurora.1.22.2
$ aws rds describe-db-engine-versions --engine aurora --engine-version 5.6.mysql_aurora.1.22.2 \
  --query '*[].[ValidUpgradeTarget]|[0][0]|[*].[EngineVersion,IsMajorVersionUpgrade]' --output text
5.6.mysql_aurora.1.22.3 False
5.6.mysql_aurora.1.23.0 False
5.6.mysql_aurora.1.23.1 False
5.7.mysql_aurora.2.07.1 True
5.7.mysql_aurora.2.07.1 True
5.7.mysql_aurora.2.07.2 True
5.7.mysql_aurora.2.07.3 True
5.7.mysql_aurora.2.09.1 True

$ aws rds modify-db-cluster --db-cluster-identifier cluster-56-2020-11-17-9355 \
  --engine-version 5.7.mysql_aurora.2.09.0 --region us-east-1 --no-apply-immediately --allow-major-version-upgrade
...

Quando um cluster é criado sem uma janela de manutenção especificada, Aurora seleciona um dia aleatório da semana. Nesse caso, o comando modify-db-cluster é enviado em uma segunda-feira. Assim, mudamos a janela de manutenção para terça-feira de manhã. Todos os horários são representados no fuso horário UTC. A janela tue:10:00-tue:10:30 corresponde a 2-2h30 - hora do Pacífico. A alteração na janela de manutenção entra em vigor imediatamente. 

$ aws rds describe-db-clusters --db-cluster-identifier cluster-56-2020-11-17-9355 --region us-east-1 --query '*[].[PreferredMaintenanceWindow]'
[
    [
        "sat:08:20-sat:08:50"
    ]
]

$ aws rds modify-db-cluster --db-cluster-identifier cluster-56-2020-11-17-3824 --preferred-maintenance-window tue:10:00-tue:10:30"
$ aws rds describe-db-clusters --db-cluster-identifier cluster-56-2020-11-17-3824 --region us-east-1 --query '*[].[PreferredMaintenanceWindow]'
[
    [
        "tue:10:00-tue:10:30"
    ]
]

$ aws rds create-db-cluster --engine aurora --db-cluster-identifier cluster-56-2020-11-17-9355 \
  --region us-east-1 --master-username my_username --master-user-password my_password
{
  "DBClusterIdentifier": "cluster-56-2020-11-17-9355",
  "DBClusterArn": "arn:aws:rds:us-east-1:123456789012:cluster:cluster-56-2020-11-17-9355",
  "Engine": "aurora",
  "EngineVersion": "5.6.mysql_aurora.1.22.2",
  "Status": "creating",
  "Endpoint": "cluster-56-2020-11-17-9355.cluster-ccfbt21ixr91.us-east-1-integ.rds.amazonaws.com",
  "ReaderEndpoint": "cluster-56-2020-11-17-9355.cluster-ro-ccfbt21ixr91.us-east-1-integ.rds.amazonaws.com"
}

$ aws rds create-db-instance --db-instance-identifier instance-2020-11-17-5158 \
  --db-cluster-identifier cluster-56-2020-11-17-9355 --db-instance-class db.r5.large --region us-east-1 --engine aurora
{
  "DBInstanceIdentifier": "instance-2020-11-17-5158",
  "DBClusterIdentifier": "cluster-56-2020-11-17-9355",
  "DBInstanceClass": "db.r5.large",
  "DBInstanceStatus": "creating"
}

$ aws rds wait db-instance-available --db-instance-identifier instance-2020-11-17-5158 --region us-east-1

O exemplo a seguir mostra como obter um relatório dos eventos gerados pela atualização. O argumento --duration representa o número de minutos para recuperar as informações do evento. Este argumento é necessário porque, por padrão, describe-events só retorna eventos de última hora. 

$ aws rds describe-events --source-type db-cluster --source-identifier cluster-56-2020-11-17-3824 --duration 20160
{
    "Events": [
        {
            "SourceIdentifier": "cluster-56-2020-11-17-3824",
            "SourceType": "db-cluster",
            "Message": "DB cluster created",
            "EventCategories": [
                "creation"
            ],
            "Date": "2020-11-17T01:24:11.093000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:cluster-56-2020-11-17-3824"
        },
        {
            "SourceIdentifier": "cluster-56-2020-11-17-3824",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Performing online pre-upgrade checks.",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2020-11-18T22:57:08.450000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:cluster-56-2020-11-17-3824"
        },
        {
            "SourceIdentifier": "cluster-56-2020-11-17-3824",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Performing offline pre-upgrade checks.",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2020-11-18T22:57:59.519000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:cluster-56-2020-11-17-3824"
        },
        {
            "SourceIdentifier": "cluster-56-2020-11-17-3824",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-cluster-56-2020-11-17-3824-5-6-mysql-aurora-1-22-2-to-5-7-mysql-aurora-2-09-0-2020-11-18-22-55].",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2020-11-18T23:00:22.318000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:cluster-56-2020-11-17-3824"
        },
        {
            "SourceIdentifier": "cluster-56-2020-11-17-3824",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Cloning volume.",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2020-11-18T23:01:45.428000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:cluster-56-2020-11-17-3824"
        },
        {
            "SourceIdentifier": "cluster-56-2020-11-17-3824",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Purging undo records for old row versions. Records remaining: 164",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2020-11-18T23:02:25.141000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:cluster-56-2020-11-17-3824"
        },
        {
            "SourceIdentifier": "cluster-56-2020-11-17-3824",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Purging undo records for old row versions. Records remaining: 164",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2020-11-18T23:06:23.036000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:cluster-56-2020-11-17-3824"
        },
        {
            "SourceIdentifier": "cluster-56-2020-11-17-3824",
            "SourceType": "db-cluster",
            "Message": "Upgrade in progress: Upgrading database objects.",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2020-11-18T23:06:48.208000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:cluster-56-2020-11-17-3824"
        },
        {
            "SourceIdentifier": "cluster-56-2020-11-17-3824",
            "SourceType": "db-cluster",
            "Message": "Database cluster major version has been upgraded",
            "EventCategories": [
                "maintenance"
            ],
            "Date": "2020-11-18T23:10:28.999000+00:00",
            "SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:cluster-56-2020-11-17-3824"
        }
    ]
}

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 mais detalhes, consulte Usar implantações azul/verde do Amazon RDS para atualizações de banco de dados.