Configuration de la réplication des journaux binaires pour Aurora MySQL

La configuration de la réplication MySQL avec Aurora MySQL implique les étapes suivantes, qui sont présentées en détail :

Table des matières

• 1. Activer la journalisation binaire sur la source de réplication

• 2. Conserver les journaux binaires sur la source de réplication jusqu’à ce qu’ils ne soient plus nécessaires

• 3. Créer une copie ou un vidage de votre source de réplication

• 4. Charger le vidage dans votre cible de réplica (si nécessaire)

• 5. Créer un utilisateur de réplication sur votre source de réplication

• 6. Activer la réplication sur votre cible de réplica

  • Définition d’une position où arrêter la réplication vers un réplica en lecture

• 7. Surveiller votre réplica

• Synchronisation des mots de passe entre la source de réplication et la cible

1. Activer la journalisation binaire sur la source de réplication

Vous trouverez des instructions sur la façon d’activer la journalisation binaire sur la source de réplication pour votre moteur de base de données ci-après.

Moteur de base de données	Instructions
Aurora MySQL	Pour activer la journalisation binaire sur un cluster de bases de données Aurora MySQL Définissez le paramètre de cluster de bases de données binlog_format sur ROW, STATEMENT ou MIXED. La valeur MIXED est recommandée sauf si vous avez besoin d’un format de journal binaire spécifique. (La valeur par défaut est OFF.) Pour modifier le paramètre binlog_format, créez un groupe de paramètres de cluster de bases de données personnalisé et associez ce groupe de paramètres personnalisé à votre cluster de bases de données. Vous ne pouvez pas modifier les paramètres dans le groupe de paramètres de cluster de bases de données par défaut. Si vous modifiez le paramètre binlog_format en remplaçant OFF par une autre valeur, redémarrez votre cluster de bases de données Aurora pour que la modification prenne effet. Pour plus d’informations, consultez Paramètres de cluster de bases de données et d’instance de base de données Amazon Aurora et Groupes de paramètres pour Amazon Aurora.
RDS for MySQL	Pour activer la journalisation binaire sur une instance de base de données Amazon RDS Vous ne pouvez pas activer la journalisation binaire directement pour une instance de base de données Amazon RDS, mais vous pouvez l’activer en exécutant l’une des actions suivantes : Activez les sauvegardes automatiques de l’instance de base de données. Vous pouvez activer les sauvegardes automatiques lorsque vous créez une instance de base de données ou vous pouvez activer les sauvegardes en modifiant une instance de base de données existante. Pour plus d’informations, consultez Création d’une instance de base de données dans le Guide de l’utilisateur Amazon RDS. Créez un réplica en lecture pour l’instance de base de données. Pour plus d’informations, consultez Utilisation des réplicas en lecture dans le Guide de l’utilisateur Amazon RDS.
MySQL (externe)	Pour configurer la réplication chiffrée Pour répliquer des données en toute sécurité avec Aurora MySQL version 2, vous pouvez utiliser la réplication chiffrée. Note Si vous n’avez pas besoin d’utiliser la réplication chiffrée, vous pouvez ignorer ces étapes. Pour pouvoir utiliser la réplication chiffrée, vous devez impérativement disposer des éléments suivants : Le protocole SSL doit être activé sur la base de données source MySQL externe. Une clé client et un certificat client doivent être préparés pour le cluster de bases de données Aurora MySQL. Pendant la réplication chiffrée, le cluster de bases de données Aurora MySQL agit comme client du serveur de base de données MySQL. Les certificats et les clés privées du client Aurora MySQL sont au format .pem dans les fichiers. Vérifiez bien que vous êtes prêt à procéder à la réplication chiffrée : Si le protocole SSL n’est pas activé sur la base de données source MySQL externe et que vous ne disposez pas d’une clé client et d’un certificat client prêts, activez le protocole SSL sur le serveur de base de données MySQL et générez la clé client et le certificat client requis. Si le protocole SSL est activé sur la base de données source externe, fournissez une clé et un certificat client pour le cluster de bases de données Aurora MySQL. En leur absence, générez une nouvelle clé et un nouveau certificat pour le cluster de bases de données Aurora MySQL. Pour signer le certificat client, vous devez disposer de la clé d’autorité de certification utilisée pour configurer le protocole SSL sur la base de données source MySQL externe. Pour plus d’informations, consultez Création de certificats et clés SSL à l’aide d’openssl dans la documentation MySQL. Vous avez besoin du certificat de l’autorité de certification, de la clé client et du certificat client. Connectez-vous au cluster de bases de données Aurora MySQL en tant qu’utilisateur principal à l’aide du protocole SSL. Pour plus d’informations sur la connexion à un cluster de bases de données Aurora MySQL avec le protocole SSL, consultez Connexions TLS aux clusters de bases de données Aurora MySQL. Exécutez la procédure stockée mysql.rds_import_binlog_ssl_material pour importer les informations SSL dans le cluster de bases de données Aurora MySQL. Pour le paramètre ssl_material_value, insérez les informations des fichiers au format .pem pour le cluster de bases de données Aurora MySQL dans les données utiles JSON correctes. L’exemple suivant importe des informations SSL dans un cluster de bases de données Aurora MySQL. Dans les fichiers au format .pem, le code du corps est généralement plus long que le code du corps affiché dans l’exemple. call mysql.rds_import_binlog_ssl_material( '{"ssl_ca":"-----BEGIN CERTIFICATE----- AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE -----END CERTIFICATE-----\n","ssl_cert":"-----BEGIN CERTIFICATE----- AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE -----END CERTIFICATE-----\n","ssl_key":"-----BEGIN RSA PRIVATE KEY----- AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE -----END RSA PRIVATE KEY-----\n"}'); Pour plus d’informations, consultez mysql.rds_import_binlog_ssl_material et Connexions TLS aux clusters de bases de données Aurora MySQL. Note Après l’exécution de la procédure, les secrets sont stockés dans les fichiers. Pour supprimer les fichiers ultérieurement, vous pouvez exécuter la procédure stockée mysql.rds_remove_binlog_ssl_material. Pour activer la journalisation binaire sur une base de données MySQL externe Depuis un shell de commande, arrêtez le service mysql. sudo service mysqld stop Modifiez le fichier my.cnf (qui se trouve généralement sous /etc). sudo vi /etc/my.cnf Ajoutez les options log_bin et server_id à la section [mysqld]. L’option log_bin fournit un identifiant de nom de fichier pour les fichiers journaux binaires. L’option server_id fournit un identifiant unique pour le serveur dans les relations source/réplica. Si la réplication chiffrée n’est pas obligatoire, assurez-vous que la base de données MySQL externe est démarrée avec les journaux binaires activés et le protocole SSL désactivé. Les entrées correspondantes du fichier /etc/my.cnf pour les données non chiffrées sont les suivantes. log-bin=mysql-bin server-id=2133421 innodb_flush_log_at_trx_commit=1 sync_binlog=1 Si la réplication chiffrée est obligatoire, assurez-vous que la base de données MySQL externe est démarrée avec le protocole SSL et les journaux binaires activés. Les entrées du fichier /etc/my.cnf incluent les emplacements de fichier .pem pour le serveur de base de données MySQL. log-bin=mysql-bin server-id=2133421 innodb_flush_log_at_trx_commit=1 sync_binlog=1 # Setup SSL. ssl-ca=/home/sslcerts/ca.pem ssl-cert=/home/sslcerts/server-cert.pem ssl-key=/home/sslcerts/server-key.pem En outre, l’option sql_mode de votre instance de base de données MySQL doit être définie avec la valeur 0 ou ne pas être incluse dans votre fichier my.cnf. Une fois connecté à la base de données MySQL externe, enregistrez la position du journal binaire de la base de données MySQL externe. mysql> SHOW MASTER STATUS; Votre sortie doit ressembler à ce qui suit : +------------------+----------+--------------+------------------+-------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +------------------+----------+--------------+------------------+-------------------+ | mysql-bin.000031 | 107 | | | | +------------------+----------+--------------+------------------+-------------------+ 1 row in set (0.00 sec) Pour plus d’informations, consultez Setting the replication source configuration dans la documentation MySQL. Démarrez le service mysql. sudo service mysqld start

