Celem tego posta jest poznanie różnych sposobów migracji danych w MongoDB, które mogą nam pomóc w pisaniu skryptów zmieniających bazę danych poprzez dodawanie nowych dokumentów, modyfikowanie istniejących.
Jeśli przyjeżdżasz tu po raz pierwszy, spójrz na prequel Self-Hosted MongoDB.
W porządku, wybierając od miejsca, w którym skończyliśmy, zacznijmy migrację danych w MongoDB.
Teraz podstawowe kroki w celu migracji danych z jednej bazy danych MongoDB do drugiej to:
- Utwórz skompresowaną kopię zapasową istniejących danych
- Zrzuć dane do nowej bazy danych
Jest to bardzo proste, gdy źródłowa baza danych nie jest online, ponieważ wiemy, że podczas procesu migracji nie zostaną utworzone/zaktualizowane żadne nowe dokumenty. Przyjrzyjmy się najpierw prostej migracji, zanim przejdziemy do scenariusza na żywo.
Migracja z bazy danych offline w MongoDB
Tworzenie kopii zapasowej
Do utworzenia kopii zapasowej bazy danych użyjemy istniejącego programu narzędziowego mongodump.
Uruchom to polecenie na serwerze źródłowej bazy danych
mongodump --host="hostname:port" \
--username="username" --password="password" \
--authenticationDatabase "admin" \
--db="db name" --collection="collection name" --query='json' \
--forceTableScan -v --gzip --out ./dump
--host :Źródłowa nazwa hosta MongoDB wraz z portem. Domyślnie jest to localhost:27017 . Jeśli jest to ciąg połączenia, możesz użyć tej opcji —-uri="mongodb://username:password@host1[:port1]..."
--username :Określa nazwę użytkownika do uwierzytelnienia w bazie danych MongoDB, która używa uwierzytelniania.
--password :Określa hasło do uwierzytelnienia w bazie danych MongoDB, która używa uwierzytelniania.
--authenticationDatabase :Określa bazę danych uwierzytelniania, w której określony --username został utworzony.
Jeśli nie określisz bazy danych uwierzytelniania lub bazy danych do wyeksportowania, mongodump zakłada, że baza danych administratora zawiera dane uwierzytelniające użytkownika.
--db :Określa bazę danych, z której ma zostać wykonana kopia zapasowa. Jeśli nie określisz bazy danych, mongodump zbiera dane ze wszystkich baz danych w tej instancji.
Alternatywnie można również określić bazę danych bezpośrednio w ciągu połączenia URI, tj. mongodb://username:password@uri/dbname .
Dostarczenie ciągu połączenia przy użyciu --db a podanie sprzecznych informacji spowoduje błąd .
--collection :Określa kolekcję do utworzenia kopii zapasowej. Jeśli nie określisz kolekcji, ta opcja kopiuje wszystkie kolekcje z określonej bazy danych lub instancji do plików zrzutu.
--query :dostarcza dokument JSON jako zapytanie, które opcjonalnie ogranicza dokumenty zawarte w danych wyjściowych mongodump.
Musisz ująć dokument zapytania w pojedynczych cudzysłowach ('{ ... }') aby upewnić się, że nie wchodzi w interakcję z Twoim środowiskiem.
Kwerenda musi być w formacie Extended JSON v2 (w trybie swobodnym lub kanonicznym/ścisłym), w tym zawierać nazwy pól i operatory w cudzysłowie, np. '{ "created_at": { "\$gte": ISODate(...) } }' .
Aby użyć --query opcja, musisz również określić --collection opcja.
--forceTableScan :Wymusza na mongodump bezpośrednie skanowanie magazynu danych. Zazwyczaj mongodump zapisuje wpisy tak, jak pojawiają się w indeksie _id pole.
Jeśli określisz zapytanie --query , mongodump użyje najbardziej odpowiedniego indeksu do obsługi tego zapytania.
Dlatego nie możesz użyć --forceTableScan z --query opcja .
--gzip :kompresuje dane wyjściowe. Jeśli mongodump wyprowadza dane do katalogu zrzutu, nowa funkcja kompresuje poszczególne pliki. Pliki mają rozszerzenie .gz .
--out :Określa katalog, w którym mongodump zapisze BSON pliki dla zrzuconych baz danych. Domyślnie mongodump zapisuje pliki wyjściowe w katalogu o nazwie dump w bieżącym katalogu roboczym.
Przywracanie kopii zapasowej
Użyjemy programu narzędziowego o nazwie mongorestore do przywrócenia kopii zapasowej bazy danych.
Skopiuj zrzut katalogu kopii zapasowej do nowej instancji bazy danych i uruchom następujące polecenie:
mongorestore --uri="mongodb://user:password@host:port/?authSource=admin" \
--drop --noIndexRestore --gzip -v ./dump
Zastąp poświadczenia nowymi poświadczeniami bazy danych. Usuń linię w poprzednim kroku, --authenticationDatabase opcja jest określona w ciągu URI.
Użyj także --gzip jeśli jest używany podczas tworzenia kopii zapasowej.
--drop :Przed przywróceniem kolekcji ze zrzuconej kopii zapasowej usuwa kolekcje z docelowej bazy danych. Nie usuwa kolekcji, których nie ma w kopii zapasowej.--noIndexRestore :Uniemożliwia mongorestore przywracanie i budowanie indeksów określonych w odpowiednich danych wyjściowych mongodump.
Jeśli chcesz zmienić nazwę bazy danych podczas przywracania, możesz to zrobić za pomocą --nsFrom="old_name.*" --nsTo="new_name.*" opcje.
Jednak nie zadziała, jeśli przeprowadzisz migrację za pomocą oplogs co jest wymagane przy migracji z instancji online.
Migracja z internetowej bazy danych w MongoDB
Jedynym wyzwaniem związanym z migracją z bazy danych online nie jest możliwość wstrzymania aktualizacji podczas migracji. Oto przegląd kroków,
- Uruchom początkową migrację zbiorczą za pomocą
oplogsprzechwytywanie - Uruchom zadanie synchronizacji, aby złagodzić opóźnienie przełączania połączenia z bazą danych
Teraz, aby przechwycić oplogs , zestaw replik musi zostać zainicjowany w źródłowej i docelowej bazie danych. Dzieje się tak, ponieważ oplogs są przechwytywane z local.oplog.rs przestrzeń nazw, która jest tworzona po zainicjowaniu zestawu replik.
Możesz postępować zgodnie z tym przewodnikiem, aby skonfigurować zestaw replik.
Początkowa migracja z Oplog Capture
Oplogs, w prostych słowach, to dzienniki operacji tworzone na operację w bazie danych. Reprezentują częściowy stan dokumentu lub innymi słowy stan bazy danych. Dlatego zamierzamy przechwycić wszelkie aktualizacje naszej starej bazy danych podczas procesu migracji za pomocą tych oplogs .
Uruchom program mongodump z następującymi opcjami,
mongodump --uri=".../?authSource=admin" \
--forceTableScan --oplog \
--gzip -v --out ./dump
--oplog :Tworzy plik o nazwie oplog.bson jako część mongodump wyjście. oplog.bson plik, znajdujący się na najwyższym poziomie katalogu wyjściowego, zawiera oplog wpisy, które występują podczas operacji mongodump. Ten plik zapewnia efektywną migawkę stanu naszej instancji bazy danych w określonym momencie.
Przywróć dane za pomocą oplog replay
Aby odtworzyć oplogi, wymagana jest specjalna rola. Utwórzmy i przypiszmy rolę do użytkownika bazy danych używanego do migracji.
Utwórz rolę
db.createRole({
role: "interalUseOnlyOplogRestore",
privileges: [
{
resource: { anyResource: true },
actions: [ "anyAction" ]
}
],
roles: []
})Przypisz rolę
db.grantRolesToUser(
"admin",
[{ role:"interalUseOnlyOplogRestore", db:"admin" }]
);Teraz możesz przywrócić za pomocą programu mongorestore z następującymi opcjami,
mongorestore --uri="mongodb://admin:.../?authSource=admin" \
--oplogReplay
--gzip -v ./dump
W powyższym poleceniu, używając tego samego użytkownika admin z kim ta rola była powiązana.
--oplogReplay :Po przywróceniu zrzutu bazy danych, odtwarza wpisy oplog z pliku bson i przywraca bazę danych do kopii zapasowej z określonego punktu w czasie przechwyconej za pomocą mongodump --oplog polecenie.
Ograniczanie opóźnienia przełączania połączenia z bazą danych
W porządku, jak dotąd skończyliśmy z większością ciężkich prac. Jedyne, co pozostaje, to utrzymanie spójności między bazami danych podczas przełączania połączenia na naszych serwerach aplikacji.
Jeśli używasz MongoDB w wersji 3.6+, lepiej wybrać podejście Change Stream, które jest mechanizmem opartym na zdarzeniach wprowadzonym w celu przechwytywania zmian w bazie danych w zoptymalizowany sposób. Oto artykuł, który to obejmuje https://www.mongodb.com/blog/post/an-introduction-to-change-streams
Sprawdź ogólny skrypt synchronizacji, który możesz uruchamiać jako zadanie CRON co minutę.
Zaktualizuj zmienne w tym skrypcie i uruchom jako
$ ./delta-sync.sh from_epoch_in_milliseconds
# from_epoch_in_milliseconds is automatically picked with every iteration if not suppliedMożesz też skonfigurować zadanie cron, aby uruchamiało to co minutę.
* * * * * ~/delta-sync.shDane wyjściowe można monitorować za pomocą następującego polecenia (używam RHEL 8, zapoznaj się z przewodnikiem po systemie operacyjnym, aby uzyskać informacje o danych wyjściowych cron)
$ tail -f /var/log/cron | grep CRONTo jest przykładowy dziennik synchronizacji.
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!)
Możesz zatrzymać ten skrypt po sprawdzeniu, że nie ma już więcej oplogs są tworzone, tj. gdy źródłowa baza danych przeszła w tryb offline.
Na tym kończy się kompletny przewodnik dotyczący samoobsługowej migracji danych MongoDB. Jeśli chcesz dowiedzieć się więcej o MongoDB, tutaj znajdziesz przydatne źródło informacji o tym, jak używać MongoDB jako źródła danych w goLang.
