Partager via

Répliquer des données dans Azure Database pour MySQL - Serveur flexible

  • Article

La réplication des données entrantes vous permet de synchroniser des données d’un serveur MySQL externe avec une instance de serveur flexible Azure Database pour MySQL. Le serveur externe peut être hébergé localement, dans des machines virtuelles, un Serveur unique Azure Database pour MySQL ou un hôte de service de base de données hébergé par les autres fournisseurs de services cloud. La réplication des données entrantes est basée sur une réplication basée sur GTID ou une position du fichier journal binaire (binlog). Si vous souhaitez obtenir plus d’informations sur la réplication binlog, consultez la Réplication MySQL.

Remarque

La configuration de la réplication des données entrantes pour la haute disponibilité avec serveurs est prise en charge uniquement par la réplication basée sur GTID.

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 un serveur flexible Azure Database pour MySQL. Cette synchronisation permet de 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 cloud : pour les solutions de cloud complexes, utilisez la réplication des données entrantes pour synchroniser les données entre un serveur flexible Azure Database pour MySQL et différents fournisseurs de cloud, y compris les machines virtuelles et les services de base de données hébergés dans ces clouds.
  • Migration : les clients peuvent effectuer une migration dans un délai minimal en tirant parti d’outils open source, tels que MyDumper/MyLoader, avec la réplication des données entrantes. Un basculement sélectif de la charge de production de la base de données source vers la base de données de destination est possible avec la réplication des données.

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.

Réplication des données entrantes est prise en charge sur des serveurs à haute disponibilité (HA)

La prise en charge de la réplication des données entrantes pour un serveur à haute disponibilité est disponible uniquement via une réplication basée sur GTID.

La procédure stockée pour la réplication en utilisant GTID est disponible sur tous les serveurs à haute disponibilité sous le nom mysql.az_replication_change_master_with_gtid.

Filtrer

Le paramètre replicate_wild_ignore_table crée un filtre de réplication pour des tables sur le serveur réplica. Pour modifier ce paramètre à partir du portail Azure, accédez à l’instance de serveur flexible Azure Database pour MySQL utilisé en tant que réplica, puis sélectionnez « Paramètres du serveur » pour afficher/modifier le paramètre replicate_wild_ignore_table.

Spécifications

  • La version du serveur source doit être au moins MySQL version 5.7.

  • Nous vous recommandons d’utiliser la même version de serveur source et de réplica. Par exemple, les deux doivent être MySQL version 5.7 ou MySQL version 8.0.

  • Nous vous recommandons de disposer d’une clé primaire dans chaque table. Si nous disposons d’une table sans clé primaire, vous pouvez rencontrer une réplication lente.

  • Le serveur source doit utiliser le moteur MySQL InnoDB.

  • L’utilisateur doit disposer des autorisations appropriées pour configurer la journalisation binaire et créer de nouveaux utilisateurs sur le serveur source.

  • Les fichiers journaux binaires sur le serveur source ne doivent pas être supprimés définitivement avant que le réplica applique ces modifications. Si la source est le serveur flexible Azure Database pour MySQL, reportez-vous à la configuration de binlog_expire_logs_seconds pour Serveur flexible ou Serveur unique

  • 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. Consultez les exemples suivants et le paramètre master_ssl_ca.

  • 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.

  • Avec accès public, 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). Si vous disposez d’un point de terminaison privé et que vous avez désactivé l’accès public, la réplication des données n’est pas prise en charge

  • Avec accès privé (Intégration VNet), assurez-vous que le nom du serveur source peut être résolu et qu’il est accessible à partir du réseau virtuel où l’instance de serveur flexible Azure Database pour MySQL est en cours d’exécution. (Pour plus de détails, consultez Résolution de noms des ressources dans les réseaux virtuels Azure).

Clé primaire invisible générée

Pour MySQL version 8.0 et ultérieure, des clés primaires invisibles générées (GIPK) sont activées par défaut pour tous les instances de serveurs flexibles Azure Database pour MySQL. Les serveurs MySQL 8.0+ ajoutent la colonne invisible my_row_id aux tables et une clé primaire sur cette colonne, lorsque la table InnoDB est créée sans clé primaire explicite. Cette fonctionnalité, lorsqu'elle est activée, peut affecter certains cas d'utilisation de réplication de données, comme décrit ci-dessous :

  • La réplication des données échoue avec l'erreur de réplication : «ERROR 1068 (42000) : Plusieurs clés primaires définies» si le serveur source crée une clé primaire sur la table sans clé primaire. Pour une atténuation, exécutez la commande SQL suivante, ignorez l’erreur de réplication et redémarrez la réplication des données entrantes.

    alter table <table name> drop column my_row_id, add primary key <primary key name>(<column name>);

  • La réplication des données entrantes échoue avec l’erreur de réplication : « ERREUR 1075 (42000) : Définition de table incorrecte. Il ne peut y avoir qu’une seule colonne automatique et elle doit être définie en tant que clé » si le serveur source ajoute une colonne auto_increment en tant que clé unique. Pour une atténuation, exécutez la commande SQL suivante, définissez « sql_generate_invisible_primary_key » sur OFF, ignorez l’erreur de réplication et redémarrez la réplication des données entrantes.

    alter table <table name> drop column my_row_id, modify <column name> int auto_increment;

  • La réplication des données entrantes échoue si le serveur source exécute un autre code SQL non pris en charge lorsque « sql_generate_invisible_primary_key » est défini sur ON. Par exemple, créez une table de partition. Dans un tel scénario, l’atténuation consiste à définir « sql_generate_invisible_primary_key » sur OFF et à redémarrer la réplication des données entrantes.

Contenu connexe