CouchDB学习-集群管理

大家好，欢迎来到IT知识分享网。

集群管理

理论

在etc/fefault.ini文件中有以下部分：

[cluster] q=8 n=3

• q – 分片的数量
• n – 每一份文档的拷贝数量(加上原文档一共几份副本)

节点管理

查看所有节点

curl -u admin:adminpw -X GET http://localhost:5984/_membership { "all_nodes":[ # 当前节点所知道的节点 ""], "cluster_nodes":[ #当前节点所连接的节点 ""], }

添加一个节点

curl -u admin:adminpw -X PUT http://localhost:5986/_nodes/ -d {}

删除一个节点

#首先获取关于文档的revision curl -u admin:adminpw -X GET "http://xxx.xxx.xxx.xxx:5986/_nodes/" {"_id":"","_rev":"1-967a00dff5e02addabb3284d"} #删除节点 curl -u admin:adminpw -X DELETE http://localhost:5986/_nodes/?rev=1-967a00dff5e02addabb3284d

数据库管理

创建数据库

数据库名字不支持大写字符，只支持[a-z],[0-9],以及特殊字符:_ $ ( ) + - /

#创建一个数据库名字为db_name curl -u admin:adminpw -X PUT http://localhost:5984/db_name?q=4&n=2

删除数据库

curl -u admin:adminpw -X DELETE http://localhost:5984/db_name

在一个具体的节点放置数据库

"zone":"metro-dc-a"

[cluster] placement = metro-dc-a:2,metro-dc-b:1

在此示例中，它将确保将一个分区的两个副本托管在将zone属性设置为metro-dc-a的节点上，并将一个副本副本托管在一个将zone属性设置为metro-dc-b的新副本上。
请注意，您还可以使用该系统，通过为群集中的某些节点提供不出现在[cluster]放置字符串中的zone属性，来确保它们不承载新创建的数据库的任何副本。

分片管理

介绍

分片和复制

可以在全局级别或每个数据库的基础上设置每个数据库有多少个分片和副本。 相关参数是q和n。
q是要维护的数据库分片数。n是要分发的每个文档的副本数。n的默认值为3,q的默认值为8。当q= 8时，数据库分为8个分片。在n=3的情况下，群集分发每个分片的三个副本。总共，一个数据库有24个分片副本。在默认的3节点群集中，每个节点将接收8个分片。在4节点群集中，每个节点将接收6个分片。 在一般情况下，我们建议群集中的节点数应为n的倍数，以使碎片均匀分布。
CouchDB节点的etc/local.ini文件中的cluster部分：

[cluster] q=8 n=3

可以修改这些设置以设置所有数据库的分片默认值，或者可以在创建数据库时通过指定q和n查询参数来针对每个数据库进行设置。 例如：

curl -X PUT "http://localhost:5984/database-name?q=4&n=2"

Quorum

curl "$COUCH_URL:5984/<db>/<doc>?r=2"

这是写文档的类似示例：

curl -X PUT "$COUCH_URL:5984/<db>/<doc>?w=2" -d '{...}'

将r或w设置为等于n（副本数）意味着只有在所有具有相关分片的节点都响应或超时后，您才会收到响应，因此这种方法不能保证ACID的一致性。 将r或w设置为1意味着仅一个相关节点响应后，您将收到响应。

数据库分片测试

有一些API端点可以帮助您了解如何分片数据库。 首先，在集群上创建一个新数据库，然后将几个文档放入其中：

$ curl -X PUT $COUCH_URL:5984/mydb {"ok":true} $ curl -X PUT $COUCH_URL:5984/mydb/joan -d '{"loves":"cats"}' {"ok":true,"id":"joan","rev":"1-cc240d66a894a7ee7ad3160e69f9051f"} $ curl -X PUT $COUCH_URL:5984/mydb/robert -d '{"loves":"dogs"}' {"ok":true,"id":"robert","rev":"1-4032b428c7574a85bc04f1f271be446e"}

首先，/db将告诉您数据库的分片参数：

