Automatisera distributionen av ditt MySQL- eller Postgres-kluster från säkerhetskopia

ClusterControl 1.7.1 introducerar en ny funktion som heter Create Cluster from Backup, som låter dig distribuera ett nytt MySQL- eller Postgres-baserat kluster och återställa data på det från en säkerhetskopia. Det här blogginlägget visar hur den här nya funktionen fungerar och hur den här typen av automatisering kan ge förbättringar av din infrastrukturverksamhet.

Introduktion:Skapa kluster från säkerhetskopia

Säkerhetskopieringshantering är den mest älskade funktionen av våra användare, och vi har just lyft den till nästa nivå. Den här nya funktionen låter enkel - ClusterControl 1.7.1 kan distribuera ett nytt kluster från en befintlig säkerhetskopia. Det finns dock flera procedurer och kontroller involverade för att distribuera ett produktionsklassat kluster direkt från en säkerhetskopia. Själva restaureringen kommer med sina egna utmaningar, såsom:

Fullständig eller partiell återställningskonsekvenser
Baskopiering och dess inkrementella säkerhetskopieringsordning (för inkrementell säkerhetskopiering)
Dekryptering av säkerhetskopia (om krypterad)
Alternativ för återställningsverktyg
Dekompression (om den är komprimerad)
Säkerhetskopiera streaming från källan till målservern
Användning av diskutrymme under och efter återställningen
Rapportering av återställningsförlopp

Kombinera ovanstående med komplexiteten och repetitiviteten hos databasklusterdistributionsuppgifter, du kan spara tid och minska risken med att köra felbenägna procedurer. Den svåraste delen ur användarens perspektiv är att välja vilken säkerhetskopia som ska återställas från. ClusterControl kommer att hantera alla tunga lyft bakom scenen och rapportera slutresultatet när det är klart.

Stegen är i grunden enkla:

Konfigurera lösenordslös SSH från ClusterControl-noden till de nya servrarna.
Välj en logisk säkerhetskopia från säkerhetskopieringslistan, eller skapa en under Säkerhetskopiering -> Skapa säkerhetskopia .
Klicka på Återställ -> Skapa kluster från säkerhetskopia och följ distributionsguiden.

Denna funktion är speciellt byggd för MySQL Galera Cluster och PostgreSQL för närvarande. Det här är vad du skulle se i användargränssnittet efter att ha klickat på "Återställ" på en befintlig säkerhetskopia:

Det nedersta alternativet är det vi letar efter. Därefter är en sammanfattningsdialog för den valda säkerhetskopian före distributionskonfigurationen:

Därefter kommer samma distributionsguide för databaskluster för respektive kluster (MySQL Galera Cluster eller PostgreSQL) att visas för att konfigurera ett nytt kluster:

Observera att du måste ange samma användarnamn och lösenord för databasens root/admin som det du har i säkerhetskopian. Annars skulle distributionen misslyckas halvvägs när den första noden startas. I allmänhet kommer återställnings- och distributionsprocedurer att ske i följande ordning:

Installera nödvändig programvara och beroenden på alla databasnoder.
Starta den första noden.
Strömma och återställ säkerhetskopia på den första noden (med flagga för automatisk omstart).
Konfigurera och lägg till resten av noderna.

Ett nytt databaskluster kommer att listas under ClusterControl-klusterinstrumentpanelen när jobbet är klart.

Vad kan du tjäna på det?

Det finns ett antal saker du kan dra nytta av den här funktionen, som förklaras i följande avsnitt.

Testa din datauppsättning under olika förhållanden

Ibland kanske du undrar om den nya databasversionen skulle fungera eller fungera för din databas arbetsbelastning och att testa den är det enda sättet att veta. Det är här den här funktionen kommer till användning. Det låter dig utföra tester och jämföra många inblandade variabler som skulle påverka databasens stabilitet eller prestanda, till exempel den underliggande hårdvaran, mjukvaruversionen, leverantörens och databasens eller applikationens arbetsbelastningar.

För ett enkelt exempel finns det en stor förbättring av DDL-exekveringen mellan MySQL 5.6 och MySQL 5.7. Följande DROP-operation på en tabell med 10 miljoner rader bevisar allt:

mysql-5.7> ALTER TABLE sbtest1 DROP COLUMN xx;
Query OK, 0 rows affected (1 min 58.12 sec)

