From: Mikael Ronström
Date: August 25 2004 8:51pm
Subject: Re: MySQL cluster and remote datacenters
List-Archive: http://lists.mysql.com/cluster/474
Message-Id: <82A79D1A-F6D8-11D8-A23C-000A959312A2@mysql.com>
MIME-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi Richard,

2004-08-25 kl. 16.17 skrev Richard F. Rebel:

>
> Hello,
>
> I have been considering a replacement for our mysql databases that
> receive queries from live internet apps.  mysql replication has
> demonstrated itself to be much too fragile to maintain, especially
> across datacenters (private T3 link between).
>
> My question is, is it possible to configure mysql cluster with say a
> configuration like this?
>
> Location A                 <-T3->              Location B
> 2 MySQL API Nodes                              2 MySQL API Nodes
> 3 Storage Nodes (one also master)              3 Storage Nodes (...)
>
> Is it possible to configure the system without using mysql replication
> and partition the data where each location can run successfully if the
> other location is unavailable or gets blown up etc.
>
> Eg, T3 goes down, or Location A is unavailable.  What happens when
> Location A comes back online?  Will the data be resync'd?
>
> I am guessing this is not possible, that I would have to continue
> running mysql replication between the two datacenters and run them as
> two discreet clusters.  I would love it if someone would smack me down
> and tell me I am oh so wrong. :)
>

Smack, you are oh so wrong :)

Actually a case like this have never been tried. MySQL Cluster is not=20
designed
for this option but I can provide some input on how you could perform=20
an experiment
on this scenario.

Using 6 DB nodes is possible but problems using it have been reported=20
so it safer to
try with 4 or 8 nodes.

1) Use 2 replicas. Assign Location A DB nodes id 2,4 and 6 and the=20
Location B nodes
to 3, 5, 7. This means 2 and 3 will form a node group replicating each=20=

other and
4 and 5 one group and 6 and 7 a third group.

2) Assign NO arbitrator. If you assign an arbitrator you will avoid=20
partitioning but the site
without arbitrator will always lose when connection is broken. In this=20=

manner you can get
a partitioned system but you can also survive failures of the link.

For this to work the T3 link must be very reliable and not be going up=20=

and down since that
will be treated as node failures by other nodes.

Other things to consider is that query execution might suffer since the=20=

NDB nodes doesn't
think in Locations, it considers all nodes equals and assign anyone=20
with the resources
to handle the task appropriate to handle it.

Since partitioning can happen you need a way to handle it. There are no=20=

rules for this, you
have to look at the application and decide from there.

If Location A was actually down and then restarts it will resynch the=20
normal manner. A partitioned
cluster that regain communication will most likely crash. So ensure=20
that one side does a normal
start so that not two working cluster parts find each other, that won't=20=

work.

Rgrds Mikael

>
> --=20
> Richard F. Rebel
> rrebel@stripped
> t. 212.239.0000
>
Mikael Ronstr=F6m, Senior Software Architect
MySQL AB, www.mysql.com

Clustering:
http://www.infoworld.com/article/04/04/14/HNmysqlcluster_1.html

http://www.eweek.com/article2/0,1759,1567546,00.asp