Thanks, Simon, for your continued feedback.
Simon Riggs wrote on 11/24/2021 12:49 PM:On Wed, 24 Nov 2021 at 17:38, MichaelDBA <MichaelDBA@sqlexec.com> 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.
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.
Please explain the magic.
Anyone interested to know more can start here:
https://www.enterprisedb.com/products/bidirectional-replication-bdr-postgresql-database
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.
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.