实现MySQL热备份的最好方法,我一直都认为是Replication,xtrabackup等各种热备脚本,都没有Replication安全方便。
面对一个大规模集群的备份,由于实例太对,没办法创建这么多实例去Replication。之前我的想法一直是通过修改MySQL的源码,扩展MySQL Replication可以创建多个M-S复制,这对MySQL本身有入侵,没办法保证我的代码能有非常高的可靠性,更严重的是要改变MySQL的语法,来支持多Master的Change语句,对.yy文件的修改风险就更大了。
在这条路不断的碰壁之时,突然想到,mysqlbinlog不是一个很好的工具吗,为什么还要靠修改源码,一个利用mysqlbinlog进行大规模备份的想法就诞生了,但是是否可靠还要去验证下。
怎么做呢,首先了解下MySQL Replication怎么做的,首先一个Slave IO线程从Master读取binlog,然后解析到Relay-log,另一个Slave SQL线程异步的从Relay-log中读取SQL应用到本地。
mysqlbinlog有一个参数read-from-remote-server,可以从远程读取binlog,只要创建一个有Replication Client权限的用户即可,这就模拟了Slave IO线程的作用。
mysqlbinglog –read-from-remote-server -u repl -p -h target_node –start-datetime=’2010-09-01 00:00:00′ –stop-datetime=’2010-09-01 23:59:59′
通过这条命令就可以获取到2010-09-01这一天的全部SQL,这些SQL可以直接导入到数据库,也可以写到Relaylog,让SLave SQL线程去执行。
假设我们原来是每5分钟备份一次新产生的binlog,每天一次全备,所有备份都在一个备份机上,利用上述方法,就可以如下操作:
1. 在备份机启动一个实例,指向任意一个没有操作的Master,使Relay-log文件生成。
2. 每个要备份的实例从备份机每5分钟发起一次mysqlbinlog请求,获取上5分钟的binlog,写入到一个临时文件,然后等临时文件写完了,去touch一个锁,写Relaylog。
3. 每天Slave Start一次,Slave Start之前touch一个锁,让Relay-log的写阻塞,等待Slave start执行完毕,删除Relay-log的写锁。
4. 删除前一天产生的临时文件。
这样操作就可以保证,每五分钟产生的SQL都被分开记录,方便查找,每天的Slave start则消化掉这些SQL。
如果想方便一点,不写Relay-log也是可以的,直接每天把SQL丢给MySQL执行一次就好,效果也一样。
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
作者
相关推荐
-
MySQL备份和其恢复机制原理简述
文章主要讨论的是 MySQL 备份和其恢复机制,以及对维护数据表的正确维护,其中主要包括的两种不同表的类型有MyISAM与 Innodb。
-
Mongodb源码分析之Replication模式
MongoDB中提供了复制(Replication)机制,通过该机制可以帮助我们很容易实现读写分离方案,并支持灾难恢复(服务器断电)等意外情况下的数据安全。
-
MySQL延时备份的实现
在实际工作中,经常有一不小心误删除数据库或表而后悔莫及的事件发生,这有没有后悔药可吃呢?今天介绍的延时备份就可以做到。
-
轻量级MySQL备份方案:AutoMySQLBackup
有句话说得好:“选择最好的不一定是最好的选择!”。AutoMySQLBackup算不上出类拔萃,但作为轻量级MySQL备份方案,对一些迷你项目而言,它绝对值得尝试。