Jeff Davis wrote:
Which doesn't work very well in the case of two groups of servers set up
in two physical locations. I can see two possibilities:
(1) You require a quorum to be effective, in which case your cluster of
databases is only as reliable as the location which holds more servers.
(2) You have another central authority that determines which databases
are up, and which are down. Then your cluster is only as reliable as
that central authority.

Right, the ideal here would be two sync clusters a both locations, connected via async replication :-)

Even if you have a large number of nodes at different locations, then
you end up with strange decisions to make if the network connections are
intermittent or very slow. A temporary slowdown of many nodes could
cause them to be degraded until some kind of human intervention brought
them back. Until that time you might not be able to determine which
nodes make up an authoritative group.

Side note: in such a case, I think a GCS will just choose only one node to be the 'authoritative group'. Because most systems cannot effort to have long waits for such decisions. For database replication I also think its better to have at least one node running than none.

> This kind of degradation could
happen in the case of a DDoS attack, or perhaps a worm moving around the

Well, sync replication in general needs a good, low latency and secure interconnect. The internet does not seem to be a good fit here.

In practice everyone can find a solution that works for them. However,
synchronous replication is not perfect, and there are many failure
scenarios which need to be resolved in a way that fits your business. I
think synchronous replication is inherently less available than

This surely depends on the environment. With a dedicated (i.e. low latency and secure) interconnect sync replication is surely more available because your arguments above don't apply. And because sync replication guarantees you won't loose committed transactions.

If however you want or have to replicate over the internet it depends. Your arguments above also apply to async replication. Only that because of the conflict resolution, async replication systems can continue to operate on all the disconnected nodes and merge their work later on as the network is up again. But then again, async still has the danger of loosing transactions.

So I probably agree: if you are on an unreliable network and if you have conflict resolution correctly setup then async replication is more available, but less secure.

As I said above, sync replication needs a reliable interconnect, better even have two interconnects, because it's a SPOF for a clustered database system.



---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?


Reply via email to