Comment créer un réplica entre régions MySQL Amazon RDS dans un autre compte AWS ?

Brève description

Vous pouvez créer un réplica Amazon RDS pour MySQL dans une autre région AWS et un compte à partir de l'instance de base de données source pour les cas d'utilisation suivants :

• Amélioration de la reprise après un sinistre
• Évolutivité horizontale à l'échelle mondiale
• Migration entre régions et comptes AWS

Remarque : Il n'existe aucun moyen direct de créer un réplica entre régions dans un autre compte AWS à l'aide de la console Amazon RDS ou de l'interface de la ligne de commande (AWS CLI). Les étapes décrites dans cet article configurent une réplication externe basée sur un journal binaire entre deux instances RDS MySQL dans différents comptes ou régions AWS.

Résolution

Pour créer un réplica entre régions pour MySQL Amazon RDS dans un autre compte AWS, procédez comme suit.

Remarque : Le compte A contient l'instance RDS principale pour MySQL dans la région source. Le compte B contient le réplica RDS pour MySQL dans la région cible.

1.    Dans le compte A (instance Amazon RDS pour MySQL principale), assurez-vous que la journalisation binaire est activée. Par défaut, les sauvegardes automatisées et la journalisation binaire sont activées dans RDS pour MySQL. La journalisation binaire est activée chaque fois que les sauvegardes automatisées sont activées.

Remarque : Une panne se produit si vous modifiez la période de rétention des sauvegardes de « 0 » à une valeur différente de zéro, ou vice versa.

2.    Mettez à jour la période de conservation des journaux binaires à l'aide de la commande suivante :

mysql>  CALL mysql.rds_set_configuration(name,value);

Astuce : choisissez une période pendant laquelle les fichiers journaux binaires de votre source de réplication sont conservés suffisamment longtemps pour que les modifications soient appliquées avant la suppression. Amazon RDS conserve les fichiers journaux binaires sur une instance MySQL pendant 168 heures (7 jours). Pour plus d'informations, consultez mysql.rds_set_configuration.

Par exemple, la syntaxe suivante définit la période de rétention des journaux binaires sur 24 heures :

mysql> call mysql.rds_set_configuration('binlog retention hours', 24);

3.    Créez un utilisateur de réplication sur l'instance principale dans le compte A, puis accordez les privilèges obligatoires :

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

4.    Accordez les privilèges RÉPLICATION CLIENT et RÉPLICATION ESCLAVE (obligatoires) à l'utilisateur créé à l'étape 3 :

mysql> GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO  'repl_user'@'<domain_name>';

5.    Créez un réplica en lecture entre régions dans le compte principal (compte A) avec la région cible sélectionnée.

6.    Connectez-vous à l'instance de réplica créée dans le compte A. Vérifiez ensuite que le réplica est rattrapé par l'instance de base de données primaire :

mysql> SHOW SLAVE STATUS\G

Remarque : vérifiez que la valeur Seconds_Behind_Master est « 0 ». Lorsque la valeur est « 0 », le réplica est rattrapé sur l'instance de base de données primaire. Pour plus d'informations, consultez la section Surveillance de la réplication en lecture.

7.    Une fois que le réplica en lecture est rattrapé sur l'instance de base de données primaire, arrêtez la réplication sur l'instance de réplica créée à l'étape 5. Pour arrêter la réplication, utilisez la syntaxe suivante :

mysql> call mysql.rds_stop_replication();

8.    Exécutez la commande SHOW SLAVE STATUS sur le réplica, puis enregistrez les valeurs de sortie pour Relay_Master_Log_File et Exec_Master_Log_Pos. Les valeurs Relay_Master_Log_File et Exec_Master_Log_Pos sont les coordonnées de votre journal binaire, qui sont utilisées pour configurer la réplication externe dans les étapes ultérieures.

9.    Créez un instantané de base de données de votre instance de réplica dans le compte A.

(Facultatif) Vous pouvez également utiliser un outil natif qui génère des sauvegardes logiques (comme mysqldump) pour exporter les données de l'instance de réplica dans le compte A. L'outil natif peut ensuite être utilisé pour importer les données vers une instance RDS MySQL nouvellement créée de la même version dans le compte B. Avec cette approche, vous n'avez pas besoin de copier et de partager des instantanés ou des clés AWS KMS entre les deux comptes. Si vous décidez d'utiliser cette approche, passez directement à l'étape 12 pour configurer l'accès au réseau et la réplication entre les deux instances. Avant d'adopter cette approche, vous devez importer des données dans l'instance Amazon RDS for MySQL du compte B.

