MySQL (Analysis of InnoDB): --- de fichiers (fichiers du moteur de stockage InnoDB: fichiers tablespace (.ibd), fichiers de journalisation (redo log))

• Les fichiers mentionnés ci-dessus sont les fichiers de la base de données MySQL elle-même et n'ont rien à voir avec le moteur de stockage. Cet article présente des fichiers uniques liés aux moteurs de stockage. Cet article présentera des fichiers étroitement liés à InnoDB, ces fichiers incluent des fichiers de journalisation, des fichiers d'espace table

 

Premièrement, le fichier d'espace table

 

• Fonction : l'InnoDB utilise les données stockées par l'espace table (TABLESPACE) pour le stockage de la conception
• Dans la configuration par défaut, il y aura un fichier nommé idbata1 avec une taille initiale de 10 Mo (voir la figure ci-dessous) , qui est le fichier d'espace de table par défaut

 

Paramètre innodb_data_file_path

Ce paramètre est utilisé pour spécifier le fichier d'espace de table partagé utilisé par InnoDB. Une fois ce paramètre défini, les données de toutes les tables basées sur le moteur de stockage InnoDB seront enregistrées dans le tablespace partagé.
Par exemple, ce qui suit montre les fichiers tablespace utilisés par défaut par InnoDB.

show variables like 'innodb_data_file_path'\G;

Le format de réglage de ce paramètre est le suivant:

Si l'utilisateur souhaite former un espace table à travers plusieurs fichiers et formuler les attributs des fichiers, vous pouvez utiliser le format de cas suivant :
Ici, les fichiers / db / ibdata1 et / dr2 / db / ibdata2 sont utilisés pour former l'espace table . Si les deux fichiers sont situés sur des disques différents, la charge du disque peut être moyennée , de sorte que les performances globales de la base de données peuvent être améliorées

 

• Dans le même temps, le nom du fichier est suivi de l'attribut de taille de fichier: la taille de ibdata1 est de 2000 Mo, et la taille de ibdata2 est de 2000 Mo. Si la taille de 2000 Mo est utilisée, le fichier augmentera automatiquement.

Paramètres innodb_file_per_table

Si ce paramètre est défini, l'utilisateur peut générer un espace table indépendant pour chaque table basé sur le moteur de stockage InnoDB. De cette manière, les utilisateurs n'ont pas besoin de stocker toutes les données dans l'espace table par défaut. Ce paramètre est désactivé par défaut et n'utilise pas de fichiers d'espace de table indépendants

show variables like 'innodb_file_per_table'\G;

La règle de dénomination de l'espace table indépendant est: nom de la table.ibd. Il
convient de noter que ces fichiers d'espace table indépendant ne stockent que les données de table, l'index, le tampon d'insertion BITMAP et d'autres informations, ainsi que le reste des informations (telles que la restauration (annuler) les informations, insérer les pages d'index du tampon, les informations de transaction système, le tampon d'écriture secondaire, etc.) sont toujours stockés dans l'espace table par défaut. La
figure suivante montre comment le moteur de stockage InnoDB stocke les fichiers:

Le serveur de base de données MySQL suivant a défini ce paramètre. On constate que les
tables Profile, t1 et t2 sont toutes des tables basées sur le stockage InnoDB.
Le paramètre innodb_file_per_table = ON étant défini, un fichier d'espace de table indépendant .ibd est généré.

 

Deux, redo log file (redo log)

Introduction aux fichiers de journalisation:

• Par défaut, il y aura deux fichiers nommés ib_logfile0 et ib_logfile1 dans le répertoire de données du moteur de stockage InnoDB . Dans le manuel officiel de MySQL, il s'appelle le fichier journal du moteur de stockage InnoDB, mais une définition plus précise devrait être le fichier de journalisation (fichier de journalisation)

Pourquoi l'accent est-il mis sur les fichiers de journalisation?

• Les fichiers de journalisation étant vitaux pour le moteur de stockage InnoDB, ils enregistrent le journal des transactions pour le moteur de stockage InnoDB
• Lorsqu'une instance ou un support échoue, le fichier de journalisation peut s'avérer utile . Par exemple, si l'instance de base de données échoue en raison d'une panne de courant de l'hôte sur lequel elle se trouve, le moteur de stockage InnoDB utilisera le fichier de journalisation pour récupérer au moment avant la panne de courant afin de garantir l'intégrité des données.

Le concept de groupe de fichiers de journalisation

