riak_core_ng节点重新平衡永远挂在vnode模块上等待

时间:2019-04-21 00:48:07

标签: erlang elixir riak

我已经看到this questionthis mailing list post关于未决节点重新平衡的信息,但是它们并不能帮助解决我的问题。同样,this之类的内容也无助于阐明正在发生的事情。我在关注this guide并将其翻译为Elixir。第3节是我遇到此问题的地方。

:riak_core在我的mix.exs中声明为:

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

escriptize cuttlefish的{​​{1}}部分被注释掉,甚至可以构建。

我将Elixir 1.8.1和Erlang 21.3结合使用。所有节点都在同一台计算机上运行。

我按照链接的rebar.config教程中的说明定义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-haltmyapp-1@127.0.0.1。两个节点都可以正常启动,然后分别启动各自的vnode。

在这一点上,我尝试将第二个节点加入第一个节点。通过myapp-2@127.0.0.1将节点连接在一起时,它最初似乎可以正常工作:

: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 []

但是它永远被卡在这种状态。等待15分钟不会改变任何事情,因此我只能假设还有其他问题。

运行了几次之后,我在================================== 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 的每个回调中添加了一些日志记录。每个试图移到MyApp.VNode的vnode都被调用MyApp.VNode.init/1,但是从未调用过其他回调。 myapp-2@127.0.0.1节点尝试启动vnode 3次,然后似乎放弃了。此时,群集将永远处于这种状态。没有记录新信息;我看不到任何错误或信息/调试消息。此外,我项目的根目录myapp-2@127.0.0.1中没有日志文件。

log*/中启用调试日志后,我得到:

:lager
在两个节点上

。在应该接收vnode的节点上,我得到:

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

,在所有3个vnode启动尝试中都会重复。在第一个节点的调试日志中,我可以看到有32个挂起的传输,但是它们从未完成。

我试图解决的问题:

  • this question中建议的解决方案。它什么都没改变。
  • this guide之后,用Elixir写。这对我没有任何改变。
  • 使用来自Hex的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 而非GitHub。这也没有解决问题。
  • 更改正在注册为服务的模块。
  • 更改vnode模块。
  • 将节点与:riak_core_ng一起加入
  • 在调用: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内部的某些东西没有正确调用切换功能。目前,我主要只是祈祷我的猜测是错误的。

0 个答案:

没有答案