Перебалансировка узла riak_core_ng зависает навсегда в ожидании модуля vnode - PullRequest
Новая
       52

Перебалансировка узла riak_core_ng зависает навсегда в ожидании модуля vnode

0 голосов
/ 21 апреля 2019

Я уже видел этот вопрос и это сообщение в списке рассылки о перебалансировках ожидающих узлов, но они не помогли решить мою проблему.Подобным образом, такие вещи, как this , не помогли пролить свет на происходящее.Я следовал этому руководству и переводил его на Эликсир по ходу дела.В разделе 3. я столкнулся с этой проблемой.

:riak_core объявлено в моем mix.exs следующим образом: 

{:riak_core, github: "Kyorai/riak_core", branch: "fifo-merge"},

и escriptize часть cuttlefishrebar.config закомментирован так, что он может даже построить.

Я использую Elixir 1.8.1 с Erlang 21.3.Все узлы выполняются на одном и том же компьютере.

Я определяю модуль vnode, как описано в связанном учебном пособии riak_core, включая удаление обратных вызовов, не упомянутых в руководстве, и настраиваю riak_core следующим образом.: 

case Supervisor.start_link(children, opts) do
  {:ok, pid} ->
    :ok = :riak_core.register vnode_module: MyApp.VNode
    :ok = :riak_core_node_watcher.service_up MyApp.Service, self()
    Supervisor.start_child MyApp.Supervisor, worker(:riak_core_vnode_master, [MyApp.VNode], id: :riak_core_vnode_master)
    {:ok, pid}
  {:error, reason} ->
    {:error, reason}
end

Затем я запускаю два узла MyApp.Оба запускаются с iex --name whatever@127.0.0.1 -S mix run --no-halt, где длинные имена узлов: myapp-1@127.0.0.1 и myapp-2@127.0.0.1.Оба узла запускаются нормально по отдельности и запускают свои отдельные vnode.

На этом этапе я пытаюсь присоединить второй узел к первому.При объединении узлов через :riak_core.join 'myapp-1@127.0.0.1', кажется, что он изначально работает:

:riak_core_console.member_status []: 

================================= Membership ==================================
Status     Ring    Pending    Node
-------------------------------------------------------------------------------
valid     100.0%     50.0%    'myapp-1@127.0.0.1'
valid       0.0%     50.0%    'myapp-2@127.0.0.1'
-------------------------------------------------------------------------------

:riak_core_ring.pretty_print ring, [:legend]: 

==================================== Nodes ====================================
Node a: 64 (100.0%) myapp-1@127.0.0.1
Node b: 0 (  0.0%) myapp-2@127.0.0.1
==================================== Ring =====================================
aaaa|aaaa|aaaa|aaaa|aaaa|aaaa|aaaa|aaaa|aaaa|aaaa|aaaa|aaaa|aaaa|aaaa|aaaa|aaaa|

:riak_core_console.ring_status []: 

================================== Claimant ===================================
Claimant:  'myapp-1@127.0.0.1'
Status:     up
Ring Ready: true

============================== Ownership Handoff ==============================
Owner:      myapp-1@127.0.0.1
Next Owner: myapp-2@127.0.0.1

Index: 22835963083295358096932575511191922182123945984
  Waiting on: [MyApp.VNode]

Index: 45671926166590716193865151022383844364247891968
  Waiting on: [MyApp.VNode]

... this continues for every vnode...

-------------------------------------------------------------------------------

============================== Unreachable Nodes ==============================
All nodes are up and reachable

но он просто застревает в этом состоянии навсегда.Ожидание до 15 минут ничего не меняет, поэтому я могу только предположить, что что-то не так.

Пройдя несколько раз, я добавил некоторые входы в каждый обратный вызов в MyApp.VNode.MyApp.VNode.init/1 вызывается для каждого vnode, пытающегося переместиться на myapp-2@127.0.0.1, но никакие другие обратные вызовы никогда не вызываются.Узел myapp-2@127.0.0.1 пытается запустить vnode 3 раза, а затем, по-видимому, сдается.В этот момент кластер «зависает» в этом состоянии навсегда.Никакой новой информации не зарегистрировано;я не вижу никаких ошибок или информационных / отладочных сообщений.Кроме того, нет файлов журналов в каталогах log*/ в корне моего проекта.

При включенных журналах отладки в :lager я получаю: 

20:41:37.865 [debug] started riak_core_metadata_manager exchange with 'myapp-2@127.0.0.1' (<0.825.0>)
20:41:37.866 [debug] Tree {state,<<0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0>>,cluster_meta,3,65536,256,0,{dict,0,16,16,8,80,48,{[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[]},{{[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[]}}},#Ref<0.2966336661.3930193920.250738>,"./data_myapp-1/cluster_meta/trees",undefined,full,[],0,{array,2428,0,0,10000}} level 1 bucket 0
L=[]
R=[]
D=[]
20:41:37.866 [debug] completed metadata exchange with 'myapp-2@127.0.0.1'. nothing repaired

на обоих узлах,На узле, который должен принимать vnode, я получаю: 

20:42:11.655 [debug] vnode :: 'Elixir.MyApp.VNode'/1415829711164312202009819681693899175291684651008 :: undefined
20:42:11.655 [debug] Started VNode, waiting for initialization to complete <0.807.0>, 1415829711164312202009819681693899175291684651008 
20:42:11.655 [debug] VNode initialization ready <0.807.0>, 1415829711164312202009819681693899175291684651008

, который повторяется со всеми 3 попытками запуска vnode.В журналах отладки первого узла я вижу, что есть 32 ожидающие передачи, но они никогда не завершаются.

Вещи, которые я пытался исправить это:

  • Решение, предложенное в этот вопрос .Ничего не изменилось.
  • После этого руководства , написанного на эликсире.Это ничего не изменило для меня.
  • Использование :riak_core_ng из Hex вместо GitHub.Это также не решило проблему.
  • Изменение модуля, зарегистрированного в качестве службы.
  • Изменение модуля vnode.
  • Объединение узлов вместе с :riak_core.join/1
  • Объединение узлов вместес Node.connect/1 перед вызовом :riak_core.join/1.

Обновление: я начал копать в обратном направлении от :riak_core_console.ring_status/1.Это привело меня к :riak_core_vnode.maybe_handoff/3.Я обнаружил, что maybe_handoff на самом деле никогда не вызывали, так что это привело меня к поиску того, откуда оно в конечном счете вызывалось.После прохождения этого приключения через :riak_core_vnode_manager лучшее, что я смог догадаться, это то, что что-то внутри riak_core неправильно вызывает функции передачи обслуживания.Сейчас я просто молюсь, чтобы мои предположения были неверными.

...