Tous les produits
Search
Centre de documentation

ApsaraDB RDS:Optimisation du délai de réplication DDL

Dernière mise à jour :Aug 25, 2026

Les instructions DDL longues, telles que ALTER TABLE sur des tables volumineuses, peuvent bloquer une base de données secondaire pendant plusieurs centaines de secondes en attendant que la base primaire termine et valide la transaction. La réplication binlog en temps réel (BRR) élimine ce délai : la base primaire notifie la base secondaire pour qu'elle commence à exécuter l'instruction DDL en parallèle, sans attendre le signal de validation. Lors de tests de référence sur une table de 80 millions de lignes occupant 23 Go, la base secondaire a subi un délai de réplication de 277 secondes sans BRR, contre aucun délai avec BRR activé.

Fonctionnement

MySQL utilise la réplication logique : après la validation d'une transaction sur la base de données primaire, l'événement binlog résultant est envoyé à la base secondaire pour rejeu. Pour les instructions DDL, la charge utile du binlog est faible (un seul Gtid_log_event et un seul Query_log_event), de sorte que le temps de transmission est négligeable. Le goulot d'étranglement réside dans le temps d'exécution de l'instruction DDL elle-même, car la base secondaire ne peut pas commencer tant que la base primaire n'a pas validé la transaction.

Standard DDL replication flow

BRR résout ce problème à la source. Lorsque la base primaire démarre une instruction DDL, elle envoie immédiatement un événement binlog Brr — un nouveau type d'événement introduit par cette fonctionnalité — à la base secondaire via une transmission en temps réel. La base secondaire commence alors à exécuter l'instruction DDL en parallèle à l'aide de threads dédiés Brr Worker, indépendants des threads Worker MySQL standards Worker threads. Une fois que la base secondaire a terminé la majeure partie du travail lié à l'instruction DDL, elle attend le résultat de la base primaire :

  • Si la base primaire réussit, elle signale à la base secondaire de valider la transaction.

  • Si la base primaire échoue, elle signale à la base secondaire d'annuler la transaction.

Le délai total de réplication se réduit ainsi au temps d'une transmission réseau vers la base secondaire plus le temps de validation de l'instruction DDL, soit généralement quelques dizaines de millisecondes.

BRR parallel DDL replication flow

L'événement binlog Brr n'est pas écrit dans le binlog ni dans le relay log, il n'a donc aucun impact sur les systèmes en aval qui consomment les journaux binaires.

Prérequis

Avant d'activer BRR, assurez-vous que :

Instructions DDL prises en charge

Les instructions DDL couvertes par BRR dépendent de votre version mineure du moteur :

Version mineure du moteur Instructions prises en charge
20250731 ou ultérieure ALTER TABLE
20251031 ou ultérieure ALTER TABLE et OPTIMIZE TABLE

Activation de BRR

Définissez les paramètres suivants sur les bases de données primaires et secondaires en configurant les paramètres de l'instance. Les modifications prennent effet immédiatement ; aucun redémarrage de l'instance n'est requis.

Base de données primaire

Paramètre Description Valeur par défaut
loose_binlog_realtime_apply_ddl_source_enabled Définissez sur ON pour activer BRR sur la base primaire. —
loose_binlog_realtime_ddl_time_limit BRR s'applique uniquement aux instructions DDL dont le temps d'exécution dépasse ce seuil (en millisecondes). N est un entier supérieur ou égal à 0. 1000

Base de données secondaire

Paramètre Description Valeur par défaut
loose_binlog_realtime_apply_workers Nombre de threads Brr Worker sur la base secondaire. Doit être un entier supérieur ou égal à 1. —

Résultats des tests de référence

Le test suivant a utilisé une table unique contenant 80 000 000 d'enregistrements (23 Go) et a exécuté ALTER TABLE sbtest1 ENGINE=InnoDB pour la reconstruire. La base primaire a exécuté l'instruction DDL à 16:21:35, puis à nouveau à 16:32:50. L'instance de test utilisait la version mineure du moteur 20251031.

BRR activé Délai de réplication de la base secondaire
Non 277 secondes
Oui 0 seconde

Benchmark results showing replication delay with and without BRR