Comment configurer les fichiers journaux MySQL, annuler le journal et refaire le journal

1 annuler

1.1 Qu'est-ce que l'annulation

Le journal d'annulation est utilisé pour stocker la valeur avant que les données ne soient modifiées. Supposons que les données de ligne avec id=2 dans la table tba soient modifiées et que Name='B' soit remplacé par Name = 'B2', alors le journal d'annulation sera être utilisé pour stocker l'enregistrement Name='B', s'il y a une exception dans cette modification, vous pouvez utiliser le journal d'annulation pour implémenter l'opération de restauration et assurer la cohérence de la transaction.

L'opération de modification des données provient principalement de INSERT UPDATE DELETE, et UNDO LOG est divisé en deux types, l'un est INSERT_UNDO (opération INSERT), qui enregistre la valeur de clé unique insérée ; Y compris les opérations UPDATE et DELETE), enregistrez les valeurs de clé uniques modifiées et les anciens enregistrements de colonnes.

A2B3#🎜 🎜 #4D#.#1.2 Paramètre UNDO#🎜🎜 ## 🎜🎜#Les paramètres liés à MySQL liés à UNDO sont définis :

r#🎜🎜 ## 🎜🎜 ## 🎜🎜#innodb_max_undo_log_size#🎜🎜 #

# 🎜🎜#

Contrôle la taille maximale du fichier d'espace de table d'annulation. Lorsque innodb_undo_log_truncate est démarré, la troncature ne sera tentée que lorsque l'espace de table d'annulation dépasse le seuil innodb_max_undo_log_size. La taille par défaut de cette valeur est de 1 G et la taille par défaut après la troncature est de 10 M.

• innodb_undo_tablespaces

Définir le nombre et la plage d'annulation de la table indépendante espaces Il est compris entre 0 et 128 et la valeur par défaut est 0. 0 signifie que l'espace table d'annulation indépendant n'est pas activé et que le journal d'annulation est stocké dans le fichier ibdata. Ce paramètre ne peut être spécifié que lors de l'initialisation de l'instance MySQL. Si l'instance a été créée, ce paramètre ne peut pas être modifié. Si le nombre d'innodb_undo_tablespaces spécifié dans le fichier de configuration de la base de données.cnf est supérieur au nombre spécifié lors de la création de l'instance. ce sera Le démarrage a échoué, indiquant que le réglage des paramètres est incorrect.

• Si ce paramètre est défini sur n (n>0), alors n annuler les fichiers (undo001, undo002. ..... annuler n) , la taille par défaut de chaque fichier est de 10M

Quand devez-vous définir ce paramètre ?

Lorsque la pression d'écriture de la base de données est élevée, vous pouvez configurer un espace table UNDO indépendant, séparer le UNDO LOG du fichier ibdata et spécifier le répertoire innodb_undo_directory pour le stockage, qui peut être attribué à un disque à grande vitesse. Accélérez les performances de lecture et d'écriture de UNDO LOG.

innodb_undo_log_truncate

Le fil de purge d'InnoDB, selon Le paramètre innodb_undo_log_truncate est activé ou désactivé, la valeur du paramètre innodb_max_undo_log_size et la fréquence de troncature pour recycler l'espace et réinitialiser le fichier d'annulation.

• La prémisse pour que ce paramètre prenne effet est que des espaces table indépendants ont été configurés et que le nombre d'espaces table indépendants est supérieur ou égal à 2.

  Lors du processus de troncature du fichier journal d'annulation, le thread de purge doit vérifier s'il y a des transactions actives sur le fichier. Sinon, le fichier journal d'annulation doit être marqué comme non allouable. À ce stade, le journal d'annulation sera enregistré dans d'autres fichiers, donc au moins 2 fichiers d'espace table indépendants sont requis pour effectuer l'opération de troncature. Après l'avoir marqué comme non allouable, un fichier indépendant undo__trunc.log sera créé pour. Enregistrez qu'un certain espace table est en cours de troncature du fichier journal d'annulation, puis commencez à initialiser le fichier journal d'annulation à 10M. Une fois l'opération terminée, supprimez le fichier undo__trunc.log indiquant l'action de troncature. garantit que même si un échec se produit pendant le processus de troncature, le service de base de données sera redémarré. Après le redémarrage, lorsque le service découvre ce fichier, il continuera à terminer l'opération de troncature. Après la suppression du fichier, il marquera le fichier journal d'annulation. disponibles pour attribution.

