Por que está demorando tanto tempo para realizar uma recuperação para um ponto no tempo da minha instância do Amazon RDS para MySQL?

Breve descrição

A recuperação para um ponto no tempo (PITR) é o processo de restaurar um banco de dados ao estado em que estava em uma data e hora especificadas. Quando você inicia uma PITR, o backup mais recente (automático ou manual) é restaurado. Os logs transacionais são então aplicados para encaminhar o banco de dados do Amazon RDS até o horário da PITR.

Resolução

Práticas recomendadas para evitar uma recuperação para um ponto no tempo prolongada

Para evitar uma recuperação para um ponto no tempo prolongada, siga estas melhores práticas:

• Crie uma estratégia de recuperação de desastres.
• Use transações menores e execute o comando COMMIT com mais frequência.
• Para executar uma transação grande, tire um snapshot antes e depois das grandes transações. No entanto, transações maiores do que o parâmetro max_allowed_packet fazem com que a PITR falhe.
• Minimize os tempos de restauração do snapshot. As restaurações snapshots são iniciadas como parte do processo de recuperação para um ponto no tempo. Uma restauração snapshot mais longa pode contribuir para uma sessão de recuperação para um ponto no tempo mais longa. Para obter mais informações, consulte Por que está demorando tanto tempo para restaurar um snapshot da minha instância de banco de dados do Amazon RDS para MySQL?
• Um processo de aplicação de logs pode levar mais tempo, dependendo do número de logs a serem aplicados. Para reduzir o número de logs a serem aplicados, considere tirar um snapshot manual entre os backups automatizados. Como a recuperação para um ponto no tempo seleciona automaticamente os snapshots automáticos ou manuais criados perto do horário da PITR, ter snapshots manuais intermediários pode reduzir o número de logs a serem aplicados. Se você estiver lidando com um grande volume de alterações, tire um snapshots manual a cada três a quatro horas.
• Se você repetir qualquer transação grande, um valor baixo de wait_timeout poderá interromper os processos de restauração para um ponto no tempo no Amazon RDS para MySQL. Por exemplo, as interrupções ocorrem se você estiver executando uma grande atualização, inserção ou exclusão em massa baseada em linhas e a reprodução demorar mais do que wait_timeout. Para evitar interrupções no processo da PITR, defina o valor de wait_timeout como "600" (10 minutos) ou mais. Para obter mais informações, consulte a seção wait_timeout em Melhores práticas para configuração de parâmetros do Amazon RDS para MySQL.
• Quando o registro em log binário baseado em linha for usado, considere definir o valor do parâmetro binlog_row_image como "MINIMAL" em vez de "FULL". Esse valor atualizado reduzirá o tamanho dos logs binários, minimizando o tempo de recuperação do log binário.
• A menos que você precise de um formato de log binário específico, considere usar o formato de registro em log MIXED. Com o registro em log misto, o registro em log baseado em instruções é usado por padrão, mas o modo de registro em log muda automaticamente para baseado em linha conforme necessário. Essa troca pode ajudar a reduzir o tamanho dos logs binários. Para obter mais informações sobre o registro em log MIXED, consulte Formatos de registro em log binários no site do MySQL.

Falhas na recuperação para um ponto no tempo

As situações a seguir farão com que a recuperação para um ponto no tempo falhe:

• Instâncias de banco de dados que estão em estado de "armazenamento cheio".
• Uso de tabelas MyISAM no MySQL. Os mecanismos de armazenamento MyISAM não oferecem suporte a processos confiáveis de recuperação de falhas. As tabelas MyISAM evitam que o processo de recuperação para um ponto no tempo funcione corretamente.
• Uso de tabelas temporárias, transações distribuídas e tabelas na memória.