Cílem tohoto příspěvku je dozvědět se o různých způsobech migrace dat v MongoDB, které nám mohou pomoci psát skripty, které změní vaši databázi přidáním nových dokumentů nebo úpravou stávajících.

Pokud sem přicházíte poprvé, podívejte se prosím na prequel Self-Hosted MongoDB.

Dobrá tedy, vybíráme tam, kde jsme skončili, a začněme s migrací dat v MongoDB.

Základní kroky k migraci dat z jednoho MongoDB do druhého by nyní byly:

Vytvořte zazipovanou zálohu stávajících dat
Uložte data do nové databáze

To je velmi přímočaré, když zdrojová databáze není online, protože víme, že během procesu migrace nebudou vytvořeny/aktualizovány žádné nové dokumenty. Než se pustíme do živého scénáře, podívejme se nejprve na jednoduchou migraci.

Migrace z offline databáze v MongoDB

Vytvoření zálohy

Pro vytvoření zálohy databáze použijeme existující obslužný program mongodump.

Spusťte tento příkaz na zdrojovém databázovém serveru

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

--host :Zdrojový název hostitele MongoDB spolu s portem. Výchozí hodnota je localhost:27017 . Pokud se jedná o připojovací řetězec, můžete použít tuto možnost —-uri="mongodb://username:password@host1[:port1]..."

--username :Určuje uživatelské jméno pro ověření v databázi MongoDB, která používá ověřování.

--password :Určuje heslo pro ověření v databázi MongoDB, která používá ověřování.

--authenticationDatabase :Určuje ověřovací databázi, kde je zadáno --username byl vytvořen.

Pokud neurčíte ověřovací databázi nebo databázi k exportu, mongodump předpokládá, že administrátorská databáze obsahuje přihlašovací údaje uživatele.

--db :Určuje databázi, ze které se má zálohovat. Pokud nezadáte databázi, mongodump shromažďuje data ze všech databází v této instanci.

Alternativně můžete také zadat databázi přímo v připojovacím řetězci URI, tj. mongodb://username:password@uri/dbname .
Poskytnutí připojovacího řetězce při použití --db a zadání konfliktních informací bude mít za následek chybu .

--collection :Určuje kolekci k zálohování. Pokud neurčíte kolekci, tato volba zkopíruje všechny kolekce v zadané databázi nebo instanci do souborů výpisu.

--query :Poskytuje dokument JSON jako dotaz, který volitelně omezuje dokumenty zahrnuté ve výstupu mongodump.
Dokument dotazu musíte uzavřít do jednoduchých uvozovek ('{ ... }') abyste zajistili, že nebude interagovat s vaším prostředím.
Dotaz musí být ve formátu Extended JSON v2 (buď uvolněný nebo kanonický/strict režim), včetně uzavření názvů polí a operátorů do uvozovek, např. '{ "created_at": { "\$gte": ISODate(...) } }' .

Chcete-li použít --query musíte také zadat --collection možnost.

--forceTableScan :Přinutí mongodump přímo skenovat úložiště dat. Typicky mongodump ukládá položky tak, jak se objevují v indexu _id pole.

Pokud zadáte dotaz --query , mongodump použije nejvhodnější index pro podporu tohoto dotazu.
Proto nemůžete použít --forceTableScan pomocí --query možnost .

--gzip :Komprimuje výstup. Pokud mongodump vystupuje do adresáře výpisu, nová funkce zkomprimuje jednotlivé soubory. Soubory mají příponu .gz .

--out :Určuje adresář, kam mongodump zapíše BSON soubory pro dumpingové databáze. Ve výchozím nastavení mongodump ukládá výstupní soubory do adresáře s názvem dump v aktuálním pracovním adresáři.

Obnovení zálohy

Použijeme obslužný program s názvem mongorestore pro obnovení zálohy databáze.

Zkopírujte výpis záložního adresáře do nové instance databáze a spusťte následující příkaz:

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

Nahraďte přihlašovací údaje novými přihlašovacími údaji databáze. V předchozím kroku zrušte řádek --authenticationDatabase volba je uvedena v řetězci URI.

Také použijte --gzip pokud se použije při vytváření zálohy.

