sql >> Databasteknik >  >> NoSQL >> MongoDB

Distribuera och konfigurera MongoDB Shards med Ansible

Databassystem fungerar bättre när det finns en fördelad arbetsbelastning mellan ett antal pågående instanser eller snarare data kategoriseras på ett enkelt sätt. MongoDB använder sharding så att data i en given databas grupperas i enlighet med någon nyckel. Sharding förbättrar horisontell skalning vilket resulterar i bättre prestanda och ökad tillförlitlighet. I allmänhet erbjuder MongoDB horisontell och vertikal skalning i motsats till SQL DBMS till exempel MySQL som endast främjar vertikal skalning.

MongoDB har en lösare konsistensmodell där ett dokument i en samling kan ha en extra nyckel som skulle saknas i andra dokument i samma samling.

Skärning

Sharding är i princip att partitionera data i separata bitar och sedan definiera en rad bitar till olika shard-servrar. En shardnyckel som ofta är ett fält som finns i alla dokument i databasen som ska delas används för att gruppera data. Sharding fungerar hand i hand med replikering för att snabba upp läsgenomströmningen genom att säkerställa en fördelad arbetsbelastning mellan ett antal servrar snarare än att vara beroende av en enskild server. Dessutom säkerställer replikering att kopior av skrivna data finns tillgängliga.

Låt oss säga att vi har 120 dokument i en samling, dessa data kan delas så att vi har 3 replikuppsättningar och var och en har 40 dokument som visas i konfigurationsinställningarna nedan. Om två klienter skickar förfrågningar, en för att hämta ett dokument som finns i index 35 och den andra vars index är på 92, tas förfrågan emot av frågeroutern (en mongoprocess) som i sin tur kontaktar konfigurationsnoden som håller register över hur intervallen av bitar är fördelade mellan skärvorna. När den angivna dokumentidentiteten hittas, hämtas den sedan från den associerade skärpan. Till exempel ovan kommer den första klientens dokument att hämtas från Shard A och för klient B kommer dokumentet att hämtas från Shard C. I allmänhet kommer det att finnas en distribuerad arbetsbelastning som definieras som horisontell skalning.

För de givna skärvorna, om storleken på en samling i en skärva överstiger chunk_size, kommer samlingen att delas och balanseras över skärvorna automatiskt med den definierade skärvnyckeln. I installationsinställningarna, för exemplet nedan, behöver vi 3 replikuppsättningar vardera med en primär och några sekundära. De primära noderna fungerar också som sharding-servrar.

Den minsta rekommenderade konfigurationen för en MongoDB-produktionsdistribution kommer att vara minst tre shard-servrar med varsin replikuppsättning. För bästa prestanda distribueras Mongos-servrarna på separata servrar medan konfigurationsnoderna är integrerade med skärvorna.

Distribuera MongoDB Shards med Ansible

Att konfigurera skärvor och replikuppsättningar av ett kluster separat är ett besvärligt åtagande, så vi löser oss i enkla verktyg som Ansible för att uppnå de önskade resultaten med stor lätthet. Playbooks används för att skriva de nödvändiga konfigurationerna och uppgifterna som Ansible-programvaran kommer att utföra.

Den systematiska handboksprocessen bör vara:

  1. Installera mongo-baspaket (ingen server, pymongo och kommandoradsgränssnitt)
  2. Installera mongodb-servern. Följ den här guiden för att komma igång.
  3. Sätt upp mongod-instanser och motsvarande replikuppsättningar.
  4. Konfigurera och konfigurera konfigurationsservrarna
  5. Konfigurera och konfigurera Mongos routingtjänst.
  6. Lägg till skärvorna i ditt kluster.

Spelboken på översta nivån ska se ut så här

- name: install mongo base packages include: mongod.yml
  tags: - mongod

- name: configure config server
  include: configServer.yml
  when: inventory_hostname in groups['mongoc-servers'] 
  tags:
  - cs

- name: configure mongos server
  include: configMongos.yml
  when: inventory_hostname in groups['mongos-server'] tags:
  - mongos

- name: add shards
  include: addShards.yml
  when: inventory_hostname in groups['mongos-servers'] 
  tags:
  - mongos
  - shards

Vi kan spara filen ovan som mongodbCluster.yml.

Severalnines Become a MongoDB DBA - Bringing MongoDB to ProductionLäs om vad du behöver veta för att distribuera, övervaka, hantera och skala MongoDBDownload gratis

