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

时间:2011-11-11 10:33:06

标签: mysql primary-key replication uuid

我正在寻找使用MySDQL实现多站点复制的最佳方法。因为我主要是一个MS-SQL用户,我觉得MySQL复制术语和多个MySQL版本完全不一样的方式相当不可思议。

根据SQL术语,我的目标是拥有一个发布者和许多订阅者。怀疑者对用户更新持开放态度。发布者会复制更改,然后将这些更改分发给其他帖子。

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

  • 使用uuid或uuid-short字段作为主键
  • 具有服务器在INSERT时间设置的相应uuid值
  • 将复制设置为RBR(基于行的复制 - 听起来相当于MS-SQl合并复制)模式,而不是SBR(基于语句的复制 - 听起来像事务复制)。据我了解,RBR将在复制时在其他服务器中按原样插入计算的uuid值,而SBR将调用uuid()函数并在每个服务器上生成一个新值...因此导致一个重大问题!

它会起作用吗?

1 个答案:

答案 0 :(得分:1)

我认为这里有两个不相关的问题:

1

以可能唯一的方式选择主键 - UUID是一种可接受的方法。如果客户端应用程序生成UUID,您可以将其与SBR或RBR一起使用。如果您正在调用mysql函数来生成它,那么您需要使用基于行的复制。基于行的复制通常要好得多,因此您希望使用基于语句的复制的唯一原因是向后兼容MySQL< 5.1从属或遗留应用程序,后者依赖于其某些行为。

2

其次,您似乎想要进行多主复制。它不会工作。

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

您无法执行多主复制,因为它会失败。 MySQL不仅不支持它(对于任意拓扑),但它也不起作用。

MySQL复制没有“冲突解决”算法,如果发现冲突,它将简单地停止和中断。

即使假设您的数据库除了由UUID分配的主键之外不包含任何唯一索引,您的应用程序仍然可以具有使多主机失败的规则。

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