Automatiseer de implementatie van uw MySQL- of Postgres-cluster vanuit een back-up

ClusterControl 1.7.1 introduceert een nieuwe functie genaamd Create Cluster from Backup, waarmee u een nieuw MySQL- of Postgres-gebaseerd cluster kunt implementeren en gegevens erop kunt herstellen vanaf een back-up. Deze blogpost laat zien hoe deze nieuwe functie werkt en hoe dit type automatisering verbeteringen kan opleveren voor uw infrastructuuractiviteiten.

Introductie:Cluster maken op basis van back-up

Back-upbeheer is de meest geliefde functie van onze gebruikers en we hebben het naar een hoger niveau getild. Deze nieuwe functionaliteit klinkt eenvoudig - ClusterControl 1.7.1 kan een nieuw cluster implementeren vanuit een bestaande back-up. Er zijn echter meerdere procedures en controles nodig om een ​​cluster van productiekwaliteit direct vanaf een back-up te implementeren. Restauratie zelf brengt zijn eigen uitdagingen met zich mee, zoals:

• Gevolgen voor volledig of gedeeltelijk herstel
• Basisback-up en de volgorde van incrementele back-ups (voor incrementele back-up)
• Back-up ontsleuteling (indien versleuteld)
• Opties voor hersteltool
• Decompressie (indien gecomprimeerd)
• Back-up streamen van de bron naar de doelserver
• Gebruik van schijfruimte tijdens en na het herstel
• Restauratie voortgangsrapportage

Combineer het bovenstaande met de complexiteit en herhaling van implementatietaken voor databaseclusters, u kunt tijd besparen en het risico verminderen bij het uitvoeren van foutgevoelige procedures. Het moeilijkste deel vanuit het perspectief van de gebruiker is om te kiezen van welke back-up je wilt herstellen. ClusterControl doet al het zware werk achter de schermen en rapporteert het eindresultaat zodra het klaar is.

De stappen zijn in principe eenvoudig:

1. Stel wachtwoordloze SSH in vanaf het ClusterControl-knooppunt naar de nieuwe servers.
2. Kies één logische back-up uit de back-uplijst of maak er een aan onder Back-ups -> Back-up maken .
3. Klik op Herstellen -> Cluster maken van back-up en volg de implementatiewizard.

Deze functie is op dit moment specifiek gebouwd voor MySQL Galera Cluster en PostgreSQL. Dit is wat u zou zien in de gebruikersinterface nadat u op "Herstellen" op een bestaande back-up hebt geklikt:

De onderste optie is wat we zoeken. Het volgende is het overzichtsdialoogvenster over de gekozen back-up vóór de implementatieconfiguratie:

Vervolgens wordt dezelfde implementatiewizard voor databaseclusters voor het betreffende cluster (MySQL Galera Cluster of PostgreSQL) weergegeven om een ​​nieuw cluster te configureren:

Merk op dat u dezelfde gebruikersnaam en hetzelfde wachtwoord voor de database root/admin moet specificeren als degene die u in de back-up heeft. Anders zou de implementatie halverwege mislukken bij het opstarten van het eerste knooppunt. Over het algemeen zullen herstel- en implementatieprocedures in de volgende volgorde plaatsvinden:

1. Installeer de benodigde software en afhankelijkheden op alle databaseknooppunten.
2. Start het eerste knooppunt.
3. Stream en herstel back-up op het eerste knooppunt (met vlag voor automatisch herstarten).
4. Configureer en voeg de rest van de knooppunten toe.

Een nieuw databasecluster wordt vermeld onder ClusterControl-clusterdashboard zodra de taak is voltooid.

Wat kun je ermee winnen?

Er zijn een aantal dingen die u van deze functie kunt profiteren, zoals uitgelegd in de volgende secties.

Test uw dataset onder verschillende omstandigheden

Soms vraag je je misschien af ​​of de nieuwe databaseversie zou werken of presteren voor je databasewerkbelasting en het testen ervan is de enige manier om erachter te komen. Dit is waar deze functie van pas komt. Het stelt u in staat om tests uit te voeren en te benchmarken op vele betrokken variabelen die van invloed kunnen zijn op de stabiliteit of prestaties van de database, bijvoorbeeld de onderliggende hardware, softwareversie, leverancier en database- of applicatieworkloads.

