Databázový systém funguje nejlépe, když je integrován s některými dobře definovanými přístupy, které usnadňují operace čtení i zápisu. MongoDB šel o krok navíc tím, že přijal replikaci a sharding s cílem umožnit horizontální a vertikální škálování na rozdíl od relačních DBM, jejichž stejný koncept pouze zlepšuje vertikální škálování.
Sharding zajišťuje rozložení zátěže mezi členy databázového clusteru, takže operace čtení jsou prováděny s malou latencí. Bez shardingu může být kapacita jednoho databázového serveru s velkým souborem dat a vysokou propustností operací technicky zpochybněna a může mít za následek selhání tohoto serveru, pokud nebudou brána v úvahu nezbytná opatření. Pokud je například rychlost dotazů velmi vysoká, kapacita CPU serveru bude zahlcena.
Replikace je na druhé straně koncept, kdy různé databázové servery uchovávají stejná data. Kromě zvýšení integrity dat zajišťuje vysokou dostupnost dat. Vezměte si příklad vysoce výkonné aplikace sociálních médií, pokud selže hlavní obsluhující databázový systém jako v případě výpadku proudu, měli bychom mít jiný systém, který bude obsluhovat stejná data. Dobrá sada replik by měla mít více než 3 členy, arbitra a optimální volbyTimeoutMillis. Při replikaci budeme mít hlavní/primární uzel, kde se provádějí všechny operace zápisu a poté se aplikují na Oplog. Z Oplogu jsou pak všechny provedené změny aplikovány na ostatní členy, které jsou v tomto případě označovány jako sekundární uzly nebo slave. V případě, že primární uzly po nějaké době nekomunikují:choiceTimeoutMillis, ostatní uzly jsou signalizovány k volbám. VolbyTimeoutMillis by neměly být nastaveny příliš vysoko ani příliš nízko z důvodu, že systémy budou dlouhou dobu mimo provoz a tím dojde ke ztrátě velkého množství dat nebo častým volbám, ke kterým může dojít i při dočasné latenci sítě, tedy nekonzistenci dat. Arbiter se používá k přidání hlasu vítěznému členovi, aby se stal mistrem v případě, že dojde k remíze, ale nenese žádná data jako ostatní členové.
Proč používat loutku k nasazení sady replik MongoDB
Častěji se sharing používá ruku v ruce s replikací. Proces konfigurace a údržby sady replik není snadný kvůli:
- Vysoká pravděpodobnost lidské chyby
- Neschopnost automaticky provádět opakující se úkoly
- Časově náročné, zvláště když se účastní velký počet členů
- Možnost pracovní nespokojenosti
- Zdrcující složitost, která se může objevit.
Abychom překonali nastíněné překážky, spokojíme se s automatizovaným systémem, jako je Puppet, který má spoustu zdrojů, které nám pomohou snadno pracovat.
V našem předchozím blogu jsme se naučili proces instalace a konfigurace MongoDB pomocí Puppet. Je však důležité porozumět základním zdrojům Puppet, protože je budeme používat při konfiguraci naší sady replik a fragmentů. V případě, že jste to propásli, toto je soubor manifestu pro proces instalace a spuštění vašeho MongoDB na počítači, který jste vytvořili
package {'mongodb':
ensure => 'installed',
}
service {'mongodb':
ensure => 'running',
enable => true
}Výše uvedený obsah tedy můžeme vložit do souboru s názvem runMongoDB.pp a spustit jej příkazem
$ sudo apply runMongoDB.ppS pomocí modulu a funkcí 'mongodb' můžeme nastavit naši sadu replik s odpovídajícími parametry pro každý zdroj mongodb.
Připojení MongoDB
Potřebujeme vytvořit mongodb spojení mezi uzlem a mongodb serverem. Hlavním cílem je zabránit použití změn konfigurace, pokud nelze dosáhnout serveru mongodb, ale může být potenciálně použit pro jiné účely, jako je monitorování databáze. Používáme mongodb_conn_validator
mongodb_conn_validator{‘mongodb_validator’:
ensure => present,
server: ‘127.0.0.1:27017’,
timeout: 40,
tcp_port:27017
}name: v tomto případě název mongodb_validator definuje identitu zdroje. Může být také považován za spojovací řetězec
server:může to být řetězec nebo pole řetězců obsahující názvy DNS/IP adresy serveru, na kterém by měl být spuštěn mongodb.
timeout:toto je maximální počet sekund, po který by měl validátor čekat, než rozhodne, že puppetdb neběží.
tcp_port: toto je poskytovatel pro zdroj, který ověřuje připojení mongodb pokusem o připojení https k serveru mongodb. Při ověřování je použito nastavení loutkového SSL certifikátu z místního prostředí loutky.
Vytvoření databáze
mongodb_database{‘databaseName’:
ensure => present,
tries => 10
}Tato funkce má 3 parametry, tedy:
name: v tomto případě název databaseName definuje název databáze, kterou vytváříme, a který by byl také deklarován jako name => ‘databaseName’.
pokusy:toto definuje maximální počet dvou sekundových pokusů pro čekání na spuštění MongoDB
Vytvoření uživatele MongoDB
Modul mongodb_user umožňuje vytvářet a spravovat uživatele pro danou databázi v loutkovém modulu.
mongodb_user {userprod:
username => ‘prodUser’,
ensure => present,
password_hash => mongodb_password(‘prodUser’, ‘passProdser’),
database => prodUser,
roles => [‘readWrite’, ‘dbAdmin’],
tries => 10
}Vlastnosti
uživatelské jméno:definuje jméno uživatele.
password_hash:toto je hash hesla uživatele. K vytvoření hashe se používá funkce mongodb_password() dostupná na MongoDB 3.0 a novějších.
role:toto definuje role, které může uživatel v cílové databázi vykonávat.
heslo:toto je prostý text uživatelského hesla.
databáze:definuje cílovou databázi uživatele.
Vytvoření sady replik
K vytvoření sady replik používáme modul mongodb_replset.
Mongodb_replset{'replicaset1':
arbiter: 'host0:27017',
ensure => present,
members => ['host0:27017','host1:27017', 'host2:27017', 'host3:27017']
initialize_host: host1:27017
}name:definuje název sady replik.
členové:pole členů, které sada replik pojme.
initialize_host:hostitel, který má být použit při inicializaci sady replik
arbiter:definuje člen sady replik, který bude použit jako arbitr.
Vytvoření fragmentu MongoDB
mongodb_shard{'shard1':
ensure => present,
members => ['shard1/host1:27017', 'shard1/host2:27017', 'shard1/host3:27017']
keys: 'price'
}name:definuje název datového fragmentu.
členové:toto pole členů, které bude fragment obsahovat.
klíče:definujte klíč, který se má použít při shardingu, nebo pole klíčů, které lze použít k vytvoření složeného shard key.