目录
1、测试环境介绍
2、备份策略
3、备份
4、灾难恢复
5、总结
1、测试环介绍
mysql> SELECT VERSION(); +------------+ | VERSION() | +------------+ | 5.5.36-log | +------------+ mysql> SHOW DATABASES; +--------------------+ | Database | +--------------------+ | information_schema | | mydb1 | | mysql | | performance_schema | | test | +--------------------+ mysql> SELECT * FROM mydb1.tb1; +----+------+------+ | id | name | age | +----+------+------+ | 1 | tom | 10 | | 2 | jack | 20 | +----+------+------+
准备两个备份目录：
[[email protected] ~]# ls /backup/data_dir/ #这个目录用来存放备份的数据文件 [[email protected] ~]# ls /backup/binlog_dir/ #这个目录用来存放利用二进制日志做的增量备份的
2、备份策略
以全备份+增量备份的方式实现数据的备份以及灾难恢复。
3、备份
3.1、先对服务器所有数据库做一次全备份：
[[email protected] ~]# mysqldump -uroot -p123456 --lock-all-tables --flush-logs --events --routines --master-data=2 --all-databases > /backup/data_dir/fulldata-`date +%F`.sql
选项说明：
--lock-all-tables
锁定库中的全部表，因对全库做备份时，mysql默认几个库中的表采用的存储引擎不是InnoDB的，而是有MyISAM、CSV、MERGE等，所以对全库备份不能实现热备
--flush-logs
刷新二进制日志，使当前服务所使用的二进制日志文件关闭，产生一个新的二进制日志文件，这样在以后做增量备份时就是从一个新的二进制日志文件开始
--master-data=2
启用此选项会把备份时刷新后的二进制日志文件及position点一同记录到备份文件中，便于在做增量备份明确应该从哪个点开始备份
[[email protected] ~]# ls /backup/data_dir/ fulldata-2015-04-14.sql
3.2、做数据修改，使其产生增量数据
进入mysql交互式模式，创建数据库、表，插入数据等操作：
mysql> CREATE DATABASE mydb2; mysql> USE mydb2; mysql> CREATE TABLE tb2 (id INT,name CHAR(15)); #只是新建了一个库和表，表中没有数据 这些建库，建表的操作会记录到二进制日志中，我们的增量备份就是基于二进制日志进行的
3.3、增量备份
因为在全备时加入了‘--master-data=2’选项，所以在备份的文件中可以查看到备份时mysql服务所使用的二进制日志文件及position的位置，这对做增量备份是一个非常重要的参考点，又因为有‘--flush-logs’选项，所以后期增量数据的二进制日志都写在了新的二进制日志文件里，所以在做增量备份时只需要再次滚动日志，把日志滚动前的那个日志备份即就是增量的二进制日志。
打开mysql交互式界面，滚动日志：
mysql> SHOW MASTER STATUS; #查看当前所使用的二进制日志文件 +------------------+----------+--------------+------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +------------------+----------+--------------+------------------+ | mysql-bin.000004 | 295 | | | +------------------+----------+--------------+------------------+ mysql> FLUSH LOGS; #滚动日志文件 mysql> SHOW MASTER STATUS; #再次查看已是使用新的日志文件 +------------------+----------+--------------+------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +------------------+----------+--------------+------------------+ | mysql-bin.000005 | 107 | | | +------------------+----------+--------------+------------------+
备份二进制日志文件：
[[email protected] ~]# cp /var/log/mysql_log/mysql-bin.000004 /backup/binlog_dir//mysql-bin.000004-increment.`date +%F` [[email protected] ~]# ls /backup/binlog_dir/ mysql-bin.000004-increment.2015-04-14
这个二进制日志文件即为增量备份的数据，mysql的二进制日志文件不要与数据存放在一起，这样可避免当数据目录丢失后还可以利用二进制文件来进行灾难恢复，这次测试的二进制日志存放在“/var/log/mysql_log”下，而数据目录则在“/mydata/data”下。
3.4、修改数据，为做时间点恢复做些数据修改
再次修改数据库，使其产生新的二进制事件
mysql> INSERT INTO mydb2.tb2 (id,name) VALUES (1,‘timepoint‘); mysql> SELECT * FROM mydb2.tb2; +------+-----------+ | id | name | +------+-----------+ | 1 | timepoint | +------+-----------+
4、灾难恢复
4.1、模拟数据库数据丢失
mysql> DROP DATABASE myddb1; Query OK, 1 row affected (0.02 sec) mysql> DROP DATABASE myddb2; Query OK, 1 row affected (0.03 sec)
4.2、服务器下线
当数据真正发生丢失时，就让mysql服务器下线，如果在现场可以直接把网线拨掉，如果是远程服务器，那可以重新启动mysql服务，但不启用网络功能：
[[email protected] ~]# /opt/lamp/mysql55/bin/mysqld_safe --skip-networking &
如果mysql服务都无法启动，排查后也启动不了，那只好重新安装数据库后再做恢复操作。
4.3、数据恢复的准备工作
先暂时关闭二进制日志功能，恢复的操作不需要记录到二进制日志文件
mysql> SET GLOBAL sql_log_bin=0; Query OK, 0 rows affected (0.00 sec) mysql> SHOW GLOBAL VARIABLES LIKE ‘sql_log_bin‘; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | sql_log_bin | OFF | +---------------+-------+ mysql> FLUSH LOGS; #滚动一下日志，因为最后要做时间点的恢复，会用到在做增量备份后的那个日志文件。 mysql> SHOW MASTER STATUS; #确认日志已滚动 +------------------+----------+--------------+------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +------------------+----------+--------------+------------------+ | mysql-bin.000006 | 107 | | | +------------------+----------+--------------+------------------+
4.4、先用完全备份恢复：
[[email protected] ~]# mysql -uroot -p123456 < /backup/data_dir/fulldata-2015-04-14.sql mysql> show databases; +--------------------+ | Database | +--------------------+ | information_schema | | mydb1 | | mysql | | performance_schema | | test | +--------------------+ mysql> SELECT * FROM mydb1.tb1; #mydb1数据库的数据已恢复了 +----+------+------+ | id | name | age | +----+------+------+ | 1 | tom | 10 | | 2 | jack | 20 | +----+------+------+
4.5、用增量的备份恢复数据：
[[email protected] ~]# mysqlbinlog /backup/binlog_dir/mysql-bin.000004-increment.2015-04-14 > /tmp/increment.sql #先导出二进制文件为sql脚本类型 [[email protected] ~]# mysql -uroot -p123456 < /tmp/increment.sql #数据恢复 mysql> SHOW DATABASES; #做增量备份时的mydb2数据库已恢复 +--------------------+ | Database | +--------------------+ | information_schema | | mydb1 | | mydb2 | | mysql | | performance_schema | | test | +--------------------+ 6 rows in set (0.00 sec) mysql> SELECT * FROM mydb2.tb2; #在做增量备份时tb2表是没有数据的，只是创建了这个表 Empty set (0.00 sec)
4.6、时间点恢复
[[email protected] ~]# ls /backup/binlog_dir/ mysql-bin.000004.incremental.2015-04-14 #这是增量备份的二进制文件，在做增量备份是先“flush logs”，所以下一个二进制日志文件里产生的修改操作就是我们没有做备份的，即"mysql-bin.000005"这个二进制文件。
使用mysqlbinlog工具查看mysql-bin.000005二进制日志文件，查找到“DROP TABLE ”这样的语句，因为之前模拟数据库丢失是直接用的删除语句，通过观察发现删除表的语句在“321”这个position，所以：
[[email protected] ~]# mysqlbinlog --stop-position=321 /var/log/mysql_log/mysql-bin.000005 > /tmp/321ttim.sql [[email protected] ~]# mysql -uroot -p123456 < /tmp/321ttim.sql mysql> SELECT * FROM mydb2.tb2; #已把表tb2中的数据恢复 +------+-----------+ | id | name | +------+-----------+ | 1 | timepoint | +------+-----------+
4.7、收尾工作
最后把sql_log_bin变量的值设置为1或者重新启动一次mysql服务:
mysql> SET GLOBAL sql_log_bin=1; [[email protected] ~]# service mysqld restart
可利用"check table"命令对表进行校验。
5、总结：
mysqldump工具对InnoDB存储引擎的表可实现热备，所以在备份时可以不锁定表，如果针对整个服务器的库做备份，有MyISAM的表，则在备份前需要锁定表，只能实现温备，即使库中有Innodb表。此工具是一种逻辑学备份方式，备份出来的文件是sql语句，备份和恢复都需要mysql进程参与，当备份的数据量较大时，恢复时间会很长，因为恢复是把一条一条的sql语句读取后在mysql中执行，是写入操作。只是对innodb库进行备份时能实现热备，建议在数据量不大时可以使用此工具进行备份操作，但当随着数据增长此工具将不适合进行mysql的备份可恢复操作，应选取其他更优的数据备份恢复方案。