Ideally the ZK data and ZK transaction log files should be on different disks, so that they don't contend for the IO resource. ZK Data and Log files should be on disks, which have least contention from other I/O activities. Because ZK recovery is hampered in this case, it defeats the purpose of high availability. This can work if all ZK servers are healthy, but if one goes down it can be difficult for the client to find a replacement.
This is because the coordinator and overlord are normally far less work intensive than data or query nodes Imply prefers to colocate ZK on master nodes rather than data or query nodes. Two ZK's doubles the probability of failure and therefore is actually less preferable than 1 ZK. In a cluster with 2 ZK's, only 1 is needed to maintain a "quorum", so it does not provide high availability. For example, with 3 ZK's, 1 ZK can be lost and the cluster can still function because 2 are left, which = ceil(3/2).Voting decisions include IP discovery, determining which overlord or coordinator is the leader, etc. For increased reliability (high availability), use 3 or 5 ZK's so that it can maintain a quorum in voting decisions (ceiling(n/2)).
0 kommentar(er)
