Riak 和 Stanchion 服务突然停止在生产环境中工作，控制台日志中出现以下错误。
2023-11-07 03:41:14.547 [信息] <0.160.0>@riak_core_app:stop:114 已停止应用程序 riak_core。 2023-11-07 03:41:14.547 [错误] <0.164.0> 主管 riak_core_vnode_sup 在未定义的退出处以 riak_core_vnode:start_link() 启动了未定义的子项，并在上下文 shutdown_error 中杀死了原因 2023-11-07 03:41:14.547 [错误] <0.164.0> 主管 riak_core_vnode_sup 在未定义退出时以 riak_core_vnode:start_link() 启动子进程未定义，并在调用 ets:lookup(ets_riak_kv_entropy, {index,{riak_kv,12331420064979493372 时参数错误34359077604363797834693083136} }) 在 riak_kv_entropy_info:update_index_info/2 第 161 行上下文 shutdown_error 2023-11-07 03:41:14.547 [错误] <0.164.0> 主管 riak_core_vnode_sup 在未定义退出时以 riak_core_vnode:start_link() 启动子进程未定义，并在调用 ets:lookup(ets_riak_kv_entropy, {index,{riak_kv,11874700803313586210 时参数错误40493926581979953470445191168} }) 在 riak_kv_entropy_info:update_index_info/2 第 161 行上下文 shutdown_error
我们尝试过重新启动服务，甚至删除 /../../ring 文件夹中的所有文件并重新加入集群，但没有成功。
请有人帮忙解决这个问题??
我们尝试过重新启动服务，甚至删除 /../../ring 文件夹中的所有文件并重新加入集群，但没有成功。
这是一个有趣的问题。由于 Stanchion 是一个独立的软件，因此只要集群中的其他节点继续运行，它就应该仍然可以工作。顺便说一句，如果您使用 Riak CS 3.1 或更高版本（撰写本文时的最新版本是 Riak CS 3.2.2），则 Stanchion 是从 Riak CS 内自动管理的，因此，在极少数情况下 Stanchion 宕机（通常是硬件）失败），Riak CS 会注意到这一点并在不同的节点上生成一个新的 Stanchion 实例。
关于您看到的错误消息，Riak KV 似乎遇到了 AAE 问题。由于 AAE 哈希树通常会被 Riak 销毁和重建，因此删除它们是安全的，因为 Riak 稍后会简单地重建它们。如果您转到数据目录（通常是 /var/lib/riak，除非您在 /etc/riak/riak.conf 中指定了不同的位置），应该有一个名为“anti_entropy”的文件夹。您可以使用以下命令安全地删除其中所有文件夹的内容：
cd /var/lib/riak
for i in $(ls anti_entropy); do rm -rf anti_entropy/$i/*; done
上述操作也可以在 anti_entropy 目录中完成，但如果原始“cd”命令中有拼写错误，则可能会删除错误文件夹中的内容。
删除哈希树后，重新启动服务器以清除内存中可能残留的任何内容，然后尝试再次启动 Riak KV。
考虑到 Stack Overflow 单一答案的局限性，而不是我们普通 Riak 支持票证系统的奢华，我将以下内容作为最后的手段。
如果上述方法仍然失败，Riak 默认情况下会存储所有数据的 3 个副本（n_val=3）。在最坏的情况下，您可以完全擦除该节点，重新安装它，将其重新添加到集群中，然后对其执行所有分区修复。您可以选择将其设置为不同的节点，即不同的 IP 和节点名称，并强制替换现已失效的节点。这将是集群加入、强制替换，然后是集群提交。
通常，强制替换后会在加入的节点上进行全分区修复，因为集群提交只会提供分区句柄，但不会提供分区的实际内容。通常，这是由 AAE 缓慢复制并读取修复，但这可能需要一段时间才能填充。然而，全分区修复将导致所有数据的填充速度更快，但代价是暂时增加资源使用量。