内容

概要

データベース レプリケーションを診断する手順

ステップ 1：データベースレプリケーションが壊れていることを確認します

ステップ 2：CUCMのCisco Unified ReportingページからCMデータベースのステータスを収集します

ステップ 3：Unified CMデータベースレポートで、エラーのフラグが付いたコンポーネントを確認します。

ステップ 4：utils diagnose testコマンドを使用する個々のコンポーネントを確認します

ステップ 5：すべてのノードの接続ステータスをチェックし、認証されていることを確認します

手順 6：utils dbreplication runtimestateコマンドでout of syncまたはnot requestedステータスが表示される

手順 7：データベースレプリケーション用のAll/Selectiveテーブルの修復

ステップ 8：データベースレプリケーションを最初からリセットする

概要

このドキュメントでは、データ レプリケーションの問題を診断する方法と、この問題のトラブルシューティングと解決に必要な手順について説明します。

データベース レプリケーションを診断する手順

このセクションでは、データベースレプリケーションが失敗するシナリオについて説明し、問題を診断して切り分けるためにTACエンジニアが従うトラブルシューティング方法を示します。

ステップ 1：データベースレプリケーションが壊れていることを確認します

データベース レプリケーションが壊れたかどうかを判断するには、レプリケーションの Real Time Monitoring Tool（RTMT）のさまざまな状態を知っている必要があります。

値

意味

説明

0

初期化状態

レプリケーションはセットアップ中です。レプリケーションがこの状態で1時間以上続くと、セットアップ障害が発生する可能性があります。

1

レプリケーションの数が正しくない

セットアップが継続中です。この状態は、バージョン6.xおよび7.xではほとんど発生しません。バージョン5.xでは、セットアップがまだ進行中であることを示します。

2

レプリケーションは良好

論理接続が確立され、テーブルはクラスタ内の他のサーバと一致しています。

3

テーブルが不一致

論理接続は確立されていますが、テーブルが一致するかどうかには不確かさがあります。

バージョン 6.x および 7.x では、クラスタの 1 つのサーバがダウンしても、すべてのサーバが状態 3 になることもあります。

この問題は、サブスクライバからクラスタの他のデバイスに渡されなかった User Facing Feature（UFF）に対する更新があるかどうかについて、他のサーバには確信がないために発生することがあります。

4

セットアップの失敗/ドロップ

サーバでは、ネットワークを介してデータベース テーブルを受信するために、アクティブな論理接続が必要なくなりました。この状態ではレプリケーションは発生しません。

データベース レプリケーションを検証するには、次の図のように、パブリッシャノードの CLI から utils dbreplication runtimestate コマンドを実行します。

その出力で、クラスタ レプリケーション状態に古い同期情報が含まれていないことを確認します。同じことを確認し、タイムスタンプを使用します。

ブロードキャスト同期が最近の日付で更新されていない場合は、utils dbreplication status コマンドを実行して、すべてのテーブルとレプリケーションを確認します。エラーと不一致が検出されると、次の図のように、出力に表示され、それに応じて RTMT 状態が変化します。

コマンドを実行すると、すべての表の一貫性が確認され、正確なレプリケーション ステータスが表示されます。

注：すべてのテーブルのチェックを許可してから、トラブルシューティングに進みます。

正確なレプリケーション ステータスが表示されたら、最初の出力に示されているように、レプリケーション セットアップ（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] をクリックします。

3. 「新規レポートの生成」オプションを使用して新規レポートを生成するか、次の図に示すように「新規レポートの生成」アイコンをクリックします。

4.レポートを生成してダウンロードしたら、サービスリクエスト(SR)をオープンする必要がある場合にTACエンジニアに提供できるようにレポートを保存します。

ステップ 3：Unified CMデータベースレポートで、エラーのフラグが付いたコンポーネントを確認します。

コンポーネントにエラーがある場合は、次の図に示すように、エラーに赤いXアイコンのフラグが付きます。

- ローカルデータベースとパブリッシャデータベースがアクセス可能であることを確認します。

- エラーがある場合は、ノード間のネットワーク接続を確認します。A Cisco DBサービスがノードのCLIから実行され、utils service listコマンドを使用するかどうかを確認します。

- A Cisco DB サービスがダウンしている場合は、utils service start A Cisco DB コマンドを実行して、サービスを開始します。これが失敗した場合は、Cisco TACに連絡してください。

- すべてのノードでレプリケーション サーバ リスト（cdr list serv）が入力されていることを確認します。

次の図は、理想的な出力を示しています。

Cisco Database Replicator（CDR）リストが空になっているノードがある場合は、ステップ 8 を参照してください。

- Unified CM Hosts、Rhosts、および Sqlhost がすべてのノードで同等であることを確認します。

これは重要なステップです。次の図に示すように、Unified CM Hosts、Rhosts、および Sqlhost はすべてのノードで同等です。

Hosts ファイルが一致しない：

サーバで 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 ファイルが Hosts ファイルとともに一致しない場合は、「Hosts ファイルが一致しない」で説明した手順に従います。 Rhosts ファイルのみが一致しない場合は、CLI から次のコマンドを実行します。

A Cisco DB ( utils service restart A Cisco DB )

Cluster Manager ( utils service restart Cluster Manager)

新しいレポートを生成し、Rhost ファイルがすべてのサーバで同等であるかどうかを確認します。ある場合は、ステップ8に進みます。存在しない場合は、Cisco TACにお問い合せください。

Sqlhosts が一致しない：

Sqlhosts ファイルが Hosts ファイルとともに一致しない場合は、「Hosts ファイルが一致しない」で説明した手順に従います。Sqlhosts ファイルのみが一致しない場合は、CLI から次のコマンドを実行します。

