| Thanks, Simon, for your continued feedback. Simon Riggs wrote on 11/24/2021 12:49 PM: Let me try to state it another way... Without a central place where you can see all the SQL coming against all of the read-write PG nodes at the same time, you cannot avoid conflicts. PG is active/passive so it cannot resolve conflicts across multiple primary PG clusters. Hence, BDR offers an "underneath the covers" approach to deal with conflicts when they do arise, but innevitably a conflict causes a previous commit to be rolled back or "suspended" for some kind of manual intervention later. That is why BDR nowhere states that BDR is ACID-compliant. If it were ACID-compliant, there would be no external need to address SQL conflicts.On Wed, 24 Nov 2021 at 17:38, MichaelDBA <MichaelDBA@xxxxxxxxxxx> wrote:Oh really? BDR is acid-compliant? How can it be without a global lock manager to control access to resources and a consistent view of data and enforce isolation levels?Many types of distributed system offer consistency. Very few use a global lock manager, so this is not a requirement. I spent about 15 minutes starting at the URL stated above to drill down into some areas where this subject might be addressed and I couldn't find it. Perhaps you could be more specific.Please explain the magic.Anyone interested to know more can start here: https://www.enterprisedb.com/products/bidirectional-replication-bdr-postgresql-database I did find this in separate BDR documentation: "BDR is a loosely coupled shared-nothing multi-master design." I guess you can say "loosely coupled" is a nice way to say not ACID-compliant. |
