【问题标题】:Informix 10 replication queues not movingInformix 10 复制队列不移动
【发布时间】:2022-01-09 06:58:19
【问题描述】:

我在 Solaris 10 上使用 Informix IDS 10.00.UC6,两台机器具有相同的数据库架构,并且所有表都使用 Enterprise Replication 双向复制,因此理论上两个数据库应该具有相同的内容。

但是,出现了一个问题,即一个复制方向(主机 A 到主机 B)继续正常工作,但另一个方向(主机 B 到主机 A)不起作用。症状是:

  • 对主机 B 上的表所做的更改不会传播到主机 A(通过更改主机 B 上的一行并检查主机 A 上的表来确定)
  • cdr list serv 显示 ActiveConnected(双向),但在主机 B 上有数百万字节的队列。
  • cdr list repl 显示多个复制的非零队列。
  • 主机 A 上的 cdr stats recvq 显示最近没有从主机 B 收到任何信息。
  • cdr stats rqm 显示假脱机 trg_send_stxn 中的数据,带有标志 SEND_Q, SPOOLED, PROGRESS_TABLE, NEED_ACK, SENDQ_MASK, SREP_TABLE
  • online.logcdr_mon.log 或我能想到的任何其他地方都没有错误或相关消息。
  • 有些表“不同步”,因为行有冲突的数据或丢失;这是由于与过去错误有关的各种原因,其中一台主机脱机。但是,即使对主机 B 上具有正确数据的表所做的更改也不会传播到主机 A。
    • 昨天我在主机 B 上做了一个cdr cleanstart,因为这个问题在两个方向都发生了,这至少使 A -> B 方向开始工作(与我预期的相反),并且主机 B 上的队列当时为0。在该 cleanstart 之后,对表(具有正确数据)的一些更改将传播到主机 A,而对 B 上的其他表的一些更改则不会。但是今天,没有表从 B 传播到 A。
    • cleanstart 之前,我通过实验发现有时删除单个副本会减小卡住队列的大小,但队列仍然卡住;有时,删除副本会使队列移动一段时间,然后再次卡住。
  • 还有一个 DR 主机,A 和 B 都向其进行单向传播,并且该主机在没有队列备份的情况下正确传播。

我现在不知道为什么要尝试诊断复制队列中的数据没有移动的原因。如果存在同步错误(即由于主机 A 数据不同而无法应用复制的更改),我希望在 online.log 中记录更新被拒绝的消息,并将信息保存到 $INFORMIXDIR/ats_dr 等等——这有最近发生了。似乎队列中必须有某些东西被拒绝但未被清除且未被记录,从而阻塞了队列。主机 A 的实时流量很大,并且(谢天谢地)正确地复制到主机 B,但反之则不然。

任何关于更多尝试的想法或诊断问题的方法都将受到欢迎。

编辑 - 可能与 Retrieving or deleting a row with a blob in Informix 10 相关,也可能不相关,其中主机 B 上的 ER 发送假脱机程序似乎已损坏。

【问题讨论】:

  • 您可能已经知道,10.00 版本已正式停止服务——后续版本 11.10、11.50、11.70 也是如此(尽管 11.70 只是最近才停止使用)。这使您很难获得帮助。升级路径也很曲折;我不确定 12.10 或 14.10 是否支持从 10.00 迁移。您应该查看更改的内容以使一直在工作的事情中断。你升级操作系统了吗? (我很确定 10.00 没有移植到 Solaris 11,因此自从首次安装 DBMS 以来,操作系统发生变化的可能性很高。)
  • @JonathanLeffler 是的,官方支持似乎不太可能,因此希望找到有经验的人来回答:) 实际上是 Solaris 10,现在正在编辑。

标签: informix database-replication


【解决方案1】:

如果您的环境中最近有任何复制定义更改,我会寻找以下任何线索。正如 Jonathan 所提到的,IDS 10.0.xC6 已经很老了,在最新版本中对 ER 进行了很多补充,使其更加健壮和对故障具有弹性

  • 主机 B 在复制中仅接收
  • ATS/RIS 文件

【讨论】:

  • 不幸的是,在这种情况下没有生成任何 ATS/RIS。很长时间以来,复制配置都没有发生任何变化。有一个不寻常的系统崩溃(数据库报告许多操作“虚拟内存不足”但继续接受其他操作)需要重新启动,因此系统表中的某个地方可能存在损坏的数据,尽管我不知道在哪里查看或如何重置它
【解决方案2】:

cdr error -a 显示什么(在每台服务器上运行)?

(以防万一您没有...版本 10 ER 手册的链接: http://publibfp.dhe.ibm.com/epubs/pdf/25122792.pdf)

哦,所有服务器都“时间同步”(ntp)吗?

JJ

【讨论】:

  • 感谢链接,我会复习一下,看看能不能学到点东西。服务器现在是同步的,但是在问题最初开始时超过了 3 分钟(不知道是怎么发生的)
  • cdr error -a 显示 2007 年的一些错误(!),最近没有
  • 这应该是一条评论。
【解决方案3】:

关于 ATS/RIS 文件,我们是否可以假设所有复制都启用了这些选项并且这在过去已经有效?

A 上的“onstat -g rcv”(接收统计信息)中有什么内容,该输出如何随时间变化?

'onstat -g nif' 在 B 上说什么?可能是传输中的阻塞?

我们是否可以假设自问题开始以来双方都至少重新启动了一次,因此任何内部线程混乱都将得到解决,并且 ER 在任一侧至少重新初始化一次?

是否可能存在一些从 B 到 A 的大型事务,这会阻塞复制,例如通过填满 A 的接收队列?队列 sbspace(或队列标头 dbspace)中是否存在空间问题?

我猜 B 上的 cleanstart 将解决问题,但当然必须重新同步所有复制的表(因为您已经在 A 上进行了 cleanstart,无论如何都是必需的)。

安德烈亚斯

【讨论】:

  • 主机 A 没有重新启动数据库或系统(主机 A 目前工作正常,我不愿打扰)。主机 B 已完全重新启动和干净启动。是的,ATS/RIS 过去一直有效(我相信现在仍然有效)。 cdr stats rqm 报告的发送假脱机程序中有数据卡住,它可能已损坏,请参阅 stackoverflow.com/questions/70208587 了解我的其他问题。
  • OK,问题又重现了。 (这次实际上是针对 DR 主机,所以我认为这表明主机 B 上的出站假脱机肯定是一个问题)。 onstat -g nif 显示 nifGState RUN 和一些发送/接收到 Host A 和 DR Host 的字节。
  • DR 主机上的 onstat -g rcv 没有显示来自主机 B 的任何内容(也支持主机 B 进入根本无法发送状态的理论)
  • onstat -g rqm 在主机 B 上显示 -12146621 字节在队列中为 trg_send_stxn 并且它已经有几天了 418 txnsin 假脱机,6 txns 在内存中
猜你喜欢
  • 1970-01-01
  • 2018-02-12
  • 1970-01-01
  • 2019-04-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2013-05-17
相关资源
最近更新 更多