Podstawy wdrażania zestawu replik MongoDB i fragmentów za pomocą marionetki

Systemy baz danych działają najlepiej, gdy są zintegrowane z pewnymi dobrze zdefiniowanymi podejściami, które ułatwiają zarówno operacje odczytu, jak i zapisu. MongoDB poszło o krok dalej, obejmując replikację i sharding w celu umożliwienia skalowania poziomego i pionowego, w przeciwieństwie do relacyjnych DBM, których ta sama koncepcja tylko poprawia skalowanie pionowe.

 Sharding zapewnia rozłożenie obciążenia między członków klastra bazy danych, dzięki czemu operacje odczytu są przeprowadzane z niewielkim opóźnieniem. Bez shardingu pojemność pojedynczego serwera bazy danych z dużym zbiorem danych i operacjami o wysokiej przepustowości może być technicznie zagrożona i może spowodować awarię tego serwera, jeśli nie zostaną wzięte pod uwagę niezbędne środki. Na przykład, jeśli częstotliwość zapytań jest bardzo wysoka, moc procesora serwera zostanie przytłoczona.

Z drugiej strony replikacja to koncepcja, w której różne serwery baz danych przechowują te same dane. Zapewnia wysoką dostępność danych oprócz poprawy integralności danych. Weźmy na przykład wysoce wydajną aplikację społecznościową, jeśli główny obsługujący system bazy danych ulegnie awarii, jak w przypadku awarii zasilania, powinniśmy mieć inny system obsługujący te same dane. Dobry zestaw replik powinien mieć więcej niż 3 członków, arbitra i optymalny czas trwania wyborów Millis. W replikacji będziemy mieli węzeł główny/główny, w którym wykonywane są wszystkie operacje zapisu, a następnie stosowane do Oploga. Z Oploga wszystkie wprowadzone zmiany są następnie stosowane do innych elementów, które w tym przypadku są określane jako węzły drugorzędne lub urządzenia podrzędne. W przypadku, gdy węzły podstawowe nie komunikują się po pewnym czasie:electTimeoutMillis, pozostałe węzły są sygnalizowane, aby przejść do wyborów. Wybory TimeoutMillis nie powinny być ustawione zbyt wysoko ani zbyt nisko, ponieważ systemy będą nieczynne przez dłuższy czas, co spowoduje utratę dużej ilości danych lub częste wybory, które mogą skutkować nawet chwilowym opóźnieniem sieci, a zatem odpowiednio niespójnością danych. Arbiter służy do oddania głosu na zwycięskiego członka, aby zostać mistrzem w przypadku remisu, ale nie zawiera żadnych danych, jak inni członkowie.

Dlaczego warto używać marionetki do wdrażania zestawu replik MongoDB

Częściej sharding jest używany w parze z replikacją. Proces konfiguracji i utrzymania zestawu replik nie jest łatwy ze względu na:

1. Wysokie prawdopodobieństwo błędu ludzkiego
2. Niezdolność do automatycznego wykonywania powtarzalnych zadań
3. Czasochłonne, zwłaszcza gdy zaangażowana jest duża liczba członków
4. Możliwość niezadowolenia z pracy
5. Przytłaczająca złożoność, która może się pojawić.

Aby przezwyciężyć opisane trudności, decydujemy się na zautomatyzowany system, taki jak Puppet, który ma mnóstwo zasobów ułatwiających nam pracę.

W naszym poprzednim blogu poznaliśmy proces instalacji i konfiguracji MongoDB za pomocą Puppet. Jednak ważne jest, aby zrozumieć podstawowe zasoby Puppet, ponieważ będziemy ich używać do konfiguracji naszego zestawu replik i odłamków. Jeśli go przegapiłeś, jest to plik manifestu dla procesu instalacji i uruchamiania MongoDB na utworzonym przez Ciebie komputerze

​  package {'mongodb':

    ensure => 'installed',

  }

  service {'mongodb':

    ensure => 'running',

    enable => true

  }

