У нас есть кластер ejabberd, состоящий из двух хостов, с которыми мы сталкиваемся с проблемами во время перезапусков хостов. Мы видим ошибки inconsistent_database вошедших в систему. Однако мы не можем окончательно проанализировать, что в конфигурациях или выполнении mod_init может привести к поведению. Удаление проблемы mnesia на узле1 может помочь решить проблему. Тем не менее, это нежелательно для целей администрирования.Как решить проблему Mnesia - inconsistent_database в кластерной среде ejabberd?
Хотелось бы запросить обзор данных ниже, а также некоторую конфигурацию и отзывы о том, что может фактически вызвать поведение, а также как смягчить его.
Заранее спасибо.
Конфигурация среды заключается в следующем:
- Ejabberd Verison: 16,03
- Кол-во хостов: 2
- odbc_type: MySQL вошли
Ошибка:
** ERROR ** mnesia_event got {inconsistent_database, running_partitioned_network, other_node}
Шаг протектора:
- Restart node1
- Restart node2
NB: это не Репрографический, если хозяева перезапущен в обратном порядке.
MnesiaInfo:
Там, кажется, две схемы с различными размерами входа и possbily содержание на любых узлах: muc_online_room и наши пользовательские схемы, как переименованный SCRUBBED_CUSTOM_FEATURE_SCHEMA_NAME вниз ниже:
Node1:
---> 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
Узел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
Благодарим вас за внимание, Микаэль. –
Когда я использовал термин «перезагрузка», я ссылался на остановку и запуск одного и того же узла. В нашей среде мы можем перезапустить второй узел в любое время, но для того, чтобы изящно перезапустить первый узел, нужно удалить второй узел. Stop02, stop01, start01, start02, а также останов 01, останов 02, запуск 01, запуск 02. Однако stop01, stop02, start02, start01 не работает. Я хочу сделать вывод, что node01 является своего рода кластерным мастером, который нужно сначала перезапустить. Причина, по которой мы хотели бы перезапустить узлы, - это сохранить экземпляры доступных узлов, избегая простоев. –
Предлагаемая альтернатива нашим системным инженером заключается в удалении узлов из кластера, внесении изменений и воссоединении их за счет накладных расходов, поскольку администрирование заказа также требует внимания и никаких необходимых шагов, если хост просто не работает и не отвечает. Я считаю, что лучше перефразировать вопрос: «Какой правильный способ сделать перезагрузки, сохраняя кластер в любое время после нарушения системного уровня?» –