← Tilbage til koncepter

Database Replication

Arkitektur

Proces hvor data kopieres fra én database til en eller flere andre for høj tilgængelighed og performance.

Beskrivelse

Databasereplikering er praksis hvor data fra én database (primary/master) kopieres til en eller flere andre databaser (replicas/slaves). Dette giver flere fordele: høj tilgængelighed ved fejl, belastningsfordeling af læseforespørgsler og geografisk distribution af data. Der findes forskellige replikeringstopologier: Master-Slave hvor én primary tager skrivninger og flere replicas tager læsninger, Master-Master hvor begge databaser tager skrivninger (komplekst) og Multi-Master med mange skrive-kapable noder. Replikering kan være synkron (garanteret konsistent men langsommere) eller asynkron (hurtigere men eventual consistency). Populære replikeringsstrategier inkluderer Statement-Based (genspil SQL-sætninger), Row-Based (replikér faktiske rækkeændringer) og Logical Replication (replikér på logisk niveau). Replikering er fundamental for produktionssystemer - næsten ingen moderne applikationer kører på enkelt databaseinstans.

Problem

En enkelt database er en single point of failure - hvis den går ned, er hele systemet nede. Derudover kan én server ikke håndtere massive read load fra millioner af brugere. Hvordan sikrer man uptime og skalerer read capacity?

Løsning

Replication kopierer data til multiple servers. Hvis primary fejler, kan en replica promoveres. Read queries distribueres på tværs af replicas for load balancing. Dette giver både high availability og bedre performance.

Eksempel

-- Master-Slave Replication Setup (PostgreSQL)

-- Primary database (master)
-- Håndterer ALL writes
CREATE TABLE products (id SERIAL PRIMARY KEY, name TEXT);
INSERT INTO products (name) VALUES ('Laptop');
-- Dette skrives til Write-Ahead Log (WAL)

-- Replica 1, 2, 3 (slaves/read replicas)
-- Modtager og replayer WAL fra primary
-- Dataene kommer automatisk til replicas

-----------------------------------------------------

-- Application Logic
class DatabaseConnection {
  constructor() {
    this.primary = new Client({ host: 'primary.db.com' });
    this.replicas = [
      new Client({ host: 'replica1.db.com' }),
      new Client({ host: 'replica2.db.com' }),
      new Client({ host: 'replica3.db.com' })
    ];
  }

  // Write operations GÅR TIL PRIMARY
  async write(query) {
    return await this.primary.query(query);
  }

  // Read operations LOAD BALANCES over replicas
  async read(query) {
    const replica = this.getRandomReplica();
    return await replica.query(query);
  }

  getRandomReplica() {
    const index = Math.floor(Math.random() * this.replicas.length);
    return this.replicas[index];
  }
}

// Usage
const db = new DatabaseConnection();

// Write går til primary
await db.write('INSERT INTO products (name) VALUES ($1)', ['Mouse']);

// Reads distribueres til replicas (1/3 chance for hver)
await db.read('SELECT * FROM products WHERE category = $1', ['electronics']);

-----------------------------------------------------

-- Synchronous vs Asynchronous

-- Synchronous: Primary venter på replica confirmation
BEGIN;
  INSERT INTO orders VALUES (...);
COMMIT; -- Blocks until ALL replicas confirm
-- Pro: Guaranteed consistency
-- Con: Higher latency

-- Asynchronous: Primary commits immediately  
BEGIN;
  INSERT INTO orders VALUES (...);
COMMIT; -- Returns immediately
-- Replicas får data 10-100ms senere
-- Pro: Low latency
-- Con: Temporary inconsistency (eventual consistency)

Fordele

  • Høj tilgængelighed via automatisk failover
  • Horisontal skalering af læseydelse
  • Geografisk distribution for lavere latenstid
  • Backup og katastrofegenopretning
  • Vedligeholdelse uden nedetid

Udfordringer

  • Replikeringsforsinkelse (asynkron)
  • Kompleksitet i failover-logik
  • Eventual consistency-problemer
  • Skriveflaskehals (primary er stadig enkelt punkt)
  • Lagringsomkostninger (duplikeret data)

Anvendelsesområder

  • Højtrafikerede websteder (skalér læsninger)
  • Globale applikationer (geo-distribution)
  • Missionskritiske systemer (HA-krav)
  • Analysearbejdsbelastninger (isoleret fra produktion)
  • Forberedelse til katastrofegenopretning

Eksempler fra den virkelige verden

  • Netflix: Replicas i alle AWS-regioner for lav latenstid
  • Facebook: Multi-datacenter-replikering til katastrofegenopretning
  • E-handel: Læsereplicas til produktkatalogforespørgsler
  • SaaS-platforme: Lejerspecifikke læsereplicas
  • Bankvirksomhed: Synkron replikering for dataholdbarhed