PolarDB:Physical replication-based semi-sync in PolarDB for MySQL

Contexte

MySQL standard propose une réplication semi-synchrone fondée sur le journal binaire. Dans ce mode, le nœud primaire doit attendre qu'un nœud secondaire confirme la réception du journal binaire généré par une transaction avant de pouvoir valider celle-ci. Cette méthode de synchronisation introduit une latence supplémentaire et affecte les performances en écriture du nœud primaire.

PolarDB for MySQL utilise une architecture de réplication physique pour synchroniser efficacement le journal redo entre les zones primaire et secondaire. Cette approche améliore considérablement l'efficacité de la réplication semi-synchrone et réduit la perte de performance sur le nœud primaire. Sous des charges de travail à forte concurrence, la dégradation des performances est d'environ 10 % par rapport à la réplication asynchrone.

Comparée à la réplication semi-synchrone basée sur le journal binaire de MySQL standard, l'approche par réplication physique de PolarDB for MySQL offre une efficacité de synchronisation supérieure. Lors de l'exécution des transactions, les enregistrements du journal redo sont générés et transmis en temps réel vers la zone secondaire. Par conséquent, au moment de la validation, le nœud primaire doit uniquement attendre que l'enregistrement correspondant du journal redo soit correctement synchronisé avec la zone secondaire. À l'inverse, le mécanisme semi-synchrone traditionnel basé sur le journal binaire ne génère le journal complet qu'au moment de la validation. Le nœud primaire ne peut alors retourner un message de succès au client qu'après la synchronisation intégrale de ce journal binaire.

Fonctionnement

La réplication semi-synchrone de PolarDB for MySQL repose sur une architecture de réplication physique pour synchroniser les données entre les zones primaire et secondaire via les journaux redo. Pour une requête d'écriture, des enregistrements de journal redo sont générés lors de la modification des données dans la zone primaire, puis synchronisés via le lien de réplication physique. Le nœud primaire doit attendre que la zone secondaire accuse réception du journal redo avant que la transaction d'écriture correspondante puisse retourner une réponse de succès.

• Temps d'attente maximal avant validation

  Afin d'éviter que des problèmes dans la zone secondaire ne bloquent indéfiniment les requêtes d'écriture dans la zone primaire, le noyau limite le temps d'attente maximal avant la validation d'une transaction d'écriture. Si la zone secondaire n'envoie pas d'accusé de réception dans ce délai, le nœud primaire valide automatiquement la transaction.

• Mécanisme adaptatif

  Dans des cas extrêmes, la zone secondaire peut ne pas envoyer d'accusés de réception au nœud primaire en temps voulu. Chaque requête d'écriture risque alors d'attendre jusqu'à l'expiration du délai avant d'être validée, ce qui entraîne une perte de performance. Pour prévenir ce problème, le mode semi-sync intègre un mécanisme adaptatif qui surveille dynamiquement la communication réseau entre les zones primaire et secondaire. Si des expirations de délai surviennent fréquemment, le système bascule automatiquement vers la réplication asynchrone afin de garantir que les écritures dans la zone primaire ne soient pas affectées. Dès que le système détecte un retour à la normale de la synchronisation, il réactive automatiquement le mode semi-sync.

Applicabilité

Votre cluster doit répondre aux exigences suivantes :

• **Product edition** : Enterprise Edition et Standard Edition

• **Engine version** :

  • MySQL 8.0.1 :

    • Version de révision 8.0.1.35.1 ou ultérieure : activation possible du mode semi-sync.

    • Version de révision 8.0.1.1.40 ou ultérieure : activation possible du mode semi-sync et prise en charge du mécanisme adaptatif.

    • Version de révision 8.0.1.1.44.2 ou ultérieure : activation possible du mode semi-sync. Le paramètre innodb_polar_wait_slave_reply_max_time est disponible pour contrôler le temps d'attente maximal par défaut avant la validation d'une transaction d'écriture. La valeur par défaut est de 500 ms.

  • MySQL 8.0.2 : Version de révision 8.0.2.2.32 et ultérieure : activation possible du mode semi-sync, avec prise en charge du mécanisme adaptatif et du paramètre innodb_polar_wait_slave_reply_max_time.

Précautions

RPO et RTO :

• En réplication asynchrone, un basculement automatique interzone entraîne une perte de données. Le RPO est généralement inférieur à 100 ms, mais peut atteindre 60 s dans le pire des cas. Évaluez l'impact potentiel avant d'utiliser cette fonctionnalité.

• L'activation de la réplication semi-synchrone réduit les performances d'environ 10 %. Le temps d'attente par défaut pour la validation des transactions est de 500 ms. Si ce délai est dépassé, le système bascule vers la réplication asynchrone et n'attend plus la synchronisation avec la zone secondaire. En l'absence de basculement, le RPO est égal à 0.

• Le RTO est inférieur à 30 s, tant pour la réplication asynchrone que pour la réplication semi-synchrone.

Tests de performance

