常用命令

innobackupex --defaults-file=/data/mysql_3306/my.cnf --no-timestamp --slave-info --compress --compress-threads=2 --parallel=4 --user automng --host=127.0.0.1 --port=3358 --password Automng_123 /export/bak/d01

O_DIRECT，绕过缓冲区高速缓存，直接IO，OS级命令

更多参考：UNIX高级环境编程（14）文件IO - O_DIRECT和O_SYNC详解

 涉及到的mysql理论绘制成一张图

 LSN

mysql内存与磁盘的数据一致性问题

写数据前，会先写redo，写完redo就可以返回客户端说写成功了

后台线程定期将内存中的脏块刷新到磁盘

如果此时，断电停机，则mysql崩溃，内存有脏块还未来得及落盘，磁盘文件不完整，文件有损；再启动时就需要崩溃恢复

mysql 崩溃恢复

last checlpoint位置以前的数据不需要恢复了

崩溃恢复，恢复的是last checkpoint到记录在redo log文件中的数据

恢复的起点

在redo log 写入文件以及脏块刷新时，LSN会写入文件

在数据库启动时，会先扫描数据文件最大的LSN与redo log文件中最大的LSN是否一致，如果不一致，就需要对数据文件进行恢复

最大的LSN更专业的叫法就是，last checkpoint，扫描数据文件中的last checkpoint与redo 中的最大LSN是否一致

利用redo log文件恢复时，只需要扫描LSN > last checpoint位置的数据

恢复过程中的前滚与回滚

在redo中，一个完整的记录有三个标识，xid（事务结束后写入的事务标识）, filename(binlog的文件名)、pos(binlog中的位点)

当然也是LSN，对应物理page的num等，但主要通过以上三个标识去确定是一个事务是该前滚，还是回滚

如果xid,filename,pos都在，就前滚

如果xid在，filename在，pos不在，就去binlogs确认事务是否已经在binlog中commit的，如果commit就前滚，没有commit就回滚。

如果xid在，filename也不在了，就去最后一个binlog中看看对应的xid是否已经提交，如果是则前滚，反之回滚。

恢复的过程

redo log文件记录并不是全部的数据，还需要数据文件、undo、binlog进行配合

找到redo log last checkpoint的位置

将相应的块从数据文件读到内存，先前滚，后回滚

备份命令

rm -rf /export/bak/d01

innobackupex --defaults-file=/data/mysql_3306/my.cnf --no-timestamp --slave-info --user automng --host=127.0.0.1 --port=3358 --password Automng_123 /export/bak/d01

 d01这个目录不必提交创建好，会自动创建

xtrabackup原理概述

如果数据库中的所有文件，数据文件，Undo文件，redo log文件等，在备份完成后，进行一次崩溃恢复；

在备份一个数据文件时，会判断所备份的数据文件的LSN是否已经包含在redo中了，

比如redo的LSN写到了500,但数据文件的LSN才到480，则会等待log scan直接数据文件中的LSN大于等于500才会开始备份这个数据文件，

一定会等到现有的 物理数据文件 + 现有redo log文件 可以不丢数据地进行“前滚”的时候，才会开始备份这个数据文件（redo log文件一直在备份）

xtrabackup备份步骤

1. 持续备份redo log文件

2. 备份数据文件, ibd文件

3. flush tables with read lock

4. 备份表结构等除数据文件的其他文件

5. 获取binlog log position（由于已经加锁，期间整个数据库不会有事务变化，也是后续恢复的起点）

6. unlock tables

7. 停止备份redo log文件