Mysql backup and restore

1. The main purpose of backup is disaster recovery 2. In a production environment, data security is crucial 3. Any loss of data may have serious consequences 4. Reasons for data loss

Program errors Human error Operation errors Disk failure Disasters (such as fires, earthquakes) and theft

Two, database backup type

2.1 Physical backup

Database backup can be divided into physical backup and logical backup. Physical backup is the backup of the physical files (such as data files, log files, etc.) of the database operating system. This type of backup is suitable for large and important databases that need to be restored quickly in the event of a problem. Physical backups can be cold backups (offline backups), hot backups (connected backups) and warm backups

① Cold backup (offline backup): It is performed when the database is closed (tar) ② Hot backup (online backup): The database is running and depends on the log file of the database (mysqlhotcopy mysqlbackup) ③ Warm backup: The database is locked (not writable but readable) and the backup operation is performed (mysqldump)

2.2 Logical backup ⭐⭐⭐

A logical backup is a backup of the logical components of a database. Expressed as a logical database structure, this type of backup is suitable for data values or table structures that can be edited

From the perspective of database backup strategy, backup can be divided into full backup, differential backup and incremental backup

① Full backup *** Every time a full backup is performed on the data, that is, the backup of the entire database, database structure and file structure, the database at the time the backup is completed is saved, which is the basis of differential backup and incremental backup.

Performing a full backup every time will cause the backup file to occupy a huge space and have a large amount of duplicate data. When restoring, you can directly use the full backup file

② Differential backup backs up all files that have been modified since the last full backup. The backup time node is from the last full backup, and the amount of backup data will become larger and larger. When restoring data, only the last full backup and the best differential backup need to be restored

For each differential backup, the data after the last full backup will be backed up, and duplicate data may appear. When restoring, restore the full backup data first, and then restore the differential backup data

③ Incremental backup *** Only those files that have been modified after the last full backup or incremental backup will be backed up. The time of the last full backup or last incremental backup is taken as the time point, and only the data changes during the backup period, so the amount of data backed up is small, the space occupied is small, and the backup speed is fast. However, when restoring, all increments from the last full backup to the last incremental backup need to be restored sequentially. If the backup data in the middle is damaged, it will cause data loss.

Each incremental backup is to back up the data after the last full backup or incremental backup. There will be no duplication of data, and no additional disk space will be occupied to restore data. You need to restore the data of the full backup and incremental backup in order

Backup method comparison

Backup method Full backup Differential backup Incremental backup
Status at full backup Table 1, Table 2 Table 1, Table 2 Table 1, Table 2
Add content for the first time Create Table 3 Create Table 3 Create Table 3
Backup content Table 1, Table 2, Table 3 Table 3 Table 3
The second time to add content Create Table 4 Create Table 4 Create Table 4
Backup content Table 1, Table 2, Table 3, Table 4 Table 3, Table 4 Table 4

Logical backup strategy (increase, full, differential) How to choose a logical backup strategy (frequency) Reasonable value range ⭐⭐⭐ Full backup once a week, the full backup time needs to be performed between PM 10:00 AM and 5:00 in the time interval when no business is provided Incremental backup: 3 days/2 days/1 day Incremental backup difference: Select a specific scenario for backup One processing (NFS) Provide extra space for the mysql server

3. Common backup methods

3.1 Physical cold backup

The database is closed during backup, and the database file (tar) is directly packaged. The backup speed is fast, and the recovery is also the easiest

3.2 Special backup tool mysqldump or mysqlhotcopy

The logical backup tool mysqlhotcopy commonly used by mysqldump only has backup MyISAM and ARCHIVE tables

3.3 Enable binary log for incremental backup

For incremental backup, the binary log needs to be refreshed

MySQL supports incremental backups, and binary logs must be enabled for incremental backups. Binary log files provide the user with the information needed to restore database changes made after the backup point was performed. If an incremental backup (including data modifications that have occurred since the last full or incremental backup) is performed, the binary log needs to be flushed.

3.4 Third-party tool backup

Free MySQL hot backup software Percona XtraBackup mysqlbackup

Four, MySQL full backup

It is a backup of the entire database, database structure and file structure
What is saved is the database at the time when the backup is completed
It is the basis of differential backup and incremental backup
Advantages and disadvantages of MySQL full backup

1. Advantages: Backup and recovery operations are simple and convenient

2. Disadvantages: There is a lot of duplication of data Occupying a lot of backup space Long backup and recovery time

Five, database full backup classification

5.1 Physical cold backup and recovery

