En ekspertvejledning til Slony-replikering til PostgreSQL

Hvad er Slony?

Slony-I (benævnt blot 'Slony' herfra) er et tredjepartsreplikeringssystem til PostgreSQL, der går tilbage til før version 8.0, hvilket gør det til en af ​​de ældre muligheder for replikering. Den fungerer som en trigger-baseret replikeringsmetode, der er en 'master til flere slaver'-løsning.

Slony opererer ved at installere triggere på hver tabel, der skal replikeres, på både master og slaver, og hver gang tabellen får en INSERT, UPDATE eller DELETE, logger den, hvilken post der bliver ændret, og hvad ændringen er. Udefrakommende processer, kaldet 'slon-dæmoner', forbinder til databaserne som enhver anden klient og henter ændringerne fra masteren og afspiller dem derefter på alle slaveknuder, der abonnerer på masteren. I en velfungerende replikeringsopsætning er denne asynkrone replikering kan forventes at være hvor som helst, 1 til 20 sekunder efter masteren.

Når dette skrives, er den seneste version af Slony på version 2.2.6 og understøtter PostgreSQL 8.3 og nyere. Support fortsætter den dag i dag med mindre opdateringer, men hvis en fremtidig version af PostgreSQL ændrer grundlæggende funktionalitet af transaktioner, funktioner, triggere eller andre kernefunktioner, kan Slony-projektet beslutte at afbryde store opdateringer for at understøtte sådanne drastiske nye tilgange.

PostgreSQLs maskot er en elefant kendt som 'Slonik', som er russisk for 'lille elefant'. Da dette replikeringsprojekt handler om, at mange PostgreSQL-databaser replikerer med hinanden, bruges det russiske ord for elefanter (flertal):Slony.

Koncepter

• Klynge:En forekomst af Slony-replikering.
• Node:En specifik PostgreSQL-database som Slony-replikeringsnode, der fungerer som enten master eller slave for et replikeringssæt.
• Replikeringssæt:En gruppe af tabeller og/eller sekvenser, der skal replikeres.
• Abonnenter:En abonnent er en node, der abonnerer på et replikeringssæt og modtager replikeringshændelser for alle tabeller og sekvenser inden for dette sæt fra masternoden.
• Slony Daemons:De vigtigste arbejdere, der udfører replikering, en Slony-dæmon startes for hver node i replikeringssættet og etablerer forskellige forbindelser til den node, den administrerer, såvel som masterknuden.

Sådan bruges det

Slony installeres enten via kilde eller gennem PGDG (PostgreSQL Global Development Group), som er tilgængelige for Red Hat- og Debian-baserede linux-distributioner. Disse binære filer bør installeres på alle værter, der vil indeholde enten en master- eller slaveknude i replikeringssystemet.

Efter installationen opsættes en Slony-replikeringsklynge ved at udstede et par kommandoer ved hjælp af 'slonik'-binæren. 'slonik' er en kommando med sin egen simpel, men unikke syntaks til at initialisere og vedligeholde en slony klynge. Det er hovedgrænsefladen til at udstede kommandoer til den kørende Slony-klynge, der er ansvarlig for replikering.

Grænseflade med Slony kan udføres ved enten at skrive brugerdefinerede slonik-kommandoer eller kompilere slony med flaget --with-perltools, som giver de 'altperl'-scripts, der hjælper med at generere disse nødvendige slonik-scripts.

Oprettelse af en Slony-replikeringsklynge

En 'replikeringsklynge' er en samling af databaser, der er en del af replikering. Når du opretter en replikeringsklynge, skal der skrives et init-script, der definerer følgende:

• Navnet på den ønskede Slony-klynge
• Forbindelsesoplysningerne for hver nodedel af replikeringen, hver med et uforanderligt nodenummer.
• Visning af alle tabeller og sekvenser, der skal replikeres som en del af et "replikeringssæt".

Et eksempel på script kan findes i Slonys officielle dokumentation.