2. Conserver les journaux binaires sur la source de réplication jusqu’à ce qu’ils ne soient plus nécessaires

Lorsque vous utilisez la réplication des journaux binaires MySQL, Amazon RDS ne gère pas le processus de réplication. En conséquence, vous devez vous assurer que les fichiers des journaux binaires sur votre source de réplication sont conservés jusqu’après que les modifications ont été appliquées au réplica. Cette maintenance vous permet de restaurer votre base de données source en cas de panne.

Suivez les instructions suivantes pour conserver les journaux binaires de votre moteur de base de données.

Moteur de base de données	Instructions
Aurora MySQL	Pour conserver les journaux binaires sur un cluster de bases de données Aurora MySQL Vous n’avez pas accès aux fichiers journaux binaires pour un cluster de bases de données Aurora MySQL. En conséquence, vous devez choisir une période assez longue de conservation des fichiers journaux binaires sur votre source de réplication pour être assuré que les modifications ont été appliquées à votre réplica avant que le fichier journal binaire ne soit supprimé par Amazon RDS. Vous pouvez conserver les fichiers journaux binaires sur un cluster de bases de données Aurora MySQL pendant 90 jours maximum. Si vous configurez la réplication avec une base de données MySQL ou une instance de base de données RDS for MySQL comme réplica, et que la base de données pour laquelle vous créez un réplica est très volumineuse, choisissez une durée conséquente pour conserver les fichiers journaux binaires jusqu’à ce que la copie initiale de la base de données sur le réplica soit complète et que le retard du réplica ait atteint la valeur 0. Pour définir la période de rétention des journaux binaires, utilisez la procédure mysql.rds_set_configuration et spécifiez un paramètre de configuration 'binlog retention hours', ainsi que le nombre d’heures pendant lequel conserver les fichiers journaux binaires sur le cluster de bases de données. La valeur maximum pour Aurora MySQL versions 2.11.0 et ultérieures et version 3 est 2 160 (90 jours). L’exemple suivant définit la période de rétention des fichiers journaux binaires sur 6 jours : CALL mysql.rds_set_configuration('binlog retention hours', 144); Une fois la réplication démarrée, vous pouvez vérifier que les modifications ont été appliquées à votre réplica en exécutant la commande SHOW SLAVE STATUS (Aurora MySQL version 2) ou SHOW REPLICA STATUS (Aurora MySQL version 3) sur votre réplica et en vérifiant le champ Seconds behind master. Si la valeur du champ Seconds behind master est 0, il n’y a pas de décalage de réplica. Quand il n’y a pas de retard du réplica, réduisez la période pendant laquelle les fichiers journaux binaires sont conservés en définissant le paramètre de configuration binlog retention hours sur une durée plus petite. Si ce paramètre n’est pas spécifié, la valeur par défaut pour Aurora MySQL est 24 (1 jour). Si vous spécifiez une valeur supérieure à la valeur maximale pour 'binlog retention hours', Aurora MySQL utilise la valeur maximale.
RDS for MySQL	Pour conserver les journaux binaires sur une instance de base de données Amazon RDS Vous pouvez conserver les fichiers journaux binaires sur une instance de base de données Amazon RDS en définissant les heures de conservation des journaux binaires comme vous le feriez pour un cluster de bases de données Aurora MySQL (procédure décrite à la ligne précédente). Vous pouvez également conserver les fichiers journaux binaires sur une instance de base de données Amazon RDS en créant un réplica en lecture pour l’instance de base de données. Ce réplica en lecture a pour seul but temporaire et exclusif de conserver les fichiers journaux binaires. Une fois le réplica en lecture créé, appelez la procédure mysql.rds_stop_replication sur le réplica en lecture. Lorsque la réplication est arrêtée, Amazon RDS ne supprime aucun des fichiers journaux binaires sur la source de réplication. Après avoir configuré la réplication avec votre réplica permanent, vous pouvez supprimer le réplica en lecture lorsque le retard du réplica (champ Seconds behind master) entre votre source de réplication et votre réplica permanent atteint 0.
MySQL (externe)	Pour conserver les journaux binaires sur une base de données MySQL externe Comme les fichiers journaux binaires sur une base de données MySQL externe ne sont pas gérés par Amazon RDS, ils sont conservés jusqu’à ce que vous les supprimiez. Une fois la réplication démarrée, vous pouvez vérifier que les modifications ont été appliquées à votre réplica en exécutant la commande SHOW SLAVE STATUS (Aurora MySQL version 2) ou SHOW REPLICA STATUS (Aurora MySQL version 3) sur votre réplica et en vérifiant le champ Seconds behind master. Si la valeur du champ Seconds behind master est 0, il n’y a pas de décalage de réplica. Quand il n’y a pas de retard du réplica, vous pouvez supprimer les anciens fichiers journaux binaires.

