sql >> Database >  >> NoSQL >> MongoDB

MongoDB Backup Management Tips voor Sharded Clusters

Het maken van goede back-ups van de database is een cruciale taak. Naast het instellen van de hoge-beschikbaarheidsarchitectuur van uw MongoDB voor databaseservices, moet u ook back-ups van uw databases hebben om de beschikbaarheid van gegevens in geval van calamiteiten te garanderen. Als u bijvoorbeeld per ongeluk gegevens uit een productiedatabase verwijdert, is de enige manier om de gegevens vanuit het oogpunt van de database te herstellen, het herstellen vanaf een back-up.

Onlangs is ClusterControl begonnen met het ondersteunen van een nieuwe back-upmethode, Percona Backup for MongoDB genaamd, ontwikkeld door Percona. Het kan consistente back-ups maken voor MongoDB Replica Sets en Sharded Clusters.

In deze blog gaan we in op back-upbeheer voor MongoDB Replica Sets en Sharded Clusters.

MongoDB-back-up in zeer beschikbare architectuur

ClusterControl ondersteunt drie back-upmethoden, namelijk mongodump,  mongodb consistent  en  Percona Backup for Mongodb. De consistente back-up van mongodb gebruikt het hulpprogramma Mongodump als back-upmethode en de back-up kan worden hersteld met behulp van mongorestore.

De nieuwste ondersteunde back-upmethode is Percona Backup for Mongodb voor consistente en op het juiste moment back-ups van Replica Set en Sharded Clusters. Er is een agent nodig om op elke node of replicaset of shard-nodes en managementnodes te draaien voor shardclusters zoals hier beschreven.

Consistente back-up configureren en plannen met Percona Backup voor Mongodb in ClusterControl is heel eenvoudig. Ga naar de pagina Back-up en configureer vervolgens de Percona-back-up voor Mongodb. Voorwaarde is dat Percona Backup for MongoDB op elk knooppunt draait, dat ook vanuit ClusterControl kan worden geïnstalleerd.

We moeten eerst de Percona Backup for MongoDB-agent installeren voordat we een back-up kunnen plannen zoals hieronder:

Configureer vervolgens de back-upmap. Houd er rekening mee dat de back-upmap een gedeelde schijf moet zijn die op alle knooppunten is gemount met exact hetzelfde gemounte pad als hieronder:

Als je geen enkele soort gedeelde schijf in het systeem hebt, u kunt NFS gebruiken om dit te bereiken. Voor het configureren van de NFS-server hebben we een dedicated server / virtuele machine nodig met voldoende vrije ruimte om de back-up op te slaan. Installeer de nfs-utils en nfs-utils-lib bibliotheek op de server zoals hieronder (ervan uitgaande dat we de op CentOS gebaseerde gebruiken):

[[email protected] ~]# yum install nfs-utils nfs-utils-lib

[[email protected] ~]# yum install portmap

En start de portmap en nfs-services.

[[email protected] ~]# /etc/init.d/portmap start

[[email protected] ~]# /etc/init.d/nfs start

Voeg daarna nieuwe items toe in /etc/exports zoals hieronder getoond:

[[email protected] ~]# vi /etc/exports

/backup 10.10.10.11(rw,sync,no_root_squash)

Op het databaseknooppunt hoeven we alleen de opslagschijf te koppelen als gedeelde opslag.

Als laatste, klik gewoon op de installatieknop en het zal een nieuwe taak activeren om de agent op elk knooppunt te configureren.

Nadat PBM ggent is geïnstalleerd, kunnen we de back-upmethode configureren voor de cluster zoals hieronder:

Fysieke versus logische back-up

MongoDB-back-up ondersteunt logische back-up en fysieke back-up. De methode voor logische back-up met behulp van het hulpprogramma mongodump is inbegrepen wanneer u het mongodb-pakket installeert. Mongodump heeft toegang nodig tot uw mongodb-database, dus het vereist referentietoegang voor mongodump met privileges voor back-uprollen en moet een actie hebben om een ​​back-up van de database te maken.

