Multi-master-replikering (BDR)

Traditionell PostgreSQL-replikering omfattar en primärserver (master) och en eller flera standbyservrar (replikor). Skrivningar sker endast på primärservern, medan läsningar kan flyttas till replikorna.

Multi-master-replikering (MMR) fungerar annorlunda. Den gör det möjligt att skriva till flera databasservrar samtidigt, samtidigt som alla ändringar synkroniseras i klustret.

MMR har betydande fördelar jämfört med traditionella konfigurationer med en enda master:

• Hög tillgänglighet: Om en masternod slutar fungera kan andra fortsätta ta emot skrivningar, vilket säkerställer kontinuerlig drift.
• Skalbarhet för skrivningar: Fördela skrivoperationer över flera noder, vilket kan förbättra prestandan för skrivintensiva applikationer.
• Geografisk distribution: Placera aktiva databasnoder närmare användare i olika regioner och minska därmed fördröjningen för lokala operationer.

Den största utmaningen med multi-master-replikering är att hantera datakonflikter.

En konflikt uppstår när samma datadel (till exempel en specifik rad) ändras oberoende på två olika masternoder innan ändringarna har replikerats till den andra noden. Till exempel:

• Användare A uppdaterar en rad på Nod 1.
• Användare B uppdaterar samma rad på Nod 2.

Vilken ändring ska slutligen gälla?

BDR står för Bi-Directional Replication. Det är ett tillägg med öppen källkod för PostgreSQL som utvecklats för att möjliggöra äkta multi-master-replikering.

BDR gör det möjligt för flera PostgreSQL-instanser att ta emot skrivningar samtidigt och samtidigt hålla sina data synkroniserade. Det bygger vidare på PostgreSQL:s inbyggda funktioner för logisk replikering men lägger till viktiga funktioner för konflikthantering.

I ett BDR-kluster fungerar varje deltagande nod både som utgivare och prenumerant:

• När en ändring (INSERT, UPDATE, DELETE) sker på Nod A publicerar den ändringen.
• Nod B (och alla andra noder) tar emot ändringen som prenumerant och tillämpar den i sin lokala databas.
• Samma process sker i motsatt riktning: Nod B publicerar sina ändringar och Nod A prenumererar på dem.

Denna peer-to-peer-kommunikation håller alla noder synkroniserade.

BDR använder robusta mekanismer för att upptäcka när konflikter uppstår:

• Ändringar spåras med hjälp av en kombination av radidentifierare och versionsnummer.
• När en replikerad ändring anländer från en annan nod kontrollerar BDR om den lokala raden har ändrats oberoende sedan det senaste gemensamma tillståndet.

Vanliga konflikttyper är UPDATE mot UPDATE, UPDATE mot DELETE och INSERT mot INSERT (för unika nycklar).

När en konflikt har upptäckts använder BDR en konfigurerbar lösningsstrategi för att avgöra vilken dataversion som ska gälla:

• Last-Updater-Wins (LUW): Ändringen med den senaste tidsstämpeln för commit tillämpas och skriver över äldre motstridiga ändringar.
• First-Updater-Wins (FUW): Den först committade ändringen gäller och efterföljande motstridiga uppdateringar förkastas.
• Anpassade konflikthanterare: Utvecklare kan definiera sin egen logik med SQL-funktioner för att lösa konflikter utifrån specifika affärsregler.

Att konfigurera ett BDR-kluster omfattar flera viktiga steg på varje deltagande PostgreSQL-instans:

• Installera BDR-tillägget.
• Konfigurera postgresql.conf för logisk replikering och BDR-specifika inställningar.
• Initiera BDR-klustret och lägg till varje nod som peer.
• Skapa publikationer för de tabeller eller scheman som Ni vill replikera.
• Skapa prenumerationer på andra noder för att ta emot ändringar från publikationerna.

Detta säkerställer att alla noder känner till varandra och kan utbyta data.

BDR passar utmärkt i scenarier som kräver aktiva databaser på båda sidor och hög tillgänglighet för skrivningar:

• Geografiskt distribuerade applikationer: Ge lokal åtkomst för skrivningar med global datakonsistens.
• Kluster med hög tillgänglighet: Minimera driftstopp vid fel på enskilda noder genom att låta skrivningar fortsätta på andra noder.
• Katastrofåterställning: Implementera robusta planer för katastrofåterställning med flera aktiva platser.

Det används ofta i komplexa, verksamhetskritiska miljöer där driftstopp och dataförlust inte kan accepteras.

BDR är kraftfullt men medför operativ komplexitet:

• Konflikthantering: Kräver noggrann planering av lösningsstrategier för att undvika oväntade dataresultat.
• Övervakning: Ni behöver aktivt övervaka replikeringsfördröjning, konfliktfrekvens och nodernas hälsa.
• Schemaändringar: Kräver samordnade DDL-ändringar (Data Definition Language) på alla noder för att upprätthålla konsistensen.

BDR är ingen lösning som kan installeras utan vidare och kräver en djupare förståelse av dess arkitektur och beteende.

Multi-master-replikering gör det möjligt att skriva till flera databasnoder och förbättrar därmed tillgängligheten och skalbarheten för skrivningar avsevärt jämfört med konfigurationer med en enda master.

Det största hindret i MMR är att lösa datakonflikter, som uppstår när samma data ändras oberoende på olika noder.

PostgreSQL:s BDR (Bi-Directional Replication)-tillägg erbjuder robusta multi-master-funktioner, inklusive avancerad konfliktdetektering och anpassningsbara lösningsstrategier som Last-Updater-Wins.

BDR är kraftfullt för hög tillgänglighet och distribuerade system, men kräver noggrann utformning, övervakning och hantering på grund av sin inneboende komplexitet.