3. Créer une copie ou un vidage de votre source de réplication

Vous utilisez un instantané, un clone ou un vidage de votre source de réplication pour charger une copie de référence de vos données sur votre réplica. Ensuite, vous commencez la réplication à partir de ce point.

Utilisez les instructions suivantes pour créer une copie ou un vidage de votre source de réplication pour votre moteur de base de données.

Moteur de base de données	Instructions
Aurora MySQL	Pour créer une copie d’un cluster de bases de données Aurora MySQL Utilisez l’une des méthodes suivantes : Restaurez un instantané de cluster de bases de données : Créez un instantané de cluster de bases de données de votre cluster de bases de données Amazon Aurora. Pour plus d’informations, consultez Création d’un instantané de cluster de bases de données. Créez un cluster de bases de données Aurora en procédant à une restauration à partir de l’instantané de cluster de bases de données que vous venez de créer. Veillez bien à conserver le même groupe de paramètres de base de données pour votre cluster de bases de données restauré que pour votre cluster de bases de données original. Ceci vous garantit que la journalisation binaire est activée pour la copie de votre cluster de bases de données. Pour plus d’informations, consultez Restauration à partir d’un instantané de cluster de bases de données. Clonez votre cluster de bases de données. Pour plus d’informations, consultez Clonage d’un volume pour un cluster de bases de données Amazon Aurora. Pour déterminer le nom et la position du fichier binlog Utilisez l’une des méthodes suivantes : Dans AWS Management Console : Choisissez Bases de données, puis choisissez l’instance principale (enregistreur) de votre nouveau cluster de bases de données Aurora afin d’en afficher les détails. Faites défiler l’écran jusqu’à Événements récents. Un message d’événement s’affiche pour indiquer le nom et la position du fichier journal binaire. Ce message d’événement est au format suivant. Binlog position from crash recovery is binlog-file-name binlog-position Enregistrez le nom et la position du fichier journal binaire lorsque vous commencez la réplication. Appelez la commande describe-events de l’AWS CLI, comme dans l’exemple suivant. aws rds describe-events { "Events": [ { "EventCategories": [], "SourceType": "db-instance", "SourceArn": "arn:aws:rds:us-west-2:123456789012:db:sample-restored-instance", "Date": "2016-10-28T19:43:46.862Z", "Message": "Binlog position from crash recovery is mysql-bin-changelog.000003 4278", "SourceIdentifier": "sample-restored-instance" } ] } Vérifiez dans le journal des erreurs MySQL la dernière position du fichier binlog MySQL. Pour créer un vidage d’un cluster de bases de données Aurora MySQL Si votre cible de réplica est une base de données MySQL externe ou une instance de base de données RDS for MySQL, vous devez créer un fichier de vidage à partir de votre cluster de bases de données Aurora. Veillez bien à exécuter la commande mysqldump sur la copie du cluster de bases de données Aurora que vous avez créée. Cela permet d’éviter le verrouillage des tables sources lors du vidage. Si le vidage était effectué directement sur le cluster de bases de données source, il serait nécessaire de verrouiller ces tables pour empêcher les écritures simultanées pendant le vidage. Connectez-vous à votre cluster de bases de données à l’aide d’un client MySQL. Émettez la commande mysqldump. Exemples : PROMPT> mysqldump --databases database_name --single-transaction --order-by-primary -r backup.sql -u local_users -p Une fois le fichier de vidage créé, vous pouvez supprimer la copie du cluster de bases de données.
RDS for MySQL	Pour créer un instantané d’une instance de base de données Amazon RDS Créez un réplica en lecture de votre instance de base de données Amazon RDS. Pour plus d’informations, consultez Création d’un réplica en lecture dans le Guide de l’utilisateur Amazon Relational Database Service. Connectez-vous à votre réplica en lecture et arrêtez la réplication en exécutant la procédure mysql.rds_stop_replication. Une fois le réplica en lecture arrêté, connectez-vous à ce réplica et exécutez la commande SHOW SLAVE STATUS (Aurora MySQL version 2) ou SHOW REPLICA STATUS (Aurora MySQL version 3). Extrayez le nom du fichier journal binaire actif du champ Relay_Master_Log_File et la position du fichier journal du champ Exec_Master_Log_Pos. Enregistrez ces valeurs lorsque vous démarrez la réplication. Pendant que le réplica en lecture reste à l’état Arrêté, créez un instantané de base de données du réplica en lecture. Pour plus d’informations, consultez Création d’un instantané de base de données dans le Guide de l’utilisateur Amazon Relational Database Service. Supprimez le réplica en lecture.
MySQL (externe)	Pour créer un vidage d’une base de données MySQL externe Avant de créer un vidage, vous devez vous assurer que l’emplacement du journal binaire du vidage est à jour avec les données de votre instance source. Pour ce faire, vous devez d’abord arrêter toutes les opérations d’écriture sur l’instance avec la commande suivante : mysql> FLUSH TABLES WITH READ LOCK; Créez un vidage de votre base de données MySQL à l’aide de la commande mysqldump comme illustré ci-après : PROMPT> sudo mysqldump --databases database_name --master-data=2 --single-transaction \ --order-by-primary -r backup.sql -u local_user -p Après avoir créé le vidage, déverrouillez les tables de votre base de données MySQL avec la commande suivante : mysql> UNLOCK TABLES;

