Couchdb 3.1.0集群-重启一个节点后数据库加载失败
Couchdb 3.1.0 cluster - database failed to load after restarting one node
情况如下：在由两个节点组成的 couchdb 集群上，每个节点都是服务器（ip1 和 ip2）上的一个 couchdb docker 实例。我不得不重新启动一台服务器并重新启动 docker，之后我的两个 couchdb 实例都会为每个数据库显示："This database failed to load."
我可以连接到 Futon 并查看完整的数据库列表，但仅此而已。在 "Verify Couchdb Installation" 和 Futon 上我有几个错误（只有 'Create database' 是绿色勾号）
容器的 docker 日志给我这个错误：
"internal_server_error : No DB shards could be opened"
我试图通过将 .couch 和 shards/ 文件复制到 couchdb 的本地实例来在本地恢复数据库，但出现了同样的问题。
如何检索数据？
PS：我用 erl 检查了两个节点之间的连接，没问题。看起来 docker 在重启时弄乱了一些 couchdb 配置文件。
好吧，以防万一有人犯同样的错误:
当你有一个 2 节点集群，couchdb@ip1 和 couchdb@ip2，并从 couchdb@ip1 创建集群时：
1) 如果节点 couchdb@ip2 停止，则集群设置混乱（couchdb@ip1 将不再工作），重新启动时节点似乎无法正确连接并且数据库会出现但会不可用。
2) 另一方面，停止和启动 couchdb@ip1 不会造成任何问题
情况 1 的解决方案是用 2 个新的 couchdb 实例（couchdb@ip1 和 couchdb@ip2）重新创建集群，然后将数据库复制到一个 couchdb 实例上，所有数据库都会恢复！
谁能详细解释一下为什么会这样？这也意味着这个集群配置是绝对不可靠的（如果 couchdb@ip2 宕机了就什么都做不了），我猜它不会和 3 节点集群一样？
元数据和克隆节点
个别数据库有metadata indicating on which nodes their shards are stored which is built on creation based on cluster options, so copying database files alone does not actually move or mirror the database on to the new node. (If one sets the metadata correctly the shards are copied by couch itself, so copying the files is only done to speed up the process.)
副本数
2 节点集群通常没有意义。与文件系统 RAID 一样，您可以条带化以获得最大性能和一半的可靠性，或者您可以创建一个镜像，但除非单个节点状态具有完美的一致性检测，否则无法自动确定两个节点中的哪个不正确，同时决定 3 个节点中的哪个是不正确的很容易自动执行。因此，大多数集群都是 3 个或更多节点，每个分片在任意 3 个节点上都有 3 个副本。
情况如下：在由两个节点组成的 couchdb 集群上，每个节点都是服务器（ip1 和 ip2）上的一个 couchdb docker 实例。我不得不重新启动一台服务器并重新启动 docker，之后我的两个 couchdb 实例都会为每个数据库显示："This database failed to load."
我可以连接到 Futon 并查看完整的数据库列表，但仅此而已。在 "Verify Couchdb Installation" 和 Futon 上我有几个错误（只有 'Create database' 是绿色勾号）
容器的 docker 日志给我这个错误：
"internal_server_error : No DB shards could be opened"
我试图通过将 .couch 和 shards/ 文件复制到 couchdb 的本地实例来在本地恢复数据库，但出现了同样的问题。
如何检索数据？
PS：我用 erl 检查了两个节点之间的连接，没问题。看起来 docker 在重启时弄乱了一些 couchdb 配置文件。
好吧，以防万一有人犯同样的错误:
当你有一个 2 节点集群，couchdb@ip1 和 couchdb@ip2，并从 couchdb@ip1 创建集群时：
1) 如果节点 couchdb@ip2 停止，则集群设置混乱（couchdb@ip1 将不再工作），重新启动时节点似乎无法正确连接并且数据库会出现但会不可用。
2) 另一方面，停止和启动 couchdb@ip1 不会造成任何问题
情况 1 的解决方案是用 2 个新的 couchdb 实例（couchdb@ip1 和 couchdb@ip2）重新创建集群，然后将数据库复制到一个 couchdb 实例上，所有数据库都会恢复！
谁能详细解释一下为什么会这样？这也意味着这个集群配置是绝对不可靠的（如果 couchdb@ip2 宕机了就什么都做不了），我猜它不会和 3 节点集群一样？
元数据和克隆节点
个别数据库有metadata indicating on which nodes their shards are stored which is built on creation based on cluster options, so copying database files alone does not actually move or mirror the database on to the new node. (If one sets the metadata correctly the shards are copied by couch itself, so copying the files is only done to speed up the process.)
副本数
2 节点集群通常没有意义。与文件系统 RAID 一样，您可以条带化以获得最大性能和一半的可靠性，或者您可以创建一个镜像，但除非单个节点状态具有完美的一致性检测，否则无法自动确定两个节点中的哪个不正确，同时决定 3 个节点中的哪个是不正确的很容易自动执行。因此，大多数集群都是 3 个或更多节点，每个分片在任意 3 个节点上都有 3 个副本。