Aurora MySQL 8.4.8 ajoute la réplication différée pour survivre à un DROP TABLE accidentel

3 septembre 2026. AWS publie Aurora MySQL 8.4.8, et avec elle deux fonctions de réplication que les équipes de base de données attendaient : la réplication différée et la réplication multi-source. La première est discrète — un réplica qui applique volontairement les changements avec une heure de retard — mais elle résout un incident que rien d’autre ne couvre : la suppression accidentelle. Pourquoi c’est important : un DROP TABLE n’est pas une panne, c’est une instruction valide, exécutée correctement et répliquée fidèlement sur toutes vos copies en quelques millisecondes. Seul un réplica différé n’a pas encore été prévenu.

La panne que rien d’autre ne couvre

Demandez-vous ce qui se passe aujourd’hui si quelqu’un exécute un DROP TABLE contre la production à 14 h 12 et que l’erreur est remarquée à 14 h 40. La réponse honnête, dans la plupart des environnements, est une restauration à un instant donné (point-in-time restore) : un nouveau cluster, une attente proportionnelle à la taille de la base, un basculement, et un RTO mesuré en heures pendant lesquelles l’application est en panne ou sert des données périmées.

Le piège est que tous les mécanismes de haute disponibilité reproduisent la faute. Multi-AZ n’aide pas : la déclaration est déjà sur l’autre instance. Un réplica de lecture n’aide pas non plus : il est répliqué en quelques millisecondes. Chaque copie que vous possédez a déjà appliqué l’instruction destructrice. La réplication différée est la seule copie qui n’a pas encore reçu l’ordre.

Un retard n’est pas du lag : c’est un budget de détection

Le principe est simple. Vous fixez un retard — disons 3 600 secondes, une heure — et le réplica applique chaque changement une heure après la source. Cela ressemble à un défaut jusqu’à ce qu’on comprenne la panne qu’il traite.

L’écart entre les deux timelines n’est pas du lag. C’est le temps dont vous disposez pour remarquer l’erreur. Fixez target delay à 3 600 et vous venez d’acheter exactement une heure : pendant cette fenêtre, l’instruction destructrice existe sur la source mais n’a pas atteint le réplica, et toute la récupération reste disponible. Passé ce délai, le réplica a lui aussi appliqué l’instruction, et vous revenez à la restauration depuis un instantané.

Le chiffre n’est donc pas un réglage de performance, c’est la réponse à une question que la plupart des équipes n’ont jamais mesurée : combien de temps nous faut-il pour remarquer une instruction destructrice ? Une heure est le défaut courant et reste optimiste pour une corruption découverte par un signalement en aval. Vingt-quatre heures se défendent pour une base dont les dégâts n’apparaissent qu’à la réconciliation du lendemain — mais coûtent plus cher, comme on le verra.

La récupération tient en trois appels de procédure

La séquence documentée est courte, et l’étape du milieu est la plus intéressante. Elle repose sur trois procédures stockées :

-- 1. Arrêter la réplication avant que le changement destructeur ne soit appliqué
CALL mysql.rds_stop_replication;

-- 2. Rejouer le binlog jusqu'à la position juste avant la faute
CALL mysql.rds_start_replication_until('nom-du-fichier-binlog', position);
-- En réplication basée sur GTID :
CALL mysql.rds_start_replication_until_gtid('identifiant-gtid');

