排除CUCM数据库复制问题

简介

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

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

本节介绍数据库复制中断的场景，并提供故障排除方法以便诊断和隔离问题。

第 1 步： 验证数据库复制过程是否已损坏

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

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

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

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

o

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

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

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

第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.等待成功生成新报告。

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

步骤3.查看任何标记为错误的组件的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。如果否，请与Cisco 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。如果否，请与Cisco TAC联系。

SQL 主机不匹配：

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

utils service restart A Cisco DB

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

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

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

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

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

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

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

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

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

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

步骤4.检查使用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

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

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

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

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

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

如何在 CUCM 上重置密码

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

第 6 步： 使用“utils dbreplication runningstate”命令显示不同步或未请求状态

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

•  节点位于同一数据中心/站点中：到达所有节点的往返时间 (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）。

• 在 CLI 中运行 utils create report database 命令所得到的输出结果。   下载.tar文件并使用SFTP服务器。

相关信息

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