Hur man replikerar PostgreSQL-data till fjärrwebbplatser

I en hektisk databasmiljö med större databaser är behovet av datareplikering i realtid en vanlig företeelse. Applikationer kräver ofta att produktionsdata replikeras i realtid till avlägsna platser för analys och andra kritiska affärsbehov.

DBA:er måste också se till att data replikeras kontinuerligt till fjärrplatserna för att uppfylla olika krav. Dessa krav är dock inte alltid att replikera hela databasen; det kan också finnas ett behov av att replikera endast en delmängd av data (som en tabell eller uppsättning tabeller eller data från flera tabeller med hjälp av en SQL för analys, rapportering etc.)

I den här bloggen kommer vi att fokusera på hur man replikerar tabeller till fjärrdatabaser i realtid.

Vad är replikering på tabellnivå?

Replikering på tabellnivå är mekanismen för att replikera data från en specifik tabell eller uppsättning tabeller från en databas (källa) till en annan databas (mål) som finns på distans i en distribuerad miljö. Replikering på tabellnivå säkerställer att tabelldata distribueras kontinuerligt och förblir konsekvent över replikerade (mål)webbplatser.

Varför använda replikering på tabellnivå?

Replikering på tabellnivå är ett väsentligt behov i större, komplexa, mycket distribuerade miljöer. Enligt min erfarenhet fanns det alltid ett behov av att replikera en uppsättning tabeller från en produktionsdatabas till ett datalager för rapporteringsändamål. Uppgifterna måste replikeras kontinuerligt för att säkerställa att rapporterna får den senaste informationen. I kritiska miljöer kan data inte tolereras, så de dataförändringar som sker i produktionen måste replikeras omedelbart till målplatsen. Detta kan vara en verklig utmaning för DBA:s att behöva prognostisera olika faktorer för att säkerställa en effektiv och smidig tabellreplikering.

Låt oss titta på några krav som replikering på tabellnivå löser:

• Rapporterna kan köras på en databas i en annan miljö än produktion, som datalager
• En distribuerad databasmiljö med distribuerade applikationer som extraherar data från flera platser. När det gäller distribuerade webb- eller mobilapplikationer bör kopian av samma data finnas tillgänglig på flera platser för att tillgodose olika applikationsbehov, för vilka replikering på tabellnivå kan vara en bra lösning
• Löneapplikationer som behöver data från olika databaser som finns på olika geografiskt distribuerade datacenter eller molninstanser för att vara tillgängliga i en centraliserad databas

Olika faktorer som påverkar replikering på tabellnivå – Vad du ska leta efter

Som vi nämnde ovan måste DBA:er ta hänsyn till en mängd olika realtidskomponenter och faktorer för att designa och implementera ett effektivt replikeringssystem på tabellnivå.

Tabellstruktur

Den typ av datatabell som är tillmötesgående har stor inverkan på replikeringsprestanda. Om tabellen rymmer en BYTEA-kolumn med större binära data, kan replikeringsprestandan ta en träff. Effekten av replikering på nätverk, CPU och disk måste utvärderas noggrant.

Datastorlek

Om tabellen som ska migreras är för stor, skulle den initiala datamigreringen ta resurser och tid, DBA:er måste se till att produktionsdatabasen inte påverkas.

Infrastrukturresurser

Infrastrukturen måste ha tillräckliga resurser för att säkerställa att ett tillförlitligt och stabilt replikeringssystem kan byggas. Vilka infrastrukturkomponenter måste beaktas?

CPU:er

Datareplikering är starkt beroende av processorer. När du replikerar från produktion får CPU:erna inte bli uttömda, vilket kan påverka produktionsprestandan.

Nätverk

Det är avgörande för replikeringsprestanda. Nätverkslatens mellan käll- och måldatabaser måste bedömas genom stresstestning för att säkerställa att det finns tillräckligt med bandbredd för att replikeringen ska gå snabbare. Samma nätverk kan också användas av andra processer eller applikationer. Så kapacitetsplanering måste göras här.

Minne