innodb_purge_rseg_truncate_ Frequency

est utilisé pour contrôler l'annulation de la purge fréquence du segment Degré , la valeur par défaut est 128. En supposant qu'il soit défini sur n, cela signifie que lorsque le thread de coordination de l'opération Innodb Purge purge les transactions 128 fois, une purge de l'historique sera déclenchée pour vérifier si l'état actuel de l'espace table du journal d'annulation déclenchera une troncature.

• 1.3 annuler la gestion de l'espace

  Si vous devez configurer des espaces table indépendants, vous devez spécifier le nombre d'espaces table indépendants lors de l'initialisation l'instance de base de données.

UNDO est composé en interne de plusieurs segments d'annulation, à savoir des segments d'annulation, un total de 128, qui sont stockés dans l'espace table du système ibdata, de l'emplacement resg0 à l'emplacement resg127, chaque emplacement resg, c'est-à-dire Chaque Le segment d'annulation est composé en interne de 1 024 segments d'annulation.

Le segment de rollback est alloué comme suit :

slot 0, réservé à l'espace table système

#🎜 🎜# ;

slot 1-32, réservé à l'espace table temporaire. Chaque fois que la base de données est redémarrée, l'espace table temporaire sera reconstruit

#🎜🎜 # ; slot33-127, s'il existe un espace table indépendant, il est réservé à l'espace table indépendant UNDO ; sinon, il est réservé à l'espace table système ; À l'exclusion de 32 pour les transactions de table temporaires, les 128-32=96 segments d'annulation restants peuvent exécuter 96*1024 opérations de transaction simultanées. Chaque transaction occupe un emplacement de segment d'annulation. Notez que s'il y a des transactions de table temporaires, elles occuperont également un autre emplacement de segment d'annulation dans le. emplacement de segment d'annulation dans l'espace table temporaire, c'est-à-dire occuper 2 emplacements de segment d'annulation. S'il y a :

dans le journal des erreurs, cela signifie qu'il y a trop de transactions simultanées et vous devez vous demander s'il faut décharger l'entreprise.

• Le segment d'annulation est alloué à l'aide de la planification d'interrogation. Si un espace table indépendant est configuré, le segment d'annulation dans le segment d'annulation de l'espace table système ne sera pas utilisé, mais sera utilisé pour une table indépendante. espaces, en même temps, si le segment lookback est tronqué, il ne sera pas alloué.

  

  2 refaire

  2.1 Qu'est-ce que refaire

  Lorsque la base de données modifie les données, elle doit lire la page de données du disque dans le pool de tampons, puis la modifier dans le pool de tampons. à ce moment-là, la page de données dans le pool de mémoire tampon n'est pas cohérente avec le contenu de la page de données sur le disque. La page de données dans le pool de mémoire tampon est appelée page sale. Si un redémarrage anormal du service de base de données se produit à ce moment-là, les données ne le sont pas. dans la mémoire et n'est pas synchronisé avec le fichier disque (notez que la synchronisation avec le fichier disque est une E/S aléatoire), c'est-à-dire qu'une perte de données se produira s'il y a un fichier à ce moment-là, lorsque la page de données est dans le tampon. pool est modifié, l'enregistrement de modification correspondant est enregistré dans ce fichier (notez que le journal est enregistré en IO séquentielle), puis lorsque le service DB plante et que la base de données est restaurée, le contenu enregistré de ce fichier peut être réappliqué au fichier disque, et les données resteront cohérentes.

  Ce fichier est le redo log, qui est utilisé pour enregistrer les données modifiées en séquence. Cela peut apporter les avantages suivants :

  • Lorsque la page sale du pool de mémoire tampon n'a pas été actualisée sur le disque, un crash se produit. Après le démarrage du service, vous pouvez trouver les enregistrements qui doivent être actualisés sur le fichier disque. le redo log ;

  • Les données du pool de tampons sont directement vidées dans le fichier disque, ce qui est une IO aléatoire, ce qui est moins efficace, tandis que l'enregistrement des données dans le pool de tampons dans le redo log est une IO séquentielle, ce qui peut améliorer la vitesse de soumission des transactions ;

  Hypothèse Modifiez les données de la ligne avec id=2 dans la table tba et remplacez Name='B' par Name = 'B2'. Ensuite, le journal redo sera utilisé pour stocker le. enregistrement de Name='B2'. Si cette modification est transférée dans le fichier disque. Si une exception se produit, vous pouvez utiliser le journal redo pour implémenter les opérations redo afin de garantir la durabilité de la transaction.

