Jak skonfigurować sterownik MongoDB Java MongoOptions do użytku produkcyjnego?

Zaktualizowano do wersji 2.9:

• ponowna próba połączenia oznacza po prostu, że sterownik automatycznie spróbuje ponownie połączyć się z serwerem (serwerami) po nieoczekiwanym rozłączeniu. W środowiskach produkcyjnych zwykle chcesz, aby ten zestaw był prawdziwy.

• connectionsPerHost to ilość fizycznych połączeń, jakie pojedyncza instancja Mongo (jest to pojedyncza, więc zwykle masz jedno na aplikację) może nawiązać z procesem mongod/mongos. W momencie pisania tego tekstu sterownik java w końcu nawiąże tę liczbę połączeń, nawet jeśli rzeczywista przepustowość zapytań jest niska (w kolejności słów zobaczysz statystykę „conn” w mongostacie, aż osiągnie tę liczbę na serwer aplikacji).

  W większości przypadków nie ma potrzeby ustawiania tego na wartość wyższą niż 100, ale to ustawienie jest jednym z elementów „przetestuj i zobacz”. Pamiętaj, że musisz upewnić się, że ustawiłeś tę wartość na tyle nisko, aby łączna liczba połączeń z Twoim serwerem nie przekroczyła

  db.serverStatus().connections.available

  W produkcji mamy to obecnie na poziomie 40.

• Czas połączenia . Jak sama nazwa wskazuje, liczba milisekund sterownik będzie czekać, zanim próba połączenia zostanie przerwana. Ustaw limit czasu na coś długiego (15-30 sekund), chyba że istnieje realistyczna, oczekiwana szansa, że ​​będzie to przeszkodą w udanych próbach połączenia. Zwykle, jeśli próba połączenia trwa dłużej niż kilka sekund, twoja infrastruktura sieciowa nie jest w stanie zapewnić wysokiej przepustowości.

• maxWaitTime . Liczba ms, przez którą wątek będzie czekał, aż połączenie stanie się dostępne w puli połączeń i zgłasza wyjątek, jeśli nie nastąpi to na czas. Zachowaj wartość domyślną.

• socketTimeout . Standardowa wartość limitu czasu gniazda. Ustaw na 60 sekund (60000).

• wątkiAllowedToBlockForConnectionMultiplier . Mnożnik dla connectionPerHost, który wskazuje liczbę wątków, które mogą czekać na dostępność połączeń, jeśli pula jest obecnie wyczerpana. Jest to ustawienie, które spowoduje wystąpienie wyjątku „com.mongodb.DBPortPool$SemaphoresOut:Out of semaphores, aby uzyskać połączenie z bazą danych”. Zgłosi ten wyjątek, gdy kolejka wątków przekroczy wartość threadsAllowedToBlockForConnectionMultiplier. Na przykład, jeśli connectionPerHost ma wartość 10, a ta wartość wynosi 5, do 50 wątków może zostać zablokowanych przed zgłoszeniem wyżej wymienionego wyjątku.

  Jeśli spodziewasz się dużych szczytów przepustowości, które mogą powodować duże kolejki, tymczasowo zwiększ tę wartość. Właśnie z tego powodu mamy go w tej chwili o godzinie 1500. Jeśli obciążenie twojego zapytania stale przewyższa serwer, powinieneś po prostu odpowiednio poprawić sytuację sprzętową/skalowania.

• odczytajPreferencje . (ZAKTUALIZOWANE, 2.8+) Służy do określania domyślnych preferencji odczytu i zastępuje „slaveOk”. Skonfiguruj ReadPreference za pomocą jednej z metod fabryki klas. Pełny opis najczęstszych ustawień można znaleźć na końcu tego posta