10.    Partager l'instantané de base de données avec le compte B.

Remarque : Si votre instantané de base de données est chiffré, la clé AWS KMS utilisée pour chiffrer l'instantané doit être partagée avec le compte cible. Pour plus d'informations, consultez la section Partage d'un instantané chiffré .

11.    Restaurer l'instantané de base de données dans le compte B.

Remarque : une instance de base de données ne peut pas être restaurée à partir d'un instantané chiffré partagé. Effectuez plutôt une copie de l'instantané de base de données et restaurez l'instance de base de données à partir de la version copiée.

12.    Configurez l'accès réseau entre le compte A (le compte source) et le compte B (compte de destination). L'accès réseau permet au trafic de circuler entre les comptes source et de destination.

13.    Configurez les règles du groupe de sécurité entrant pour l'instance de base de données primaire du compte A. Cette configuration permet au trafic de circuler sur l'Internet public à partir de l'instance RDS MySQL nouvellement créée dans le compte B (le compte de destination). Les groupes de sécurité protègent votre instance Amazon RDS pour MySQL.

Pour le trafic de réplication privée, une connexion d'appairage de VPC doit être créée et acceptée entre les deux comptes AWS.

14.    Configurez la réplication externe sur votre instance cible dans le compte B. Utilisez repl_user dans la commande en tant que paramètre. Remarque : La commande CALL mysql.rds_set_external_master doit être exécutée par un utilisateur de base de données avec des privilèges d'exécution de commande.

mysql> CALL mysql.rds_set_external_master (
  host_name
  , host_port
  , replication_user_name
  , replication_user_password
  , mysql_binary_log_file_name
  , mysql_binary_log_file_location
  );

Par exemple :

mysql> CALL mysql.rds_set_external_master (mytestinnstance.us-east-1.rds.amazonaws.com', 3306, 'repl_user', '<password>', 'mysql-bin-changelog.000031', 107, 0);

mytestinnstance.us-east-1.rds.amazonaws.com : point de terminaison d'instance principale 3306 : port d'instance principale repl_user : nom d'utilisateur de réplication créé à l'étape 3 mot de passe : mot de passe utilisateur créé à l'étape 3 mysql-bin-changelog.000031 : nom du fichier journal binaire à partir de la sortie de l'étape 8 107 : position du journal binaire à partir de la sortie de l'étape 8

15.    Démarrez la réplication sur l'instance restaurée dans le compte B :

CALL mysql.rds_start_replication;

Voici un exemple de sortie :

+-------------------------+
| Message                 |
+-------------------------+
| Slave running normally. |
+-------------------------+

16.    Exécutez la commande suivante sur l'instance du compte B pour vérifier l'état de votre réplication :

mysql> show replica status \G

Remarque : pour MySQL version 8.0.22 et supérieure, SHOW SLAVE STATUS est obsolète et SHOW REPLICA STATUS est disponible. Pour plus d'informations, consultez la section Vérification de l'état de la réplication sur le site web de MySQL.

17.    Supprimez le réplica (qui a fait office d'instance intermédiaire) créé à l'étape 5. Ce réplica a été utilisé pour extraire les coordonnées du journal binaire sans avoir à suspendre les écritures sur l'instance primaire du compte A.

Remarques sur la réplication entre régions

Envisagez les approches suivantes pour la réplication entre régions :

• Une instance de base de données source peut avoir des réplicas en lecture entre régions dans plusieurs régions AWS. Pour plus d'informations, consultez Création d'un réplica en lecture dans une autre région AWS.
• Vous pouvez vous attendre à un délai plus élevé pour tout réplica en lecture qui se trouve dans une région AWS différente de celle de l'instance source. Ce décalage est dû à des canaux réseau plus longs entre les centres de données régionaux. Pour plus d'informations sur le retard de réplication, consultez la rubrique Surveillance de la réplication en lecture.
• Les données transférées pour la réplication entre régions sont facturées pour le transfert de données Amazon RDS. Pour plus d'informations sur ces frais de transfert de données, consultez la rubrique Coûts de réplication entre régions.

---

Informations connexes

Réplicas en lecture entre régions pour Amazon RDS for MySQL