En enkel mongodb.yml-fil kommer att se ut så här:

---
- hosts: ansible-test
  remote_user: root
  become: yes
  tasks:
  - name: Import the public key used by the package management system
    apt_key: keyserver=hkp://keyserver.ubuntu.com:80 id=7F0CEB10 state=present
  - name: Add MongoDB repository
    apt_repository: repo='deb <a class="vglnk" href="https://downloads-distro.mongodb.org/repo/ubuntu-upstart" rel="nofollow"><span>http</span><span>://</span><span>downloads</span><span>-</span><span>distro</span><span>.</span><span>mongodb</span><span>.</span><span>org</span><span>/</span><span>repo</span><span>/</span><span>ubuntu</span><span>-</span><span>upstart</span></a> dist 10gen' state=present
  - name: install mongodb
    apt: pkg=mongodb-org state=latest update_cache=yes
    notify:
    - start mongodb
  handlers:
    - name: start mongodb
      service: name=mongod state=started

Till de allmänna parametrarna som krävs vid distributionen av en replikuppsättning behöver vi dessa två till för att lägga till skärvorna.

  • shard: som standard är den null. Detta är en shard-anslutningssträng som ska vara i formatet /host:port. Till exempel replica0/siteurl1.com:27017
  • uppge: som standard är värdet närvarande vilket anger att skärpan ska finnas, annars kan man ställa in den så att den saknas.

Efter att ha distribuerat en replikuppsättning enligt beskrivningen i den här bloggen kan du fortsätta att lägga till skärvorna.

# add a replicaset shard named replica0 with a member running on port 27017 on mongodb0.example.net
- mongodb_shard:
    login_user: admin
    login_password: root
    shard: "replica0/mongodb1.example.net:27017"
    state: present

# add a standalone mongod shard running on port 27018 of mongodb2.example.net
- mongodb_shard:
    login_user: admin
    login_password: root
    shard: "mongodb2.example.net:27018"
    state: present

# Single node shard running on localhost
- name: Ensure shard replica0 exists
  mongodb_shard:
    login_user: admin
    login_password: root
    shard: "replica0/localhost:3001"
    state: present

# Single node shard running on localhost
- name: Ensure shard replica0 exists
  mongodb_shard:
    login_user: admin
    login_password: root
    shard: "replica0/localhost:3002"
    state: present

Efter att ha ställt in alla dessa konfigurationer kör vi spelboken med kommandot

ansible-playbook -i hosts mongodbCluster.yml

När spelboken är klar kan vi logga in på någon av mongos servrar och utfärda kommandot sh.status(). Om utgången är något liknande nedan, har skärvorna distribuerats. Dessutom kan du se nyckeln mongodb_shard om den har uppskattats till framgång.

mongos> sh.status()
    --- Sharding Status --- 
      sharding version: { "_id" : 1, "version" : 3 }
      shards:
        {  "_id" : "shardA",  "host" : "locahhost1/web2:2017,locahhost3:2017" }
        {  "_id" : "shardB",  "host" : "locahhost3/web2:2018,locahhost3:2019" }
{  "_id" : "shardC",  "host" : "locahhost3/web2:2019,locahhost3:2019" }

    databases:
        {  "_id" : "admin",  "partitioned" : false,  "primary" : "config" }

För att ta bort en skärva som heter replica0

- mongodb_shard:
    login_user: admin
    login_password: root
    shard: replica0
    state: absent

Slutsats

Ansible har spelat en stor roll för att göra implementeringsprocessen enkel eftersom vi bara behöver definiera de uppgifter som behöver utföras. Föreställ dig till exempel om du hade 40 replika-uppsättningsmedlemmar och du behöver lägga till skärvor till varje. Att gå den normala vägen kommer att ta dig åldrar och är benägen att göra många mänskliga fel. Med ansible definierar du bara dessa uppgifter i en enkel fil som heter playbook och ansible tar hand om uppgifterna när filen körs.


  1. 9 ClusterControl-funktioner som du inte hittar i andra databashanteringsverktyg

  2. MongoDB Upsert förklaras

  3. Skapa en webbsida för matbutiker online med Angular, NodeJS, Express och MongoDB

  4. Kan redis-nyckelutrymmesaviseringar skjutas till redis-strömmen istället för pub-/underkanal