Hoe PostgreSQL logische replicatie te optimaliseren

Logische replicatie of Pglogical is een op WAL gebaseerd replicatiemechanisme op tabelniveau dat de gegevens van specifieke tabellen repliceert tussen twee PostgreSQL-instanties. Er lijkt een verwarring te bestaan ​​tussen "pglogical" en "Logical Replication". Beide bieden hetzelfde soort replicatiemechanisme met enkele verschillen in functies en mogelijkheden. Logische replicatie is geïntroduceerd in PostgreSQL-10 als een ingebouwde functie, in tegenstelling tot pglogical, dat een extensie is. "Pglogical" met voortdurende voortdurende ontwikkelingen, blijft de enige optie voor het implementeren van Logical Replication voor die omgevingen die PostgreSQL-versies ouder dan 10 gebruiken. Uiteindelijk zullen alle functies die deel uitmaken van pglogical onderdeel uitmaken van Logical Replication. Met andere woorden, pglogical (extensie) werd Logische replicatie (ingebouwde functie). Het basisvoordeel van logische replicatie is dat er geen extensies hoeven te worden geïnstalleerd / gemaakt, wat op zijn beurt gunstig is voor die omgevingen waar het installeren van extensies beperkt is.

Deze blog gaat over het optimaliseren van logische replicatie. Dat betekent dat de optimalisatietips en -technieken die in deze blog worden genoemd, van toepassing zijn op zowel pglogische als logische replicatie.

Logische replicatie is een op WAL gebaseerde replicatie die de eerste in zijn soort is. Als DBA zou dit een veel betrouwbaarder en performanter replicatiemechanisme zijn in vergelijking met andere op triggers gebaseerde replicatieoplossingen. De wijzigingen die zijn aangebracht in het tabellengedeelte van pglogische replicatie worden in realtime gerepliceerd via WAL-records, wat het zeer efficiënt en niet-complex maakt. Alle andere replicatiemechanismen op de markt zijn op triggers gebaseerd, wat een prestatie- en onderhoudsuitdaging kan opleveren. Met de komst van logische replicatie is de afhankelijkheid van replicatie op basis van triggers bijna verdwenen.

Er zijn andere blogs die heel gedetailleerd uitleggen hoe logische replicatie moet worden geconfigureerd.

In deze blog ligt de nadruk op het optimaliseren van logische replicatie.

Logische replicatie optimaliseren

Om te beginnen is het gedrag van "Logische replicatie" vrij gelijkaardig aan "Streaming-replicatie", het enige verschil is dat streaming-replicatie de volledige database repliceert, terwijl logische replicatie alleen afzonderlijke tabellen repliceert. Bij het kiezen van specifieke individuele tabellen om te repliceren, zijn er factoren / uitdagingen die moeten worden voorzien.

Laten we eens kijken naar factoren die logische replicatie beïnvloeden.

Factoren die de prestaties van logische replicatie beïnvloeden

Het optimaliseren van logische replicatie is belangrijk om ervoor te zorgen dat gegevens naadloos worden gerepliceerd zonder onderbrekingen. Er zijn factoren die u moet voorzien voordat u het instelt. Laten we ze eens bekijken:

• Het type gegevens dat is opgeslagen in de tabellen die moeten worden gerepliceerd
• Hoe transactioneel actief zijn de tabellen (onderdeel van replicatie)
• Infrastructuurcapaciteit moet worden voorzien
• Parameterconfiguratie moet optimaal worden gedaan

Alle bovenstaande factoren beïnvloeden logische replicatie in grotere mate. Laten we ze eens in detail bekijken.

PostgreSQL-gegevenstypen voor logische replicatie

Het is belangrijk om het type gegevens te begrijpen dat in de tabel is opgeslagen. Als het tabelgedeelte van replicatie grote tekst- of binaire objecten opslaat en een groot aantal transacties tegenkomt, kan de replicatie vertragen vanwege het hoge gebruik van infrastructuurbronnen. De capaciteit van de infrastructuur moet voldoende zijn om dergelijke complexe en grootschalige gegevensreplicatie aan te kunnen.

Hoe actieve tabellen transactioneel deel uitmaken van replicatie

Bij het repliceren van zeer transactioneel actieve tabellen kan de replicatie synchroon achterblijven vanwege problemen met de I/O-prestaties, impasses, enzovoort, waarmee rekening moet worden gehouden. Hierdoor zien productiedatabaseomgevingen er mogelijk niet gezonder uit. Als het aantal tabellen dat wordt gerepliceerd hoog is en de gegevens naar meerdere sites worden gerepliceerd, is er mogelijk een hoog CPU-gebruik en zijn meer CPU's (of CPU-cores) vereist.

Infrastructuurcapaciteit

Voordat Logical Replication als oplossing wordt overwogen, is het belangrijk om ervoor te zorgen dat de infrastructuurcapaciteit van de databaseservers voldoende is. Als er een groot aantal tabellen wordt gerepliceerd, moeten er voldoende CPU's beschikbaar zijn om de replicatietaak uit te voeren.

Wanneer u een groot aantal tabellen repliceert, kunt u overwegen deze in groepen te splitsen en parallel te repliceren. Nogmaals, dit heeft meerdere CPU's nodig om beschikbaar te zijn voor replicatie. Als de gegevenswijzigingen in de tabellen die worden gerepliceerd frequent en hoog zijn, kan dit ook van invloed zijn op de replicatieprestaties.

