sql >> Database teknologi >  >> RDS >> PostgreSQL

Top PG Clustering High Availability Solutions til PostgreSQL

Hvis dit system er afhængig af PostgreSQL, og du leder efter klyngeløsninger til High Availability, vil vi gerne på forhånd fortælle dig, at det er en kompleks opgave, men ikke umulig at opnå.

I betragtning af dine krav til fejltolerance er her nogle klyngeløsninger med høj tilgængelighed at vælge imellem, som kan hjælpe.

PostgreSQL understøtter ikke indbygget nogen multi-master klyngeløsning som MySQL eller Oracle. Ikke desto mindre tilbyder mange kommercielle produkter og fællesskabsprodukter denne implementering, inklusive replikering og belastningsbalancering til PostgreSQL.

For at starte, lad os gennemgå nogle grundlæggende begreber:

Hvad er høj tilgængelighed?

Høj tilgængelighed refererer til den tid, en tjeneste er tilgængelig og er normalt defineret af en virksomheds aftalte ydeevne.

Redundans er grundlaget for høj tilgængelighed; i tilfælde af en hændelse kan du fortsætte med at betjene og få adgang til systemer uden problemer.

Kontinuerlig gendannelse

Når en hændelse opstår, hvis du skal gendanne en sikkerhedskopi og derefter anvende WAL-logfilerne (Write-Ahead Logging), ville genoprettelsestiden være meget høj, og den ville ikke være meget tilgængelig.

Men hvis du har sikkerhedskopierne og logfilerne arkiveret på en beredskabsserver, kan du anvende logfilerne, efterhånden som de ankommer. Hvis logfilerne sendes og anvendes hvert minut, ville beredskabsbasen være i en kontinuerlig genopretning og ville have en forældet tilstand til produktion på højst et minut.

Standby-databaser

Idéen med en standby-database er at beholde en kopi af en produktionsdatabase, der altid har de samme data og er klar til at blive brugt i tilfælde af en hændelse.

Der er flere måder at klassificere en standby-database på.

Af arten af ​​replikationen:

  • Fysiske standbys:Diskblokke kopieres.

  • Logiske standbys:Streaming af dataændringerne.

Ved synkroniteten af ​​transaktionerne:

  • Asynkron:Der er mulighed for tab af data.

  • Synkron:Der er ingen mulighed for tab af data; Forpligtelserne i masteren venter på svar fra standby.

Ved brug:

  • Varme standbys:De understøtter ikke forbindelser.

  • Hot standbys:Understøtter skrivebeskyttede forbindelser.

Klynger

En klynge er en gruppe værter, der arbejder sammen og ses som én. Dette giver mulighed for at opnå horisontal skalerbarhed og mulighed for at behandle mere arbejde ved at tilføje servere.

Det kan modstå svigt af en node og fortsætte med at arbejde gennemsigtigt. Afhængigt af hvad der deles, er der to klyngemodeller:

  • Delt lager:Alle noder får adgang til det samme lager med de samme oplysninger.

  • Delt intet:Hver node har sit eget lager, som muligvis har samme information som den anden. noder, afhængigt af strukturen af ​​vores system.

Lad os nu gennemgå nogle af de klyngemuligheder, vi har i PostgreSQL.

Distribueret replikeret blokeringsenhed

DRBD er et Linux-kernemodul, der implementerer synkron blokreplikering ved hjælp af netværket. Den implementerer faktisk ikke en klynge og håndterer ikke failover eller overvågning. Du har brug for komplementær software til det, for eksempel Corosync + Pacemaker + DRBD.

Eksempel:

  • Corosync:Håndterer beskeder mellem værter.

  • Pacemaker:Starter og stopper tjenester og sikrer, at de kun kører på én vært.

  • DRBD:Synkroniserer data på niveau med blokenheder.

ClusterControl

ClusterControl er en agentfri administrations- og automatiseringssoftware til databaseklynger. Det hjælper med at implementere, overvåge, administrere og skalere din databaseserver/-klynge direkte fra dens brugergrænseflade. Den kan håndtere de fleste administrationsopgaver, der kræves for at vedligeholde databaseservere eller klynger.

Med ClusterControl kan du:

  • Implementer selvstændige, replikerede eller klyngede databaser på den teknologistak, du vælger.

  • Automatiser failovers, gendannelse og daglige opgaver ensartet på tværs af polyglot-databaser og dynamiske infrastrukturer.

  • Opret komplette eller trinvise sikkerhedskopier manuelt eller planlæg dem.

  • Foretag samlet og omfattende realtidsovervågning af hele din database og serverinfrastruktur.

  • Tilføj eller fjern nemt en node med en enkelt handling.

  • Klon din klynge til en anden datacenter-/skyudbyder

Hvis du har en hændelse på PostgreSQL, kan din Standby-knude automatisk forfremmes til Primær.

Det er et komplet værktøj, der tilbyder fuld-ops livscyklusstyring og automatisering gennem en enkelt rude. ClusterControl giver også en gratis 30-dages prøveperiode, så du kan evaluere den uden bindinger.

Rubyrep

Rubyrep er en løsning, der giver asynkron, multi-master, multi-platform replikering (implementeret i Ruby eller JRuby) og multi-DBMS (MySQL eller PostgreSQL).

Den er baseret på triggere, og den understøtter ikke DDL, brugere eller bevillinger. Enkelheden i brug og administration er dens primære mål.

Nogle funktioner omfatter:

  • Simpel konfiguration

  • Simpel installation

  • Platformuafhængig, borddesign uafhængig.

Pgpool-II

Pgpool-II er en middleware, der fungerer mellem PostgreSQL-servere og en PostgreSQL-databaseklient.

Nogle funktioner omfatter:

  • Forbindelsespulje

  • replikering

  • Belastningsbalancering

  • Automatisk failover

  • Parallelle forespørgsler

Det kan konfigureres oven på streamingreplikering:

Bucardo

Bucardo tilbyder asynkron cascading master-slave-replikering, rækkebaseret, ved hjælp af triggere og kø i databasen, og asynkron master-master-replikering, rækkebaseret, ved hjælp af triggere og tilpasset konfliktløsning.

Bucardo kræver en dedikeret database og kører som en Perl-dæmon, der kommunikerer med denne database og alle andre databaser involveret i replikeringen. Det kan køre som multi-master eller multi-slave.

Master-slave-replikering involverer en eller flere kilder, der går til et eller flere mål. Kilden skal være PostgreSQL, men målene kan være PostgreSQL, MySQL, Redis, Oracle, MariaDB, SQLite eller MongoDB.

Nogle funktioner omfatter:

  • Belastningsbalancering

  • Slaver er ikke begrænset og kan skrives

  • Delvis replikering

  • Replikering efter behov (ændringer kan skubbes automatisk eller efter ønske)

  • Slaver kan "forvarmes" for hurtig opsætning

Ulemper:

  • Kan ikke håndtere DDL

  • Kan ikke håndtere store objekter

  • Kan ikke trinvist replikere tabeller uden en unik nøgle

  • Virker ikke på versioner ældre end Postgres 8

Postgres-XC

Postgres-XC er et open source-projekt, der skal levere en skriveskalerbar, synkron, symmetrisk og gennemsigtig PostgreSQL-klyngeløsning. Det er en samling af tæt koblede databasekomponenter, der kan installeres i mere end én hardware eller virtuel maskine.

Skrive-skalerbar betyder, at Postgres-XC kan konfigureres med så mange databaseservere, du vil, og håndtere mange flere skrivninger (opdatering af SQL-sætninger) sammenlignet med, hvad en enkelt databaseserver kan gøre.

Du kan have mere end én databaseserver, som klienter opretter forbindelse til, hvilket giver en enkelt, ensartet klyngedækkende visning af databasen.

Enhver databaseopdatering fra enhver databaseserver er umiddelbart synlig for alle andre transaktioner, der kører på forskellige mastere.

Transparent betyder, at du ikke behøver at bekymre dig om, hvordan dine data lagres på mere end én databaseserver internt.

Du kan konfigurere Postgres-XC til at køre på flere servere. Dine data lagres på en distribueret måde, partitioneret eller replikeret, som du vælger for hver tabel. Når du udsteder forespørgsler, bestemmer Postgres-XC, hvor måldataene er gemt, og sender tilsvarende forespørgsler til servere, der indeholder måldataene.

Citus

Citus er en drop-in-erstatning for PostgreSQL med indbyggede funktioner med høj tilgængelighed, såsom auto-sharding og replikering. Citus skærer din database og replikerer flere kopier af hvert skær på tværs af klyngen af ​​vareknudepunkter. Hvis en node i klyngen bliver utilgængelig, omdirigerer Citus transparent alle skrivninger eller forespørgsler til en af ​​de andre noder, som rummer en kopi af det berørte shard.

Nogle funktioner omfatter:

  • Automatisk logisk sønderdeling

  • Indbygget replikering

  • Datacenterbevidst replikering til katastrofegendannelse

  • Fejltolerance i midten af ​​forespørgsler med avanceret belastningsbalancering

Du kan øge oppetiden for dine realtidsapplikationer drevet af PostgreSQL og minimere indvirkningen af ​​hardwarefejl på ydeevnen. Du kan opnå dette med indbyggede værktøjer med høj tilgængelighed, der minimerer dyre og fejlbehæftede manuel indgreb.

PostgresXL

PostgresXL er en delt-intet, multi-master klyngeløsning, der transparent kan distribuere en tabel på et sæt noder og udføre forespørgsler parallelt med disse noder. Den har en ekstra komponent kaldet Global Transaction Manager (GTM) for at give et globalt ensartet overblik over klyngen.

PostgresXL er en horisontalt skalerbar open source SQL-databaseklynge, fleksibel nok til at håndtere varierende databasearbejdsbelastninger:

  • OLTP skriveintensive arbejdsbelastninger

  • Business Intelligence, der kræver MPP-parallelisme

  • Operational datastore

  • Nøgleværdilager

  • GIS Geospatial

  • Miljøer med blandet arbejdsbelastning

  • Multi-lejer-udbyder-hostede miljøer

Komponenter:

  • Global Transaction Monitor (GTM):Global Transaction Monitor sikrer ensartet transaktion i hele klyngen.

  • Koordinator:Koordinatoren administrerer brugersessionerne og interagerer med GTM og dataknuderne.

  • Dataknude:Dataknuden er det sted, hvor de faktiske data er gemt.

Afslutning

Der er mange flere tilgængelige produkter til at implementere dit høje tilgængelighedsmiljø for PostgreSQL, men du skal være forsigtig med:

  • Nye produkter, ikke tilstrækkeligt testet

  • Afsluttede projekter

  • Begrænsninger

  • Licensomkostninger

  • Meget komplekse implementeringer

  • Usikre løsninger

Når du vælger hvilken løsning du vil bruge, skal du også tage hensyn til din infrastruktur. Hvis du kun har én applikationsserver, uanset hvor meget du har konfigureret den høje tilgængelighed af databaserne, er du utilgængelig, hvis applikationsserveren svigter. Du skal analysere de enkelte fejlpunkter i infrastrukturen godt og prøve at løse dem.

Med disse punkter i betragtning kan du finde en klyngeløsning med høj tilgængelighed, der tilpasser sig dine behov og krav, uden hovedpine. Hvis du leder efter yderligere HA-ressourcer til din PG-database, så tjek dette indlæg om implementering af PostgreSQL for høj tilgængelighed.

For at holde dig opdateret om databasestyringsløsninger og bedste praksis, følg os på Twitter og LinkedIn og abonner på vores nyhedsbrev.


  1. Brug af OAuth til at godkende din ODBC-forbindelse til Salesforce.com

  2. Sådan omdannes en database i MySQL Workbench

  3. Felttyper og anvendelser i Access 2019-databaser

  4. Kaldning af en lagret funktion (der returnerer et array af en brugerdefineret type) i oracle på tværs af et databaselink