Целта на тази публикация е да научите за различните начини за миграция на данни в MongoDB, които могат да ни помогнат да пишем скриптове, които променят вашата база данни чрез добавяне на нови документи, модифициране на съществуващи.

Ако идвате тук за първи път, моля, разгледайте предисторията Self-Hosted MongoDB.

Добре тогава, избирайки откъдето спряхме, нека започнем с миграцията на данни в MongoDB.

Сега основните стъпки за мигриране на данни от един MongoDB към друг биха били:

1. Създайте архивирано архивно копие на съществуващите данни
2. Изхвърлете данните в нова база данни

Това е много лесно, когато изходната база данни не е онлайн, защото знаем, че няма да има нови документи, създадени/актуализирани по време на процеса на миграция. Нека първо разгледаме простата миграция, преди да се потопим в сценария на живо.

Мигриране от офлайн база данни в MongoDB

Създаване на резервно копие

Ще използваме съществуваща помощна програма mongodump за създаване на резервно копие на базата данни.

Изпълнете тази команда в изходния сървър на база данни

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

--host :Изходното име на хост MongoDB заедно с порта. По подразбиране е localhost:27017 . Ако това е низ за връзка, можете да използвате тази опция —-uri="mongodb://username:password@host1[:port1]..."

--username :Посочва потребителско име за удостоверяване на база данни MongoDB, която използва удостоверяване.

--password :Посочва парола за удостоверяване на база данни MongoDB, която използва удостоверяване.

--authenticationDatabase :Указва базата данни за удостоверяване, където е указан --username е създаден.

Ако не посочите база данни за удостоверяване или база данни за експортиране, mongodump приема, че администраторската база данни съдържа идентификационните данни на потребителя.

--db :Указва базата данни, от която да се направи резервно копие. Ако не посочите база данни, mongodump събира от всички бази данни в този екземпляр.

Като алтернатива, можете също да посочите базата данни директно в низа за URI връзка, т.е. mongodb://username:password@uri/dbname .
Предоставяне на низ за връзка, като същевременно се използва --db и посочването на противоречива информация ще доведе до грешка .

--collection :Указва колекция за архивиране. Ако не посочите колекция, тази опция копира всички колекции в посочената база данни или екземпляр в дъмп файловете.

--query :Предоставя JSON документ като заявка, която по избор ограничава документите, включени в изхода на mongodump.
Трябва да поставите документа на заявката в единични кавички ('{ ... }') за да гарантирате, че няма да взаимодейства с вашата среда.
Заявката трябва да бъде във формат Extended JSON v2 (или спокоен, или каноничен/строг режим), включително обграждане на имената на полетата и операторите в кавички, напр. '{ "created_at": { "\$gte": ISODate(...) } }' .

За да използвате --query опция, трябва също да посочите --collection опция.

--forceTableScan :Принуждава mongodump да сканира директно хранилището на данни. Обикновено mongodump запазва записи, както се появяват в индекса на _id поле.

Ако посочите заявка --query , mongodump ще използва най-подходящия индекс за поддръжка на тази заявка.
Следователно не можете да използвате --forceTableScan с --query опцията .

--gzip :Компресира изхода. Ако mongodump изведе в директорията dump, новата функция компресира отделните файлове. Файловете имат суфикс .gz .

--out :Указва директорията, където mongodump ще напише BSON файлове за изхвърлените бази данни. По подразбиране mongodump записва изходни файлове в директория с име dump в текущата работна директория.

Възстановяване на архива

Ще използваме помощна програма, наречена mongorestore за възстановяване на архива на базата данни.

Копирайте дъмпа на резервната директория в новия екземпляр на базата данни и изпълнете следната команда:

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

Заменете идентификационните данни с новите идентификационни данни за база данни. Премахнете линията в предишната стъпка, --authenticationDatabase опцията е посочена в URI низа.

Също така използвайте --gzip ако се използва при създаване на резервно копие.

