De kern van ClusterControl is de automatisering ervan, net als ervoor zorgen dat uw gegevens veilig worden geback-upt en klaar zijn voor herstel wanneer er iets misgaat. Het hebben van een effectieve back-upstrategie en noodherstelplan is de sleutel tot het succes van elke applicatie of omgeving.
In onze nieuwste release, ClusterControl 1.5, hebben we een aantal verbeteringen geïntroduceerd voor het maken van back-ups van op MySQL en MariaDB gebaseerde systemen.
Een van de belangrijkste verbeteringen is de mogelijkheid om vanuit ClusterControl een back-up te maken naar de cloudprovider van uw keuze. Cloudproviders zoals Google Cloud Services en Amazon S3 bieden elk vrijwel onbeperkte opslag, waardoor er minder lokale ruimte nodig is. Hierdoor kunt u uw back-upbestanden langer bewaren, zo lang als u wilt en hoeft u zich geen zorgen te maken over de lokale schijfruimte.
Laten we eens kijken naar alle opwindende nieuwe back-upfuncties voor ClusterControl 1.5...
Wizard back-up/herstel opnieuw ontwerpen
Allereerst zult u merken dat back-up- en herstelwizards zijn vernieuwd om de gebruikerservaring te verbeteren. Het wordt nu geladen als een zijmenu aan de rechterkant van het scherm:
De back-uplijst krijgt ook een kleine aanpassing waarbij back-updetails worden weergegeven wanneer u op de specifieke back-up klikt:
U kunt de back-uplocatie bekijken en welke databases zich in de back-up bevinden. Er zijn ook opties om de back-up te herstellen of deze naar de cloud te uploaden.
PITR-compatibele back-up
ClusterControl voert de standaard mysqldump-back-up uit met afzonderlijke schema- en gegevensdumps. Dit maakt het gemakkelijk om gedeeltelijke back-ups te herstellen. Het verbreekt echter de consistentie van de back-up (schema en gegevens worden in twee afzonderlijke sessies gedumpt), dus het kan niet worden gebruikt om een slaaf of herstel op een bepaald tijdstip in te richten.
Een mysqldump PITR-compatibele back-up bevat één enkel dumpbestand, met GTID-info, binlogbestand en positie. Dus alleen het databaseknooppunt dat binaire logs produceert, heeft de optie "PITR-compatibel" beschikbaar, zoals gemarkeerd in de onderstaande schermafbeelding:
Wanneer de PITR-compatibele optie is ingeschakeld, worden de database- en tabelvelden grijs weergegeven omdat ClusterControl altijd de back-up zal uitvoeren tegen alle databases, gebeurtenissen, triggers en routines van de MySQL-doelserver.
De volgende regels verschijnen in de eerste ~50 regels van het voltooide dumpbestand:
$ head -50 mysqldump_2017-11-07_072250_complete.sql
...
-- GTID state at the beginning of the backup
--
SET @@GLOBAL.GTID_PURGED='20dc5247-4a98-ee18-73af-5c79373388ee:1-1681';
--
-- Position to start replication or point-in-time recovery from
--
CHANGE MASTER TO MASTER_LOG_FILE='binlog.000001', MASTER_LOG_POS=2457790;
...De informatie kan worden gebruikt om slaves te bouwen vanaf een back-up, of om point-in-time herstel uit te voeren samen met binaire logboeken, waar u het herstel kunt starten vanaf de MASTER_LOG_FILE en MASTER_LOG_POS gerapporteerd in het dumpbestand met behulp van het hulpprogramma "mysqlbinlog". Houd er rekening mee dat er geen back-up wordt gemaakt van binaire logbestanden door ClusterControl.
Slaves bouwen vanuit back-up Een andere functie is de mogelijkheid om een slave rechtstreeks vanaf een PITR-compatibele back-up te bouwen, in plaats van dit vanaf een gekozen master te doen. Dit is een enorm voordeel omdat het de hoofdserver ontlast. Deze optie kan worden gebruikt met MySQL-replicatie of Galera-cluster. Een bestaande back-up kan worden gebruikt om een bestaande replicatieslave opnieuw op te bouwen of een nieuwe replicatieslave toe te voegen tijdens de faseringsfase, zoals weergegeven in de volgende schermafbeelding:
Zodra de enscenering is voltooid, zal de slave verbinding maken met de gekozen master en beginnen met inhalen. Voorheen voerde ClusterControl een streaming back-up uit direct vanaf de gekozen master met behulp van Percona Xtrabackup. Dit kan van invloed zijn op de prestaties van de master bij het uitschalen van een grote dataset, ondanks dat de bewerking niet-blokkerend is op de master. Met de nieuwe optie, als de back-up wordt opgeslagen op ClusterControl, zullen alleen deze hosts (ClusterControl + de slave) bezig zijn bij het ensceneren van de gegevens op de slave.
Back-up naar cloud
Back-ups kunnen nu automatisch worden geüpload in de cloud. Hiervoor moet een ClusterControl-module worden geïnstalleerd, genaamd clustercontrol-cloud (Cloud-integratiemodule) en clustercontrol-clud (Cloud download/upload CLI) die beschikbaar zijn in v1.5 en later. De upgrade-instructies zijn bij deze pakketten inbegrepen en worden geleverd zonder extra configuratie. Op dit moment zijn de ondersteunde cloudplatforms Amazon Web Services en Google Cloud Platform. Cloudreferenties worden geconfigureerd onder ClusterControl -> Instellingen -> Integraties -> Cloudproviders.
Wanneer u een back-up maakt of plant, zou u de volgende extra opties moeten zien wanneer "Upload back-up naar de cloud" is ingeschakeld:
Met deze functie kunt u eenmalig uploaden of back-ups plannen die na voltooiing worden geüpload (Amazon S3 of Google Cloud Storage). U kunt de back-ups vervolgens naar wens downloaden en herstellen.
Aangepaste compressie voor mysqldump
Deze functie werd in feite voor het eerst geïntroduceerd met ClusterControl v1.4.2 na de release. We hebben een back-upcompressieniveau toegevoegd op basis van gzip. Voorheen gebruikte ClusterControl de standaard back-upcompressie (niveau 6) als de back-upbestemming zich op het controllerknooppunt bevond. De laagste compressie (niveau 1 - snelste, minder compressie) werd gebruikt als de back-upbestemming zich op de databasehost zelf bevond, om een minimale impact op de database te garanderen tijdens het comprimeren.
In deze versie hebben we het compressieaspect opgepoetst en u kunt nu het compressieniveau aanpassen, ongeacht de back-upbestemming. Bij het upgraden van uw ClusterControl-instantie worden alle geplande back-ups automatisch geconverteerd naar gebruiksniveau 6, tenzij u ze expliciet bewerkt in v1.5.
Back-upcompressie is van vitaal belang wanneer uw dataset groot is, gecombineerd met een lang back-upretentiebeleid, terwijl de opslagruimte beperkt is. Mysqldump, dat op tekst is gebaseerd, kan profiteren van compressie met een besparing tot 60% van de schijfruimte van de oorspronkelijke bestandsgrootte. In sommige gevallen is de hoogste compressieverhouding de beste optie, hoewel dit gepaard gaat met een langere decompressie bij het herstellen.
Bonusfunctie:automatische back-upverificatie
Zoals oude systeembeheerders zeggen:een back-up is geen back-up als deze niet kan worden hersteld. Back-upverificatie is iets dat meestal door velen wordt verwaarloosd. Sommige systeembeheerders hebben hiervoor interne routines ontwikkeld, meestal meer handmatig dan geautomatiseerd. Het automatiseren ervan is moeilijk, voornamelijk vanwege de complexiteit van de operatie als geheel - te beginnen met hostprovisioning, MySQL-installatie en voorbereiding, overdracht van back-upbestanden, decompressie, herstelbewerking, verificatieprocedures en tenslotte het opschonen van het systeem na het proces. Al dit gedoe zorgt ervoor dat mensen zo'n belangrijk aspect van een betrouwbare back-up verwaarlozen. Over het algemeen moet minimaal één keer per maand een back-uphersteltest worden uitgevoerd, of in geval van significante wijzigingen in de gegevensomvang of de databasestructuur. Zoek een schema dat voor u werkt en formaliseer het met een gepland evenement.
ClusterControl kan de back-upverificatie automatiseren door het terugzetten op een nieuwe host uit te voeren, zonder de bovengenoemde verificatieprocedures in gevaar te brengen. Dit kan met enige vertraging, of direct nadat de back-up is voltooid. Het rapporteert de back-upstatus op basis van de afsluitcode van de herstelbewerking, sluit automatisch af als de back-up is geverifieerd, of laat de herstelde host gewoon draaien zodat u aanvullende handmatige verificaties van de gegevens kunt uitvoeren.
Bij het maken of plannen van een back-up heeft u extra opties als "Back-up verifiëren" is ingeschakeld:
Als "Install Database Software" is ingeschakeld, zal ClusterControl alle bestaande MySQL-installaties op de doelhost verwijderen en de databasesoftware opnieuw installeren met dezelfde versie als de bestaande MySQL-server. Anders kunt u deze optie overslaan als u een specifieke instelling voor de herstelde host heeft. De rest van de opties spreken voor zich.
Bonusfunctie:vergeet PostgreSQL niet
Naast al deze geweldige functionaliteit voor MySQL en MariaDB biedt ClusterControl 1.5 PostgreSQL nu ook een extra back-upmethode (pg_basebackup) die kan worden gebruikt voor online binaire back-ups. Back-ups die zijn gemaakt met pg_basebackup kunnen later worden gebruikt voor herstel op een bepaald tijdstip en als startpunt voor een logverzending of standby-servers voor streamingreplicatie.
Dat was het voor nu. Probeer ClusterControl v1.5 eens, speel wat met de nieuwe functies en laat ons weten wat je ervan vindt.