Het werkt voor BSON-gegevensdumpformaten. De mongodump maakt verbinding met uw database met de verstrekte inloggegevens, leest de volledige gegevens in uw database en dumpt de gegevens in bestanden. Omdat het een proces met één thread is, duurt het maken van de back-up langer, vooral bij een grote database. Mongodump handhaaft de atomiciteit van transacties over de shards niet, daarom kan het niet worden gebruikt als back-upstrategie voor mongodb-versie 4.2 en hoger in een shard-cluster. Percona Backup voor MongoDB is een logische back-up, maar ondersteunt consistente back-ups van clusters.

Fysieke back-up in MongoDB werkt via de momentopname van de mongodb-bestandssystemen, het kopieert de onderliggende mongodb-bestanden naar een andere locatie als basisback-up van uw mongodb-database. De snapshot van het bestandssysteem is het besturingssysteem als u LVM (Logical Volume Manager) gebruikt als software voor het beheren van uw schijflay-out en apparaat, of softwaretoepassing, bijv. Veritas of NetApp Backup. U moet journaal inschakelen, het activiteitenlogboek voor wijzigingen in mongodb voordat u de momentopname van het bestandssysteem uitvoert om de back-up consistent te maken.

Naast de momentopname van het bestandssysteem, kunt u ook de opdracht cp of rsync gebruiken om MongoDB-gegevensbestanden te kopiëren, maar u moet het schrijfproces naar mongodb stoppen omdat het kopiëren van gegevensbestanden geen atomaire bewerking is. De back-up kan niet worden gebruikt voor Point-in-Time Recovery in Replica Sets of Sharded Cluster-architecturen.

Percona Backup voor MongoDB bestaat uit twee componenten, de pbm-agent die op elk knooppunt moet worden geïnstalleerd en de pbm als een opdrachtregelinterface om te communiceren en de back-ups uit te voeren. De pbm-agentcoördinaat tussen de databaseknooppunten en het uitvoeren van het back-up- en herstelproces. De pbm-agent bepaalt de beste node voor het maken van de back-up.

PITR-back-up

In veel databasesystemen is het gebruikelijk om een ​​controlepunt te gebruiken om de gegevens naar de schijf te spoelen. MongoDB gebruikt de WiredTiger-opslagengine als standaardopslagengine en gebruikt ook controlepunten om een ​​consistent beeld van gegevens te bieden. Niet alleen dat, het controlepunt in MongoDB kan worden gebruikt om te herstellen van het laatste controlepunt. De logboekregistratie werkt tussen elk controlepunt, het logboek is vereist om te herstellen van onverwachte storingen die zich op elk moment tussen de controlepunten voordoen. Journaling garandeert dat de schrijfbewerkingen op schijf worden vastgelegd, MongoDB maakt een journaalboeking voor elke wijziging, inclusief de gewijzigde bytes en de schijflocatie.

Mongodump en mongorestore kunnen worden gebruikt voor back-up van herstel op een bepaald moment, er is een optie om gebruik te maken van de oplog. De oplog is een afgetopte verzameling in MongoDB die alle wijzigingen in verzamelingen bijhoudt voor elke schrijftransactie (bijv. invoegen, bijwerken, verwijderen). Dus als u herstel op een bepaald tijdstip wilt uitvoeren, moet u herstellen vanaf de laatste volledige back-up en ook het oplog-bestand gebruiken om de wijzigingen toe te passen op het exacte tijdstip waarop u wilt herstellen. Een ander hulpmiddel dat kan worden gebruikt, is de Percona Backup voor MongoDB, het proces is vergelijkbaar met mongodump, we moeten de back-up herstellen en vervolgens de oplog toepassen.

Conclusie

Het is belangrijk om een ​​consistente back-up te maken, vooral in geclusterde MongoDB-setups (replicaset of sharded cluster). ClusterControl biedt een gemakkelijke manier om de Percona Backup voor MongoDB in uw cluster te configureren en uw back-ups te plannen.


  1. MongoRegex gebruiken (MongoDB C#-stuurprogramma)

  2. Berichten verzenden naar groepen in Django Channels 2

  3. MongoDB - Een verzameling maken

  4. Lombok - java.lang.StackOverflowError:null op toString methode