In de afgelopen vier berichten van de blogreeks hebben we het gehad over de implementatie van clustering/replicatie (MySQL/Galera, MySQL-replicatie, MongoDB &PostgreSQL), beheer en monitoring van uw bestaande databases en clusters, prestatiebewaking en gezondheid en in de laatste post, hoe u uw installatie maximaal beschikbaar maakt via HAProxy en ProxySQL.
Hoe zorgt u ervoor dat u back-ups van uw gegevens hebt, nu u uw databases up-and-running en in hoge mate beschikbaar heeft?
U kunt back-ups voor meerdere dingen gebruiken:noodherstel, om productiegegevens te leveren om te testen tegen ontwikkeling of zelfs om een slave-knooppunt in te richten. Dit laatste geval wordt al gedekt door ClusterControl. Wanneer je een nieuwe (replica) node toevoegt aan je replicatie setup, zal ClusterControl een backup/snapshot maken van de master node en deze gebruiken om de replica te bouwen. Het kan ook een bestaande back-up gebruiken om de replica te stagen, voor het geval u die extra belasting van de master wilt vermijden. Nadat de back-up is uitgepakt, voorbereid en de database actief is, zal ClusterControl automatisch replicatie instellen.
Een directe back-up maken
In wezen is het maken van een back-up hetzelfde voor Galera, MySQL-replicatie, PostgreSQL en MongoDB. U vindt de back-upsectie onder ClusterControl> Back-up en standaard ziet u een lijst met gemaakte back-ups van het cluster (indien aanwezig). Anders zou je een tijdelijke aanduiding zien om een back-up te maken:
Vanaf hier kunt u op de knop "Back-up maken" klikken om direct een back-up te maken of een nieuwe back-up te plannen:
Alle gemaakte back-ups kunnen ook naar de cloud worden geüpload door "Upload back-up naar de cloud" in te schakelen, op voorwaarde dat u werkende cloudreferenties opgeeft. Standaard worden alle back-ups die ouder zijn dan 31 dagen verwijderd (configureerbaar via de instellingen voor het bewaren van back-ups) of u kunt ervoor kiezen deze voor altijd te bewaren of een aangepaste periode te definiëren.
"Back-up maken" en "Back-up plannen" delen vergelijkbare opties, behalve het planningsgedeelte en incrementele back-upopties voor de laatste. Daarom gaan we dieper in op de functie Back-up maken (ook wel een directe back-up genoemd).
Aangezien al deze verschillende databases verschillende back-uptools hebben, is er duidelijk een verschil in de opties die u kunt kiezen. Met MySQL kun je bijvoorbeeld kiezen tussen mysqldump en xtrabackup (volledig en incrementeel). Voor MongoDB ondersteunt ClusterControl mongodump en mongodb-consistent-backup (bèta), terwijl PostgreSQL, pg_dump en pg_basebackup worden ondersteund. Als je twijfelt welke je moet kiezen voor MySQL, bekijk dan deze blog over de verschillen en use cases voor mysqldump en xtrabackup.
Back-up maken van MySQL en Galera
Zoals vermeld in de vorige paragraaf, kunt u MySQL-back-ups maken met mysqldump of xtrabackup (volledig of incrementeel). In de wizard "Back-up maken" kunt u kiezen op welke host u de back-up wilt uitvoeren, de locatie waar u de back-upbestanden wilt opslaan en de map en specifieke schema's (xtrabackup) of schema's en tabellen (mysqldump).
Als het knooppunt waarvan u een back-up maakt (productie)verkeer ontvangt, en u vreest dat de extra schrijfbewerkingen opdringerig zullen worden, is het raadzaam de back-ups naar de ClusterControl-host te sturen door de optie "Opslaan op controller" te kiezen. Dit zorgt ervoor dat de back-up de bestanden via het netwerk naar de ClusterControl-host streamt en u moet ervoor zorgen dat er voldoende ruimte beschikbaar is op dit knooppunt en dat de streamingpoort is geopend op de ClusterControl-host.
Er zijn ook verschillende andere opties of u compressie en het compressieniveau wilt gebruiken. Hoe hoger het compressieniveau, hoe kleiner de back-upgrootte. Het vereist echter een hoger CPU-gebruik voor het compressie- en decompressieproces.
Als je xtrabackup zou kiezen als de methode voor de back-up, zou dit extra opties openen:desync, back-upvergrendelingen, compressie en xtrabackup parallelle threads/gzip. De desync-optie is alleen van toepassing om een node van een Galera-cluster te desync. Back-upvergrendelingen gebruiken een nieuw MDL-vergrendelingstype om updates van niet-transactionele tabellen en DDL-instructies voor alle tabellen te blokkeren, wat efficiënter is voor InnoDB-specifieke werkbelasting. Als u op Galera Cluster draait, wordt aanbevolen deze optie in te schakelen.
Na het plannen van een directe back-up kunt u de voortgang van de back-uptaak volgen in de Activiteit> Taken :
Nadat het klaar is, zou u een nieuw item onder de back-uplijst moeten kunnen zien.
Back-up maken van PostgreSQL
Net als bij de directe back-ups van MySQL, kunt u een back-up uitvoeren op uw Postgres-database. Met Postgres-back-ups worden twee back-upmethoden ondersteund - pg_dumpall of pg_basebackup. Houd er rekening mee dat ClusterControl altijd een volledige back-up zal maken, ongeacht de gekozen back-upmethode.
We hebben dit aspect in deze details behandeld in Word een PostgreSQL DBA - Logische en fysieke PostgreSQL-back-ups.
Back-up maken van MongoDB
Voor MongoDB ondersteunt ClusterControl de standaard mongodump en mongodb-consistent-backup ontwikkeld door Percona. De laatste is nog steeds in bètaversie die clusterconsistente point-in-time back-ups van MongoDB biedt die geschikt zijn voor shard-clusterconfiguraties. Aangezien het shard MongoDB-cluster uit meerdere replicasets, een configuratiereplicaset en shardservers bestaat, is het erg moeilijk om een consistente back-up te maken met alleen mongodump.
Houd er rekening mee dat u in de wizard geen databaseknooppunt hoeft te kiezen waarvan u een back-up wilt maken. ClusterControl kiest automatisch de gezondste secundaire replica als back-upknooppunt. Anders wordt de primaire geselecteerd. Wanneer de back-up wordt uitgevoerd, wordt het geselecteerde back-upknooppunt vergrendeld totdat het back-upproces is voltooid.
Back-ups plannen
Nu we hebben gespeeld met het maken van directe back-ups, kunnen we dat nu uitbreiden door de back-ups te plannen.
De planning is heel eenvoudig:u kunt selecteren op welke dagen de back-up moet worden gemaakt en op welk tijdstip deze moet worden uitgevoerd.
Voor xtrabackup is er een extra functie:incrementele back-ups. Een incrementele back-up maakt alleen een back-up van de gegevens die zijn gewijzigd sinds de laatste back-up. Natuurlijk zijn de incrementele back-ups nutteloos als er geen volledige back-up als uitgangspunt zou zijn. Tussen twee volledige back-ups kunt u zoveel incrementele back-ups maken als u wilt. Maar het herstellen ervan duurt langer.
Eenmaal gepland zouden de job(s) zichtbaar moeten worden onder het tabblad "Geplande back-up" en u kunt ze bewerken door op de knop "Bewerken" te klikken. Net als bij de directe back-ups, plannen deze taken het maken van een back-up en kun je de voortgang volgen via het tabblad Activiteit.
Back-uplijst
U vindt de back-uplijst onder ClusterControl> Back-up en dit geeft u een overzicht op clusterniveau van alle gemaakte back-ups. Als u op elk item klikt, wordt de rij uitgevouwen en wordt meer informatie over de back-up weergegeven:
Elke back-up gaat vergezeld van een back-uplogboek wanneer ClusterControl de taak heeft uitgevoerd, die beschikbaar is onder de knop "Meer acties".
Offsite back-up in de cloud
Omdat we nu veel back-ups hebben opgeslagen op de databasehosts of de ClusterControl-host, willen we er ook voor zorgen dat ze niet verloren gaan voor het geval we te maken krijgen met een totale uitval van de infrastructuur. (bijv. DC in brand of overstroomd) Daarom kunt u met ClusterControl uw back-ups offsite in de cloud opslaan of kopiëren. De ondersteunde cloudplatforms zijn Amazon S3, Google Cloud Storage en Azure Cloud Storage.
Het uploadproces vindt plaats direct nadat de back-up met succes is gemaakt (als u "Upload back-up naar de cloud") of u kunt handmatig op de cloudpictogramknop van de back-uplijst klikken:
Kies de cloudreferentie en specificeer de back-uplocatie dienovereenkomstig:
Back-up terugzetten en/of verifiëren
Vanuit de interface van de back-uplijst kunt u rechtstreeks een back-up terugzetten naar een host in het cluster door op de knop "Herstellen" voor de specifieke back-up te klikken of op de knop "Back-up herstellen" te klikken:
Een leuke functie is dat het een knooppunt of cluster kan herstellen met behulp van de volledige en incrementele back-ups, omdat het de laatst gemaakte volledige back-up bijhoudt en vanaf daar de incrementele back-up start. Vervolgens groepeert het een volledige back-up samen met alle incrementele back-ups tot de volgende volledige back-up. Dit stelt je in staat om te herstellen vanaf de volledige back-up en de incrementele back-ups er bovenop toe te passen.
ClusterControl ondersteunt herstel op een bestaand databaseknooppunt of herstel en verificatie op een nieuwe zelfstandige host:
Deze twee opties lijken veel op elkaar, behalve dat de verificatie-optie extra opties heeft voor de nieuwe hostinformatie. Als u de herstelwizard volgt, moet u een nieuwe host opgeven. 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.
Zodra de back-up is hersteld en geverifieerd, ontvangt u een melding over de herstelstatus en wordt de node automatisch afgesloten.
Point-in-Time herstel
Voor MySQL kunnen zowel xtrabackup als mysqldump worden gebruikt om herstel op een bepaald tijdstip uit te voeren en ook om een nieuwe replicatieslave in te richten voor master-slave-replicatie of Galera Cluster. 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:
Als de PITR-compatibele optie is ingeschakeld, worden de database- en tabelvelden grijs weergegeven, aangezien ClusterControl altijd een volledige back-up zal maken van alle databases, gebeurtenissen, triggers en routines van de MySQL-doelserver.
Nu de back-up herstellen. Als de back-up compatibel is met PITR, wordt een optie gepresenteerd om een Point-In-Time Recovery uit te voeren. U hebt daarvoor twee opties:"Time Based" en "Position Based". Voor "Time Based" kunt u gewoon de dag en tijd doorgeven. Voor "Position Based" kunt u de exacte positie doorgeven aan waar u wilt herstellen. Het is een preciezere manier om te herstellen, hoewel u mogelijk de binlog-positie moet verkrijgen met behulp van het hulpprogramma mysqlbinlog. Meer details over herstel op een bepaald tijdstip vindt u in deze blog.
Back-up versleuteling
Universeel ondersteunt ClusterControl back-upversleuteling voor MySQL, MongoDB en PostgreSQL. Back-ups worden in rust versleuteld met behulp van het AES-256 CBC-algoritme. Een automatisch gegenereerde sleutel wordt opgeslagen in het configuratiebestand van het cluster onder /etc/cmon.d/cmon_X.cnf (waarbij X de cluster-ID is):
$ sudo grep backup_encryption_key /etc/cmon.d/cmon_1.cnf
backup_encryption_key='JevKc23MUIsiWLf2gJWq/IQ1BssGSM9wdVLb+gRGUv0='Als de back-upbestemming niet lokaal is, worden de back-upbestanden in gecodeerde indeling overgedragen. Deze functie vormt een aanvulling op de offsite back-up in de cloud, waar we geen volledige toegang hebben tot het onderliggende opslagsysteem.
Laatste gedachten
We hebben u laten zien hoe u een back-up van uw gegevens kunt maken en hoe u deze veilig off-site kunt opslaan. Herstel is altijd iets anders. ClusterControl kan uw databases automatisch herstellen van de in het verleden gemaakte back-ups die op locatie zijn opgeslagen of vanuit de cloud zijn gekopieerd.
Het is duidelijk dat er meer komt kijken bij het beveiligen van uw gegevens, vooral aan de kant van het beveiligen van uw verbindingen. We zullen dit bespreken in de volgende blogpost!