Sådan optimeres PostgreSQL logisk replikering

Logisk replikering eller Pglogical er en WAL-baseret replikeringsmekanisme på tabelniveau, som replikerer data fra specifikke tabeller mellem to PostgreSQL-instanser. Der synes at være en forvirring mellem "pglogical" og "Logical Replication". Begge giver den samme slags replikeringsmekanisme med nogle forskelle i funktioner og muligheder. Logisk replikering er introduceret i PostgreSQL-10 som en indbygget funktion i modsætning til pglogical, som er en udvidelse. "Pglogical" med igangværende kontinuerlige udviklinger, forbliver som den eneste mulighed for at implementere logisk replikering for de miljøer, der bruger PostgreSQL-versioner før 10. Til sidst vil alle funktionerne i pglogical være en del af logisk replikering. Med andre ord blev pglogical (udvidelse) til logisk replikering (indbygget funktion). Den grundlæggende fordel ved logisk replikering er, at det ikke behøver nogen udvidelser at blive installeret / oprettet, hvilket igen er gavnligt for de miljøer, hvor installation af udvidelser er begrænset.

Denne blog vil fokusere på at optimere logisk replikering. Det betyder, at de optimeringstip og -teknikker, der er fremhævet i denne blog, vil gælde for både pglogisk og logisk replikering.

Logisk replikering er en WAL-baseret replikering, som er den første af sin slags. Som en DBA ville dette være meget mere pålidelig og mere effektiv replikeringsmekanisme sammenlignet med andre triggerbaserede replikeringsløsninger. Ændringerne i tabeldelen af ​​pglogisk replikering replikeres i realtid via WAL-poster, hvilket gør det yderst effektivt og ikke-komplekst. Alle de andre replikeringsmekanismer på markedet er triggerbaserede, hvilket kan udgøre præstations- og vedligeholdelsesudfordringer. Når logisk replikering kommer ind, er afhængigheden af ​​triggerbaseret replikering næsten væk.

Der er andre blogs, som forklarer, hvordan man konfigurerer logisk replikering ganske detaljeret.

I denne blog vil fokus være på, hvordan man optimerer logisk replikering.

Optimering af logisk replikering

Til at begynde med er adfærden for "Logical Replication" ret lig med "Streaming Replication", den eneste forskel er, at streaming-replikering replikerer hele databasen, mens Logisk replikering kun replikerer individuelle tabeller. Når du vælger specifikke individuelle tabeller til replikering, er der faktorer/udfordringer, der skal forudses.

Lad os tage et kig på faktorer, der påvirker logisk replikering.

Faktorer, der påvirker logisk replikeringsydelse

Optimering af logisk replikering er vigtigt for at sikre, at data replikeres problemfrit uden nogen afbrydelser. Der er faktorer, der skal forudses, før du sætter det op. Lad os tage et kig på dem:

• Den type data, der er gemt i tabellerne, der skal replikeres
• Hvor transaktionsaktive er tabellerne (en del af replikering)
• Infrastrukturkapacitet skal forudses
• Parameterkonfiguration skal udføres optimalt

Alle ovenstående faktorer påvirker logisk replikering i højere grad. Lad os se nærmere på dem.

PostgreSQL logiske replikeringsdatatyper

Det er vigtigt at forstå typen af ​​data, der er gemt i tabellen. Hvis tabeldelen af ​​replikering gemmer store tekst- eller binære objekter og støder på et stort antal transaktioner, kan replikeringen blive langsommere på grund af høj brug af infrastrukturressourcer. Infrastrukturens kapacitet skal være tilstrækkelig til at håndtere en så kompleks og stor datareplikering.

Hvordan aktive tabeller er transaktionsmæssigt en del af replikering

Når du replikerer meget transaktionsaktive tabeller, kan replikering halte bagud i synkronisering på grund af I/O-ydelsesproblemer, deadlocks osv., som skal tages i betragtning. Dette får muligvis ikke produktionsdatabasemiljøer til at se sundere ud. Hvis antallet af tabeller, der replikeres, er højt, og dataene replikeres til flere websteder, kan der være højt CPU-forbrug, og der kræves flere CPU'er (eller CPU-kerner).

Infrastrukturkapacitet

Før du overvejer logisk replikering som en løsning, er det vigtigt at sikre, at databaseservernes infrastrukturkapacitet er tilstrækkelig nok. Hvis der er et stort antal tabeller, der replikeres, skal der være nok CPU'er til rådighed til at udføre replikeringsjobbet.

