django-\/\/ i K | 
  ## 实验环境


此次实验的环境如下

- MySQL 5.7.25

- Redhat 6.10

- 操作系统账号:mysql

- 数据库备份账号:backup

## 1. 备份命令

### 1.1 首先新建备份账号

```
mysql> CREATE USER 'backup'@'localhost' IDENTIFIED BY '123456'; 

mysql> GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT ON *.* TO 'backup'@'localhost'; 

mysql> FLUSH PRIVILEGES;
```

### 1.2 建立备份目录

```
shell>mkdir -p /oradata/data/mysql/xtra
```
注意 mysql用户需要有读写权限，并且该目录需要为空，否则备份失败

### 1.3 开始备份

我们有如下方法对MySQL数据库进行全备

```
shell> innobackupex  -S /oradata/data/mysql/data/mysql.sock --user=backup --password=123456   /oradata/data/mysql/xtra
```


[image:599 size:orig]


备份完成后可以看到在/oradata/data/mysql/xtra目录下新建了以日期命名的目录



## 2. 备份过程分析

接下来分析下其备份的过程，从输出的日志上来看

### 2.1 命令提示部分

[image:600 size:orig]


上图首先打印出innobackupex可以用的一些参数

并提示说在结束时检查是否备份成功，需要在最后有"completed OK"字样

### 2.2 连接数据库

[image:601 size:orig]

然后是连接数据库，进入数据文件目录检查参数，之后开始备份

### 2.3 备份系统及undo表空间

[image:602 size:orig]

这部分首先列出数据库中有哪些表空间

- 系统表空间(ibdata)
- undo表空间(undo)
- 用户表空间(innodb_file_per_table开启后每张表和表空间一一对应)

首先拷贝系统表空间文件然后是undo表空间文件，最后是innodb表文件

可以看到由于我在备份时手动插入了数据，innobackupex一直在扫描redo 日志文件以反映数据的变化

### 2.4 备份innodb表数据

[image:603 size:orig]

可以看到正在拷贝innodb表的文件

由于我在备份时手动插入了数据，可以看到innobackupex一直在扫描redo 日志文件以反映数据的变化


### 2.5 备份非innodb表数据

[image:604 size:orig]

可以看到在拷贝数据文件时先执行下面语句进行锁表，不允许用户DML操作

- FLUSH NO_WRITE_TO_BINLOG TABLES

- FLUSH TABLES WITH READ LOCK

[image:605 size:orig]

之后在非InnoDB表拷贝完之后写信息至xtrabackup_binlog_info文件

该文件后续说明

最后记录最终的LSN号


### 2.6 完成备份

[image:606 size:orig]

之后解除锁表，拷贝ib_buffer_pool文件

记录binlog 位置信息

写信息值backup-my.cnf及xtrabackup_info 

最后拷贝在备份期间变化的redo日志





## 3. 生成文件说明

通过上面我们看到除了拷贝数据文件外还生成了一些文件

下面我们一一说明

[image:607 size:orig]

### 3.1 backup-my.cnf

[image:608 size:orig]

包含了备份数据库如下信息

- innodb的一些配置信息
- 数据库的server ID
- redo log 的版本
- 数据库服务器的uuid
- master key id(安全相关)


### 3.2 xtrabackup_binlog_info

[image:609 size:orig]

其记录了备份完成时binlog的位置及GTID信息

用于复制的搭建

### 3.3 xtrabackup_checkpoints

该文件对于后续增量备份有用

[image:610 size:orig]

该文件有如下信息

- 备份类型:全备
- 开始LSN:0
- 最后检查点LSN:9429655438
- 最后拷贝的LSN:9429655752
- 行COMPACT存储:否

可以看到to_lsn和last_lsn不同 说明在备份过程中有DML操作

to_last用于增量备份的起点

last_scn用于最后恢复的位置

这些后面介绍

### 3.4 xtrabackup_info

[image:611 size:orig]


该文件包含一些备份的信息就不一一介绍了





## 4. 参考资料

本专题所有内容翻译子Percona XtraBackup的官方文档

可通过如下链接下载


[上一章](http://www.zhaibibei.cn/mysql/xtrabackup/tutorial4)

[下一章](http://www.zhaibibei.cn/mysql/xtrabackup/tutorial6)