mysql-5.6> ALTER TABLE sbtest1 DROP COLUMN xx;
Query OK, 0 rows affected (2 min 23.74 sec)

Genom att ha ett annat kluster att jämföra med kan vi faktiskt mäta förbättringen och motivera en migrering.

Databasmigrering med logisk säkerhetskopiering

Logisk säkerhetskopiering som mysqldump och pg_dumpall är det säkraste sättet att uppgradera, nedgradera eller migrera din data från en version eller leverantör till en annan. Alla logiska säkerhetskopior kan användas för att utföra databasmigrering. Databasuppgraderingsstegen är i grunden enkla:

Skapa (eller schemalägg) en logisk säkerhetskopia - mysqldump för MySQL eller pg_dumpall för PostgreSQL
Konfigurera lösenordslös SSH från ClusterControl-noden till de nya servrarna.
Välj en skapad logisk säkerhetskopia från säkerhetskopieringslistan.
Klicka på Återställ -> Skapa kluster från säkerhetskopia och följ distributionsguiden.
Verifiera dataåterställningen på det nya klustret.
Peka din ansökan till det nya klustret.

Snabbare total återställningstid för kluster

Föreställ dig ett katastrofalt fel som hindrar ditt kluster att köras, som till exempel ett centraliserat lagringsfel som påverkade alla virtuella maskiner som var anslutna till det, du kan få ett ersättningskluster nästan omedelbart (förutsatt att säkerhetskopieringsfilerna lagras utanför de misslyckade databasnoderna , konstaterar det självklara). Den här funktionen kan automatiseras via s9s-klienten, där du kan utlösa ett jobb via kommandoradsgränssnittet, till exempel:

$ s9s cluster \
--create \
--cluster-type=postgresql \
--nodes="192.168.0.101?master;192.168.0.102?slave;192.168.0.103?slave" \
--provider-version=11 \
--db-admin=postgres \
--db-admin-passwd='s3cr3tP455' \
--os-user=root \
--os-key-file=/root/.ssh/id_rsa \
--cluster-name="PostgreSQL 9.6 - Test"
--backup-id=214 \
--log

En sak att notera när du använder den här funktionen är att använda samma administratörsanvändarnamn och lösenord som det som lagras i säkerhetskopian. Dessutom måste den lösenordslösa SSH till alla databasnoder konfigureras i förväg. Annars, om du föredrar att konfigurera det interaktivt, använd bara webbgränssnittet.

Skala ut via asynkron replikering

För MySQL Galera Cluster har det nyskapade klustret möjlighet att skalas ut via MySQL asynkron replikering. Låt oss säga att vi redan har återställt ett nytt kluster på kontoret baserat på den senaste säkerhetskopian från produktionsklustret i datacentret, och vi skulle vilja att kontorsklustret fortsätter att replikera från produktionsklustret, som illustreras i följande diagram:

Du kan sedan ställa in den asynkrona replikeringslänken på följande sätt:

Välj en nod i produktionen och aktivera binär loggning (om inaktiverad). Gå till Noder -> välj en nod -> Nodåtgärder -> Aktivera binär loggning.
Aktivera binär loggning på alla noder för kontorskluster. Denna åtgärd kräver en rullande omstart som kommer att utföras automatiskt om du väljer "Ja" under rullgardinsmenyn "Auto-restart node":

Annars kan du utföra denna operation utan driftstopp genom att använda Hantera -> Uppgradera -> Rullande omstart (eller starta om en nod i taget manuellt).
Skapa en replikeringsanvändare i produktionsklustret genom att använda Hantera -> Schema och användare -> Användare -> Skapa ny användare:

Välj sedan en nod att replikera till huvudnoden i produktionsklustret och ställ in replikeringslänken:

mysql> CHANGE MASTER master_host = 'prod-mysql1', master_user = 'slave', master_password = 'slavepassw0rd', master_auto_position = 1;
mysql> START SLAVE;

Kontrollera om replikeringen körs:
```
mysql> SHOW SLAVE STATUS\G
```
Se till att Slave_IO_Thread och Slave_SQL_thread rapporterar "Ja". Kontorets kluster bör börja komma ikapp huvudnoden om den släpar efter.

Det var allt för nu gott folk!