Når den udføres, vil slonik oprette forbindelse til alle definerede noder og oprette Slony-skemaet på hver. Når Slony-dæmonerne sparkes i gang, vil de så rydde alle data i de replikerede tabeller på slaven (hvis der er nogen), og kopiere alle data fra masteren til slaven/slaverne. Fra det tidspunkt vil dæmonerne løbende replikere ændringer, der er registreret på masteren, til alle abonnerede slaver.

Smarte konfigurationer

Mens Slony oprindeligt er et Master-to-Multiple-Slave-replikeringssystem, og hovedsageligt er blevet brugt på den måde, er der flere andre funktioner og smarte anvendelser, der gør Slony mere anvendelig end en simpel replikeringsløsning. Den meget tilpasselige karakter af Slony holder den relevant i en række forskellige situationer for administratorer, der kan tænke ud af boksen.

Cascading Replikation

Slony-noder kan sættes op til at kaskade replikation ned ad en kæde af forskellige noder. Hvis masterknudepunktet er kendt for at tage en ekstremt tung belastning, vil hver ekstra slave øge denne belastning en smule. Med kaskadereplikering kan en enkelt slaveknude, der er forbundet til masteren, konfigureres som en 'videresendelsesknude', som derefter vil være ansvarlig for at sende replikeringshændelser til flere slaver, hvilket holder belastningen på masternoden på et minimum.

Databehandling på en slaveknude

I modsætning til PostgreSQL's indbyggede replikering er slaveknuderne faktisk ikke 'read only', kun de tabeller, der replikeres, er låst ned som 'read only'. Dette betyder på en slaveknude, at databehandling kan finde sted ved at oprette nye tabeller, der ikke er en del af replikering, for at huse behandlede data. Tabeller, der er en del af replikering, kan også have tilpassede indekser oprettet afhængigt af de adgangsmønstre, der kan afvige fra slaven og masteren.

Skrivebeskyttede tabeller på slaverne kan stadig have tilpassede triggerbaserede funktioner udført på dataændringer, hvilket tillader mere tilpasning med dataene.

Minimale nedetidsopgraderinger

Opgradering af større versioner af PostgreSQL kan være ekstremt tidskrævende. Afhængigt af datastørrelse og tabelantal, kan en opgradering, inklusive "analyse"-processen efter opgradering, endda tage adskillige dage. Da Slony kan replikere data mellem PostgreSQL-klynger af forskellige versioner, kan den bruges til at opsætte replikering mellem en ældre version som master og en nyere version som slave. Når opgraderingen skal ske, skal du blot udføre en 'switchover', hvilket gør slaven til den nye master, og den gamle master bliver slaven. Når opgraderingen er markeret som en succes, skal du dekommissionere Slony-replikeringsklyngen og lukke den gamle database ned.

Høj tilgængelighed med hyppig servervedligeholdelse

Ligesom den minimale nedetid for opgraderinger, kan servervedligeholdelse nemt udføres uden nedetid ved at udføre en 'switchover' mellem to eller flere noder, hvilket tillader en slave at blive genstartet med opdateringer/anden vedligeholdelse. Når slaven kommer online igen, vil den genoprette forbindelse til replikeringsklyngen og indhente alle de replikerede data. Slutbrugere, der opretter forbindelse til databasen, kan have afbrudt lange transaktioner, men nedetiden i sig selv ville være sekunder, efterhånden som skiftet sker, snarere end hvor lang tid det tager at genstarte/opdatere værten.

Logforsendelse

Selvom det sandsynligvis ikke er en populær løsning, kan en Slony-slave konfigureres som en 'log shipping'-node, hvor alle data, den modtager gennem replikering, kan skrives til SQL-filer og sendes. Dette kan bruges af en række forskellige årsager, såsom at skrive til et eksternt drev og transportere til en slavedatabase manuelt og ikke over et netværk, komprimeret og opbevaret arkiveret til fremtidige sikkerhedskopier, eller endda få et eksternt program til at analysere SQL-filerne og ændre indholdet.

