Ao usar o AWS re:Post, você concorda com os AWS re:Post Termos de uso

Por que está demorando tanto para restaurar um snapshot da minha instância de banco de dados do Amazon RDS para MySQL?

4 minuto de leitura
0

Estou tentando restaurar um snapshot de uma instância de banco de dados do Amazon Relational Database Service (Amazon RDS) para MySQL. Por que está demorando tanto?

Breve descrição

A demora na restauração de snapshots geralmente é causada por recuperações muito grandes de bancos de dados. O tempo de recuperação depende da workload na instância quando o snapshot foi captado. Caso o registro em log binário esteja habilitado na instância de banco de dados de origem, a recuperação poderá levar mais tempo. Por consequência, a restauração do snapshot também poderá demorar mais.

Resolução

Quando você restaura um snapshot, o Amazon RDS executa um processo de recuperação e o mecanismo de banco de dados MySQL é iniciado em uma nova instância de banco de dados. O início da nova instância pode levar alguns minutos, dependendo da duração da sessão de recuperação durante a startup da instância. Para mais informações, consulte InnoDB Crash Recovery no site do MySQL.

Observação: é normal que haja latência (ou carregamento lento) até que o volume seja completamente abastecido pelo Amazon Simple Storage Service (Amazon S3). Para saber mais sobre o carregamento lento, consulte Restaurar a partir de um snapshot.

Para reduzir o tempo de restauração de um snapshot no Amazon RDS, considere o seguinte:

  • Programe uma janela de backup ou faça um snapshot manual da instância fora do horário de pico. As atividades realizadas na instância de origem durante a captura de um snapshot afetam o tempo que leva para recuperar um banco de dados e para restaurar o snapshot.
  • Se a instância de origem estava usando o armazenamento magnético quando o snapshot foi captado, a instância recém‑restaurada entrará em estado de modificação. Por exemplo, quando você restaura um snapshot de banco de dados usando o armazenamento SSD de uso geral (GP2) ou o armazenamento SSD de IOPS provisionadas (PIOPS), ocorre uma alteração no volume. Por consequência, o status da nova instância muda para “Modificando”. Você ainda pode se conectar a uma instância do Amazon RDS durante esse período, mas é possível que haja uma piora no desempenho.
  • Restaure a instância com uma classe de instância de banco de dados superior, de forma temporária. Pode ser uma classe que tenha mais memória ou mais RAM, por exemplo. A recuperação de falhas pode ser mais rápida ao atualizar a classe da instância de banco de dados. Como você ganha mais recursos temporariamente, a recuperação de falhas ocorre em menos tempo no geral. Depois que a restauração do snapshot for concluída, você poderá redefinir a classe da instância para uma inferior.

Para reduzir o tempo de restauração de snapshots no Amazon RDS quando o registro em log binário estiver ativado, considere as informações a seguir:

  • Os logs binários afetam diretamente o tempo de restauração do snapshot quando o registro em log binário está ativado (por exemplo, quando os backups automatizados estão habilitados na instância de origem). Durante a recuperação de falhas, o processo de restauração do snapshot também recupera os logs binários.
  • Para diminuir o tempo de recuperação de logs binários, evite transações grandes e arquivos grandes de log binário. Quanto mais dados forem registrados nos logs binários, mais dados o processo de restauração terá de processar durante a recuperação de logs binários. Por consequência, o tempo de recuperação aumentará, aumentando também o tempo de restauração do snapshot.
  • Use o tamanho correto para a transação sempre que possível. Transações grandes são gravadas no arquivo de log binário ao mesmo tempo e não são divididas entre arquivos diferentes. Por consequência, o arquivo de log binário acaba ficando grande, o que aumenta o tempo de recuperação de falhas.
  • O formato do registro em log binário também pode afetar o tamanho e a eficiência da recuperação. Alguns formatos (como o registro em log baseado em linha) registram mais informações do que outros nos logs binários. Instruções que modificam um número grande de linhas em uma tabela fazem com que o mecanismo de banco de dados gere entradas de log binário para cada linha modificada. Por consequência, o arquivo de log binário ficará grande. Para mais informações sobre o registro em log baseado em linha, consulte Usage of row-based logging and replication no site do MySQL. Para saber mais sobre os diferentes formatos de registro em log binário, consulte Advantages and disadvantages of statement-based and row-based replication no site do MySQL.