Yes, consider using Repmgr.
> On 08-Aug-2018, at 3:20 AM, Richard Schmidt
> wrote:
>
> We think we have found our missing step. We needed to do an ordered shutdown
> of the original primary before promoting the standby
> I.e.
>
> >1. Make some changes to the A (the primary) and check that th
We think we have found our missing step. We needed to do an ordered shutdown of
the original primary before promoting the standby
I.e.
>1. Make some changes to the A (the primary) and check that they are replicated
>to the B (the standby)
Missing step:
Perform ordered shutdown of A (the pr
> On Aug 4, 2018, at 13:50, Michael Paquier wrote:
>
> Hm?
The specific situation is if pg_rewind is attached to the target before the
forced post-recovery checkpoint completes, the target can be corrupted:
https://www.postgresql.org/message-id/ece3b665-e9dd-43ff-b6a6-734e74352...@
On Sat, Aug 04, 2018 at 07:54:36AM -0700, Christophe Pettus wrote:
> Would having pg_rewind do a checkpoint on the source actually cause
> anything to break, as opposed to a delay while the checkpoint
> completes?
Users relying only on streaming without archives would be impacted as
potentially tw
> On Aug 4, 2018, at 06:13, Michael Paquier wrote:
>
> Well, since its creation we have the tool behave this way. I am not
> sure either that we can have pg_rewind create a checkpoint on the source
> node each time a rewind is done, as it may not be necessary, and it
> would enforce WAL segmen
On Sat, Aug 04, 2018 at 04:59:45AM -0700, Andres Freund wrote:
> On 2018-08-04 10:54:22 +0100, Simon Riggs wrote:
>> pg_rewind doesn't work correctly. Documenting a workaround doesn't change
>> that.
>
> Especially because most people will only understand this after they've
> been hit, as test sc
On 2018-08-04 10:54:22 +0100, Simon Riggs wrote:
> On 4 August 2018 at 07:56, Michael Paquier wrote:
> >> Sounds like we should write a pending timeline change to the control
> >> file and have pg_rewind check that instead.
> >>
> >> I'd call this a timing bug, not a doc issue.
> >
> > Well, havin
On 4 August 2018 at 07:56, Michael Paquier wrote:
> On Sat, Aug 04, 2018 at 07:44:59AM +0100, Simon Riggs wrote:
>> I think the problem is that writing the online checkpoint is deferred
>> after promotion, so this is a timing issue that probably doesn't show
>> in our regression tests.
>
> Somewha
On Sat, Aug 04, 2018 at 07:44:59AM +0100, Simon Riggs wrote:
> I think the problem is that writing the online checkpoint is deferred
> after promotion, so this is a timing issue that probably doesn't show
> in our regression tests.
Somewhat. It is a performance improvement of 9.3 to let the start
On 3 August 2018 at 21:59, Michael Paquier wrote:
> On Wed, Aug 01, 2018 at 09:09:30PM +, Richard Schmidt wrote:
>> Our procedure that runs on machine A and B is as follows:
>>
>> 1. Build new databases on A and B, and configure A as Primary and B
>> as Standby databases.
>> 2. Make so
On Wed, Aug 01, 2018 at 09:09:30PM +, Richard Schmidt wrote:
> Our procedure that runs on machine A and B is as follows:
>
> 1. Build new databases on A and B, and configure A as Primary and B
> as Standby databases.
> 2. Make some changes to the A (the primary) and check that they ar
> Now once your master A can’t become slave of B.
Isn’t that the exact situation that pg_rewind should take care of?
This email and any attachments may contain confidential information. If you are
not the intended recipient, your use or communication of the information is
strictly prohibited.
Whenever you do switch-over, postgres-wal creates a new timeline, which
simplifies managing PITR process.
During switch-over(promoting B as master) you had some delta records written to
A, that’s where it causes this timeline issue.
Now since A had some delta records, it can’t replicate from B
We have been struggling to get pr_rewind to work. In desperation we have been
trying to make the use case as simple as possible:)
We have two databases servers running Postgres 10 on two different machine in
the normal Primary/Standby configuration.
Both machines write their WAL archive logs to
14 matches
Mail list logo
