Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
L’exécution d’une migration de modifications de réplication (avec notre scénario hors connexion) avec « Activer la cohérence transactionnelle » permet aux entreprises de migrer leurs bases de données vers Azure pendant que les bases de données restent opérationnelles. En d’autres termes, les migrations peuvent être effectuées avec un temps d’arrêt minimal pour les applications sensibles, ce qui limite l’impact sur la disponibilité du niveau de service et les inconvénients pour leurs clients finaux.
Implémentation actuelle
Vous devez exécuter un scénario de migration hors connexion avec « Activer la cohérence transactionnelle » pour obtenir le fichier journal bin et la position pour répliquer les modifications entrantes. L’interface utilisateur du portail DMS affiche le nom de fichier journal binaire et la position alignées sur le moment où les verrous ont été obtenus sur la source pour l’instantané cohérent. Vous pouvez utiliser cette valeur dans notre migration de modifications de réplication pour diffuser en continu les modifications entrantes.
Lors de l’exécution de la migration des modifications de réplication, lorsque votre cible est presque rattrapée avec le serveur source, arrêtez toutes les transactions entrantes vers la base de données source et attendez que toutes les transactions en attente aient été appliquées à la base de données cible. Pour vérifier que la base de données cible est à jour sur le serveur source, exécutez la requête 'SHOW MASTER STATUS;', puis comparez cette position au dernier événement de journal binaire validé (affiché sous Progression de la migration). Lorsque les deux positions sont identiques, c’est que la cible a rattrapé toutes les modifications. Vous pouvez alors commencer le basculement.
Fonctionnement de la réplication des modifications
L’implémentation actuelle est basée sur les modifications de journal binaire de diffusion en continu du serveur source et leur application au serveur cible. Comme la réplication des données entrantes, elle est plus facile à mettre en place et ne nécessite pas de connexion physique entre les serveurs source et cible.
Le serveur peut envoyer Binlog en tant que flux qui contient des données binaires comme documenté ici. Le client peut spécifier la position du journal initial avec laquelle démarrer le flux. Le nom du fichier journal décrit la position du journal, la position dans ce fichier et éventuellement GTID (ID de transaction globale) si le mode gtid est activé à la source.
Les modifications de données sont envoyées en tant qu’événements de « ligne », qui contiennent des données pour des lignes individuelles (avant et/ou après la modification en fonction du type d’opération, qui est insert (insérer), delete (supprimer) ou update (mettre à jour). Les événements de ligne sont ensuite appliqués dans leur format brut à l’aide d’une instruction BINLOG : Manuel de référence MySQL 8.0 :: 13.7.8.1 Instruction BINLOG. Toutefois, pour une migration DMS vers un serveur 5.7, DMS n’applique pas de modifications en tant qu’instructions BINLOG (étant donné que DMS n’a pas les privilèges nécessaires pour le faire) et traduit plutôt les événements de ligne en instructions INSERT, UPDATE, ou DELETE.
Prerequisites
Pour réussir la migration des modifications de réplication, vérifiez que les conditions préalables suivantes sont remplies :
Utilisez l’outil de ligne de commande MySQL de votre choix pour déterminer s’il
log_binest activé sur le serveur source. Binlog n’est pas toujours activé par défaut. Vérifiez donc qu’il est activé avant de démarrer la migration. Pour déterminer si log_bin est activé sur le serveur source, exécutez la commande :SHOW VARIABLES LIKE 'log_bin'Vérifiez que l’utilisateur dispose de l’autorisation
REPLICATION_APPLIERouBINLOG_ADMINsur le serveur cible pour appliquer le journal bin.Vérifiez que l’utilisateur dispose
REPLICATION REPLICAd’une autorisation sur le serveur cible.Vérifiez que l’utilisateur dispose des autorisations
REPLICATION CLIENTetREPLICATION REPLICAsur le serveur source pour lire et appliquer le journal de bin.Exécutez un scénario de migration hors connexion avec Activer la cohérence transactionnelle pour obtenir le fichier journal bin et la position.
Si vous envisagez une migration des modifications de réplication, configurez le paramètre binlog_expire_logs_seconds sur le serveur source pour vous assurer que les fichiers de journal binaire ne sont pas purgés avant que le réplica valide les modifications. Nous vous recommandons de commencer par au moins deux jours. Lorsque le basculement a réussi, la valeur peut être réinitialisée.
Limitations
- Lors de l’exécution d’une migration de modifications de réplication, le nom de la base de données sur le serveur cible doit être identique au nom du serveur source.
- La prise en charge est limitée au format de journal binaire ROW.
- La réplication des modifications DDL est prise en charge uniquement lorsque vous avez sélectionné l’option de Réplication des instructions de définition de données et d’administration pour les objets sélectionnés sur l’interface utilisateur DMS. La fonctionnalité de réplication prend en charge la réplication des instructions de définition de données et d’administration qui se produisent après la charge initiale et sont consignées dans le journal binaire sur la cible.
- Le changement de nom des bases de données ou des tables n’est pas pris en charge lors de la réplication des modifications.