curl -s $COUCH_URL:5984/db | jq . { "db_name": "mydb", ... "cluster": { "q": 8, "n": 3, "w": 2, "r": 2 }, ... }

因此，我们知道此数据库是由8个分片(q=8)建的，每个分片具有3个副本(n=3),集群中节点之间总共有24个分片副本。
现在，让我们看一下这些分片副本如何通过/db/_shards端点放置在集群上：

curl -s $COUCH_URL:5984/mydb/_shards | jq . { "shards": { "00000000-1fffffff": [ "node1@127.0.0.1", "node2@127.0.0.1", "node4@127.0.0.1" ], "-3fffffff": [ "node1@127.0.0.1", "node2@127.0.0.1", "node3@127.0.0.1" ], ... } }

curl -s $COUCH_URL:5984/mydb/_shards/joan | jq . { "range": "e0000000-ffffffff", "nodes": [ "node1@127.0.0.1", "node3@127.0.0.1", "node4@127.0.0.1" ] } $ curl -s $COUCH_URL:5984/mydb/_shards/robert | jq . { "range": "-7fffffff", "nodes": [ "node1@127.0.0.1", "node3@127.0.0.1", "node4@127.0.0.1" ] }

CouchDB向我们展示了两个示例文档中每个映射到的特定分片。

移动一个分片

1. 确保目标节点已经加入集群
2. 将分片和任何辅助索引分片复制到目标节点上。
3. 设置目标节点为维护模式。
4. 更新集群元数据反映新的目标分片。
5. 监视内部复制以确保最新的分片。
6. 清除目标节点的维护模式。
7. 再次更新集群元数据移除原分片。
8. 移除原节点的分片和任何辅助索引分片.

拷贝分片文件

data/shards/00000000-1fffffff/abc..couch data/shards/-3fffffff/abc..couch data/shards/-5fffffff/abc..couch ...

辅助索引(包括JavaScript视图，Erlang视图和Mango索引)也被分片，并且应移动它们的分片以节省新节点重建视图的工作量。查看data/.中的分片。例如：

data/.shards data/.shards/e0000000-ffffffff/_replicator._design data/.shards/e0000000-ffffffff/_replicator._design/mrview data/.shards/e0000000-ffffffff/_replicator._design/mrview/3e823c2a4383ac0c18d4ea5b08.view ...

由于它们是文件，因此可以使用cp，rsync，scp或其他文件复制命令将它们从一个节点复制到另一个节点。 例如：

# 1主机 $ mkdir -p data/.shards/<range> $ mkdir -p data/shards/<range> # 2主机 $ scp <couch-dir>/data/.shards/<range>/<database>.<datecode>* \ <node>:<couch-dir>/data/.shards/<range>/ $ scp <couch-dir>/data/shards/<range>/<database>.<datecode>.couch \ <node>:<couch-dir>/data/shards/<range>/

先移动视图文件再移动数据库文件！ 如果视图索引在其数据库之前，则数据库将从头开始重建它。

设置目标节点为维护模式

在告诉CouchDB节点上的这些新分片之前，必须将节点置于维护模式。维护模式指示CouchDB返回404 Not Found响应在/_up端点，并确保其不参与其分片的常规交互式集群请求。使用GET/_up检查节点的运行状况的正确配置的负载均衡器将检测到此404并将该节点从循环中删除，从而阻止将请求发送到该节点。 例如，要将HAProxy配置为使用/_up端点，请使用：

http-check disable-on-404 option httpchk GET /_up

 curl -X PUT -H "Content-type: application/json" \ $COUCH_URL:5984/_node/<nodename>/_config/couchdb/maintenance_mode \ -d "\"true\""

然后，通过在该节点的单个端点上执行GET/_up来验证该节点是否处于维护模式：

curl -v $COUCH_URL/_up ... < HTTP/1.1 404 Object Not Found ... {"status":"maintenance_mode"}

最后，检查负载均衡器是否已从可用后端节点池中删除了该节点。

更新集群元数据反映新的目标分片。

