ホストの再起動時に問題が発生している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
ご注意いただきありがとうございます、Mickaël。 –
私は「restart」という用語を使用したとき、同じノードの停止と起動を指していました。私たちの環境では、いつでも第2のノードを再起動できますが、最初のノードを正常に再起動するには、2番目のノードを停止する必要があります。 Stop02、stop01、start01、start02は、停止01、停止02、開始01、開始02と同様に機能します。ただし、stop01、stop02、start02、start01は機能しません。私は、node01が最初に再起動する必要のあるクラスタマスターであるという結論を出したいと思います。ノードを再起動したい理由は、ノードのインスタンスを使用可能にしてダウンタイムを避けるためです。 –
システムエンジニアによる推奨代替案は、クラスタのノードをクラスタから削除し、オーダーの管理にも注意が必要で、ホストがただ失敗して応答しない場合には必要な手順がないため、オーバーヘッドを犠牲にして変更および再結合することです。私はより良い言い換えられた質問は** "システムレベルではなく、変更を非システムレベルでいつでもクラスタを維持することによって再起動を行う正しい方法は何ですか?** –