Når du replikerer et stort antal tabeller, skal du overveje at opdele dem i grupper og replikere parallelt. Igen vil dette kræve flere CPU'er for at være tilgængelige for replikering. Hvis dataændringerne i de tabeller, der replikeres, er hyppige og høje, kan dette også påvirke replikeringsydelsen.

Optimering af parametre til logisk replikering

Parametre, der er konfigureret til logisk replikering, skal indstilles optimalt for at sikre, at replikering ikke går i stykker.

Lad os først tage et kig på de nødvendige parametre for at konfigurere det:

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

Tuning af max_wal_sendere

max_wal_senders skal altid være større end antallet af replikaer. Hvis dataene replikeres til flere websteder, kommer flere max_wal_sendere i spil. Så det er vigtigt at sikre, at denne parameter er indstillet til et optimalt tal.

Tuning max_replication_slots

Generelt bliver alle dataændringer, der forekommer på tabellerne, skrevet til WAL-filer i pg_xlog / pg_wal, som betegnes som WAL-poster. Wal-afsenderprocessen vil afhente disse WAL-poster (der hører til de tabeller, der replikeres) og sender videre til replikaerne, og wal_receiver-processen på replika-webstedet vil anvende disse ændringer ved abonnentknudepunktet.

WAL-filerne fjernes fra pg_xlog/pg_wal-placeringen, hver gang kontrolpunktet opstår. Hvis WAL-filerne fjernes, selv før ændringerne anvendes på abonnentknudepunktet, ville replikeringen bryde og halte bagud. I tilfælde af at abonnentknudepunktet halter bagud, vil en replikeringsslot sikre, at alle de WAL-filer, der er nødvendige for, at abonnenten kan synkroniseres med udbyderen, bevares. Det anbefales at konfigurere én replikeringsplads til hver abonnent node.

Justering af max_worker_processes

Det er vigtigt at have et optimalt antal arbejdsprocessorer konfigureret. Dette afhænger af, hvor mange maks. antal processer en server kan have. Dette er kun muligt i multi-CPU-miljøer. Max_worker_processes vil sikre, at flere processer opstår for at få arbejdet gjort på en hurtigere måde ved at bruge flere CPU-kerner. Når du replikerer data ved hjælp af logisk replikering, kan denne parameter hjælpe med at generere flere arbejdsprocesser for at replikere dataene hurtigere. Der er en specifik parameter kaldet max_logical_worker_processes, som sikrer, at der bruges flere processer til at kopiere dataene.

Justering af max_logical_worker_processes

Denne parameter angiver det maksimale antal logiske arbejdsprocesser, der kræves for at udføre tabeldatareplikering og synkronisering. Denne værdi er taget fra max_worker_processes, som burde være højere end denne parameterværdi. Denne parameter er meget fordelagtig, når du replikerer data til flere websteder i multi-CPU-miljøer. Standarden er 4. Den maksimale værdi afhænger af, hvor mange arbejdsprocesser systemet understøtter.

Tuning max_sync_workers_per_subscription

Denne parameter angiver det maksimale antal synkroniseringsprocesser, der kræves pr. abonnement. Synkroniseringsprocessen finder sted under indledende datasynkronisering, og for at sikre, at det sker hurtigere, kan denne parameter bruges. I øjeblikket kan der kun konfigureres én synkroniseringsproces pr. tabel, hvilket betyder, at flere tabeller kan synkroniseres indledningsvis parallelt. Standardværdien er 2. Denne værdi er valgt fra værdien max_logical_worker_processes.

Det er de parametre, der skal justeres for at sikre, at logisk replikering er effektiv og hurtigere. De andre parametre, som også påvirker logisk replikering, er som følger.

wal_receiver_timeout, wal_receiver_status_interval and wal_retrieve_retry_interval.

Disse parametre har ingen effekt på udbydernoden.

Konklusion

Replikeringsspecifikke tabeller er et almindeligt krav, som opstår i store og komplekse databasesystemer. Dette kan være til forretningsrapportering eller data warehousing formål. Som DBA tror jeg, at logisk replikering i høj grad henvender sig til sådanne formål på grund af dens nemme implementering med mindre kompleksitet. Konfiguration og justering af logisk replikering kræver en god mængde planlægning, arkitektur og test. Mængden af ​​data, der replikeres i realtid, skal evalueres for at sikre, at et effektivt og tilsyneladende replikeringssystem er på plads. For at konkludere, databaser, der kører i PostgreSQL-10, er logisk replikering vejen at gå, og for de databaser, der kører i PostgreSQL-versioner <10, er pglogical muligheden.