Het doel van dit bericht is om meer te weten te komen over de verschillende manieren van gegevensmigratie in MongoDB die ons kunnen helpen om scripts te schrijven die uw database veranderen door nieuwe documenten toe te voegen, bestaande documenten aan te passen.

Als je hier voor het eerst komt, kijk dan eens naar de prequel Self-Hosted MongoDB.

Goed dan, laten we beginnen met de gegevensmigratie in MongoDB, waar we gebleven waren.

De basisstappen om gegevens van de ene MongoDB naar de andere te migreren zijn:

Maak een gezipte back-up van de bestaande gegevens
Dump de gegevens in een nieuwe DB

Dit is heel eenvoudig wanneer de brondatabase niet online is, omdat we weten dat er tijdens het migratieproces geen nieuwe documenten zullen worden gemaakt/geüpdatet. Laten we eerst kijken naar eenvoudige migratie voordat we ons in het live-scenario duiken.

Migreren vanuit een offline database in MongoDB

Een back-up maken

We gaan een bestaand hulpprogramma mongodump gebruiken voor het maken van de databaseback-up.

Voer deze opdracht uit in de brondatabaseserver

mongodump --host="hostname:port" \
  --username="username" --password="password" \
  --authenticationDatabase "admin" \
  --db="db name" --collection="collection name" --query='json' \
  --forceTableScan -v --gzip --out ./dump

--host :De bron MongoDB-hostnaam samen met de poort. Het is standaard localhost:27017 . Als het een verbindingsreeks is, kunt u deze optie gebruiken —-uri="mongodb://username:password@host1[:port1]..."

--username :Specificeert een gebruikersnaam voor authenticatie bij een MongoDB-database die authenticatie gebruikt.

--password :Specificeert een wachtwoord voor authenticatie bij een MongoDB-database die authenticatie gebruikt.

--authenticationDatabase :Specificeert de authenticatiedatabase waar de gespecificeerde --username is gemaakt.

Als u geen authenticatiedatabase of een database opgeeft om te exporteren, gaat mongodump ervan uit dat de beheerdersdatabase de inloggegevens van de gebruiker bevat.

--db :Specificeert de database waarvan een back-up moet worden gemaakt. Als u geen database opgeeft, verzamelt mongodump in dit geval alle databases.

Als alternatief kunt u de database ook rechtstreeks in de URI-verbindingsreeks specificeren, d.w.z. mongodb://username:password@uri/dbname .
Een verbindingsreeks opgeven terwijl ook --db wordt gebruikt en het specificeren van tegenstrijdige informatie zal resulteren in een fout .

--collection :specificeert een verzameling waarvan een back-up moet worden gemaakt. Als u geen verzameling opgeeft, kopieert deze optie alle verzamelingen in de opgegeven database of instantie naar de dumpbestanden.

--query :Biedt een JSON-document als een query die optioneel de documenten beperkt die zijn opgenomen in de uitvoer van mongodump.
U moet het zoekdocument tussen enkele aanhalingstekens plaatsen ('{ ... }') om ervoor te zorgen dat het geen interactie heeft met uw omgeving.
De query moet de Extended JSON v2-indeling hebben (ofwel ontspannen of canonieke/strikte modus), inclusief het omsluiten van de veldnamen en operators tussen aanhalingstekens, b.v. '{ "created_at": { "\$gte": ISODate(...) } }' .

Om de --query te gebruiken optie, moet u ook de --collection . specificeren optie.

--forceTableScan :dwingt mongodump om de gegevensopslag rechtstreeks te scannen. Gewoonlijk slaat mongodump items op zoals ze verschijnen in de index van de _id veld.

Als u een zoekopdracht specificeert --query , zal mongodump de meest geschikte index gebruiken om die zoekopdracht te ondersteunen.
Daarom kunt u --forceTableScan niet gebruiken met de --query optie .

--gzip :comprimeert de uitvoer. Als mongodump uitvoer naar de dump-directory, comprimeert de nieuwe functie de individuele bestanden. De bestanden hebben het achtervoegsel .gz .

