Säkerhetskopiering - en av de viktigaste sakerna att ta hand om när du hanterar databaser. Det sägs att det finns två typer av människor - de som säkerhetskopierar sina data och de som kommer att säkerhetskopiera sina data. I det här blogginlägget kommer vi att diskutera god praxis kring säkerhetskopiering och visa dig hur du kan bygga ett pålitligt säkerhetskopieringssystem med ClusterControl.
Vi kommer att se hur ClusterControl's ger dig centraliserad säkerhetskopieringshantering för MySQL, MariaDB, MongoDB och PostgreSQL. Det ger dig heta säkerhetskopior av stora datamängder, punktåterställning, datakryptering i vila och under transport, dataintegritet via automatisk återställningsverifiering, molnsäkerhetskopiering (AWS, Google och Azure) för katastrofåterställning, lagringspolicyer för att säkerställa efterlevnad och automatiska varningar och rapportering.
Säkerhetskopieringstyper
Det finns två huvudtyper av säkerhetskopiering som vi kan göra i ClusterControl:
- Logisk säkerhetskopiering - säkerhetskopiering av data lagras i ett läsbart format som SQL
- Fysisk säkerhetskopiering – säkerhetskopiering innehåller binär data
Båda kompletterar varandra - logisk säkerhetskopiering gör att du (mer eller mindre enkelt) kan hämta upp till en enda rad med data. Fysiska säkerhetskopieringar skulle kräva mer tid för att åstadkomma det, men å andra sidan låter de dig återställa en hel värd mycket snabbt (något som kan ta timmar eller till och med dagar när du använder logisk säkerhetskopiering).
ClusterControl stöder säkerhetskopiering för MySQL/MariaDB/Percona Server, PostgreSQL och MongoDB.
Schemalägg säkerhetskopiering
Att starta en säkerhetskopia i ClusterControl är enkelt och effektivt med hjälp av en guide. Att schemalägga en säkerhetskopia ger användarvänlighet och tillgänglighet till andra funktioner som kryptering, automatisk test/verifiering av säkerhetskopiering eller molnarkivering.
Schemalagda säkerhetskopior som är tillgängliga kommer att listas på fliken Schemalagda säkerhetskopieringar som visas i bilden nedan:
Som en god praxis för att schemalägga en säkerhetskopia måste du redan ha din definierade säkerhetskopieringslagring och en daglig säkerhetskopiering rekommenderas. Men det beror också på vilken data du behöver, trafiken du kan förvänta dig och tillgängligheten av data när du behöver dem, särskilt under dataåterställning där data av misstag har raderats eller en diskkorruption - vilket är oundvikligt. Det finns även situationer där dataförlust är reproducerbar eller kan dupliceras manuellt som till exempel rapportgenerering, miniatyrbilder eller cachad data. Även om frågan beror på hur omedelbart du behöver dem när en katastrof inträffar; när det är möjligt skulle du vilja ta både mysqldump och xtrabackup säkerhetskopior på daglig basis för MySQL att utnyttja den logiska och fysiska säkerhetskopieringen. För att täcka ännu fler baser kanske du vill schemalägga flera inkrementella xtrabackup-körningar per dag. Detta kan spara lite diskutrymme, disk I/O eller till och med CPU I/O än att ta en fullständig säkerhetskopia.
I ClusterControl kan du enkelt schemalägga dessa olika typer av säkerhetskopior. Det finns ett par inställningar att ta ställning till. Du kan lagra en säkerhetskopia på styrenheten eller lokalt, på den databasnod där säkerhetskopian tas. Du måste bestämma dig för var säkerhetskopian ska lagras och vilka databaser du vill säkerhetskopiera - alla datauppsättningar eller separata scheman? Se bilden nedan:
Den avancerade inställningen skulle dra fördel av en cron-liknande konfiguration för mer granularitet. Se bilden nedan:
Närhelst ett fel inträffar, hanterar ClusterControl dessa problem effektivt och producerar loggar för ytterligare diagnos av säkerhetskopieringsfelet.
Beroende på vilken säkerhetskopieringstyp du har valt finns det separata inställningar att konfigurera. För Xtrabackup och Galera Cluster kan du ha alternativen att välja vilka inställningar som din fysiska säkerhetskopiering ska tillämpas vid körning. Se nedan:
- Använd komprimering
- Kompressionsnivå
- Avsynkronisera nod under säkerhetskopiering
- Säkerhetskopieringslås
- Lås DDL per tabell
- Xtrabackup Parallel Copy Threads
- Strömhastighet för nätverksströmning (MB/s)
- Använd PIGZ för parallell gzip
- Aktivera kryptering
- Behållning
Du kan se, i bilden nedan, hur du kan flagga alternativen i enlighet med detta och det finns verktygstipsikoner som ger mer information om de alternativ du vill använda för din säkerhetskopieringspolicy.
Beroende på din säkerhetskopieringspolicy kan ClusterControl skräddarsys i enlighet med bästa praxis för att ta dina säkerhetskopior som är tillgängliga uppdaterade. När du definierar din säkerhetskopieringspolicy, förväntas du ha din nödvändiga konfiguration tillgänglig från hårdvara till mjukvara till moln, hållbarhet, hög tillgänglighet eller skalbarhet.
När du tar säkerhetskopior på ett Galera-kluster är det bra att ställa in Galera-noden wsrep_desync=ON medan säkerhetskopieringen körs. Detta tar bort noden från att delta i flödeskontrollen och skyddar hela klustret från replikeringsfördröjning, särskilt om dina data som ska säkerhetskopieras är stora. I ClusterControl, kom ihåg att detta också kan ta bort din målbackupnod från lastbalanseringsuppsättningen. Detta gäller särskilt om du använder HAProxy-, ProxySQL- eller MaxScale-proxies. Om du har ställt in en varningshanterare om noden avsynkroniseras, kan du stänga av under den period då säkerhetskopieringen har utlösts.
Ett annat populärt sätt att minimera inverkan av en säkerhetskopia på ett Galera Cluster eller en replikeringsmaster är att distribuera en replikeringsslav och sedan använda den som en källa för säkerhetskopior - på så sätt kommer Galera Cluster inte att påverkas vid något tillfälle eftersom säkerhetskopian på slaven är frikopplad från klustret.
Du kan distribuera en sådan slav med bara några klick med ClusterControl. Se bilden nedan:
och när du klickar på den knappen kan du välja vilka noder du vill ställa in en slav på. Se till att nodernas binära loggning är aktiverad. Aktivering av den binära loggen kan också göras genom ClusterControl, vilket ökar möjligheterna att administrera din önskade master. Se bilden nedan:
och du kan också ställa in befintlig replikeringsslav,
För PostgreSQL har du alternativ att säkerhetskopiera antingen logiska eller fysiska säkerhetskopior. I ClusterControl kan du utnyttja dina PostgreSQL-säkerhetskopior genom att välja pg_dump eller pg_basebackup. pg_basebackup kommer inte att fungera för versioner äldre än 9.3.
För MongoDB erbjuder ClusterControl mongodump eller mongodb konsekvent. Du kanske måste notera att mongodb consistent inte stöder RHEL 7 men du kanske kan installera det manuellt.
Som standard kommer ClusterControl att lista en rapport för alla säkerhetskopior som har tagits, framgångsrika eller misslyckade. Se nedan:
Du kan kontrollera listan över säkerhetskopieringsrapporter som har skapats eller schemalagts med ClusterControl. I listan kan du se loggarna för vidare utredning och diagnos. Till exempel, om säkerhetskopieringen slutfördes korrekt enligt din önskade säkerhetskopieringspolicy, om komprimering och kryptering är korrekt inställd eller om den önskade säkerhetskopieringsdatastorleken är korrekt. Det här är ett bra sätt att göra en snabb förnuftskontroll - om din datauppsättning är cirka 1 GB stor, finns det inget sätt att en fullständig säkerhetskopia kan vara så liten som 100 KB - något måste ha gått fel någon gång.
Återställning efter katastrof
Att lagra säkerhetskopior inom klustret (antingen direkt på en databasnod eller på ClusterControl-värden) är praktiskt när du snabbt vill återställa dina data:alla säkerhetskopior finns på plats och kan dekomprimeras och återställas omgående. När det kommer till Disaster Recovery (DR) är detta kanske inte det bästa alternativet. Olika problem kan hända - servrar kan krascha, nätverket kanske inte fungerar tillförlitligt, till och med hela datacenter kanske inte är tillgängliga på grund av någon form av avbrott. Det kan hända oavsett om du arbetar med en mindre tjänsteleverantör med ett enda datacenter, eller en global leverantör som Amazon Web Services. Det är därför inte säkert att förvara alla dina ägg i en enda korg - du bör se till att du har en kopia av din säkerhetskopia lagrad på någon extern plats. ClusterControl stöder Amazon S3, Google Storage och Azure Cloud Storage .
För dem som vill implementera sina egna DR-policyer, lagras ClusterControl-säkerhetskopior i en snyggt strukturerad katalog. Du har också möjlighet att ladda upp din säkerhetskopia till molnet. Se bilden nedan:
Du kan välja och ladda upp till Amazon Web Services, Google Cloud och Microsoft Azure. Se bilden nedan:
Som en god praxis när du arkiverar dina databassäkerhetskopior, se till att din målmolndestination är baserad på samma region som dina databasservrar, eller åtminstone den närmaste. Se till att den erbjuder hög tillgänglighet, hållbarhet och skalbarhet; eftersom du måste tänka på hur ofta och omedelbart du behöver dina uppgifter.
Förutom att skapa en logisk eller fysisk säkerhetskopia för din DR, kan skapa en fullständig ögonblicksbild av dina data (t.ex. med LVM Snapshot, Amazon EBS Snapshots eller Volume Snapshots om du använder Veritas filsystem) på den specifika noden öka din backupåterställning. Du kan också använda WAL (för Postgres) för din Point In Time Recovery (PITR) eller dina MySQL binära loggar för din PITR. Därför måste du tänka på att du kan behöva skapa din egen arkivering för din PITR. Så det går alldeles utmärkt att bygga och distribuera din egen uppsättning skript och hantera DR enligt dina exakta krav.
Ett annat bra sätt att implementera en Disaster Recovery-policy är att använda en asynkron replikeringsslav – något vi nämnde tidigare i det här blogginlägget. Du kan distribuera en sådan asynkron slav på en avlägsen plats, något annat datacenter kanske, och sedan använda det för att göra säkerhetskopior och lagra dem lokalt på den slaven. Naturligtvis skulle du vilja ta en lokal säkerhetskopia av ditt kluster för att ha det lokalt om du skulle behöva återställa klustret. Att flytta data mellan datacenter kan ta lång tid, så att ha en säkerhetskopia tillgänglig lokalt kan spara lite tid. Om du förlorar åtkomsten till ditt huvudproduktionskluster kan du fortfarande ha åtkomst till slaven. Den här inställningen är mycket flexibel - för det första har du en körande MySQL-värd med dina produktionsdata så det borde inte vara för svårt att distribuera hela din applikation på DR-webbplatsen. Du kommer också att ha säkerhetskopior av din produktionsdata som du kan använda för att skala ut din DR-miljö.
Slutligen och viktigast av allt, en säkerhetskopia som inte har testats förblir en overifierad säkerhetskopia, alias Schroedinger Backup. För att säkerställa att du har en fungerande säkerhetskopia måste du utföra ett återställningstest. ClusterControl erbjuder ett sätt att automatiskt verifiera och testa din säkerhetskopia.
Vi hoppas att detta ger dig tillräckligt med information för att bygga en säker och pålitlig säkerhetskopiering av dina databaser med öppen källkod.