排除CUCM数据库复制问题

简介

本文档介绍如何诊断数据库复制问题，并提供排除和解决这些问题所需的步骤。

诊断数据库复制问题的步骤

本节介绍数据库复制中断的场景，并提供TAC工程师为了诊断和隔离问题而遵循的故障排除方法。

步骤1:验证数据库复制是否已中断

为了确定数据库复制过程是否已损坏，您必须了解用于监控复制的实时监控工具 (RTMT) 的各种状态。

要验证数据库复制，请从发布方节点的CLI运行utils dbplication runtimestate命令，如下图所示。 

在命令输出中，确保“Cluster Replication State“（集群复制状态）不包含旧同步信息。选中该选项并使用Timestamp。

如果广播同步未在最近日期更新，请运行 utils dbreplication status 命令检查所有表和复制。系统发现的任何错误/不匹配会显示在输出中，并且 RTMT 状态会相应更改，如下图所示。

此命令检查所有表的一致性，并显示准确的复制状态。

注意：允许检查所有表，然后继续排除故障。

显示准确的复制状态后，检查复制设置 (RTMT) 和详细信息，如第一个输出所示。您必须检查每个节点的状态。如果任何节点的状态不是 2，请继续进行故障排除。

第二步：从CUCM上的Cisco Unified Reporting页面收集CM数据库状态

1. 完成第1步后，从Cisco Unified Communications Manager(CUCM)发布器中的Navigation下拉列表中选择Cisco Unified Reporting选项，如下图所示。

2. 前往“System Reports”（系统报告），然后点击“Unified CM Database Status”（统一 CM 数据库状态），如下图所示。

3.使用生成新报告选项生成新报告，或单击生成新报告图标，如下图所示。

4.生成并下载报告后，保存报告，以便在需要打开服务请求(SR)时，可以将其提供给TAC工程师。

第三步：查看标记为错误的任何组件的Unified CM数据库报告

如果组件中存在任何错误，这些错误会用红色的X图标进行标记，如本图所示。

• 确保可以访问本地和发布服务器数据库。

• 如果出现错误，请检查节点之间的网络连接。验证A Cisco DB服务是否从节点的CLI运行并使用utils service list命令。

• 如果思科 DB 服务关闭，请运行 utils service start A Cisco DB 命令启动服务。 如果失败，请联系思科TAC。     

• 确保为所有节点填充复制服务器列表 (“cdr list serv”)。

此图显示了理想的输出。

 如果某些节点的思科数据库复制器 (DR) 列表为空，请参阅第 8 步。

• 确保 Unified CM 主机、Rhosts 和 Sqlhosts 在所有节点上都等同。

这是一个重要步骤。如下图所示，Unified CM 主机、Rhost 和 sqlhost 在所有节点上都等同。

主机文件不匹配：

当 IP 地址更改或服务器上的主机名更新时，可能会发生错误活动。

请参阅此链接，将 IP 地址更改为 CUCM 的主机名。

IP 地址和主机名更改

从发布服务器的CLI重新启动这些服务，并检查是否清除不匹配。如果是，请转至步骤8。如果不是，请联系思科TAC。 每次在 GUI/CLI 上进行更改时均生成新报告，以检查是否包含更改。

Cluster Manager ( utils service restart Cluster Manager) 
A Cisco DB ( utils service restart A Cisco DB)

Rhosts 文件不匹配：

如果 Rhosts 文件与主机文件不匹配，请执行本文档“主机文件不匹配”部分所述的步骤。 如果只有 Rhosts 文件不匹配，请从 CLI 运行命令：

A Cisco DB ( utils service restart A Cisco DB )
Cluster Manager ( utils service restart Cluster Manager)

生成新报告，并检查所有服务器上的 Rhost 文件是否等同。如果是，请转至步骤8。如果不是，请联系思科TAC。

SQL 主机不匹配：

如果 Sqlhosts 与主机文件不匹配，请执行本文档“主机文件不匹配”部分所述的步骤。如果只有 Sqlhosts 文件不匹配，请从 CLI 运行命令：

utils service restart A Cisco DB

生成新报告，并检查所有服务器上的 Sqlhosts 文件是否等同。如果是，请转至步骤8。如果不是，请联系思科TAC

• 确保数据库层远程过程调用 (DBL RPC)“Hello”操作成功，如下图所示。

  如果 RPC 的“Hello”操作不适用于特定节点：

• 确保特定节点和发布方之间的网络连接正常。
• 确保网络中允许使用端口号 1515。

有关 TCP/UDP 端口使用的详细信息，请参阅此链接：

思科统一通信管理器 TCP 和 UDP 端口使用

• 确保节点之间的网络连接成功，如下图所示：

如果节点的网络连接失败：

• 确保节点之间的网络可访问。
• 确保在网络中允许使用适当的 TCP/UDP 端口号。

生成新报告，并检查连接是否成功。如果连接不成功，请转至第 8 步。

第四步：检查使用Utils Diagnose Test命令的单个组件

使用 utils diagnostic test 命令检查所有组件并返回通过/失败的值。数据库复制正常运行所必需的组件包括：

• 网络连接:

