Pourquoi la restauration à un instant dans le passé de mon instance Amazon RDS for MySQL prend-elle beaucoup de temps ?

Brève description

La restauration à un instant dans le passé (PITR) est le processus de restauration d'une base de données à l'état dans lequel elle se trouvait à une date et une heure spécifiées. Lorsque vous lancez une PITR, la sauvegarde la plus récente (automatisée ou manuelle) est restaurée. Les journaux transactionnels sont ensuite appliqués pour transférer la base de données Amazon RDS à l'heure PITR.

Résolution

Bonnes pratiques pour éviter une longue restauration à un instant dans le passé

Pour éviter une longue restauration à un instant dans le passé, suivez les bonnes pratiques ci-dessous :

• Créez une stratégie de reprise après sinistre.
• Utilisez des transactions plus petites et exécutez la commande COMMIT plus fréquemment.
• Pour exécuter une transaction volumineuse, prenez un instantané avant et après les transactions volumineuses. Toutefois, les transactions supérieures au paramètre max_allowed_packet entraînent l'échec du PITR.
• Réduisez les temps de restauration des instantanés. Les restaurations d'instantanés sont initiées dans le cadre du processus de restauration à un instant dans le passé. Une restauration d'instantanés plus longue peut contribuer à une séance de restauration à un instant dans le passé plus longue. Pour plus d'informations, consultez Pourquoi la restauration d'un instantané de mon instance de base de données Amazon RDS for MySQL prend-elle autant de temps ?
• Un processus d'application de journaux peut prendre plus de temps en fonction du nombre de journaux à appliquer. Pour réduire le nombre de journaux à appliquer, envisagez de prendre un instantané manuel entre les sauvegardes automatisées. Comme la restauration à un instant dans le passé sélectionne automatiquement les instantanés automatiques ou manuels créés près de l'heure PITR, le fait d'avoir des instantanés manuels intermédiaires peut réduire le nombre de journaux à appliquer. Si vous faites face à un volume important de modifications, prenez un instantané manuel toutes les 3 à 4 heures.
• Si vous effectuez la relecture des transactions importantes, une valeur de wait_timeout faible peut interrompre les processus de restauration à un instant dans le passé dans Amazon RDS for MySQL. Par exemple, des interruptions se produisent si vous effectuez une mise à jour, une insertion ou une suppression volumineuses en bloc basées sur les lignes et que la relecture dure plus que wait_timeout. Pour éviter toute interruption du processus PITR, définissez la valeur wait_timeout sur « 600 » (10 minutes) ou plus. Pour plus d'informations, consultez la section wait_timeout dans Bonnes pratiques pour la configuration des paramètres pour Amazon RDS for MySQL.
• Lorsque la journalisation binaire basée sur les lignes est utilisée, envisagez de définir la valeur du paramètre binlog_row_image sur « MINIMAL » au lieu de « FULL ». Cette valeur mise à jour réduit la taille des journaux binaires, ce qui réduit le temps de récupération des journaux binaires.
• À moins que vous n'ayez besoin d'un format spécifique de journaux binaires, envisagez d'utiliser le format de journalisation MIXTE. Avec la journalisation mixte, la journalisation basée sur les instructions est utilisée par défaut, mais le mode de journalisation passe automatiquement en mode ligne si nécessaire. Ce changement peut contribuer à réduire la taille des journaux binaires. Pour plus d'informations sur la journalisation MIXTE, consultez Formats de journalisation binaire sur le site Web MySQL.

Échecs de restaurations à un instant dans le passé

Les scénarios suivants entraînent l'échec de la restauration à un instant dans le passé :

• Instances de bases de données qui sont dans un état « stockage plein ».
• Utilisation des tables MyISAM dans MySQL. Les moteurs de stockage MyISAM ne prennent pas en charge les processus fiables de reprise après incident. Les tables MyISAM empêchent le processus de restauration à un instant dans le passé de fonctionner correctement.
• Utilisation de tables temporaires, de transactions distribuées et de tables en mémoire.