2016-09-26 8 views
0

У нас есть кластер 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 

ответ

0

NB: он не воспроизводится, если хосты перезапускаются в обратном порядке.

Непоследовательная база данных предназначена для защиты данных. Если вы остановили кластер в одном порядке, вам необходимо перезапустить его в обратном порядке. В противном случае, первый узел остановился, будет записан, что есть другой активный узел и что для актуальной информации, чтобы предотвратить потерю данных.

+0

Благодарим вас за внимание, Микаэль. –

+0

Когда я использовал термин «перезагрузка», я ссылался на остановку и запуск одного и того же узла. В нашей среде мы можем перезапустить второй узел в любое время, но для того, чтобы изящно перезапустить первый узел, нужно удалить второй узел. Stop02, stop01, start01, start02, а также останов 01, останов 02, запуск 01, запуск 02. Однако stop01, stop02, start02, start01 не работает. Я хочу сделать вывод, что node01 является своего рода кластерным мастером, который нужно сначала перезапустить. Причина, по которой мы хотели бы перезапустить узлы, - это сохранить экземпляры доступных узлов, избегая простоев. –

+0

Предлагаемая альтернатива нашим системным инженером заключается в удалении узлов из кластера, внесении изменений и воссоединении их за счет накладных расходов, поскольку администрирование заказа также требует внимания и никаких необходимых шагов, если хост просто не работает и не отвечает. Я считаю, что лучше перефразировать вопрос: «Какой правильный способ сделать перезагрузки, сохраняя кластер в любое время после нарушения системного уровня?» –