节点或磁盘故障
DataNode
节点故障处理
当三副本的卷其中一个datanode所处的机器故障导致宕机,从而使得节点上的所有的data partition处于unavailable状态时,需要及时进行迁移下线处理,防止其他节点再宕机造成某些data partition 同时缺少两副本导致不可用。
下线节点
从集群中下线某个数据节点, 该数据节点上的所有数据分片都会被异步的迁移到集群中其它可用的数据节点
curl -v "http://192.168.2.160:15010/dataNode/decommission?addr=192.168.2.161:15310"
参数说明
| 参数 | 类型 | 描述 |
|---|---|---|
| addr | string | 数据节点地址 |
响应示例
{"code":0,"msg":"success","data":"decommission data node [192.168.2.161:15310] submited!need check status later!"}
设置迁移速率
当被迁移的节点有大量的extent文件时,其中副本所在的其他节点带来大量的读IO,以及对被迁移到的节点造成大量的写IO,如果负载较高时,可以限制迁移的速率:
curl -v "http://192.168.2.160:15010/admin/setNodeInfo?autoRepairRate=2000"
参数说明
| 参数 | 类型 | 描述 |
|---|---|---|
| batchCount | uint64 | metanode 删除批量大小 |
| markDeleteRate | uint64 | datanode批量删除限速设置. 0代表未做限速设置 |
| autoRepairRate | uint64 | datanode上同时修复的extent个数 |
| deleteWorkerSleepMs | uint64 | 删除间隔时间 |
| loadFactor | uint64 | 集群超卖比,默认0,不限制 |
| maxDpCntLimit | uint64 | 每个节点上dp最大数量,默认3000, 0 代表默认值 |
响应示例
{"code":0,"msg":"success","data":"set nodeinfo params map[autoRepairRate:2000] successfully"}
查看下线迁移状态
如果需要判断下线是否完成,可以看下当前集群的data partition状态
curl -v "http://192.168.2.160:15010/dataPartition/diagnose" | python -m json.tool
响应示例
{
"code": 0,
"data": {
"BadDataPartitionIDs": [],
"BadReplicaDataPartitionIDs": [],
"CorruptDataPartitionIDs": [],
"InactiveDataNodes": [],
"LackReplicaDataPartitionIDs": []
},
"msg": "success"
}
BadDataPartitionIDs字段为空说明下线完成
磁盘故障处理
当datanode节点上发生某个磁盘故障时,可以根据具体磁盘执行该磁盘的下线迁移
同样可以根据datanode的负载情况来设置迁移速率
curl -v "http://192.168.2.160:15010/disk/decommission?addr=192.168.2.161:15310&disk=/data/udbto/replica/disk1/"
参数说明
| 参数 | 类型 | 描述 |
|---|---|---|
| addr | string | 要下线的磁盘的节点地址 |
| disk | string | 故障磁盘 |
| count | int | 每次下线个数,默认0,代表全部下线 |
响应示例
{"code":0,"msg":"success","data":""}
MetaNode
节点故障处理
当节点不可用(机器故障或者网络不同),需要执行节点的下线,防止节点上的meta partition出现多数副本不可用从而导致整个partition 出现unavailable的情况。
下线节点
从集群中下线某个元数据节点, 该节点上的所有元数据分片都会被异步的迁移到集群中其它可用的元数据节点。即需要有其他可用元数据节点来替代此节点才可以执行此操作,即使节点已经INVALID,也无法下线。因此一般副本系统建议配置4台主机,其中一台作为备用节点。如果在实际部署中只有3个元数据节点情况下,当发生元数据节点发生故障,且无法恢复时,应该另外部署一个元数据节点,并加入到集群中(使用相同的配置参数即可自动加入到集群中),然后再执行故障节点的下线操作。
curl -v "http://192.168.2.160:15010/metaNode/decommission?addr=192.168.2.161:15210"
参数说明
| 参数 | 类型 | 描述 |
|---|---|---|
| addr | string | 元数据节点地址 |
响应示例
{"code":0,"msg":"success","data":"decommissionMetaNode metaNode [192.168.2.161:15210] limit 0 has offline successfully"}
同时为了避免下线node时其被写入新数据,可以先进行设置节点状态操作
curl -v "http://192.168.2.160:15010/admin/setNodeRdOnly?addr=192.168.2.161:15210&nodeType=1&rdOnly=true"
参数说明
| 参数 | 类型 | 描述 |
|---|---|---|
| addr | string | 元数据节点地址 |
| nodeType | string | 节点类型,1:metanode, 2:datanode |
| rdOnly | bool | 是否只读 |
响应示例
{"code":0,"msg":"success","data":"[setNodeRdOnlyHandler] set node 192.168.2.161:15210 to rdOnly(true) success"}
查看状态,192.168.0.143:15210已经变成不可写
./udbto-cli metanode list
[Meta nodes]
ID ADDRESS WRITABLE STATUS
2 192.168.0.244:15210 Yes Active
3 192.168.0.121:15210 Yes Active
5 192.168.0.183:15210 Yes Active
13 192.168.0.143:15210 No Active
查看下线迁移状态
如果需要判断下线是否完成,可以看下当前当前集群的meta partition状态
curl -v "http://192.168.2.160:15010/metaPartition/diagnose" | python -m json.tool
响应示例
{
"code": 0,
"data": {
"BadMetaPartitionIDs": [],
"CorruptMetaPartitionIDs": [],
"InactiveMetaNodes": [],
"LackReplicaMetaPartitionIDs": []
},
"msg": "success"
}
BadMetaPartitionIDs字段为空说明下线完成
纠删码子系统
Access、Proxy 均为无状态节点,不涉及到数据搬迁,这里仅介绍 Clustermgr 与 BlobNode 的故障处理
Clustermgr
节点故障
集群可用,宕机的节点数不超过集群的大多数
在新的节点启用 clustermgr 服务,将新服务中的配置中加上当前节点的成员信息;
调用成员移除接口 API 移除宕机的节点;
调用成员添加接口 API 将刚启动的 Clustermgr 节点加到集群中;
等待数据自动同步即可
BlobNode
磁盘故障
调用 clusterMgr 接口设置坏盘,走坏盘修复流程,详细参考磁盘管理
curl -X POST --header 'Content-Type: application/json' -d '{"disk_id":2,"status":2}' "http://127.0.0.1:9998/disk/set"
节点故障
机器可用的情况,重启 blobnode 服务,观察能否自动恢复;
机器不可用或者服务不能自动恢复,手动下线该机器
# 列举下线节点的个磁盘(返回数据包含之前下线或修复的磁盘id)
curl "http://127.0.0.1:9998/disk/list?host=http://下线节点IP:8899&count=XX"
# 手动下线磁盘,走坏盘修复流程