MariaDB Undo contrôle la manière dont InnoDB stocke les anciennes versions des lignes, effectue des rollbacks en toute sécurité et fournit des vues de lecture cohérentes pendant l'exécution des opérations d'écriture. Je vais vous montrer comment les journaux d'annulation (Undo Logs) interagissent avec la liste d'historique (History List) et la purge (Purge), pourquoi les transactions longues monopolisent la mémoire et comment je gère la croissance de la Annuler- je contrôle ces domaines.
Points centraux
- MVCC et des lectures cohérentes : la fonction « Undo » enregistre les anciennes versions, les lecteurs ne sont pas bloqués.
- Historique: Les commits s'ajoutent à l'historique, tandis que la commande « purge » supprime des éléments.
- Transactions longues: Elles conservent les anciennes versions, ce qui augmente la consommation de mémoire et les latences.
- Configuration: Les tablespaces « Undo », les threads de purge et les opérations « Truncate » régulent la croissance.
- Suivi: Vérifier dès le début la longueur de l'historique, l'âge des transactions et la taille des opérations d'annulation.
Comment les journaux d'annulation permettent le MVCC
Je commence par l'essentiel : chaque modification enregistre la version précédente de la ligne dans le Annuler-Log, afin qu'un instantané cohérent reste valide. Les lecteurs accèdent à la version antérieure appropriée, tandis que les rédacteurs enregistrent de nouvelles données et mettent à jour les index ; ainsi, Parallélisme haut. Les lignes s'enchaînent à leurs prédécesseurs jusqu'à ce que « Purge » puisse les supprimer. Sans cette chaîne, les annulations seraient manquantes et les vues de lecture seraient faussées. C'est précisément là que « Undo » fait le lien entre la sécurité des transactions, l'isolation et des accès en lecture fiables.
Structure interne des journaux d'annulation
En substance, je distingue principalement deux types d'« Undo » : Annuler l'insertion et Annuler la mise à jour. La fonction « Insert-Undo » permet d'annuler les insertions qui n'ont pas encore été validées. La fonction « Update-Undo » conserve les anciennes versions en cas de modifications ou de marquages de suppression, afin que les instantanés continuent de fonctionner. InnoDB marque d’abord les lignes supprimées comme « supprimées » (marque « Delete ») et retarde leur suppression effective jusqu’à ce qu’aucun instantané ne puisse plus les voir. Cette distinction est cruciale : les annulations (rollbacks) ont besoin d’états antérieurs précis, tandis que les lecteurs cohérents doivent trouver une version qui corresponde logiquement à leur point de départ. C’est pourquoi les lignes font référence en interne à la version précédente, et les index contiennent des informations supplémentaires afin que la fonction « Purge » puisse ultérieurement supprimer proprement les entrées d’index.
Historique, Purge et mémoire
Après chaque commit, l'historique des modifications est enregistré dans le fichier global Historique Liste que le thread de purge traite de manière asynchrone. Si le thread de purge n'arrive pas à suivre, cette liste s'allonge et maintient artificiellement en vie d'anciennes versions de lignes. Cela entraîne davantage d'opérations de lecture, davantage d'E/S et des tablespaces « undo » plus volumineux. Dans de telles situations, je vérifie toujours les niveaux d’isolation et les snapshots ouverts, car une configuration inappropriée Choix de l'isolation prolonge la durée de vie des anciennes versions. En prenant en compte à la fois la vitesse de purge, la longueur de l'historique et les transactions actives, on peut détecter rapidement les goulots d'étranglement et freiner la dérive de la mémoire avant qu'elle ne devienne critique.
Mécanisme de purge et options de réglage
La purge fonctionne « au mieux »: Il rassemble les entrées pouvant être nettoyées issues de la liste d'historique, supprime définitivement les marqueurs de suppression, met à jour les index secondaires et libère les zones d'annulation. Dans les systèmes présentant un taux de modification élevé, j'adapte la Parallélisme (par exemple, via plusieurs Purge-Workers) et ajuste la stratégie de traitement par lots afin que Purge fonctionne de manière continue, mais sans être trop agressif. Règles générales :
- Des lots courts et réguliers plutôt que des traitements volumineux et sporadiques : cela permet de lisser les opérations d'E/S et les points de contrôle.
- Ne pas opposer la purge à la mémoire ou au vidage des journaux : ces deux méthodes doivent être aussi performantes l'une que l'autre.
- Je commence par résoudre les instantanés longs avant d'augmenter davantage la taille des lots, sinon l'effet est perdu.
Important : la fonction « Purge » ne remplace pas une bonne discipline en matière de transactions. Même avec un niveau élevé de parallélisme, les opérations « Undo » restent bloquées tant que d'anciens instantanés existent. Je surveille donc à la fois la progression de la fonction « Purge » et l'âge des transactions, et j'ajuste la charge de travail si la fonction « Purge » accuse un retard constant.
Configuration des tablespaces « Undo »
Selon la configuration, les informations d'annulation peuvent être stockées dans l'espace de table système ou dans des Annuler-tablespaces. Je préfère isoler les espaces « Undo » afin de mieux contrôler leur croissance et les E/S. De nombreuses installations permettent une croissance dynamique, incluant parfois la libération d’espace via la commande « TRUNCATE ». Cela semble pratique, mais cela accroît la nécessité d’une surveillance, car des instantanés de longue durée empêchent une réduction rapide. Je choisis l'emplacement de stockage, la taille et le parallélisme de purge de manière à ce que les taux de modification et les fenêtres temporelles du quotidien soient correctement pris en charge et Restauration ne souffre pas.
| Réglage | Effet | Remarque |
|---|---|---|
| innodb_undo_directory | Emplacement de stockage pour AnnulerFichiers | Les supports de données séparés découplent les E/S |
| innodb_purge_threads | Plus Purge- Ouvrier dans le secteur minier | Augmenter lorsque le taux de variation est élevé |
| innodb_undo_log_truncate | Libère de l'espace inutilisé | Ne fonctionne que si l'historique est vide |
| innodb_max_undo_log_size | Seuil de croissance | Disponibilité selon la version |
Structure de la mémoire et aspects liés au système de fichiers
Je préfère placer les tablespaces « Undo » séparés sur des SSD rapides, à l'écart des E/S de données et de journaux. Si le système de fichiers prend en charge TRIM/Discard, une commande « Truncate » peut restituer physiquement de l'espace au système d'exploitation. Je prévois néanmoins des limites maximales prudentes, car la libération d’espace n’est pas garantie tant que les instantanés sont liés à l’historique des annulations. De même, la compression au niveau du système de fichiers n’est utile que s’il y a une marge de manœuvre au niveau du processeur et si les modèles d’écriture ne provoquent pas de fragmentation. Il reste important de surveiller les pics de latence : si la pile d’annulations s’accroît sur un support de stockage saturé, l’amplification d’écriture et la pression sur les points de contrôle s’aggravent progressivement.
Surveillance et diagnostic
Je vérifie régulièrement la taille de la Annuler- les tablespaces, la longueur de la liste d’historique et l’âge des transactions ouvertes. Les commandes SHOW ENGINE InnoDB STATUS, Performance Schema et Information Schema fournissent des indications claires. Si les zones Undo grossissent alors que la purge ne donne que peu de résultats, je commence par interrompre les anciennes sessions. De plus, je vérifie les verrous, car les verrous inutiles Verrous de rangée prolongent les transactions et les instantanés. En surveillant quotidiennement ces indicateurs, on évite les pics soudains d'E/S et on raccourcit les chemins dans le Mémoire.
Conséquences sur les performances des transactions longues
Prolonger les transactions de lecture ou d'écriture Versions même si elles sont logiquement obsolètes. Cela alourdit la fonction « Undo », allonge les analyses et augmente la pression sur le cache. Je réduis ces effets en utilisant des lots plus courts, en effectuant systématiquement des COMMIT et en définissant des délais d'expiration pour les sessions. Les rapports dont la lecture dure des heures s’exécutent mieux dans des fenêtres plus petites ou sur des répliques. En désactivant l’autocommit, en rationalisant les plans de requêtes et en fermant les transactions inactives, on libère la mémoire de purge et on allège la charge sur le Instance.
Segments de rollback et parallélisme
Les entrées « Annuler » se trouvent dans Segments de rollback, qui fournissent en quelque sorte des « slots » pour les modifications actives simultanément. Un grand nombre d’écrivains simultanés tirent profit d’un nombre suffisant de segments de rollback, car les insertions et les mises à jour ont alors moins souvent besoin de partager leurs chaînes d’annulation. J’observe les schémas d’attente sur les ressources de rollback et j’augmente leur nombre lorsque la version et la distribution le permettent. Les symptômes d’un manque de parallélisme sont des temps d’attente inattendus lors de phases de mise à jour par ailleurs courtes, ou des latences d’écriture très variables sous charge. Un plus grand nombre de segments répartit la pression, mais ne remet pas en cause la règle fondamentale : les instantanés longs l’emportent sur tout optimisation.
Les niveaux d'isolation en détail
Le niveau d'isolation détermine la durée pendant laquelle les versions « undo » restent pertinentes. En mode REPEATABLE READ, une transaction conserve son instantané de départ pendant toute sa durée ; les versions « undo » restent donc potentiellement liées pendant très longtemps. En mode READ COMMITTED, des fenêtres de visibilité sont créées pour chaque instruction ; cela réduit considérablement la durée de vie des anciennes versions dans de nombreuses charges de travail. Les instructions SELECT … FOR UPDATE et LOCK IN SHARE MODE imposent des verrous et modifient le profil de concurrence – ce qui est utile pour éviter les « lost updates », mais critique pour les opérations de rétroaction si les lecteurs restent ouverts trop longtemps. J’utilise donc READ COMMITTED de manière ciblée lorsque les rapports ou les lectures d’API nécessitent des vues cohérentes, mais pas à l’échelle de la transaction, et je m’en tiens à REPEATABLE READ lorsque la logique métier l’exige.
Scénarios de récupération et de démarrage
Au démarrage, InnoDB utilise la Annuler-Des informations permettant de revenir en arrière proprement en cas de transactions incomplètes. Cela garantit la cohérence des vues avant que de nouveaux clients ne se connectent. Dans certains cas particuliers, il existe des modes de démarrage qui raccourcissent les vérifications, mais je ne les utilise qu’en cas d’urgence. Se contenter d’accélérer le processus sans diagnostic peut avoir des conséquences néfastes, car l’intégrité est prioritaire. En gardant un œil sur le temps de récupération et la taille des opérations d’annulation, on prend de meilleures décisions concernant les fenêtres de maintenance et Risque.
Règles pratiques en matière d'administration
Je veille à ce que les transactions soient courtes, j'effectue des commits fréquents et j'évite les sessions de lecture interminables, afin que Purge a le champ libre. Je répartis les modifications de grande envergure en lots bien dosés afin que la liste d'historique ne grossisse pas. J'adapte le nombre de threads de purge au taux de modification et j'ajuste la structure de l'historique aux capacités de mémoire. De plus, je documente les processus métier qui nécessitent de longs instantanés et je planifie délibérément des créneaux horaires. Ainsi, l’utilisation de la fonction d’annulation reste prévisible et la Latence bas.
Modèles de charge de travail et optimisation
Le commerce électronique, les systèmes de reporting et les systèmes de gestion de contenu génèrent de nombreux changements et nécessitent une approche rigoureuse Transactions. Je définis des délais d'expiration prudents pour les lecteurs, j'optimise les index pour des mises à jour précises et je limite la taille des lots. En cas de charge d'écriture élevée, j'augmente le parallélisme des opérations de purge et je régule la fréquence des points de contrôle. De plus, je vérifie le taux d'écriture par rapport à Journaux de transactions et récupération, afin que la récupération après crash reste prévisible. Cette interaction permet de planifier le volume des opérations d'annulation et protège la Consistance.
Sauvegardes et réplication
Les sauvegardes logiques avec instantané cohérent prolongent inévitablement la durée de vie des anciennes versions : la file d’attente « Undo » s’allonge jusqu’à ce que la sauvegarde soit terminée. Je planifie ces opérations en dehors des plages horaires de forte charge, je limite le nombre d’écrivains simultanés et je prévois une capacité de purge suffisante. Les sauvegardes physiques peuvent réduire la charge des opérations « Undo », mais ne dispensent pas de la diligence requise pour les instantanés. Sur les répliques, je préfère conserver les rapports en mode READ COMMITTED et je termine les transactions inactives de longue durée afin que SQL Apply ne prenne pas de retard. Si une réplique prend du retard, la charge « undo » y augmente également, car la mise à jour de nombreuses suppressions/mises à jour génère une vague d’historique que la purge doit d’abord traiter.
Runbook : Freiner rapidement la croissance des opérations « Undo »
- Identifier les processus actifs de longue durée : vérifier la durée des transactions ouvertes et les sessions générant des jeux de résultats volumineux.
- Mettre fin systématiquement à l'inactivité dans les transactions : vérifier l'autocommit, fermer les curseurs oubliés.
- Augmenter la capacité de purge : activer des workers supplémentaires et augmenter modérément la taille des lots.
- Lisser les pics de charge sur Writer : limiter la taille des lots, mettre en place des micro-commits.
- Tirer parti des fenêtres de maintenance : reporter les grandes vagues de suppression/mise à jour vers des créneaux prévisibles.
- Une fois la situation stabilisée : autoriser la commande « Undo-Truncate » jusqu'à ce que la taille du système de fichiers corresponde à nouveau aux besoins.
Planification des capacités pour Undo
Je calcule la capacité « Undo » de manière prudente en fonction du taux de modification, de la taille moyenne des lignes et de la fenêtre de snapshot maximale. Une approximation simple : nombre d’événements de modification par seconde × charge utile moyenne × fenêtre de snapshot prévue en secondes. Il faut prendre en compte une marge de sécurité pour les index et les métadonnées. Cette règle empirique permet d'avoir une idée des besoins dans le pire des cas et évite les mauvaises surprises lors des opérations de reporting, de sauvegarde ou de migration. en même temps Intégrer des instantanés. Dans les systèmes en pleine croissance, je vérifie chaque trimestre si les évolutions de la charge de travail (nouvelles fonctionnalités, augmentation du nombre de clients mobiles, pics d'activité plus importants) modifient les besoins.
Cas particuliers : tables temporaires et DDL
Les tables InnoDB temporaires utilisent leurs propres espaces ; leurs modifications sollicitent moins la file d'annulation standard, mais peuvent néanmoins générer des opérations d'E/S lors de tris ou de jointures volumineux. Les opérations DDL telles que ALTER TABLE génèrent souvent des vagues de modifications massives ; si nécessaire, je les divise en étapes incrémentielles et je les planifie pendant les périodes creuses. Ici aussi, la règle est la suivante : mieux vaut des transactions courtes et propres que des raccourcis risqués. Si une exécution DDL est interrompue, la fonction Undo permet de revenir à un état cohérent ; cela nécessite toutefois suffisamment de mémoire et de temps, que je prévois à l’avance.
Exemple : mesurer les effets
Je commence par un instantané de référence de la taille de la mémoire « Undo », qui Historique-la longueur et la durée moyenne des transactions. Je procède ensuite à des modifications ciblées, comme l'augmentation du nombre de threads de purge ou la réduction de la taille des lots. Je compare ensuite les indicateurs jusqu’à ce que la croissance des opérations d’annulation et les latences atteignent un équilibre satisfaisant. Si je constate des valeurs aberrantes, j’examine les plans de requêtes et les listes de sessions afin d’identifier les lecteurs bloqués. Ce processus itératif permet d’obtenir des résultats rapides sans Disponibilité de mettre en danger.
Idées reçues courantes
Un commit ne supprime pas immédiatement les anciennes versions ; Purge ne prendra sa décision que plus tard. Les options « Truncate » ne résolvent pas un problème de conception fondamental lorsque les transactions durent trop longtemps. Des fichiers d’annulation volumineux ne sont pas nécessairement synonymes de corruption ; souvent, une seule session suffit à les bloquer. Les lecteurs bloquent certes rarement les écriteurs, mais des requêtes inadaptées prolongent indirectement la durée des instantanés. En éliminant ces erreurs, on prend de meilleures décisions et on réduit Arrêts de travail.
Résumé pour les personnes pressées
Conserver les journaux d'annulation passé tangible, afin qu’InnoDB annule les transactions en toute sécurité et que les lecteurs voient des vues cohérentes. Je contrôle la croissance en optimisant les transactions, en configurant correctement les threads de purge et en plaçant judicieusement les tablespaces « undo ». La surveillance de la longueur de l’historique, de la taille des tables d’annulation et de l’ancienneté des transactions permet de détecter les tendances à un stade précoce. En cas d’anomalies, je vérifie la charge de travail, les verrous et les sessions, plutôt que de me concentrer sur les symptômes. Ceux qui adoptent cette routine préservent les performances, la cohérence et redémarrage sous contrôle en toutes circonstances.
