Re: Horizontal scalability/sharding

From: "David E(dot) Wheeler" <david(at)justatheory(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Horizontal scalability/sharding
Date: 2015-09-01 22:07:41
Message-ID: 2A4846BD-D2BE-46A1-AB25-B5274190A102@justatheory.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sep 1, 2015, at 1:47 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> Admittedly, there are some problems with snapshots here: if you don't
> do anything special about snapshots, then what you have here will be
> "eventually consistent" behavior. But that might be suitable for some
> environments, such as very loosely coupled system where not all nodes
> are connected all the time.

Given that we’re discussing multi-node architectures here, you should expect that not all nodes will be connected at any time. Nodes fail, but the cluster should not.

> And, for those environments where you do
> need consistent snapshots, we can imagine ways to get that behavior,
> like having the GTM consider the transaction uncommitted until it's
> been logically replicated to every node.

Again, you need a way to deal with nodes going down. I can envision building a cluster with twelve nodes replicated to each of three geographically-distributed data centers. Each replication/sync model needs to be able to handle nodes going up and down, data centers or racks going up or down, and nodes being added and removed.

But even with smaller clusters, there’s no way around the fact that no system can guarantee that all nodes will be available at all times.

Best,

David

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2015-09-01 22:09:09 Re: Horizontal scalability/sharding
Previous Message Greg Stark 2015-09-01 21:58:18 Re: Unicode mapping scripts cleanup