Mysql模拟故障恢复案例过程

Posted 2020-11-24 Leader.Z

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Mysql模拟故障恢复案例过程相关的知识，希望对你有一定的参考价值。

一、数据库全备，全备脚本如下：

[root@leader script]# cat bak_all.sh
#!/bin/bash
#Date: 2019-12-08
#Author: chan
#Mail: chan
#Function:This scripts function is More complex backup scripts which need to find binlog log files and location points
#Version: 1.1
USER=root
PASS=root
MYSOCK=/tmp/mysql.sock
DATA_PATH=/data/backup
DATA_FILE=${DATA_PATH}/mysql_backup_`date +%F`.sql.gz
LOG_FILE=${DATA_PATH}/mysql_backup_`date +%F`.log
MYSQL_PATH=/usr/local/mysql/bin
mysqldb=test
#--single-transaction Specifically for the InnoDB engine when the data is updated when the data is updated it can‘t see the whole isolation
MYSQL_DUMP="${MYSQL_PATH}/mysqldump -u$USER -p$PASS -S $MYSOCK --events -B -F --master-data=2 --single-transaction $mysqldb"
MYSQL_CMD="${MYSQL_PATH}/mysql -u$USER -p$PASS -S $MYSOCK"
cat |${MYSQL_CMD}<<EOF
flush table with read lock;
system echo "-----show master status result-----" >>${LOG_FILE};
system ${MYSQL_CMD} -e "show master status"|tail -1 >>${LOG_FILE};
system ${MYSQL_DUMP}|gzip > ${DATA_FILE};
unlock tables;
quit
EOF

(1)执行备份

[root@leader script]# ./bak_all.sh
mysql: [Warning] Using a password on the command line interface can be insecure.
mysql: [Warning] Using a password on the command line interface can be insecure.
mysqldump: [Warning] Using a password on the command line interface can be insecure.

（2）查看备份结果

[root@leader backup]# ll
total 8
-rw-r--r-- 1 root root 70 Dec 8 13:25 mysql_backup_2019-12-08.log
-rw-r--r-- 1 root root 1742 Dec 8 13:25 mysql_backup_2019-12-08.sql.gz

（3）用crontab配置调度时间点

00 00 * * * /bin/bash /root/script/bak_all.sh >/dev/null 2>&1

二、备份后查看binlog日志情况

[root@leader mysql]# ll
total 374644
-rwxrwxr-x 1 mysql mysql 4406 Nov 23 21:40 mysql-bin.000001
-rw-r----- 1 mysql mysql 177 Nov 23 21:46 mysql-bin.000002
-rw-r----- 1 mysql mysql 32191 Nov 23 22:44 mysql-bin.000003
-rw-r----- 1 mysql mysql 360 Nov 23 22:46 mysql-bin.000004
-rw-r----- 1 mysql mysql 383565742 Dec 1 13:49 mysql-bin.000005
-rw-r----- 1 mysql mysql 1285 Dec 8 13:25 mysql-bin.000006
-rw-r----- 1 mysql mysql 154 Dec 8 13:25 mysql-bin.000007
-rw-r----- 1 mysql mysql 224 Dec 8 13:25 mysql-bin.index

[root@leader backup]# cat mysql_backup_2019-12-08.log
-----show master status result-----
mysql-bin.000006 1238 test mysql

提示，我们可以看用-F参数备份生成的新的文件mysql-bin.00007，所以增量恢复是从这开始的。

三、模拟用户更新数据

mysql> use test;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

mysql> select * from test_bf;
+------+---------+
| id | name |
+------+---------+
| 101 | zgp |
| 102 | fadacai |
+------+---------+
2 rows in set (0.00 sec)

mysql> insert into test_bf(id,name)values(103,‘pg‘);
Query OK, 1 row affected (0.07 sec)

mysql> insert into test_bf(id,name)values(104,‘linux‘);
Query OK, 1 row affected (0.09 sec)

mysql> insert into test_bf(id,name)values(105,‘gp‘);
Query OK, 1 row affected (0.07 sec)

mysql>

下面标红部分为需要回复的数据，否则就属于丢失。

mysql> select * from test_bf;
+------+---------+
| id | name |
+------+---------+
| 101 | zgp |
| 102 | fadacai |
| 103 | pg |
| 104 | linux |
| 105 | gp |
+------+---------+
5 rows in set (0.00 sec)

三、模拟用户破坏数据库

在全备后的某个时点，有其他DBA误删了test库

mysql> drop database test;
Query OK, 3 rows affected (0.25 sec)

四，故障排查

用户反馈系统报错，联系DBA排除故障，经确认是由DBA xxx误删引起的。

五、增量备份

停止主库对外访问，避免增量更新数据带来的死循环操作。

a.查看最近的全备

[root@leader backup]# ll
total 8
-rw-r--r-- 1 root root 70 Dec 8 13:25 mysql_backup_2019-12-08.log
-rw-r--r-- 1 root root 1742 Dec 8 13:25 mysql_backup_2019-12-08.sql.gz

