Répliquer des données dans Azure Database pour MySQL

  • Article

S’APPLIQUE À : Azure Database pour MySQL - Serveur unique

Important

Azure Database pour MySQL serveur unique se trouve sur le chemin de mise hors service. Nous vous recommandons vivement de procéder à la mise à niveau vers Azure Database pour MySQL serveur flexible. Pour plus d’informations sur la migration vers Azure Database pour MySQL serveur flexible, consultez Ce qui se passe pour Azure Database pour MySQL serveur unique ?

La Réplication des données entrantes vous permet de synchroniser les données d'un serveur MySQL externe avec le service Azure Database pour MySQL. Le serveur externe peut être hébergé localement, dans des machines virtuelles, ou il peut s'agir d'un service de base de données hébergé par d'autres fournisseurs de services cloud. La réplication des données repose sur la réplication basée sur le GTID ou sur la position du fichier journal binaire (binlog) native à MySQL. Pour en savoir plus sur la réplication binlog, consultez la vue d’ensemble de la réplication binlog MySQL.

Quand utiliser la réplication des données entrantes

Voici les principaux scénarios à prendre en compte concernant l’utilisation de la réplication des données entrantes :

  • Synchronisation de données hybride : avec la réplication des données entrantes, vous pouvez maintenir la synchronisation des données entre vos serveurs locaux et Azure Database pour MySQL. Cette synchronisation est utile pour créer des applications hybrides. Cette méthode est intéressante si vous disposez d'un serveur de base de données local mais souhaitez déplacer les données vers une région proche des utilisateurs finaux.
  • Synchronisation de plusieurs clouds : pour les solutions cloud complexes, utilisez la réplication des données entrantes pour synchroniser les données entre Azure Database pour MySQL et différents fournisseurs de cloud, notamment les machines virtuelles et les services de base de données hébergés dans ces clouds.

Pour les scénarios de migration, utilisez Azure Database Migration Service (DMS).

Limitations et considérations

Données non répliquées

La base de données système mysql sur le serveur source n’est pas répliquée. De plus, les changements apportés aux comptes et aux autorisations sur le serveur source ne le sont pas non plus. Si vous créez un compte sur le serveur source et que ce compte a besoin d’accéder au serveur réplica, créez manuellement le même compte sur le serveur réplica. Pour une présentation des tables figurant dans la base de données système, consultez le manuel MySQL.

Filtrage

Pour ignorer la réplication des tables à partir de votre serveur source (hébergé localement, dans des machines virtuelles ou un service de base de données hébergé par d’autres fournisseurs cloud), le paramètre replicate_wild_ignore_table est pris en charge. Si vous le souhaitez, mettez à jour ce paramètre sur le serveur de réplication hébergé dans Azure à l’aide du portail Azure ou d’Azure CLI.

Pour en savoir plus sur ce paramètre, consultez la documentation MySQL.

Pris en charge dans le niveau Usage général ou Mémoire optimisée uniquement

La réplication des données entrantes est prise en charge uniquement dans les niveaux tarifaires Usage général et Mémoire optimisée.

La liaison privée pour la base de données Azure pour MySQL ne prend en charge que les connexions entrantes. La réplication des données entrantes nécessitant une connexion sortante du service, la liaison privée n’est pas prise en charge pour le trafic des données entrantes.

Notes

Le GTID est pris en charge sur les versions 5.7 et 8.0, et uniquement sur les serveurs qui prennent en charge un stockage maximum de 16 To (stockage à usage général v2).

Spécifications

  • La version du serveur source doit être au moins MySQL version 5.6.
  • La version du serveur source et celle du serveur réplica doivent être identiques. Par exemple, ce doit être MySQL version 5.6 ou MySQL version 5.7.
  • Chaque table doit avoir une clé primaire.
  • Le serveur source doit utiliser le moteur MySQL InnoDB.
  • L’utilisateur doit disposer des autorisations nécessaires pour configurer la journalisation binaire et créer de nouveaux utilisateurs sur le serveur source.
  • Si SSL est activé sur le serveur source, vérifiez que le certificat d’autorité de certification SSL fourni pour le domaine a été inclus dans la procédure stockée mysql.az_replication_change_master ou mysql.az_replication_change_master_with_gtid. Consultez les exemples suivants et le paramètre master_ssl_ca.
  • Vérifiez que l’adresse IP du serveur source a été ajoutée aux règles de pare-feu du serveur réplica Azure Database pour MySQL. Mettez à jour les règles de pare-feu à l’aide du portail Azure ou d’Azure CLI.
  • Vérifiez que la machine qui héberge le serveur source autorise à la fois le trafic entrant et le trafic sortant sur le port 3306.
  • Vérifiez que le serveur source dispose d’une adresse IP publique, que DNS est accessible publiquement ou que le serveur source comporte un nom de domaine complet (FQDN).

Étapes suivantes