2014-07-17 02:50 PM
2014年7月17日(初版)
replicationdynamicテーブルにおいて、データのミスマッチが発生する場合があります。
Admin CLIにおいて、utils dbreplication statusコマンドの結果出力ファイル内に以下の例のような記述が見られます。
---------- Suspect Replication Summary ----------
For table: ccmdbtemplate_cucm862pub_ccm8_6_2_23059_1_1_225_replicationdynamic
replication is suspect for node(s):
g_cucm862sub2_ccm8_6_2_23059_1
-------------------------------------------------
実装通りの動作です。
replicationdynamicテーブルは、各サーバのデータベースが最後に更新されたタイムスタンプを管理しているテーブルであり、動的に書き換えられるテーブルのため、期待動作として一時的にmismatchが発生する場合があります。
解決策
期待動作のため、replicationdynamicテーブルにおける一時的なmismatchについては、サービス影響を与えるものではありません。もし、管理上問題となるようでしたら、Admin CLIにおいて以下のコマンドを用いて修正してください。
utils dbreplication repairtable replicationdynamic
備考:
replicationdynamic テーブルはReplicate Stateの遷移に利用されており、もし、クラスタ内のサーバが一定時間以上ダウンした場合や、ネットワークから切り離された状態が継続すると、 replicationdynamicテーブルで管理しているタイムスタンプが更新されず、Replicate State が "3" に遷移します。
その後、サーバとの接続が正常になり、replicationによってデータベースが更新され、replicationdynamicテーブルが管理しているタイムスタンプが更新されると、"2" に遷移します。
もし、replicationdynamicテーブルが一定時間以上更新されず、Replicate State が "3" に遷移した場合は、サーバの接続性を確認するとともに、下記のページ等を参考に状況を確認してください。
Linux アプライアンス モデルにおける CUCM データベース レプリケーションのトラブルシューティング
https://supportforums.cisco.com/docs/DOC-16698#Using_Replication_Commands
検索バーにキーワード、フレーズ、または質問を入力し、お探しのものを見つけましょう
シスコ コミュニティをいち早く使いこなしていただけるよう役立つリンクをまとめました。みなさんのジャーニーがより良いものとなるようお手伝いします
下記より関連するコンテンツにアクセスできます