Det måste finnas tillräckligt med minne tillgängligt för att säkerställa att tillräckligt med data cachelagras för snabbare replikering.

Uppdateringar av källtabeller

Om dataändringarna i källtabellen är tunga måste replikeringssystemet ha förmågan att synkronisera ändringarna till fjärrplatsen/platserna så snart som möjligt. Replikering kommer att skicka ett stort antal synkroniseringsförfrågningar till måldatabasen, vilket kan vara resurskrävande.

Typ av infrastruktur (datacenter eller moln) kan också påverka replikeringsprestanda och kan utgöra utmaningar. Att genomföra övervakning kan också vara en utmaning. Om det finns en fördröjning och viss data saknas i måldatabasen kan det vara svårt att övervaka och det kan inte vara synkront

Hur man implementerar tabellreplikering

Tabellnivåreplikering i PostgreSQL kan implementeras med en mängd olika externa verktyg (kommersiella eller öppen källkod) som finns tillgängliga på marknaden eller genom att använda specialbyggda dataströmmar.

Låt oss ta en titt på några av dessa verktyg, deras funktioner och möjligheter...

Slony

Slony är ett av de mest populära verktygen som används för att asynkront replikera specifika individuella tabeller i realtid från en PostgreSQL-databas till en annan. Detta är ett Perl-baserat verktyg som utför triggerbaserad replikering av dataändringar i en tabell (eller uppsättning tabeller) från en databas på en plats till en annan. Det är ganska pålitligt och det har många års utvecklingshistoria. Även om det är mycket tillförlitligt, eftersom det är ett triggerbaserat verktyg, kan det bli komplicerat att hantera replikeringsinställningarna.

Låt oss titta på några funktioner hos Slony...

Fördelar med att använda Slony

• Stöder replikeringsmetodologi från master till slav eller multipla slavar som hjälper till att förbättra skalbarheten för horisontell läsning. Med andra ord, slavar är inte skrivbara
• Det är möjligt att konfigurera flera slavar till en enda master och stöder även Cascading-replikeringsmetoder
• Stöder övergångs- och failover-mekanismer
• Ett stort antal tabeller kan replikeras i grupper, parallellt
• Vi kan replikera mellan olika större versioner av PostgreSQL-instanser vilket gör Slony till ett utmärkt alternativ för databasuppgraderingar
• Enkel att installera

Nackdelar med att använda Slony

• Stöder inte DDL-replikering
• Vissa schemaändringar kan bryta replikeringen
• Replikeringshändelser loggas i databasen i Slony-specifika loggtabeller som kan utgöra en underhållskostnad.
• Om ett stort antal tabeller med stora datamängder ska replikeras, kan prestanda och underhåll utgöra allvarliga utmaningar
• Eftersom det är en triggerbaserad replikering kan prestandan påverkas

Bucardo

Bucardo är ett annat open source perl-baserat replikeringssystem för PostgreSQL som stöder asynkron replikering av specifik tabelldata mellan två eller flera PostgreSQL-instanser. Det som skiljer Bucardo från Slony är att det också stöder multi-master replikering.

Låt oss titta på olika typer av replikeringsmekanismer som Bucardo hjälper till att implementera...

• Multi-master replikering:Tabeller kan replikeras i båda riktningarna mellan två eller flera PostgreSQL-instanser och transaktionsdata kommer att synkroniseras dubbelriktat
• Master-slave:Data från tabeller i master kommer att replikeras till slav asynkront och slav är tillgänglig för läsoperationer
• Full kopieringsläge (Master-slave):Bucardo -/replikera hela data från mastern till slavnoden genom att ta bort all data från slaven

Fördelar med att använda Bucardo

• Enkel att installera
• Stöder multi-master, master-slave och full copy replikeringslägen
• Den kan användas för att uppgradera databaser
• Replikering kan göras mellan olika PostgreSQL-versioner

Nackdelar med att använda Bucardo

• Eftersom det är en triggerbaserad replikering kan prestandan vara en utmaning
• Schematändringar som att DDL kan bryta replikeringen
• Att replikera ett stort antal tabeller kan innebära underhållskostnader
• Infrastrukturresurserna måste optimeras för replikering med bra prestanda, annars kan konsekvensen inte uppnås.