4. Charger le vidage dans votre cible de réplica (si nécessaire)

Si vous prévoyez de charger les données à partir d’un vidage d’une base de données MySQL externe à Amazon RDS, vous souhaiterez peut-être créer une instance EC2 sur laquelle copier les fichiers de vidage. Vous pourrez ensuite charger les données dans votre cluster de bases de données ou votre instance de base de données à partir de cette instance EC2. À l’aide de cette approche, vous pouvez compresser les fichiers de vidage avant de les copier sur l’instance EC2 afin de réduire les coûts réseau associés à la copie des données sur Amazon RDS. Vous pouvez aussi chiffrer les fichiers de vidage pour sécuriser les données tandis qu’elles sont transférées sur le réseau.

Note

Si vous créez un cluster de bases de données Aurora MySQL comme cible de réplica, vous n’avez pas besoin de charger un fichier de vidage :

• Vous pourrez ultérieurement restaurer un cluster de bases de données pour créer le cluster. Pour plus d’informations, consultez Restauration à partir d’un instantané de cluster de bases de données.

• Vous pouvez cloner votre cluster de bases de données source pour créer un cluster de bases de données. Pour plus d’informations, consultez Clonage d’un volume pour un cluster de bases de données Amazon Aurora.

• Vous pouvez migrer les données d’un instantané d’instance de base de données vers un nouveau cluster de bases de données. Pour plus d’informations, consultez Migration de données vers un cluster de bases de données Amazon Aurora MySQL.

