1. Three formats of bin log

1. statement: SQL statement-based replication (statement-based replication, SBR)

Every sql that modifies data will be recorded in binlog.

Advantages: There is no need to record the changes of each row, which reduces the amount of binlog logs, saves IO, and improves performance. But pay attention to how much performance and log volume can be saved by statement compared with row, depending on the SQL situation of the application. Normally, the amount of logs generated by modifying or inserting the same record in the row format is smaller than that generated by the Statement, but considering the conditional update operation, deletion of the entire table, alter table and other operations, the ROW format will generate a large number of logs, so When considering whether to use ROW format logs, it should be based on the actual situation of the application, how much the log volume will increase, and the IO performance problems it will bring.

Disadvantages: Since only execution statements are recorded, in order for these statements to run correctly on the slave, we must also record some relevant information when each statement is executed, so as to ensure that all statements can get the same results on the slave as they are executed on the master side. . In addition, if some specific functions are to be consistent on the slave and the master, there will be many related problems.

2. row: row-based replication (row-based replication, RBR)

Version 5.1.5 of MySQL only started to support row level replication. It does not record the relevant information of the SQL statement context, but only saves which record has been modified.

Advantages: The binlog does not need to record the context-related information of the executed SQL statement, but only needs to record what the record has been modified to. Therefore, the row level log will record the details of each row of data modification very clearly. And there will be no problem that the stored procedure, function, or trigger call and trigger cannot be copied correctly in some specific cases.

Disadvantages: When all executed statements are recorded in the log, they will be recorded as the modification of each line record, which may generate a large amount of log content. However, the new version of MySQL optimizes the row level mode. Not all modifications will be recorded at the row level. For example, when the table structure changes, it will be recorded in the statement mode. If the SQL statement is indeed update or delete, etc. The statement that modifies the data, then the changes of all rows will still be recorded.

3. mixed: mixed mode replication (mixed-based replication, MBR)

Starting from version 5.1.8, MySQL provides a Mixed format, which is actually a combination of Statement and Row.

In Mixed mode, the general statement modification uses the statment format to save the binlog. If some functions and statements cannot complete the master-slave replication operation, the row format is used to save the binlog. MySQL will treat the records differently according to each specific SQL statement executed. The log form, that is, choose one between Statement and Row.

4. View mode and change mode
mysql> show variables like 'binlog_format';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | MIXED |
+---------------+-------+
1 row in set, 1 warning (0.00 sec)

mysql> set binlog_format=mixed;
Query OK, 0 rows affected (0.00 sec)
2. Configure the bin log strategy

In the configuration file add
[mysqld]

# 指定 binary log 的路径和名称
log-bin="/var/lib/mysql/binlog"

# 存活时间
binlog_expire_logs_seconds=60000

# 单个 binlog 文件的最大大小
max_binlog_size=100M

# binlog的日志策略
binlog_format=mixed;
3. Obtain the list of bin log files
mysql> show binary logs;
+------------------+-----------+-----------+
| Log_name         | File_size | Encrypted |
+------------------+-----------+-----------+
| IU077-bin.000038 |       157 | No        |
| IU077-bin.000039 |      1400 | No        |
| IU077-bin.000040 |       157 | No        |
| IU077-bin.000041 |       333 | No        |
| IU077-bin.000042 |       157 | No        |
| IU077-bin.000043 |       157 | No        |
| IU077-bin.000044 |       157 | No        |
| IU077-bin.000045 |       157 | No        |
| IU077-bin.000046 |       157 | No        |
| IU077-bin.000047 |       157 | No        |
| IU077-bin.000048 |       180 | No        |
| IU077-bin.000049 |       180 | No        |
| IU077-bin.000050 |       157 | No        |
| IU077-bin.000051 |       157 | No        |
+------------------+-----------+-----------+
Fourth, generate a new bin log file

The following three situations can generate a new bin log

Whenever we stop or restart the server, the server will record the log file into the next log file, and MySQL will generate a new log file when restarting, and the file sequence number will increase.

