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

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
A réplica associada entre regiões do Aurora ainda não foi corrigida Aurora cancela a atualização. Atualize a réplica entre regiões do Aurora e tente novamente.
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 essa condição é o tamanho da lista de histórico (HLL). O processo de atualização reverte as alterações não confirmadas.

É possível conferir o HLL na saída do comando SHOW ENGINE INNODB STATUS SQL ou diretamente usando a seguinte consulta SQL:

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

Também é possível monitorar a métrica RollbackSegmentHistoryListLength no Amazon CloudWatch.

Pense em realizar a atualização somente quando o HLL for menor.
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.
Inconsistências em esquemas resultantes da remoção ou corrupção de arquivos Aurora cancela a atualização.

Altere o mecanismo de armazenamento padrão para tabelas temporárias do MyISAM para o InnoDB. Siga estas etapas:

  1. Modifique o parâmetro de banco de dados default_tmp_storage_engine para InnoDB.

  2. Reinicialize o cluster de banco de dados.

  3. Após a reinicialização, confirme se o parâmetro de banco de dados default_tmp_storage_engine está definido como InnoDB. Use o seguinte comando:

    show global variables like 'default_tmp_storage_engine';

  4. Certifique-se de não criar nenhuma tabela temporária que use o mecanismo de armazenamento MyISAM. Recomendamos que você pause todas as workloads de banco de dados e não crie nenhuma conexão de banco de dados, porque você fará upgrade em breve.

  5. Tente realizar o upgrade local novamente.
O usuário mestre foi excluído. Aurora cancela a atualização.
Importante

Não exclua o usuário mestre.

No entanto, se por algum motivo você excluir o usuário mestre, restaure-o usando os seguintes comandos SQL:

CREATE USER 'master_username'@'%' IDENTIFIED BY 'master_user_password' REQUIRE NONE PASSWORD EXPIRE DEFAULT ACCOUNT UNLOCK;

GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, 
LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, 
TRIGGER, LOAD FROM S3, SELECT INTO S3, INVOKE LAMBDA, INVOKE SAGEMAKER, INVOKE COMPREHEND ON *.* TO 'master_username'@'%' WITH GRANT OPTION;

Para ver mais detalhes sobre a solução de problemas que fazem com que as verificações prévias de atualização falhem, consulte os seguintes blogs:

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