案例：DB2 三点 SQL 复制，APPLY 状态 -1

macrozeng

原帖由 junli0310 于 2010-2-4 10:34 发表
贴出TRC文件的内容

哈哈，

TRC 内容不少，我贴一段关键的

sqlvar[1].sqldata:
      +00000000  02006162 e0388942 10000000           |  ab 8 B        |
SQLVAR[1].sqlname.length:     7
sqlvar[1].sqlname.data:
      +00000000  434f4e54 454e54                      |CONTENT         |
DOUPD: insert failed. apperrc is CA0105. sqlstate is 23505. sqlcode is -803

我笨故我在

原帖由 macrozeng 于 2010-2-4 10:00 发表
呵呵，不是主键更新的问题，忘记交代一点了，真实环境中的主键自动增长的，而且是做了 offset 了的，就是说在 peer1 是 ID 是 start with 1 increase  by 3 上插入的主键只能是  1,4,7,11 。peer2 上是 2,5,8 。 Peer3 上是 3,6,9 ，而且对应用的要求是主键不能修改的，这是 P2P 复制的基本前提，否则早就乱了套

这要求牛 想不出是什么业务的需求
不知道你的复制怎么定义的
要是我就在表上另利用一个唯一索引(创建最好,非强制)添加到预定集,预定集里不包含id列就可以了

junli0310

在apply的column注册表schema.IBMSNAP_SUBS_COLS里是不是有ID的注册项？
因为ID是自增长的，所以，把它去掉吧

macrozeng

4.分析原因
Apply Log 中的 -803 代表 PK/UK 冲突，查看数据库表 和 TRC 文件


sqlvar[1].sqldata:
      +00000000  02006162 e0388942 10000000           |  ab 8 B        |
SQLVAR[1].sqlname.length:     7
sqlvar[1].sqlname.data:
      +00000000  434f4e54 454e54                      |CONTENT         |
DOUPD: insert failed. apperrc is CA0105. sqlstate is 23505. sqlcode is -803

这段 TRC 说明冲突是 CONTENT 字段，当然还可以找到表信息（未贴出）

运行下面的查询语句在每个 Peer
select * from SR.S_TAB where CONTENT='ab'


发现 Peer1 有数据 "4,ab" 而 Peer2 和 Peer3 的数据是 "5,ab" ，因为  ID 是 offset 了的，所以可以确认 ID=4 是从 Peer1 插入的， ID=5 是从 Peer2 插入的。现在数据是从 Peer2 复制到了 Peer3 。
但是 Peer2 到 Peer1 出了问题，
PEER2TOPEER1           -1 2010-02-03-01.38.38.925787
原因是无法把 Peer2 的 "5,ab" 复制到 Peer1 上，原因是 UK 冲突 （"4,ab" on Peer1)
同样的原因，Peer1 到 Peer2 和 Peer3 都有问题。
PEER1TOPEER2           -1 2010-02-03-01.38.41.502129
PEER1TOPEER3           -1 2010-02-03-01.38.45.122122

[ 本帖最后由 macrozeng 于 2010-2-4 16:56 编辑 ]

macrozeng

5. 解决办法
可能每个项目都有不同，所以我只简单讲讲我项目中的解决办法。
为了保持数据的一致，必须对这两条数据进行选择，按照我们的游戏规则，两条 5,ab > 一条 4,ab ，所以我们的解决办法是在  Peer1 上删除  "4,ab" 和相关的 CD 表，如果有子表存在还要删除相关子表及其 CD 表。
等到下个 apply 的时候，Peer1 上的数据就是 "5,ab" ，而且所有的状态都不会再为 -1 了

huajieaixue

原帖由 macrozeng 于 2010-2-4 17:25 发表
5. 解决办法
可能每个项目都有不同，所以我只简单讲讲我项目中的解决办法。
为了保持数据的一致，必须对这两条数据进行选择，按照我们的游戏规则，两条 5,ab > 一条 4,ab ，所以我们的解决办法是在  Peer1 上删除  "4,ab" 和相关的 CD 表，如果有子表存在还要删除相关子表及其 CD 表。
等到下个 apply 的时候，Peer1 上的数据就是 "5,ab" ，而且所有的状态都不会再为 -1 了

简单来说，解决方法就是保证初始数据的一致性？ 那如果以后在运行过程中数据又发生不一致了改如何解决？
感觉三点之间的PEER-TO-PEER复制不太实用。

macrozeng

这种情况其实发生的概率不大，首先需要插入重复值，还有一个要求是在两个点同时插入重复值。如果 "5,ab" 已经复制到 Peer1 上了，peer1 上再去插入 "4,ab" ，在 peer1 上就会插入失败，根本不会出现 -1 的情况。如果说不实用，这也不对，一切还都是业务和高可用性的要求，不少项目有 三点之间的 P2P 需求

我笨故我在

设计问题，稍微考虑一下复制的设计就不会出现这样的问题
搞出这样的设计就应该打板子

macrozeng

原帖由 我笨故我在 于 2010-2-5 08:46 发表
设计问题，稍微考虑一下复制的设计就不会出现这样的问题
搞出这样的设计就应该打板子

呵呵，现在是3点的数据库互相复制同步，数据从哪个点插入是没办法控制，因为前端 WAS 是做的集群。如何避免呢？

我笨故我在

原帖由 macrozeng 于 2010-2-5 14:01 发表

呵呵，现在是3点的数据库互相复制同步，数据从哪个点插入是没办法控制，因为前端 WAS 是做的集群。如何避免呢？

自增长的主键 还是3点同步复制，想想就一定会出问题。
1 认真考虑下这个主键是否必须，或者3个表是否必须相同。
2 要么把offset各自设置的差别非常大，大过将来表的数据量比如点1 start with1 点2 start with 10亿 点3 start with 20亿
3 最好的方法就是不用自增长列。应用自己写入数据改设计