Configurer la réplication différée avec Amazon Aurora MySQL

Vous pouvez utiliser la réplication différée comme stratégie de reprise après sinistre avec Aurora MySQL. Avec la réplication retardée, vous spécifiez la durée minimale, en secondes, pour retarder la réplication de la source vers la réplique de lecture. En cas de sinistre, par exemple la suppression accidentelle d'une table, vous appliquez la procédure suivante pour reprendre rapidement après le sinistre :

1. Arrêtez la réplication vers la réplique en lecture avant que la source n'envoie la modification à l'origine du sinistre. Utilisez la procédure stockée mysql.rds_stop_replication pour arrêter la réplication.

2. Arrêtez la réplication et précisez qu'elle doit s'arrêter automatiquement à une position donnée dans un fichier journal. Vous indiquez une position juste avant le sinistre grâce à la procédure stockée mysql.rds_start_replication_until(Aurora MySQL version 3).

3. Faites de la réplique lue le nouveau cluster de bases de données source en suivant les instructions figurant dansPromotion d’un réplica en lecture en cluster de bases de données pour Aurora MySQL.

Note

Aurora MySQL prend en charge la réplication différée pour les versions 8.4.8 et supérieures.

• Utilisez des procédures stockées pour configurer la réplication retardée. Vous ne pouvez pas configurer la réplication différée avec l' Console de gestion AWS API Amazon RDS ou l'API Amazon RDS. AWS CLI

• Vous pouvez utiliser la réplication basée sur les identificateurs de transaction globaux (GTID) dans une configuration de réplication différée sur Aurora MySQL version 8.4.8 et supérieure.

• Si vous utilisez GTID-based la réplication, utilisez la procédure mysql.rds_start_replication_until_gtid (Aurora MySQL version 3) stockée au lieu de la procédure mysql.rds_start_replication_until(Aurora MySQL version 3) stockée.

• Aurora MySQL prend en charge la réplication multisource avec jusqu'à 15 canaux. Utilisez les variantes de _for_channel procédure pour configurer la réplication différée sur des canaux spécifiques.

Cas d'utilisation de la réplication différée

La réplication différée sur Aurora MySQL s'applique à la réplication basée sur un journal binaire. Cela inclut la réplication depuis un cluster de base de données Aurora MySQL Writer vers une réplique binlog, depuis une source MySQL externe vers un cluster de bases de données Aurora MySQL ou via des canaux de réplication multi-sources. Elle ne s'applique pas aux réplicas Aurora au sein d'un seul cluster de base de données, car ceux-ci sont lus depuis le stockage du cluster partagé plutôt que depuis le journal binaire. Les cas d'utilisation courants sont les suivants :

• Reprise après sinistre suite à une erreur de l'opérateur  : gérez une réplique binlog qui est en retard par rapport à la source d'un intervalle défini. Si une instruction destructive est exécutée involontairement (par exemple, si vous supprimez une table), arrêtez la réplication sur la réplique différée avant que la source n'applique la modification. Passez ensuite à la veille de l'événement en utilisant mysql.rds_start_replication_until(Aurora MySQL version 3) oumysql.rds_start_replication_until_gtid (Aurora MySQL version 3). Enfin, faites la promotion de la réplique. Cette approche fournit un chemin de restauration plus rapide que la restauration instantanée, qui nécessite une restauration après incident et une relecture du journal binaire.

• Protection contre la corruption logique des données  : une réplication différée protège également contre un déploiement d'applications défectueux ou une migration qui corrompt progressivement les données. Comme la réplique conserve son état antérieur à la corruption pendant toute la durée du délai, vous pouvez la récupérer avant que les transactions défectueuses ne soient appliquées.

• Version majeure et blue/green mises à niveau  : conservez une réplique retardée du binlog lors d'une mise à niveau ou d'un blue/green déploiement à titre de filet de sécurité, afin de pouvoir revenir à un état vérifié si la mise à niveau pose des problèmes.

• Capture de données de modification (CDC) depuis une source externe — Lorsque vous ingérez des modifications dans un cluster de bases de données Aurora MySQL à partir d'une source MySQL externe, un délai intentionnel vous permet de contrôler la mémoire tampon avant que les modifications ne soient appliquées en aval.

• Inspection historique sans restauration  : interrogez la réplique différée pour voir à quoi ressemblaient vos données à une date antérieure. Cela est utile pour déboguer, auditer ou étudier ce qui a changé, sans provisionner de clone ni exécuter de restauration instantanée.

• Tester le comportement de l'application en cas de retard de réplication  : utilisez un délai artificiellement gonflé pour valider le comportement de votre application lorsqu'une réplique est en retard et pour exécuter des tests de régression pour les conditions sensibles au décalage, sans avoir à générer une charge importante pour reproduire le décalage.

Configuration de la réplication externe avec retard

