Zestaw replik to zestaw komputerów, które są swoimi klonami. (tj.:repliki ) W danym zestawie znajduje się wybrany mistrz. Domyślnie odczyty i zapisy trafiają do tego wybranego wzorca, a repliki po prostu „śledzą” zmiany, aby były aktualnymi kopiami. Jeśli mistrz zawiedzie, wybierany jest nowy, a system po prostu działa. Dokumentacja znajduje się tutaj .
Pytasz więc o skalowanie z MongoDB. Istnieją dwa rodzaje skalowania:
Minimalna konfiguracja zestawów replik to – 2 pełne repliki – 1 arbiter (lekki proces, zrywa remisy podczas głosowania)
Minimalna konfiguracja dla shardingu to – 1 serwer konfiguracyjny – 1 mongod proces (tylko jeden fragment) - 1 lub więcej mongos (zazwyczaj na serwerze aplikacji)
Jednak prawdopodobnie nie chcesz tak działać w środowisku produkcyjnym. Uruchamianie tylko jednej bazy danych oznacza, że masz tylko jedno źródło danych, co może skutkować dużymi przestojami lub całkowitą utratą danych. Zwykle jest to rozwiązywane za pomocą zestawów replik.
Dodatkowo serwer konfiguracyjny jest dość ważny. MongoDB obsługuje 1 lub 3 serwery konfiguracyjne. Większość wdrożeń produkcyjnych używa 3. Pamiętaj, że serwery konfiguracyjne i arbitrzy są bardzo lekkie i mogą działać na innych urządzeniach lub na mikroinstancjach Amazon.
Większość wdrożeń produkcyjnych z fragmentacją obejmuje również zestawy replik. W rzeczywistości zwykle zaczynają się jako zestawy replik.
Z perspektywy shardingu powinno być tak proste, jak:- uruchom nowy serwer shard - uruchom addshard
polecenie z mongos
Pamiętaj, że po dodaniu fragmentu będziesz musiał poświęcić czas i zasoby, ponieważ dane są migrowane między fragmentami i wszystko jest ponownie równoważone.