Deling af flere databasedata

Da et hvilket som helst antal tabeller kan replikeres efter behag, kan Slony-replikeringssæt sættes op til at dele specifikke tabeller mellem databaser. Mens lignende adgang kan opnås gennem Foreign Data Wrappers (som er blevet forbedret i de seneste PostgreSQL-udgivelser), kan det være en bedre løsning at bruge Slony afhængigt af brugen. Hvis en stor mængde data er nødvendig for at blive hentet fra én vært til en anden, betyder det, at Slony replikerer disse data, at de nødvendige data allerede vil eksistere på den anmodende node, hvilket eliminerer lang overførselstid.

Forsinket replikering

Normalt ønskes replikering så hurtig som muligt, men der kan være nogle scenarier, hvor en forsinkelse ønskes. Slon-dæmonen for en slaveknude kan konfigureres med et lag_interval, hvilket betyder, at den ikke modtager nogen replikeringsdata, før dataene er gamle som specificeret. Dette kan være nyttigt for hurtig adgang til mistede data, hvis noget går galt, for eksempel hvis en række slettes, vil den eksistere på slaven i 1 time for hurtig genfinding.

Ting at vide:

• Enhver DDL-ændring af tabeller, der er en del af replikering, skal udføres ved hjælp af slonik execute-kommandoen.
• Enhver tabel, der skal replikeres, skal enten have en primær nøgle eller et UNIKT indeks uden nullbare kolonner.
• Data, der replikeres fra masternoden, replikeres, efter at data kan være blevet funktionelt genereret. Det betyder, at hvis data blev genereret ved hjælp af noget som 'random()', bliver det resulterende tal gemt og replikeret på slaverne, i stedet for at 'random()' køres igen på slaven, hvilket returnerer et andet resultat.
• Tilføjelse af Slony-replikering vil øge serverbelastningen en smule. Selvom den er skrevet effektivt, vil hver tabel have en trigger, der logger hver INSERT, UPDATE og DELETE til en Slony-tabel, og forvent omkring 2-10 % serverbelastningsforøgelse, afhængigt af databasestørrelse og arbejdsbelastning.

Tips og tricks:

• Slony-dæmoner kan køre på enhver vært, der har adgang til alle andre værter, men den højest ydende konfiguration er at lade dæmonerne køre på de noder, de administrerer. For eksempel, master-dæmonen kører på master-knuden, slave-dæmonen kører på slave-knuden.
• Hvis du opsætter en replikeringsklynge med en meget stor mængde data, kan den første kopi tage ret lang tid, hvilket betyder, at alle ændringer, der sker fra start til kopien er færdig, kan betyde endnu længere tid at indhente og være synkroniseret . Dette kan løses ved enten at tilføje et par tabeller ad gangen til replikering (meget tidskrævende), eller ved at oprette en datamappekopi af masterdatabasen til slaven og derefter lave et 'subscribe-sæt' med muligheden UDEL KOPI sat til rigtigt. Med denne mulighed vil Slony antage, at slavetabellen er 100 % identisk med masteren og ikke rydde den ud og kopiere data over.
• Det bedste scenarie for dette er at oprette en Hot Standby ved hjælp af de indbyggede værktøjer til PostgreSQL, og under et vedligeholdelsesvindue med nul forbindelser, der modificerer data, bringe standbyen online som en master, validere datamatches mellem de to, starte slony replikeringsklynge med OMIT COPY =true, og til sidst genaktiver klientforbindelser. Det kan tage tid at udføre opsætningen af ​​Hot Standby, men processen vil ikke forårsage stor negativ indvirkning på kunderne.

Fællesskab og dokumentation

Fællesskabet for Slony kan findes i mailinglisterne, som findes på http://lists.slony.info/mailman/listinfo/slony1-general, som også omfatter arkiver.

Dokumentation er tilgængelig på det officielle websted, http://slony.info/documentation/, og giver hjælp til loganalyse og syntaksspecifikation for interfacing med slony.