Hur man schemalägger databassäkerhetskopior med ClusterControl

Databassäkerhetskopiering är en kritisk del av databashantering och måste planeras noggrant. Det räcker inte att schemalägga en säkerhetskopia, säkerhetskopieringsdata måste också verifieras för konsekvens och integritet. Det finns andra överväganden som kryptering och arkivering utanför platsen. En bra backup-hanterare skulle ha funktioner som tar hänsyn till alla dessa olika överväganden.

I det här blogginlägget kommer vi att undersöka hur du kan schemalägga dina databassäkerhetskopior med ClusterControl.

Säkerhetskopiering av databas med ClusterControl

ClusterControl stöder ett antal säkerhetskopieringsmetoder beroende på klustertyp, som sammanfattas i följande tabell:

När du schemalägger säkerhetskopiering med ClusterControl kan var och en av säkerhetskopieringsmetoderna konfigureras med en uppsättning alternativ för hur du vill att säkerhetskopieringen ska köras. Olika databasarbetsbelastningar och säkerhetskopieringsstrategier skulle kräva stöd för olika funktioner, till exempel:

• Disk IOPS-strypning
• Nätverksbegränsning
• Säkerhetskopieringslås
• Kryptering
• Kompression
• Lagringsperiod
• Verifiering

ClusterControl kommer automatiskt att ställa in ett antal säkerhetskopieringsalternativ, enligt bästa praxis från den specifika databasleverantören. Till exempel, om måldatabasnoden har binär logg aktiverad, kommer den att lägga till en ytterligare flagga, --master-data att inkludera de binära loggkoordinaterna (filnamn och position) för den dumpade servern. Om det är en Galera-nod och säkerhetskopieringsmetoden är xtrabackup, kommer ClusterControl att lägga till en extra flagga, --galera-info som innehåller det lokala nodtillståndet vid tidpunkten för säkerhetskopieringen.

Planera en säkerhetskopia

Innan vi schemalägger någon backup måste vi planera hur backupoperationen ska vara. Att svara på följande exempelfrågor skulle vara till hjälp innan du skapar ett backupschema:

• Vilken backupmetod vill du använda? Vissa säkerhetskopieringsmetoder är icke-blockerande, men mycket resurskrävande. Förstå avvägningarna så att du inte blir förvånad över hur processen beter sig i produktionen.
• Hur ofta vill du säkerhetskopiera dina databaser? Att köra en fullständig säkerhetskopiering kan vara smärtsamt om säkerhetskopieringsintervallet är för kort. Du behöver förmodligen en blandning av fullständiga och inkrementella säkerhetskopior.
• Hur snabbt vill du återställa dina data? Fysisk säkerhetskopiering är vanligtvis mycket snabbare än logisk säkerhetskopiering när det gäller full återställningstid. Å andra sidan är logisk säkerhetskopiering vanligtvis snabbare för partiell återställning.
• Hur stor är din datastorlek? I vissa fall är logisk säkerhetskopiering inte ett bra val för stora databaser, och binär säkerhetskopiering är den enda vägen att gå.
• Hur mycket ledigt utrymme har du för att lagra din säkerhetskopia? Säkerhetskopieringar tenderar att äta mycket utrymme. Bestäm om kompression behövs och vilken kompressionsnivå du har råd med. Bättre komprimering kräver högre CPU-användning.
• Vad händer om backupservern är nere under backuptiden? Ska säkerhetskopieringen failover till en annan tillgänglig värd? Att hoppa över en säkerhetskopia på grund av ett underhållsfönster är vanligtvis inte en bra idé.
• Hur säkerställer man integriteten för den skapade säkerhetskopian? Kom ihåg att en säkerhetskopia inte är en säkerhetskopia om den inte går att återställa.
• Litar du på säkerhetskopieringslagringen? Kryptering kan vara en bra idé för att skydda dina data.

I allmänhet, genom att svara på dessa frågor, kan vi komma på en lämplig säkerhetskopieringsstrategi. Listan med frågor kan vara längre beroende på din säkerhetskopierings- och återställningspolicy.

