Hur man optimerar PostgreSQL logisk replikering

Logisk replikering eller Pglogical är en WAL-baserad replikeringsmekanism på tabellnivå som replikerar data från specifika tabeller mellan två PostgreSQL-instanser. Det verkar finnas en förvirring mellan "pglogical" och "Logical Repplication". Båda ger samma typ av replikeringsmekanism med vissa skillnader i funktioner och möjligheter. Logisk replikering introduceras i PostgreSQL-10 som en inbyggd funktion till skillnad från pglogical som är en förlängning. "Pglogical" med pågående kontinuerlig utveckling, kvarstår som det enda alternativet för att implementera logisk replikering för de miljöer som använder PostgreSQL-versioner före 10. Så småningom kommer alla funktioner i pglogical att vara en del av logisk replikering. Med andra ord, pglogical (extension) blev Logical Replication (inbyggd funktion). Den grundläggande fördelen med logisk replikering är att det inte behöver installeras/skapas några tillägg, vilket i sin tur är fördelaktigt för de miljöer där installationen av tillägg är begränsad.

Den här bloggen kommer att fokusera på att optimera logisk replikering. Det betyder att optimeringstipsen och teknikerna som lyfts fram i den här bloggen kommer att gälla för både pglogical och logisk replikering.

Logisk replikering är en WAL-baserad replikering som är den första i sitt slag. Som en DBA skulle detta vara mycket mer tillförlitlig och mer effektiv replikeringsmekanism jämfört med andra triggerbaserade replikeringslösningar. Ändringarna i tabelldelen av pglogical replikering replikeras i realtid via WAL-poster, vilket gör det mycket effektivt och icke-komplext. Alla andra replikeringsmekanismer på marknaden är triggerbaserade vilket kan innebära prestanda- och underhållsutmaningar. När logisk replikering kommer in är beroendet av triggerbaserad replikering nästan borta.

Det finns andra bloggar som förklarar hur man konfigurerar logisk replikering i detalj.

I den här bloggen kommer fokus ligga på hur man optimerar logisk replikering.

Optimera logisk replikering

Till att börja med är beteendet för "Logical Replication" ganska likt "Streaming Replication", den enda skillnaden är att strömmande replikering replikerar hela databasen medan Logisk replikering endast replikerar enskilda tabeller. När du väljer specifika individuella tabeller att replikera finns det faktorer/utmaningar som måste förutses.

Låt oss ta en titt på faktorer som påverkar logisk replikering.

Faktorer som påverkar prestanda för logisk replikering

Att optimera logisk replikering är viktigt för att säkerställa att data replikeras sömlöst utan några avbrott. Det finns faktorer att förutse innan du ställer in den. Låt oss ta en titt på dem:

• Typen av data som lagras i tabellerna som ska replikeras
• Hur transaktionsaktiva är tabellerna (en del av replikeringen)
• Infrastrukturkapacitet måste förutses
• Parameterkonfiguration måste göras optimalt

Alla ovanstående faktorer påverkar logisk replikering i större utsträckning. Låt oss ta en titt på dem i detalj.

PostgreSQL logiska replikeringsdatatyper

Det är viktigt att förstå vilken typ av data som lagras i tabellen. Om tabelldelen av replikeringen lagrar stora text- eller binära objekt och stöter på ett stort antal transaktioner, kan replikeringen sakta ner på grund av hög användning av infrastrukturresurser. Infrastrukturens kapacitet måste vara tillräcklig för att hantera sådana komplexa och stora datareplikering.

Hur aktiva tabeller är transaktionsmässigt en del av replikering

Vid replikering av mycket transaktionsaktiva tabeller kan replikering släpa efter i synkronisering på grund av I/O-prestandaproblem, dödlägen, etc, som måste tas i beaktande. Detta kanske inte får produktionsdatabasmiljöer att se hälsosammare ut. Om antalet tabeller som replikeras är högt och data replikeras till flera webbplatser, kan det bli hög CPU-användning och fler CPU-enheter (eller CPU-kärnor) krävs.

Infrastrukturkapacitet

Innan man överväger logisk replikering som en lösning är det viktigt att säkerställa att databasservrarnas infrastrukturkapacitet är tillräcklig. Om det finns ett stort antal tabeller som replikeras måste det finnas tillräckligt många processorer tillgängliga för att utföra replikeringsjobbet.

