ySQL数据库每日零点自动全备

某天上午10点，小明莫名其妙地drop了一个数据库

我们需要通过全备的数据文件，以及增量的binlog文件进行数据恢复

利用全备的sql文件中记录的CHANGE MASTER语句，binlog文件及其位置点信息，找出binlog文件增量的部分

用mysqlbinlog命令将上述的binlog文件导出为sql文件，并剔除其中的drop语句

通过全备文件和增量binlog文件的导出sql文件，就可以恢复到完整的数据

1. 模拟数据

CREATE TABLE `student` (

  `id` int(11) NOT NULL AUTO_INCREMENT,

  `name` char(20) NOT NULL,

  `age` tinyint(2) NOT NULL DEFAULT '0',

  PRIMARY KEY (`id`),

  KEY `index_name` (`name`)

) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET=utf8

mysql> insert student values(1,'zhangsan',20);

mysql> insert student values(2,'lisi',21);

mysql> insert student values(3,'wangwu',22);

2. 全备命令

# mysqldump -uroot -p -B -F -R -x --master-data=2 test|gzip >/server/backup/test_$(date +%F).sql.gz

参数说明：

-B 指定数据库

-F 刷新日志

-R 备份存储过程等

-x 锁表

--master-data 在备份语句里添加CHANGE MASTER语句以及binlog文件及位置点信息

3. 继续插入数据

mysql> insert student values(6,'xiaoming',20);

mysql> insert student values(6,'xiaohong',20);

此时误操作，删除了test数据库

mysql> drop database test;

此时，全备之后到误操作时刻之间，用户写入的数据在binlog中，需要恢复出来

4.查看全备之后新增的binlog文件

# cd /server/backup/

# ls

test_2016-08-02.sql.gz

# gzip -d test_2016-08-02.sql.gz

# grep CHANGE test_2016-08-02.sql

-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000003', MASTER_LOG_POS=107;

这是全备时刻的binlog文件位置，即mysql-bin.000003的107行，因此在该文件之前的binlog文件中的数据都已经包含在这个全备的sql文件中了

5. 移动binlog文件，并读取sql，剔除其中的drop语句

# cp /data/3306/mysql-bin.000003 /server/backup/

# mysqlbinlog -d test mysql-bin.000003 >003bin.sql

# 用vim编辑文件，剔除drop语句

在恢复全备数据之前必须将该binlog文件移出，否则恢复过程中，会继续写入语句到binlog，最终导致增量恢复数据部分变得比较混乱

6. 恢复数据

# mysql -uroot -p <test_2016-08-02.sql

# mysql -uroot -p -e "select * from test.student;"

+----+----------+-----+

| id | name     | age |

+----+----------+-----+

|  1 | zhangsan |  20 |

|  2 | lisi     |  21 |

|  3 | wangwu   |  22 |

+----+----------+-----+

//此时恢复了全备时刻的数据

//然后使用003bin.sql文件恢复全备时刻到删除数据库之间，新增的数据

# mysql -uroot -p test<003bin.sql <span style="color: #3366ff;" data-mce-style="color: #3366ff;"><-需要指定恢复的数据库

</span># mysql -uroot -p -e "select * from test.student;"

+----+----------+-----+

| id | name     | age |

+----+----------+-----+

|  1 | zhangsan |  20 |

|  2 | lisi     |  20 |

|  3 | wangwu   |  20 |

|  4 | xiaoming |  20 |

|  5 | xiaohong |  20 |

+----+----------+-----+

完成

恢复从库t2表数据

0).关闭从库同步

1).主库添加读锁

读锁和写锁说明：

读锁

当前会话可以读取t2表数据，无法写入数据，立即返回错误ERROR 1099。

其他会话可以读取t2表数据，无法写入数据，写入时会卡住，Waiting for table metadata lock。

写锁

锁定后，当前会话仍然可以读、写t2表，其他会话对t2表不可读、不可写。

2).主库备份

注意：

mysqldump中如果添加了--master-data=2或--flush-logs参数会导致备份时执行：