Parameters optimaliseren voor logische replicatie

Parameters die zijn geconfigureerd voor het functioneren van logische replicatie moeten optimaal worden afgestemd om te voorkomen dat de replicatie wordt verbroken.

Laten we eerst eens kijken naar de parameters die nodig zijn om het te configureren:

wal_level=’logical’
max_wal_senders=10                     # greater than number of subscribers (or replicas)
max_replication_slots=10              # greater than number of subscribers (or replicas)
max_worker_processes=10           # greater than number of subscribers (or replicas)
max_logical_replication_workers  # greater than number of subscribers (or replicas)
max_sync_workers_per_subscription # depends on number of tables being replicated

Max_wal_senders afstemmen

max_wal_senders moet altijd groter zijn dan het aantal replica's. Als de gegevens naar meerdere sites worden gerepliceerd, komen meerdere max_wal_senders in het spel. Het is dus belangrijk om ervoor te zorgen dat deze parameter is ingesteld op een optimaal aantal.

Max_replication_slots afstemmen

Over het algemeen worden alle gegevenswijzigingen die plaatsvinden in de tabellen geschreven naar WAL-bestanden in pg_xlog / pg_wal die WAL-records worden genoemd. Het Wal-zenderproces zou die WAL-records (behorende tot de tabellen die worden gerepliceerd) ophalen en naar de replica's verzenden en het wal_receiver-proces op de replicasite zou die wijzigingen toepassen op het abonneeknooppunt.

De WAL-bestanden worden verwijderd van de pg_xlog/pg_wal-locatie wanneer het controlepunt zich voordoet. Als de WAL-bestanden worden verwijderd nog voordat de wijzigingen zijn toegepast op het abonneeknooppunt, zou de replicatie worden afgebroken en achterblijven. In het geval dat het abonneeknooppunt achterblijft, zou een replicatieslot ervoor zorgen dat alle WAL-bestanden die de abonnee nodig heeft om te synchroniseren met de provider, behouden blijven. Het wordt aanbevolen om één replicatieslot voor elk abonneeknooppunt te configureren.

Max_worker_processes afstemmen

Het is belangrijk om een ​​optimaal aantal worker-processors te configureren. Dit hangt af van het maximale aantal processen dat een server kan hebben. Dit is alleen mogelijk in omgevingen met meerdere CPU's. Max_worker_processes zorgt ervoor dat meerdere processen worden gestart om de klus op een snellere manier te klaren door gebruik te maken van meerdere CPU-kernen. Bij het repliceren van gegevens met behulp van logische replicatie, kan deze parameter helpen bij het genereren van meerdere werkprocessen om de gegevens sneller te repliceren. Er is een specifieke parameter genaamd max_logical_worker_processes die ervoor zorgt dat meerdere processen worden gebruikt om de gegevens te kopiëren.

Max_logical_worker_processes afstemmen

Deze parameter geeft het maximale aantal logische werkprocessen aan dat nodig is om tabelgegevensreplicatie en -synchronisatie uit te voeren. Deze waarde is afkomstig van max_worker_processes, die hoger moet zijn dan deze parameterwaarde. Deze parameter is erg handig bij het repliceren van gegevens naar meerdere sites in omgevingen met meerdere CPU's. De standaardwaarde is 4. De maximale waarde hangt af van het aantal werkprocessen dat het systeem ondersteunt.

Max_sync_workers_per_subscription afstemmen

Deze parameter specificeert het maximale aantal synchronisatieprocessen dat per abonnement vereist is. Het synchronisatieproces vindt plaats tijdens de initiële gegevenssynchronisatie en om ervoor te zorgen dat dit sneller gebeurt, kan deze parameter worden gebruikt. Momenteel kan er slechts één synchronisatieproces per tafel worden geconfigureerd, wat betekent dat in eerste instantie meerdere tabellen parallel kunnen worden gesynchroniseerd. De standaardwaarde is 2. Deze waarde wordt gekozen uit de max_logical_worker_processes-waarde.

Dat zijn de parameters die moeten worden afgestemd om ervoor te zorgen dat logische replicatie efficiënt en sneller is. De andere parameters die ook logische replicatie beïnvloeden, zijn als volgt.

wal_receiver_timeout, wal_receiver_status_interval and wal_retrieve_retry_interval.

Deze parameters hebben geen effect op het providerknooppunt.

Conclusie

Replicatiespecifieke tabellen zijn een veelvoorkomende vereiste die zich voordoet in grote en complexe databasesystemen. Dit kan zijn voor zakelijke rapportage of Data Warehousing-doeleinden. Als DBA geloof ik dat Logical Replication zeer geschikt is voor dergelijke doeleinden vanwege de eenvoudige implementatie met minder complexiteit. Het configureren en afstemmen van Logical Replication vereist een behoorlijke hoeveelheid planning, architectuur en testen. De hoeveelheid gegevens die in realtime wordt gerepliceerd, moet worden geëvalueerd om ervoor te zorgen dat er een efficiënt en schijnbaar minder replicatiesysteem is. Tot slot, Databases die draaien in PostgreSQL-10, Logische replicatie is de juiste keuze en voor die databases die draaien in PostgreSQL-versies <10, is pglogical de optie.