Datareplicatie (data replication)

Wat is datareplicatie?

Datareplicatie betekent dezelfde data op meer dan één plek houden en ervoor zorgen dat de kopieën gelijk blijven lopen terwijl het origineel verandert. Wordt er een record naar het hoofdsysteem geschreven, dan gaat die wijziging door naar één of meer kopieën, zodat die dezelfde informatie bevatten. Het is geen eenmalige export. Een gerepliceerde kopie volgt zijn bron continu, dus ze blijft actueel in plaats van te verouderen zodra ze gemaakt is.

Mensen grijpen naar replicatie voor drie verschillende noden, en het helpt om die uit elkaar te houden, want ze trekken elk een andere kant op. De eerste is beschikbaar blijven: valt de hoofddatabase uit, dan neemt een kopie over. De tweede is snelheid voor een verspreid publiek: een kopie in een andere regio antwoordt lokale gebruikers sneller dan één database aan de andere kant van de wereld. De derde is leesverkeer opvangen: stuur rapporten en opzoekingen naar de kopieën, zodat het hoofdsysteem vrij blijft voor het schrijven.

Synchroon tegenover asynchroon

De grootste keuze in replicatie is wanneer de bron een schrijfactie als afgerond beschouwt, en het komt neer op twee opties.

Bij synchrone replicatie wacht het hoofdsysteem. Een schrijfactie wordt pas bevestigd aan de applicatie zodra minstens één kopie bevestigd heeft dat ze de wijziging ook opgeslagen heeft. Er gaat niks verloren als het hoofdsysteem een seconde later uitvalt, want de kopie heeft de wijziging al. De prijs is snelheid: elke schrijfactie wacht nu op een heen-en-terug naar de kopie, dus die moet dichtbij zitten op het netwerk om dit werkbaar te houden.

Bij asynchrone replicatie wacht het hoofdsysteem niet. Het bevestigt de schrijfactie meteen en stuurt de wijziging net erna naar de kopieën. Zo blijft schrijven snel en mogen de kopieën ver weg staan, zelfs duizenden kilometers, zonder lokale gebruikers te vertragen. De keerzijde is een risicovenster: valt het hoofdsysteem uit voor een recente wijziging de kopie bereikt, dan is die wijziging weg. De grootte van dat venster is de replicatie-lag.

Die afweging valt recht op de hersteldoelen uit disaster recovery. RPO, de recovery point objective, is hoeveel recente data je je kan veroorloven te verliezen. Synchrone replicatie geeft een RPO van nul, want de kopie loopt altijd bij. Asynchrone replicatie geeft een RPO gelijk aan de lag op het moment van de uitval, van een fractie van een seconde tot minuten, afhankelijk van afstand en belasting.

Wie mag schrijven: master-replica en verder

De andere ontwerpvraag is welke kopieën schrijfacties mogen aanvaarden.

De gewone opzet is single-leader, ook master-replica of primary-replica genoemd. Eén systeem, de leader, neemt alle schrijfacties. De andere zijn followers die de wijzigingen van de leader ontvangen en enkel lezen bedienen. Dat is makkelijk te overzien, want er is één gezaghebbende kopie en geen discussie over wat de huidige waarde is. Een read replica, de standaardoptie bij beheerde databases, is precies dat: een follower waar je leesvragen naartoe stuurt zodat de leader gespaard blijft.

Het alternatief is meer dan één kopie laten schrijven, ofwel meerdere leaders, ofwel een leaderless ontwerp waar elke kopie een schrijfactie aanneemt. Dat haalt de ene schrijf-flessenhals weg en overleeft de uitval van een schrijfknooppunt, maar het brengt conflicten mee: twee kopieën kunnen hetzelfde record op hetzelfde moment wijzigen, en dan heeft het systeem een regel nodig om te beslissen wie wint. Net die extra complexiteit is waarom de meeste teams bij single-leader blijven tot ze een concrete reden hebben om het niet te doen.

Waar je replicatie tegenkomt

• Hoge beschikbaarheid. Een standby-kopie staat klaar zodat de dienst doorloopt met weinig of geen onderbreking als de primary uitvalt.

• Disaster recovery. Een kopie in een aparte regio overleeft een datacenter-storing of een regionaal probleem dat de primary volledig plat legt.

• Leesverkeer opvangen. Rapportagevragen, dashboards en zoekopdrachten draaien op read replicas, zodat de primary de transacties kan afhandelen.

• Een warehouse voeden. Operationele data repliceren naar een data warehouse houdt de analyses actueel zonder de productiedatabase te belasten. Change Data Capture is een lichte vorm hiervan: het stuurt elke insert, update en delete door zodra ze gebeurt, in plaats van hele tabellen te kopiëren.

Waar moet je op letten bij datareplicatie

Replicatie-lag geeft verouderde reads. Bij asynchrone replicatie loopt een follower altijd een tikje achter. Wie een wijziging schrijft en meteen daarna van een replica leest, kan de oude waarde zien en denken dat het opslaan mislukt is. Moet een proces zijn eigen schrijfacties meteen terugzien, stuur die reads dan naar de leader.

Replicatie is geen back-up. Een foute delete of een bug die data beschadigt, wordt binnen seconden trouw naar elke replica gekopieerd. Replicatie beschermt tegen een machine die stukgaat, niet tegen een fout in de data zelf. Je hebt nog altijd echte back-ups nodig die je vanaf een tijdstip kan terugzetten.

Failover is een beslissing, geen reflex. Een replica tot leader promoveren terwijl de oude leader niet echt uitgevallen is, kan twee systemen achterlaten die allebei schrijven, en dat beschadigt je data. Failover juist krijgen, en het testen, is lastiger dan replicatie aanzetten.

Kopieën kosten geld en aandacht. Elke replica is opslag, rekenkracht en netwerk waar je voor betaalt, plus iets extra om te monitoren en te patchen. Repliceer voor een reden die je kan benoemen, niet standaard.