Chaque moteur de stockage InnoDB possède au moins un groupe de fichiers de journalisation. Il y a au moins deux fichiers de journalisation sous chaque groupe de fichiers (comme le ib_logfile0 par défaut et ib_logfile2).
Pour obtenir une plus grande fiabilité, les utilisateurs peuvent créer des groupes de journaux de miroir multiples et mettre différents groupes de fichiers sur des disques différents., En vue de améliorer la haute disponibilité des fichiers de journalisation

Chaque fichier de journalisation du groupe de journaux a la même taille et s'exécute en mode d'écriture circulaire . Par exemple: InnoDB a 3 fichiers de journalisation. InnoDB écrit d'abord le fichier de journalisation 0, lorsque le fichier 0 est plein, puis le fichier de journalisation 1, lorsque le fichier 1 est plein, il commence à réécrire le fichier journal 2, et lorsque la réécriture du fichier journal 2 est plein, il recommence Écrire le fichier de journalisation 0. La figure suivante montre un groupe de fichiers de journalisation avec 3 fichiers de journalisation

 

Paramètre innodb_log_file_size
Ce paramètre spécifie la taille de chaque fichier de journalisation.
Avant InnoDB 1.2.x, la taille totale du fichier de journalisation ne doit pas être supérieure ou égale à 4 Go et la version 1.2.x étend la limite à 512 Go.

show variables like 'innodb_log_file_size'\G;

Paramètre innodb_log_files_in_group
Ce paramètre spécifie le nombre de fichiers de journalisation dans le groupe de fichiers journaux. La valeur par défaut est de 2
variables d'affichage telles que'innodb_log_files_in_group '\ G;

Paramètre innodb_mirrored_log_groups
Ce paramètre spécifie le nombre de groupes de fichiers journaux miroir. La
valeur par défaut est 1, ce qui signifie qu'il n'y a qu'un seul groupe de fichiers journaux et aucune mise en miroir. Si le disque lui-même a créé une solution à haute disponibilité, telle qu'une matrice de disques, vous pouvez désactiver la fonction de mise en miroir de redo log
show variables telles que'innodb_mirrored_log_groups '\ G;

Paramètre innodb_log_group_home_dir
Ce paramètre spécifie le chemin où se trouve le groupe de fichiers journaux. La
valeur par défaut est "./", ce qui signifie
afficher des variables comme "Innodb_log_group_home_dir" \ G;

