Open bnamasivayam opened 5 years ago
Does this mean we're formally declaring that zoneid
needs to be a larger granularity than machineid
? I'm not aware that there was any restriction before on how one could arrange zoneid
s. I'm specifically thinking that zoneid
== disk UID might be a thing a person could do.
If we could have a machine to be part of multiple zones, then we should change the logic of machine status returning locality info. Currently it assumes a machine to be in one zone only.
zoneid
is used as a larger granularity than machined in team collection, which affects where a shard is placed. To be specific, zoneid
is viewed as a machine rack in team collection.
If we change zoneid
to anything with smaller granularity than machineid
, say disk UID, we may hurt the purpose of team collection and increase the probability of data loss when a machine fails.
Currently there is a possibility where processes in a machine can end up having different zoneId's. For example, running number of fdbservers on the same machine with different zoneId being set will lead to this scenario. This is not fatal but it can lead to some confusion as our status reports on machine assumes that all processes in the machine have same zoneId and datacenterId. There should be some form of error reporting to the user indicating the misconfiguration or may be there is a possibility of auto-correcting it.