2016-09-26 6 views
0

ホストの再起動時に問題が発生している2つのホストからなるejabberdクラスタが設定されています。 inconsistent_databaseエラーが記録されています。しかし、実際にコンフィギュレーションやmodule_initの実行で何が起こるのかを決定的に分析することはできません。 ノード1のmnesiaを削除すると、問題を解決するのに役立ちます。しかし、それは投与目的には望ましくない。クラスタ化されたejabberd環境でのMnesia - inconsistent_databaseエラーの解決方法

以下のデータのレビューと、実際にその動作を引き起こしている可能性のあるものとそれを緩和する方法についてのフィードバックをリクエストしたいと思います。

ありがとうございます。

  • Ejabberd Verison:ホストの16.03
  • 数:2
  • odbc_type:MySQLの

エラーがログに記録:

** ERROR ** mnesia_event got {inconsistent_database, running_partitioned_network, other_node} 
を次のように

環境設定です

複製ステップ:

  • 再起動ノード1
  • 再起動ノード2

NB:ホストが逆の順序で再起動された場合、それはREPROしません。

MnesiaInfo:ダウン下の名前を変更SCRUBBED_CUSTOM_FEATURE_SCHEMA_NAMEとして muc_online_room、当社のカスタムスキーマ:

ノード1:

---> Processes holding locks <--- 
---> Processes waiting for locks <--- 
---> Participant transactions <--- 
---> Coordinator transactions <--- 
---> Uncertain transactions <--- 
---> Active tables <--- 
mod_register_ip: with 0  records occupying 299  words of mem 
muc_online_room: with 348  records occupying 10757 words of mem 
http_bind  : with 0  records occupying 299  words of mem 
carboncopy  : with 0  records occupying 299  words of mem 
oauth_token : with 0  records occupying 299  words of mem 
session  : with 0  records occupying 299  words of mem 
session_counter: with 0  records occupying 299  words of mem 
sql_pool  : with 10  records occupying 439  words of mem 
route   : with 4  records occupying 405  words of mem 
iq_response : with 0  records occupying 299  words of mem 
temporarily_blocked: with 0  records occupying 299  words of mem 
s2s   : with 0  records occupying 299  words of mem 
route_multicast: with 0  records occupying 299  words of mem 
shaper   : with 2  records occupying 321  words of mem 
access   : with 28  records occupying 861  words of mem 
acl   : with 6  records occupying 459  words of mem 
local_config : with 32  records occupying 1293  words of mem 
schema   : with 19  records occupying 2727  words of mem 
SCRUBBED_CUSTOM_FEATURE_SCHEMA_NAME  : with 2457  records occupying 49953 words of mem 
===> System info in version "4.12.5", debug level = none <=== 
opt_disc. Directory "SCRUBBED_LOCATION" is used. 
use fallback at restart = false 
running db nodes = [SCRUBBED_NODE2,SCRUBBED_NODE1] 
stopped db nodes = [] 
master node tables = [] 
remote    = [] 
ram_copies   = [access,acl,carboncopy,http_bind,iq_response, 
         local_config,mod_register_ip,muc_online_room,route, 
         route_multicast,s2s,session,session_counter,shaper, 
         sql_pool,temporarily_blocked,SCRUBBED_CUSTOM_FEATURE_SCHEMA_NAME] 
disc_copies  = [oauth_token,schema] 
disc_only_copies = [] 
[{'SCRUBBED_NODE1',disc_copies}, 
{'SCRUBBED_NODE2',disc_copies}] = [schema, 
                    oauth_token] 
[{'SCRUBBED_NODE1',ram_copies}] = [local_config, 
                   acl,access, 
                   shaper, 
                   sql_pool, 
                   mod_register_ip] 
[{'SCRUBBED_NODE1',ram_copies}, 
{'SCRUBBED_NODE2',ram_copies}] = [route_multicast, 
                   s2s, 
                   temporarily_blocked, 
                   iq_response, 
                   route, 
                   session_counter, 
                   session, 
                   carboncopy, 
                   http_bind, 
                   muc_online_room, 
                   SCRUBBED_CUSTOM_FEATURE_SCHEMA_NAME] 
2623 transactions committed, 35 aborted, 26 restarted, 60 logged to disc 
0 held locks, 0 in queue; 0 local transactions, 0 remote 
0 transactions waits for other nodes: [] 
ok 

異なるエントリサイズのいずれかのノード上possbilyコンテンツを持つ2つのスキーマがあるようです

ノード2:

mnesia:info(). 
---> Processes holding locks <--- 
---> Processes waiting for locks <--- 
---> Participant transactions <--- 
---> Coordinator transactions <--- 
---> Uncertain transactions <--- 
---> Active tables <--- 
mod_register_ip: with 0  records occupying 299  words of mem 
muc_online_room: with 348  records occupying 8651  words of mem 
http_bind  : with 0  records occupying 299  words of mem 
carboncopy  : with 0  records occupying 299  words of mem 
oauth_token : with 0  records occupying 299  words of mem 
session  : with 0  records occupying 299  words of mem 
session_counter: with 0  records occupying 299  words of mem 
route   : with 4  records occupying 405  words of mem 
sql_pool  : with 10  records occupying 439  words of mem 
iq_response : with 0  records occupying 299  words of mem 
temporarily_blocked: with 0  records occupying 299  words of mem 
s2s   : with 0  records occupying 299  words of mem 
route_multicast: with 0  records occupying 299  words of mem 
shaper   : with 2  records occupying 321  words of mem 
access   : with 28  records occupying 861  words of mem 
acl   : with 6  records occupying 459  words of mem 
local_config : with 32  records occupying 1293  words of mem 
schema   : with 19  records occupying 2727  words of mem 
SCRUBBED_CUSTOM_FEATURE_SCHEMA_NAME  : with 2457  records occupying 38232 words of mem 
===> System info in version "4.12.5", debug level = none <=== 
opt_disc. Directory "SCRUBBED_LOCATION" is used. 
use fallback at restart = false 
running db nodes = ['SCRUBBED_NODE1','SCRUBBED_NODE2'] 
stopped db nodes = [] 
master node tables = [] 
remote    = [] 
ram_copies   = [access,acl,carboncopy,http_bind,iq_response, 
         local_config,mod_register_ip,muc_online_room,route, 
         route_multicast,s2s,session,session_counter,shaper, 
         sql_pool,temporarily_blocked,SCRUBBED_CUSTOM_FEATURE_SCHEMA_NAME] 
disc_copies  = [oauth_token,schema] 
disc_only_copies = [] 
[{'SCRUBBED_NODE1',disc_copies}, 
{'SCRUBBED_NODE2',disc_copies}] = [schema, 
                    oauth_token] 
[{'SCRUBBED_NODE1',ram_copies}, 
{'SCRUBBED_NODE2',ram_copies}] = [route_multicast, 
                   s2s, 
                   temporarily_blocked, 
                   iq_response, 
                   route, 
                   session_counter, 
                   session, 
                   carboncopy, 
                   http_bind, 
                   muc_online_room, 
                   SCRUBBED_CUSTOM_FEATURE_SCHEMA_NAME] 
[{'SCRUBBED_NODE2',ram_copies}] = [local_config, 
                   acl,access, 
                   shaper, 
                   sql_pool, 
                   mod_register_ip] 
2998 transactions committed, 18 aborted, 0 restarted, 99 logged to disc 
0 held locks, 0 in queue; 0 local transactions, 0 remote 
0 transactions waits for other nodes: [] 
ok 

答えて

0

NB:ホストが逆の順序で再起動された場合は再書き込みしません。

不一致データベースは、データを保護することです。クラスタを1つの順序で停止した場合は、逆の順序でクラスタを再起動する必要があります。それ以外の場合、最初のノードが停止し、他のアクティブノードが存在し、最新の情報がデータ損失を防止するために記録されます。

+0

ご注意いただきありがとうございます、Mickaël。 –

+0

私は「restart」という用語を使用したとき、同じノードの停止と起動を指していました。私たちの環境では、いつでも第2のノードを再起動できますが、最初のノードを正常に再起動するには、2番目のノードを停止する必要があります。 Stop02、stop01、start01、start02は、停止01、停止02、開始01、開始02と同様に機能します。ただし、stop01、stop02、start02、start01は機能しません。私は、node01が最初に再起動する必要のあるクラスタマスターであるという結論を出したいと思います。ノードを再起動したい理由は、ノードのインスタンスを使用可能にしてダウンタイムを避けるためです。 –

+0

システムエンジニアによる推奨代替案は、クラスタのノードをクラスタから削除し、オーダーの管理にも注意が必要で、ホストがただ失敗して応答しない場合には必要な手順がないため、オーバーヘッドを犠牲にして変更および再結合することです。私はより良い言い換えられた質問は** "システムレベルではなく、変更を非システムレベルでいつでもクラスタを維持することによって再起動を行う正しい方法は何ですか?** –

関連する問題