Cluster Unavailability During Node Removal about m3

[angelala00]

@robskillington @cw9 @vdarulis

[vdarulis]

It's hard to tell without current/previous placement (eg. debug bundles) and graphs at the time of the issue - since a 4 node cluster can only tolerate a single node failure, another node bootstrapping or restarting at the time of delete would cause write and/or query failures.

Was the cluster created with RF=3?

[angelala00]

It's hard to tell without current/previous placement (eg. debug bundles) and graphs at the time of the issue - since a 4 node cluster can only tolerate a single node failure, another node bootstrapping or restarting at the time of delete would cause write and/or query failures.

Was the cluster created with RF=3?

Thank you very much for your response!

My cluster had 5 nodes,placement like this:
{ "placement":{ "instances":{ "hostname1":{ "id": "hostname1", "isolationGroup": "group1", "zone": "embedded", "weight": 100, "endpoint": "ip1:9000", "shards": [ { "id": 1, "state": "AVAILABLE", "sourceId": "", "cutoverNanos": "0", "cutoffNanos": "0" }, { "id": 2, "state": "AVAILABLE", "sourceId": "", "cutoverNanos": "0", "cutoffNanos": "0" }, ...... ], "shardSetId": 0, "hostname": "ip1", "port": 9000, "metadata": { "debugPort": 0 } }, "hostname2":{ "id": "hostname2", "isolationGroup": "group2", "zone": "embedded", "weight": 100, "endpoint": "ip2:9000", "shards": [ { "id": 0, "state": "AVAILABLE", "sourceId": "", "cutoverNanos": "0", "cutoffNanos": "0" }, { "id": 2, "state": "AVAILABLE", "sourceId": "", "cutoverNanos": "0", "cutoffNanos": "0" } ...... ], "shardSetId": 0, "hostname": "ip1", "port": 9000, "metadata": { "debugPort": 0 } } ...... }, "replicaFactor": 3, "numShards": 64, "isSharded": true, "cutoverTime": "0", "isMirrored": false, "maxShardSetId": 0 }, "version": 33 }

when I run this command:
curl -X DELETE http://localhost:7201/api/v1/services/m3db/placement/hostnam1

then the placement is like this:
{ "placement":{ "instances":{ "hostname1":{ "id": "hostname1", "isolationGroup": "group1", "zone": "embedded", "weight": 100, "endpoint": "ip1:9000", "shards": [ { "id": 1, "state": "LEAVING", "sourceId": "", "cutoverNanos": "0", "cutoffNanos": "0" }, { "id": 2, "state": "LEAVING", "sourceId": "", "cutoverNanos": "0", "cutoffNanos": "0" }, ...... ], "shardSetId": 0, "hostname": "ip1", "port": 9000, "metadata": { "debugPort": 0 } }, "hostname2":{ "id": "hostname2", "isolationGroup": "group2", "zone": "embedded", "weight": 100, "endpoint": "ip2:9000", "shards": [ { "id": 0, "state": "AVAILABLE", "sourceId": "", "cutoverNanos": "0", "cutoffNanos": "0" }, { "id": 1, "state": "INITIALIZING", "sourceId": "hostname1", "cutoverNanos": "0", "cutoffNanos": "0" }, { "id": 2, "state": "AVAILABLE", "sourceId": "", "cutoverNanos": "0", "cutoffNanos": "0" } ...... ], "shardSetId": 0, "hostname": "ip1", "port": 9000, "metadata": { "debugPort": 0 } } ...... }, "replicaFactor": 3, "numShards": 64, "isSharded": true, "cutoverTime": "0", "isMirrored": false, "maxShardSetId": 0 }, "version": 34 }

and then I call query interface host:7201/api/v1/query , it show error
{"status":"error","error":"unable to satisfy consistency requirements: shards=22, err=[error fetching tagged from host hostname2: Error({Type:INTERNAL_ERROR Message:index is not yet bootstrapped to read})]"}

so what more information we need?

[angelala00]

"Is this a bug? Or is it intended to be designed this way? Or did I do something wrong?"
please help!
@vdarulis

[vdarulis]

What state shard 22 is across nodes? What's the query consistency level? It might be a single shard isn't bootstrapped across all replicas. There are no known issues with this sort of configuration and node operations.
Without a full dump of configs for coordinator and dbnodes, as well as full placement status, there's not enough for anyone to go on. If you're on k8s, using m3db-operator is preferred.

[angelala00]

What state shard 22 is across nodes? What's the query consistency level? It might be a single shard isn't bootstrapped across all replicas. There are no known issues with this sort of configuration and node operations. Without a full dump of configs for coordinator and dbnodes, as well as full placement status, there's not enough for anyone to go on. If you're on k8s, using m3db-operator is preferred.

Thanks again!
Here is the config file m3dbnode.yml


I deploy the cluster with binaries and my m3db version is 0.15.14.
curl http://localhost:7201/api/v1/services/m3db/placement
the status of shard 22, all three replicas is AVAILABLE.
{ "id": 22, "state": "AVAILABLE", "sourceId": "", "cutoverNanos": "0", "cutoffNanos": "0" }
{ "id": 22, "state": "AVAILABLE", "sourceId": "", "cutoverNanos": "0", "cutoffNanos": "0" }
{ "id": 22, "state": "AVAILABLE", "sourceId": "", "cutoverNanos": "0", "cutoffNanos": "0" }
so, can we go on? @vdarulis

[vdarulis]

I don't see anything up with config, the bootstrappers/consistency level are correct for this setup.

I deploy the cluster with binaries and my m3db version is 0.15.14.

This is about 1100~ commits behind latest release - definitely try upgrading first

[angelala00]

I don't see anything up with config, the bootstrappers/consistency level are correct for this setup.

I deploy the cluster with binaries and my m3db version is 0.15.14.

This is about 1100~ commits behind latest release - definitely try upgrading first

Okay, then I'll upgrade the version and try.
Which stable version is recommended?