Geographic Clusters connected by Gateway Nodes

206 views
Skip to first unread message

KTWalrus

unread,
May 14, 2012, 2:40:50 PM5/14/12
to Percona Discussion
I'm considering upgrading to Percona Cluster. I will have 4 MySQL
nodes in my local cluster. When performance dictates that I need
another node in the cluster, I'd like to colocate a new 4 node cluster
in another DC (probably on the opposite coast from my first cluster).
When I need yet more clusters, I want to locate it in another DC.

I'm a bit worried that connecting my 4 node clusters to make 1 big
Percona Cluster is going to kill performance. As I understand it,
Percona Clusters are only as fast to execute an update query as the
slowest RTT between all nodes in the cluster. The WAN links will
naturally have the slowest RTT since they are geographically
distributed (potentially crossing the entire continent).

So, I'm wonder if Percona Cluster has or plans to have any enhancement
to not make replicating changes between LAN clusters over WAN?

If not, I suggest that 1 node in a cluster is the Gateway node for the
cluster (accepting WAN to LAN and forwarding LAN to WAN updates).
I'd think the current Master for the LAN cluster should automatically
be the Gateway.

Now, the updates within the LAN cluster should be virtually
synchronous but asynchronous between Gateways over the WAN. Of
couse, asynchronous updates should flow in both directions and be
initiated as soon as the update is committed to the sending Gateway's
node.

The point is to not allow the replication time between clusters to
affect a local cluster update time, but still keep the entire
Geographic Cluster fairly in sync. Also, this should save WAN
bandwidth since the update only travels to and from Gateway nodes and
not all nodes in the Geographic Cluster.

Alex Yurchenko

unread,
May 14, 2012, 3:35:09 PM5/14/12
to percona-d...@googlegroups.com
Why don't you just use the regular asynchronous MySQL replication for
that? Any cluster node can serve as a "gateway", so provided you have
enough nodes you can theoretically have dedicated gateways for each
remote DC.

The thing is it won't be a Cluster anymore, as each DC will have its
own GTID, so it will be a group of loosely coupled clusters.

KTWalrus

unread,
May 14, 2012, 4:10:50 PM5/14/12
to Percona Discussion
I thought MySQL replication is one-way? So, I would have to designate
two Gateway nodes in my 4 node cluster. One would server for inbound
updates and the other would serve for outbound updates. And, for 3 or
more clusters, I would need to setup a Gateway ring of replication.

Percona Cluster uses a star network for replication and nodes handle
both inbound and outbound updates. I think it would be simpler if
Percona Cluster supported Geographic Clusters as I described. The
Geographic Cluster could automatically handle failouts of clusters (as
it does for LAN nodes) and auto-increments WAN wide instead of just
LAN wide. The Geographic Cluster would look just like a mega cluster
with WAN links using optimized asynchronous replication and LAN links
using virtually synchronous replication. Otherwise, the entire
cluster would look like one big efficient cluster.

Really, the main feature that attracts me to Percona Cluster is the
easy of setup and maintenance (handling failouts and joins) and the
virtually synchronous feature is of lower priority to me. A Percona
Geographic Cluster that works just like a LAN Cluster, except that
multiple Clusters may be semi-asynchronously connected for WAN
updates, would be a fantastic option.

On May 14, 3:35 pm, Alex Yurchenko <alexey.yurche...@codership.com>
wrote:

KTWalrus

unread,
May 14, 2012, 4:23:06 PM5/14/12
to Percona Discussion
BTW, the updates between Gateway nodes could be virtually synchronous
too, except that instead of an error back to the originator on failed
commit, the originating Gateway node could log the failed update to an
internal MySQL table so it could be manually examined, fixed, and re-
applied (if desired). The update wouldn't be virtually synchronous
with the originating transaction since that would be committed to the
LAN Cluster before the Gateway node would initiate WAN replication.
But, individual clusters connected to the Gateway node would either be
all updated or none.

Also, I want to avoid using Oracle MySQL replication for anything
since I believe that if Oracle adds good star network replication,
they will not Open Source it (but keep it as a premium addon).
Percona Cluster looks like one project that is committed to Open
Source and I would like to choose it over any premium addon from
Oracle.

Justin Swanhart

unread,
May 14, 2012, 5:08:39 PM5/14/12
to percona-d...@googlegroups.com, Percona Discussion
Have you investigated tungsten replicator from Continuent? It is open source and may meet your wan needs with or without xtradb cluster.

Sent from my iPhone
> --
> You received this message because you are subscribed to the Google Groups "Percona Discussion" group.
> To post to this group, send email to percona-d...@googlegroups.com.
> To unsubscribe from this group, send email to percona-discuss...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/percona-discussion?hl=en.
>

Alex Yurchenko

unread,
May 14, 2012, 6:14:54 PM5/14/12
to percona-d...@googlegroups.com
Speaking of Tungsten, here's a good summary of the problems you're
going to face with asynchronous multi-master:
http://scale-out-blog.blogspot.com/2012/04/if-you-must-deploy-multi-master.html
. Paragraphs 4 to 6.
--
Alexey Yurchenko,
Codership Oy, www.codership.com
Skype: alexey.yurchenko, Phone: +358-400-516-011

KTWalrus

unread,
May 14, 2012, 8:13:53 PM5/14/12
to Percona Discussion
> Have you investigated tungsten replicator from Continuent?  It is open source and may meet your wan needs with or without xtradb cluster.

No. I'll check it out, but I won't need Geographically distributed
cluster for a very long time. I am leaning towards scaling locally
from 1 node currently to 4 nodes locally by the end of this year.
Therefore, I am strongly thinking of using Percona Cluster when we
scale to multiple dbs.

Hopefully, we will keep growing and eventually outgrow 4 nodes and
that is when we plan to use an East Coast DC and a West Coast DC, each
with 4 nodes. In reality, we plan to only use 2 nodes in a DC for
internet users, 1 node for Master updates (that run mostly at night),
and 1 node for backup (incremental remote backups done from this node
every 3 hours).

I'd rather end up with 8 DCs each with 4 nodes than a single DC with
32 nodes. I really want to only colocate 1 rack in each DC, but build
an architecture to scale from the very beginning. Therefore, I'm
hoping that Percona Cluster commits to evolving over time to an
architecture that can eventually scale to many DCs with multiple nodes
in each DC, even if I need to deal with the possibility that WAN
replication is asynchronous while LAN replication is synchronous.

On May 14, 5:08 pm, Justin Swanhart <greenl...@gmail.com> wrote:
> Have you investigated tungsten replicator from Continuent?  It is open source and may meet your wan needs with or without xtradb cluster.
>
> Sent from my iPhone
>
Reply all
Reply to author
Forward
0 new messages