Id	Name
1#🎜🎜 #
C
	#🎜🎜 #

Id	Nom
1	A
2	B
3	C
4	D

Notez ici la différence entre le journal redo et le journal binaire. Le journal redo est généré par la couche du moteur de stockage, tandis que le journal binaire est généré par la couche de base de données. Supposons qu'une transaction volumineuse insère 100 000 lignes d'enregistrements dans tba. Au cours de ce processus, les enregistrements sont continuellement enregistrés de manière séquentielle dans le journal redo, mais le journal binaire ne sera pas enregistré. Ce n'est que lorsque la transaction sera validée qu'elle sera écrite dans le fichier journal binaire. une fois. Il existe trois formats d'enregistrement différents disponibles pour les journaux binaires, à savoir les lignes, les instructions et les mixtes, et les formes d'enregistrement parmi eux sont différentes.

2.2 redo Paramètres

• # 🎜🎜 #

  innodb_log_files_in_group

redo numéro de fichier journal, méthode de dénomination telle que : ib_logfile0, iblogfile1... iblogfilen. La valeur par défaut est 2, le maximum est 100. # 🎜🎜 ## 🎜🎜 ## 🎜🎜 ## 🎜🎜 ## 🎜🎜 # innodb_log_file_size # 🎜🎜 ## 🎜🎜 ## 🎜🎜 ## 🎜🎜 ## 🎜🎜 # Taille de paramètre de fichier, la valeur par défaut est 48m , La valeur maximale est de 512 G. Notez que la valeur maximale fait référence à la somme de l'intégralité des fichiers de la série de journaux redo, c'est-à-dire que (innodb_log_files_in_group * innodb_log_file_size) ne peut pas être supérieure à la valeur maximale de 512 G.

• innodb_log_group_home_dir

chemin de stockage des fichiers#🎜 🎜##🎜 🎜#

innodb_log_buffer_size

• Redo Log zone de cache, par défaut 8M, peut être définie sur 1-8M . Retardez l'écriture du journal des transactions sur le disque, placez le journal de rétablissement dans le tampon, puis videz le journal du tampon vers le disque en fonction du paramètre innodb_flush_log_at_trx_commit.

innodb_flush_log_at_trx_commit

• #🎜 🎜#
innodb_flush_log_at_trx_commit =1, chaque validation écrira le journal de rétablissement du tampon de journalisation vers le système et le synchronisera avec le fichier disque.

innodb_flush_log_at_trx_commit=2, chaque fois qu'une transaction est soumise, MySQL écrira le journal du tampon de journalisation vers le système, mais l'écrira uniquement dans le tampon du système de fichiers , qui est interne au système pour se synchroniser avec le fichier disque. Si l'instance de base de données plante, le journal redo ne sera pas perdu. Cependant, si le serveur tombe en panne, cette partie des données sera perdue car le tampon du système de fichiers n'a pas eu le temps de se synchroniser avec le fichier disque.