Problème de taille du fichier de journalisation Le paramètre innodb_log_file_size décrit ci-dessus est utilisé pour déterminer la taille de chaque fichier de journalisation. Le réglage de la taille du fichier de journalisation a un impact très important
sur les performances du moteur de stockage InnoDB: d'une part, le fichier de journalisation ne peut pas être défini trop volumineux, s'il est trop volumineux, cela peut prendre beaucoup de temps pour restaurer d'
autre part, le fichier de journalisation ne peut pas être défini trop petit, sinon le journal d'une transaction peut devoir changer plusieurs fois de fichier de journalisation.
De plus, le fichier de journalisation est trop petit, ce qui entraînera des point de contrôle asynchrone (voir l'article: https: // blog.csdn.net/qq_41453285/article/details/104091059), entraînant une instabilité des performances.
Par exemple, les utilisateurs peuvent voir le message d'avertissement suivant dans le journal des erreurs:
Les erreurs suivantes sont concentrées dans les deux premières lignes. Cela est dû au fait que le fichier de journalisation a une variable de capacité, qui signifie que le dernier point de contrôle ne peut pas dépasser ce seuil. S'il dépasse ce seuil, une partie des données modifiées de la liste des pages modifiées du pool de mémoire tampon doit être réécrite sur le disque, ce qui provoquera le blocage des threads utilisateur

La différence entre les fichiers de journalisation et les fichiers journaux binaires (journal bin)

Le fichier de journalisation et le journal binaire sont tous deux des journaux d'enregistrement des transactions. Les différences entre les deux sont les suivantes:

• Tout d'abord, le journal binaire enregistre tous les enregistrements de journal liés à la base de données MySQL, y compris les journaux d'autres moteurs de stockage tels que InnoDB, MyISAM et Heap. Le redo log du moteur de stockage InnoDB n'enregistre que le journal des transactions avec le moteur de stockage lui-même
• Deuxièmement, le contenu de l'enregistrement est différent. Peu importe que l'utilisateur définisse le format de l'enregistrement du fichier journal binaire sur STATEMENT, ROW ou MIXED, il enregistre le contenu d'opération spécifique d'une transaction, c'est-à-dire que le journal est un journal logique. Le fichier de journalisation du moteur de stockage InnoDB enregistre l'état physique de chaque changement de page (page)
• En outre, le temps d'écriture est également différent: le fichier journal binaire n'est soumis qu'avant la validation de la transaction, c'est-à-dire qu'il n'est écrit qu'une seule fois sur le disque, quelle que soit la taille de la transaction à ce stade. Au cours de la transaction, les entrées de journalisation sont continuellement écrites dans le fichier de journalisation

Structure des entrées de journalisation
Dans InnoDB, il existe différents formats de journalisation pour diverses opérations.Depuis
InnoDB 1.2.x, un total de 51 types de journalisation ont été définis. Bien que les types de divers fichiers de journalisation soient différents, ils ont un format de base. Le tableau suivant montre la structure des entrées de journalisation:
redo_log_type: occupe 1 octet, indiquant le type d'
espace de journalisation : indiquant l'ID de l'espace table, mais en utilisant la compression, donc l'espace occupé peut être inférieur à 4 octets
page_no: indiquant Le décalage de la page est également compressé,
redo_log_body: indique la partie données de chaque redo log, et la fonction correspondante doit être appelée pour analyse lors de la restauration

Le processus d'écriture du journal de restauration
a été mentionné dans les articles précédents. L'opération d'écriture dans le fichier de journalisation n'est pas directement écrite, mais d'abord écrite dans un tampon de journalisation, puis conformément à certaines conditions d'écriture séquentielle dans le fichier journal La
figure suivante illustre bien le processus d'écriture du journal de rétablissement:

Lors de l'écriture à partir du tampon de journalisation sur le disque, il est écrit en 512 octets, ce qui correspond à la taille d'un secteur. Étant donné que le secteur est la plus petite unité d'écriture, il peut être garanti que l'écriture doit réussir. Par conséquent, il n'est pas nécessaire de réécrire
innodb_flush_log_at_trx_commit dans le processus d'écriture du journal de rétablissement.
Comme mentionné précédemment, le tampon du journal est écrit sur le disque. Journal les fichiers sont créés selon certaines conditions. Ces conditions sont les suivantes:
L'une est mentionnée dans l'article présentant "Master Thread". Le tampon de redo log est écrit dans le fichier redo log du disque toutes les secondes dans le thread principal. Indépendamment du fait que la transaction a été validée ou non,
un autre processus qui déclenche l'écriture sur disque est contrôlé par le paramètre innodb_flush_log_trx_commit, qui indique la manière dont
le journal de rétablissement est traité pendant l'opération de validation. La valeur de ce paramètre est la suivante:
0: lorsque la transaction est validée, Il n'écrit pas le journal de rétablissement des transactions dans le fichier journal sur le disque, mais attend que le thread principal s'actualise
1 par seconde (valeur par défaut): le tampon de journalisation est écrit de manière synchrone sur le disque lorsque la validation est exécutée, c'est-à-dire , il est accompagné de fsync L'appel
2: signifie que le redo log est écrit sur le disque de manière asynchrone, c'est-à-dire dans le cache du système de fichiers
show variables comme'innodb_flush_log_at_trx_commit '\ G;

Par conséquent, il n'est pas totalement garanti que le fichier de journalisation sera écrit lors de l'exécution de la validation, mais cette action (validation) se produit.
Par conséquent, afin de garantir la durabilité dans l'ACID physique, innodb_flush_log_trx_commit doit être défini sur 1, ce qui est, chaque fois qu'une transaction est validée À ce stade, il est nécessaire de s'assurer que toutes les transactions ont été écrites dans le fichier de journalisation. Ensuite, lorsque la base de données tombe en panne en raison d'un accident, elle peut être récupérée via le fichier de journalisation, et il est garanti que les transactions validées peuvent être récupérées. Si le fichier de journalisation est défini sur 0 ou 2, une partie de la transaction peut être perdue lors de la récupération. La différence est que lorsqu'il est défini sur 2, lorsque la base de données MySQL est en panne et que le système d'exploitation et le serveur ne sont pas en panne, le journal des transactions qui n'est pas écrit sur le disque à ce moment est stocké dans le cache du système de fichiers, et il peut également être restauré lors de la restauration. Assurez-vous que les données ne sont pas perdues