replikacja mongoDB + sharding na 2 serwerach uzasadnione?

Question

Należy wziąć pod uwagę następujące ustawienia:

Istnieją dwa serwery fizyczne skonfigurowane jako regularne zestawy replikacji mongodów (w tym proces arbitra, więc automatyczne przełączanie awaryjne będzie działać poprawnie).

teraz, o ile rozumiem, większość faktycznych prac będzie wykonywana na serwerze głównym, podczas gdy urządzenie slave będzie głównie pracowało nad zsynchronizowaniem swojego zestawu danych.

Czy byłoby rozsądnie, wprowadzić shardowanie do tej konfiguracji w taki sposób, aby ustawić inny zestaw replikacji na tych samych 2 serwerach, aby każdy z nich miał jeden proces mongody działający jako podstawowy i jeden proces działający jako pomocniczy .

Oczekiwany wynik to fakt, że oba serwery będą dzielić obciążenie rzeczywistych zapytań/wstawień, gdy oba są w górze. W przypadku awarii jednego serwera, cała instalacja powinna pomyślnie zakończyć się niepowodzeniem, dopóki drugi serwer nie zostanie przywrócony.

Czy są jakieś minusy tej konfiguracji, z wyjątkiem ogólnych kosztów instalacji i liczby procesów (mongos/configservers/arbitrów)?

Answer 1

To na pewno zadziała. Już wcześniej zadawałem pytanie na kanale #mongodb IRC, czy nie jest to zły pomysł na uruchamianie wielu procesów mongod na jednej maszynie. Odpowiedź brzmiała "tak długo, jak masz RAM/CPU/przepustowość, idź orzechy".

Warto zauważyć, że jeśli szukasz wysokiej wydajności czyta, a nie przeszkadza pisze jest nieco wolniejszy, można:

• zrobić swoją pisze w „trybie awaryjnym”, gdzie zapisu nie wraca, dopóki nie został propagowane do N serwerów (w tym przypadku, gdzie N oznacza liczbę serwerów w zestawie replik, więc wszystkie z nich)
• Ustaw flagę kierowcę stosowne w związku kod umożliwiający odczyt z niewolników.

To dostarczy Ci zestaw w klastrze podobny do MySQL - napisz raz na wzorcu, ale którykolwiek z niewolników kwalifikuje się do odczytu. W sytuacji, gdy masz dużo więcej odczytów niż zapisów (powiedzmy, rząd wielkości), może to być wyższa wydajność, ale nie wiem, jak by się zachowywało, gdy węzeł przestanie działać (ponieważ zapisy mogą utknąć próbując pisać do 3 węzłów, ale tylko 2 są w górze itd. - to wymagałoby testowania).

Answer 2

Brakuje jednego kluczowego szczegółu: jeśli masz zmienioną konfigurację tylko z dwoma fizycznymi węzłami, jeśli zginiesz, wszystkie twoje dane znikną. Dzieje się tak dlatego, że nie ma żadnej nadmiarowości poniżej warstwy shardingu (zalecanym sposobem jest to, że każdy fragment składa się z zestawu replik).

To, co powiedziałeś o zestawie replik, jest jednak prawdziwe: możesz uruchomić go na dwóch węzłach współdzielonych i mieć dodatkowego arbitra. Jednak zalecana konfiguracja to 3 węzły: jeden podstawowy i dwa wtórne.

http://www.markus-gattol.name/ws/mongodb.html#do_i_need_an_arbiter

Answer 3

W tej sytuacji, to bym sharding rozważyć w pierwszej kolejności, a po prostu zrobić to un-sharded zestawu replik na 2 maszynach (+1 arbitra).

Answer 4

Jedną rzeczą, na którą należy zwrócić uwagę, jest to, że podczas gdy oba urządzenia są podniesione, twoje zapytania są dzielone między nimi.Kiedy jeden z nich upadnie, wszystkie zapytania trafią do pozostałej maszyny, podwajając w ten sposób nałożone na nią wymagania. Musiałbyś się upewnić, że twoje maszyny wytrzymają nagłe podwojenie zapytań.