使用 validate_network 命令检查集群中所有节点的网络连接的所有方面。如果连接存在问题，域名服务器/反向域名服务器 (DNS/RDNS) 上通常会显示错误。命令 validate_network 可在 300 秒内完成相应操作。网络连接测试中常见的错误消息如下：

1.错误“集群内通信已中断”，如图所示。

• 原因

当集群中的一个或多个节点出现网络连接问题时，会导致此错误。确保所有节点均可 Ping 通。

• 效果

如果集群内通信中断，则会发生数据库复制问题。

2. 反向 DNS 查找失败。

• 原因

当节点上的反向 DNS 查找失败时，会导致此错误。但是，当您使用这些命令时，您可以验证DNS是否配置正确且运行正常：

utils network eth0 all - Shows the DNS configuration (if present)
utils network host <ip address/Hostname> - Checks for resolution of ip address/Hostname

• 效果

如果DNS无法正常工作，则当定义服务器并使用主机名时，可能导致数据库复制问题。

• 网络时间协议 (NTP) 可访问性：

NTP负责使服务器的时间与参考时钟保持同步。发布方始终将时间与其IP列为NTP服务器的设备同步；相反，订阅方将时间与发布方同步。

为了避免任何数据库复制问题，NTP 的全部功能都正常运行至关重要。

NTP层数（到父参考时钟的跳数）必须小于5或不可靠。

请完成以下步骤以检查 NTP 状态：

1. 使用 utils diagnostic test 命令并检查输出，如下图所示。

  2.此外，还可以运行以下命令：

utils ntp status

第五步：检查所有节点的连接状态并确保它们已通过身份验证

1. 完成第 4 步后，如果未报告任何问题，请在所有节点上运行 utils network Connectivity 命令，以检查与数据库的连接是否成功，如下图所示。

2.如果收到“无法发送TCP/UDP数据包”错误信息，请检查网络是否有任何重新传输或阻止TCP/UDP端口。使用 show network cluster 命令检查所有节点的身份验证。

3.如果节点状态为未经身份验证，请确保所有节点的网络连接和安全密码相同，如下图所示。

请参阅以下链接以更改/恢复安全密码：

如何在 CUCM 上重置密码

CUCM 操作系统管理员密码恢复

第六步：Utils Deplication Runtimestate命令显示不同步或未请求的状态

必须注意的是，数据库复制是一项网络密集型任务，因为它将实际的表推送到集群中的所有节点。请确保：

•  节点位于同一个数据中心/站点中：所有节点均可通过更短的往返时间(RTT)到达。如果RTT异常高，请检查网络性能。

•  节点分布在广域网(WAN)中：确保节点的网络连接时间不超过80毫秒。如果某些节点无法加入复制过程，请提高该参数的值，如图所示。

utils dbreplication setprocess <1-40>

注意：更改此参数后，会提高复制设置性能，但会消耗额外的系统资源。

• 复制超时取决于群集中的节点数：复制超时（默认值：300秒）是发布方等待所有订用方发送其定义的消息的时间。根据集群中的节点数计算复制超时。

Server 1-5 = 1 Minute Per Server Servers 6-10  = 2 Minutes Per Server Servers >10 = 3 Minutes Per Server.

Example: 12 Servers in Cluster : Server 1-5 * 1 min = 5 min, + 6-10 * 2 min = 10 min, + 11-12 * 3 min = 6 min,  
Repltimeout should be set to 21 Minutes.

用于检查/设置复制超时的命令：

show tech repltimeout ( To check the current replication timeout value )
utils dbreplication setrepltimeout ( To set the replication timeout )

完成核对表后，必须执行步骤7和步骤8:

检查清单：

• 所有节点之间都相互连接。有关信息，请参阅步骤 5。

• RPC 可访问。有关信息，请参阅步骤 3。

• 如果节点数大于8，请在执行第7步和第8步之前咨询思科TAC。

• 在非办公时间执行此程序。

步骤 7.修复所有/选择性数据库复制表

如果 utils dbreplication 运行状态命令显示存在错误/不匹配的表，请运行以下命令：

Utils dbreplication repair all

运行 utils dbreplication runningstate 命令以再次检查状态。

如果状态未更改，请继续执行第 8 步。

步骤 8从头重置数据库复制

请参考顺序以重置数据库复制并从头开始此过程。

utils dbreplication stop all  (Only on the publisher)
utils dbreplication dropadmindb (First on all the subscribers one by one then the publisher)
utils dbreplication reset all ( Only on the publisher )

要监控进程，请运行 RTMT/utils dbreplication runningstate 命令。

请参阅操作步骤以重置特定节点的数据库复制：

utils dbreplication stop <sub name/IP> (Only on the publisher)
utils dbreplcation dropadmindb (Only on the affected subscriber)
utils dbreplication reset <sub name/IP> (Only on the publisher )

如果您联系思科TAC寻求进一步帮助，请确保提供以下输出和报告：

utils dbreplication runtimestate
utils diagnose test
utils network connectivity

Reports:

• Cisco Unified Reporting CM数据库报告（请参阅步骤2）。

• utils create report database命令从CLI。下载.tar文件并使用SFTP服务器。

相关信息

• 了解CUCM实用程序复制运行时间状态的输出
• 排除 CUCM 数据库复制 Linux 设备型号故障
• CX交付数据保护和隐私