Utilisez les instructions suivantes pour charger le vidage de votre source de réplication dans votre cible de réplica pour votre moteur de base de données.

Moteur de base de données	Instructions
Aurora MySQL	Pour charger un vidage dans un cluster de bases de données Aurora MySQL Copiez la sortie de la commande mysqldump de votre source de réplication vers un emplacement qui peut aussi se connecter à votre cluster de bases de données Aurora MySQL. Connectez-vous à votre cluster de bases de données Aurora MySQL à l’aide de la commande mysql. Voici un exemple de. PROMPT> mysql -h host_name -port=3306 -u db_master_user -p À l’invite de commande mysql, exécutez la commande source et transmettez-lui le nom du fichier de vidage de votre base de données pour charger les données dans le cluster de bases de données Aurora MySQL, par exemple : mysql> source backup.sql;
RDS for MySQL	Pour charger un vidage dans une instance de base de données Amazon RDS Copiez la sortie de la commande mysqldump depuis votre source de réplication vers un emplacement qui peut aussi se connecter à votre instance de base de données MySQL. Connectez-vous à votre instance de base de données MySQL à l’aide de la commande mysql. Voici un exemple de. PROMPT> mysql -h host_name -port=3306 -u db_master_user -p A l’invite de commande mysql, exécutez la commande source et transmettez-lui le nom du fichier de vidage de votre base de données pour charger les données dans l’instance de base de données MySQL, par exemple : mysql> source backup.sql;
MySQL (externe)	Pour charger un vidage dans une base de données MySQL externe Vous ne pouvez pas charger un instantané de base de données ou un instantané de cluster de bases de données dans une base de données MySQL externe. A la place, vous devez utiliser la sortie de la commande mysqldump. Copiez la sortie de la commande mysqldump depuis votre source de réplication vers un emplacement qui peut aussi se connecter à votre base de données MySQL. Connectez-vous à votre base de données MySQL à l’aide de la commande mysql. Voici un exemple de. PROMPT> mysql -h host_name -port=3306 -u db_master_user -p À l’invite de commande mysql, exécutez la commande source et transmettez-lui le nom du fichier de vidage de votre base de données pour charger les données dans votre base de données MySQL. Voici un exemple de. mysql> source backup.sql;

