MySQL复制还原的最佳实践

Question

因此，我想在一个非常基本的主/从设置中设置MySQL复制。我们主要关注的是服务器故障，而不是灾难恢复，所以我最感兴趣的是故障转移。我们所有的应用程序都是用PHP编写的，所以我想在MySQL连接中设置一些东西是相当简单的，这样如果主数据库无法连接，我们将编写一个文件并将其故障转移到从服务器并使用它。

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

故障转移本身应该是自动化的，但是恢复过程可以是手动的，我们希望通过WAN来完成。提前感谢您的帮助

编辑

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

我对复制服务器的主要关注/使用是故障转移，因此，虽然主-主复制似乎是这些目的的理想选择，但读取这些副本听起来好像一旦故障转移实际发生，并且记录被添加到数据库B中，恢复数据库A将比在主从关系中更困难。

除了rollup/归档期间，两个数据库中的项目都不会被删除，我们可以添加功能来验证这两个服务器在主/从安装过程中都可用。在故障转移已经发生的灾难恢复情况下，15-20分钟的恢复时间是可以的，但不是每晚一致的。希望这些帮助使情况更加明朗。

Answer 1

这里有很多因素。根据数据库的大小，您可以创建一个算法来获取已更改的内容(IE存储移动到故障转移或最大id时的日期/时间)，只需使用该数据填充新数据库即可。这将导致一个问题，删除的项目。如果项目实际上已被删除，并且不只是在删除时设置日期。

根据大小，您可以关闭站点进行15-30分钟的维护，执行SQL，只需截断表并通过MySQL CLI接口重新导入数据，这可能需要一些时间，取决于数据。

更好的是，这完全取决于你的需要。后者可能会被脚本编写到可以关闭站点以进行维护的地方，然后将数据从FailOverServer获取到RegServer，然后实现一系列MySQL命令来截断RegServer并在完成后从FailServer导入数据--打开站点。

我从来没有这样做过，所以不能说这是否是个好办法。但是，只要FailOverServer上没有修改表，它就能正常工作。