由于主库已经将t2表改只读状态，导致mysqldump时FLUSH TABLES操作卡住，无法正常备份表。

所以备份时需要去掉--master-data=2和--flush-logs参数。

备份

传到备库

3).导入到从库

从库

恢复

4).忽略过滤

从库检查表数据

忽略过滤

注意：无单引号

检查同步：

5).从库：启动同步

6).主、从：验证数据量是否一致  

7).主库：解锁表

适用于：

测试环境：

创建测试数据

先看一下mysqldump备份选项：

执行数据库全备

全库备份

指定数据库备份

指定表备份

只备份表结构

只备份表数据

其中：

--single-transaction 参数会添加下面额外执行：

--master-data=2和--flush-logs都会添加下面额外操作，注意锁表：

继续插入数据

查看数据

场景二：MySQL恢复指定表结构

通常定时备份是备份所有数据库--all-databases，如何通过备份文件恢复所需的数据？

例如：cjc库t2表

全备备份文件

恢复表结构

方式1：全备数据量很小时，直接通过vi进行查找

方式2：通过sed方式查找中备份文件中备份t2表结构部分

示例如下：

场景三：MySQL恢复指定表数据

例如：cjc库t1表

方式1：全备数据量很小时，直接通过vi进行查找

方式2：通过grep方式查找中备份文件中备份t1表数据

示例如下：

场景四：MySQL恢复指定库

通过--all-databases方式备份文件恢复指定数据库数据。

例如:cjc库数据

方式1：使用参数--one-database

还原：

通过general_log可以看到，只还原了cjc库。

方式2：sed

查看文件

示例如下：

场景五：MySQL恢复所有库数据

还原--all-databases备份的所有数据。

由于恢复了mysql库，还原完数据库后需要执行flush privileges;操作，或在备份是指定--flush-privileges。

参数说明如下：

场景六：MySQL恢复指定表到指定时间点

生成测试数据

备份表

继续插入数据库

更新数据

查看当前数据

删除数据，模拟误删除

如何将数据恢复到删除前时刻，恢复误删除的数据？

主库查看信息

查看binlog信息

查看event信息

解析binlog数据

信息如下：

或者

备份数据还原

查询数据

已将t1表还原到备份时间点数据。

需要通过binlog将数据推进到误删除数据前一时刻。

查看备份文件位置信息

查询delete位置信息

前面查到的

或者

误删除开始位置  1312

这个位置应该在delete的上一个事务COMMIT下面的位置，也就是delete前面SET @@SESSION.GTID_NEXT对应的位置信息。

生成还原语句

先生成可读的文件，通过vi等校验是否有问题

在去掉-vvv --base64-output=decode-rows参数，生成最终恢复文件

注意：

这里必须选择上一条语句commit之后的position，不能是删除语句开始的position 1439，否则会有这个警告。

警告：打印的事件范围以未设置STMT_END_F标志的行事件或表映射事件结束。这可能是因为最后一条语句没有完全写入日志，或者是因为您使用了--stop-position或--stop-datetime来引用语句中间的事件。分部语句中的事件尚未写入输出。

使用 --skip-gtids=true 参数

如果要恢复数据到源数据库或者和源数据库有相同 GTID 信息的实例，那么就要使用该参数，否则无法恢复成功的。

因为相同的GTID事务已经在源数据库执行过了，根据 GTID 特性，一个 GTID 信息在一个数据库只能执行一次，所以默认不会恢复成功。

查看日志内容

刷新binlog

还原误删除的数据：

通常会先将数据还原到测试库里，确保没问题以后，在导出导入到生产库。

查看数据

已恢复到误删除前的数据

适合人为SQL语句造成的误操作或者没有主从复制等的热备情况宕机时的修复

恢复条件要全备和增量的所有数据

恢复时建议对外停止更新，即禁止更新数据库

先恢复全量，然后把全备时刻点以后的增量日志，按顺序恢复成SQL文件，然后把文件中有问题的SQL语句删除（也可通过时间和位置点），再恢复到数据库