--drop :Před obnovením kolekcí z výpisu zálohy odstraní kolekce z cílové databáze. Nezahazuje sbírky, které nejsou v záloze.--noIndexRestore :Zabraňuje mongorestore v obnovování a vytváření indexů, jak je uvedeno v odpovídajícím mongodump výstupu.

Pokud chcete během obnovy změnit název databáze, můžete tak učinit pomocí
--nsFrom="old_name.*" --nsTo="new_name.*" možnosti.

Nebude to však fungovat, pokud byste migrovali pomocí oplogs což je požadavek při migraci z online instance.

Migrace z online databáze v MongoDB

Jediným problémem při migraci z online databáze není možnost pozastavit aktualizace během migrace. Zde je tedy přehled kroků

Spusťte úvodní hromadnou migraci pomocí oplogs zachytit
Spusťte úlohu synchronizace ke zmírnění latence přepnutí databázového připojení

Nyní k zachycení oplogs , musí být sada replik inicializována ve zdrojové a cílové databázi. Je to proto, že oplogs jsou zachyceny z local.oplog.rs jmenný prostor, který se vytvoří po inicializaci sady replik.

Pomocí tohoto průvodce můžete nakonfigurovat sadu replik.

Počáteční migrace se zachycením Oplog

Oplogy, jednoduše řečeno, jsou provozní protokoly vytvořené pro každou operaci v databázi. Představují dílčí stav dokumentu nebo jinými slovy stav databáze. Během procesu migrace tedy zachytíme všechny aktualizace v naší staré databázi pomocí těchto oplogs .

Spusťte program mongodump s následujícími možnostmi

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

--oplog :Vytvoří soubor s názvem oplog.bson jako součást mongodump výstup. Soubor oplog.bson soubor umístěný na nejvyšší úrovni výstupního adresáře obsahuje oplog záznamy, ke kterým dojde během operace mongodump. Tento soubor poskytuje efektivní momentální snímek stavu instance naší databáze.

Obnovení dat pomocí přehrání oplogu

Pro přehrání oplogů je vyžadována speciální role. Pojďme vytvořit a přiřadit roli uživateli databáze použitému pro migraci.

Vytvořit roli

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

Přiřadit roli

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

Nyní můžete obnovit pomocí programu mongorestore s následujícími možnostmi,

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

Ve výše uvedeném příkazu pomocí stejného uživatele admin s kým byla role spojena.

--oplogReplay :Po obnovení výpisu databáze znovu přehraje položky oplog ze souboru bson a obnoví databázi do zálohy k určitému okamžiku zachycené pomocí mongodump --oplog příkaz.

Snížení latence přepnutí databázového připojení

Dobře, zatím jsme skončili s většinou těžkého zvedání. Jediné, co zůstává, je zachování konzistence mezi databázemi během přepínání připojení na našich aplikačních serverech.

Pokud používáte MongoDB verze 3.6+, je lepší zvolit přístup Change Stream, což je mechanismus založený na událostech zavedený k zachycení změn ve vaší databázi optimalizovaným způsobem. Zde je článek, který to pokrývá https://www.mongodb.com/blog/post/an-introduction-to-change-streams

Podívejte se na obecný synchronizační skript, který můžete každou minutu spustit jako úlohu CRON.

Aktualizujte proměnné v tomto skriptu a spusťte jako

$ ./delta-sync.sh from_epoch_in_milliseconds

# from_epoch_in_milliseconds is automatically picked with every iteration if not supplied

Nebo můžete nastavit úlohu cron, která to spustí každou minutu.

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

Výstup lze monitorovat pomocí následujícího příkazu (používám RHEL 8, výstup cron naleznete v příručce k operačnímu systému)

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

Toto je ukázkový protokol synchronizace.

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!)

Tento skript můžete zastavit po ověření, že se již žádné oplogs jsou vytvářeny, tj. když zdrojová DB přešla do režimu offline.

Tímto je uzavřen kompletní průvodce migrací dat MongoDB s vlastním hostitelem. Pokud se chcete dozvědět více o MongoDB, zde je užitečný zdroj o tom, jak používat MongoDB jako zdroj dat v goLangu.

Jak migrovat data v MongoDB