utils service restart A Cisco DB

新しいレポートを生成し、Sqlhosts ファイルがすべてのサーバで同等であるかどうかを確認します。ある場合は、ステップ8に進みます。サポートされていない場合は、Cisco TACに連絡してください。

- 次の図のように、データベース層リモート プロシージャ コール（DBL RPC）hello が正常に完了していることを確認します。

RPC hello が特定のノードに対して機能しない場合：

- その特定のノードとパブリッシャ間のネットワーク接続を確認します。

- ポート番号 1515 がネットワークに割り当てられていることを確認します。

TCP/UDP ポートの使用に関する詳細は、次のリンクを参照してください。

Cisco Unified Communications Manager の TCP および UDP ポートの使用

- 次の図のように、ネットワーク接続がノード間で正常に機能していることを確認します。

ノードのネットワーク接続が失敗した場合は、次の手順を実行します。

- ノード間にネットワーク到達可能性があることを確認します。

- 適切な TCP/UDP ポート番号がネットワークに割り当てられていることを確認します。

新しいレポートを生成し、接続が正常に機能していることを確認します。接続が正常に機能していない場合は、ステップ 8 に進みます。

ステップ 4：utils diagnose testコマンドを使用する個々のコンポーネントを確認します

utils diagnose test コマンドは、すべてのコンポーネントをチェックし、合格/不合格の値を返します。データベース レプリケーションが適切に機能するために必要なコンポーネントは、次のとおりです。

- ネットワーク接続:

validate_network コマンドは、クラスタ内のすべてのノードでネットワーク接続のあらゆる側面をチェックします。接続の問題があれば、多くの場合、エラーがドメイン ネーム サーバ/逆引きドメイン ネーム サーバ（DNS/RDNS）に表示されます。validate_network コマンドは、300 秒でこの操作を完了します。ネットワーク接続性テストでよく見られるエラー メッセージは、次のとおりです。

1. Error, Intra-cluster communication is broken。次の図のように表示されます。

- 原因

このエラーは、クラスタ内の 1 つ以上のノードにネットワーク接続の問題があると発生します。すべてのノードに ping の到達可能性があることを確認します。

- 影響

クラスタ内通信が壊れていると、データベース レプリケーションの問題が発生します。

2. Reverse DNS lookup failed。

- 原因

このエラーは、ノードで逆引き 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が正しく機能しない場合、サーバが定義され、ホスト名を使用すると、データベースレプリケーションの問題が発生する可能性があります。

- Network Time Protocol（NTP）の到達可能性：

NTPは、サーバの時刻を基準クロックと同期させる役割を担っています。パブリッシャは常に、IPがNTPサーバとしてリストされているデバイスと時刻を同期しますが、サブスクライバはパブリッシャと時刻を同期します。

データベース レプリケーションの問題を回避するためには、NTP が完全に機能することが非常に重要です。

NTPストラタム（親の基準クロックまでのホップ数）は、必ず5未満にする必要があります。そうでない場合は、信頼性が低いと見なされます。

NTP ステータスをチェックするには、次の手順を実行します。

1. 次の図のように、utils diagnose test コマンドを使用して、出力をチェックします。

2.  さらに、次のコマンドを実行できます。

utils ntp status

ステップ 5：すべてのノードの接続ステータスをチェックし、認証されていることを確認します

1. ステップ 4 の完了後、報告された問題がなければ、次の図のように、すべてのノードで utils network connectivity コマンドを実行して、データベースへの接続が正常に機能していることを確認します。

2. 「Cannot send TCP/UDP packets」というエラーメッセージが表示された場合は、ネットワークで再送信を確認するか、TCP/UDPポートをブロックします。show network cluster コマンドは、すべてのノードが認証されているかどうかをチェックします。

3.ノードのステータスが認証されていない場合は、次の図に示すように、ネットワーク接続とセキュリティパスワードがすべてのノードで同じであることを確認します。

セキュリティ パスワードを変更/回復するには、次のリンクを参照してください。

CUCM でパスワードをリセットする方法

CUCM オペレーティング システム管理者パスワードの回復

手順 6：utils dbreplication runtimestateコマンドでout of syncまたはnot requestedステータスが表示される

データベース レプリケーションは、クラスタ内のすべてのノードに実際のテーブルをプッシュするため、ネットワークの使用率が非常に高いタスクであることを理解することが重要です。次の点を確認します。

- ノードは同じデータセンター/サイト内にあります。すべてのノードは、より低いラウンドトリップ時間(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に進む前にCisco TACに問い合せてください。

- 営業時間外に手順を実行する。

手順 7：データベースレプリケーション用のAll/Selectiveテーブルの修復

utils dbreplication runtimestate コマンドにより、エラー/不一致のテーブルがあると示された場合は、次のコマンドを実行します。

Utils dbreplication repair all

utils dbreplication runtimestate コマンドを実行して、ステータスをもう一度確認します。

ステータスが変更されていない限り、ステップ 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 runtimestate コマンドを実行します。

次の一連のコマンドを参照して、特定のノードのデータベース レプリケーションをリセットします。

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 )

Cisco TACに連絡してさらにサポートを受ける場合は、次の出力とレポートが提供されていることを確認してください。

utils dbreplication runtimestate

utils diagnose test

utils network connectivity

レポート:

- Cisco Unified Reporting CM データベース レポート（手順 2 を参照）

- CLI からの utils create report database コマンド。   .tarファイルをダウンロードし、SFTPサーバを使用します。

詳細については、次のリンクを参照してください。

CUCMのutils dbreplication runtimestateの出力について

CUCM データベース レプリケーション Linux アプライアンス モデルのトラブルシューティング