curl http://localhost:5986/_dbs/{name} { "_id": "{name}", "_rev": "1-e13fb7e79af3b3107edbfa3a", "shard_suffix": [46, 49, 53, 51, 48, 50, 51, 50, 53, 50, 54], "changelog": [ ["add", "00000000-1fffffff", ""], ["add", "00000000-1fffffff", ""], ["add", "00000000-1fffffff", ""], ... ], "by_node": { "": [ "00000000-1fffffff", ... ], ... }, "by_range": { "00000000-1fffffff": [ "", "", "" ], ... } }

这是该文档的简要剖析：

• _id:数据库的名字
• _rev:元数据的当前版本
• shard_suffix:数据库创建时的时间戳，在Unix时期映射到ASCII数字的代码点后的秒。
• changelog:数据库分片的历史
• by_node:每个节点的分片列表
• by_range:每个分片由哪些节点持有。

要反映元数据中的分片移动，请执行以下三个步骤：

1. 添加合适的changelog实体。
2. 更新by_node实体。
3. 更新by_range实体。

["add", "<range>", "<node-name>"]

<range>是特定的硬范围设置。<node-name>应该与集群中GET/_membership中显示的节点的名称和地址匹配。
如果从节点移除一个分片，简单地将add替换为remove。
找到新的变更日志条目后，将需要更新by_node和by_range以反映谁在存储哪些分片。 更改日志条目中的数据和这些属性必须匹配。 否则，数据库可能会损坏。
继续我们的示例，这是上面的元数据的更新版本，该版本将分片添加到名为node4的其他节点中：

{ "_id": "{name}", "_rev": "1-e13fb7e79af3b3107edbfa3a", "shard_suffix": [46, 49, 53, 51, 48, 50, 51, 50, 53, 50, 54], "changelog": [ ["add", "00000000-1fffffff", ""], ["add", "00000000-1fffffff", ""], ["add", "00000000-1fffffff", ""], ... ["add", "00000000-1fffffff", ""] ], "by_node": { "": [ "00000000-1fffffff", ... ], ... "": [ "00000000-1fffffff" ] }, "by_range": { "00000000-1fffffff": [ "", "", "", "" ], ... } }

现在可以PUT新元数据：

curl -X PUT http://localhost:5986/_dbs/{name} -d '{...}'

强制同步分片

curl -X POST $COUCH_URL:5984/{dbname}/_sync_shards {"ok":true}

监视内部复制以确保最新的分片

完成上一步后，CouchDB将开始同步分片。可以通过监视/_node/<nodename>/_system端点(包括internal_replication_jobs指标)来观察这种情况。
一旦此指标从开始分片同步之前返回到基线，或者为0，分片副本就可以提供数据了，我们可以使节点退出维护模式。

清除目标节点的维护模式

现在，可以像在步骤2中一样，通过在维护模式配置端点上放置false,使节点开始为数据请求提供服务。
通过在该节点的单个端点上执行GET/_up来验证该节点是否不在维护模式下。最后，检查负载均衡器是否已将该节点返回到可用后端节点池中。

再次更新集群元数据移除原分片

现在，以与在步骤2中将新目标分片添加到分片图中相同的方式，从分片图中删除源分片。确保将[“ remove”，<range>，<source-shard>]条目添加到 更改日志的末尾，以及修改数据库元数据文档的by_node和by_range部分。

移除原节点的分片和任何辅助索引分片

最后，可以通过从源主机上的命令行中删除源碎片副本的文件以及任何视图碎片副本来删除源碎片副本：

rm <couch-dir>/data/shards/<range>/<dbname>.<datecode>.couch rm -r <couch-dir>/data/.shards/<range>/<dbname>.<datecode>*

恭喜你！ 您已经移动了数据库分片副本。通过以这种方式添加和删除数据库分片副本，您可以更改集群的分片布局，也称为分片映射。

指定数据库放置位置

"zone": "{zone-name}"

在集群中的每一个节点都这样做：

curl -X PUT http://localhost:5986/_nodes/<node-name> \ -d '{ \ "_id": "<node-name>", "_rev": "<rev>", "zone": "<zone-name>" }'