Możemy więc umieścić powyższą zawartość w pliku o nazwie runMongoDB.pp i uruchomić go za pomocą polecenia 

$ sudo apply runMongoDB.pp

Wyśpiewuj moduł i funkcje „mongodb”, możemy skonfigurować nasz zestaw replik z odpowiednimi parametrami dla każdego zasobu mongodb.

Połączenie MongoDB

Musimy ustanowić połączenie mongodb między węzłem a serwerem mongodb. Głównym celem jest zapobieganie stosowaniu zmian konfiguracji, jeśli serwer mongodb jest nieosiągalny, ale potencjalnie może być użyty do innych celów, takich jak monitorowanie bazy danych. Używamy mongodb_conn_validator

mongodb_conn_validator{‘mongodb_validator’:

ensure => present,

     server: ‘127.0.0.1:27017’,

     timeout: 40,

     tcp_port:27017

    }

nazwa:  w tym przypadku nazwa mongodb_validator określa tożsamość zasobu. Może być również uważany za ciąg połączenia

serwer:może to być ciąg lub tablica ciągów zawierających nazwy DNS/adresy IP serwera, na którym ma działać mongodb.

limit czasu:jest to maksymalna liczba sekund, przez którą walidator powinien odczekać zanim zdecyduje, że baza danych nie jest uruchomiona.

tcp_port:  jest to dostawca zasobu, który weryfikuje połączenie mongodb, próbując nawiązać połączenie https z serwerem mongodb. Podczas uwierzytelniania używana jest konfiguracja marionetkowego certyfikatu SSL z lokalnego środowiska marionetkowego.

Tworzenie bazy danych

mongodb_database{‘databaseName’:

ensure => present,

     tries => 10

}

Ta funkcja przyjmuje 3 parametry, czyli:

name:  w tym przypadku nazwa databaseName określa nazwę tworzonej bazy danych, która również zostałaby zadeklarowana jako name => „databaseName”.

próby:określa maksymalną ilość dwóch sekund prób oczekiwania na uruchomienie MongoDB

Tworzenie użytkownika MongoDB

Moduł mongodb_user umożliwia tworzenie i zarządzanie użytkownikami dla danej bazy danych w module marionetek.

mongodb_user {userprod:

  username => ‘prodUser’,

  ensure => present,

  password_hash => mongodb_password(‘prodUser’, ‘passProdser’),

  database => prodUser,

  roles => [‘readWrite’, ‘dbAdmin’],

  tries  => 10

}

Właściwości

nazwa użytkownika:określa nazwę użytkownika.

password_hash:jest to skrót hasła użytkownika. Funkcja mongodb_password() dostępna w MongoDB 3.0 i nowszych jest używana do tworzenia skrótu.

role:definiuje role, które użytkownik może wykonywać w docelowej bazie danych.

hasło:to jest zwykły tekst hasła użytkownika.

baza danych:określa docelową bazę danych użytkownika.

Tworzenie zestawu replik

Do utworzenia zestawu replik używamy modułu mongodb_replset.

Mongodb_replset{'replicaset1':

   arbiter: 'host0:27017',

   ensure  => present,

   members => ['host0:27017','host1:27017', 'host2:27017', 'host3:27017'] 

   initialize_host: host1:27017

}

nazwa:określa nazwę zestawu replik.

członkowie:tablica członków, które będzie zawierać zestaw replik.

initialize_host:host używany do inicjalizacji zestawu replik

arbiter:definiuje członka zestawu replik, który będzie używany jako arbiter.

Tworzenie fragmentu MongoDB

mongodb_shard{'shard1':

   ensure  => present,

   members => ['shard1/host1:27017', 'shard1/host2:27017', 'shard1/host3:27017'] 

   keys: 'price'

}

nazwa:określa nazwę fragmentu.

członkowie:jest to tablica członków, które będzie przechowywać odłamek.

klucze:zdefiniuj klucz do użycia w shardingu lub tablicę kluczy, które mogą być użyte do utworzenia złożonego klucza shard.