If the log file exceeds the upper limit of the max_binlog_size (default value 1G) system variable configuration, a new log file will also be generated (it should be noted here that if you are using a large transaction, the binary log will exceed max_binlog_size and will not be generated In the new log file, all transactions are written into a binary log, which is mainly to ensure the integrity of the transaction)

Manual flush logs to refresh the log will generate a new log file;
mysql> flush logs;
Query OK, 0 rows affected (0.07 sec)
5. View the contents of the log

1. Use show binlog events in mysql to view

View the contents of a specific log:
mysql> show binlog events in 'IU077-bin.000052';
+------------------+-----+----------------+-----------+-------------+-----------------------------------------------------------------------+
| Log_name         | Pos | Event_type     | Server_id | End_log_pos | Info                                                                  |
+------------------+-----+----------------+-----------+-------------+-----------------------------------------------------------------------+
| IU077-bin.000052 |   4 | Format_desc    |         1 |         126 | Server ver: 8.0.30, Binlog ver: 4                                     |
| IU077-bin.000052 | 126 | Previous_gtids |         1 |         157 |                                                                       |
| IU077-bin.000052 | 157 | Anonymous_Gtid |         1 |         234 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS'                                  |
| IU077-bin.000052 | 234 | Query          |         1 |         345 | create database db_16 /* xid=20 */                                    |
| IU077-bin.000052 | 345 | Anonymous_Gtid |         1 |         422 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS'                                  |
| IU077-bin.000052 | 422 | Query          |         1 |         555 | use `db_16`; create table tb1(id int, lname varchar(20)) /* xid=24 */ |
| IU077-bin.000052 | 555 | Anonymous_Gtid |         1 |         634 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS'                                  |
| IU077-bin.000052 | 634 | Query          |         1 |         710 | BEGIN                                                                 |
| IU077-bin.000052 | 710 | Table_map      |         1 |         768 | table_id: 92 (db_16.tb1)                                              |
| IU077-bin.000052 | 768 | Write_rows     |         1 |         821 | table_id: 92 flags: STMT_END_F                                        |
| IU077-bin.000052 | 821 | Xid            |         1 |         852 | COMMIT /* xid=26 */                                                   |
| IU077-bin.000052 | 852 | Rotate         |         1 |         899 | IU077-bin.000053;pos=4                                                |
+------------------+-----+----------------+-----------+-------------+-----------------------------------------------------------------------+
12 rows in set (0.00 sec)
Specify to start viewing from a certain pos
mysql> show binlog events in 'IU077-bin.000052' from 710;
+------------------+-----+------------+-----------+-------------+--------------------------------+
| Log_name         | Pos | Event_type | Server_id | End_log_pos | Info                           |
+------------------+-----+------------+-----------+-------------+--------------------------------+
| IU077-bin.000052 | 710 | Table_map  |         1 |         768 | table_id: 92 (db_16.tb1)       |
| IU077-bin.000052 | 768 | Write_rows |         1 |         821 | table_id: 92 flags: STMT_END_F |
| IU077-bin.000052 | 821 | Xid        |         1 |         852 | COMMIT /* xid=26 */            |
| IU077-bin.000052 | 852 | Rotate     |         1 |         899 | IU077-bin.000053;pos=4         |
+------------------+-----+------------+-----------+-------------+--------------------------------+
4 rows in set (0.00 sec)
View the log status currently being written:
mysql> show master status\G
*************************** 1. row ***************************
             File: IU077-bin.000053
         Position: 157
     Binlog_Do_DB:
 Binlog_Ignore_DB:
Executed_Gtid_Set:
1 row in set (0.00 sec)
2. Use mysqlbinlog in the shell to view
mysqlbinlog -v 日志文件的路径

例如：
mysqlbinlog -v /usr/local/mysql/data/binlog.000010
6. Use bin log to restore data

Notice:

The bin log does not recover data by rolling back, but by re-executing SQL statements.

1. Restore through pos

Method 1: Execute mysql login and switch in the shell
mysqlbinlog --start-position=100 --stop-position=300 --database=数据库名 binlog文件 | mysql -uroot -p密码 -v 数据库名
Method 2: Generate a script with a .sql suffix, and then execute the script in mysql
# 第一步：先生成sql脚本
mysqlbinlog --start-position=100 --stop-position=300 --database=数据库名 binlog文件 > resume.sql

