I PostgreSQL kan du växla en databas från den primära servern till standby-rollen, såväl som från standby-servern till den primära. Detta är känt som en databasövergång eller failover. I händelse av en katastrof kan en kontrollerad failover alltid göras manuellt. Men många kunder föredrar automatiserad failover framför manuell failover eftersom det minskar mängden stillestånd och minimerar eller till och med eliminerar dataförlust.

Bygga PostgreSQL-kluster med hög tillgänglighet med sanna experter

CYBERTEC har 20 års erfarenhet inom PostgreSQL-databaskluster och failover. Vi har byggt kluster med en mängd olika tekniker inklusive, men inte begränsat till:

  • Patroni och vipmanager (”Virtual IP Manager”)
  • Linux HA (hjärtslag, pacemaker, corosync, etc.)
  • repmgr
  • Solaris-klustret

Clustering PostgreSQL med Patroni och vipmanager

CYBERTEC rekommenderar en kombination av Patroni och vipmanager när det gäller failover och hög tillgänglighet för din PostgreSQL-databas. Fördelarna med detta är den enkla realiserbarheten och den enkla hanteringen.
Lär dig mer om den här professionella installationen och hur CYBERTEC stöder dig med konfigurationen.

clustering and failover

Andra lösningar på PostgreSQL-replikering, kluster och failover

Patronis enkelhet ger den en verklig fördel jämfört med mer traditionella lösningar. Men många kunder där ute använder fortfarande traditionella lösningar, som naturligtvis stöds fullt ut av CYBERTEC.

Linux HA (pacemaker, corosync, etc.)

Linux HA är en allmän lösning för hög tillgänglighet eftersom den kan användas för att klustera i stort sett alla typer av programvara. Denna typ av flexibilitet är också dess största svaghet eftersom den introducerar mycket komplexitet, vilket inte nödvändigtvis är önskvärt.

Utöver detta har Patroni gjorts speciellt för PostgreSQL så att det kan använda inbyggd funktionalitet mycket bättre än Linux HA kan.

Linux HA är dock fortfarande en bra lösning och erbjuder en rik uppsättning funktioner inklusive:

  • Upptäcker och återställer maskin- och applikationsfel
  • Stöder konfigurationer för redundans
  • Stöder både kvoraterade och resursdrivna kluster
  • Ger konfigurerbara strategier för att hantera kvorumförlust (= för många maskiner förlorades)
  • Stöder applikationsstart / avstängningsbeställning, oavsett vilken eller vilka maskiner applikationerna är på
  • Stöder applikationer som måste / får köras på samma maskin
  • Stöder applikationer som måste vara aktiva på flera maskiner
  • Stöder applikationer med flera lägen (t.ex. primär / standby)

Linux HA tillåter PostgreSQL att integreras med andra komponenter som krävs för att vara tillgängliga dygnet runt.

pgpool-II och pgbouncer

När vi pratar om separata pooling-servrar i PostgreSQL-sammanhang sticker två produkter ut – PgBouncer och pgpool-II. Båda verktygen används ofta i samband med PostgreSQL-kluster och sammankopplingspooling.
Våra databasexperter har skrivit om pgpool-II och pgbouncer. För mer information, kolla in följande blogginlägg >>.

Generellt rekommenderar vi Patroni över pgpool-II eftersom det är mindre invasivt.

Legacy: Slony and Skytools (londiste)

Slony utvecklades runt släppdatumet för PostgreSQL 7.4. Den stöder trigger-baserad replikering. Innan introduktionen av transaktionsloggbaserade replikeringar var triggers i stort sett det enda sättet att replikera data till en uppsättning fjärrvärdar.

Skytools (nämligen ett verktyg som heter londiste) står inför problem som liknar Slony och anses därför vara föråldrade. Om du är intresserad av att replikera enstaka tabeller, överväg att kolla in ”CREATE PUBLICATION” och ”CREATE SUBSCRIPTION”, som introducerades i PostgreSQL 10.0.

Om du använder Slony och är angelägen om att migrera eller bara är intresserad av att lära dig om ny teknik, kontakta oss idag.

Professionell hjälp

Vill du veta mer om kluster och failover?
Kontakta oss idag för att få ditt personliga erbjudande från CYBERTEC. Vi erbjuder snabb leverans, professionell hantering och 20 års erfarenhet av PostgreSQL.

Kontakta oss