-- 3. Promouvoir le réplica en instance autonome (via la console ou l'API)

L’étape du milieu est ce qui rend la méthode supérieure à une restauration à un instant donné plutôt que simplement plus rapide. Vous ne choisissez pas un horodatage en espérant tomber juste : vous rejouez le journal binaire jusqu’à une position nommée et vous vous arrêtez là. Et AWS émet un événement RDS précis quand le réplica atteint ce point, ce qui rend l’arrêt observable plutôt que déduit.

Le gain opérationnel tient dans une clause que AWS utilise pour décrire la fonction : la récupération se fait sans effectuer de restauration complète de la base. La base est déjà en marche, déjà chaude. C’est la différence entre un RTO en heures et un RTO en minutes.

Le piège : une configuration invisible pour l’IaC

C’est ici que la fonction peut mordre plus tard, et la documentation le dit sans détour : la réplication différée se configure uniquement par procédures stockées. Ni la console, ni la CLI, ni l’API RDS ne l’exposent.

Deux appels selon le moment. Avant de créer les réplicas, exécutez sur la source la configuration suivante, et tout réplica créé ensuite en hérite :

-- Définit le retard hérité par les futurs réplicas
CALL mysql.rds_set_configuration('target delay', 3600);

Pour un réplica déjà existant, arrêtez la réplication, appliquez le retard, puis relancez-la :

CALL mysql.rds_stop_replication;
CALL mysql.rds_set_source_delay(3600);
CALL mysql.rds_start_replication;

Comme aucun de ces appels n’est une opération d’API, le retard n’apparaît ni dans l’état Terraform, ni dans un modèle CloudFormation, ni dans AWS Config, ni dans aucun rapport de dérive. Un réplica reconstruit par un pipeline revient sans retard, et rien nulle part ne le signale : la ressource existe, elle est saine, et elle n’est plus, silencieusement, la chose que votre plan de récupération suppose. Ajoutez un contrôle planifié qui lit le retard courant et alerte s’il est nul ou absent — c’est la seule défense contre cette dérive invisible.

La réplication multi-source, l’autre nouveauté

La réplication multi-source est une histoire plus modeste mais réelle : un cluster peut désormais répliquer depuis plusieurs sources à la fois. Les usages nommés par AWS sont la fusion de shards et l’agrégation de bases régionales ou départementales vers un point central pour le reporting et les sauvegardes. Concrètement, cela supprime une catégorie d’ETL qui n’existe que pour déplacer des lignes entre instances MySQL.

Ce qu’il faut mettre en place

Quatre règles évitent les échecs les plus fréquents, par ordre décroissant de probabilité d’oubli :

• Choisissez le retard à partir de votre temps de détection mesuré, pas d’un chiffre rond. Le retard est votre budget de détection ; si personne ne sait combien de temps il vous faut aujourd’hui, c’est la première chose à mesurer.
• Ne faites pas faire un second métier à ce réplica. Pas de disaster recovery, pas de reporting, pas de montée en charge en lecture : chacun veut des données à jour, et celui-ci est délibérément en retard. Promouvoir le réplica différé lors d’une panne de région, c’est jeter la fenêtre de retard.
• Alertez sur la dérive du retard, pas sur le lag. Un réplica différé a toujours l’air en retard ; l’alarme qu’il faut, c’est celle qui se déclenche quand le lag réel ne correspond plus au retard voulu.
• Répétez le chemin rejeu-et-promotion. Retrouver une position de binlog sous pression est l’étape qui échoue ; la répéter ne coûte rien sur la source.

La marge existe si vous en voulez plusieurs : jusqu’à 15 réplicas de lecture par instance dans une même région. Deux retards — un court pour les erreurs vite repérées, un long pour les autres — est un motif défendable quand les données le justifient.

Verdict

Si votre pire incident de base réaliste est une mauvaise instruction plutôt qu’une panne d’infrastructure — et c’est le cas de la plupart des environnements matures — et que votre réponse actuelle à un DROP TABLE est une restauration avec un RTO en heures, adoptez la réplication différée : elle convertit ce scénario en minutes pour le coût d’une seule instance. Si votre base est assez petite pour qu’une restauration à un instant donné tienne déjà votre RTO, passez : l’instance dédiée est de l’argent réel, et le gain est proportionnel à la durée de vos restaurations. Si vous êtes dans un environnement réglementé, notez que le réplica détient un état antérieur des données : une demande d’effacement exécutée sur la source n’est, pendant toute la durée du retard, pas exécutée sur le réplica.

La réplication différée est aussi l’un des rares contrôles efficaces contre un acteur interne muni d’identifiants légitimes : rien dans IAM ne distingue un DELETE autorisé d’un DELETE malveillant, mais le retard vous laisse le temps d’arriver à une conclusion différente avant que la seconde copie soit touchée. À condition que le réplica différé soit accessible à moins de monde que la source, et que sa promotion passe par la même approbation que tout autre acte de break-glass.

Références

• AWS What’s New — Aurora MySQL prend en charge la réplication multi-source et différée, septembre 2026
• AWS Documentation — Configuring delayed replication with MySQL
• AWS Documentation — MySQL stored procedures for replicating
• AWS Documentation — Promoting a read replica to be a standalone DB instance