Assistant de migration de données depuis MySQL vers Azure Database pour MySQL – Capture instantanée cohérente MySQL
Capture instantanée cohérente MySQL est une nouvelle fonctionnalité qui permet aux utilisateurs d’effectuer une sauvegarde cohérente d’un serveur MySQL sans affecter l’intégrité des données à la source en raison d’opérations de création, de lecture, de mise à jour et de suppression (CRUD) en cours. La cohérence transactionnelle est obtenue sans avoir à configurer le serveur source en mode lecture seule par le biais de cette fonctionnalité. De plus, plusieurs options de cohérence des données sont proposées à l’utilisateur : activer une capture instantanée cohérente avec un verrou en lecture (en disponibilité générale), activer la capture instantanée cohérente sans verrous (en préversion), rendre le serveur source en lecture seule et Aucune. Sélectionner l’option "Aucune" n’implique aucune mesure supplémentaire pour garantir la cohérence des données. Les deux options : activez l’instantané cohérent avec le verrou de lecture (GA), activez l’instantané cohérent sans verrous prennent en charge l’exécution d’une migration en ligne. Nous vous recommandons vivement de sélectionner l’option "Activer la capture instantanée cohérente sans verrous" pour préserver la cohérence transactionnelle.
Activer la capture instantanée cohérente sans verrous (préversion)
Lorsque vous activez cette option, une phase de rapprochement se produit après la charge initiale. Cela permet de s’assurer que les données écrites dans votre cible sont transactionnellement cohérentes avec le serveur source à partir d’une position spécifique dans le journal binaire.
Avec cette fonctionnalité, nous ne prenons pas de verrou de lecture sur le serveur. Nous lisons plutôt des tables à un point différent dans le temps, tout en surveillant les différentes positions binlog de chaque table. Cela permet de rapprocher les tables vers la fin de la charge initiale en effectuant une réplication en mode rattrapage pour obtenir une capture instantanée cohérente.
Fonctionnalités clés des instantanés cohérents sans verrouillage :
- Possibilité de prendre en charge des serveurs à forte charge de travail ou des serveurs avec des transactions de longue durée sans qu’il soit nécessaire d’utiliser des verrous de lecture.
- Résilience dans l’exécution des migrations, même en cas de défaillances causées par des perturbations transitoires du réseau/serveur qui entraînent la perte de toutes les connexions créées au préalable.
Activer une capture instantanée cohérente avec un verrou en lecture (GA)
Lorsque vous activez cette option, le service vide toutes les tables sur le serveur source présentant un verrou en lecture pour obtenir la capture instantanée à un instant dans le temps. On a recours à ce vidage, car un verrou global est plus fiable que de tenter de verrouiller des bases de données ou des tables individuelles. Par conséquent, même si vous ne migrez pas toutes les bases de données d’un serveur, elles sont verrouillées dans le cadre de la configuration du processus de migration. Le service de migration lance une lecture reproductible et combine l’état actuel de la table avec le contenu du journal d’annulation pour l’instantané. L’instantané est généré après l’obtention du verrou à l’échelle du serveur pendant quelques secondes et la génération de plusieurs connexions pour la migration. Après la création de toutes les connexions utilisées pour la migration, les verrous sur la table sont libérés.
Les lectures reproductibles sont activées afin que les journaux d’annulation restent accessibles pendant la migration, ce qui augmente le stockage requis sur la source à cause des connexions longues. Une migration longue avec plusieurs modifications de table entraîne un historique de journaux d’opérations d’annulation étendu qui doit être relu, et peut également augmenter les exigences de calcul et la charge sur le serveur source.
Rendre le serveur source en lecture seule
Sélectionner cette option maintient l’intégrité des données de la base de données cible pendant que la source est migrée, tout en empêchant les opérations d’écriture ou de suppression sur le serveur source lors de la migration. Lorsque vous configurez le serveur source en lecture seule dans le cadre du processus de migration, la sélection s’applique à toutes les bases de données du serveur source, qu’elles soient sélectionnées ou non pour la migration.
Configurer le serveur source en lecture seule empêche les utilisateurs de modifier les données, ce qui rend la base de données indisponible pour les opérations de mise à jour. Toutefois, si cette option n’est pas activée, il est possible que des mises à jour de données se produisent pendant la migration. Par conséquent, les données migrées peuvent être incohérentes, car les instantanés de base de données seraient lus à différents moments dans le temps.
Conditions préalables à l’activation d’un instantané cohérent avec un verrou de lecture
Pour terminer la migration avec une capture instantanée cohérente avec le verrou de lecture activé :
Vérifier que l’utilisateur qui tente de vider les tables avec un verrou en lecture dispose de l’autorisation RELOAD ou FLUSH.
Utiliser l’outil client mysql pour déterminer si log_bin est activé sur le serveur source. Le journal binaire n’est pas toujours activé par défaut. Il faut le vérifier avant de démarrer la migration. L’outil client mysql est utilisé pour déterminer si log_bin est activé sur la source en exécutant la commande SHOW VARIABLES LIKE 'log_bin';
Remarque
Avec Azure Database pour MySQL Single Server, qui prend en charge jusqu’à 4 To, cette option n’est pas activée par défaut. Toutefois, si vous promouvez un réplica en lecture pour le serveur source et que vous supprimez ensuite le réplica en lecture, le paramètre est défini sur ON.
- Configurez le paramètre binlog_expire_logs_seconds sur le serveur source pour vous assurer que les fichiers binlog ne sont pas purgés avant que le réplica ne valide les modifications. Une fois le basculement réussi, la valeur peut être réinitialisée.
Problèmes connus et limitations liés à l’activation d’une capture instantanée cohérente sans verrous
- Les tables avec des clés étrangères présentant la clause Cascade ou Définir Null lors de la suppression/lors de la mise à jour ne sont pas prises en charge.
- Aucune modification DDL ne doit se produire pendant la charge initiale.
Problèmes connus et limitations liés à l’activation d’une capture instantanée cohérente avec un verrou en lecture
Les problèmes connus et limitations associés à Sauvegarde cohérente se répartissent en deux catégories : les verrous et les nouvelles tentatives.
Remarque
Le service de migration exécute la requête START TRANSACTION WITH CONSISTENT SNAPSHOT pour tous les threads de travail afin d’obtenir l’instantané du serveur. Mais cela n’est pris en charge que par InnoDB. Vous trouverez davantage d’informations ici.
Verrous
En règle générale, l’obtention d’un verrou est un processus simple qui doit prendre de quelques secondes à quelques minutes. Toutefois, dans quelques scénarios les tentatives d’obtention d’un verrou sur le serveur source peuvent échouer.
La présence de requêtes de longue durée peut entraîner un temps d’arrêt inutile, car DMS est susceptible de verrouiller un sous-ensemble des tables, puis de voir son délai d’attente expirer en attendant que les dernières soient disponibles. Avant de démarrer la migration, vérifiez la présence d’opérations de longue durée en exécutant la commande SHOW PROCESSLIST.
Si le serveur source rencontre un grand nombre de mises à jour d’écriture au moment où un verrou est demandé, celui-ci ne pourra pas être facilement obtenu et son obtention risque d’échouer après le délai d’attente du verrou. Cela se produit dans le cas de tâches de traitement par lots dans les tables, qui peuvent entraîner le refus de la demande de verrou. Comme mentionné précédemment, le verrou demandé est un verrou de niveau global unique pour l’ensemble du serveur. Ainsi, même si une seule table ou base de données est en cours de traitement, la demande de verrou doit attendre la fin de la tâche en cours.
Une autre limitation concerne la migration à partir d’un serveur source RDS AWS. RDS ne prend pas en charge les tables de vidage avec verrou en lecture, et la requête LOCK TABLE est exécutée sur les tables sélectionnées sous le capot. Les tables étant verrouillées individuellement, le processus de verrouillage peut être moins fiable et l’acquisition des verrous peut prendre davantage de temps.
Nouvelle tentatives
La migration gère les problèmes de connexion temporaires, et des connexions supplémentaires sont généralement provisionnées immédiatement à cet effet. Nous examinons les paramètres de migration, en particulier le nombre d’opérations de lecture parallèles sur la source, appliquons un facteur (généralement ~1,5) et créons le plus de connexions possible immédiatement. Ainsi, le service garantit que nous pouvons poursuivre l’exécution des opérations en parallèle. À tout moment, s’il y a une perte de connexion ou si le service ne parvient pas à obtenir un verrou, le service utilise les connexions excédentaires provisionnées pour réessayer la migration. Si toutes les connexions approvisionnées sont épuisées, ce qui entraîne la perte de la synchronisation jusqu’à un instant dans le temps, la migration doit être redémarrée à partir du début. En cas de réussite et d’échec, toutes les actions de nettoyage sont effectuées par ce service de migration hors connexion, et l’utilisateur n’a pas à effectuer d’actions de nettoyage explicites.