ApsaraDB RDS:Binlog in Redo

Prérequis

• Version de la base de données :

  • MySQL 8.4

  • MySQL 8.0 : la version mineure du moteur doit être 20200430 ou ultérieure. Pour mettre à jour la version mineure du moteur de votre instance, consultez la rubrique Mettre à jour la version mineure du moteur.

• Définissez le paramètre sync_binlog de l'instance sur 1 et le paramètre binlog_order_commits sur OFF. Pour plus d'informations, consultez la rubrique Configurer les paramètres d'instance.

• Configurez le mode de réplication des données de l'instance en réplication asynchrone. Pour plus d'informations, consultez la rubrique Interroger et modifier le mode de réplication des données.

Contexte

Dans les scénarios MySQL critiques, afin de garantir la sécurité des données, le journal binaire et le journal des transactions (redo log) doivent être vidés de manière synchrone sur le disque lors de la validation d'une transaction. Cela signifie que les deux paramètres suivants doivent être définis sur 1 :

sync_binlog = 1;
innodb_flush_log_at_trx_commit = 1;

Le standard MySQL impose deux opérations d'E/S disque synchrones pour chaque validation de transaction : une pour le journal binaire et une pour le journal des transactions. Cette exigence réduit l'efficacité des validations, un impact plus prononcé sur les disques cloud.

Pour améliorer l'efficacité des validations de transaction, AliSQL a introduit la fonctionnalité Binlog in Redo. Celle-ci est activée en définissant le paramètre persist_binlog_to_redo=ON et est désactivée par défaut. Lors de la validation d'une transaction, cette fonctionnalité fusionne le contenu du journal binaire avec le journal des transactions et les écrit ensemble. Une seule opération d'E/S synchrone est nécessaire pour persister le journal des transactions, ce qui vide également les données du journal binaire sur le disque. Cette conception élimine les deux opérations d'E/S distinctes requises dans le standard MySQL pour le journal binaire et le journal des transactions, réduisant ainsi considérablement la latence et augmentant le débit.

De plus, Binlog in Redo utilise le traitement par lots et un mécanisme de validation groupée pour atténuer la contention des verrous liée à l'allocation des GTID dans les scénarios à forte concurrence. Cette approche réduit les conflits de verrous et garantit des performances élevées.

Un thread d'arrière-plan écrit de manière asynchrone le fichier du journal binaire, en ajoutant des données par lots périodiquement. Cela évite la pression sur le système de fichiers causée par les appels fsync en temps réel et améliore l'efficacité globale des E/S. Même si la base de données redémarre de manière inattendue, le système peut restaurer automatiquement l'intégrité du fichier du journal binaire en rejouant les données du journal binaire stockées dans le journal des transactions, garantissant ainsi la cohérence des données.

La fonctionnalité Binlog in Redo ne modifie pas le format du journal binaire. La réplication et les outils tiers basés sur le journal binaire ne sont pas affectés.

Remarques

Après avoir activé la fonctionnalité Binlog in Redo, pour restaurer une instance à disque local haute performance vers une base de données auto-gérée à l'aide d'un fichier de sauvegarde physique, vous devez utiliser l'outil XtraBackup fourni par RDS. Pour installer l'outil XtraBackup, consultez la rubrique Préparation des outils.

Paramètres

• persist_binlog_to_redo

  Active ou désactive la fonctionnalité Binlog in Redo. Il s'agit d'une variable système globale. Valeurs valides : on ou off. Les modifications apportées à ce paramètre prennent effet immédiatement sans redémarrer l'instance.

  Remarque

  Pour activer cette fonctionnalité, outre le fait de définir persist_binlog_to_redo sur on, vous devez également définir binlog_order_commits sur off et configurer le mode de réplication des données de l'instance en réplication asynchrone.

  • Pour plus d'informations sur la configuration des paramètres d'instance, consultez la rubrique Configurer les paramètres d'instance.

  • Pour plus d'informations sur la configuration du mode de réplication des données, consultez la rubrique Interroger et modifier le mode de réplication des données.

  Si le paramètre sync_binlog de votre instance n'est pas défini sur 1, la fonctionnalité Binlog in Redo n'est pas activée, même si vous configurez les paramètres précédents. Dans ce cas, nous vous recommandons d'utiliser la fonctionnalité Binlog Parallel Flush pour optimiser les performances de votre instance.

• sync_binlog_interval

  L'intervalle auquel les journaux binaires sont persistés de manière asynchrone. Il s'agit d'une variable système globale qui prend effet uniquement lorsque persist_binlog_to_redo = on. La valeur par défaut est 50, exprimée en millisecondes (ms). Dans la plupart des cas, la valeur par défaut est suffisante. Les modifications apportées à ce paramètre prennent effet immédiatement sans redémarrer l'instance.

Tests de performance

• Environnement de test

  • Serveur d'application : une instance ECS Alibaba Cloud

  • Spécifications de l'instance RDS : 32 cœurs, 128 Go de mémoire, disque cloud ESSD

  • Type d'instance : Édition Haute Disponibilité (mode de réplication des données : réplication asynchrone)

• Cas de test

  Les cas de test Sysbench intégrés suivants ont été utilisés :

  • oltp_update_non_index

  • oltp_write_only

• Résultats des tests

  • oltp_update_non_index

    Après l'activation de Binlog in Redo, le TPS augmente considérablement dans les scénarios à faible concurrence et de manière notable dans les scénarios à forte concurrence, avec une latence réduite.

    

  • oltp_write_only

    Après l'activation de Binlog in Redo, le TPS augmente substantiellement tant dans les scénarios à faible qu'à forte concurrence, avec une latence réduite.

    

Conclusions

• Le cas de test oltp_update_non_index contient uniquement des transactions à instruction unique, il valide donc plus fréquemment. En revanche, oltp_write_only contient des transactions multi-instructions (deux instructions UPDATE, une instruction DELETE et une instruction INSERT), il valide donc moins souvent. Par conséquent, l'amélioration des performances pour oltp_update_non_index est plus significative que pour oltp_write_only.

• Avec moins de 64 connexions simultanées, la fonctionnalité Binlog in Redo améliore considérablement les performances et réduit la latence. Cela la rend efficace pour la plupart des charges de travail de production.

• Avec plus de 256 connexions simultanées, la fonctionnalité Binlog in Redo offre des performances de pointe plus élevées et une latence plus faible, lui permettant de mieux gérer les pics de trafic soudains.