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.kla...@aklaver.com) 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 (ronljohnso...@gmail.com > <mailto:ronljohnso...@gmail.com>) 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.kla...@aklaver.com
