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

  • Article

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

La réplication des données entrantes vous permet de synchroniser des données à partir d’un serveur MySQL externe dans 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 les serveurs activés avec la haute disponibilité est prise en charge uniquement par le biais de 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 des données hronisation hybride : avec la réplication des données entrantes, vous pouvez conserver les données synchronisées entre vos serveurs locaux et Azure Database pour MySQL serveur flexible. 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 multicloud : pour les solutions cloud complexes, utilisez la réplication de données entrantes pour synchroniser les données entre Azure Database pour MySQL serveur flexible 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 de l’Portail Azure, accédez à l’instance de serveur flexible Azure Database pour MySQL utilisée en tant que réplica et sélectionnez « Paramètres du serveur » pour afficher/modifier le replicate_wild_ignore_table paramètre.

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 Azure Database pour MySQL serveur flexible, consultez comment configurer binlog_expire_logs_seconds pour un serveur flexible ou un 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).
  • Avec l’accès privé, 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, les clés primaires invisibles générées (GIPK) sont activées par défaut pour toutes les instances de serveur 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. Lorsqu’elle est activée, cette fonctionnalité peut avoir un impact sur certains des cas d’usage de la réplication des données entrantes, tel que décrit ci-dessous :

  • La réplication des données entrantes échoue avec une erreur de réplication : « ERREUR 1068 (42000) : clé primaire multiple définie » 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.

Étapes suivantes