# 第二步：在sql中执行该脚本
mysql> source 脚本路径/脚本名称
2. Recovery through time

Change position to datetime or timestamp

2. Logical backup and recovery

1. The mysqldump tool realizes logical backup

Basic operation:
# 备份单个数据库
mysqldump -uroot -p密码 database_1 > database_1.sql

# 备份全部数据库
mysqldump -uroot -p密码 --all-databases
# 或者
mysqldump -uroot -p密码 --A
More detailed operation:

parameter effect

--databases or -B back up part of the database

The database name followed by the table name backup partial table

--where="id < 10" Partial data in the backup table

--ignore-table=database.tablename do not back up this table

--no-create-info No structure is backed up, only the data

--no_data do not back up data

2. Logic recovery

1. Restore in the shell
mysql -uroot -p密码 数据库名 < .sql脚本
2. Restore in mysql
mysql> source 脚本路径/脚本名称.sql

3. Physical backup and recovery

1. Physical backup

1. Lock the database first to prevent the database from being modified during the backup process
mysql> flush tables with read lock;
2. Physical copy backup
cp -r database_1 /backup/database_1_bak
3. Unlock the database (must not forget to unlock)
mysql> unlock tables;
2. Physical recovery

1. Physical movement
cp 数据库 路径/名称
2. Restart the mysql service
systemctl restart mysql
3. Grant permissions to the mysql user
chown -R mysql.mysql /var/lib/mysql/数据库名

Fourth, the export and import of the database

1. Export

1. Export through INTO OUTFILE

1. First check whether the database can be exported

mysql> show variables like '%secure%';
+--------------------------+------------------------------------------------+
| Variable_name            | Value                                          |
+--------------------------+------------------------------------------------+
| require_secure_transport | OFF                                            |
| secure_file_priv         | D:\Program Files (x86)\MySQL\Data 8.0\Uploads\ |
+--------------------------+------------------------------------------------+

2. Start exporting

mysql> select * from tb1 INTO OUTFILE "D:\Program Files (x86)\MySQL\Data 8.0\Uploads\tb1.txt";

2. Use mysqldump to export

Generate txt files and sql scripts at the same time

mysqldump -uroot -p密码 -T "路径" 数据库名 表名;

3. Use the mysql command to export

Export the query content to a txt file

mysql -uroot -p密码 --execute="select * from tb1;" 数据库名 > 名字.txt;

Two, import

1. LOAD DATA INFILE import

mysql> LOAD DATA INFILE 'txt文本文件' INTO TABLE dbname.tbname;

5. Recovery steps for accidentally deleted database

Take the most recent full backup.

Restore a temporary library with a full backup.

Take out the bin log log after the full backup.

Eliminate misoperation SQL in the log, and apply other statements to the temporary library.

After the reply is complete, restore the temporary library to the main library.

Backup, restore, export, import of MySQL database (bin log and mydump)

Table of contents

1. Use bin log to restore data

1. Three formats of bin log

1. statement: SQL statement-based replication (statement-based replication, SBR)

2. row: row-based replication (row-based replication, RBR)

3. mixed: mixed mode replication (mixed-based replication, MBR)

4. View mode and change mode

2. Configure the bin log strategy

3. Obtain the list of bin log files

Fourth, generate a new bin log file

5. View the contents of the log

1. Use show binlog events in mysql to view

2. Use mysqlbinlog in the shell to view

6. Use bin log to restore data

1. Restore through pos

2. Recovery through time

2. Logical backup and recovery

1. The mysqldump tool realizes logical backup

2. Logic recovery

3. Physical backup and recovery

1. Physical backup

2. Physical recovery

Fourth, the export and import of the database

1. Export

1. Export through INTO OUTFILE

2. Use mysqldump to export

3. Use the mysql command to export

Two, import

5. Recovery steps for accidentally deleted database

Guess you like

parameter	effect
--databases or -B	back up part of the database
The database name followed by the table name	backup partial table
--where="id < 10"	Partial data in the backup table
--ignore-table=database.tablename	do not back up this table
--no-create-info	No structure is backed up, only the data
--no_data	do not back up data