我正在运行连接到 SQL 主机的服务器。我有另一台服务器，我决定将它作为 SQL 备份运行。所以，我有3个。Srv A 是 SQL 主机，srv B 是备份。
我知道有 mysql 复制，但这根本不是我喜欢的（如果我错了，请纠正我）。我想要一些分布式的东西，所以如果 srv A 回来了，它不会覆盖在 srv B 停机期间建立的数据库。我只有 3 个服务器，所以设置集群不是一个选项。
如果有人能帮助我，我会很高兴。
使用主从配置，并从从服务器上进行备份是 MySQL 数据库的一个相当标准的策略。在故障转移和故障回复的恢复阶段解决了保护数据不被覆盖的过程。
通常，您会使用从服务器 B 以mysqldump -h serverB --all-databases --lock-tables --other-options一致的方式对数据库 ( )进行完整或增量备份，而不会在转储期间通过锁定影响主数据库。这很有用，因为从站是主站的相同副本。
首先，主 A 配置了 mysql bin-log 指令，以使复制可用于从 B .. 和可能的 C、D 等。
但从 B 也被配置为保留事务的 bin-log。（通常为空，因为它不应该记录复制更新，除非您正在链接从属）
一旦 serverA 出现故障，master 角色就会转移到 serverB，并且 B 现在开始记录到它自己的 bin-log 文件。在故障转移操作的这一点上，您将手动禁用从 A 到 B 的复制，( mysql -h serverB -e 'stop slave')因为正如您所提到的，您希望保护 B 免受故障服务器 A 的影响。
我所说的“主角色从服务器 A 移动到服务器 B”是指您将更改应用程序以将 CRUD 操作（创建、替换、更新、删除）写入服务器 B 地址。例如mysql -h serverB -e 'INSERT INTO table X'。在 2 节点设置中，您还将迁移 SELECT 查询，因为您没有与主角色不同的集群只读角色。
现在是 sys-admin 任务，让 A 作为 B 的从站重新上线。
如果是完全失败，A 现在是 B 后面的一些事件，但 B 上的 binlog 包含这些事件的记录。因此，您可以将 masterB 二进制日志重放到 slaveA 上（它包含基本的 SQL 语句）
如果服务器A被彻底摧毁你可以选择使用使用一个最近的转储，或使用像来自Percona的innobackex脚本工具从B线的全备份到mysql恢复到xtrabackup包。
您现在应该以相反的方向配置复制，以允许 slaveA 从 masterB 复制。
现在 A 和 B 应该是相同的。如果你有充分的理由，比如 slaveA 是一台更高规格的机器，那么你现在可以切换复制方向来恢复 masterA-slaveB 配置。
处理这种情况（故障转移和故障回复）的其他策略包括MMM、多主复制或percona 复制管理器工具（我还没有在生产中尝试过）