• innodb_flush_log_at_trx_commit=0, pendant la transaction, le journal est toujours actif dans le tampon de journalisation, tout comme les autres paramètres, mais lorsque la transaction est validée, pas de réécriture L'opération se produit. Au lieu de cela, MySQL fonctionne en interne une fois par seconde pour écrire les données du tampon de journalisation dans le système. En cas de crash, les opérations de modification de transaction dans un délai d'une seconde seront perdues.

• Remarque : En raison de problèmes de politique de planification des processus, il n'est pas garanti que cette opération "effectuer un vidage (vidage sur le disque) toutes les secondes" être 100 % de "par seconde".

• 2.3

redo

#🎜 🎜# Gestion de l'espace

• Le fichier Redo log porte le nom de

  Le Redo log écrit les fichiers de manière séquentielle. Lorsqu'il est plein, il reviendra au premier fichier et. écrasez-le. (Mais lors de la restauration du point de contrôle, la marque du point de contrôle d'en-tête du premier fichier journal sera également mise à jour, donc à proprement parler, elle n'est pas comptée comme une écriture séquentielle).

En fait, le redo log se compose de deux parties : le tampon redo log et le fichier redo log. Dans le pool de mémoire tampon, les modifications de données sont enregistrées dans le tampon de journalisation. Si ce qui suit se produit, le journal de rétablissement est vidé dans le fichier de journalisation :

Espace insuffisant dans. le tampon de journalisation# 🎜🎜#Soumission de la transaction (dépend du paramètre innodb_flush_log_at_trx_commit)

Thème de fond#🎜 🎜 ##🎜 🎜## 🎜🎜#

Do checkpointib_logfile[number]

Arrêt de l'instance

• binlog commutation
# 🎜🎜#

• 3 Comment enregistrer des transactions avec annulation et rétablissement

• 3.1 Processus simplifié de Annuler + Rétablir les transactions

• Supposons qu'il y ait deux données A et B avec les valeurs 1 et 2 respectivement. Démarrez une transaction. Le contenu de l'opération est : modifier 1 à 3 et. 2 à 4. Ensuite, l'enregistrement réel est le suivant (simplifié) :

A. Début de la transaction.

• B. Enregistrez A=1 pour annuler le journal.

C. Modifiez A=3.

• D. Enregistrez A=3 pour refaire le journal.

E. Enregistrez B=2 pour annuler le journal.#🎜🎜 #

F. Modifiez B=4 .

G. Enregistrez B=4 pour refaire le journal.

H. Écrivez le journal de rétablissement sur le disque.

I. Soumission de transaction

3.2 Impact des IO

L'objectif principal de la conception d'Undo + Redo est d'améliorer Performances d'entrée et de sortie, augmentent la puissance de traitement de la base de données. On peut voir que B D E G H sont toutes de nouvelles opérations, mais B D E G est mis en mémoire tampon dans la zone tampon. Seul G ajoute des opérations d'E/S. Afin de garantir que Redo Log puisse avoir de meilleures performances d'E/S, la conception du Redo Log d'InnoDB a les fonctionnalités suivantes :

B. Essayez de vous assurer que Redo Log est stocké dans un espace continu. Par conséquent, l’espace du fichier journal sera entièrement alloué lors du premier démarrage du système. Afin d'améliorer les performances, Redo Log sera enregistré de manière séquentielle et complété étape par étape.

