Verschil tussen stroomreplicatie en logische replicatie

TL;DR :Logische replicatie verzendt rij-voor-rij wijzigingen, fysieke replicatie stuurt schijfblokwijzigingen. Logische replicatie is beter voor sommige taken, fysieke replicatie voor andere.

Merk op dat in PostgreSQL 12 (actueel op het moment van update) logische replicatie stabiel en betrouwbaar is, maar vrij beperkt. Gebruik fysieke replicatie als je deze vraag stelt.

Streaming-replicatie kan zijn logische replicatie. Het is allemaal een beetje ingewikkeld.

WAL-verzending versus streaming

Er zijn twee manieren om gegevens van master naar replica te verzenden in PostgreSQL:

• WAL-verzending of continu archiveren , waar individuele write-ahead-log-bestanden worden gekopieerd van pg_xlog door het archive_command draaien op de master naar een andere locatie. Een restore_command geconfigureerd in recovery.conf . van de replica draait op de replica om de archieven op te halen, zodat de replica de WAL kan afspelen.

  Dit wordt gebruikt voor point-in-time replicatie (PITR), die wordt gebruikt als een methode voor continue back-up.

  Er is geen directe netwerkverbinding met de masterserver nodig. Replicatie kan lange vertragingen hebben, vooral zonder een archive_timeout set. WAL-verzending kan niet worden gebruikt voor synchrone replicatie.

• streaming-replicatie , waarbij elke wijziging direct via een TCP/IP-verbinding naar een of meer replicaservers wordt verzonden. De replica's moeten een directe netwerkverbinding hebben die de master heeft geconfigureerd in hun recovery.conf 's primary_conninfo optie.

  Streamingreplicatie heeft weinig of geen vertraging zolang de replica snel genoeg is om bij te blijven. Het kan worden gebruikt voor synchrone replicatie . U kunt streaming-replicatie voor PITR niet gebruiken, dus het heeft niet veel zin voor continue back-up. Als je een tafel op de master laat vallen, oeps, wordt deze ook op de replica's gedropt.

De twee methoden hebben dus verschillende doelen.

Asynchrone vs synchrone streaming

Bovendien is er synchrone en asynchroon streaming replicatie:

• In asynchrone streaming-replicatie de replica('s) mogen op tijd achterlopen op de master als de master sneller/drukker is. Als de master crasht, kunt u gegevens kwijtraken die nog niet zijn gerepliceerd.

  Als de asynchrone replica te ver achterloopt op de master, kan de master informatie weggooien die de replica nodig heeft als max_wal_size (voorheen wal_keep_segments) is too low and no slot is used, meaning you have to re-create the replica from scratch. Or the master's pg_wal(was pg_xlog) kan vol raken en de master stoppen met werken totdat schijfruimte is vrijgemaakt als max_wal_size is te hoog of er wordt een slot gebruikt.

• In synchrone replicatie de master is pas klaar met committen als een replica heeft bevestigd dat de transactie is ontvangen. U verliest nooit gegevens als de master crasht en u een failover naar een replica moet uitvoeren. De master zal nooit gegevens weggooien die de replica nodig heeft of zijn xlog vullen en geen schijfruimte meer hebben vanwege replicavertragingen. In ruil daarvoor kan het ervoor zorgen dat de master langzamer werkt of zelfs stopt met werken als replica's problemen hebben, en het heeft altijd enige invloed op de prestaties van de master vanwege netwerklatentie.

  Wanneer er meerdere replica's zijn, is er slechts één tegelijk synchroon. Zie synchronous_standby_names .

U kunt geen synchrone verzending van logbestanden hebben.

U kunt logboekverzending en asynchrone replicatie eigenlijk combineren om te voorkomen dat u een replica opnieuw moet maken als deze te ver achterblijft, zonder het risico te lopen de master te beïnvloeden. Dit is een ideale configuratie voor veel implementaties, gecombineerd met het bewaken van hoe ver de replica zich achter de master bevindt om ervoor te zorgen dat deze binnen acceptabele limieten voor noodherstel valt.

Logisch versus fysiek

Bovendien dat we hebben logische vs fysiek streaming replicatie, zoals geïntroduceerd in PostgreSQL 9.4:

• In fysieke streaming-replicatie wijzigingen worden verzonden op bijna schijfblokniveau, zoals "op offset 14 van schijfpagina 18 van relatie 12311, schreef tuple met hexadecimale waarde 0x2342beef1222...".

  Fysieke replicatie verzendt alles :de inhoud van elke database in de PostgreSQL-installatie, alle tabellen in elke database. Het verzendt indexitems, het verzendt de geheel nieuwe tabelgegevens wanneer u VACUUM FULL , het verzendt gegevens voor transacties die zijn teruggedraaid, enz. Het genereert dus veel "ruis" en verzendt veel overtollige gegevens. Het vereist ook dat de replica volledig identiek is, dus u kunt niets doen waarvoor een transactie nodig is, zoals het maken van tijdelijke of niet-gelogde tabellen. Het opvragen van de replica vertraagt ​​de replicatie, dus lange zoekopdrachten op de replica moeten worden geannuleerd.

In ruil daarvoor is het eenvoudig en efficiënt om de wijzigingen op de replica toe te passen, en de replica is betrouwbaar precies hetzelfde als de master. DDL wordt transparant gerepliceerd, net als al het andere, dus het vereist geen speciale behandeling. Het kan ook grote transacties streamen wanneer ze plaatsvinden, dus er is weinig vertraging tussen het vastleggen op de master en het vastleggen op de replica, zelfs bij grote wijzigingen.

Fysieke replicatie is volwassen, goed getest en algemeen aanvaard.

• logische streaming-replicatie , nieuw in 9.4, stuurt wijzigingen op een hoger niveau en veel selectiever.

Het repliceert slechts één database tegelijk. Het verzendt alleen rijwijzigingen en alleen voor vastgelegde transacties, en het hoeft geen vacuümgegevens, indexwijzigingen, enz. te verzenden. Het kan selectief alleen gegevens verzenden voor sommige tabellen in een database. Dit maakt logische replicatie veel meer bandbreedte-efficiënt.

Werken op een hoger niveau betekent ook dat u transacties kunt doen op de replicadatabases. U kunt tijdelijke en niet-gelogde tabellen maken. Zelfs normale tafels, als je wilt. U kunt externe gegevenswrappers, weergaven, functies maken, wat u maar wilt. Het is ook niet nodig om zoekopdrachten te annuleren als ze te lang duren.

Logische replicatie kan ook worden gebruikt om multi-masterreplicatie in PostgreSQL te bouwen, wat niet mogelijk is met fysieke replicatie.

In ruil daarvoor kan het echter (momenteel) geen grote transacties streamen wanneer ze plaatsvinden. Het moet wachten tot ze zich committeren. Er kan dus een lange vertraging zijn tussen het uitvoeren van een grote transactie op de master en het toepassen op de replica.

Het speelt transacties strikt in vastleggingsvolgorde af, dus kleine snelle transacties kunnen vast komen te zitten achter een grote transactie en een behoorlijke tijd vertraging oplopen.

DDL wordt niet automatisch afgehandeld. U moet zelf de tabeldefinities synchroon houden tussen master en replica, of de applicatie die gebruik maakt van logische replicatie moet hiervoor eigen faciliteiten hebben. Het kan ingewikkeld zijn om dit goed te krijgen.

Het aanvraagproces zelf is ook ingewikkelder dan "een paar bytes schrijven waar mij dat wordt verteld". Er zijn ook meer middelen nodig voor de replica dan fysieke replicatie.

De huidige logische replicatie-implementaties zijn niet volwassen of algemeen aanvaard, of bijzonder gemakkelijk te gebruiken.

Te veel opties, vertel me wat ik moet doen

Opluchting. Ingewikkeld, hè? En dan heb ik het nog niet eens gehad over de details van vertraagde replicatie, slots, max_wal_size , tijdlijnen, hoe promotie werkt, Postgres-XL, BDR en multimaster, enz.

Dus wat moet je doen ?

Er is niet één juist antwoord. Anders zou PostgreSQL dat maar op één manier ondersteunen. Maar er zijn een paar veelvoorkomende gebruiksscenario's:

Voor back-up en noodherstel gebruik pgbarman om basisback-ups te maken en WAL voor u te behouden, zodat u eenvoudig continue back-ups kunt beheren. U moet nog steeds periodiek pg_dump . nemen back-ups als extra verzekering.

Voor hoge beschikbaarheid zonder risico op gegevensverlies gebruik streaming synchrone replicatie.

Voor hoge beschikbaarheid met een laag risico op gegevensverlies en betere prestaties u moet asynchrone streaming-replicatie gebruiken. Zorg dat WAL-archivering is ingeschakeld voor fallback of gebruik een replicatieslot. Houd bij hoe ver de replica zich achter de master bevindt met behulp van externe tools zoals Icinga.

Referenties

• continu archiveren en PITR
• hoge beschikbaarheid, taakverdeling en replicatie
• replicatie-instellingen
• recovery.conf
• pgbarman
• repmgr
• wiki:replicatie, clustering en pooling van verbindingen