När du replikerar ett stort antal tabeller, överväg att dela upp dem i grupper och replikera parallellt. Återigen kommer detta att behöva flera processorer för att vara tillgängliga för replikering. Om dataändringarna i tabellerna som replikeras är frekventa och höga kan detta också påverka replikeringsprestandan.

Optimera parametrar för logisk replikering

Parametrar som är konfigurerade för logisk replikering måste ställas in optimalt för att säkerställa att replikeringen inte går sönder.

Låt oss först ta en titt på parametrar som behövs för att konfigurera den:

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

Justera max_wal_sändare

max_wal_sändare måste alltid vara större än antalet repliker. Om data replikeras till flera webbplatser, kommer flera max_wal_sändare att spela in. Så det är viktigt att se till att denna parameter är inställd på ett optimalt antal.

Tuning max_replication_slots

I allmänhet skrivs alla dataändringar som sker i tabellerna till WAL-filer i pg_xlog / pg_wal som kallas WAL-poster. Wal-avsändarprocessen skulle plocka upp dessa WAL-poster (som tillhör tabellerna som replikeras) och skickar till replikerna och wal_receiver-processen på replikplatsen skulle tillämpa dessa ändringar vid abonnentnoden.

WAL-filerna tas bort från pg_xlog/pg_wal-platsen närhelst kontrollpunkten inträffar. Om WAL-filerna tas bort redan innan ändringarna tillämpas på abonnentnoden, skulle replikeringen gå sönder och släpa efter. Om abonnentens nod släpar efter, skulle en replikeringsplats säkerställa att alla WAL-filer som behövs för att abonnenten ska bli synkroniserade med leverantören behålls. Det rekommenderas att konfigurera en replikeringsplats för varje abonnentnod.

Tuning max_worker_processes

Det är viktigt att ha ett optimalt antal arbetarprocessorer konfigurerade. Detta beror på hur många max antal processer en server kan ha. Detta är endast möjligt i multi-CPU-miljöer. Max_worker_processes kommer att säkerställa att flera processer skapas för att få jobbet gjort på ett snabbare sätt genom att använda flera CPU-kärnor. När du replikerar data med hjälp av logisk replikering kan den här parametern hjälpa till att generera flera arbetsprocesser för att replikera data snabbare. Det finns en specifik parameter som heter max_logical_worker_processes som säkerställer att flera processer används för att kopiera data.

Justera max_logical_worker_processes

Den här parametern anger det maximala antalet logiska arbetsprocesser som krävs för att replikera och synkronisera tabelldata. Detta värde är hämtat från max_worker_processes som bör vara högre än detta parametervärde. Den här parametern är mycket fördelaktig när du kopierar data till flera platser i miljöer med flera processorer. Standard är 4. Maxvärdet beror på hur många arbetsprocesser som systemet stöder.

Tuning max_sync_workers_per_subscription

Den här parametern anger det maximala antalet synkroniseringsprocesser som krävs per prenumeration. Synkroniseringsprocessen äger rum under initial datasynkronisering och för att säkerställa att det sker snabbare kan denna parameter användas. För närvarande kan endast en synkroniseringsprocess konfigureras per tabell, vilket innebär att flera tabeller initialt kan synkroniseras parallellt. Standardvärdet är 2. Detta värde väljs från max_logical_worker_processes värde.

Det är de parametrar som måste ställas in för att säkerställa att logisk replikering är effektiv och snabbare. De andra parametrarna som också påverkar logisk replikering är följande.

wal_receiver_timeout, wal_receiver_status_interval and wal_retrieve_retry_interval.

Dessa parametrar har ingen effekt på leverantörsnoden.

Slutsats

Replikeringsspecifika tabeller är ett vanligt krav som uppstår i stora och komplexa databassystem. Detta kan vara för affärsrapportering eller datalagringsändamål. Som en DBA tror jag att logisk replikering i hög grad tillgodoser sådana ändamål på grund av dess enkla implementering med mindre komplexitet. Konfigurering och justering av logisk replikering kräver en hel del planering, arkitektur och testning. Mängden data som replikeras i realtid måste utvärderas för att säkerställa att ett effektivt och skenbart replikeringssystem finns på plats. Sammanfattningsvis, databaser som körs i PostgreSQL-10, logisk replikering är vägen att gå och för de databaser som körs i PostgreSQL-versioner <10, är ​​pglogical alternativet.