Méthode de test : ce test compare les performances en termes de requêtes par seconde (QPS) de clusters aux spécifications identiques dans trois modes : PolarDB for MySQL avec réplication asynchrone, PolarDB for MySQL avec semi-sync, et MySQL standard avec semi-sync.

Outil de test : Sysbench (oltp_write_only).

Spécifications du test : 16 cœurs, 64 Go.

Version testée : PolarDB for MySQL 8.0.1 avec la version de révision 8.0.1.35.1. Les performances peuvent varier légèrement par rapport à la dernière version.

Volume de données : 10 tables, avec 10 millions de lignes par table.

Les résultats indiquent que dans des scénarios à forte concurrence, l'activation de la réplication semi-synchrone réduit les performances d'environ 10 %. Quel que soit le niveau de concurrence, les performances de la réplication semi-synchrone basée sur le journal redo dans PolarDB for MySQL surpassent celles de la réplication semi-synchrone basée sur le journal binaire dans MySQL.

FAQ

Q1 : Pourquoi les performances se dégradent-elles de plus de 10 % après l'activation du mode semi-sync ?

R1 : Dans des scénarios à forte concurrence, la dégradation des performances dans le meilleur des cas est d'environ 10 %. Cela s'explique par le traitement par lots des journaux redo, qui réduit efficacement la surcharge liée à la latence réseau. Dans des scénarios à faible concurrence, l'amélioration des performances apportée par le traitement par lots est moins significative, ce qui peut entraîner une dégradation plus marquée. Avec un seul thread d'écriture, les E/S du journal redo ne peuvent pas être traitées par lots. Le délai aller-retour réseau supplémentaire induit par l'activation de la réplication semi-synchrone réduit alors considérablement les performances.

Q2 : Pourquoi le paramètre innodb_polar_wait_slave_reply_max_time n'apparaît-il pas dans la console ? Comment l'ajuster à une valeur appropriée ?

R2 : Ce paramètre ne peut être modifié que sur les clusters PolarDB for MySQL Enterprise Edition dont la version majeure est 8.0.1 et la version de révision 8.0.1.1.44.2 ou ultérieure. Si vous ne trouvez pas ce paramètre dans la console, vérifiez d'abord que la version de votre cluster répond aux exigences. Si ce n'est pas le cas, effectuez une mise à niveau de version.

Dans la plupart des cas, il n'est pas nécessaire de modifier ce paramètre. Sa valeur par défaut est de 500 ms. Si vous avez des exigences spécifiques, comme garantir qu'une transaction attende la synchronisation avec la zone secondaire avant d'être validée, augmentez cette valeur. Toutefois, la valeur par défaut de 500 ms suffit pour la majorité des scénarios. Pour limiter le temps d'attente des transactions, réduisez la valeur du paramètre. Notez cependant qu'une valeur très faible, telle que 0 ou 1 ms, risque de provoquer le basculement du mode semi-sync vers la réplication asynchrone. En effet, la latence réseau entre les zones de disponibilité est généralement inférieure à 1 ms, or la réplication semi-synchrone nécessite au moins un aller-retour réseau. Tenez donc compte de la latence réseau de votre environnement lors de la modification de ce paramètre.

Q3 : Quand le mécanisme adaptatif du mode semi-sync entre-t-il en vigueur ? Est-il possible d'activer le mode semi-sync tout en désactivant le mécanisme adaptatif ?

R3 : Actuellement, l'activation du mode semi-sync active également le mécanisme adaptatif par défaut. Celui-ci surveille dynamiquement l'état de synchronisation entre les zones primaire et secondaire et procède à des ajustements en temps réel. Il n'est pas possible de désactiver le mécanisme adaptatif séparément. Pour maintenir la fonctionnalité semi-sync active en permanence, définissez innodb_polar_wait_slave_reply_max_time sur une valeur plus élevée. Le mécanisme adaptatif utilise ce paramètre pour détecter les expirations de délai.

Q4 : Le RPO est égal à 0 lorsque le mode semi-sync ne bascule pas. Ce « basculement » correspond-il à la désactivation dynamique du mode semi-sync par le mécanisme adaptatif ?

R4 : Il s'agit de concepts différents. L'« absence de basculement » signifie qu'une transaction n'est validée qu'après la synchronisation de son journal redo avec la zone secondaire. Dans ce cas, un RPO de 0 est strictement garanti. Cependant, le mécanisme adaptatif effectue sa surveillance au niveau des paquets réseau, et non au niveau des transactions. Lorsque le mécanisme adaptatif désactive dynamiquement le mode semi-sync, c'est généralement parce que plusieurs transactions ont déjà été validées en raison d'expirations de délai de synchronisation. Autrement dit, même si le mode semi-sync est activé et n'a pas été désactivé par le mécanisme adaptatif, le RPO n'est pas strictement égal à 0. Quelques transactions peuvent être validées en raison d'expirations de délai de synchronisation, bien que cela reste un événement rare. Par conséquent, la fonctionnalité semi-sync garantit un RPO proche de 0.