Een experthandleiding voor Slony-replicatie voor PostgreSQL

Wat is Slony?

Slony-I (vanaf nu gewoon 'Slony' genoemd) is een replicatiesysteem van derden voor PostgreSQL dat dateert van vóór versie 8.0, waardoor het een van de oudere beschikbare opties voor replicatie is. Het werkt als een op triggers gebaseerde replicatiemethode die een 'master naar meerdere slaven'-oplossing is.

Slony werkt door triggers te installeren op elke tafel die moet worden gerepliceerd, op zowel master als slaves, en elke keer dat de tafel een INSERT, UPDATE of DELETE krijgt, wordt vastgelegd welk record wordt gewijzigd en wat de wijziging is. Externe processen, de 'slon-daemons' genoemd, maken verbinding met de databases zoals elke andere client en halen de wijzigingen op van de master en spelen ze vervolgens opnieuw af op alle slave-knooppunten die zijn geabonneerd op de master. In een goed presterende replicatieconfiguratie is deze asynchroon replicatie kan naar verwachting overal 1 tot 20 seconden achterlopen op de master.

Op het moment van schrijven is de nieuwste versie van Slony versie 2.2.6 en ondersteunt PostgreSQL 8.3 en hoger. Ondersteuning wordt tot op de dag van vandaag voortgezet met kleine updates, maar als een toekomstige versie van PostgreSQL de fundamentele functionaliteit van transacties, functies, triggers of andere kernfuncties verandert, kan het Slony-project besluiten om grote updates stop te zetten om dergelijke drastische nieuwe benaderingen te ondersteunen.

De mascotte van PostgreSQL is een olifant die bekend staat als 'Slonik', wat Russisch is voor 'kleine olifant'. Aangezien dit replicatieproject gaat over veel PostgreSQL-databases die met elkaar repliceren, wordt het Russische woord voor olifanten (meervoud) gebruikt:Slony.

Begrippen

• Cluster:een exemplaar van Slony-replicatie.
• Knooppunt:een specifieke PostgreSQL-database als Slony-replicatieknooppunt, dat werkt als een master of als slaaf voor een replicatieset.
• Replicatieset:een groep tabellen en/of reeksen die moeten worden gerepliceerd.
• Abonnees:een abonnee is een knooppunt dat is geabonneerd op een replicatieset en replicatiegebeurtenissen ontvangt voor alle tabellen en reeksen binnen die set van het hoofdknooppunt.
• Slony Daemons:de belangrijkste werkers die replicatie uitvoeren, een Slony-daemon wordt gestart voor elk knooppunt in de replicatieset en brengt verschillende verbindingen tot stand met het knooppunt dat het beheert, evenals het hoofdknooppunt.

Hoe het wordt gebruikt

Slony wordt ofwel door de bron geïnstalleerd ofwel via de PGDG (PostgreSQL Global Development Group) repositories die beschikbaar zijn voor op Red Hat en Debian gebaseerde Linux-distributies. Deze binaire bestanden moeten worden geïnstalleerd op alle hosts die een master- of slave-knooppunt in het replicatiesysteem zullen bevatten.

Na installatie wordt een Slony-replicatiecluster opgezet door een paar opdrachten uit te geven met behulp van het binaire 'slonik'. 'slonik' is een opdracht met een eenvoudige, maar unieke eigen syntaxis om een ​​slony-cluster te initialiseren en te onderhouden. Het is de belangrijkste interface voor het geven van opdrachten aan het draaiende Slony-cluster dat verantwoordelijk is voor replicatie.

Interfacing met Slonik kan worden gedaan door ofwel aangepaste slonik-commando's te schrijven, of slony te compileren met de --with-perltools-vlag, die de 'altperl'-scripts levert die helpen bij het genereren van deze benodigde slonik-scripts.

Een Slony-replicatiecluster maken

Een ‘Replicatiecluster’ is een verzameling databases die onderdeel zijn van replicatie. Bij het maken van een replicatiecluster moet een init-script worden geschreven dat het volgende definieert:

• De naam van het gewenste Slony-cluster
• De verbindingsinformatie voor elk knooppuntonderdeel van replicatie, elk met een onveranderlijk knooppuntnummer.
• Een lijst van alle tabellen en reeksen die moeten worden gerepliceerd als onderdeel van een 'replicatieset'.

Een voorbeeldscript is te vinden in de officiële documentatie van Slony.

