MySQL Delay Replicating
经常会出现执行了错误的SQL语句，例如写了一个update，后面没有写where，结果可想而知这种数据的恢复总是比较麻烦，考虑了一段时间觉得使用Delay Replicating的机制可以快速的完成这种由于误操作原因产生的数据恢复工作，但是目前MySQL的同步机制不提供这种方式，好痛苦啊……
目前我们的MySQL系统由三个部门组成：
Unit(s) R/W Comments
————————————————————————-
Master DB RW MySQL Replication Master DB
Slave DBs R MySQL Replication Slave DB
Backup DBs - MySQL Replication Slave DB
Master DB，Slave DB都是面向业务开放的，但是Backup DB不对业务开放
根据MySQL同步的设定，只有MasterDB可由业务系统写入数据
Slave DB只提供业务系统查询数据
Backup DB其实也是一个Slave DB，只是它不对业务系统开放
当Master DB出现灾难性的硬件或者磁盘故障，全部数据丢失，无法恢复的时候，可以直接将BackupDB上面的MYD, MYI, frm文件直接复制到MasterDB，达到恢复目的。（我们之前就已经遇到过一次SMS系统的核心数据库由于EMC CX700的一个SP故障，同时本地SCSI磁盘损坏，然后导致VXFS文件系统崩溃，数据全部不可恢复，我们通过BackupDB完整的恢复了所有数据，而且没有丢失，非常的幸运~~）
当Slave DB由于某些问题出现数据不一致，或者我们需要增加一台新的SlaveDB的时候，也可以直接将BackupDB上面的MYD, MYI, frm文件直接复制到Slave DB，然后将同步状态也从BackupDB上面复制过来，而不用将MasterDB停机。
如果MySQL可以提供Delay Replicating机制，那我们就可以建立一套Delay Replicating的备份系统，对关键业务提供10分钟Delay, 30分钟Delay，2小时Delay，4小时Delay，8小时Delay，24小时Delay的备份系统，如此实现数据库的快速数据恢复。
最近在考虑继续MySQL-Proxy的工作，看了SQLRelay的OpenSource的项目，而且现在MySQL5也出来了，感觉MySQL越来越强了，不过俺还是对MySQL的一些功能表示不满，因此还是想继续搞MySQL-Proxy的项目：
1. QCache的优化：MySQL的QCache机制实在是太滥了
2. SQL Filter的引入：开发人员总是执行一些误操作，我想实现一个SQL语句的Firewall，通过正则表达式来实现SQL语句的严格判断与执行
3. Delay Replicating：说实话，我对这个能否实现还没有把握
4. MySQL Cluster：说实在的MySQL官方的那个Cluster真的不好用，而且性能好像没有提高多少……
没有评论▼