Sådan replikeres PostgreSQL-data til eksterne websteder

I et travlt databasemiljø med større databaser er behovet for datareplikering i realtid en almindelig begivenhed. Applikationer har ofte brug for, at produktionsdataene replikeres i realtid til fjerntliggende steder til analyse og andre kritiske forretningsdriftsbehov.

DBA'er skal også sikre, at dataene replikeres kontinuerligt til de fjerntliggende steder for at opfylde forskellige krav. Disse krav er dog ikke altid at replikere hele databasen; der kan også være behov for kun at replikere en delmængde af dataene (såsom en tabel eller et sæt tabeller eller data fra flere tabeller ved hjælp af en SQL til analyse, rapportering osv.)

I denne blog vil vi fokusere på, hvordan man replikerer tabeller til eksterne databaser i realtid.

Hvad er replikering på tabelniveau?

Replikering på tabelniveau er mekanismen til at replikere data fra en specifik tabel eller et sæt tabeller fra en database (kilde) til en anden database (mål), der hostes eksternt i et distribueret miljø. Replikering på tabelniveau sikrer, at tabeldata distribueres kontinuerligt og forbliver ensartet på tværs af replikerede (mål)websteder.

Hvorfor bruge replikering på tabelniveau?

Replikering på tabelniveau er et væsentligt behov i større, komplekse, meget distribuerede miljøer. Efter min erfaring var der altid behov for at replikere et sæt tabeller fra en produktionsdatabase til et datavarehus til rapporteringsformål. Dataene skal replikeres løbende for at sikre, at rapporterne får de seneste data. I kritiske miljøer kan forældede data ikke tolereres, så de dataændringer, der sker i produktionen, skal replikeres øjeblikkeligt til målstedet. Dette kan være en reel udfordring for DBA's at skulle forudsige forskellige faktorer for at sikre en effektiv og smidig tabelreplikering.

Lad os se på nogle krav, som replikering på tabelniveau løser:

• Rapporterne kan køre på en database i et andet miljø end produktion, såsom data warehousing
• Et distribueret databasemiljø med distribuerede applikationer, der udtrækker data fra flere websteder. I tilfælde af distribuerede web- eller mobilapplikationer bør kopien af ​​de samme data være tilgængelig flere steder for at opfylde forskellige applikationsbehov, som replikering på tabelniveau kunne være en god løsning for
• Lønapplikationer, der kræver, at data fra forskellige databaser placeret på forskellige geografisk distribuerede datacentre eller cloud-instanser er tilgængelige i en centraliseret database

Forskellige faktorer, der påvirker replikering på tabelniveau - Hvad skal man kigge efter

Som vi nævnte ovenfor, skal DBA'er tage højde for en række realtidskomponenter og faktorer for at designe og implementere et effektivt replikeringssystem på tabelniveau.

Tabelstruktur

Den type datatabel, der er imødekommende, har stor indflydelse på replikeringsydelsen. Hvis tabellen rummer en BYTEA-kolonne med større binære data, kan replikeringsydelsen blive ramt. Effekten af ​​replikering på netværk, CPU og disk skal vurderes omhyggeligt.

Datastørrelse

Hvis tabellen, der skal migreres, er for stor, vil den indledende datamigrering tage ressourcer og tid, DBA'er skal sikre, at produktionsdatabasen ikke påvirkes.

Infrastrukturressourcer

Infrastrukturen skal have tilstrækkelige ressourcer til at sikre, at der kan bygges et pålideligt og stabilt replikeringssystem. Hvilke infrastrukturkomponenter skal tages i betragtning?

CPU'er

Datareplikering er stærkt afhængig af CPU'er. Når du replikerer fra produktion, må CPU'er ikke blive opbrugt, hvilket kan påvirke produktionsydelsen.

Netværk

Det er afgørende for replikeringsydelsen. Netværksforsinkelse mellem kilde- og måldatabase(r) skal vurderes ved stresstest for at sikre, at der er nok båndbredde til, at replikeringen kan være hurtigere. Det samme netværk kan også blive brugt op af andre processer eller applikationer. Så kapacitetsplanlægning skal laves her.

Hukommelse

Der skal være tilstrækkelig hukommelse tilgængelig for at sikre, at nok data er cachelagret til hurtigere replikering.

