复制，uuid字段作为主键，基于行的复制

我正在寻找使用MySDQL实现多站点复制的最佳方法。由于我主要是MS-SQL用户，因此对MySQL复制术语和多个MySQL版本不完全相同，我感到非常不舒服。复制，uuid字段作为主键，基于行的复制

根据SQL术语，我的目标是拥有一个发布者和许多订阅者。 Suscribers开放给用户更新。更改将与发布者一起复制，然后发布者将这些更改分发给其他用户。

所以我的目标是确定用于我们表格的正确的主键规则。由于我们只需要代理键，所以我们可以使用整数\ autoincrement或uuid/uuid_short字段。为避免复制冲突，整数\ autoincrement不符合我们的需要，因为在两次同步之间，两个服务器在同一个表中插入一条记录时，可能会产生复制冲突。因此，根据我的，正确的解决方案，以避免复制\主键冲突将是：

使用UUID或UUID短领域作为主键
有相应的UUID值由接入服务器设置时间
将复制设置为RBR（基于行的复制 - 相当于MS-SQl合并复制的声音）模式，而不是SBR（基于语句的复制 - 听起来像事务复制）。据我了解，RBR会在复制时将计算出的uuid值“按原样”插入其他服务器，而SBR将调用uuid（）函数并在每个服务器上生成一个新值...因此造成严重问题！

它会工作吗？

来源

2011-11-11 Philippe Grondier

如果您将主键定义为'PRIMARY KEY（id，server_id）'，然后在每个新添加的服务器上为'server_id'列设置默认值 - 您可以避免使用UUID并避免pk冲突。 –

这是一个解决方案，但我不想拥有复合主键。他们让JOINS很难理解。我相信有一种方法可以让它在没有这种解决方案的情况下工作。不管怎么说，还是要谢谢你。 –

UUID增加了很多开销，并且在JOIN中增加了一个'AND'实际上不应该是使用auto_increment作为PK失败的标准。我尝试了两种方式，UUID是我的第一选择，但是它们很慢，很长，会为InnoDB造成问题，并且当你想在你的db中手动查找某些东西时 - 看起来完全是胡言乱语，使得很难快速查找某些东西。 –

我认为这里有两个无关的问题：

选择在某种程度上这可能是唯一的主键 - UUID是一个可以接受的方法。您可以将其与SBR或RBR一起使用，前提是客户端应用程序生成UUID。如果你碰巧在调用mysql函数来生成它，那么你需要使用基于行的复制。基于行的复制通常要好得多，所以你想要使用基于语句的复制的唯一原因是向后兼容MySQL从属服务器或依赖其某些行为的遗留应用程序。

其次，您似乎想要执行多主复制。不起作用。

MySQL复制非常简单 - 它将更改写入日志，将它们从一台服务器推送到另一台服务器，根据需要读取日志。

您不能执行多主复制，因为它会失败。 MySQL不仅没有实际支持它（对于任意的toplologies），但它也不起作用。

MySQL复制没有“冲突解决”算法，它只会在发现冲突时停止并中断。

即使假设您的数据库中包含NO UIID分配的主键除外的UNIQUE INDEXES，您的应用程序仍可能有使多主设备发生故障的规则。

应用程序中的任何约束，不变量或假设可能仅在数据库具有即时一致性时才有效。尝试使用多主复制打破了这一假设，并会导致应用程序进入意外状态（即通常不可能）。

来源

2011-11-11 11:42:13 MarkR

感谢您的回答。所以我从您的意见中了解到，使用MySQL进行复制仅限于“只读”复制，其中更新只能在一台服务器上完成，然后分发到“只读”服务器。这听起来像是使用这个服务器的主要限制。 MySQL用户如何管理这种限制？ –

通常只写给主人;他们要么不同步地写入队列（以实现高可用性），要么容忍主机成为唯一写入的地方。实际上这不是一个主要的限制。多主复制只能在非常有限的情况下与MySQL一起使用，不适用于通用目的（例如，应用程序的设计非常专门用于容忍多主机情况）。正如我所说，没有复制冲突解决方案，所以唯一的解决方案是不存在复制冲突，实际上这意味着只写一个位置。 – MarkR

您有关于为多主复制设计的数据库的任何参考或文档吗？市场上没有可用于冲突解决方案的附件？ –

复制，uuid字段作为主键，基于行的复制

回答

相关问题