MySQL Forums :: NDB clusters :: configuration where 2 out of 3 physical servers can fail


Advanced Search

Re: configuration where 2 out of 3 physical servers can fail
Posted by: Ron Arts ()
Date: March 06, 2017 04:51AM

Mikael,

thanks for your detailed answer.

In my case the three VM's are located in 3 different datacenters about 10 miles apart. The chance of two failing at the same time can be assumed to be zero.

(I don't want to run circular replication because we as a supplier do not have access, and we cannot easily rely on MySQL Cluster-competent staff on site, so I want to keep the setup as simple as possible).

I'm leaning towards running with 3 replicas, since in my tests it worked well, Also shutdown will not happen at all, so the minor problem you mentioned does not bother me.

Your answer implies that if I colocate management daemons with data nodes, that if any single node fails, the cluster will go down if that happens to be the current arbitrator correct? Won't the other two management nodes negotiate a new arbitrator and thus keep the cluster up?

If not, I do have the option of running the management nodes on neighbouring-but-not-on-the-same-blade VMs. Would this alleviate the problem?

Thanks,
Ron

Options: ReplyQuote


Subject Views Written By Posted
configuration where 2 out of 3 physical servers can fail 112 Ron Arts 02/21/2017 10:36AM
Re: configuration where 2 out of 3 physical servers can fail 50 Jonathan Stephens 02/21/2017 11:10AM
Re: configuration where 2 out of 3 physical servers can fail 51 Mikael Ronström 02/21/2017 01:05PM
Re: configuration where 2 out of 3 physical servers can fail 51 Ron Arts 03/06/2017 04:51AM
Re: configuration where 2 out of 3 physical servers can fail 28 Ron Arts 03/07/2017 04:05AM
Re: configuration where 2 out of 3 physical servers can fail 37 Mikael Ronström 03/08/2017 02:26AM


Sorry, only registered users may post in this forum.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.