我正在寻找使用 MySDQL 实现多站点复制的最佳方法。由于我主要是一个 MS-SQL 用户，我对 MySQL 复制术语感到很不自在，而且多个 MySQL 版本不会以相同的方式做完全相同的事情。
根据 SQL 术语，我的目标是拥有一个发布者和许多订阅者。订户对用户更新持开放态度。更改由发布者复制，然后发布者会将这些更改分发给其他订阅者。
所以我的目标是确定要用于我们的表的正确主键规则。因为我们只需要代理键，所以我们可以使用 integer\autoincrement 或 uuid/uuid_short 字段。为了避免复制冲突，integer\autoincrement 不符合我们的需要，因为当在两次同步之间，两个服务器都在同一个表中插入一条记录时，它会产生复制冲突。因此，根据我的说法，避免复制\主键冲突的正确解决方案是:
- 使用 uuid 或 uuid-short 字段作为主键
- 具有服务器在 INSERT 时设置的相应 uuid 值
- 将复制设置为 RBR(基于行的复制 - 听起来等同于 MS-SQL 合并复制)模式，而不是 SBR(基于语句的复制 - 听起来像事务复制)。据我了解，RBR 将在复制时“按原样”在其他服务器中插入计算出的 uuid 值，而 SBR 将调用 uuid() 函数并在每台服务器上生成一个新值……从而导致重大问题!
它会起作用吗？
最佳答案
我认为这里有两个不相关的问题:
1.
以可能唯一的方式选择主键 - UUID 是一种可接受的方法。您可以将它与 SBR 或 RBR 一起使用，前提是客户端应用程序生成 UUID。如果恰好是调用mysql函数生成的，那么就需要使用row-based replication。基于行的复制通常要好得多，因此您想要使用基于语句的复制的唯一原因是向后兼容 MySQL <5.1 从属或依赖其某些行为的遗留应用程序。
2.
其次，您似乎想要进行多主复制。它不会工作。
MySQL 复制非常简单 - 它将更改写入日志，将它们从一台服务器推送到另一台服务器，根据需要读取日志。
你不能做多主复制，因为它会失败。 MySQL 不仅实际上不支持它(对于任意拓扑)，而且它也不起作用。
MySQL 复制没有“冲突解决”算法，如果发现冲突，它会简单地停止并中断。
即使假设您的数据库除了由 UUID 分配的主键外不包含任何唯一索引，您的应用程序仍然可以具有使多主机失败的规则。
应用程序中的任何约束、不变量或假设，可能仅在数据库具有即时一致性时才有效。尝试使用多主复制打破了这个假设，并会导致您的应用程序进入意外(即通常不可能的)状态。
关于mysql - 复制，uuid 字段作为主键，基于行的复制，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/8092700/