Partager via

Procédure de configuration de la réplication des données sortantes pour Azure Database pour MySQL – Serveur flexible

  • Article

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

Cet article décrit la procédure de configuration de la réplication des données sortantes dans un serveur flexible Azure Database pour MySQL en configurant les serveurs source et réplica. Cet article suppose que vous avez déjà utilisé des serveurs et des bases de données MySQL.

Pour la réplication des données sortantes, la source est toujours un serveur flexible Azure Database pour MySQL. Le réplica peut être n’importe quel serveur MySQL externe sur d’autres fournisseurs de cloud, sur des machines locales ou virtuelles. Passez en revue les limitations et conditions requises de la Réplication des données sortantes avant de suivre les étapes décrites dans cet article.

Notes

Cet article fait référence au terme esclave, un terme que Microsoft n’utilise plus. Lorsque le terme sera supprimé du logiciel, nous le supprimerons de cet article.

Créez une instance de Serveur flexible Azure Database pour MySQL à utiliser comme source.

  1. Créez une instance Azure Database pour MySQL - Serveur flexible (par exemple, sourceserver.mysql.database.Azure.com). Reportez-vous à Créer une instance de serveur flexible Azure Database pour MySQL à l’aide du Portail Azure pour la création de serveurs. Ce serveur est le serveur « source » pour la réplication des données sortantes.

  2. Créez des comptes d’utilisateur dupliqués et les privilèges correspondants.

    1. Les comptes d’utilisateur ne sont pas répliqués à partir du serveur source vers le serveur réplica. Supposons que vous prévoyiez de fournir aux utilisateurs l’accès au serveur réplica. Dans ce cas, vous devez créer manuellement tous les comptes et privilèges correspondants sur cette nouvelle instance de serveur flexible Azure Database pour MySQL.

Configurer le serveur MySQL source

Les étapes suivantes préparent et configurent l’instance de serveur flexible Azure Database pour MySQL agissant en tant que source.

  1. Configuration réseau requise

    Assurez-vous que vos paramètres réseau sont établis de sorte que le serveur source et le serveur réplica puissent communiquer en toute transparence.
    Si le serveur source est en accès public, vérifiez que les règles de pare-feu autorisent l’adresse IP du serveur réplica. Si le serveur réplica est hébergé sur Azure, veillez à sélectionner l’option permettant d’autoriser l’accès public à partir de n’importe quel service Azure depuis la page réseau du portail Azure. Si le serveur source est sur un accès privé, assurez-vous que le serveur réplica peut se connecter à la source via le peering de réseaux virtuels ou une connexion de passerelle VPN de réseau virtuel à réseau virtuel.

    Remarque

    Pour plus d’informations - Vue d’ensemble des réseaux - Serveur flexible Azure Database pour MySQL.

  2. Activer la journalisation binaire

    Vérifiez si la journalisation binaire a été activée sur le serveur source en exécutant la commande suivante :

    SHOW VARIABLES LIKE 'log_bin';

    Si la variable log_bin est renvoyée avec la valeur 'ON', la journalisation binaire est activée sur votre serveur.

  3. Créer un rôle de réplication et définissez une autorisation

    Créez un compte d’utilisateur sur le serveur source configuré avec des privilèges de réplication. Vous pouvez pour cela utiliser des commandes SQL ou un outil tel que MySQL Workbench. Si vous prévoyez une réplication avec SSL, cela doit être spécifié lors de la création de l’utilisateur. Pour comprendre comment ajouter des comptes d’utilisateur sur votre serveur source, reportez-vous à la documentation MySQL.

    Les commandes suivantes permettent au nouveau rôle de réplication d’accéder au serveur source à partir de n’importe quelle machine, et pas seulement de celle qui héberge le serveur source. Cela s’effectue en spécifiant « syncuser@’%’ » dans la commande de création d’un utilisateur. Consultez la documentation MySQL pour en savoir plus sur la définition des noms de compte.

    Il existe quelques outils que vous pouvez utiliser pour définir des noms de compte. Choisissez celui qui répond le mieux à vos besoins.

Réplication avec SSL

Pour exiger le protocole SSL pour toutes les connexions utilisateur, utilisez la commande suivante pour créer un utilisateur :

CREATE USER 'syncuser'@'%' IDENTIFIED BY 'yourpassword';
GRANT REPLICATION SLAVE ON *.* TO ' syncuser'@'%' REQUIRE SSL;

Réplication sans SSL

Si le protocole SSL n’est pas requis pour toutes les connexions, utilisez la commande suivante pour créer un utilisateur :

CREATE USER 'syncuser'@'%' IDENTIFIED BY 'yourpassword';
GRANT REPLICATION SLAVE ON *.* TO ' syncuser'@'%';

Videz et restaurez le serveur source.

Ignorez cette section s’il s’agit d’un serveur source nouvellement créé sans données existantes à migrer vers le réplica. À ce stade, vous pouvez déverrouiller les tables :

SET GLOBAL read_only = OFF;
UNLOCK TABLES;

