Lorsque la journalisation binaire est activée, une transaction volumineuse peut saturer la file d'attente d'écriture des binlogs et bloquer la validation de toutes les autres transactions. Cela entraîne une latence d'écriture en cascade, une augmentation des requêtes lentes et un pic de connexions. PolarDB for MySQL propose une écriture optimisée des binlogs pour les transactions volumineuses. Cette fonctionnalité redirige les données de binlog des transactions importantes vers un fichier dédié afin que les autres transactions puissent se valider sans attente.
Versions prises en charge
Cette fonctionnalité requiert PolarDB for MySQL Enterprise Edition ou Standard Edition exécutant l'une des versions de moteur de base de données suivantes :
PolarDB for MySQL 8.0.1, version de révision 8.0.1.1.42 ou ultérieure
PolarDB for MySQL 8.0.2, version de révision 8.0.2.2.25 ou ultérieure
Pour vérifier la version du moteur de votre cluster, consultez la section « Query an engine version » de la rubrique Engine versions 5.6, 5.7, and 8.0 .
Cas d'utilisation
Activez cette fonctionnalité lorsque des transactions volumineuses s'exécutent parallèlement à d'autres transactions au sein du même cluster. Elle convient particulièrement aux scénarios suivants :
Clusters à charges mixtes : des écritures par lots importantes ou des importations massives de données coexistent avec des transactions OLTP.
Charges sensibles à la latence : évitez que la validation de transactions volumineuses ne provoque des pics de latence ou une hausse des requêtes lentes pour les transactions concurrentes.
Prévention des pics de connexions : la validation de transactions importantes déclenche des tentatives de reconnexion au niveau applicatif et une augmentation soudaine du nombre de connexions.
Fonctionnement
Au moment de la validation, chaque transaction transfère ses données de binlog depuis son cache mémoire vers le fichier binlog partagé. Lors de validations concurrentes, ces opérations s'accumulent dans une file d'attente. Si une transaction (par exemple, une transaction générant 1 Go de données de binlog) occupe cette file pendant une durée prolongée, toutes les autres transactions doivent patienter. Il en résulte une série de problèmes : augmentation des requêtes lentes, maintien prolongé des verrous d'écriture, nouvelles tentatives d'opérations échouées par les applications et pics de connexions.
Une fois la fonctionnalité activée, PolarDB for MySQL redirige les données de binlog de toute transaction volumineuse éligible vers un fichier binlog dédié. Ainsi, la transaction importante ne bloque plus les autres dans la file d'attente d'écriture, ce qui permet aux transactions concurrentes de se valider sans délai.
Le fichier binlog dédié possède un en-tête standard comprenant FORMAT_DESCRIPTION_EVENT et PREVIOUS_GTIDS_LOG_EVENT. Il contient également un espace réservé spécial nommé IGNORABLE_LOG_EVENT, ignoré automatiquement par les systèmes en aval.
Activer l'écriture optimisée des binlogs
Définissez loose_enable_large_trx_optimization sur ON pour activer la fonctionnalité. Utilisez loose_binlog_large_trx_threshold_up pour spécifier le seuil de taille de binlog déclenchant l'optimisation.
Ces deux paramètres prennent effet immédiatement, sans redémarrage du cluster.
Pour obtenir des instructions sur la configuration des paramètres, consultez Configure cluster and node parameters .
| Paramètre | Portée | Valeur par défaut | Valeurs valides | Description |
|---|---|---|---|---|
loose_enable_large_trx_optimization |
Global | OFF | OFF, ON | Active ou désactive l'écriture optimisée des binlogs pour les transactions volumineuses. |
loose_binlog_large_trx_threshold_up |
Global | 1 Go | 10 Mo–300 Go | Seuil de taille de binlog au-delà duquel une transaction est écrite dans un fichier binlog dédié plutôt que dans le fichier binlog partagé. |
Limites
Les nœuds de réplication en aval ne peuvent pas utiliser la réplication multithread basée sur la concurrence de la base de données lorsque cette fonctionnalité est activée. Ne configurez pas simultanément slave_parallel_workers>0 et slave_parallel_type='DATABASE'. Utilisez plutôt slave_parallel_workers>0 avec slave_parallel_type='logical_clock'.
La limite supplémentaire suivante s'applique également :
La somme de contrôle n'est pas prise en charge pour les fichiers binlog des transactions volumineuses.
Comparaison des performances
La figure suivante illustre le temps nécessaire pour valider des transactions volumineuses sur un cluster utilisant le type de stockage PSL5, avant et après l'activation de la fonctionnalité.
Après l'activation de la fonctionnalité, le temps de validation des transactions volumineuses diminue considérablement. Cela élimine la lourde charge d'E/S et les verrous d'écriture prolongés que provoquaient auparavant ces validations.