--drop :Преди да възстановите колекциите от изхвърления архив, изтрива колекциите от целевата база данни. Той не изпуска колекции, които не са в архива.--noIndexRestore :Предотвратява възстановяването и изграждането на индекси на mongorestore, както е посочено в съответния изход на mongodump.

Ако искате да промените името на базата данни по време на възстановяване, можете да го направите с помощта на
--nsFrom="old_name.*" --nsTo="new_name.*" опции.

Няма да работи обаче, ако мигрирате с oplogs което е изискване при миграция от онлайн екземпляр.

Мигриране от онлайн база данни в MongoDB

Единственото предизвикателство с мигрирането от онлайн база данни не е в състояние да постави на пауза актуализациите по време на миграция. Ето преглед на стъпките,

1. Изпълнете първоначална групова миграция с oplogs улавяне
2. Изпълнете задание за синхронизиране, за да намалите забавянето на превключването на връзката с базата данни

Сега, за да заснемете oplogs , набор от реплика трябва да бъде инициализиран в базата данни източник и местоназначение. Това е така, защото oplogs са заснети от local.oplog.rs пространство от имена, което се създава след инициализиране на набор от реплика.

Можете да следвате това ръководство, за да конфигурирате набор от реплики.

Първоначална миграция с Oplog Capture

Oplogs, с прости думи, са регистрационните файлове на операциите, създадени за операция в базата данни. Те представляват частично състояние на документа или, с други думи, състоянието на базата данни. Така че ще улавяме всички актуализации в нашата стара база данни по време на процеса на миграция, използвайки тези oplogs .

Стартирайте програмата mongodump със следните опции,

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

--oplog :Създава файл с име oplog.bson като част от mongodump изход. oplog.bson файл, разположен в горното ниво на изходната директория, съдържа oplog записи, които се появяват по време на операцията mongodump. Този файл предоставя ефективна моментна снимка в момента на състоянието на нашата база данни.

Възстановяване на данните с oplog replay

За да възпроизведете оплоговете, е необходима специална роля. Нека създадем и присвоим ролята на потребителя на базата данни, който се използва за миграция.

Създаване на ролята

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

Присвояване на ролята

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

Сега можете да възстановите с помощта на програмата mongorestore със следните опции,

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

В горната команда с помощта на същия потребител admin с когото е била свързана ролята.

--oplogReplay :След възстановяване на дъмпа на базата данни, възпроизвежда записите в oplog от bson файл и възстановява базата данни в резервното копие в момента, заснето с mongodump --oplog команда.

Намаляване на забавянето при превключване на връзката с база данни

Добре, засега приключихме с по-голямата част от вдигането на тежести. Единственото нещо, което остава, е поддържането на последователност между базите данни по време на превключването на връзката в нашите сървъри на приложения.

Ако използвате MongoDB версия 3.6+, по-добре е да изберете подхода Change Stream, който е базиран на събития механизъм, въведен за улавяне на промените във вашата база данни по оптимизиран начин. Ето статия, която го обхваща https://www.mongodb.com/blog/post/an-introduction-to-change-streams

Вижте общия скрипт за синхронизиране, който можете да изпълнявате като CRON задача всяка минута.

Актуализирайте променливите в този скрипт и стартирайте като

$ ./delta-sync.sh from_epoch_in_milliseconds

# from_epoch_in_milliseconds is automatically picked with every iteration if not supplied

Или можете да настроите задание на cron, което да изпълнява това всяка минута.

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

Резултатът може да бъде наблюдаван със следната команда (изпълнявам RHEL 8, вижте ръководството за вашата ОС за изход на cron)

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

Това е примерен дневник за синхронизиране.

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

Можете да спрете този скрипт, след като се уверите, че няма повече oplogs се създават, т.е., когато изходната БД излезе офлайн.

Това завършва пълното самостоятелно хоствано ръководство за миграция на данни на MongoDB. Ако искате да научите повече за MongoDB, тук е полезен ресурс за това как да използвате MongoDB като източник на данни в goLang.