Voor een eenvoudig voorbeeld is er een grote verbetering in de DDL-uitvoering tussen MySQL 5.6 en MySQL 5.7. De volgende DROP-bewerking op een tabel met 10 miljoen rijen bewijst het allemaal:

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)

Als we een ander cluster hebben om mee te vergelijken, kunnen we de verbetering meten en een migratie rechtvaardigen.

Databasemigratie met logische back-up

Logische back-up zoals mysqldump en pg_dumpall is de veiligste manier om uw gegevens te upgraden, downgraden of migreren van de ene versie of leverancier naar de andere. Alle logische back-ups kunnen worden gebruikt om databasemigratie uit te voeren. De stappen voor het upgraden van de database zijn in principe eenvoudig:

1. Maak (of plan) een logische back-up - mysqldump voor MySQL of pg_dumpall voor PostgreSQL
2. Stel wachtwoordloze SSH in van ClusterControl-knooppunt naar de nieuwe servers.
3. Kies een gemaakte logische back-up uit de back-uplijst.
4. Klik op Herstellen -> Cluster maken van back-up en volg de implementatiewizard.
5. Controleer het gegevensherstel op het nieuwe cluster.
6. Wijs uw toepassing naar het nieuwe cluster.

Sneller totale hersteltijd van clusters

Stelt u zich een catastrofale storing voor waardoor uw cluster niet kan worden uitgevoerd, zoals bijvoorbeeld een storing in de gecentraliseerde opslag die gevolgen heeft voor alle virtuele machines die ermee zijn verbonden, dan kunt u vrijwel onmiddellijk een vervangend cluster krijgen (op voorwaarde dat de back-upbestanden buiten de defecte databaseknooppunten worden opgeslagen , met vermelding van het voor de hand liggende). Deze functie kan worden geautomatiseerd via de s9s-client, waar u een taak kunt activeren via de opdrachtregelinterface, bijvoorbeeld:

$ 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

Een ding om op te merken bij het gebruik van deze functie is om dezelfde beheerdersgebruikersnaam en hetzelfde wachtwoord te gebruiken als wat in de back-up is opgeslagen. Ook moet de wachtwoordloze SSH naar alle databaseknooppunten vooraf worden geconfigureerd. Anders, als u het liever interactief configureert, gebruikt u gewoon de web-UI-interface.

Uitschalen via asynchrone replicatie

Voor MySQL Galera Cluster heeft het nieuw gecreëerde cluster de mogelijkheid om uit te schalen via MySQL asynchrone replicatie. Laten we zeggen dat we al een nieuw cluster op kantoor hebben hersteld op basis van de laatste back-up van het productiecluster in het datacenter, en dat we willen dat het kantoorcluster doorgaat met repliceren vanuit het productiecluster, zoals geïllustreerd in het volgende diagram:

U kunt dan de asynchrone replicatielink op de volgende manier instellen:

1. Kies één knooppunt in de productie en schakel binaire logboekregistratie in (indien uitgeschakeld). Ga naar Knooppunten -> kies een knooppunt -> Knooppuntacties -> Binaire logboekregistratie inschakelen.

2. Schakel binaire logboekregistratie in op alle knooppunten voor het kantoorcluster. Deze actie vereist een rollende herstart die automatisch wordt uitgevoerd als u "Ja" kiest onder de vervolgkeuzelijst "Knooppunt automatisch opnieuw opstarten":

   

   Anders kunt u deze bewerking zonder downtime uitvoeren door Beheren -> Upgraden -> Rolling Restart te gebruiken (of handmatig één knooppunt tegelijk opnieuw te starten).

3. Maak een replicatiegebruiker op het productiecluster met Beheren -> Schema's en gebruikers -> Gebruikers -> Nieuwe gebruiker maken:

   

4. Kies vervolgens een knooppunt om te repliceren naar het hoofdknooppunt in het productiecluster en stel de replicatielink in:

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

5. Controleer of de replicatie actief is:

   mysql> SHOW SLAVE STATUS\G

   Zorg ervoor dat Slave_IO_Thread en Slave_SQL_thread 'Ja' rapporteren. Het cluster van het kantoor zou het hoofdknooppunt moeten inhalen als het achterloopt.

Dat was het voor nu mensen!