Kildetabelopdateringer

Hvis dataændringerne på kildetabellen er tunge, skal replikeringssystemet have evnen til at synkronisere ændringerne til det eller de eksterne websteder så hurtigt som muligt. Replikering vil ende med at sende et stort antal synkroniseringsanmodninger til måldatabasen, hvilket kan være ressourcekrævende.

Infrastrukturtype (datacentre eller cloud) kan også påvirke replikeringsydelsen og udgøre udfordringer. Implementering af overvågning kan også være en udfordring. Hvis der er en forsinkelse, og visse data mangler på måldatabasen, kan det være svært at overvåge, og det kan ikke være synkront

Sådan implementeres tabelreplikering

Replikering på tabelniveau i PostgreSQL kan implementeres ved hjælp af en række eksterne værktøjer (kommercielle eller open source), som er tilgængelige på markedet eller ved at bruge specialbyggede datastrømme.

Lad os tage et kig på nogle af disse værktøjer, deres funktioner og muligheder...

Slony

Slony er et af de mest populære værktøjer, der bruges til asynkront at replikere specifikke individuelle tabel eller tabeller i realtid fra en PostgreSQL-database til en anden. Dette er et Perl-baseret værktøj, som udfører triggerbaseret replikering af dataændringer af en tabel (eller et sæt tabeller) fra en database på et sted til et andet. Det er ret pålideligt, og det har mange års udviklingshistorie. Selvom det er meget pålideligt, da det er et trigger-baseret værktøj, kan det blive komplekst at administrere replikeringsopsætningerne.

Lad os se på nogle af Slony's muligheder...

Fordele ved at bruge Slony

• Understøtter master-til-slave- eller multiple-slavs-replikeringsmetodologi, som hjælper med at forbedre horisontal læseskalerbarhed. Med andre ord er slaver ikke skrivbare
• Konfiguration af flere slaver til en enkelt master er muligt og understøtter også Cascading-replikeringsmetodologi
• Understøtter switchover- og failover-mekanismer
• Et stort antal tabeller kan replikeres i grupper parallelt
• Vi kan replikere mellem forskellige større versioner af PostgreSQL-instanser, hvilket gør Slony til en fantastisk mulighed for databaseopgraderinger
• Simpelt at installere

Ulemper ved at bruge Slony

• Understøtter ikke DDL-replikering
• Visse skemaændringer kan bryde replikeringen
• Replikeringshændelser logges i databasen i Slony-specifikke logtabeller, som kan udgøre en vedligeholdelsesomkostning.
• Hvis et stort antal tabeller med store datasæt skal replikeres, kan ydeevne og vedligeholdelse udgøre alvorlige udfordringer
• Da er en triggerbaseret replikering, kan ydeevnen blive påvirket

Bucardo

Bucardo er et andet open source perl-baseret replikeringssystem til PostgreSQL, som understøtter asynkron replikering af specifikke tabeldata mellem to eller flere PostgreSQL-instanser. Det, der gør Bucardo anderledes end Slony, er, at den også understøtter multi-master replikering.

Lad os se på forskellige typer replikeringsmekanismer, som bucardo hjælper med at implementere...

• Multi-master replikering:Tabeller kan replikeres i begge retninger mellem to eller flere PostgreSQL-instanser, og transaktionsdataene vil blive synkroniseret tovejs
• Master-slave:Data fra tabeller i master vil blive replikeret til slave asynkront, og slave er tilgængelig for læseoperationer
• Fuld kopitilstand (Master-slave):Bucardo -/repliker alle data fra masteren til slavenoden ved at slette alle data fra slaven

Fordele ved at bruge Bucardo

• Simpelt at installere
• Understøtter multi-master, master-slave og fuld kopi replikeringstilstande
• Den kan bruges til at opgradere databaser
• Replikering kan udføres mellem forskellige PostgreSQL-versioner

Ulemper ved at bruge Bucardo

• Da er en trigger-baseret replikering, kan ydeevnen være en udfordring
• Skemaændringer som DDL'er kan bryde replikeringen
• Replikation af et stort antal tabeller kan medføre vedligeholdelsesomkostninger
• Infrastrukturressourcerne skal optimeres til replikering med god effektivitet, ellers kan konsistensen ikke opnås.

