Por que meu clone de cluster de banco de dados Amazon Aurora, a restauração de snapshot ou a restauração pontual estão demorando tanto?

Breve descrição

As técnicas contínuas de backup e restauração do Amazon Aurora são otimizadas para evitar variações nos tempos de restauração. Eles também ajudam o volume de armazenamento do cluster a atingir o desempenho total assim que o cluster se tornar disponível. Os longos tempos de restauração geralmente são causados por transações de longa duração no banco de dados de origem no momento em que o backup é feito.

Resolução

Observação: se você receber erros ao executar comandos da AWS Command Line Interface (AWS CLI), verifique se está usando a versão mais recente da AWS CLI.

O Amazon Aurora faz backup das alterações do volume do seu cluster de forma automática e contínua. Os backups são retidos durante o período de retenção do backup. Esse backup contínuo permite que você restaure seus dados em um novo cluster, a qualquer momento dentro do período de retenção especificado. Isso evita a necessidade de um longo processo de atualização do binlog. Como você cria um novo cluster, não há impacto no desempenho ou interrupção do banco de dados original.

Quando você inicia um clone, um snapshot ou uma restauração pontual, o Amazon Relational Database Service (Amazon RDS) chama as seguintes APIs em seu nome:

• RestoreDBClusterFromSnapshot ou RestoreDBClusterToPointInTime. Essas APIs criam um novo cluster e restauram o volume do Amazon Simple Storage Service (Amazon S3). Isso pode levar algumas horas para ser concluído. Quando você restaura dados em um cluster do Aurora, todos os dados são transferidos em paralelo do Amazon S3 para as seis cópias em suas três zonas de disponibilidade.
• A clonagem do volume de armazenamento em cluster é uma variação do RestoreDBClusterToPointInTime. Ele usa o protocolo copy-on-write e geralmente é concluído em alguns minutos.

Quando essa etapa é concluída, o cluster muda para o estado Disponível. Você pode verificar o estado do seu cluster atualizando o console ou verificando com o AWS CLI.

O processo de criação da instância começa somente quando o cluster está disponível. Isso acontece em dois estágios: configuração da instância e recuperação de falhas no banco de dados.

Você pode verificar se a API concluiu a configuração da instância procurando o arquivo de log de erros do MySQL. Você pode fazer isso mesmo se a instância estiver no status Criando. Se o arquivo de log de erros estiver disponível para download, a instância está configurada e o mecanismo agora está realizando a recuperação de falhas. O arquivo de log de erros também é o melhor recurso para verificar o progresso da recuperação de falhas do banco de dados, junto com as métricas do Amazon CloudWatch.

Observação: se você estiver usando a CLI ou a API da AWS para realizar uma operação de restauração, deverá invocar a chamada CreateDBInstance porque ela não é automática.

Verifique se há operações de gravação de longa duração no banco de dados de origem

É uma prática recomendada confirmar que não há operações de gravação de longa duração no banco de dados de origem no momento do snapshot, point-in-time ou clone. Qualquer DCL, DDL ou DML (transações abertas de gravação) de longa duração pode aumentar o tempo necessário para que o banco de dados restaurado fique disponível.

Por exemplo, você ativa o log binário de um cluster do Aurora e isso aumenta o tempo necessário para realizar uma recuperação. Isso ocorre porque o InnoDB verifica automaticamente os registros e executa uma reversão do banco de dados até o presente. Em seguida, ele reverte todas as transações não comprometidas que estejam presentes no momento da recuperação. Para obter mais informações sobre a recuperação de falhas do InnoDB, consulte Recuperação do Innodb.

Quando a instância conclui os processos de criação e recuperação, o cluster e a instância estão prontos para aceitar conexões de entrada.

Observação: O Aurora não exige o log binário. É uma prática recomendada desativá-la, a menos que seja necessário. Em vez disso, para replicação entre regiões, você pode avaliar os bancos de dados globais do Aurora. Os bancos de dados globais do Aurora também não exigem registros binários.

Informações relacionadas

Armazenamento e confiabilidade do Amazon Aurora

Restauração a partir de um snapshot de cluster de banco de dados