--out :Specificeert de map waar mongodump BSON zal schrijven bestanden voor de gedumpte databases. Standaard slaat mongodump uitvoerbestanden op in een map met de naam dump in de huidige werkmap.

De back-up herstellen

We zullen een hulpprogramma gebruiken met de naam mongorestore voor het herstellen van de databaseback-up.

Kopieer de back-upmapdump naar de nieuwe database-instantie en voer de volgende opdracht uit:

mongorestore --uri="mongodb://user:password@host:port/?authSource=admin" \
  --drop --noIndexRestore --gzip -v ./dump

Vervang de referenties door de nieuwe databasereferenties. Unline in de vorige stap, de --authenticationDatabase optie is gespecificeerd in de URI-tekenreeks.

Gebruik ook --gzip indien gebruikt tijdens het maken van de back-up.

--drop :Voordat u de verzamelingen van de gedumpte back-up herstelt, verwijdert u de verzamelingen uit de doeldatabase. Verzamelingen die niet in de back-up staan worden niet verwijderd.--noIndexRestore :Voorkomt dat mongorestore indexen herstelt en opbouwt zoals gespecificeerd in de corresponderende mongodump-uitvoer.

Als u de naam van de database wilt wijzigen tijdens het herstellen, kunt u dit doen met
--nsFrom="old_name.*" --nsTo="new_name.*" opties.

Het werkt echter niet als u zou migreren met oplogs wat een vereiste is bij migratie vanaf een online exemplaar.

Migreren vanuit een online database in MongoDB

De enige uitdaging bij het migreren vanuit een online database is het niet kunnen pauzeren van de updates tijdens de migratie. Dus hier is het overzicht van de stappen,

Voer een eerste bulkmigratie uit met oplogs vastleggen
Voer een synchronisatietaak uit om de latentie van de databaseverbinding te verminderen

Nu, om oplogs vast te leggen , moet een replicaset worden geïnitialiseerd in de bron- en doeldatabase. Dit komt omdat de oplogs worden vastgelegd van local.oplog.rs namespace, die wordt gemaakt na het initialiseren van een replicaset.

U kunt deze handleiding volgen om een replicaset te configureren.

Eerste migratie met Oplog Capture

Oplogs, in eenvoudige bewoordingen, zijn de bewerkingslogboeken die per bewerking in de database worden gemaakt. Ze vertegenwoordigen een gedeeltelijke documentstatus of, met andere woorden, de databasestatus. We gaan dus alle updates in onze oude database vastleggen tijdens het migratieproces met behulp van deze oplogs .

Voer het mongodump-programma uit met de volgende opties,

mongodump --uri=".../?authSource=admin" \
  --forceTableScan --oplog \
  --gzip -v --out ./dump

--oplog :Creëert een bestand met de naam oplog.bson als onderdeel van de mongodump uitvoer. De oplog.bson bestand, dat zich op het hoogste niveau van de uitvoermap bevindt, bevat oplog vermeldingen die optreden tijdens de mongodump-bewerking. Dit bestand biedt een effectieve momentopname van de status van onze database-instantie.

De gegevens herstellen met oplog replay

Om de oplogs opnieuw te spelen, is een speciale rol vereist. Laten we de rol maken en toewijzen aan de databasegebruiker die wordt gebruikt voor de migratie.

Maak de rol

db.createRole({
  role: "interalUseOnlyOplogRestore",
  privileges: [
    {
      resource: { anyResource: true },
      actions: [ "anyAction" ] 
    }
  ],
  roles: []
})

De rol toewijzen

db.grantRolesToUser(
  "admin",
  [{ role:"interalUseOnlyOplogRestore", db:"admin" }]
);

Nu kunt u herstellen met behulp van het mongorestore-programma met de volgende opties,

mongorestore --uri="mongodb://admin:.../?authSource=admin" \
  --oplogReplay 
  --gzip -v ./dump

In de bovenstaande opdracht, met dezelfde gebruiker admin met wie de rol was geassocieerd.

--oplogReplay :Na het herstellen van de databasedump, worden de oplog-items uit een bson-bestand opnieuw afgespeeld en wordt de database hersteld naar de point-in-time back-up die is vastgelegd met de mongodump --oplog commando.

