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
On May 14, 4:10 pm, KTWalrus <ktwal...@gmail.com> wrote:
> 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
> Really, the main feature that attracts me to Percona Cluster is the
> On May 14, 3:35 pm, Alex Yurchenko <alexey.yurche...@codership.com>
> > Why don't you just use the regular asynchronous MySQL replication for
> > The thing is it won't be a Cluster anymore, as each DC will have its
> > On 2012-05-14 21:40, KTWalrus wrote:
> > > I'm considering upgrading to Percona Cluster. I will have 4 MySQL
> > > I'm a bit worried that connecting my 4 node clusters to make 1 big
> > > So, I'm wonder if Percona Cluster has or plans to have any
> > > If not, I suggest that 1 node in a cluster is the Gateway node for
> > > Now, the updates within the LAN cluster should be virtually
> > > The point is to not allow the replication time between clusters to
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.