gpt4 book ai didi

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

转载 作者:行者123 更新时间:2023-11-29 00:52:05 32 4
gpt4 key购买 nike

我正在寻找使用 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/

32 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com