Logisk PostgreSQL-replikering

Logisk replikering er en revolutionerende indbygget funktion i PostgreSQL, som hjælper med at replikere individuelle tabeller via WAL-poster. At være en WAL-baseret replikering (ligner Streaming Replication) skiller pg logical sig ud sammenlignet med andre tabelreplikeringsværktøjer. Replikering af data via WAL-registreringer er altid den mest pålidelige og effektive måde at replikere data på netværket. Næsten alle værktøjerne på markedet giver trigger-baseret replikering undtagen logisk replikering.

Fordele ved at bruge PostgreSQL logisk replikering

• Den bedste mulighed, når du ønsker at replikere en enkelt tabel eller et sæt tabeller
• Det er en god mulighed, hvis kravet er at migrere specifikke tabeller fra forskellige databaser til én enkelt database (såsom data warehousing eller rapporteringsdatabaser) til rapportering eller analytiske formål
• Intet besvær med udløsere

Ulemper ved at bruge PostgreSQL logisk replikering

• Fejlhåndtering af WAL-filer / WAL-arkivfiler kan udgøre udfordringer for logisk replikering
• Vi kan ikke replikere tabeller uden primære eller unikke nøgler
• DDL'er og TRUNCATE replikeres ikke
• Replikeringsforsinkelse kan stige, hvis WAL'erne fjernes. Det betyder, at replikeringen og WAL-styringen skal komplementere hinanden for at sikre, at replikeringen ikke går i stykker
• Store objekter kan ikke replikeres

Her er nogle flere ressourcer til at hjælpe dig med bedre at forstå PostgreSQL logisk replikering og forskellene mellem det og streaming replikering.

Udenlandske dataindpakninger

Selvom Foreign Data Wrappers faktisk ikke replikerer dataene, ville jeg fremhæve denne funktion ved PostgreSQL, fordi det kan hjælpe DBA'er med at opnå noget, der ligner replikering uden faktisk at replikere dataene. Dette betyder, at dataene ikke replikeres fra kilde til mål, og dataene kan tilgås af applikationer fra måldatabasen. Måldatabasen har kun en tabelstruktur med et link, der indeholder værts- og databasedetaljer for kildetabellen, og når applikationen forespørger måltabellen, trækkes dataene over fra kildedatabasen til måldatabasen svarende til Database Links. Hvis FDW'er kan hjælpe, så kan du helt undgå omkostningerne ved at replikere dataene over netværket. Mange gange kommer vi i en situation, hvor rapporter kan udføres på en ekstern måldatabase uden at have behov for, at dataene er fysisk til stede.

FDW'er er en god mulighed i følgende situationer -

• Hvis du har små og statiske tabeller i kildedatabasen, så er det ikke rigtig værd at replikere dataene over
• Kan være rigtig fordelagtig, hvis du har virkelig store tabeller i kildedatabasen, og du kører samlede forespørgsler på måldatabasen.

Fordele ved at bruge udenlandske dataindpakninger

• Replikation af data kan helt undgås, hvilket kan spare tid og ressourcer
• Simpel at implementere
• Data, der trækkes over, er altid de seneste
• Ingen vedligeholdelse over hovedet

Ulemper ved at bruge udenlandske dataindpakninger

• Strukturelle ændringer på kildetabellen kan påvirke applikationsfunktionaliteten på måldatabasen
• Stærkt afhængig af netværket og kan have betydelige netværksomkostninger afhængigt af typen af ​​rapporter, der køres
• Ydeevneoverhead forventes, når forespørgslerne udføres flere gange, da hver gang forespørgslen udføres, skal dataene trækkes over netværket fra kildedatabasen og kan også udgøre ydeevneoverhead på kildedatabasen
• Enhver belastning af kilden kan påvirke ydeevnen af ​​applikationer på måldatabasen

Konklusion

• Replikation af tabeller kan tjene forskellige kritiske formål for virksomheden
• Kan understøtte distribueret parallel forespørgsel i distribuerede miljøer
• Implementering af synkron er næsten umulig
• Infrastruktur skal være tilstrækkeligt kapacitet, hvilket medfører omkostninger
• En fantastisk mulighed for at bygge en integreret centraliseret database til rapportering og analytiske formål