Managed to find following in the announcement of BDR on 9.6:
"BDR has always been an extension, but on 9.4 it required a heavily patched PostgreSQL, one that isn’t fully on-disk-format compatible with stock community PostgreSQL 9.4. The goal all along has been to allow it to run as an extension on an unmodified PostgreSQL … and now we’re there."
Source: https://www.2ndquadrant.com/en/blog/bdr-is-coming-to-postgresql-9-6/
I suppose this answers why logical dump / restore works, but pg_basebackup fails - the stock 9.4 and BDR 9.4 are not compatible on disk level.
On 25 May 2019 at 23:26:26, Adrian Klaver (adrian.klaver@xxxxxxxxxxx) wrote:
On 5/25/19 11:46 AM, Jānis Pūris wrote:
> Hi Ron,
>
> I can not reproduce this error on BDR_Node_2 (it is not BDR_Node_1 as
> stated before. Typo)
>
> I've been successful in transferring the data with pg_dump on BDR_Node_2
> and then restoring it on Regular_Node_1. Then running "select * from
> information_schema.sequences;" all is OK.
So the issue is that a binary backup/restore via pg_basebackup fails but
a logical backup/restore via pg_dump/pg_restore works, correct?
You might want to take a look here:
https://github.com/2ndQuadrant/bdr/issues/140
It might make sense to you, it does not to me. Looks to me something is
being done on the binary level that makes this difficult. I guessing you
are going to have to talk to the BDR folks.
>
> The problem with this approach is that I'm required to have minimal
> downtime in this transition and we have a lot of data to transfer, which
> would be lengthy process.
>
> Thank you in advance.
> Best regards, Janis Puris
>
> On 25 May 2019 at 19:16:11, Ron (ronljohnsonjr@xxxxxxxxx
> <mailto:ronljohnsonjr@xxxxxxxxx>) wrote:
>
>> 1. Are you sure that you removed all BDR from the node?
>> 2. Is the corruption there in BDR_Node_1?
>> 3. Can you rebuild the indexes?
--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx
