En expertguide till Slony-replikering för PostgreSQL

Vad är Slony?

Slony-I (hädanefter kallad "Slony") är ett replikeringssystem från tredje part för PostgreSQL som går tillbaka till före version 8.0, vilket gör det till ett av de äldre alternativen för replikering som finns tillgängliga. Den fungerar som en triggerbaserad replikeringsmetod som är en "master till flera slavar"-lösning.

Slony fungerar genom att installera triggers på varje tabell som ska replikeras, på både master och slavar, och varje gång tabellen får en INSERT, UPDATE eller DELETE, loggar den vilken post som ändras och vad ändringen är. Utomstående processer, kallade "slon-demoner", ansluter till databaserna som vilken annan klient som helst och hämtar ändringarna från mastern och spelar sedan upp dem på alla slavnoder som prenumererar på mastern. I en välpresterande replikeringsinställning är denna asynkrona replikering kan förväntas vara var som helst med 1 till 20 sekunder efter mastern.

När detta skrivs har den senaste versionen av Slony version 2.2.6 och stöder PostgreSQL 8.3 och högre. Supporten fortsätter till denna dag med mindre uppdateringar, men om en framtida version av PostgreSQL ändrar grundläggande funktionalitet för transaktioner, funktioner, triggers eller andra kärnfunktioner, kan Slony-projektet besluta att avbryta stora uppdateringar för att stödja sådana drastiska nya tillvägagångssätt.

PostgreSQLs maskot är en elefant känd som "Slonik", vilket är ryska för "liten elefant". Eftersom detta replikeringsprojekt handlar om att många PostgreSQL-databaser replikerar med varandra, används det ryska ordet för elefanter (plural):Slony.

Koncept

• Kluster:En instans av Slony-replikering.
• Nod:En specifik PostgreSQL-databas som Slony-replikeringsnod, som fungerar som antingen master eller slav för en replikeringsuppsättning.
• Replikeringsuppsättning:En grupp tabeller och/eller sekvenser som ska replikeras.
• Prenumeranter:En prenumerant är en nod som prenumererar på en replikeringsuppsättning och tar emot replikeringshändelser för alla tabeller och sekvenser inom den uppsättningen från masternoden.
• Slony Daemons:De huvudsakliga arbetarna som kör replikering, en Slony-demon startas för varje nod i replikeringsuppsättningen och upprättar olika anslutningar till noden som den hanterar, såväl som masternoden.

Hur det används

Slony installeras antingen via källa eller genom PGDG (PostgreSQL Global Development Group) arkiv som är tillgängliga för Red Hat- och Debianbaserade Linux-distributioner. Dessa binärer bör installeras på alla värdar som kommer att innehålla antingen en master- eller slavnod i replikeringssystemet.

Efter installationen ställs ett Slony-replikeringskluster upp genom att utfärda några kommandon med hjälp av "slonik"-binären. 'slonik' är ett kommando med en enkel men unik syntax för att initiera och underhålla ett slänt kluster. Det är huvudgränssnittet för att utfärda kommandon till det körande Slony-klustret som ansvarar för replikering.

Gränssnitt med Slony kan göras genom att antingen skriva anpassade slonik-kommandon eller kompilera slony med flaggan --with-perltools, som tillhandahåller "altperl"-skripten som hjälper till att generera dessa slonik-skript som behövs.

Skapa ett Slony-replikeringskluster

Ett "replikeringskluster" är en samling databaser som är en del av replikering. När du skapar ett replikeringskluster måste ett init-skript skrivas som definierar följande:

• Namnet på Slony-klustret som önskas
• Anslutningsinformationen för varje noddel av replikeringen, var och en med ett oföränderligt nodnummer.
• Visar alla tabeller och sekvenser som ska replikeras som en del av en "replikeringsuppsättning".

Ett exempelskript finns i Slonys officiella dokumentation.

När den körs kommer slonik att ansluta till alla definierade noder och skapa Slony-schemat på var och en. När Slony-demonerna startar kommer de att rensa ut all data i de replikerade tabellerna på slaven (om det finns några), och kopiera över all data från mastern till slaven/slavarna. Från den tidpunkten kommer demonerna kontinuerligt att replikera ändringar som registrerats på mastern till alla prenumererade slavar.

Smarta konfigurationer

Medan Slony från början är ett Master-to-Multiple-Slave-replikeringssystem, och huvudsakligen har använts på det sättet, finns det flera andra funktioner och smarta användningsområden som gör Slony mer användbar än en enkel replikeringslösning. Den mycket anpassningsbara karaktären hos Slony håller den relevant för en mängd olika situationer för administratörer som kan tänka utanför ramarna.

Kaskadreplikering

Slony-noder kan ställas in för att kaskadreplikera ner i en kedja av olika noder. Om masternoden är känd för att ta en extremt tung belastning, kommer varje ytterligare slav att öka den belastningen något. Med kaskadreplikering kan en enskild slavnod ansluten till mastern konfigureras som en "vidarebefordrande nod", som sedan kommer att ansvara för att skicka replikeringshändelser till fler slavar, vilket håller belastningen på masternoden till ett minimum.

Databehandling på en slavnod

Till skillnad från PostgreSQL:s inbyggda replikering är slavnoderna faktiskt inte "read only", bara tabellerna som replikeras är låsta som "read only". Detta innebär att på en slavnod kan databearbetning ske genom att skapa nya tabeller som inte ingår i replikeringen för att inrymma bearbetad data. Tabeller som ingår i replikeringen kan också ha anpassade index skapade beroende på åtkomstmönstren som kan skilja sig från slaven och mastern.

Skrivskyddade tabeller på slavarna kan fortfarande ha anpassade triggerbaserade funktioner exekverade på dataändringar, vilket möjliggör mer anpassning med data.

Minsta uppgraderingar av driftstopp

Att uppgradera större versioner av PostgreSQL kan vara extremt tidskrävande. Beroende på datastorlek och tabellantal kan en uppgradering inklusive "analys"-processen efter uppgraderingen ta flera dagar till och med. Eftersom Slony kan replikera data mellan PostgreSQL-kluster av olika versioner, kan den användas för att ställa in replikering mellan en äldre version som master och en nyare version som slav. När uppgraderingen ska ske, utför helt enkelt en "switchover", vilket gör slaven till den nya mastern, och den gamla mastern blir slav. När uppgraderingen har markerats som en framgång, avveckla Slony-replikeringsklustret och stänger av den gamla databasen.

Hög tillgänglighet med frekvent serverunderhåll

Liksom den minimala stilleståndstiden för uppgraderingar kan serverunderhåll enkelt utföras utan driftstopp genom att utföra en "växling" mellan två eller flera noder, vilket gör att en slav kan startas om med uppdateringar/annat underhåll. När slaven kommer tillbaka online kommer den att återansluta till replikeringsklustret och fånga upp all replikerad data. Slutanvändare som ansluter till databasen kan få långa transaktioner avbrutna, men själva driftstoppet skulle vara sekunder när övergången sker, snarare än hur lång tid det tar att starta om/uppdatera värden.

Loggleverans

Även om det sannolikt inte är en populär lösning, kan en Slony-slav ställas in som en "loggsändningsnod", där all data den tar emot genom replikering kan skrivas till SQL-filer och skickas. Detta kan användas av en mängd olika skäl, som att skriva till en extern enhet och transportera till en slavdatabas manuellt, och inte över ett nätverk, komprimeras och förvaras arkiverad för framtida säkerhetskopior, eller till och med låta ett externt program analysera SQL-filerna och ändra innehållet.

Dela flera databasdata

Eftersom valfritt antal tabeller kan replikeras efter behag, kan Slony-replikeringsuppsättningar ställas in för att dela specifika tabeller mellan databaser. Även om liknande åtkomst kan uppnås genom Foreign Data Wrappers (som har förbättrats i de senaste PostgreSQL-utgåvorna), kan det vara en bättre lösning att använda Slony beroende på användningen. Om en stor mängd data behövs för att hämtas från en värd till en annan, innebär det att Slony replikerar denna data att den nödvändiga informationen redan finns på den begärande noden, vilket eliminerar lång överföringstid.

Försenad replikering

Vanligtvis önskas replikeringen vara så snabb som möjligt, men det kan finnas vissa scenarier där en fördröjning önskas. Slon-demonen för en slavnod kan konfigureras med ett lag_interval, vilket betyder att den inte kommer att ta emot några replikeringsdata förrän data är gammal som specificerats. Detta kan vara användbart för snabb åtkomst till förlorad data om något går fel, till exempel om en rad raderas, kommer den att finnas på slaven i 1 timme för snabb hämtning.

Saker att veta:

• Alla DDL-ändringar av tabeller som är en del av replikering måste exekveras med slonik execute-kommandot.
• Alla tabeller som ska replikeras måste ha antingen en primärnyckel eller ett UNIKT index utan nollbara kolumner.
• Data som replikeras från masternoden replikeras efter att data kan ha genererats funktionellt. Det betyder att om data genererades med något som "random()", lagras och replikeras det resulterande numret på slavarna, istället för att "random()" körs igen på slaven och returnerar ett annat resultat.
• Om du lägger till Slony-replikering ökar serverbelastningen något. Även om den är effektiv skriven kommer varje tabell att ha en utlösare som loggar varje INSERT, UPDATE och DELETE till en Slony-tabell, förvänta dig en ökning av serverbelastningen med cirka 2-10 %, beroende på databasstorlek och arbetsbelastning.

Tips och tricks:

• Slony-demoner kan köras på vilken värd som helst som har tillgång till alla andra värdar, men den bästa konfigurationen är att låta demonerna köras på noderna de hanterar. Till exempel, masterdemonen som körs på masternoden, slavdemonen som körs på slavnoden.
• Om du ställer in ett replikeringskluster med en mycket stor mängd data kan den initiala kopian ta ganska lång tid, vilket innebär att alla ändringar som sker från start tills kopian är klar kan innebära ännu längre tid att komma ikapp och vara synkroniserade . Detta kan lösas genom att antingen lägga till några tabeller åt gången till replikering (mycket tidskrävande), eller genom att skapa en datakatalogkopia av masterdatabasen till slaven, och sedan göra en 'prenumerationsuppsättning' med alternativet OMIT COPY inställt på Sann. Med det här alternativet kommer Slony att anta att slavtabellen är 100 % identisk med mastern och inte rensa bort den och kopiera data över.
• Det bästa scenariot för detta är att skapa en Hot Standby med hjälp av de inbyggda verktygen för PostgreSQL, och under ett underhållsfönster med noll anslutningar som modifierar data, sätta standby online som en master, validera datamatchningar mellan de två, initiera slony replikeringskluster med OMIT COPY =true, och slutligen återaktivera klientanslutningar. Detta kan ta tid att göra inställningarna för Hot Standby, men processen kommer inte att orsaka någon enorm negativ inverkan på kunderna.

Community och dokumentation

Communityn för Slony kan hittas i e-postlistorna, som finns på http://lists.slony.info/mailman/listinfo/slony1-general, som även inkluderar arkiv.

Dokumentation finns tillgänglig på den officiella webbplatsen, http://slony.info/documentation/, och ger hjälp med logganalys och syntaxspecifikation för gränssnitt med slony.