On Fri, Feb 7, 2014 at 03:57:31PM +1100, James Sewell wrote:
> I've just noticed that on PostgreSQL 9.3 I can do the following with a master
> node A and a slave node B (as long as I have set recovery_target_timeline =
> 'latest'):
>
> 1. Stop Node A
> 2. Promote Node B
> 3. Attach Node A as s
Michael Paquier wrote:
> On Fri, Feb 7, 2014 at 3:02 PM, James Sewell
> wrote:
>
>> Node A could get ahead even if it has been shut down cleanly BEFORE the
>> promotion?
>> I'd always assumed if I shut down the master the slave would be at the same
>> point after shutdown
>> - is this incorrec
On Fri, Feb 7, 2014 at 3:02 PM, James Sewell wrote:
> Node A could get ahead even if it has been shut down cleanly BEFORE the
> promotion?
> I'd always assumed if I shut down the master the slave would be at the
> same point after shutdown - is this incorrect?
>
Yes and no. A node will wait at shu
Node A could get ahead even if it has been shut down cleanly BEFORE the
promotion?
I'd always assumed if I shut down the master the slave would be at the same
point after shutdown - is this incorrect?
Cheers,
James Sewell,
PostgreSQL Team Lead / Solutions Architect
_
On Fri, Feb 7, 2014 at 1:57 PM, James Sewell wrote:
> I've just noticed that on PostgreSQL 9.3 I can do the following with a
> master node A and a slave node B (as long as I have set
> recovery_target_timeline = 'latest'):
>
>1. Stop Node A
>2. Promote Node B
>3. Attach Node A as slave
I've just noticed that on PostgreSQL 9.3 I can do the following with a
master node A and a slave node B (as long as I have set
recovery_target_timeline = 'latest'):
1. Stop Node A
2. Promote Node B
3. Attach Node A as slave
This is sufficient for my needs (I know it doesn't cover a crash
On Wed, Feb 5, 2014 at 3:14 PM, Amit Kapila wrote:
> On Wed, Feb 5, 2014 at 10:30 AM, James Sewell
>> I've seen some proposals and a tool (pg_rewind), but all seem to have draw
>> backs.
>
> As far as I remember, one of the main drawbacks for pg_rewind was related to
> hint bits which can be avoi
On Wed, Feb 5, 2014 at 10:30 AM, James Sewell
wrote:
>
> Hello All,
>
> I have been reading through some of the recent discussions about failback
when in a streaming replication setup. I define failback as:
>
> Node A is master, Node B is slave
> Node A crashes || Node A is stopped || nothing happ
Hello All,
I have been reading through some of the recent discussions about failback
when in a streaming replication setup. I define failback as:
1. Node A is master, Node B is slave
2. Node A crashes || Node A is stopped || nothing happens
3. Promote Node B to Master
4. Attach Node
