Bien que ce soit une bonne idée de verrouiller la base de données et de geler le système de fichiers lorsque vous lancez l'instantané, l'appel d'API réel pour lancer l'instantané prend une fraction de seconde, de sorte que votre base de données et votre système de fichiers ne sont pas verrouillés/gelés pendant longtemps.
Cela dit, il y a quelques autres considérations que vous n'avez pas mentionnées :
-
Lorsque vous tentez de créer le verrou sur la base de données, il peut être nécessaire d'attendre la fin d'autres instructions avant que le verrou ne soit accordé. Pendant ce temps, votre verrou en attente peut être soumis à d'autres instructions pour attendre que vous obteniez et libériez le verrou. Cela peut entraîner des interruptions dans le flux des déclarations sur votre base de données de production.
-
Une fois que vous avez lancé la création de l'instantané, votre application/base de données est libre d'utiliser le système de fichiers sur le volume, mais si vous avez beaucoup d'écritures, vous pouvez rencontrer une attente élevée, parfois suffisante pour créer un ralentissement notable de votre application. La raison en est que le processus d'instantané en arrière-plan doit copier un bloc sur S3 avant d'autoriser une écriture sur ce bloc sur le volume actif.
Je résous le premier problème en demandant un verrou et un délai d'expiration s'il n'est pas accordé rapidement. J'attends ensuite un peu et continue de réessayer jusqu'à ce que j'obtienne le verrou. Les délais d'attente appropriés et le délai de nouvelle tentative peuvent varier pour différentes charges de base de données.
Je résous le deuxième problème en effectuant des instantanés fréquents et cohérents sur l'esclave au lieu du maître, comme vous l'avez proposé. Je recommande toujours d'effectuer des instantanés occasionnels sur le maître simplement pour améliorer sa durabilité intrinsèque (une propriété EBS profonde), mais ces instantanés n'ont pas besoin d'être effectués avec verrouillage ou gel car vous n'allez pas les utiliser pour les sauvegardes.
Je recommande également l'utilisation d'un système de fichiers prenant en charge le vidage et le gel (XFS). Sinon, vous capturez des tables verrouillées dans MySQL qui n'ont peut-être même pas encore tous leurs blocs sur le volume EBS ou d'autres parties du système de fichiers peuvent être modifiées et incohérentes dans l'instantané.
Si vous êtes intéressé, j'ai publié un logiciel open source qui applique les meilleures pratiques que j'ai recueillies concernant la création d'instantanés EBS cohérents avec MySQL et XFS (tous deux facultatifs).
Pour répondre à votre dernière question, le verrouillage des tables dans le maître n'interrompra pas la réplication. Dans mon logiciel d'instantané, je vide également les tables avec un verrou en lecture pour m'assurer que tout se trouve sur le disque en cours d'instantané et j'ajoute le mot-clé "LOCAL" afin que le vidage ne soit pas répliqué sur les esclaves potentiels.