Latentie van switch naar databaseverbinding verminderen

Oké, tot nu toe zijn we klaar met het meeste zware werk. Het enige dat overblijft is het handhaven van consistentie tussen de databases tijdens het wisselen van verbinding in onze applicatieservers.

Als u MongoDB versie 3.6+ gebruikt, is het beter om voor de Change Stream-aanpak te gaan, een op gebeurtenissen gebaseerd mechanisme dat is geïntroduceerd om wijzigingen in uw database op een geoptimaliseerde manier vast te leggen. Hier is een artikel dat het behandelt https://www.mongodb.com/blog/post/an-introduction-to-change-streams

Bekijk het generieke synchronisatiescript, dat u elke minuut als een CRON-taak kunt uitvoeren.

Werk de variabelen in dit script bij en voer het uit als

$ ./delta-sync.sh from_epoch_in_milliseconds

# from_epoch_in_milliseconds is automatically picked with every iteration if not supplied

Of je kunt een cron-taak instellen om dit elke minuut uit te voeren.

* * * * * ~/delta-sync.sh

De uitvoer kan worden gecontroleerd met de volgende opdracht (ik gebruik RHEL 8, raadpleeg uw OS-gids voor cron-uitvoer)

$ tail -f /var/log/cron | grep CRON

Dit is een voorbeeld van een synchronisatielogboek.

CMD (~/cron/dsync.sh)
CMDOUT (INFO: Updated log registry to use new timestamp on next run.)
CMDOUT (INFO: Created sync directory: /home/ec2-user/cron/dump/2020-11-03T19:01:01Z)
CMDOUT (Fetching oplog in range [2020-11-03T19:00:01Z - 2020-11-03T19:01:01Z])
CMDOUT (2020-11-03T19:01:02.319+0000#011dumping up to 1 collections in parallel)
CMDOUT (2020-11-03T19:01:02.334+0000#011writing local.oplog.rs to /home/ec2-user/cron/dump/2020-11-03T19:01:01Z/local/oplog.rs.bson.gz)
CMDOUT (2020-11-03T19:01:04.943+0000#011local.oplog.rs  0)
CMDOUT (2020-11-03T19:01:04.964+0000#011local.oplog.rs  0)
CMDOUT (2020-11-03T19:01:04.964+0000#011done dumping local.oplog.rs (0 documents))
CMDOUT (INFO: Dump success!)
CMDOUT (INFO: Replaying oplogs...)
CMDOUT (2020-11-03T19:01:05.030+0000#011using write concern: &{majority false 0})
CMDOUT (2020-11-03T19:01:05.054+0000#011will listen for SIGTERM, SIGINT, and SIGKILL)
CMDOUT (2020-11-03T19:01:05.055+0000#011connected to node type: standalone)
CMDOUT (2020-11-03T19:01:05.055+0000#011mongorestore target is a directory, not a file)
CMDOUT (2020-11-03T19:01:05.055+0000#011preparing collections to restore from)
CMDOUT (2020-11-03T19:01:05.055+0000#011found collection local.oplog.rs bson to restore to local.oplog.rs)
CMDOUT (2020-11-03T19:01:05.055+0000#011found collection metadata from local.oplog.rs to restore to local.oplog.rs)
CMDOUT (2020-11-03T19:01:05.055+0000#011restoring up to 4 collections in parallel)
CMDOUT (2020-11-03T19:01:05.055+0000#011replaying oplog)
CMDOUT (2020-11-03T19:01:05.055+0000#011applied 0 oplog entries)
CMDOUT (2020-11-03T19:01:05.055+0000#0110 document(s) restored successfully. 0 document(s) failed to restore.)
CMDOUT (INFO: Restore success!)

Je kunt dit script stoppen nadat je hebt gecontroleerd dat er geen oplogs meer zijn worden gemaakt, d.w.z. toen bron-DB offline ging.

Dit besluit de volledige zelf-gehoste MongoDB-gegevensmigratiegids. Als u meer wilt weten over MongoDB, vindt u hier een handige bron over het gebruik van MongoDB als gegevensbron in goLang.

Gegevens migreren in MongoDB