将分片从一台 bigcouch 服务器移动到另一台服务器（用于平衡）
我目前正在测试 bigcouch 的大量数据（每天 1500 万条记录）。
当我需要生成数据视图时，我遇到了一些平衡问题，因为我的两台机器中的一台比另一台弱得多。结果是，较好的机器已经完成并无事可做，而较弱的机器仍有很多工作要做。 （单核与双核）
我现在的想法是将一些碎片从较弱的机器移动到另一台机器，以便它们大约在同一时间完成。
因此我的问题是，如何将分片从较周的 bigcouch 服务器移动到更好的服务器？
感谢您的帮助+最诚挚的问候！
安迪
I'm currently testing bigcouch for big amounts of data (15 million records daily).
When I need to generate views of the data, I experience some balancing problems, because one of my two machines is much weaker than the other one. The result is, that the better machine is finished and has nothing to do while the weaker one has still a lot to do. (single- vs. dualcore)
My idea is now to move some shards from the weaker machine to the other one, so that they are finished at about the same time.
Therefore my question is, how can I move shards from the weeker bigcouch server to the better one?
Thank you for your help + best regards!
Andy
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
Bigcouch 分片只是 CouchDB 数据库，因此移动它们的过程非常简单。 Bigcouch 的未来版本将使该过程自动化，但现在我只描述它。
一些背景知识将有助于解释。 Bigcouch 节点正在侦听两个端口：5984 和 5986。前端口 5984 看起来像 CouchDB（同时具有集群性和容错性）。后端端口 5986 直接与特定节点上的底层 CouchDB 服务器通信。您会注意到，除了数据库的分片之外，localhost:5986/_all_dbs 中还显示了两个额外的数据库。其中一个称为“节点”，您在设置集群时就已经与它进行了交互。另一个称为“dbs”，包含每个集群数据库的文档，指定数据库每个分片的每个副本实际所在的位置。
因此，要移动分片，您需要做一些事情；
步骤1
在你的Bigcouch节点的数据目录中，你会发现这样的文件；
所有分片都组织在 shards/ 目录下，然后按范围，最后是名称后跟一个随机数。
选择数据库的文件之一并记住其名称。
步骤2
使用任意方法将该文件复制到目标服务器上的同一路径。 rsync 和 scp 是不错的选择，CouchDB 复制也是如此（确保从端口 5986 复制到端口 5986）。
步骤 3
需要修改“dbs”中管理集群数据库布局的文档。它看起来有点像这样；
更新 by_node 和 by_range 值，以便您移动的分片解析到新主机。
此时您已经移动了分片。但是，如果自您开始复制文件以来但在更新“dbs”文档之前有更新，则这些写入发生在原始节点并且不可见，因此您应该继续执行步骤 4。如果没有更新，您可以删除原始服务器上的分片，但我建议您检查端口 5984 上的数据库以确保所有文档都正确显示。
步骤 4
执行从源分片到目标分片的复制，再次注意在每个分片的 5986 端口上执行此操作。这将确保所有更新再次可用。您现在可以在原始服务器上删除此分片的副本。
哈特哈，
罗伯特·纽森 - Cloudant。
Bigcouch shards are simply CouchDB databases so the procedure for moving them is pretty simple. A future release of Bigcouch will automate the process but, for now, I'll just describe it.
A little background will help ground the explanation. A Bigcouch node is listening on two ports, 5984 and 5986. The front port, 5984, looks like CouchDB (while being clustered and fault-tolerant). The back port, 5986, talks directly to the underlying CouchDB server on a particular node. You will notice that there are two extra databases shown in localhost:5986/_all_dbs besides the shards of your database. One is called 'nodes' and you have already interacted with it when you set up your cluster. The other is called 'dbs' and contains a document for each clustered database, specifying where each copy of each shard of your database actually lives.
So, to move a shard, you need to do a few things;
Step 1
In the data directory of your Bigcouch node, you will find files like this;
All shards are organized under the shards/ directory, then by range, and finally the name followed by a random number.
Select one of the files for your database and remember its name.
Step 2
Use any method to copy this file to the same path on your target server. rsync and scp are fine choices, as is CouchDB replication (be sure to replicate from port 5986 to port 5986).
Step 3
The document in 'dbs' that governs the layout of your clustered database needs to be modified. It looks a bit like this;
Update both the by_node and by_range values so that the shard you have moved resolves to the new host.
At this point you have moved the shard. However, if there have been updates since you started copying the file but before you updated the 'dbs' document, those writes happened at the original node and are not visible so you should proceed to step 4. If there have been no updates, you can delete the shard on the original server, though I recommend you check your database on port 5984 to be sure all your docs show up correctly.
Step 4
Perform a replication from the source shard to the target shard, again taking care to do this on the 5986 port of each. This will ensure that all updates are available once again. You can now delete the copy of this shard on the original server.
HTH,
Robert Newson - Cloudant.