Kärnan i ClusterControl är dess automatisering, liksom att se till att dina data är säkert säkerhetskopierade och redo för återställning när något går fel. Att ha en effektiv säkerhetskopieringsstrategi och katastrofåterställningsplan är nyckeln till framgången för alla program eller miljöer.
I vår senaste version, ClusterControl 1.5, har vi introducerat ett antal förbättringar för säkerhetskopiering av MySQL och MariaDB-baserade system.
En av de viktigaste förbättringarna är möjligheten att säkerhetskopiera från ClusterControl till den molnleverantör du väljer. Molnleverantörer som Google Cloud Services och Amazon S3 erbjuder var och en praktiskt taget obegränsad lagring, vilket minskar behovet av lokalt utrymme. Detta gör att du kan behålla dina säkerhetskopior längre, så länge du vill och inte ha problem med lokalt diskutrymme.
Låt oss utforska alla spännande nya säkerhetskopieringsfunktioner för ClusterControl 1.5...
Redesign av guiden för säkerhetskopiering/återställning
Först och främst kommer du att märka att säkerhetskopierings- och återställningsguider har förnyats för att förbättra användarupplevelsen. Den kommer nu att laddas som en sidomeny till höger på skärmen:
Säkerhetskopieringslistan får också en mindre justering där säkerhetskopieringsinformation visas när du klickar på den specifika säkerhetskopian:
Du kommer att kunna se säkerhetskopieringsplatsen och vilka databaser som finns i säkerhetskopian. Det finns också alternativ för att återställa säkerhetskopian eller ladda upp den till molnet.
PITR-kompatibel säkerhetskopiering
ClusterControl utför standard säkerhetskopiering av mysqldump med separata schema- och datadumpar. Detta gör det enkelt att återställa partiella säkerhetskopior. Det bryter dock säkerhetskopieringens konsistens (schema och data dumpas i två separata sessioner), och kan därför inte användas för att tillhandahålla en slav eller punkt-i-tidsåterställning.
En mysqldump PITR-kompatibel säkerhetskopia innehåller en enda dumpfil, med GTID-information, binlogfil och position. Således kommer endast databasnoden som producerar binär logg att ha alternativet "PITR-kompatibelt" tillgängligt, som markerats i skärmdumpen nedan:
När PITR-kompatibelt alternativ växlas, är databas- och tabellfälten nedtonade eftersom ClusterControl alltid kommer att utföra säkerhetskopiering mot alla databaser, händelser, triggers och rutiner för mål-MySQL-servern.
Följande rader kommer att visas i de första ~50 raderna i den färdiga dumpfilen:
$ 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;
...Informationen kan användas för att bygga slavar från säkerhetskopiering, eller utföra punkt-i-tidsåterställning tillsammans med binära loggar, där du kan starta återställningen från MASTER_LOG_FILE och MASTER_LOG_POS som rapporteras i dumpfilen med hjälp av verktyget "mysqlbinlog". Observera att binära loggar inte säkerhetskopieras av ClusterControl.
Bygg slavar från säkerhetskopiering En annan funktion är möjligheten att bygga en slav direkt från en PITR-kompatibel säkerhetskopia, istället för att göra det från en vald master. Detta är en stor fördel eftersom det avlastar huvudservern. Det här alternativet kan användas med MySQL-replikering eller Galera Cluster. En befintlig säkerhetskopia kan användas för att bygga om en befintlig replikeringsslav eller lägga till en ny replikeringsslav under iscensättningsfasen, som visas i följande skärmdump:
När iscensättningen är klar kommer slaven att ansluta till den valda mastern och börja komma ikapp. Tidigare har ClusterControl utfört en streaming backup direkt från den valda mastern med hjälp av Percona Xtrabackup. Detta kan påverka masterns prestanda när en stor datauppsättning skalas ut, trots att operationen inte är blockerande på mastern. Med det nya alternativet, om säkerhetskopian lagras på ClusterControl, kommer endast dessa värdar (ClusterControl + slaven) att vara upptagna när data lagras på slaven.
Säkerhetskopiera till molnet
Säkerhetskopieringar kan nu laddas upp automatiskt i molnet. Detta kräver att en ClusterControl-modul är installerad, kallad clustercontrol-cloud (molnintegreringsmodul) och clustercontrol-clud (Hämta/ladda upp CLI för moln) som är tillgängliga i v1.5 och senare. Uppgraderingsinstruktionerna har medföljt dessa paket och de kommer utan någon extra konfiguration. För närvarande är de molnplattformar som stöds Amazon Web Services och Google Cloud Platform. Molnuppgifter konfigureras under ClusterControl -> Inställningar -> Integrationer -> Molnleverantörer.
När du skapar eller schemalägger en säkerhetskopia bör du se följande ytterligare alternativ när "Ladda upp säkerhetskopia till molnet" är växlad:
Funktionen tillåter en engångsuppladdning eller att schemalägga säkerhetskopior som ska laddas upp efter färdigställandet (Amazon S3 eller Google Cloud Storage). Du kan sedan ladda ner och återställa säkerhetskopiorna efter behov.
Anpassad komprimering för mysqldump
Denna funktion introducerades faktiskt först med ClusterControl v1.4.2 efter lanseringen. Vi lade till en säkerhetskopieringsnivå baserad på gzip. Tidigare använde ClusterControl standard backup-komprimering (nivå 6) om backupdestinationen var på kontrollernoden. Den lägsta komprimeringen (nivå 1 - snabbast, mindre komprimering) användes om backupdestinationen låg på själva databasvärden, för att säkerställa minimal påverkan på databasen under komprimeringsoperationen.
I den här versionen har vi polerat komprimeringsaspekten och du kan nu anpassa komprimeringsnivån, oavsett destination för backup. När du uppgraderar din ClusterControl-instans kommer alla schemalagda säkerhetskopior att konverteras automatiskt till att använda nivå 6, om du inte uttryckligen redigerar dem i v1.5.
Säkerhetskopieringskomprimering är avgörande när din datauppsättning är stor, i kombination med en lång säkerhetskopieringspolicy, medan lagringsutrymmet är begränsat. Mysqldump, som är textbaserat, kan dra nytta av komprimering med besparingar på upp till 60 % av diskutrymmet av den ursprungliga filstorleken. Vid vissa tillfällen är det högsta kompressionsförhållandet det bästa alternativet, även om det kommer till priset av längre dekompression vid återställning.
Bonusfunktion:Automatisk säkerhetskopiering
Som gamla systemadministratörer säger - En säkerhetskopia är inte en säkerhetskopia om den inte går att återställa. Backupverifiering är något som vanligtvis försummas av många. Vissa systemadministratörer har utvecklat interna rutiner för detta, vanligtvis mer manuella än automatiserade. Att automatisera det är svårt, främst på grund av komplexiteten i operationen som helhet - med början från värdprovisionering, MySQL-installation och förberedelse, överföring av säkerhetskopior, dekomprimering, återställningsoperation, verifieringsprocedurer och slutligen att städa upp systemet efter processen. Alla dessa krångel gör att människor försummar en så viktig aspekt av en pålitlig säkerhetskopiering. I allmänhet bör ett backupåterställningstest göras minst en gång i månaden, eller vid betydande förändringar i datastorlek eller databasstruktur. Hitta ett schema som fungerar för dig och formalisera det med ett schemalagt evenemang.
ClusterControl kan automatisera säkerhetskopieringsverifieringen genom att utföra återställningen på en ny värd, utan att kompromissa med någon av verifieringsprocedurerna som nämns ovan. Detta kan göras efter en viss fördröjning, eller direkt efter att säkerhetskopieringen har slutförts. Den kommer att rapportera säkerhetskopieringsstatus baserat på utgångskoden för återställningsåtgärden, utföra automatisk avstängning om säkerhetskopieringen är verifierad, eller helt enkelt låta den återställda värden köra så att du utför ytterligare manuella verifieringar av data.
När du skapar eller schemalägger en säkerhetskopia har du ytterligare alternativ om "Verifiera säkerhetskopiering" är växlad:
Om "Installera databasprogramvara" är aktiverat kommer ClusterControl att ta bort alla befintliga MySQL-installationer på målvärden och installera om databasprogramvaran med samma version som den befintliga MySQL-servern. Annars, om du har en specifik inställning för den återställda värden, kan du hoppa över det här alternativet. Resten av alternativen är självförklarande.
Bonusfunktion:Glöm inte PostgreSQL
Utöver all denna fantastiska funktionalitet för MySQL och MariaDB ClusterControl 1.5 ger PostgreSQL nu även en extra säkerhetskopieringsmetod (pg_basebackup) som kan användas för binära säkerhetskopieringar online. Säkerhetskopieringar tagna med pg_basebackup kan användas senare för punkt-i-tid återställning och som utgångspunkt för en loggleverans eller strömmande replikeringsberedskapsservrar.
Det var allt för nu. Ge ClusterControl v1.5 ett försök, lek med de nya funktionerna och låt oss veta vad du tycker.