这个test.sql文件有1.7G
执行这个binlog从09:26至10:06结束,共计花费30分钟
然后修改了参数innodb_flush_log_at_trx_commit=0
再将9点至10点的binlog导出
mysqlbinlog --start-datetime=‘2015-06-07 09:00:00‘ --stop-datetime=‘2015-06-07 10:00:00‘ mysql-bin.004989 mysql-bin.004990> /data/tmp/test2.sql
test2.sql有962M
执行test2.sql,从10:15开始至10:29结束,大致用时15分钟.
假设下午4点半出现误操作,需要恢复至4点的数据
仅仅是使用binlog进行不完全恢复的时间,大致就是
135分钟(30+7*15,从凌晨3点到9点需要30分钟,假设9点以后每个小时需要15分钟恢复)
也就是2小时零15分钟!!
而实际时间应该比这个还要长些.估计3小时以内能恢复就不错了.中间还不能出现任何差错
这时候,估计已经里三层外三层的把dba包的水泄不通了..
每分钟的停机,都是真金白银的损失(携程..)
是损失一些数据先把系统拉起来,还是尽量保一些数据,确实是一个值得权衡的事情.
(不过这种权衡已经不是dba能做的了..都是领导决定的..不过领导肯定会狠狠的给你一个白眼..)
有几个思考
1.为什么会有这么多binlog数据?
在我们单位日志是记录在生产库的,甚至都不是单独的schema
大量的日志确实给恢复造成了极大的压力.
如果我设计系统,一定会将日志放在单独的数据库,最起码也是单独的schema
2.不同于mysqldump,不完全恢复调整
innodb_flush_log_at_trx_commit参数似乎作用不大.
3.异地恢复之前一定要调整的参数
innodb_buffer_pool_size
max_allowed_packet(要恢复的目标服务器配置低于源服务器的配置,可能报错,导致恢复失败!!)
4.增加force参数
mysql -uroot -p --force -S mysql.sock < /data/test.sql
5.备份本质上是防止人为的错误,而下午又是高发期.
考虑是否在下午1点,增加一个全备份.
