Por que meu snapshot de cluster de banco de dados do Aurora MySQL-Compatible está demorando tanto para ser restaurado?

Descrição breve

O processo de restauração de snapshots para clusters de banco de dados do Amazon Aurora MySQL-Compatible Edition envolve várias tarefas importantes. Por exemplo, durante esse processo, um cluster do Aurora é criado, assim como o volume do cluster de alta disponibilidade. Processos como verificação de status, alocação de armazenamento e hardware e gravação de volumes de dados contribuem para o tempo necessário para restaurar um snapshot.

O tempo de restauração do snapshot é influenciado por vários fatores:

• Para clusters do Aurora, um único cluster é distribuído por três zonas de disponibilidade (AZs) para fornecer alta disponibilidade. Quando o cluster do Aurora é restaurado do snapshot, ele provisiona o armazenamento nessas três AZs. Depois que o cluster se torna disponível, ele cria mais seis cópias dentro do volume do cluster para armazenar dados. O volume de armazenamento é repartido por centenas de nós de armazenamento e distribuído em três AZs diferentes.
• Depois que o cluster do Aurora é criado, o cluster faz download de dados do Amazon Simple Storage Solution S3 (Amazon S3) para os nós de armazenamento. O cluster faz isso antes que os dados se tornem disponíveis. Ao contrário do processo de restauração do Amazon Relational Database Service (Amazon RDS) para instâncias do MySQL, o carregamento lento não ocorre após a restauração.
• As restaurações do Aurora não são lineares. Então, por exemplo, você pode restaurar dois clusters separados, um com 1 GB de dados e outro com 10 GB de dados. Em vez de levar dez vezes mais tempo, o conjunto de dados maior demora apenas um pouco mais do que o conjunto de dados menor para ser restaurado.
• Outros processos da restauração incluem verificações de status, alocação de armazenamento e hardware e gravação de volumes de dados. Todos esses processos são demorados, mas precisam ser executados com precisão para garantir a melhor performance.

Resolução

É possível usar o recurso de clonagem de clusters ou o recurso de backtracking do Aurora ao fazer alterações nos bancos de dados do Aurora, dependendo do caso de uso.

Clonagem de clusters do Aurora

Usar o recurso de clonagem de clusters do Aurora é a maneira mais rápida de criar uma cópia idêntica do seu cluster atual. Depois que o cluster clonado for criado, você poderá testar suas alterações no próprio cluster clonado sem afetar o cluster original. Se o teste for bem-sucedido, as alterações poderão ser aplicadas ao cluster original.

Observação: ainda é prática recomendada capturar um snapshot do cluster antes de implementar qualquer alteração em um banco de dados.

Aqui estão alguns casos de uso comuns para clonagem de um cluster do Aurora existente:

• Você deseja experimentar e avaliar o impacto de mudanças, como alterações de esquema ou alterações em grupos de parâmetros.
• Você deseja realizar operações com workloads intensivas, como exportar dados ou executar consultas analíticas.
• Você deseja criar uma cópia de um cluster de banco de dados de produção em um ambiente de não produção para fins de desenvolvimento ou teste.

Recurso de backtracking do Aurora

Também é possível usar a funcionalidade de backtracking para seus clusters do Aurora. O backtracking permite desfazer erros rapidamente recuperando seus dados no local. O backtracking de um cluster de banco de dados não exige a criação de um novo cluster de banco de dados. Portanto, ele precisa de apenas alguns minutos para ser concluído.

Mas esse recurso têm algumas limitações. Primeiro, ele está disponível somente em clusters que foram criados com o recurso ativado. Se seu cluster não tiver esse recurso ativado, será necessário realizar uma restauração instantânea para ativar o backtracking. Além disso, o backtracking não oferece suporte à replicação binária de logs, e a replicação entre regiões deverá ser desativada para que o backtracking possa ser configurado ou usado. O limite máximo para uma janela de backtracking é de 72 horas.

Considerações

Os recursos de clonagem e backtracking de clusters do Aurora foram introduzidos para melhorar o tempo de restauração do Aurora em determinados casos de uso. Porém, capturar um snapshot convencional ainda é uma boa prática, e recomenda-se adotar essa abordagem antes de realizar qualquer alteração planejada em um banco de dados.

Além disso, certifique-se de que nenhuma operação de gravação de longa duração esteja sendo executada no banco de dados de origem no momento do snapshot, point-in-time ou clone. Qualquer DCL, DDL ou DML (transações de gravação abertas) de longa duração pode aumentar o tempo necessário para que o banco de dados restaurado se torne disponível.

Informações relacionadas

Clonagem de um volume para um cluster de banco de dados do Amazon Aurora

Backtracking de clusters de banco de dados do Aurora

---