5. Créer un utilisateur de réplication sur votre source de réplication

Créez un ID utilisateur sur la source qui est utilisé uniquement pour la réplication. L’exemple suivant concerne RDS for MySQL ou les bases de données sources MySQL externes.

mysql> CREATE USER 'repl_user'@'domain_name' IDENTIFIED BY 'password';

Pour les bases de données source Aurora MySQL, le paramètre de cluster de bases de données skip_name_resolve est défini sur 1 (ON) et ne peut pas être modifié. Vous devez donc utiliser une adresse IP pour l’hôte au lieu d’un nom de domaine. Pour plus d’informations, consultez skip_name_resolve dans la documentation MySQL.

mysql> CREATE USER 'repl_user'@'IP_address' IDENTIFIED BY 'password';

L’utilisateur nécessite les privilèges REPLICATION CLIENT et REPLICATION SLAVE. Accordez ces privilèges à l’utilisateur.

Si vous avez besoin d’utiliser la réplication chiffrée, demandez des connexions SSL à l’utilisateur de la réplication. Par exemple, vous pouvez utiliser l’une des instructions suivantes pour demander les connexions SSL sur le compte d’utilisateur repl_user.

GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'IP_address';

GRANT USAGE ON *.* TO 'repl_user'@'IP_address' REQUIRE SSL;

Note

Si REQUIRE SSL n’est pas inclus, la connexion de réplication peut revenir de façon silencieuse à une connexion non chiffrée.

6. Activer la réplication sur votre cible de réplica

Avant d’activer la réplication, nous vous recommandons de prendre un instantané manuel du cluster de bases de données Aurora MySQL ou de la cible de réplica de l’instance de base de données RDS for MySQL. Si un problème survient et que vous avez besoin de rétablir la réplication avec la cible de réplica du cluster de bases de données ou de l’instance de base de données, vous pouvez restaurer le cluster de bases de données ou l’instance de base de données à partir de cet instantané au lieu de devoir importer à nouveau les données dans votre cible de réplica.

Suivez les instructions suivantes pour activer la réplication pour votre moteur de base de données.

