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.
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.
> 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.
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:
> 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.
> On 2012-05-14 21:40, KTWalrus wrote:
> > 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.
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.
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
> 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:
> > 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.
> > On 2012-05-14 21:40, KTWalrus wrote:
> > > 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.
> 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.
> 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
>> 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:
>>> 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.
>>> On 2012-05-14 21:40, KTWalrus wrote:
>>>> 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.
> -- > You received this message because you are subscribed to the Google Groups "Percona Discussion" group.
> To post to this group, send email to percona-discussion@googlegroups.com.
> To unsubscribe from this group, send email to percona-discussion+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/percona-discussion?hl=en.
> 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
> On May 14, 2012, at 1:23 PM, KTWalrus <ktwal...@gmail.com> wrote:
>> 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.
>> 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
>>> 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:
>>>> 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.
>>>> On 2012-05-14 21:40, KTWalrus wrote:
>>>>> 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.
>> --
>> You received this message because you are subscribed to the Google >> Groups "Percona Discussion" group.
>> To post to this group, send email to >> percona-discussion@googlegroups.com.
>> To unsubscribe from this group, send email to >> percona-discussion+unsubscribe@googlegroups.com.
>> For more options, visit this group at >> http://groups.google.com/group/percona-discussion?hl=en.
-- Alexey Yurchenko,
Codership Oy, www.codership.com Skype: alexey.yurchenko, Phone: +358-400-516-011
> 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
> On May 14, 2012, at 1:23 PM, KTWalrus <ktwal...@gmail.com> wrote:
> > 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.
> > 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
> >> 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:
> >>> 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.
> >>> On 2012-05-14 21:40, KTWalrus wrote:
> >>>> 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.
> > --
> > You received this message because you are subscribed to the Google Groups "Percona Discussion" group.
> > To post to this group, send email to percona-discussion@googlegroups.com.
> > To unsubscribe from this group, send email to percona-discussion+unsubscribe@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/percona-discussion?hl=en.
