Re: Merge a sharded master into a single read-only slave

From: Sébastien Lorion <sl(at)thestrangefactory(dot)com>
To: Francisco Olarte <folarte(at)peoplecall(dot)com>
Cc: Keith Fiske <keith(at)omniti(dot)com>, PostgreSQL <pgsql-general(at)postgresql(dot)org>
Subject: Re: Merge a sharded master into a single read-only slave
Date: 2014-06-05 18:09:50
Message-ID: CAGa5y0PQ+XB0isN6_ni93QXNBsZq7YR8k39gBR-e1UAfsEvqmg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, Jun 5, 2014 at 12:55 PM, Francisco Olarte <folarte(at)peoplecall(dot)com>
wrote:

> Hi Sébastien:
>
> On Thu, Jun 5, 2014 at 5:41 PM, Sébastien Lorion
> <sl(at)thestrangefactory(dot)com> wrote:
>
> > .... Correct me if I am wrong, but will it not also suffer the same
> > limitation as any statement based replication, namely that the "merged"
> > slave will have to sustain the same write load as all shards combined ?
>
> I cannot tell you the exact mimeo behaviour, but if you incremental
> replication using an id/timestamp by >pulling< changes from the
> masters, you will normally batch them and insert all the changes to
> the slaves in a single transaction, which leads to less load as many
> times your limit is in transaction rate, not record rate. (i.e., every
> 5 minutes you query for all the tuples changed, and insert/update them
> all in one go ) ( Also, if tuples are updated many times between
> sweeps the slave will get only one )
>
> Francisco Olarte.
>

​You are right, requesting changes at fixed time intervals would certainly
help reduce the load. I will have to test and see if a good balance can be
achieved between not having stale data for too long and keeping up with
writes.

Sébastien

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message David G Johnston 2014-06-05 18:28:13 Re: help with a procedure
Previous Message Magnus Hagander 2014-06-05 17:33:38 Re: Heartbleed Impact