Het team “voegt replicatie toe voor prestaties.” Twee maanden later: master verzadigd, replica inactief bij 4% CPU, budget verdubbeld. Een ander scenario: “automatische” failover geactiveerd – de applicatie schrijft nog steeds naar het oude IP-adres van de master valt – twintig minuten onbeschikbaarheid.
Replicatie lost een goed gesteld probleem op:
- Beschikbaarheid (overleef de dood van de meester)
- Belastingstoename aflezen (belastingsafname van SELECT)
- Rapportage (analytisch zonder de productie te onderbreken)
- Geografische nabijheid (lokale lezing — met zwakke consistentie)
Kiezen voor “replica omdat het professioneel is” zonder leesroutering = kosten plus complexiteit zonder winst.
Doelmatrix → architectuur
| Doel | Model | Val |
|---|---|---|
| Hoge beschikbaarheid | Primaire + synchrone/semi-synchrone stand-by + Patroni | Ongeteste gespleten hersenen |
| Lezen opschalen | Asynchrone replica's + lees-/schrijfproxy | Post-schrijven UX Shift |
| Live-back-up | Vertraagde replica | Vervangt geen geteste back-up |
| Geografisch lezen | Regionale replica | Consistentieconflicten |
Een replica is geen back-up — logische corruptie wordt ook gerepliceerd.
Replicatievertraging en webgebruikerservaring
Na registratie:
// POST-master → redirect GET /profile
// GET op replica → gebruiker nog niet zichtbaar als vertraging 2s
Oplossingen:
- Je eigen schrijfsels lezen: sticky-sessie op de master N seconden na schrijven.
- Proxy: ProxySQL, PgBouncer met intelligente routing.
- CQRS: accepteer mogelijke consistentie aan de interfacezijde.
MySQL versus PostgreSQL: exploitatieweergave
MySQL: asynchrone/semi-synchrone binlog; replica's lezen; Omschakeling MHA/orkestrator.
PostgreSQL: streaming-replicatie; hete stand-by bij het lezen; Patroni-omschakeling + etcd.
Beheerde database (RDS, Cloud SQL, OVH DB): Multi-AZ ≠ leesreplica — lees de productdocumentatie. Om hosting te kiezen, zie VPS of cloud en de overzicht.
Wanneer een replica op dezelfde host voldoende is — of niet
| Laden | Aanbeveling |
|---|---|
| Blog, kleine SaaS | Eén exemplaar plus geteste back-ups |
| Lezen >> gemeten schrijven | Eén of twee leesreplica's |
| SLA 99,9%+ | Beheerde hoge beschikbaarheid of Patroni-team |
| Zware analyses | Replica gewijd aan rapportage |
Een replica op dezelfde fysieke server (sommige aanbiedingen op gedeeld of instapniveau) is een illusie van hoge beschikbaarheid: hardwarestoring, storing van beide. Voordat u een replica toevoegt, meet u de lees-/schrijfverhouding met pg_stat_statements of uw applicatiemonitoringtool. Een slecht geïndexeerde master blijft traag, zelfs met drie ongebruikte replica's.
De top: het repliceren van dubbele gegevens – geen beschikbaarheid zonder testen
Dit is wat de dia ‘hoge beschikbaarheid’ vergeet te laten zien.
Budget: driemaandelijkse omschakeling > derde ongebruikte replica.
Beslis en ga vooruit zonder blinde vlek
Voordat u een replica toevoegt, vermeldt u het doel in één zin:
- Formuleer de doelstelling: hoge beschikbaarheid, uitlezen, rapportage of geografie.
- Meet de lees-/schrijfverhouding van uw applicatieroutes.
- Expliciet routeren SELECTEERT als de leesbelasting toeneemt.
- Bewaak de vertraging plus waarschuwingen boven de bedrijfsdrempel.
- Test gedocumenteerde failover minstens elk kwartaal.
Een replica zonder leesroutering of failover-oefening is een budgetlijn, geen verzekering. Kruis met EXPLAIN PostgreSQL om de master te optimaliseren voordat deze wordt gedupliceerd.
Veelgestelde vragen
Versnelt een leesreplica mijn site automatisch?
Alleen als u SELECTs expliciet naar de replica routeert en de belasting grotendeels wordt gelezen. Als alles via de master gaat, blijft de replica inactief en nutteloos voor prestaties.
Wat is replicatievertraging?
Dit is de vertraging tussen het vastleggen op de master en de zichtbaarheid op de replica. Een vertraging van enkele seconden kan er tijdelijk voor zorgen dat de gegevens die een gebruiker zojuist heeft geschreven, verdwijnen.
Synchrone versus asynchrone replicatie?
Synchrone beperkt gegevensverlies maar verhoogt de schrijflatentie. Asynchroon verbetert de schrijfprestaties ten koste van het risico op verlies als de master vóór propagatie sterft.
Is de automatische schakelaar klaar voor gebruik?
Nee. Het vereist een orkestrator, regelmatige tests en split-brain management. DNS of virtueel adres moet overschakelen naar de nieuwe master - niets gaat automatisch zonder configuratie en oefening.
Repliceren zonder een doel betekent twee keer betalen voor dezelfde zoekopdracht die slecht is geïndexeerd op de master.