I have been researching the possibility of clustering four geographically separate
locations with MySQL and using clustering to keep them all in synch. The master will be
in Las Vegas or Chicago, with the other nodes in Los Angeles, Dallas and New York. There
is also the possibility of having a fifth node in the UK within two years.
One node would be the 'master' that our back-end processes would talk to. That data,
through clustering, would be available to the other three nodes. These other three nodes
can also modify data that must be available on the other nodes. Now, the questions.
1) As I understand it, clustering is transaction based. So, say a program attaches
to node A, begins a transaction, updates 100 records and closes the transaction. Is
control returned to the requesting program when the transaction is complete on A, or is
control returned when all nodes are updated?
2) If node B starts experiencing high communication latency with the other nodes for
a period of time, will that effect the performance of the other nodes?
3) If I choose to have one MySQL server initially, how difficult would it be to roll
that into a cluster later as the entire system matures?
I am new to MySQL clustering and distributed SQL systems, so a lot of the terminology in
the White Papers and FAQs is quite new to me.