I de senaste fyra inläggen i bloggserien har vi behandlat distribution av klustring/replikering (MySQL/Galera, MySQL Replication, MongoDB &PostgreSQL), hantering och övervakning av dina befintliga databaser och kluster, prestandaövervakning och hälsa och i det senaste inlägget, hur du gör din installation mycket tillgänglig genom HAProxy och ProxySQL.
Så nu när du har dina databaser igång och mycket tillgängliga, hur säkerställer du att du har säkerhetskopior av dina data?
Du kan använda säkerhetskopior för flera saker:katastrofåterställning, för att tillhandahålla produktionsdata för att testa mot utveckling eller till och med för att tillhandahålla en slavnod. Det sista fallet täcks redan av ClusterControl. När du lägger till en ny (replika) nod till din replikeringsinställning, kommer ClusterControl att göra en säkerhetskopia/ögonblicksbild av huvudnoden och använda den för att bygga repliken. Den kan också använda en befintlig säkerhetskopia för att iscensätta repliken, om du vill undvika den extra belastningen på mastern. Efter att säkerhetskopian har extraherats, förberetts och databasen är igång, kommer ClusterControl automatiskt att ställa in replikering.
Skapa en omedelbar säkerhetskopia
Att skapa en säkerhetskopia är i huvudsak detsamma för Galera, MySQL-replikering, PostgreSQL och MongoDB. Du hittar avsnittet för säkerhetskopiering under ClusterControl> Säkerhetskopiering och som standard skulle du se en lista över skapade säkerhetskopior av klustret (om någon). Annars skulle du se en platshållare för att skapa en säkerhetskopia:
Härifrån kan du klicka på knappen "Skapa säkerhetskopia" för att göra en omedelbar säkerhetskopia eller schemalägga en ny säkerhetskopia:
Alla skapade säkerhetskopior kan också laddas upp till molnet genom att växla mellan "Ladda upp säkerhetskopia till molnet", förutsatt att du tillhandahåller fungerande molnuppgifter. Som standard kommer alla säkerhetskopior som är äldre än 31 dagar att raderas (kan konfigureras via inställningar för säkerhetskopiering) eller så kan du välja att behålla det för alltid eller definiera en anpassad period.
"Skapa säkerhetskopia" och "Schemalägg säkerhetskopiering" delar liknande alternativ förutom schemaläggningsdelen och inkrementella säkerhetskopieringsalternativ för den senare. Därför kommer vi att undersöka funktionen Skapa säkerhetskopiering (a.k.a omedelbar säkerhetskopiering) mer djupgående.
Eftersom alla dessa olika databaser har olika säkerhetskopieringsverktyg är det uppenbarligen en viss skillnad i de alternativ du kan välja. Till exempel med MySQL kan du välja mellan mysqldump och xtrabackup (fullständig och inkrementell). För MongoDB stöder ClusterControl mongodump och mongodb-consistent-backup (beta) medan PostgreSQL, pg_dump och pg_basebackup stöds. Om du är osäker på vilken du ska välja för MySQL, kolla in den här bloggen om skillnaderna och användningsfallen för mysqldump och xtrabackup.
Säkerhetskopiera MySQL och Galera
Som nämnts i föregående stycke kan du göra MySQL-säkerhetskopior med antingen mysqldump eller xtrabackup (fullständig eller inkrementell). I guiden "Skapa säkerhetskopia" kan du välja vilken värd du vill köra säkerhetskopian på, platsen där du vill lagra säkerhetskopieringsfilerna och dess katalog och specifika scheman (xtrabackup) eller scheman och tabeller (mysqldump).
Om noden du säkerhetskopierar tar emot (produktions)trafik och du är rädd att de extra diskskrivningarna kommer att bli påträngande, rekommenderas det att skicka säkerhetskopiorna till ClusterControl-värden genom att välja alternativet "Lagra på styrenhet". Detta gör att säkerhetskopieringen strömmar filerna över nätverket till ClusterControl-värden och du måste se till att det finns tillräckligt med utrymme på denna nod och att streamingporten är öppen på ClusterControl-värden.
Det finns också flera andra alternativ om du vill använda komprimering och komprimeringsnivån. Ju högre komprimeringsnivån är, desto mindre blir backupstorleken. Det kräver dock högre CPU-användning för komprimering och dekomprimering.
Om du skulle välja xtrabackup som metod för säkerhetskopieringen, skulle det öppna upp extra alternativ:desync, backup-lås, komprimering och xtrabackup parallella trådar/gzip. Alternativet desync är endast tillämpligt för att avsynkronisera en nod från ett Galera-kluster. Säkerhetskopieringslås använder en ny MDL-låstyp för att blockera uppdateringar av icke-transaktionella tabeller och DDL-satser för alla tabeller, vilket är mer effektivt för InnoDB-specifik arbetsbelastning. Om du kör på Galera Cluster, rekommenderas att aktivera det här alternativet.
Efter att ha schemalagt en omedelbar säkerhetskopiering kan du hålla reda på hur säkerhetskopieringen fortskrider i Aktivitet> Jobb :
När den är klar bör du kunna se en ny post under säkerhetskopieringslistan.
Säkerhetskopiera PostgreSQL
I likhet med omedelbara säkerhetskopior av MySQL kan du köra en säkerhetskopia på din Postgres-databas. Med Postgres-säkerhetskopior finns det två säkerhetskopieringsmetoder som stöds - pg_dumpall eller pg_basebackup. Observera att ClusterControl alltid kommer att utföra en fullständig säkerhetskopiering oavsett vald säkerhetskopieringsmetod.
Vi har täckt denna aspekt i denna information i Bli en PostgreSQL DBA - Logical &Physical PostgreSQL Backups.
Säkerhetskopiera MongoDB
För MongoDB stöder ClusterControl standarden mongodump och mongodb-consistent-backup som utvecklats av Percona. Den sistnämnda är fortfarande i betaversion som tillhandahåller klusterkonsekventa säkerhetskopior av MongoDB lämpliga för fragmenterade klusterinställningar. Eftersom det sönderdelade MongoDB-klustret består av flera replikuppsättningar, en konfigurationsreplikuppsättning och shardservrar, är det mycket svårt att göra en konsekvent säkerhetskopiering med endast mongodump.
Observera att i guiden behöver du inte välja en databasnod för att säkerhetskopieras. ClusterControl väljer automatiskt den sundaste sekundära repliken som backupnod. Annars kommer den primära att väljas. När säkerhetskopieringen körs kommer den valda säkerhetskopieringsnoden att vara låst tills säkerhetskopieringen är klar.
Schemaläggning av säkerhetskopior
Nu när vi har lekt med att skapa omedelbara säkerhetskopior kan vi nu utöka det genom att schemalägga säkerhetskopieringarna.
Schemaläggningen är mycket enkel att göra:du kan välja vilka dagar säkerhetskopieringen måste göras och vid vilken tidpunkt den måste köras.
För xtrabackup finns det en extra funktion:inkrementella säkerhetskopieringar. En inkrementell säkerhetskopiering kommer endast att säkerhetskopiera de data som ändrats sedan den senaste säkerhetskopieringen. Naturligtvis är de inkrementella säkerhetskopieringarna värdelösa om det inte skulle finnas full backup som utgångspunkt. Mellan två fullständiga säkerhetskopior kan du ha så många inkrementella säkerhetskopior som du vill. Men att återställa dem kommer att ta längre tid.
När de har schemalagts bör jobbet/jobben bli synliga under fliken "Schemalagd säkerhetskopiering" och du kan redigera dem genom att klicka på knappen "Redigera". Precis som med omedelbara säkerhetskopieringar kommer dessa jobb att schemalägga skapandet av en säkerhetskopia och du kan hålla reda på framstegen via fliken Aktivitet.
Säkerhetskopieringslista
Du hittar säkerhetskopieringslistan under ClusterControl> Säkerhetskopiering och detta ger dig en översikt på klusternivå över alla säkerhetskopior som gjorts. Om du klickar på varje post utökas raden och mer information om säkerhetskopian visas:
Varje säkerhetskopia åtföljs av en säkerhetskopieringslogg när ClusterControl utförde jobbet, som är tillgänglig under knappen "Fler åtgärder".
Säkerhetskopiering utanför webbplatsen i molnet
Eftersom vi nu har många säkerhetskopior lagrade på antingen databasvärdarna eller ClusterControl-värden, vill vi också säkerställa att de inte går vilse ifall vi råkar ut för ett totalt infrastrukturavbrott. (t.ex. DC i brand eller översvämmad) Därför låter ClusterControl dig lagra eller kopiera dina säkerhetskopior utanför platsen i molnet. De molnplattformar som stöds är Amazon S3, Google Cloud Storage och Azure Cloud Storage.
Uppladdningsprocessen sker direkt efter att säkerhetskopieringen har skapats (om du växlar mellan "Ladda upp säkerhetskopia till molnet") eller så kan du manuellt klicka på molnikonknappen i säkerhetskopieringslistan:
Välj molnuppgifterna och ange säkerhetskopieringsplatsen i enlighet med detta:
Återställ och/eller verifiera säkerhetskopia
Från gränssnittet för säkerhetskopiering kan du återställa en säkerhetskopia direkt till en värd i klustret genom att klicka på knappen "Återställ" för den specifika säkerhetskopian eller klicka på knappen "Återställ säkerhetskopia":
En trevlig funktion är att den kan återställa en nod eller ett kluster med hjälp av de fullständiga och inkrementella säkerhetskopiorna eftersom den kommer att hålla reda på den senaste fullständiga säkerhetskopian som gjordes och starta den inkrementella säkerhetskopieringen därifrån. Sedan kommer den att gruppera en fullständig säkerhetskopia tillsammans med alla inkrementella säkerhetskopior till nästa fullständiga säkerhetskopia. Detta gör att du kan återställa från den fullständiga säkerhetskopian och använda de inkrementella säkerhetskopiorna ovanpå den.
ClusterControl stöder återställning på en befintlig databasnod eller återställning och verifiering på en ny fristående värd:
Dessa två alternativ är ganska lika, förutom att verifiera ett har extra alternativ för den nya värdinformationen. Om du följer återställningsguiden måste du ange en ny värd. 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.
När säkerhetskopian har återställts och verifierats får du ett meddelande om återställningsstatus och noden kommer att stängas av automatiskt.
Återställning vid tidpunkt
För MySQL kan både xtrabackup och mysqldump användas för att utföra punkt-i-tid återställning och även för att tillhandahålla en ny replikeringsslav för master-slave replikering eller Galera Cluster. 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:
När PITR-kompatibelt alternativ växlas, är databas- och tabellfälten nedtonade eftersom ClusterControl alltid kommer att utföra en fullständig säkerhetskopiering mot alla databaser, händelser, triggers och rutiner för mål-MySQL-servern.
Återställer nu säkerhetskopian. Om säkerhetskopieringen är kompatibel med PITR, kommer ett alternativ att presenteras för att utföra en punkt-i-tid-återställning. Du kommer att ha två alternativ för det - "Tidsbaserat" och "Positionsbaserat". För "Tidsbaserad" kan du bara passera dagen och tiden. För "Positionsbaserad" kan du skicka den exakta positionen dit du vill återställa. Det är ett mer exakt sätt att återställa, även om du kan behöva få binlog-positionen med hjälp av mysqlbinlog-verktyget. Mer information om tidpunktsåterställning finns i den här bloggen.
Säkerhetskopieringskryptering
Universellt stöder ClusterControl säkerhetskopieringskryptering för MySQL, MongoDB och PostgreSQL. Säkerhetskopieringar krypteras i vila med AES-256 CBC-algoritm. En automatiskt genererad nyckel kommer att lagras i klustrets konfigurationsfil under /etc/cmon.d/cmon_X.cnf (där X är kluster-ID):
$ sudo grep backup_encryption_key /etc/cmon.d/cmon_1.cnf
backup_encryption_key='JevKc23MUIsiWLf2gJWq/IQ1BssGSM9wdVLb+gRGUv0='Om säkerhetskopieringsdestinationen inte är lokal överförs säkerhetskopiorna i krypterat format. Den här funktionen kompletterar den externa säkerhetskopieringen på molnet, där vi inte har full tillgång till det underliggande lagringssystemet.
Sluta tankar
Vi visade dig hur du säkerhetskopierar dina data och hur du lagrar dem säkert utanför webbplatsen. Återhämtning är alltid en annan sak. ClusterControl kan automatiskt återställa dina databaser från säkerhetskopior som gjorts i det förflutna som lagras i lokaler eller kopieras tillbaka från molnet.
Uppenbarligen är det mer att säkra din data, särskilt när det gäller att säkra dina anslutningar. Vi kommer att ta upp detta i nästa blogginlägg!