分布式的mysql同步

使用主从configuration以及从服务器备份是MySQL数据库的一个相当标准的策略。 保护数据免于重写的过程在故障转移和故障恢复的恢复阶段得到解决。

通常，您可以使用从服务器B以一致的方式对数据库（ mysqldump -h serverB --all-databases --lock-tables --other-options服务器B mysqldump -h serverB --all-databases --lock-tables --other-options服务器）执行完全备份或增量备份，而不影响master数据库在转储期间locking。 这是有用的，因为奴隶是主人的一个相同的复制品。

首先，主站Aconfiguration了mysql bin-log指令，以使复制可用于从站B ..以及潜在的C，D等。

而且从机B被configuration为保持事务的bin-log。 （这通常是空的，因为它不应该logging复制更新，除非你链接奴隶）

一旦serverA发生故障，主angular色被移到serverB，B现在开始login到它自己的bin-log文件。 在故障转移操作的这一点上，您将手动禁用从A复制到B（ mysql -h serverB -e 'stop slave' ），因为正如您所提到的， 您希望保护B免于故障服务器A.

我所说的“主angular色从服务器A移动到服务器B”的意思是你要改变你的应用程序来写服务器B地址的CRUD操作（创build，replace，更新，删除）。 例如mysql -h serverB -e 'INSERT INTO table X' 。 在双节点设置中，您也将迁移SELECT查询，因为您没有与主angular色不同的群集只读angular色。

现在是系统pipe理员的任务，使A作为B的奴隶回到在线状态。

如果这是一个干净的失败，则A现在是B后面的一些事件，但是B上的二进制日志包含这些事件的logging。 因此，您可以将masterB binlog重放到slaveA（它包含基本的SQL语句）

如果服务器A完全被破坏，则可以select使用从最近的转储或使用来自xtrabackup软件包的 percona innobackex脚本之类的工具从B中获取的完全备份将mysql恢复到A.

您现在应该在相反的方向configuration复制，以允许slaveA从masterB复制。

现在A和B应该是相同的。 如果你有一个很好的理由，比如slaveA是一个更高规格的机器，那么现在你可以切换复制方向来恢复masterA-slaveB的configuration。

处理这种情况（故障转移和故障恢复）的其他策略包括MMM ，多主复制或percona复制pipe理器工具（我还没有在生产中尝试过）

我只有3台服务器，所以build立群集不是一个选项。

如果你在他们之间传递数据，那么他们就是一个集群。 一个集群就是你描述的目标。 在MyQL中，有一种称为NDB集群的非常特定的configurationtypes – 这可能不是您正确的解决scheme。

所以如果srv A回来，它不会覆盖在srv B停机期间build立的数据库

只有在使用自动递增列或从序列中生成的其他值时才会这样做 – 而且mysql具有特定的function来避免这种情况。

我正在运行连接到SQL主机的服务器。 我有另一台服务器，我决定将其作为SQL备份运行。 所以，我有三个。 Srv A是SQL主机，srv B是备份。

我不关注 – 你有三台数据库服务器吗？ 还是2？

不pipe你需要将这些设置为asynchronous复制的主 – 主对（NOT master slave）。 如果你想添加第三个节点，那么只需将它添加为从属节点。 这样可以避免在发生故障时提升从属设备 – 只需将stream量路由到其他节点（对于备份和模式更新也很方便）。 有很多方法可以实现这一点 – 但最明智的做法是在客户端进行隔离或使用虚拟地址。

我不打算在这里描述这个过程，因为空间是有限的，你需要明白你在做什么。 互联网上也有很多的指南 – 但是你可能想要去买一本好书 （只是注意到O'Reilly 提出了这个更适合的）。 并坚持在那里描述的方法。