Moteur de base de données	Instructions
Aurora MySQL	Pour activer la réplication à partir d’un cluster de bases de données Aurora MySQL Trouvez le point de départ de la réplication. Vous avez besoin du nom du fichier journal binaire et de la position du journal binaire. Si la cible de réplication de votre cluster de bases de données a été créée à partir de ce qui suit : Instantané du cluster de bases de données ou clone : récupérez le nom et la position du fichier binlog à partir des événements récents de votre nouveau cluster de bases de données, comme indiqué dans 3. Créer une copie ou un vidage de votre source de réplication. Instantané de la base de données : vous avez extrait le nom et la position du fichier de journal binaire à partir de la commande SHOW SLAVE STATUS (Aurora MySQL version 2) ou SHOW REPLICA STATUS (Aurora MySQL version 3) lors de la création de l’instantané de votre source de réplication. Connectez-vous au cluster de bases de données et exécutez les procédures suivantes pour démarrer la réplication avec votre source de réplication à l’aide du nom du fichier journal binaire et de l’emplacement de l’étape précédente : mysql.rds_set_external_source (Aurora MySQL version 3) mysql.rds_set_external_master (Aurora MySQL version 2) mysql.rds_start_replication (toutes les versions) L’exemple suivant concerne Aurora MySQL version 3. CALL mysql.rds_set_external_source ('mydbinstance.123456789012.us-east-1.rds.amazonaws.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0); CALL mysql.rds_start_replication; Pour utiliser le chiffrement SSL, définissez la valeur finale sur 1 au lieu de 0.
RDS for MySQL	Pour activer la réplication à partir d’une instance de base de données Amazon RDS Si votre cible de réplica d’instance de base de données a été créé à partir d’un instantané de base de données, vous avez besoin du fichier journal binaire et de la position du journal binaire qui sont le point de départ de la réplication. Vous avez extrait ces valeurs à partir de la commande SHOW SLAVE STATUS (Aurora MySQL version 2) ou SHOW REPLICA STATUS (Aurora MySQL version 3) lors de la création de l’instantané de votre source de réplication. Connectez-vous à l’instance de base de données et appelez les procédures mysql.rds_set_external_master (Aurora MySQL version 2) ou mysql.rds_set_external_source (Aurora MySQL version 3) et mysql.rds_start_replication pour démarrer la réplication avec votre source de réplication. Utilisez le nom du fichier journal binaire et l’emplacement à partir de l’étape précédente. Voici un exemple. CALL mysql.rds_set_external_master ('mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0); CALL mysql.rds_start_replication; Pour utiliser le chiffrement SSL, définissez la valeur finale sur 1 au lieu de 0.
MySQL (externe)	Pour activer la réplication à partir d’une base de données MySQL externe Extrayez le fichier journal binaire et la position du journal binaire qui sont le point de départ de la réplication. Vous avez extrait ces valeurs à partir de la commande SHOW SLAVE STATUS (Aurora MySQL version 2) ou SHOW REPLICA STATUS (Aurora MySQL version 3) lors de la création de l’instantané de votre source de réplication. Si votre cible de réplica MySQL externe a été renseignée à partir de la sortie de la commande mysqldump avec l’option --master-data=2, le fichier journal binaire et la position du journal binaire sont inclus dans la sortie. Voici un exemple. -- -- Position to start replication or point-in-time recovery from -- -- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.000031', MASTER_LOG_POS=107; Connectez-vous à la cible de réplica MySQL externe et exécutez CHANGE MASTER TO et START SLAVE (Aurora MySQL version 2) ou START REPLICA (Aurora MySQL version 3) pour démarrer la réplication avec votre source de réplication à l’aide du nom du fichier journal binaire et de l’emplacement de l’étape précédente, par exemple : CHANGE MASTER TO MASTER_HOST = 'mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com', MASTER_PORT = 3306, MASTER_USER = 'repl_user', MASTER_PASSWORD = 'password', MASTER_LOG_FILE = 'mysql-bin-changelog.000031', MASTER_LOG_POS = 107; -- And one of these statements depending on your engine version: START SLAVE; -- Aurora MySQL version 2 START REPLICA; -- Aurora MySQL version 3

Si la réplication échoue, cela peut entraîner une augmentation importante des I/O involontaires sur le réplica, ce qui peut dégrader les performances. Si la réplication échoue ou n’est plus nécessaire, vous pouvez exécuter la procédure stockée mysql.rds_reset_external_master (Aurora MySQL version 2) ou mysql.rds_reset_external_source (Aurora MySQL version 3) pour supprimer la configuration de réplication.

Définition d’une position où arrêter la réplication vers un réplica en lecture

Dans Aurora MySQL versions 3.04 et ultérieures, vous pouvez démarrer la réplication, puis l’arrêter à la position spécifiée dans le fichier journal binaire en utilisant la procédure stockée mysql.rds_start_replication_until (Aurora MySQL version 3).

Pour démarrer la réplication vers un réplica en lecture et l’arrêter à une position donnée

1. À l’aide d’un client MySQL, connectez-vous au cluster de bases de données Aurora MySQL du réplica en tant qu’utilisateur principal.

2. Exécutez la procédure stockée mysql.rds_start_replication_until (Aurora MySQL version 3).

   L’exemple suivant lance la réplication et réplique les modifications jusqu’à ce qu’il atteigne la position 120 dans le fichier journal binaire mysql-bin-changelog.000777. Dans un scénario de reprise après sinistre, nous supposons que cette position 120 est juste avant le sinistre.

   call mysql.rds_start_replication_until(
     'mysql-bin-changelog.000777',
     120);
   

La réplication s’arrête automatiquement lorsque le point d’arrêt est atteint. L’événement RDS suivant est généré: Replication has been stopped since the replica reached the stop point specified by the rds_start_replication_until stored procedure.

Si vous utilisez une réplication basée sur des identifiants de transaction globaux (GTID), utilisez la procédure stockée mysql.rds_start_replication_until_gtid (Aurora MySQL version 3) au lieu de la procédure stockée mysql.rds_start_replication_until (Aurora MySQL version 3). Pour en savoir plus sur les réplications basées sur des identifiants de transaction globaux (GTID), consultez Utilisation de la réplication basée sur des identifiants de transaction globaux (GTID).

7. Surveiller votre réplica

Lorsque vous configurez la réplication MySQL avec un cluster de bases de données Aurora MySQL, vous devez surveiller les événements de basculement du cluster de bases de données Aurora MySQL quand il s’agit de la cible de réplica. En cas de basculement, le cluster de bases de données qui est votre cible de réplica peut alors être recréé sur un nouvel hôte avec une adresse réseau différente. Pour plus d’informations sur la surveillance des événements de basculement, consultez Utiliser la notification d’événements d’Amazon RDS.

Vous pouvez aussi surveiller à quelle distance la cible de réplica se trouve de la source de réplication en vous connectant à la cible de réplica et en exécutant la commande SHOW SLAVE STATUS (Aurora MySQL version 2) ou SHOW REPLICA STATUS (Aurora MySQL version 3). Dans la sortie de la commande, le champ Seconds Behind Master vous indique à quelle distance la cible de réplica se trouve de la source de réplication.

Important

Si vous mettez à niveau votre cluster de bases de données et que vous spécifiez un groupe de paramètres personnalisé, assurez-vous de redémarrer manuellement le cluster une fois la mise à niveau terminée. Cela obligera le cluster à utiliser vos nouveaux paramètres personnalisés et redémarrera la réplication des journaux binaires.

Synchronisation des mots de passe entre la source de réplication et la cible

Lorsque vous modifiez des comptes d’utilisateur et des mots de passe sur la source de réplication à l’aide d’instructions SQL, ces modifications sont automatiquement répliquées sur la cible de réplication.

Si vous utilisez la AWS Management Console, la AWS CLI, ou l’API RDS pour modifier le mot de passe principal sur la source de réplication, ces modifications ne sont pas automatiquement répliquées sur la cible de réplication. Si vous souhaitez synchroniser l’utilisateur principal et le mot de passe principal entre les systèmes source et cible, vous devez effectuer vous-même la même modification sur la cible de réplication.