B. Écrivez les journaux par lots. Le journal n'est pas écrit directement dans le fichier, mais d'abord écrit dans le tampon de journalisation. Lorsque le journal doit être vidé sur le disque (comme la soumission d'une transaction), plusieurs journaux sont écrits ensemble sur le disque. 🎜🎜# C. Concurrence Les transactions partagent l'espace de stockage du Redo Log, et leurs Redo Logs sont enregistrés ensemble alternativement selon l'ordre d'exécution des instructions pour réduire l'espace occupé par le log. Par exemple, le contenu de l'enregistrement dans Redo Log peut ressembler à ceci :

Enregistrement 1 :

Enregistrement 2 :

Enregistrement 3 :
Enregistrement 4 :
Enregistrement 5 :

D. Grâce au C, lorsqu'une transaction écrit le Redo Log sur le disque, les journaux des autres transactions non validées seront également écrits sur le disque.

E. Seules les opérations d'ajout séquentielles sont effectuées sur le journal de rétablissement. Lorsqu'une transaction doit être annulée, ses enregistrements de journal de rétablissement ne seront pas supprimés du journal de rétablissement.

3.3 Récupération

Comme mentionné précédemment, les transactions non validées et les transactions annulées seront également enregistrées dans le journal de rétablissement, donc pendant la récupération, ces transactions nécessitent un traitement spécial. Il existe 2 stratégies de récupération différentes :

A. Lors de la récupération, refaites uniquement les transactions validées.

Lors de la récupération, toutes les transactions doivent être réexécutées, y compris les transactions non validées et annulées. Annulez ensuite ces

transactions non validées via Annuler le journal.

Le moteur de stockage de la base de données MySQL InnoDB utilise la stratégie B,

Le mécanisme de récupération du moteur de stockage InnoDB a plusieurs caractéristiques : A. Lors de la restauration Log, ne vous

vous souciez pas du caractère transactionnel

. Pendant la récupération, il n'y a pas de comportement BEGIN, COMMIT ou ROLLBACK. Peu importe à quelle transaction appartient chaque journal. Bien que le contenu lié à la transaction, tel que l'ID de transaction, soit enregistré dans le Redo Log, ce contenu n'est considéré que comme une partie des données à exploiter. B. Lors de l'utilisation de la stratégie B, le journal d'annulation doit être conservé et le journal d'annulation correspondant doit être écrit sur le disque avant d'écrire le journal de rétablissement. Cette relation entre Undo et Redo Log rend la persistance compliquée. Afin de réduire la complexité, InnoDB traite Undo Log comme des données, de sorte que l'opération d'enregistrement d'Undo Log sera également enregistrée dans le redo log. En mettant en cache les journaux d'annulation dans la mémoire, la nécessité d'écrire les journaux de rétablissement sur le disque avant de les écrire est évitée.

Le journal de rétablissement contenant l'opération d'annulation du journal ressemble à ceci :

Enregistrement 1 : Annuler l'insertion du journal
> Enregistrement 2 : Enregistrement 3 : Annuler l'insertion du journal
Enregistrement 4 : Enregistrement 5 :
Annuler l'insertion du journal > Enregistrement 6 :
C. À ce stade, il y a toujours un problème qui n'a pas été résolu. clarifié. Puisque Redo n'est pas transactionnel, ne serait-il pas possible de réexécuter la transaction annulée ?

C'est vrai. Dans le même temps, Innodb enregistrera également les opérations lors de l'annulation des transactions dans le journal redo. Lorsqu'une opération de restauration est effectuée, les modifications apportées aux données sont enregistrées dans le journal de rétablissement, car l'opération de restauration modifie également les données.

Le journal de rétablissement d'une transaction annulée ressemble à ceci :

Enregistrement 1 : >

Enregistrement 2 : insert A
…> Enregistrement 3 : # 🎜🎜# Enregistrement 4 : update B
…>
Enregistrement 5 : ># 🎜🎜# Enregistrement 6 : delete C…>
Enregistrement 7 : insert C> enregistrement 8 : < ;trx1,
mettre à jour B vers l'ancienne valeur>
Enregistrement 9 : supprimer A># 🎜🎜#

L'opération de récupération d'une transaction annulée consiste à refaire d'abord puis à annuler, afin que la cohérence des données ne soit pas détruite.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!