Close the MySQL database and use the tar command to directly package the database folder and directly replace the existing MySQL directory

5.2 mysqldump backup and recovery

The built-in backup tool of MySQL can easily realize the backup of MySQL. You can export the specified library and table as SQL script and use the command mysq| to import the backup data.

6. Practical cases

Environmental preparation

use kgc;
create table if not exists info1 (
id int(4) not null auto_increment,
name varchar(10) not null,
age char(10) not null,
hobby varchar(50),
primary key (id));

insert into info1 values(1,'user1',20,'running');
insert into info1 values(2,'user2',30,'singing');

6.1 MySQL full backup and recovery

The database of the InnoDB storage engine is stored on the disk as three files: db.opt (table attribute file), table name.frm (table structure file), table name.ibd (table data file).

6.1.1 Physical cold backup and recovery

systemctl stop mysqld
yum -y install xz
#压缩备份
tar Jcvf /opt/mysql_all_$(date +%F).tar.xz /usr/local/mysql/data/
mv /usr/local/mysql/data/ /opt/
#解压恢复
tar Jxvf /opt/mysql_all_2020-11-22.tar.xz -C /usr/local/mysql/data/
cd /usr/local/mysql/data
mv /usr/local/mysql/data/* ./

6.1.2 mysqldump backup and recovery (warm backup)

create table info2 (id int,name char(10),age int,sex char(4));
insert into info2 values(1,'user',11,'性别');
insert into info2 values(2,'user',11,'性别');

(1), fully back up one or more complete libraries (including all tables)

MySQLDUmp -u Root -P [Password] -Databases Library Name 1 [Library Name 2] ...> /Backup Path /Backup file name.sql #Export is the database script file. Back up a KGC library MySQLDUMP -U ROOT -P -Databases MySQL KGC> /opt/Mysql -KGC.SQL #Backup
MySQL
and
KGC

(2), fully back up all libraries in the MySQL server

mysqldump -u root -p [password] --all-databases > /backup path/backup file name.sql
Example:
mysqldump -u root -p --all-databases > /opt/all.sql

(3), fully back up some tables in the specified library

mysqldump -u root -p[password] library name [table name 1] [table name 2] ... > /backup path/backup file name.sql Example: mysqldump -u root -p [-d] kgc info1 info2 > /opt/kgc_info1.sql #Use the "-d" option, indicating that only the table structure of the database is saved #Do not use the "-d" option, indicating that the table data is also backed up
#As
a
table
structure
template

6.1.3 Mysql full recovery

1. Use the file exported by mysqldump, you can use the import method
source command
mysql command

2. Steps to restore the database using source

Log in to the MySQL database
and execute the source backup sql script path

3. Example of source recovery

MySQL [(none)]> source /backup/all-data.sql

Use the source command to restore data
1. There is a problem with the simulated database

[root@server1 backup]# mysql -uroot -pabc123 Log in to the database
mysql> show databases; view database information
mysql> drop database school; delete the database kgc
mysql> show databases;

2 Application example:

Create a backup (back up the table)
[root@server1 ~]# mysqldump -uroot -pabc123 kgc > mysql-kgc.sql
[root@server1 ~]# mysql -uroot -pabc123 Log in to the database to view

[root@server1 ~]# mysql -uroot -p123123 -e 'drop database kgc;' #Delete database table

recovery data table

mysql -uroot -p123123 < /opt/mysql-kgc.sql

6.2 MySQL incremental backup and recovery

6.2.1 MySQL database incremental recovery

1. General recovery

Restore all backed up binary log contents

2. Location-based recovery

The database may have both wrong operations and correct operations at a certain point in time. The wrong operation can be skipped based on the precise location. A node before the error node occurs, and the last correct operation point stops.

3. Point-in-time recovery

Skip a certain point in time when an error occurs to achieve data recovery Stop at the wrong point in time and start at the next correct point in time

6.2.2 MySQL incremental backup

1. Backup experiment 1. Turn on the binary log function

vim /etc/my.cnf
[mysqld]
log-bin=mysql-bin
binlog_format = MIXED #Optional, specify the record format of the binary log (binlog) as MIXED (mixed input)
server-id = 1 #This command can be added or not

#Binary log (binlog) has 3 different record formats: STATEMENT (based on SQL statements), ROW (based on rows), MIXED (mixed mode), the default format is STATEMENT

① STATEMENT (based on SQL statement):
Every sql that involves modification will be recorded in binlog.
Disadvantage: Excessive log volume, such as sleep() function, last_insert_id()>, and user-defined functions (udf), master-slave replication and other architectures will cause problems when recording logs

Summary: Add, delete, modify, and query records are realized through SQL statements. If high concurrency is used, errors may occur, and time differences or delays may occur. It may not be the recovery we think about. Maybe you delete or modify it first, and it may be reversed. low accuracy

② ROW (row-based)
only records changed records, and does not record the context of sql.
Disadvantage: If you encounter update...set...where true, then the data volume of binlog will become larger and larger

Summary: update and delete work with multiple rows of data to record them in rows.
Only the changed records are recorded, and the context of SQL is not recorded.
For example, a SQL statement records one row, but ROW may record 10 rows, but the accuracy is high. When there is high concurrency, due to the amount of operations, the performance becomes lower, so the records are all recorded.

③ MIXED recommends using
statement for general statements, and storing functions in ROW.

systemctl restart mysqld

View the contents of the binary log file
cp /usr/local/mysql/data/mysql-bin.000002 /opt/

① mysqlbinlog --no-defaults /opt/mysql-bin.000002

mysqlbinlog --no-defaults --base64-output=decode-rows -v /opt/mysql-bin.000002

#--base64-output=decode-rows: Use 64-bit encoding mechanism to decode (decode) and read by row (rows) #-v:
Display detailed content
#--no-defaults: Default character set (if you don’t add it, you will report UTF-8 errors) PS: You can export the
decoded file to txt format for easy reference to
mysqlbinlog --no-defaults --base64-output=decode-rows -v /opt/mysql -bin.000002 > /opt/mysql-bin.000002

2. Make a full backup (the incremental backup is based on the full backup, so we directly back up the database completely)

[root@mysql data]# mysqldump -uroot -p school info > /opt/school_info1_$(date +%F).sql
[root@mysql data]# mysqldump -uroot -p123123 school > /opt/school_all_$(date +%F).sql

3. Incremental backup operations can be performed every day to generate new binary log files (for example: mysql-bin.000002)
mysqladmin -u root -p flush-logs

4. Insert new data to simulate data increase or change
PS: refresh the binary file after the first full backup, and record "incremental backup data" in the second binary file
mysql> create database ky29;
Query OK, 1 row affected (0.00 sec)

mysql> use ky29;
Database changed
mysql> create table test1 (id int(4),name varchar(4));
Query OK, 0 rows affected (0.00 sec)

mysql> insert into test1 values(1,'one');
Query OK, 1 row affected (0.00 sec)

mysql> insert into test1 values(2,'two');
Query OK, 1 row affected (0.00 sec)

mysql> select * from test1;
+------+------+
| id | name |
+------+------+
| 1 | one |
| 2 | two |
+------+------+
2 rows in set (0.00 sec)

5. Generate a new binary log file again (for example: mysql-bin.000003)
mysqladmin -u root -p flush-logs
#The database operations in the previous step 4 will be saved in the mysql-bin.000002 file, and then we will test that the operation of deleting the ky29 library will be saved in the mysql-bin.000003 file (so as not to delete the library when we restore based on the mysql-bin.000002 log)

6.2.3 MySQL Incremental Recovery

1. General recovery

(1), Simulate the recovery steps of lost and changed data (just use recovery directly)

① Back up the test1 table in the ky29 database
mysqldump -uroot -pabc123 ky29 test1 > /opt/ky29_test1.sql
② Delete the test1 table in the ky29 database
drop table ky29.test1;

③ Restore the test1 table

mysql -uroot -pabc123 ky29 < ky29_test1.sql

#View log file

mysqlbinlog --no-defaults --base64-output=decode-rows -v /usr/local/mysql/data/mysql-bin.000003

(2), the recovery steps of simulating the loss of all data
① Simulate the loss of all data

mysqlbinlog --no-defaults /usr/local/mysql/data/mysql-bin.000002 | mysql -u root -pabc123

2. Breakpoint recovery

mysqlbinlog --no-defaults --base64-output=decode-rows -v /opt/mysql-bin.000002

③ Restoration based on location

mysqlbinlog --no-defaults --start-position='595' --stop-position='623' /usr/local/mysql/data//mysql-bin.000003 | mysql -uroot -p      #恢复从位置为595开始到位置为4286为止

(2), based on point-in-time recovery

mysqlbinlog --no-defaults --start-datetime='230717 19:02:12' --stop-datetime='230717 19:30:02' /usr/local/mysql/data//mysql-bin.000003 | mysql -uroot -p