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 3.04.1, o 3 representa a versão principal. 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.
Sumário
Como funciona a atualização da versão principal no local Aurora MySQL
Planejando uma atualização de versão principal para um cluster de Aurora MySQL
Verificações prévias de atualização da versão principal do Aurora MySQL
Descobrir os motivos das falhas de atualização da versão principal do Aurora MySQL
Solução de problemas para atualização no local de Aurora MySQL
Atualizar o Aurora MySQL versão 2 para a versão 3
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 ter mais informações, consulte Como funciona a atualização da versão principal no local Aurora MySQL.
O método de 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 do cluster, é possível escolher entre as técnicas de atualização:
-
nota
Se você usar a AWS CLI ou a API do RDS para o método de atualização de restauração de snapshot, deverá executar uma operação subsequente para criar uma instância de banco de dados do gravador no cluster de banco de dados restaurado.
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 Planejando uma atualização de versão principal para um cluster de Aurora MySQL e Como realizar uma atualização local.
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, versão 2 |
Sim |
A atualização no local é compatível com clusters do Aurora MySQL compatíveis com o MySQL 5.7. Para obter informações sobre o upgrade para o Aurora MySQL versão 3, consulte Planejando uma atualização de versão principal para um cluster de Aurora MySQL e Como realizar uma atualização local. |
|
Cluster provisionado do Aurora MySQL, versão 3 |
Não aplicável |
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 |
Não aplicável |
O Aurora Serverless v1 só é compatível com o Aurora MySQL na versão 2. |
|
Aurora Serverless v2Cluster do |
Não aplicável |
O Aurora Serverless v2 só é compatível com o Aurora MySQL na versão 3. |
|
Cluster em um banco de dados Aurora global |
Sim |
Para fazer upgrade do Aurora MySQL versão 2 para a versão 3, siga o procedimento para fazer um upgrade no local para clusters em um banco de dados Aurora global. Execute o upgrade no cluster 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 Será possível realizar um upgrade no local do Aurora MySQL versão 2 para a versão 3 somente se o parâmetro |
|
Cluster de consulta paralela |
Sim |
Você pode executar um upgrade no local. |
|
Cluster que é o destino da replicação de log binário |
Talvez |
Se a replicação de log binário for de um cluster do Aurora MySQL, você poderá executar um upgrade no local. Você não poderá executar o upgrade se a replicação de log binário for de uma instância de banco de dados do RDS para MySQL ou de uma instância de banco de dados MySQL on-premises. 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 |
É possível executar uma atualização no local para um cluster do 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 ter 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:
-
O Aurora realiza uma série de verificações prévias 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.
-
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.
-
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 (se necessário) 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.
-
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.
-
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.
-
-
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.
-
-
Aurora atualiza a versão do mecanismo nas instâncias de banco de dados do leitor.
-
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.
Planejando uma atualização de versão principal para um cluster de Aurora MySQL
Para ajudar você a decidir o momento certo e a abordagem apropriada para atualização, conheça as diferenças entre o Aurora MySQL versão 3 e o ambiente atual:
-
Se estiver convertendo do RDS para o MySQL 8.0 ou do MySQL 8.0 Community Edition, consulte Comparar o Aurora MySQL versão 3 e o MySQL 8.0 Community Edition.
-
Se estiver realizando a atualização do Aurora MySQL versão 2, do RDS para MySQL 5.7 ou do MySQL Community Edition 5.7, consulte Comparar o Aurora MySQL versão 2 e o Aurora MySQL versão 3.
-
Crie novas versões compatíveis com o MySQL 8.0 de qualquer grupo de parâmetros personalizado. Aplique todos os valores de parâmetros personalizados necessários aos novos grupos de parâmetros. Consulte Alterações de parâmetros do Aurora MySQL versão 3 para saber mais sobre as alterações nos parâmetros.
-
Analise o esquema de banco de dados e as definições de objetos do Aurora MySQL versão 2 para saber sobre o uso das novas palavras-chave reservadas introduzidas no MySQL 8.0 Community Edition. Faça isso antes de fazer a atualização. Para obter mais informações, consulte Novas palavras-chave e palavras reservadas no MySQL 8.0
na documentação do MySQL.
Você também pode encontrar mais dicas e considerações de upgrade específicas do MySQL em Alterações no MySQL 8.0mysqlcheck --check-upgrade para analisar seus bancos de dados existentes do Aurora MySQL e identificar possíveis problemas de upgrade.
nota
Recomendamos o uso de classes maiores de instâncias de banco de dados ao atualizar para o Aurora MySQL versão 3 utilizando a atualização no local ou a técnica de restauração de snapshot. Os exemplos são db.r5.24xlarge e db.r6g.16xlarge. Isso ajuda o processo de atualização a ser concluído mais rapidamente usando a maior parte da capacidade de CPU disponível na instância de banco de dados. Você pode mudar para a classe da instância de banco de dados que deseja após a conclusão da atualização da versão principal.
Depois de concluir a atualização em si, você pode seguir os procedimentos pós-upgrade no Limpeza pós-upgrade do Aurora MySQL versão 3. Por fim, teste a funcionalidade e a performance da aplicação.
Se você estiver convertendo do RDS do MySQL ou MySQL Community Edition, siga o procedimento de migração explicado em Migrar dados para um cluster de banco de dados do Amazon Aurora MySQL. Em alguns casos, é possível utilizar a replicação de logs binários para sincronizar seus dados com um cluster do Aurora MySQL versão 3 como parte da migração. Nesse caso, o sistema de origem deve executar uma versão compatível com o cluster de banco de dados de destino.
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 conhecer os problemas 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.
nota
A atualização no local requer que o cluster de banco de dados fique desligado enquanto a operação é realizada. O Aurora MySQL executa um encerramento limpo e conclui as operações pendentes, como uma limpeza do tipo desfazer. Uma atualização poderá levar muito tempo se houver necessidade de limpar muitos registros de desfazer. Recomendamos realizar a atualização somente após a redução do tamanho da lista de histórico (HLL). Um valor geralmente aceitável para o HLL é 100 mil ou menos. Veja este post de blog
Simular a atualização clonando o cluster de banco de dados
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:
-
Crie um clone do cluster original. Siga o procedimento em Clonar um volume para um cluster de banco de dados do Amazon Aurora.
-
Configure um conjunto semelhante de instâncias de banco de dados de gravador e leitor como no cluster original.
-
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.
-
Teste a compatibilidade de aplicações, performance, procedimentos de administração e assim por diante usando o cluster clonado.
-
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.
-
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.
-
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.
Implantações 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 Aurora para atualizações de banco de dados.
