MySQL 复制还原的最佳实践

Question

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

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

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

编辑

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

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

项目不会从任一数据库中删除，除非在汇总/归档期间，我们可以添加功能以验证在此期间两台服务器都可用于主/从设置。在发生故障转移的灾难恢复情况下，15-20 分钟的恢复时间可能是可以的，但不是每晚都一致。希望这些有助于澄清情况。

Answer 1

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

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

哪个更好，这完全取决于您的需要。后者可能会被脚本化到可以关闭站点进行维护的位置，然后将数据从 FailOverServer 获取到 RegServer，然后执行一系列 MySQL 命令来截断 RegServer 并在完成后从 FailServer 导入数据重新打开站点。

我从来没有做过，所以不能说这是一个好方法。但只要在 FailOverServer 上没有修改表，它应该可以正常工作。