Wanneer het wordt uitgevoerd, zal slonik verbinding maken met alle gedefinieerde knooppunten en op elk knooppunt het Slony-schema maken. Wanneer de Slony-daemons worden gestart, wissen ze alle gegevens in de gerepliceerde tabellen op de slave (indien aanwezig) en kopiëren ze alle gegevens van de master naar de slave(s). Vanaf dat moment zullen de daemons continu de wijzigingen die op de master zijn opgenomen, repliceren naar alle geabonneerde slaves.

Slimme configuraties

Hoewel Slony in eerste instantie een Master-to-Multiple-Slave-replicatiesysteem is en voornamelijk op die manier is gebruikt, zijn er verschillende andere functies en slimme toepassingen die Slony nuttiger maken dan een eenvoudige replicatie-oplossing. Het zeer aanpasbare karakter van Slony houdt het relevant voor verschillende situaties voor beheerders die buiten de gebaande paden kunnen denken.

Cascading replicatie

Slony-knooppunten kunnen worden ingesteld om replicatie door een keten van verschillende knooppunten te laten lopen. Als bekend is dat het masterknooppunt een extreem zware belasting aankan, zal elke extra slave die belasting iets verhogen. Met trapsgewijze replicatie kan een enkele slave-node die op de master is aangesloten, worden geconfigureerd als een 'forwarding node', die vervolgens verantwoordelijk is voor het verzenden van replicatiegebeurtenissen naar meer slaven, waardoor de belasting van de master-node tot een minimum wordt beperkt.

Gegevensverwerking op een slaveknooppunt

In tegenstelling tot de ingebouwde replicatie van PostgreSQL, zijn de slave-knooppunten niet echt 'alleen-lezen', alleen de tabellen die worden gerepliceerd, zijn vergrendeld als 'alleen-lezen'. Dit betekent dat op een slave-knooppunt gegevensverwerking kan plaatsvinden door nieuwe tabellen te maken die geen deel uitmaken van replicatie om verwerkte gegevens te huisvesten. Tabellen die deel uitmaken van replicatie kunnen ook aangepaste indexen hebben, afhankelijk van de toegangspatronen die kunnen verschillen van de slave en de master.

Alleen-lezen-tabellen op de slaves kunnen nog steeds aangepaste, op triggers gebaseerde functies hebben die worden uitgevoerd op gegevenswijzigingen, waardoor meer maatwerk met de gegevens mogelijk is.

Minimale downtime-upgrades

Het upgraden van belangrijke versies van PostgreSQL kan extreem tijdrovend zijn. Afhankelijk van de gegevensgrootte en het aantal tabellen, kan een upgrade inclusief het 'analyseren'-proces na de upgrade zelfs enkele dagen duren. Omdat Slony gegevens kan repliceren tussen PostgreSQL-clusters van verschillende versies, kan het worden gebruikt om replicatie in te stellen tussen een oudere versie als master en een nieuwere versie als slave. Wanneer de upgrade moet plaatsvinden, voert u eenvoudig een 'omschakeling' uit, waardoor de slaaf de nieuwe meester wordt en de oude meester de slaaf. Wanneer de upgrade succesvol is bevonden, ontmantelt u het Slony-replicatiecluster en sluit u de oude database af.

Hoge beschikbaarheid met frequent serveronderhoud

Net als de minimale downtime voor upgrades, kan serveronderhoud eenvoudig worden gedaan zonder downtime door een 'omschakeling' tussen twee of meer nodes uit te voeren, waardoor een slave opnieuw kan worden opgestart met updates / ander onderhoud. Wanneer de slave weer online komt, maakt hij opnieuw verbinding met het replicatiecluster en haalt hij alle gerepliceerde gegevens in. Eindgebruikers die verbinding maken met de database hebben mogelijk langdurige transacties onderbroken, maar de downtime zelf zou seconden zijn als de omschakeling plaatsvindt, in plaats van hoe lang het duurt om de host opnieuw op te starten / bij te werken.

Log verzending

Hoewel het waarschijnlijk geen populaire oplossing is, kan een Slony-slave worden ingesteld als een 'log shipping'-knooppunt, waar alle gegevens die het via replicatie ontvangt, naar SQL-bestanden kunnen worden geschreven en verzonden. Dit kan om verschillende redenen worden gebruikt, zoals schrijven naar een externe schijf en handmatig transporteren naar een slave-database, en niet via een netwerk, gecomprimeerd en gearchiveerd bewaard voor toekomstige back-ups, of zelfs een extern programma de SQL-bestanden laten parseren en wijzig de inhoud.

