Journal binaire d'exploitation et de maintenance MySQL

Le journal binaire MySQL stocke les instructions SQL qui provoquent ou peuvent provoquer des modifications de données. Des fonctions telles que la sauvegarde de reprise après sinistre à distance en temps réel, la séparation lecture-écriture et la récupération de données peuvent être réalisées via des journaux binaires. Jetons ensuite un coup d'œil au journal binaire Mysql.

Activer le journal bin-log

Mysql n'active pas le journal bin-log par défaut, nous devons ajouter la configuration nous-mêmes.

log-bin=mysql-bin
binlog_format=mixed
server-id   = 1
expire_logs_days = 10

log-bin Après avoir configuré cet élément, la fonction de journal binaire est activée. mysql-bin est le nom du fichier journal bin-log.

expire_logs_days = 10 indique que seuls les journaux bin-log des 10 derniers jours seront stockés.

Généralement, les journaux bin-log sont stockés sous le chemin d'installation de MySQL /var/

Conseils d'exploitation et de maintenance : il est préférable de ne pas placer de fichiers journaux binaires et de fichiers de données de base de données sur le même disque dur. Si le disque dur stockant les fichiers de données est cassé, vous pouvez utiliser le journal binaire d'un autre disque dur pour récupérer les données

Plusieurs commandes utiles

• vider les journaux : générer de nouveaux journaux de journaux bin-logs

• afficher l'état principal : afficher le dernier statut du journal bin-log.

• réinitialiser le maître : effacer tous les fichiers journaux bin

mysql > afficher l'état du maître

Afficher le journal Mysql

Le journal étant un journal binaire, son affichage avec la commande générale cat ou vim entraînera un code tronqué . Mysql nous fournit l'outil mysqlbinlog. Utilisez-le pour le visualiser.

./mysqlbinlog ../var/mysql-bin.000015
……
# at 123
#200601  8:35:19 server id 1  end_log_pos 154 CRC32 0xd25b404e  Previous-GTIDs
# [empty]
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
……

• at : nœud pos au démarrage de SQL

• server_id : le numéro de service de l'hôte de la base de données

• end_log_pos 154 : nœud pos à la fin de SQL

Les options courantes de Mysqlbinlog sont les suivantes :

• --start-datetime : Lit l'heure spécifiée dans le journal binaire qui est égale à l'horodatage ou postérieure à l'ordinateur local

• --stop-datetime : lit l'heure spécifiée dans le journal binaire qui est inférieure que l'horodatage ou égal à l'ordinateur local La valeur de l'heure est la même que ci-dessus

• --start-position : lit la position de l'événement de position spécifiée dans le journal binaire comme début.

• --stop-position : lit la position de l'événement de position spécifiée dans le journal binaire en tant qu'événement à compter du

• -d,-- database= name : afficher uniquement les opérations de journalisation de la base de données spécifiée

Utiliser les journaux bin-log pour récupérer les données

• Exporter le fichier SQL Commande : nom de la base de données mysqldump [nom de la table de données 1 [nom de la table de données 2...]] > Répertoire de fichiers externe (il est recommandé d'utiliser .sql)

• importation de fichiers SQL base de données : mysql - u** -p** Nom de la base de données

Simulez maintenant un scénario : une base de données est sauvegardée régulièrement à 15 heures tous les soirs, et le site Web fonctionne normalement pendant une demi-journée le lendemain. Soudain, à 17 heures, le programmeur A n'a pas accidentellement ajouté de condition WHERE lors de la suppression, puis toutes les données de l'une des tables ont été perdues. Ensuite, Xiao A a trouvé le directeur technique Dasheng et lui a demandé de l'aider à récupérer les données.

La base de données binlog_test n'a qu'une seule table utilisateur

Les données avant la sauvegarde à trois heures du matin sont les suivantes :

+---------+----------+---------------------+
| user_id | username | add_time            |
+---------+----------+---------------------+
|       1 | gwx      | 2018-07-05 13:00:31 |
|       2 | snn      | 2018-07-05 14:00:00 |
|       3 | zy       | 2018-07-05 15:00:00 |
+---------+----------+---------------------+

A 3 heures du matin le matin, les données de sauvegarde

mysqldump binlog_test -l -F > /root/sql_backup/20180706.sql
ll /root/sql_backup/
总用量 4
-rw-r--r-- 1 root root 2149 7月   6 13:42 20180706.sql
=======数据备份完成=========

Le site Web fonctionne normalement depuis un certain temps et de nombreux utilisateurs se sont inscrits

INSERT INTO `user` (username) values('user1'),('user2'),('user3');
Query OK, 3 rows affected (0.01 sec)
Records: 3  Duplicates: 0  Warnings: 0
select * from user;
+---------+----------+---------------------+
| user_id | username | add_time            |
+---------+----------+---------------------+
|       1 | gwx      | 2018-07-05 13:00:31 |
|       2 | snn      | 2018-07-05 14:00:00 |
|       3 | zy       | 2018-07-05 15:00:00 |
|       4 | user1    | 2018-07-06 15:01:18 |
|       5 | user2    | 2018-07-06 15:01:18 |
|       6 | user3    | 2018-07-06 15:01:18 |
+---------+----------+---------------------+
==============新增了3个用户user1 user2 及user3==============

A 17 heures de l'après-midi, Little A a commencé à sois stupide

DELETE FROM user;
Query OK, 6 rows affected (0.00 sec)
=========没where条件，数据全没了===========

Petit A a trouvé le Grand Sage pour aider à restaurer les données, et le Grand Sage a d'abord restauré les données d'hier Les données ont été restaurées à 3 heures du matin

service nginx stop;  # 大圣先关闭了nginx，使网站用户暂时访问不了数据库
Stoping nginx...  done 
MariaDB [binlog_test]> flush logs;  #生成新的binlog日志
MariaDB [binlog_test]> show master status;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000003 |     1536 |              |                  |
+------------------+----------+--------------+------------------+
mysql -v -f binlog_test < /root/sql_backup/20180706.sql

A ce moment, le Grand Sage avait restauré les données à 3 heures du matin hier soir

MariaDB [binlog_test]> select * from user;
+---------+----------+---------------------+
| user_id | username | add_time            |
+---------+----------+---------------------+
|       1 | gwx      | 2018-07-05 13:00:31 |
|       2 | snn      | 2018-07-05 14:00:00 |
|       3 | zy       | 2018-07-05 15:00:00 |
+---------+----------+---------------------+
=============昨晚凌晨三点数据恢复完成===============

Ensuite, les données entre 3 heures du matin et DELETE ont été restaurées

Trouvez d'abord le point de suppression du point de vente. Après la sauvegarde, le journal est 000002. Après. suppression, les journaux de vidage sont également 000003, il suffit donc de trouver le point de vente avant la suppression de 000002.

# /usr/local/mariadb/bin/mysqlbinlog --stop-position=629  >
'mysql-bin.000002' >
| mysql binlog_test;

MariaDB [binlog_test]> select * from user;
+---------+----------+---------------------+
| user_id | username | add_time            |
+---------+----------+---------------------+
|       1 | gwx      | 2018-07-05 13:00:31 |
|       2 | snn      | 2018-07-05 14:00:00 |
|       3 | zy       | 2018-07-05 15:00:00 |
|       4 | user1    | 2018-07-06 15:01:18 |
|       5 | user2    | 2018-07-06 15:01:18 |
|       6 | user3    | 2018-07-06 15:01:18 |
+---------+----------+---------------------+
==============数据都回来了========================

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!