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
designed
for this option but I can provide some input on how you could perform
an experiment
on this scenario.
Using 6 DB nodes is possible but problems using it have been reported
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
Location B nodes
to 3, 5, 7. This means 2 and 3 will form a node group replicating each
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
partitioning but the site
without arbitrator will always lose when connection is broken. In this
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
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
NDB nodes doesn't
think in Locations, it considers all nodes equals and assign anyone
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
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
normal manner. A partitioned
cluster that regain communication will most likely crash. So ensure
that one side does a normal
start so that not two working cluster parts find each other, that won't
work.
Rgrds Mikael
>
> --
> Richard F. Rebel
> rrebel@stripped
> t. 212.239.0000
>
Mikael Ronström, 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