Pour configurer une source externe avec réplication différée, utilisez la procédure mysql.rds_set_source_external_with_delay (Aurora MySQL version 8.4.8 et supérieure) stockée. Pour plus d'informations sur toutes les procédures stockées de réplication, consultezConfiguration, démarrage et arrêt de la réplication des journaux binaires (binlog).

Exemple (chaîne par défaut) :

CALL mysql.rds_set_external_source_with_delay(
  'source-host.example.com',
  3306,
  'repl_user',
  'repl_password',
  'mysql-bin-changelog.000001',
  120,
  0,
  3600);

Exemple (chaîne spécifique) :

CALL mysql.rds_set_external_source_with_delay_for_channel(
  'source-host.example.com',
  3306,
  'repl_user',
  'repl_password',
  'mysql-bin-changelog.000001',
  120,
  0,
  3600,
  'channel_1');

Paramètres :

host_name

Le nom d'hôte ou l'adresse IP de la source externe.

host_port

Numéro de port de la source externe.

replication_user_name

L'utilisateur de réplication sur la source externe.

replication_user_password

Le mot de passe de l'utilisateur de réplication.

mysql_binary_log_file_name

Nom du fichier journal binaire de la source externe.

mysql_binary_log_file_location

Position dans le fichier journal binaire pour commencer la réplication.

ssl_encryption

Définissez ce paramètre 1 pour activer le cryptage SSL pour la connexion de réplication ou 0 pour désactiver le cryptage SSL.

delay

Délai minimal en secondes (0 à 259 200).

channel

(variante for_channel uniquement) Le nom du canal pour la réplication multi-sources.

Contraintes :

• Aurora MySQL prend en charge un maximum de 15 canaux de réplication.

• Chaque canal doit être répliqué à partir d'une source différente (combinaison hôte/port).

• Le délai doit être compris entre 0 et 259 200 secondes (72 heures).

• Arrêtez la réplication avant de modifier la configuration des canaux.

Modifier la réplication différée pour une réplique en lecture existante

Pour modifier la réplication retardée pour un réplica en lecture existant, exécutez la procédure stockée mysql.rds_set_source_delay (Aurora MySQL version 8.4.8 et supérieure). Pour plus d'informations sur toutes les procédures stockées de réplication, consultezConfiguration, démarrage et arrêt de la réplication des journaux binaires (binlog).

Pour modifier la réplication différée pour une réplique en lecture existante, procédez comme suit :

1. À l'aide d'un client MySQL, connectez-vous à la réplique en lecture en tant qu'administrateur.

2. Utilisez la procédure stockée mysql.rds_stop_replication pour arrêter la réplication.

3. Exécutez la procédure stockée mysql.rds_set_source_delay (Aurora MySQL version 8.4.8 et supérieure).

4. Utilisez la procédure stockée mysql.rds_start_replication pour lancer la réplication.

Exemple (chaîne par défaut) :

CALL mysql.rds_set_source_delay(3600);

Exemple (chaîne spécifique) :

CALL mysql.rds_set_source_delay_for_channel(3600, 'channel_1');

Cela indique que la réplication vers la réplique lue est retardée d'au moins une heure (3 600 secondes). La valeur du délai doit être comprise entre 0 et 259 200 secondes (72 heures).

Note

Arrêtez la réplication avant de définir le délai. Si la réplication est en cours, vous recevez un message d'erreur vous demandant d'appeler mysql.rds_stop_replication (ou mysql.rds_stop_replication_for_channel d'appeler un canal spécifique) en premier.

Définir un emplacement pour arrêter la réplication vers un réplica en lecture

Après avoir arrêté la réplication vers le réplica en lecture, 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 et l'arrêter à un emplacement spécifique, procédez comme suit :

1. À l'aide d'un client MySQL, connectez-vous à la réplique en lecture en tant qu'administrateur.

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

Exemple :

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

Cela lance la réplication et réplique les modifications jusqu'à ce qu'elles atteignent l'emplacement 120 dans le mysql-bin-changelog.000777 fichier journal binaire. Dans un scénario de reprise après sinistre, supposons que l'emplacement 120 se trouve juste avant le sinistre.

La réplication s'arrête automatiquement lorsque Aurora MySQL atteint le point d'arrêt. Aurora MySQL génère l'événement suivant :Replication has been stopped since the replica reached the stop point specified by the rds_start_replication_until stored procedure.

Si vous utilisez GTID-based la réplication, utilisez plutôt la procédure mysql.rds_start_replication_until_gtid (Aurora MySQL version 3) stockée.

Promouvoir une réplique lue

Une fois la réplication arrêtée, dans un scénario de reprise après sinistre, vous pouvez promouvoir un réplica en lecture comme nouveau cluster de base de données source. Pour de plus amples informations sur la promotion d'un réplica en lecture, veuillez consulter Promotion d’un réplica en lecture en cluster de bases de données pour Aurora MySQL.

Rubriques associées

• Pour une référence complète de toutes les procédures stockées de réplication, consultezConfiguration, démarrage et arrêt de la réplication des journaux binaires (binlog).