Het delen van meerdere databasegegevens

Aangezien een willekeurig aantal tabellen naar believen kan worden gerepliceerd, kunnen Slony-replicatiesets worden ingesteld om specifieke tabellen tussen databases te delen. Hoewel vergelijkbare toegang kan worden verkregen via Foreign Data Wrappers (die zijn verbeterd in recente PostgreSQL-releases), kan het een betere oplossing zijn om Slony te gebruiken, afhankelijk van het gebruik. Als er een grote hoeveelheid gegevens van de ene host naar de andere moet worden opgehaald, betekent het dat Slony die gegevens repliceert dat de benodigde gegevens al aanwezig zijn op het verzoekende knooppunt, waardoor lange overdrachtstijd wordt geëlimineerd.

Vertraagde replicatie

Gewoonlijk is replicatie gewenst om zo snel mogelijk te zijn, maar er kunnen enkele scenario's zijn waarin een vertraging gewenst is. De slon-daemon voor een slave-knooppunt kan worden geconfigureerd met een lag_interval, wat betekent dat het geen replicatiegegevens ontvangt totdat de gegevens oud zijn zoals gespecificeerd. Dit kan handig zijn voor snelle toegang tot verloren gegevens als er iets misgaat, bijvoorbeeld als een rij wordt verwijderd, blijft deze gedurende 1 uur op de slave staan ​​om snel te kunnen worden opgehaald.

Dingen om te weten:

• Alle DDL-wijzigingen in tabellen die deel uitmaken van replicatie moeten worden uitgevoerd met de opdracht slonik execute.
• Elke tabel die moet worden gerepliceerd, moet een primaire sleutel hebben, of een UNIEKE index zonder kolommen die null kunnen bevatten.
• Gegevens die vanaf het hoofdknooppunt worden gerepliceerd, worden gerepliceerd nadat eventuele gegevens functioneel zijn gegenereerd. Dit betekent dat als gegevens zijn gegenereerd met behulp van zoiets als 'random()', het resulterende nummer wordt opgeslagen en gerepliceerd op de slaves, in plaats van dat 'random()' opnieuw wordt uitgevoerd op de slave en een ander resultaat oplevert.
• Het toevoegen van Slony-replicatie zal de serverbelasting iets verhogen. Hoewel efficiënt geschreven, heeft elke tabel een trigger die elke INSERT, UPDATE en DELETE logt in een Slony-tabel, verwacht een toename van de serverbelasting met ongeveer 2-10%, afhankelijk van de databasegrootte en werkbelasting.

Tips en trucs:

• Slony-daemons kunnen draaien op elke host die toegang heeft tot alle andere hosts, maar de best presterende configuratie is om de daemons te laten draaien op de knooppunten die ze beheren. Bijvoorbeeld de master-daemon die op de master-node draait, de slave-daemon die op de slave-node draait.
• Als een replicatiecluster met een zeer grote hoeveelheid gegevens wordt opgezet, kan de eerste kopie behoorlijk lang duren, wat betekent dat alle wijzigingen die plaatsvinden vanaf de kick-off tot de kopie is voltooid, nog langer kunnen duren om bij te praten en synchroon te lopen . Dit kan worden opgelost door ofwel een paar tabellen tegelijk toe te voegen aan replicatie (zeer tijdrovend), of door een datadirectory-kopie van de masterdatabase naar de slave te maken en vervolgens een 'subscribe set' te doen met de OMIT COPY-optie ingesteld op WAAR. Met deze optie gaat Slony ervan uit dat de slave-tabel 100% identiek is aan de master, en niet leegmaken en gegevens kopiëren.
• Het beste scenario hiervoor is om een ​​Hot Standby te creëren met behulp van de ingebouwde tools voor PostgreSQL, en tijdens een onderhoudsperiode zonder verbindingen die gegevens wijzigen, de standby online brengen als een master, gegevensovereenkomsten tussen de twee valideren, de slony-replicatiecluster met OMIT COPY =true, en schakel ten slotte clientverbindingen opnieuw in. Dit kan enige tijd duren om de instelling voor de Hot Standby uit te voeren, maar het proces zal geen enorme negatieve gevolgen hebben voor klanten.

Community en documentatie

De community voor Slony is te vinden in de mailinglijsten op http://lists.slony.info/mailman/listinfo/slony1-general, die ook archieven bevat.

Documentatie is beschikbaar op de officiële website, http://slony.info/documentation/, en biedt hulp bij loganalyse en syntaxisspecificatie voor interfacing met slony.