• w . (ZAKTUALIZOWANE, 2.6+) Ta wartość określa „bezpieczeństwo” zapisu. Gdy ta wartość wynosi -1, zapis nie zgłosi żadnych błędów niezależnie od błędów sieci lub bazy danych. WriteConcern.NONE jest do tego odpowiednim predefiniowanym WriteConcern. Jeśli w wynosi 0, błędy sieciowe spowodują, że zapis się nie powiedzie, ale błędy mongo nie. Jest to zwykle określane jako zapis „uruchom i zapomnij” i powinno być używane, gdy wydajność jest ważniejsza niż spójność i trwałość. W tym trybie użyj WriteConcern.NORMAL.

  Jeśli ustawisz w na 1 lub więcej, zapis jest uważany za bezpieczny. Bezpieczne zapisy wykonują zapis, a następnie wysyłają żądanie do serwera, aby upewnić się, że zapis się powiódł, lub w przypadku niepowodzenia pobiera wartość błędu (innymi słowy, po zapisaniu wysyła polecenie getLastError()). Zauważ, że dopóki ta komenda getLastError() nie zostanie zakończona, połączenie jest zarezerwowane. W wyniku tego i dodatkowego polecenia przepustowość będzie znacznie niższa niż zapisów zw <=0. Przy wartości w dokładnie 1 MongoDB gwarantuje, że zapis powiódł się (lub nie powiódł się) na instancji, do której wysłałeś zapis.

  W przypadku zestawów replik można użyć wyższych wartości w, które powiedzą MongoDB, aby przed zwróceniem wysłały zapis do co najmniej „w” członków zestawu replik (lub dokładniej, poczekaj na replikację twojego zapisu do członków „w” ). Możesz również ustawić w na ciąg „większość”, który mówi MongoDB, aby wykonał zapis do większości członków zestawu replik (WriteConcern.MAJORITY). Zazwyczaj powinieneś ustawić to na 1, chyba że potrzebujesz surowej wydajności (-1 lub 0) lub zreplikowanych zapisów (>1). Wartości wyższe niż 1 mają znaczny wpływ na przepustowość zapisu.

• fsync . Opcja trwałości, która wymusza opróżnianie mongo na dysk po każdym zapisie, gdy jest włączona. Nigdy nie miałem żadnych problemów z trwałością związanych z zaległościami w zapisie, więc w środowisku produkcyjnym mamy to na wartość false (domyślnie).

• j *(NOWOŚĆ 2.7+) *. Wartość logiczna, która po ustawieniu na true zmusza MongoDB do czekania na pomyślne zatwierdzenie grupy księgowania przed powrotem. Jeśli masz włączone kronikowanie, możesz to włączyć, aby uzyskać dodatkową trwałość. Odwiedź stronę http://www.mongodb.org/display/DOCS/Journaling, aby zobaczyć, co daje dziennikarstwo (i dlaczego możesz chcieć włączyć tę flagę).

Czytaj preferencje Klasa ReadPreference umożliwia skonfigurowanie, do jakich zapytań o instancje mongod są kierowane, jeśli pracujesz z zestawami replik. Dostępne są następujące opcje:

• ReadPreference.primary() :Wszystkie odczyty trafiają tylko do głównego elementu członkowskiego resetowania. Użyj tego, jeśli chcesz, aby wszystkie zapytania zwracały spójne (ostatnio zapisane) dane. To jest ustawienie domyślne.

• ReadPreference.primaryPreferred() :wszystkie odczyty trafiają do głównego elementu członkowskiego resetowania, jeśli to możliwe, ale mogą wysyłać zapytania do elementów pomocniczych, jeśli węzeł podstawowy jest niedostępny. W związku z tym, jeśli podstawowa staje się niedostępna, odczyty stają się w końcu spójne, ale tylko wtedy, gdy podstawowa jest niedostępna.

• ReadPreference.secondary() :Wszystkie odczyty trafiają do drugorzędnych członków zresetowanych, a podstawowy element członkowski jest używany tylko do zapisów. Używaj tego tylko wtedy, gdy możesz żyć z ostatecznie spójnymi odczytami. Dodatkowych członków repety można użyć do zwiększenia wydajności odczytu, chociaż istnieją ograniczenia dotyczące liczby (głosujących) członków, jaką może mieć repset.

• ReadPreference.secondaryPreferred() :Wszystkie odczyty trafiają do drugorzędnych członków zresetowanych, jeśli którykolwiek z nich jest dostępny. Podstawowy element członkowski jest używany wyłącznie do zapisów, chyba że wszystkie dodatkowe elementy członkowskie staną się niedostępne. Poza powrotem do podstawowego elementu członkowskiego dla odczytów jest to to samo, co ReadPreference.secondary().

• ReadPreference.nearest() :Odczyty trafiają do najbliższego członka repset dostępnego dla klienta bazy danych. Używaj tylko wtedy, gdy ostatecznie spójne odczyty są akceptowalne. Najbliższy członek to członek z najmniejszym opóźnieniem między klientem a różnymi członkami zresetowanymi. Ponieważ zajęci członkowie w końcu będą mieli wyższe opóźnienia, powinno również automatycznie równoważy obciążenie odczytu, chociaż z mojego doświadczenia wynika, że ​​drugorzędne (preferowane) wydaje się to robić lepiej, jeśli opóźnienia członków są stosunkowo spójne.

Uwaga :Wszystkie powyższe mają wersje tej samej metody obsługujące tagi, które zamiast tego zwracają instancje TaggableReadPreference. Pełny opis tagów zestawu replik można znaleźć tutaj:Tagi zestawu replik