MySQL Replication Restore的最佳实践

时间:2011-04-19 18:56:47

标签: php mysql replication restore

所以我正在寻找在非常基本的主/从设置中设置MySQL Replication。我们主要针对的是服务器故障而不是灾难恢复,所以我最感兴趣的是故障转移。我们所有的应用程序都是用PHP编写的,所以我想在MySQL连接中设置一些内容会相当简单,这样如果主数据库无法连接,我们就会编写一个文件并故障转移到slave和用那个。

我的问题在于在故障转移后重新同步数据的最佳做法是什么,或者是否有更好的解决方案。

故障转移本身应该是自动化的,但恢复过程可以是手动的,我们希望通过WAN进行此操作。在此先感谢您的帮助

修改

在阅读了关于Master / Master与Master / Slave架构的内容之后,我对于哪种设置最适合我的场景我并不是很清楚。数据库本身相当大(我目前没有确切的大小)并主要表示事务/日志数据(带有一些次要身份验证和重复检查)。大多数情况下,行不会被更改,只会添加到数据库中。

我对复制服务器的主要关注/用法是故障转移,因此虽然Master-Master复制似乎是出于这些目的的理想选择,但读取这些内容会使听起来好像实际发生故障转移并添加记录对于数据库B,恢复数据库A比在主从关系中更难。

除了在汇总/存档期间,不会从任一数据库中删除项目,我们只需添加功能即可验证这两个服务器在此期间是否可用于主/从设置。在发生故障转移的灾难恢复情况下,15-20分钟的恢复时间可能正常,但不会在每晚一致的情况下恢复。希望这些帮助能够使情况更加清晰。

1 个答案:

答案 0 :(得分:0)

这里有很多因素。根据数据库的大小,您可以创建一个算法来获取已更改的内容(IE存储转移到故障转移的日期/时间或MAX ID),并使用该数据填充新数据库。这会导致问题,删除项目。如果实际删除了项目,并且不仅仅为删除时设置了日期。

根据大小,您可以关闭站点以进行维护15-30分钟,执行SQL转储并截断表并通过MySQL CLI界面重新导入数据,这可能需要一些时间,具体取决于数据。

哪个更好,这完全取决于您的需求。后者可能会编写脚本,可以关闭网站进行维护,然后将数据从FailOverServer提取到RegServer,然后实现一系列MySQL命令来截断RegServer并在完成后从FailServer导入数据。重新打开网站。

我从来没有这样做过,所以如果这是一个好的方式,就不能说话。但只要在FailOverServer上没有修改表,它就可以正常工作。