Verschil tussen streamreplicatie en logische replicatie

Kan iemand me meer vertellen over het verschil tussen fysieke replicatie en logische replicatie in PostgreSQL?

Antwoord 1, autoriteit 100%

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 kanlogische replicatie zijn. 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-verzendingof continue archivering, waarbij individuele vooruitschrijf-logbestanden worden gekopieerd van pg_xlogdoor de archive_commanddraait op de master naar een andere locatie. Een restore_commandgeconfigureerd in recovery.confvan de replica wordt uitgevoerd op de replica om de archieven op te halen, zodat de replica de WAL kan afspelen.

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

  Er is geen directe netwerkverbinding met de hoofdserver vereist. Replicatie kan lange vertragingen hebben, vooral zonder een archive_timeoutset. 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.

  Streaming-replicatie heeft weinig of geen vertraging zolang de replica snel genoeg is om bij te blijven. Het kan worden gebruikt voor synchrone replicatie. U kunt streamingreplicatie 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 synchroneen asynchronestreamingreplicatie:

• Bij asynchrone streaming-replicatiemogen de replica(‘s) 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(waspg_xlog) van de master kan vol raken en de master stoppen met werken totdat schijfruimte is vrijgemaakt als max_wal_sizete hoog is of een slot wordt gebruikt .

• In synchrone replicatiebeëindigt de master het committen niet totdat een replica heeft bevestigd dat het de transactie²heeft 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.

  Als er meerdere replica’s zijn, is er maar één tegelijk synchroon. Zie synchronous_standby_names.

U kunt geen synchrone verzending van logbestanden hebben.

Je kunt het verzenden van logbestanden en asynchrone replicatie combineren om te voorkomen dat je een replica opnieuw moet maken als deze te ver achterblijft, zonder dat dit gevolgen heeft voor de master. 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

Bovenop dathebben we logischevs fysiekestreaming-replicatie, zoals geïntroduceerd in PostgreSQL 9.4:

• In fysieke streaming-replicatieworden wijzigingen 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 veelbandbreedte-efficiënter.

Op een hoger niveau werken 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-master replicatie 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 herhaalt transacties strikt in de vastgelegde volgorde, dus kleine snelle transacties kunnen vast komen te zitten achter een grote transactie en een behoorlijke tijd vertraging oplopen.

DDL wordt niet automatisch verwerkt. 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 opgedragen”. 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

Oef. 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 gebruiksgevallen:

Voor back-up en noodherstelgebruikt u pgbarmanom basisback-ups te maken en WAL voor u te behouden, zodat u eenvoudig continue back-ups kunt beheren. U moet nog steeds periodieke pg_dumpback-ups nemen als extra verzekering.

Gebruik voor hoge beschikbaarheid zonder risico op gegevensverliesstreaming synchrone replicatie.

Voor hoge beschikbaarheid met een laag risico op gegevensverlies en betere prestatiesmoet u asynchrone streamingreplicatie gebruiken. Zorg dat WAL-archivering is ingeschakeld voor fallback of gebruik een replicatieslot. Controleer 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