Vi har täckt det här kapitlet i detalj i vårt whitepaper, The DevOps Guide to Database Backups for MySQL och MariaDB.

Schemalägga en säkerhetskopia
 

Med ClusterControl är schemaläggning ganska enkel. Gå direkt till Säkerhetskopiering -> Skapa säkerhetskopia -> Schemalägg säkerhetskopiering och du kommer att presenteras med följande dialogruta:

Beroende på klustertyp kan alternativen vara olika, som visas i följande skärmdumpar för PostgreSQL och MongoDB:

De flesta av alternativen är självförklarande och behandlas i detaljer i användarhandboken. När schemat har skapats kan du redigera konfigurationssäkerhetskopiorna, aktivera/inaktivera säkerhetskopian eller ta bort schemat under fliken "Schemalagda säkerhetskopior":

Observera att när du schemalägger säkerhetskopiering med ClusterControl måste all tid schemaläggas i UTC-tidszonen för ClusterControl-servern. Anledningen bakom detta är att minska förvirringen av säkerhetskopieringskörningstiden. När man arbetar med ett kluster kan databasservrarna vara spridda i olika tidszoner och olika geografiska områden. Genom att använda en referenstidszon för att hantera dem alla säkerställer du att säkerhetskopiorna alltid körs vid rätt tidpunkt.

Du kan övervaka förloppet för en säkerhetskopiering genom att titta på Aktivitet -> Jobb när tiden är inne. Om säkerhetskopieringsjobbet misslyckades, skulle du se felet direkt:

Ovanstående logg är också tillgänglig under fliken Säkerhetskopiering på varje backuppost:

Kontroller och verifiering efter säkerhetskopiering

När säkerhetskopieringsjobbet är klart betyder det inte att ditt ansvar är över. Det finns ett par saker som måste följas upp. Den viktigaste är tillståndet för den skapade säkerhetskopian. ClusterControl tillhandahåller e-postmeddelanden och kommer att meddela dig om statusen. Denna aviseringstjänst är naturligtvis konfigurerbar baserat på svårighetsgraden under Inställningar -> Allmänna inställningar -> Inställningar för e-postmeddelanden -> Säkerhetskopiering:

Leverera innebär att ClusterControl kommer att skicka ett e-postmeddelande omedelbart efter att ett larm för denna komponent har utlösts. Du kan också konfigurera det som Ignorera eller Digest, där ClusterControl skickar en daglig sammanfattning av larm som har utlösts.

Om säkerhetskopian har skapats, rekommenderas det starkt att verifiera om säkerhetskopian är återställbar. Du kan använda funktionen för säkerhetskopieringsverifiering genom att klicka på knappen "Återställ" för det valda säkerhetskopierings-ID:t och du kommer att presenteras med två återställningsalternativ:

"Återställ och verifiera på fristående värd" kräver en separat värd, som inte redan är en del av databasinställningen. ClusterControl kommer först att distribuera en MySQL-instans på målvärden, starta tjänsten, kopiera säkerhetskopian från säkerhetskopieringsförrådet och starta återställningen. När du är klar kan du välja att antingen stänga av servern när den har återställts eller låta den köras så att du kan göra ytterligare undersökningar på servern.

Hushållning är också viktigt för att bara behålla de användbara säkerhetskopiorna i ditt lager. Konfigurera därför säkerhetskopieringen efter behov. Som standard rensar ClusterControl säkerhetskopior som är äldre än 30 dagar. Du kan också anpassa vart och ett av säkerhetskopieringsscheman med olika lagringsperioder.

Om backuplagringen närmar sig några utrymmesgränser, eller om du vill arkivera din backup offside, kan du välja att manuellt radera filen genom att klicka på papperskorgen eller ladda upp den till molnet, som markerats nedan:

I skrivande stund stöds AWS S3 och GCP Cloud Storage. Molnets autentiseringsuppgifter måste vara förkonfigurerade under sidomenyn -> Integrationer -> Molnleverantörer.

Det var allt, gott folk. Lycka till med klustringen!