PostgreSQL logisk replikering

Logisk replikering är en revolutionerande inbyggd funktion i PostgreSQL som hjälper till att replikera enskilda tabeller via WAL-poster. Att vara en WAL-baserad replikering (liknande strömmande replikering) sticker pg logical ut i jämförelse med andra tabellreplikeringsverktyg. Att replikera data via WAL-poster är alltid det mest pålitliga och effektiva sättet att replikera data på nätverket. Nästan alla verktyg på marknaden tillhandahåller triggerbaserad replikering förutom logisk replikering.

Fördelar med att använda PostgreSQL logisk replikering

• Det bästa alternativet när du vill replikera en enskild tabell eller uppsättning tabeller
• Det är ett bra alternativ om kravet är att migrera specifika tabeller från olika databaser till en enda databas (som datalager eller rapporteringsdatabaser) för rapporterings- eller analysändamål
• Inga krångel med utlösare

Nackdelar med att använda PostgreSQL logisk replikering

• Felhantering av WAL-filer / WAL-arkivfiler kan innebära utmaningar för logisk replikering
• Vi kan inte replikera tabeller utan primära eller unika nycklar
• DDL och TRUNCATE replikeras inte
• Replikeringsfördröjning kan öka om WALs tas bort. Det betyder att replikeringen och WAL-hanteringen måste komplettera varandra för att säkerställa att replikeringen inte går sönder
• Stora objekt kan inte replikeras

Här är några fler resurser som hjälper dig att bättre förstå PostgreSQL Logical Replication och skillnaderna mellan den och strömmande replikering.

Utländska dataomslag

Även om Foreign Data Wrappers faktiskt inte replikerar data, ville jag lyfta fram denna funktion i PostgreSQL eftersom det kan hjälpa DBA:er att uppnå något som liknar replikering utan att faktiskt replikera data. Detta innebär att data inte replikeras från källa till mål och data kan nås av applikationer från måldatabasen. Måldatabasen har bara en tabellstruktur med en länk som innehåller värd- och databasdetaljer för källtabellen, och när applikationen frågar efter måltabellen överförs data från källdatabasen till måldatabasen som liknar Databas Links. Om FDW:er kan hjälpa dig kan du helt undvika överkostnaderna med att replikera data över nätverket. Många gånger hamnar vi i en situation där rapporter kan köras på en avlägsen måldatabas utan att data behöver finnas fysiskt närvarande.

FDW:er är ett utmärkt alternativ i följande situationer -

• Om du har små och statiska tabeller i källdatabasen är det inte värt att replikera data över
• Kan vara mycket fördelaktigt, om du har riktigt stora tabeller i källdatabasen och du kör sammanställda frågor på måldatabasen.

Fördelar med att använda utländska datainpackningar

• Replicering av data kan helt undvikas vilket kan spara tid och resurser
• Enkel att implementera
• Data som hämtas är alltid den senaste
• Inget underhåll över huvud taget

Nackdelar med att använda utländska datainpackningar

• Strukturella förändringar i källtabellen kan påverka applikationsfunktionaliteten på måldatabasen
• Literar starkt på nätverket och kan ha betydande nätverkskostnader beroende på vilken typ av rapporter som körs
• Prestanda overhead förväntas när frågorna exekveras ett flertal gånger eftersom varje gång frågan exekveras måste data hämtas över nätverket från källdatabasen och kan även utgöra prestandaoverhead på källdatabasen
• All belastning på källan kan påverka prestandan för applikationer på måldatabasen

Slutsats

• Replicering av tabeller kan tjäna olika viktiga syften för företag
• Kan stödja distribuerad parallell sökning i distribuerade miljöer
• Att implementera synkront är nästan omöjligt
• Infrastrukturen måste vara tillräckligt kapaciterad vilket innebär kostnader
• Ett bra alternativ för att bygga en integrerad centraliserad databas för rapporterings- och analysändamål