在每个节点的本地配置文件（local.ini）中，定义一个一致的群集范围设置，例如：

[cluster] placement = <zone-name-1>:2,<zone-name-2>:1

在此示例中，CouchDB将确保将分区的两个副本托管在区域属性设置为<zone-name-1>的节点上，并将一个副本托管在新的区域属性设置为<zone-name-2>的节点上。
这种方法非常灵活，因为您还可以在创建数据库时使用与ini文件相同的语法，通过将放置设置指定为查询参数来基于每个数据库指定区域：

curl -X PUT $COUCH_URL:5984/<dbname>?zone=<zone>

修改数据库到一个新的q值

数据库的q值只能在创建数据库时设置，不能进行实时重新分片。 相反，要重新分片数据库，必须重新生成它。 步骤如下：

1. 通过在PUT操作期间将q值指定为查询参数来创建具有所需分片设置的临时数据库。
2. 停止客户端访问数据库
3. 将主数据库复制到临时数据库。 如果主数据库正在使用中，则可能需要多次复制。
4. 删除主数据库，确保没有人在使用!
5. 使用所需的分片设置重新创建主数据库。
6. 客户端现在可以再次访问数据库。
7. 将临时数据库复制回主数据库。
8. 删除临时数据库.

集群清除

内部结构

为了在节点和二级索引之间实现内部清除信息的复制，将两个内部清除树添加到数据库文件中以跟踪历史清除。

purge_tree: UUID -> {PurgeSeq, DocId, Revs} purge_seq_tree: PurgeSeq -> {UUID, DocId, Revs}

每次对_purge API的交互式请求，都会在增加purge_seq和purge_request时创建成对的有序集合，其中purge_request是一个包含docid和修订列表的元组。 对于每个purge_request都会生成uuid。清除请求将添加到内部清除树：将元组{UUID-> {PurgeSeq，DocId，Revs}}添加到topurge_tree，atupleis {PurgeSeq-> {UUID，DocId，Revs}}添加到purge_seq_tree。

压缩清除

在数据库压缩期间，最旧的清除请求将被删除，以仅在数据库中存储purged_infos_limit个清除数目。 但是，为了使数据库与索引和其他副本保持一致，我们只能删除索引和内部复制作业已处理的清除请求。因此，有时清除树可能存储的数据超过purged_infos_limit清除数目。 如果数据库中存储的清除数量超出purged_infos_limit某个阈值，则日志中会产生警告，表明数据库的清除与索引和其他副本的同步问题。

本地清除检查点文档

具有清除的数据库索引和内部复制会创建并定期更新本地检查点清除文档：_local/purge-$type-$hash。 这些文档报告了它们最后处理的purge_seq以及最后处理的时间戳。 本地检查点清除文档的示例：

{ "_id": "_local/purge-mrview-86cacdfbaf6968d4ebbc324dd3723fe7", "type": "mrview", "purge_seq": 10, "updated_on": , "ddoc_id": "_design/foo", "signature": "5df826ae3e00966ec24b7bf6" }

内部复制

索引

每个清除请求将增加数据库的update_seq，以便还更新每个辅助索引，以便应用清除请求以维护主数据库内的一致性。

配置设置

这些设置可以在default.ini或local.ini中进行更新：

在数据库压缩期间，我们检查所有检查点清除文档。 允许客户端（索引或内部复制作业）的上一次报告的purge_seq小于当前数据库碎片的purge_seq的值(purged_infos_limit + allowed_purge_seq_lag)。如果客户端的purge_seq甚至更小，并且客户端未在index_lag_warn_seconds内设置检查点，则它会阻止清除清除树，因此我们必须对此客户端发出以下日志警告：

Purge checkpoint '_local/purge-mrview-9152d15cbcffba7693fd4’ not updated in 86400 seconds in <<"shards/00000000-1fffffff/testdb12.">>

"Invalid purge doc '<<"_design/bar">>' on database <<"shards/00000000-1fffffff/testdb12.">> with purge_seq '50'"

如果发生这种类型的日志警告，请从数据库中删除本地清除文档。