查看binlog刷新的位置以及在那个binlog文件开始刷新，从下面可以得知从mysql-bin.00006日志文件的1238这个位置开始的全备，mysql-bin.00006日志文件以后生成的文件是从零点全备到出现问题这个时间段的增量

提示：我们在0点执行的全备，所以binlog日志文件是从0点往后更新的。我们可以用mysqlbinlog参数查看一下零点之后更新的binlog文件，看看里面有没有更新的数据。当然我们也可以通过查看0点全备的数据文件里面的change master的位置来查看最新更新的binlog文件。可以看到执行全备后的所有binlog日志文件，它里面记录了从0点全备之后到第二天十点所有有更新的数据包括执行的误操作，所以我们在增量恢复的时候必须把执行误操作的那条语句删掉。例如本次演示应该把drop那条语句删掉。

b.刷新binlog

一般数据库故障我们要停止数据库，不能停这种情况下我们要刷新一下binlog。刷新一下binlog就会生成一个新的mysql-bin日志文件mysql-bin.000008，这时候再更新数据就会往这个新的里面写。现在增量恢复的目标就是mysql-bin.000008。

[root@leader backup]# /usr/local/mysql/bin/mysqladmin -uroot -proot -S /tmp/mysql.sock flush-logs

c.增量备份binlog防止二次破坏

c.1 备份00007，忽略演示

c.2将mysql-bin.000007解析成test.sql数据文件

[root@leader mysql]# /usr/local/mysql/bin/mysqlbinlog -d test /var/log/mysql/mysql-bin.000007>/data/backup/test.sql
WARNING: The option --database has been used. It may filter parts of transactions, but will include the GTIDs in any case. If you want to exclude or include transactions, you should use the options --exclude-gtids or --include-gtids, respectively, instead.

C.3删除导致故障语句

[root@leader backup]# grep ‘drop‘ test.sql
drop database test

注意：将生产的test.sql文件内容中的drop database test删掉保存，再进行增量恢复，不然恢复不了！

六、恢复数据

如果不挺库禁止对外访问就会有一个问题，什么问题呢？
第一个问题就是，在恢复的时候还有用户往数据库写数据，mysql-bin.000008还会记录更新的内容；全备恢复和增量恢复后还要恢复mysql-bin.000008更新的数据，备份mysql-bin.000008还得刷新binlog，增量恢复完mysql-bin.000008还得增量恢复更新的binlog，这样就死锁了老得恢复。
第二个问题就是，我们在增量恢复的时候，mysql-bin.000008也会记录全量和增量恢复的更新。在全量和增量恢复之后再恢复mysql-bin.000008更新的记录的时候就会导致主键冲突，可以编辑mysql-bin.000008解析成的mysql数据文件将冲突的数据删掉，如果数据多呢？还可以关闭sql_log_bin。关闭sql_log_bin就不会更新binlog日志文件了，这样会导致数据缺失。最好的方法就是停库，禁止对外访问，再做全量和增量备份。最根本的就是数据库的权限管理，不给删除修改权限，只给数据库管理员删除修改权限，防止故障的发生。谁有权限都要有记录，谁导致的故障要负责任。

mysql> set sql_log_bin=off;
Query OK, 0 rows affected (0.00 sec)

全量恢复

[root@leader backup]# gzip -d mysql_backup_2019-12-08.sql.gz
[root@leader backup]# ls
mysql_backup_2019-12-08.log mysql_backup_2019-12-08.sql test.sql
[root@leader backup]# mysql -uroot -proot </data/backup/mysql_backup_2019-12-08.sql
mysql: [Warning] Using a password on the command line interface can be insecure.

增量恢复

[root@leader backup]# mysql -uroot -proot </data/backup/test.sql
mysql: [Warning] Using a password on the command line interface can be insecure.

查看恢复后的数据

mysql> select * from test_bf;
+------+---------+
| id | name |
+------+---------+
| 101 | zgp |
| 102 | fadacai |
| 103 | pg |
| 104 | linux |
| 105 | gp |
+------+---------+
5 rows in set (0.00 sec)

小结：

1.人为SQL造成的误操作

2.全量和增量

3.恢复时建议对外停止更新

4.恢复全量，然后把增量日志中有问题的SQL语句删除，恢复到数据库。

增量恢复的核心思想：

1.流程制度的控制，如果不做，面临服务和数据，鱼和熊掌不可兼得。

2.可以通过延迟备份来解决或者通过监控，黑名单（不加where的语句是不让执行），白名单机制。

3.业务需求容忍度，选择停库，根据业务需求选择停库或锁表或者容忍丢失部分数据。

以上是关于Mysql模拟故障恢复案例过程的主要内容，如果未能解决你的问题，请参考以下文章

MySQL主从延迟复制实践及生产故障案例恢复实践

服务器数据恢复成功案例（raid5阵列故障恢复方法）