千万不要小看日志
. Les réponses à de nombreuses questions apparemment étranges sont souvent cachées dans les journaux. Dans de nombreux cas, la cause du problème ne peut être découverte et véritablement résolue qu'en consultant les journaux. Par conséquent, vous devez apprendre à vérifier les journaux et développer l’habitude de vérifier les journaux, ce qui est crucial pour améliorer les capacités de développement de vos applications de base de données.
Adresse du journal du site officiel MySQL8.0 : "https://dev.mysql.com/doc/refman/8.0/en/server-logs.html"
1 journaux pris en charge par MySQL
1.1 Type de journal
MySQL dispose de différents types de fichiers journaux, qui sont utilisés pour stocker différents types de journaux. Ils sont divisés en 二进制日志
, et . Ce sont également les quatre types couramment utilisés 错误日志
. MySQL 8 ajoute deux nouveaux journaux pris en charge : et . En utilisant ces fichiers journaux, vous pouvez voir ce qui se passe en interne dans MySQL.通用查询日志
慢查询日志
中继日志
数据定义语句日志
Ces 6 types de journaux sont :
慢查询日志
: Enregistrez toutes les requêtes dont le temps d'exécution dépasse long_query_time, afin que nous puissions optimiser la requête.通用查询日志
: Enregistrez l'heure de début et l'heure de fin de toutes les connexions, ainsi que toutes les instructions envoyées par la connexion au serveur de base de données, ce qui nous est très utile pour restaurer le scénario réel de l'opération, trouver des problèmes et même auditer le fonctionnement de la base de données. .错误日志
: Enregistrez les problèmes qui surviennent lors du démarrage, de l'exécution ou de l'arrêt du service MySQL, afin que nous puissions comprendre l'état du serveur et maintenir le serveur.二进制日志
: Enregistre toutes les instructions qui modifient les données, qui peuvent être utilisées pour la synchronisation des données entre les serveurs maître et esclave, ainsi que pour la récupération sans perte de données lorsque le serveur rencontre une panne.中继日志
: Utilisé dans l'architecture du serveur maître-esclave, un fichier intermédiaire utilisé par le serveur esclave pour stocker le contenu du journal binaire du serveur maître. Le serveur esclave synchronise les opérations sur le serveur maître en lisant le contenu du journal relais.数据定义语句日志
: Enregistrez les opérations de métadonnées effectuées par l'instruction de définition de données.
Tous les journaux sauf les journaux binaires 文本文件
. Par défaut, tous les journaux sont créés MySQL数据目录
dans .
1.2 Inconvénients des journaux
- La fonction de journalisation le fera
降低MySQL数据库的性能
. - Séance de journal
占用大量的磁盘空间
.
2. journal des requêtes lent (journal des requêtes lent)
Le chapitre précédent « Bases de MySQL (27) Utilisation des outils d'analyse des performances » a été décrit en détail.
3. Journal des requêtes générales
Le journal général des requêtes est utilisé pour 记录用户的所有操作
inclure le démarrage et l'arrêt du service MySQL, l'heure de début et de fin de connexion de tous les utilisateurs, toutes les instructions SQL envoyées au serveur de base de données MySQL, etc. Lorsqu’une anomalie se produit dans nos données, 查看通用查询日志,还原操作时的具体场景
cela peut nous aider à localiser avec précision le problème.
3.1 Scénario de problème
3.2 Afficher l'état actuel
mysql> SHOW VARIABLES LIKE '%general%';
+------------------+------------------------------+
| Variable_name | Value |
+------------------+------------------------------+
| general_log | OFF | #通用查询日志处于关闭状态
| general_log_file | /var/lib/mysql/DESKTOP-HD37NRE.log | #通用查询日志文件的名称是DESKTOP-HD37NRE.log
+------------------+------------------------------+
2 rows in set (0.03 sec)
3.3 Journal de démarrage
Méthode 1 : Méthode permanente
Modifiez le fichier de configuration my.cnf ou my.ini à définir. Ajoutez l'option de journalisation sous le groupe [mysqld] et redémarrez le service MySQL. Le format est le suivant :
[mysqld]
general_log=ON
general_log_file=[path[filename]] #日志文件所在目录路径,filename为日志文件名
Si vous ne spécifiez pas de répertoire ni de nom de fichier, le journal des requêtes générales sera stocké par défaut dans le fichier hostname.log du répertoire de données MySQL, où hostname représente le nom d'hôte.
Méthode 2 : méthode temporaire
SET GLOBAL general_log=on; # 开启通用查询日志
SET GLOBAL general_log_file=’path/filename’; # 设置日志文件保存位置
En conséquence, la commande SQL de l’opération d’arrêt est la suivante :
SET GLOBAL general_log=off; # 关闭通用查询日志
Visualisez la situation après avoir réglé :
SHOW VARIABLES LIKE 'general_log%';
3.4 Afficher les journaux
Le journal général des requêtes est stocké dans le système de fichiers sous la forme d'un fichier texte. Vous pouvez utiliser un éditeur de texte pour ouvrir directement le fichier journal. Le contenu du journal général des requêtes est différent pour chaque serveur MySQL.
- Dans les systèmes d'exploitation Windows, utilisez une visionneuse de fichiers texte ;
- Dans les systèmes Linux, vous pouvez utiliser l'outil vi ou l'outil gedit pour afficher ;
- Dans le système Mac OSX, vous pouvez utiliser la visionneuse de fichiers texte ou vi et d'autres outils pour afficher.
À partir SHOW VARIABLES LIKE 'general_log%';
des résultats, vous pouvez voir l'emplacement du journal des requêtes générales.
/usr/sbin/mysqld, Version: 8.0.26 (MySQL Community Server - GPL). started with:
Tcp port: 3306 Unix socket: /var/lib/mysql/mysql.sock
Time Id Command Argument
2022-01-04T07:44:58.052890Z 10 Query SHOW VARIABLES LIKE '%general%'
2022-01-04T07:45:15.666672Z 10 Query SHOW VARIABLES LIKE 'general_log%'
2022-01-04T07:45:28.970765Z 10 Query select * from student
2022-01-04T07:47:38.706804Z 11 Connect root@localhost on using Socket
2022-01-04T07:47:38.707435Z 11 Query select @@version_comment limit 1
2022-01-04T07:48:21.384886Z 12 Connect root@172.16.210.1 on using TCP/IP
2022-01-04T07:48:21.385253Z 12 Query SET NAMES utf8
2022-01-04T07:48:21.385640Z 12 Query USE `test12`
2022-01-04T07:48:21.386179Z 12 Query SHOW FULL TABLES WHERE Table_Type !=
'VIEW'
2022-01-04T07:48:23.901778Z 13 Connect root@172.16.210.1 on using TCP/IP
2022-01-04T07:48:23.902128Z 13 Query SET NAMES utf8
2022-01-04T07:48:23.905179Z 13 Query USE `test`
2022-01-04T07:48:23.905825Z 13 Query SHOW FULL TABLES WHERE Table_Type !=
'VIEW'
2022-01-04T07:48:32.163833Z 14 Connect root@172.16.210.1 on using TCP/IP
2022-01-04T07:48:32.164451Z 14 Query SET NAMES utf8
2022-01-04T07:48:32.164840Z 14 Query USE `test`
2022-01-04T07:48:40.006687Z 14 Query select * from account
Dans le journal général des requêtes, nous pouvons clairement voir quand un nouveau client a été ouvert pour se connecter à la base de données, quelles opérations SQL ont été effectuées après la connexion, quelle table de données a été ciblée et d'autres informations.
3.5 Arrêter la journalisation
Méthode 1 : Méthode permanente
Modifiez le fichier my.cnf ou my.ini, définissez la valeur general_log sous le groupe [mysqld] sur OFF ou commentez l'élément general_log. Après avoir enregistré la modification, redémarrez le service MySQL pour prendre effet. Exemple 1:
[mysqld]
general_log=OFF
Exemple 2 :
[mysqld]
#general_log=ON
Méthode 2 : méthode temporaire
Utilisez l'instruction SET pour arrêter la fonction de journal des requêtes générales MySQL :
SET GLOBAL general_log=off;
Fonction de journalisation générale de requête :
SHOW VARIABLES LIKE 'general_log%';
3.6 Supprimer\actualiser le journal
Si les données sont utilisées très fréquemment, le journal général des requêtes occupera une très grande quantité d’espace disque sur le serveur. Les administrateurs de données peuvent supprimer
les journaux de requêtes d'il y a longtemps pour garantir de l'espace disque sur le serveur MySQL.
Supprimer les fichiers manuellement
SHOW VARIABLES LIKE 'general_log%';
On peut voir que le répertoire du journal général des requêtes est par défaut le répertoire de données MySQL. Supprimez manuellement le journal des requêtes générales DESKTOP-HD37NRE.log dans ce répertoire
.
Utilisez la commande suivante pour régénérer le fichier journal des requêtes. La commande spécifique est la suivante. Actualisez le répertoire de données MySQL et constatez que de nouveaux fichiers journaux ont été créés. La condition préalable doit être d'activer le journal général.
mysqladmin -uroot -p flush-logs
4. journal des erreurs
4.1 Journal de démarrage
Dans la base de données MySQL, la fonction de journal des erreurs est 默认开启
. Également, journal des erreurs 无法被禁止
.
Par défaut, le journal des erreurs est stocké dans le dossier de données de la base de données MySQL et le nom par défaut est mysqld.log
(système Linux) ou hostname.err
(système mac). Si vous devez spécifier un nom de fichier, vous devez effectuer la configuration suivante dans my.cnf ou my.ini :
[mysqld]
log-error=[path/[filename]] #path为日志文件所在的目录路径,filename为日志文件名
Après avoir modifié les éléments de configuration, vous devez redémarrer le service MySQL pour prendre effet.
4.2 Afficher les journaux
Les journaux d'erreurs MySQL sont stockés dans des fichiers texte et peuvent être consultés directement à l'aide d'un éditeur de texte.
Recherchez le chemin de stockage du journal des erreurs :
mysql> SHOW VARIABLES LIKE 'log_err%';
+----------------------------+----------------------------------------+
| Variable_name | Value |
+----------------------------+----------------------------------------+
| log_error | /var/log/mysqld.log |
| log_error_services | log_filter_internal; log_sink_internal |
| log_error_suppression_list | |
| log_error_verbosity | 2 |
+----------------------------+----------------------------------------+
4 rows in set (0.01 sec)
Vous pouvez voir dans les résultats de l'exécution que le fichier journal des erreurs est mysqld.log, qui se trouve dans le répertoire de données par défaut de MySQL.
4.3 Supprimer\actualiser le journal
Pour les journaux d'erreurs d'il y a longtemps, il est peu probable que l'administrateur de la base de données consulte ces journaux d'erreurs. Ces journaux d'erreurs peuvent être supprimés pour garantir la sécurité du serveur MySQL 硬盘空间
. Les journaux d'erreurs MySQL sont stockés dans le système de fichiers sous forme de fichiers texte, oui 直接删除
.
[root@atguigu01 log]# mysqladmin -uroot -p flush-logs
Enter password:
mysqladmin: refresh failed; error: 'Could not open file '/var/log/mysqld.log' for
error logging.'
Conseils sur le site officiel :
Opérations supplémentaires :
install -omysql -gmysql -m0644 /dev/null /var/log/mysqld.log
5. Journal binaire (journal bin
Binlog peut être considéré comme le journal le plus populaire dans MySQL 重要
. Il est souvent rencontré lors du développement, de l'exploitation et de la maintenance quotidiens.
Binlog est un journal binaire, un fichier journal binaire, également appelé journal des modifications (journal de mise à jour). Il enregistre toutes les instructions exécutées par la base de données DDL
et les autres événements de mise à jour de la base de données, mais n'inclut pas les instructions qui ne modifient aucune donnée (telles que les instructions de requête de données select, show, etc.).DML
Principaux scénarios d'application de binlog :
- L'un est pour
数据恢复
- Deuxièmement, il est utilisé pour
数据复制
5.1 Afficher les conditions par défaut
Vérifiez si la journalisation binaire est activée : par défaut dans MySQL8, les fichiers binaires sont activés.
mysql> show variables like '%log_bin%';
+---------------------------------+----------------------------------+
| Variable_name | Value |
+---------------------------------+----------------------------------+
| log_bin | ON |
| log_bin_basename | /var/lib/mysql/binlog |
| log_bin_index | /var/lib/mysql/binlog.index |
| log_bin_trust_function_creators | OFF |
| log_bin_use_v1_row_events | OFF |
| sql_log_bin | ON |
+---------------------------------+----------------------------------+
6 rows in set (0.00 sec)
5.2 Paramètres de journalisation
Méthode 1 : Méthode permanente
Modifiez le MySQL my.cnf
ou my.ini
le fichier pour définir les paramètres pertinents du journal binaire :
[mysqld]
#启用二进制日志
log-bin=atguigu-bin
binlog_expire_logs_seconds=600
max_binlog_size=100M
Redémarrez le service MySQL et interrogez les informations du journal binaire. Les résultats de l'exécution sont :
mysql> show variables like '%log_bin%';
+---------------------------------+----------------------------------+
| Variable_name | Value |
+---------------------------------+----------------------------------+
| log_bin | ON |
| log_bin_basename | /var/lib/mysql/atguigu-bin |
| log_bin_index | /var/lib/mysql/atguigu-bin.index |
| log_bin_trust_function_creators | OFF |
| log_bin_use_v1_row_events | OFF |
| sql_log_bin | ON |
+---------------------------------+----------------------------------+
6 rows in set (0.00 sec)
Définir le répertoire de stockage des journaux bin-log avec un dossier
Si vous souhaitez modifier le répertoire et le nom du fichier journal, vous pouvez modifier le paramètre log_bin dans my.cnf ou my.ini comme suit :
[mysqld]
log-bin="/var/lib/mysql/binlog/atguigu-bin"
Remarque : Le dossier nouvellement créé nécessite l'utilisateur mysql, utilisez simplement la commande suivante.
chown -R -v mysql:mysql binlog
Méthode 2 : Méthode temporaire
Si vous ne souhaitez pas définir le journal binaire en modifiant le fichier de configuration et en redémarrant, vous pouvez également utiliser les instructions suivantes. A noter que dans mysql8, il n'y a que des paramètres et aucun paramètre de niveau global 会话级别
.
# global 级别
mysql> set global sql_log_bin=0;
ERROR 1228 (HY000): Variable 'sql_log_bin' is a SESSION variable and can`t be used
with SET GLOBAL
# session级别
mysql> SET sql_log_bin=0;
Query OK, 0 rows affected (0.01 秒)
5.3 Afficher les journaux
Lorsque MySQL crée un fichier journal binaire, il crée d'abord un fichier avec "nom de fichier" comme nom et ".index" comme suffixe, puis crée un fichier avec "nom de fichier" comme nom et ".000001" comme suffixe.
Pour le service MySQL 重新启动一次
, un fichier avec le suffixe ".000001" sera ajouté et le nom du suffixe sera incrémenté de 1. Autrement dit, le nombre de fichiers journaux est le même que le nombre de démarrages du service MySQL ; si la longueur du journal dépasse la max_binlog_size
limite supérieure (la valeur par défaut est de 1 Go), un nouveau fichier journal sera créé.
Affichez la liste et la taille actuelles des fichiers journaux binaires. Les instructions sont les suivantes :
mysql> SHOW BINARY LOGS;
+--------------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+--------------------+-----------+-----------+
| atguigu-bin.000001 | 156 | No |
+--------------------+-----------+-----------+
1 行于数据集 (0.02 秒)
La commande suivante 伪SQL的形式
affiche les événements de ligne sous la forme
mysqlbinlog -v "/var/lib/mysql/binlog/atguigu-bin.000002"
#220105 9:16:37 server id 1 end_log_pos 324 CRC32 0x6b31978b Query thread_id=10
exec_time=0 error_code=0
SET TIMESTAMP=1641345397/*!*/;
SET @@session.pseudo_thread_id=10/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0,
@@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1168113696/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8mb3 *//*!*/;
SET
@@session.character_set_client=33,@@session.collation_connection=33,@@session.collatio
n_server=255/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
/*!80011 SET @@session.default_collation_for_utf8mb4=255*//*!*/;
BEGIN
/*!*/;
# at 324
#220105 9:16:37 server id 1 end_log_pos 391 CRC32 0x74f89890 Table_map:
`atguigu14`.`student` mapped to number 85
# at 391
#220105 9:16:37 server id 1 end_log_pos 470 CRC32 0xc9920491 Update_rows: table id
85 flags: STMT_END_F
BINLOG '
dfHUYRMBAAAAQwAAAIcBAAAAAFUAAAAAAAEACWF0Z3VpZ3UxNAAHc3R1ZGVudAADAw8PBDwAHgAG
AQEAAgEhkJj4dA==
dfHUYR8BAAAATwAAANYBAAAAAFUAAAAAAAEAAgAD//8AAQAAAAblvKDkuIkG5LiA54+tAAEAAAAL
5byg5LiJX2JhY2sG5LiA54+tkQSSyQ==
'/*!*/;
### UPDATE `atguigu`.`student`
### WHERE
### @1=1
### @2='张三'
### @3='一班'
### SET
### @1=1
### @2='张三_back'
### @3='一班'
# at 470
#220105 9:16:37 server id 1 end_log_pos 501 CRC32 0xca01d30f Xid = 15
COMMIT/*!*/;
La commande précédente affiche également l'instruction au format binlog. Utilisez la commande suivante pour ne pas l'afficher.
mysqlbinlog -v --base64-output=DECODE-ROWS "/var/lib/mysql/binlog/atguigu-bin.000002"
#220105 9:16:37 server id 1 end_log_pos 324 CRC32 0x6b31978b Query thread_id=10
exec_time=0 error_code=0
SET TIMESTAMP=1641345397/*!*/;
SET @@session.pseudo_thread_id=10/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0,
@@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1168113696/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8mb3 *//*!*/;
SET
@@session.character_set_client=33,@@session.collation_connection=33,@@session.collatio
n_server=255/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
/*!80011 SET @@session.default_collation_for_utf8mb4=255*//*!*/;
BEGIN
/*!*/;
# at 324
#220105 9:16:37 server id 1 end_log_pos 391 CRC32 0x74f89890 Table_map:
`atguigu14`.`student` mapped to number 85
# at 391
#220105 9:16:37 server id 1 end_log_pos 470 CRC32 0xc9920491 Update_rows: table id
85 flags: STMT_END_F
### UPDATE `atguigu14`.`student`
### WHERE
### @1=1
### @2='张三'
### @3='一班'
### SET
### @1=1
### @2='张三_back'
### @3='一班'
# at 470
#220105 9:16:37 server id 1 end_log_pos 501 CRC32 0xca01d30f Xid = 15
Il existe de nombreuses techniques pour utiliser l'outil mysqlbinlog, comme par exemple analyser uniquement les opérations sur une certaine bibliothèque ou les opérations sur une certaine période de temps. Je vais simplement partager quelques instructions couramment utilisées. Pour plus d'opérations, veuillez vous référer à la documentation officielle.
# 可查看参数帮助
mysqlbinlog --no-defaults --help
# 查看最后100行
mysqlbinlog --no-defaults --base64-output=decode-rows -vv atguigu-bin.000002 |tail
-100
# 根据position查找
mysqlbinlog --no-defaults --base64-output=decode-rows -vv atguigu-bin.000002 |grep -A
20 '4939002'
La méthode ci-dessus lit une grande partie du contenu en texte intégral du journal binlog, et il n'est pas facile de distinguer et d'afficher les informations du point de vente. Voici une commande de requête plus pratique :
mysql> show binlog events [IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count];
IN 'log_name'
: Spécifiez le nom du fichier binlog à interroger (s'il n'est pas spécifié, ce sera le premier fichier binlog)FROM pos
: Spécifiez à partir du point de départ pos à partir duquel commencer la recherche (s'il n'est pas spécifié, elle commencera à partir du premier point pos de l'ensemble du fichier)LIMIT [offset]
: Décalage (0 si non spécifié)row_count
: Interrogez le nombre total de lignes (toutes les lignes si non spécifiées)
mysql> show binlog events in 'atguigu-bin.000002';
+--------------------+-----+----------------+-----------+-------------+---------------
--------------------------------------------------------------+
| Log_name | Pos | Event_type | Server_id | End_log_pos | Info
|
+--------------------+-----+----------------+-----------+-------------+---------------
--------------------------------------------------------------+
| atguigu-bin.000002 | 4 | Format_desc | 1 | 125 | Server ver:
8.0.26, Binlog ver: 4 |
| atguigu-bin.000002 | 125 | Previous_gtids | 1 | 156 |
|
| atguigu-bin.000002 | 156 | Anonymous_Gtid | 1 | 235 | SET
@@SESSION.GTID_NEXT= 'ANONYMOUS' |
| atguigu-bin.000002 | 235 | Query | 1 | 324 | BEGIN
|
| atguigu-bin.000002 | 324 | Table_map | 1 | 391 | table_id: 85
(atguigu14.student) |
| atguigu-bin.000002 | 391 | Update_rows | 1 | 470 | table_id: 85
flags: STMT_END_F |
| atguigu-bin.000002 | 470 | Xid | 1 | 501 | COMMIT /*
xid=15 */ |
| atguigu-bin.000002 | 501 | Anonymous_Gtid | 1 | 578 | SET
@@SESSION.GTID_NEXT= 'ANONYMOUS' |
| atguigu-bin.000002 | 578 | Query | 1 | 721 | use
`atguigu14`; create table test(id int, title varchar(100)) /* xid=19 */ |
| atguigu-bin.000002 | 721 | Anonymous_Gtid | 1 | 800 | SET
@@SESSION.GTID_NEXT= 'ANONYMOUS' |
| atguigu-bin.000002 | 800 | Query | 1 | 880 | BEGIN
|
| atguigu-bin.000002 | 880 | Table_map | 1 | 943 | table_id: 89
(atguigu14.test) |
| atguigu-bin.000002 | 943 | Write_rows | 1 | 992 | table_id: 89
flags: STMT_END_F |
| atguigu-bin.000002 | 992 | Xid | 1 | 1023 | COMMIT /*
xid=21 */
+--------------------+-----+----------------+-----------+-------------+---------------
--------------------------------------------------------------+
14 行于数据集 (0.02 秒)
Ce que nous avons dit ci-dessus est basé sur le format par défaut de binlog. Affichez-le au format binlog.
mysql> show variables like 'binlog_format';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | ROW |
+---------------+-------+
1 行于数据集 (0.02 秒)
De plus, binlog a deux formats, à savoir Statement
etMixed
- Chaque instruction SQL
qui modifie les données sera enregistrée dans le binlog.
Avantages : pas besoin d'enregistrer les modifications dans chaque ligne, ce qui réduit la quantité de journaux binlog, économise les E/S et améliore les performances. - La version Row
5.1.5 de MySQL commence seulement à prendre en charge la réplication au niveau des lignes. Elle n'enregistre pas les informations liées au contexte des instructions SQL, mais enregistre uniquement les enregistrements qui ont été modifiés.
Avantages : Le contenu du journal au niveau des lignes enregistrera clairement les détails de chaque ligne de modification de données. Et il n'y aura aucun problème si les procédures stockées, les fonctions et les appels et déclencheurs de déclencheurs ne peuvent pas être copiés correctement dans certaines circonstances. - Mixed
À partir de la version 5.1.8, MySQL propose un format Mixed, qui est en fait une combinaison de Statement et Row.
Les détails seront expliqués dans le chapitre suivant.
5.4 Utiliser les journaux pour récupérer des données
La syntaxe permettant à mysqlbinlog de restaurer les données est la suivante :
mysqlbinlog [option] filename|mysql –uuser -ppass;
Cette commande peut être comprise comme suit : utilisez la commande mysqlbinlog pour lire le contenu du nom de fichier, puis utilisez la commande mysql pour restaurer le contenu dans la base de données.
-
filename
: est le nom du fichier journal. -
option
: Facultatif. Les deux paires de paramètres d'option les plus importantes sont –start-date, –stop-date et –start-position, –stop-position.--start-date 和 --stop-date
: Vous pouvez spécifier le point temporel de début et le point temporel de fin pour la récupération de la base de données.--start-position和--stop-position
: Vous pouvez spécifier la position de départ et la position de fin des données récupérées.
Remarque : Lorsque vous utilisez la commande mysqlbinlog pour effectuer des opérations de récupération, le plus petit nombre doit être restauré en premier. Par exemple, atguigu-bin.000001 doit être restauré avant atguigu-bin.000002.
5.5 Supprimer les journaux binaires
Les fichiers binaires MySQL peuvent être configurés pour être automatiquement supprimés, et MySQL fournit également une méthode sûre pour supprimer manuellement les fichiers binaires. PURGE MASTER LOGS
Supprimez uniquement la partie spécifiée des fichiers journaux binaires et RESET MASTER
supprimez tous les fichiers journaux binaires. détails comme suit :
1. PURGER LES JOURNAUX MAÎTRES : supprimer les fichiers journaux spécifiés
La syntaxe de PURGE MASTER LOGS est la suivante :
PURGE {MASTER | BINARY} LOGS TO ‘指定日志文件名’
PURGE {MASTER | BINARY} LOGS BEFORE ‘指定日期’
5.6 Autres scénarios
全量备份
Les journaux binaires peuvent être enregistrés dans la base de données et les journaux binaires 增量信息
pour compléter la base de données 无损失恢复
. Cependant, si vous rencontrez un scénario avec une grande quantité de données et de nombreuses bases de données et tables de données (comme l'application de bases de données et de tables de partitionnement), il est très difficile d'utiliser des journaux binaires pour la récupération de données car les positions de début et de fin sont pas facile à gérer.
Dans ce cas, une solution efficace consiste à synchroniser le contenu du fichier journal binaire avec le serveur de base de données esclave via le journal de relais, 配置主从数据库服务器
même dans 一主多从
une architecture, afin que les problèmes tels que les anomalies de données causées par des pannes de base de données puissent être efficacement évités.
6. Parlons encore du journal binaire (binlog)
6.1 Mécanisme d'écriture
Le moment d'écriture du binlog est également très simple. Lors de l'exécution de la transaction, le journal est écrit en premier binlog cache
et lorsque la transaction est soumise,
le cache binlog est écrit dans le fichier binlog. Étant donné que le journal binaire d'une transaction ne peut pas être divisé, quelle que soit la taille de la transaction, il doit être
écrit une fois, de sorte que le système alloue un bloc de mémoire à chaque thread en tant que cache du journal binaire.
Le timing d'écriture et de fsync peut être contrôlé par le paramètre sync_binlog, et la valeur par défaut est 0. Lorsqu'il vaut 0, cela signifie que seule l'écriture est effectuée à chaque fois qu'une transaction est soumise et que le système détermine quand exécuter fsync. Bien que les performances soient améliorées, si la machine tombe en panne, le binglog dans le cache des pages
sera perdu. Comme indiqué ci-dessous :
Pour des raisons de sécurité, cela peut être défini pour 1
signifier que fsync sera exécuté à chaque fois qu'une transaction est soumise, tout comme la redo log 刷盘流程
même chose.
Enfin, il existe un compromis, qui peut être défini sur N (N>1), ce qui signifie écrire à chaque fois qu'une transaction est soumise, mais fsync seulement après que N transactions ont été accumulées.
Dans les scénarios où des goulots d'étranglement d'E/S se produisent, la définition de sync_binlog sur une valeur relativement élevée peut améliorer les performances. De même, si la machine tombe en panne, les journaux binlog des N dernières transactions seront perdus.
6.2 Comparaison entre binlog et redolog
- redo log Il
物理日志
enregistre "quelles modifications ont été apportées sur une certaine page de données" et est généré par la couche du moteur de stockage InnoDB. - Dans binlog
逻辑日志
, le contenu de l'enregistrement est la logique originale de l'instruction, similaire à "ajouter 1 au champ c de la ligne avec ID=2", qui appartient à la couche MySQL Server.
6.3 Soumission en deux étapes
Pendant l'exécution de l'instruction de mise à jour, deux journaux, redo log et binlog, seront enregistrés. Sur la base des transactions de base, le redo log peut être écrit en continu pendant l'exécution de la transaction, tandis que le binlog ne peut être écrit que lorsqu'une transaction est soumise, donc redo log et binlog 写入时机
est différent.
redo log与binlog两份日志之间的逻辑不一致,会出现什么问题?
Étant donné que le journal binaire est anormal avant d'être terminé, il n'y a aucun enregistrement de modification correspondant dans le journal binaire pour le moment.
Afin de résoudre le problème de cohérence logique entre les deux logs, le moteur de stockage InnoDB utilise 两阶段提交
une solution.
Après utilisation 两阶段提交
, il n'y aura aucun impact si une exception se produit lors de l'écriture dans binlog.
Dans un autre scénario, si une exception se produit pendant la phase de validation des paramètres de journalisation, la transaction sera-t-elle annulée ?
Il n'annulera pas la transaction, il exécutera la logique décrite dans la figure ci-dessus. Bien que le journal redo soit en phase de préparation, le journal binlog correspondant peut être trouvé via l'ID de transaction, donc MySQL le considère comme terminé et soumettra le transaction pour restaurer les données.
7. Journal de relais
7.1 Introduction
中继日志只在主从服务器架构的从服务器上存在
. Afin d'être cohérent avec le serveur maître, le serveur esclave doit lire le contenu du journal binaire du serveur maître et écrire les informations lues dans 本地的日志文件
. Le fichier journal local de ce serveur esclave est appelé 中继日志
. Ensuite, le serveur esclave lit le journal de relais et met à jour les données du serveur esclave en fonction du contenu du journal de relais pour compléter le serveur maître-esclave 数据同步
.
Après avoir configuré le serveur maître-esclave, le journal du relais sera enregistré par défaut dans le répertoire de données du serveur esclave.
Le format du nom de fichier est : 从服务器名 -relay-bin.序号
. Le journal de relais contient également un fichier d'index : 从服务器名 -relaybin.index
, qui est utilisé pour localiser le journal de relais actuellement utilisé.
7.2 Afficher les journaux de relais
Les journaux de relais ont le même format que les journaux binaires et peuvent être mysqlbinlog
consultés à l'aide de l'outil. Voici un extrait du journal du relais :
SET TIMESTAMP=1618558728/*!*/;
BEGIN
/*!*/;
# at 950
#210416 15:38:48 server id 1 end_log_pos 832 CRC32 0xcc16d651 Table_map:
`atguigu`.`test` mapped to number 91
# at 1000
#210416 15:38:48 server id 1 end_log_pos 872 CRC32 0x07e4047c Delete_rows: table id
91 flags: STMT_END_F -- server id 1 是主服务器,意思是主服务器删了一行数据
BINLOG '
CD95YBMBAAAAMgAAAEADAAAAAFsAAAAAAAEABGRlbW8ABHRlc3QAAQMAAQEBAFHWFsw=
CD95YCABAAAAKAAAAGgDAAAAAFsAAAAAAAEAAgAB/wABAAAAfATkBw==
'/*!*/;
# at 1040
Le sens de ce paragraphe est que le serveur principal ("server id 1") a effectué 2 étapes sur la table atguigu.test :
定位到表 atguigu.test 编号是 91 的记录,日志位置是 832;
删除编号是 91 的记录,日志位置是 872。
7.3 Erreurs typiques lors de la récupération
Si le serveur esclave tombe en panne, le système d'exploitation doit parfois être réinstallé pour la récupération du système, ce qui peut rendre votre situation différente 服务器名称
de celle d'avant 不同
. Et le journal du relais est 包含从服务器名
. Dans ce cas, lorsque vous restaurez le serveur esclave, vous ne pourrez peut-être pas lire les données du journal du relais avant le temps d'arrêt. Vous pouvez penser que le fichier journal est endommagé, mais en fait le nom est erroné.
La solution est également très simple, remettez le nom du serveur esclave au nom précédent.