Suivez les étapes ci-dessous si le serveur source contient des données existantes à migrer vers le réplica.

  1. Déterminez les bases de données et les tables que vous souhaitez répliquer dans Serveur flexible Azure Database pour MySQL et effectuez la copie de sauvegarde à partir du serveur source. Vous pouvez utiliser mysqldump pour vider les bases de données à partir de votre serveur principal. Pour plus d’informations, consultez Vider et restaurer. Il n’est pas nécessaire de vider la bibliothèque MySQL ni la bibliothèque de test.

  2. Définissez le serveur source en mode lecture/écriture.

Après avoir vidé la base de données, passez l’instance de serveur flexible Azure Database pour MySQL en mode lecture/écriture.

SET GLOBAL read_only = OFF;
UNLOCK TABLES;
  1. Restaurez le fichier de vidage sur le nouveau serveur. Restaurez le fichier de sauvegarde sur le serveur créé dans le serveur flexible Azure Database pour MySQL. Reportez-vous à « Vider et restaurer » pour restaurer un fichier de sauvegarde sur une instance de serveur flexible Azure Database pour MySQL. Si le fichier de vidage est volumineux, transférez-le vers une machine virtuelle dans Azure au sein de la même région que votre serveur réplica. Restaurez-le sur l’instance de serveur flexible Azure Database pour MySQL à partir de la machine virtuelle.

Remarque

Si vous souhaitez éviter de définir la base de données en lecture uniquement lorsque vous sauvegardez et restaurez, vous pouvez utiliser mydumper/myloader.

Configurez le serveur réplica pour démarrer la réplication des données sortantes.

  1. Filtrage

    Supposons que la réplication des données sortantes est en cours de configuration entre un serveur flexible Azure Database pour MySQL et un serveur MySQL externe sur d’autres fournisseurs de cloud ou locaux. Dans ce cas, vous devez utiliser le filtre de réplication pour filtrer les tables personnalisées Azure sur le serveur réplica. Pour ce faire, définissez Replicate_Wild_Ignore_Table = "mysql.__%" pour filtrer les tables internes mysql du serveur flexible Azure Database pour MySQL. Reportez-vous à MySQL :: MySQL 5.7 Reference Manual :: 13.4.2.2 CHANGE REPLICATION FILTER Statement pour plus d’informations sur la modification de ce paramètre de serveur.

  2. Définissez le serveur réplica en vous connectant à celui-ci et en ouvrant l’interpréteur de commandes MySQL sur le serveur réplica. À partir de l’invite, exécutez l’opération suivante, qui configure plusieurs paramètres de réplication MySQL en même temps :

    CHANGE THE REPLICATION SOURCE TO
SOURCE_HOST='<master_host>',
SOURCE_USER='<master_user>',
SOURCE_PASSWORD='<master_password>',
SOURCE_LOG_FILE='<master_log_file>',
SOURCE_LOG_POS=<master_log_pos>
    • master_host: nom d'hôte du serveur source (exemple : 'source.mysql.database.Azure.com')
    • master_user : nom d'utilisateur du serveur source (exemple : 'syncuser'@'%')
    • master_password : mot de passe pour le serveur source
    • master_log_file : nom de fichier du journal binaire à partir de l’exécution de show master status
    • master_log_pos : position du journal binaire à partir de l’exécution de show master status

    Notes

    Pour utiliser SSL pour la connexion, ajoutez l’attribut SOURCE_SSL=1 à la commande. Pour plus d’informations sur l’utilisation de SSL dans un contexte de réplication, consultez https://dev.mysql.com/doc/refman/8.0/en/change-replication-source-to.html

  3. Activez le serveur réplica à l’aide de la commande suivante.

    START REPLICA;

    À ce stade, l’instance de réplica commence à répliquer toutes les modifications apportées à la base de données du serveur source. Vous pouvez tester cette opération en créant un exemple de table sur votre base de données source et en vérifiant si elle est correctement répliquée.

  4. Vérifiez l’état de la réplication.

    Appelez la commande Afficher l’état de l’esclave\G sur le serveur réplica pour afficher l’état de la réplication.

     show slave status;

    Si l'état de Slave_IO_Running et Slave_SQL_Running est yes et si la valeur de Seconds_Behind_Master est 0, alors la réplication fonctionne bien. Seconds_Behind_Master indique la fin du réplica. Le réplica traite les mises à jour si la valeur est différente de 0.

    Si le serveur du réplica est hébergé dans une machine virtuelle Azure, activez l’option Autoriser l’accès aux services Azure (ON) sur la source pour autoriser les serveurs sources et de réplica à communiquer. Ce paramètre peut être modifié dans les options de sécurité de la connexion. Pour plus d’informations, consultez Gérer les règles de pare-feu à l’aide du portail.

    Si vous avez utilisé mydumper/myloader pour sauvegarder la base de données, vous pouvez obtenir les fichiers master_log_file et master_log_pos à partir du fichier /backup/metadata.

Étape suivante