From: | Chris Winslett <chris(at)compose(dot)io> |
---|---|
To: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Asynchronous replication in postgresql |
Date: | 2015-04-08 00:46:21 |
Message-ID: | CALfAUrhNk=wSfi=cewcAhrYeeKDn9-81BzWKPHAM8cVoyDVbDQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
I've recently open sourced this template for managing state for PostgreSQL:
https://github.com/compose/governor
Take a test drive around it. As long as the old Leader is verifiably dead
or stopped at the forked WAL log point, I've not had issues with inserting
a `recovery.conf` to tail the new Leader.
On Tue, Apr 7, 2015 at 5:16 PM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> wrote:
> On 3/11/15 5:27 AM, Deole, Pushkar (Pushkar) wrote:
>
>> Hi,
>>
>> I am new to postgresql and evaluating the streaming replication for my
>> use case. My use case is:
>>
>> 1.Need to replicate data from primary database (master) to secondary
>> database (slave) asynchronously.
>>
>> 2.If master goes down, the slave should automatically be promoted to
>> master.
>>
>> 3.Later, when the original primary server (original master) is brought
>> up again, it should obtain back its master role and the new master
>> should assume the slave again as it was with original setup.
>>
>> For #1, the streaming replication of postgresql is good enough.
>>
>> For #2, we need to create the trigger file. How can we do this
>> automatically?
>>
>
> You'll need to use something else to figure out that the master node died.
> But that's not the big problem... the big problem is you need to be careful
> to ensure you don't get into a 'split brain' state.
>
> Say you promoted the slave, so now it's responding to all queries. Now the
> master suddenly starts. Not only is the master missing data that's been
> written to the slave, but if you have a load balancer now *both* databases
> are acting as if they're the master.
>
> That's bad. :)
>
> Typically, you want some way to "Shoot The Other Node In The Head" before
> you promote the slave. For example, you could modify the configuration of
> something in your network so it's no longer possible to reach the old
> master.
>
> For #3, this seems to be quite complicated. Is this even possible using
>> streaming replication? If yes, how can this be achieved?
>>
>
> You basically need to replace the master with a new replica built off the
> new master. There's been some recent work to make this easier/faster to do,
> but it's not terribly trivial, and you have to be careful to do it
> correctly.
> --
> Jim Nasby, Data Architect, Blue Treble Consulting
> Data in Trouble? Get it in Treble! http://BlueTreble.com
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tim Uckun | 2015-04-08 02:49:37 | Re: Benchmarking partitioning triggers and rules |
Previous Message | Jim Nasby | 2015-04-08 00:41:56 | Re: Working with Array of Composite Type |