Implementați un set de replici cu disponibilitate ridicată în MongoDB 3.4 Utilizând fișierul cheie pentru controlul accesului pe Ubuntu 16.04

• Despre setul de replici
• Cerințe preliminare
• Proiectați setul Replica
• Instrucțiuni de implementare
• Concluzie

De la concepția sa în 2009, MongoDB a condus industria NoSQL. Unul dintre conceptele de bază ale MongoDB este Replica Set, așa că, înainte de a lucra cu acesta, permite mai întâi revizuirea conceptului.

Despre setul de replici

Cel mai simplu model de comunicare utilizat în replicarea bazelor de date este arhitectura Master-Slave. După cum sugerează numele său, acest model are 2 roluri care sunt răspândite într-un maestru unic și mulți sclavi, rolul maestrului este să proceseze operațiunile de citire și scriere efectuate de clienți, iar sclavii sunt tratați ca o replică a maestrului.

Cel mai important avantaj al acestui model este că performanța masterului nu este compromisă de operațiunile de rezervă, operațiunile de backup se realizează într-un mod asincron și acest lucru poate deveni o problemă gravă atunci când un nod master eșuează. Nodurile slave sunt numai citite și trebuie promovate manual la nodul principal, astfel încât în ​​acest timp există posibilitatea pierderii de date.

O opțiune pentru soluționarea problemei de disponibilitate este de a avea mai mult de un master în arhitectură, dar acest lucru poate duce la o altă problemă în consistența datelor dintre aceste instanțe și complexitatea adăugată a configurației.

Contextul dat, putem prezenta tehnologia Replica Set a MongoDB. Replica Set este numele arhitecturii Master-Slave care are reactivare automată, deci în momentul în care un master (care este numit acum primary) nu funcționează corect, se electionva declanșa și un nou nod primar va fi ales dintre sclavii rămași ( denumit acum secondaries).

Nodul primar

Nodul primar este singurul care efectuează operațiuni de scriere, în mod implicit operațiunile de citire sunt gestionate și de primar, dar acest comportament poate fi modificat ulterior.

Operațiunile sunt înregistrate în oplog(jurnalul de operații), apoi nodurile secundare își actualizează conținutul asincron pe baza conținutuluioplog

Notă: oplogeste o colecție plafonată, asta înseamnă că colecția are o limită, cu ajutorul căreia local.oplog.rsputeți verifica conținutul acestei colecții în interiorul unei cochilii de mongo în orice membru setat.

Nod secundar

Pe lângă faptul că sunt cei care fac o copie de rezervă corectă a bazei de date, un nod secundar are aceste roluri:

• Poate accepta operațiunile de citire dacă este nevoie.
• Poate declanșa o alegere dacă un nod primar eșuează.
• Poate vota la alegeri.
• Poate deveni noul element primar, dacă este nevoie.

Datorită acestor caracteristici putem avea diferite tipuri de noduri secundare:

• Prioritate 0 : Aceste noduri nu pot deveni primaryși nu pot declanșa alegeri, totuși pot vota la alegeri, au o replică completă și pot accepta operațiuni de citire. Acestea pot fi utile în implementarea mai multor centre de date.
• Ascuns : sunt Priority 0membri, dar nu pot prelucra operațiunile de citire. Aceștia pot vota dacă este necesar. Sarcinile preferate pentru acești membri sunt raportarea și backup-urile.
• Întârziați : Aceste noduri sunt responsabile de „date istorice”, întârziate cu o unitate în timp. Un membru cu întârziere trebuie să fie un priority 0nod și este recomandat să fie și el hiddenmembru.

Cerințe preliminare

• Disponibilitatea de a rula cel puțin 3 instanțe Ubuntu 16.04 x64 cu aceeași dimensiune a serverului.

Proiectați setul Replica

Înainte de a implementa o infrastructură, este important să o proiectăm și există puncte de luat în considerare în acest proiect.

Alegerea numărului de membri

Rețineți că numărul minim de elemente pentru a construi un set de replici este 3. Puteți amesteca cele trei tipuri de noduri cu cel puțin un nod primar și unul secundar.

În acest ghid desfășurăm 3 membri, unul primar și doi secundari standard.

Notă: Se recomandă să existe un număr maxim de 7 membri care votează cu un mix de arbitri și membri secundari.

Alegeți un nume

Numele este doar pentru referință, dar îl utilizați în configurația setului. Rețineți că puteți avea mai multe seturi de replici în mediul de producție, deci nu neglijați numele setului.

Acest tutorial încurajează utilizatorul să selecteze numele setului.

Distribuirea membrilor în diferite centre de date

Acest tutorial sugerează implementarea pe același centru de date, astfel încât să poți evita problemele de comunicare.

Notă: În cazul implementării în diferite centre de date, se recomandă să vă înveliți nodurile cu un VPN

Instrucțiuni de implementare

Pasul 1: implementați nodurile minime pentru infrastructura dvs.

Lansați 3 noduri Ubuntu 16.04 x64; în aceeași regiune din portalul clienților dvs., dacă este posibil. Nu uitați să le numiți în consecință în funcție de tipul de proiect cu care aveți de-a face și asigurați-vă că aveți aceeași dimensiune a serverului în toate aceste noduri.

După ce ai implementat cele 3 noduri, va trebui să fii sigur că fiecare nod poate vorbi cu restul. Trebuie să ssh în două noduri și să ajungeți la celelalte folosind ping -c 4 EXAMPLE_IP. Modificați EXAMPLE_IPIP-urile reale ale nodurilor.

Aici puteți vedea un exemplu de comunicare reușită între două noduri.

root@foo_node:~# ping -c 4 EXAMPLE_IP
PING EXAMPLE_IP (EXAMPLE_IP) 56(84) bytes of data.
64 bytes from EXAMPLE_IP: icmp_seq=1 ttl=59 time=0.594 ms
64 bytes from EXAMPLE_IP: icmp_seq=2 ttl=59 time=0.640 ms
64 bytes from EXAMPLE_IP: icmp_seq=3 ttl=59 time=0.477 ms
64 bytes from EXAMPLE_IP: icmp_seq=4 ttl=59 time=0.551 ms

--- EXAMPLE_IP ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3021ms
rtt min/avg/max/mdev = 0.477/0.565/0.640/0.064 ms

Pasul 2: Instalează MongoDB în fiecare nod al infrastructurii tale

În general, puteți utiliza pachetul MongoDB de Ubuntu, dar este mai bine să folosiți repo-ul comunității oficiale, deoarece este mereu actualizat. Acest repo conține aceste pachete:

• mongodb-org , pachetul de grup care cuprinde cele patru componente.
• mongodb-org-server , acesta conține mongoddemonul (procesul primar care gestionează solicitările de date).
• mongodb-org-mongos , acesta conține mongosdemonul (serviciu de rutare pentru implementări partajate).
• mongodb-org-shell , aceasta este mongo shellinterfața JavaScript.
• mongodb-org-tools , unele instrumente pentru activități de administrare.

Continuați la instalarea pachetelor.

Importați cheia publică în sistemul de gestionare a pachetelor.

sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 0C49F3730359A14518585931BC711F9BA15703C6

Creați fișierul de listă pentru MongoDB '/etc/apt/sources.list.d/mongodb-org-3.4.list'.

echo "deb [ arch=amd64,arm64 ] http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-3.4.list

Actualizați baza de date de pachete.

sudo apt-get update

Instalați metapackage MongoDB.

sudo apt-get install -y mongodb-org

Porniți serviciul MongoDB.

sudo service mongod start

Acum puteți deschide mongo shellîn orice sesiune bash. Pentru a face acest lucru, trebuie să utilizați mongocomanda. Vei fi întâmpinat de ceva similar cu acesta.

MongoDB shell version v3.4.7
connecting to: mongodb://127.0.0.1:27017
MongoDB server version: 3.4.7
Welcome to the MongoDB shell.
For interactive help, type "help".
For more comprehensive documentation, see http://docs.mongodb.org/
Questions? Try the support group
http://groups.google.com/group/mongodb-user
Server has startup warnings:
*Some extra logs are cut by the way*
>

Nu uitați să închideți serviciul sudo service mongod stop, deoarece mai târziu vom începe mongoddin nou cu unii parametri. Repetați acest proces în toate cele 3 noduri ale setului.

Pasul 3: Configurați fișierul cheie de acces

Utilizarea unui fișier cheie forțează două concepte în administrarea setului de replici. Primul este Internal Authentication. În mod implicit, puteți începe o mongo shellsesiune fără a utiliza un utilizator, iar această sesiune va avea controlul complet asupra bazei de date, dar când utilizați un fișier cheie pentru autentificare, mongo shellsesiunea dvs. ajunge la o stare apelată localhost exception. Această stare vă permite doar să creați utilizatorul de administrator și setul de replici. Al doilea concept este Role-Based Access Control, sau cu alte cuvinte autorizarea. Acest lucru este aplicat pentru a guverna nivelurile administrative la setul de replici.

Creați fișierul dvs. cheie

Fișierul cheie este parola de utilizat în set, această parolă trebuie să fie aceeași la toți membrii setului. Pentru a crește securitatea, este important să utilizați o cheie aleatorie cu instrumentul ales.

Conținutul trebuie să aibă între 6 și 1064 de caractere. De asemenea, trebuie să setați read onlypermisiunea pentru fișierul cheie.

chmod 400 PATH_OF_YOUR_KEYFILE

Plasați fișierul cheie în fiecare membru al setului

Acum copiați fișierul cheie pe fiecare membru setat, utilizați un folder consistent pentru referințe viitoare și nu îl depozitați într-un suport amovibil.

De asemenea, utilizați un folder pentru fișierul care mongodpoate accesa.

Aplicați folosind fișierul cheie din setul de replici

În acest pas, trebuie să pornim mongod daemon în fiecare membru set . Există două moduri de a începe mongodprocesul: folosind un fișier de configurare sau folosind linia de comandă. Ambele sunt metode destul de ușoare, dar doar pentru simplitate, acest tutorial folosește versiunea liniei de comandă.

Configurația liniei de comandă

Utilizați numele pe care l-ați ales mai devreme în această comandă.

mongod --keyFile PATH_OF_YOUR_KEYFILE --replSet "YOUR_SET_NAME"

În mod implicit mongod, nu rulează ca un demon. Va trebui să utilizați --forkparametrul sau să îl folosiți upstartpentru a-l rula complet ca demon. În acest tutorial nu încurajăm rularea mongodca demon, astfel încât să puteți vedea jurnalele în terminalul dvs. direct.

Notă: Introduceți cu atenție numele setului de replici, deoarece odată creat, nu îl puteți schimba.

Pasul 4: Conectați-vă la interfața localhost de la unul dintre membrii setați

Notă: Dacă rulați mongodca un proces non-demon, atunci va trebui să deschideți o altă conexiune ssh pentru a continua să lucreze.

Trebuie să folosiți mongocomanda pentru a deschide mongo shell. Acest lucru se poate face în orice membru al setului.

În acest moment ne aflăm într-o stare numită localhost exception. Când se folosește un fișier cheie pentru configurarea mongodprocesului, sunteți obligat să creați un administrator al bazei de date înainte de a putea aplica operațiuni de citire a scrierii, dar vom intra în asta mai târziu.

Pasul 5: Inițierea setului de replici

Aceasta este o parte delicata, folosim comanda in rs.initiate()interiorul mongo shelldin Etapa 4. înainte de a utiliza această comandă recenzie Să - l.

rs.initiate(
  {
    _id : <replicaSetName>,
    members: [
      { _id : 0, host : "example1.net:27017" },
      { _id : 1, host : "example2.net:27017" },
      { _id : 2, host : "example3.net:27017" }
    ]
  }
)

Primul _idcâmp este un șir și trebuie să se potrivească cu --replSetcel trecut mongod. De asemenea, fiecare valoare hosttrebuie să fie ip sau numele de domeniu al fiecărui membru al setului Replica. Nu uitați să adăugați portul pe care îl folosește instanța mongo pentru fiecare membru.

Acum este timpul să executați comanda cu datele dvs. pe ea, acest lucru va declanșa un election, apoi un primar va fi ales automat.

Aici ar trebui să rețineți că cursorul dvs. shell s-a schimbat în YOUR_SET_NAME:PRIMARY>sau YOUR_SET_NAME:SECONDARY. Aceasta înseamnă că crearea unui set a fost un succes.

Pentru a continua munca, trebuie să găsiți primary, dacă nu sunteți pe ea, desigur. Utilizați rs.status()comanda pentru a afișa informațiile setului de replici și pentru a localiza primary. Căutați proprietatea "stateStr" : "PRIMARY".

Pasul 6: Crearea administratorului

După ce ați localizat primary, introduceți mongo shellși rulați următoarea comandă folosind datele dvs.

admin = db.getSiblingDB("admin")
admin.createUser(
  {
    user: "YOUR_USER",
    pwd: "YOU_PASSWORD",
    roles: [ { role: "userAdminAnyDatabase", db: "admin" } ]
  }
)

Partea admin = db.getSiblingDB("admin")ne permite să scriem admindintr-o altă bază de date. Aceasta creează un alias numit admin, astfel încât să putem executa comenzi folosind în schimb.

Dacă operațiunea este un succes, veți primi o notificare conform căreia utilizatorul a fost adăugat.

Successfully added user: {
    "user" : "YOUR_USER",
    "roles" : [
        {
            "role" : "userAdminAnyDatabase",
            "db" : "admin"
        }
    ]
}

În acest moment, avem doar un administrator pentru toate serverele, dar faptul că un set Replica ne obligă să avem un utilizator cu clusterAdminrolul. Vom crea un alt utilizator cu doar acest rol pentru a separa preocupările.

Pasul 7: Autentificare ca administrator

Am ajuns la limita de localhost exception, motiv pentru care trebuie să schimbăm autentificarea cu utilizatorul creat cu un pas înainte.

Puteți schimba utilizatorii din interior mongo shellcu următoarele.

db.getSiblingDB("admin").auth("YOUR_ADMIN", "YOUR_PASSWORD" )

Dacă nu te-ai conectat deja la mongo shellutilizarea acestei comenzi.

mongo -u "YOUR_ADMIN" -p "YOUR_PASSWORD" --authenticationDatabase "admin"

Vi se va anunța schimbarea unui utilizator și puteți trece la pasul următor.

Pasul 8: Crearea maestrului clusterului

clusterAdminRolul oferă utilizatorului un control complet al setului de reproduceri. Crearea acestuia este la fel de ușoară precum crearea utilizatorului de admin.

db.getSiblingDB("admin").createUser(
  {
    "user" : "YOUR_USER",
    "pwd" : "YOUR_PASSWORD",
    roles: [ { "role" : "clusterAdmin", "db" : "admin" } ]
  }
)

Rețineți că de această dată rolul este schimbat înclusterAdmin .

Pasul 9: Inserarea datelor în setul de replici

În acest moment avem 2 utilizatori admin: unul care are control total asupra serverului și altul care are acces la sarcini administrative la nivelul setului Replica. Cu toate acestea, avem un utilizator care are acces la „utilizarea” unei baze de date, deci vom crea acel utilizator acum.

admin = db.getSiblingDB("admin")
admin.createUser(
  {
    user: "YOUR_USER",
    pwd: "YOUR_PASSWORD",
    roles: [ { role: "userAdminAnyDatabase", db: "cars" } ]
  }
)

Observați că de data aceasta schimbăm dbpartea, acolo punem baza de date accesibilă utilizatorului, în acest caz folosim o bază de date numită cars.

Baza de date nu este încă creată. Pentru a face acest lucru, va trebui să tastați unele comenzi pentru a le crea implicit. Comutați la carsbaza de date.

use cars

Vei primi o notificare: switched to db cars.

Baza de date încă nu a fost creată, pentru a face acest lucru trebuie să îi scrieți ceva. Folosim următorul exemplu.

db.models.insert({ make: "Dodge", model: "Viper", year: 2010 })

De această dată veți fi anunțați WriteResult({ "nInserted" : 1 }).

Dacă doriți, puteți prelua toate obiectele din baza de date, cu find()metoda:

db.models.find()
{ "_id" : ObjectId("59acd8b55334882863541ff4"), "make" : "Dodge", "model" : "Viper", "year" : 2010 }

Rețineți că _idva fi diferit în rezultatul dvs., dar celelalte date ar trebui să fie aceleași. Având suficient timp, aceste date vor fi replicate celorlalți membri.

Concluzie

Crearea unui set de replici poate fi dificilă la început, deoarece există o mulțime de informații de înțeles, dar, odată ce obțineți ideea în spatele acesteia, o puteți implementa într-o adiere, așa că nu renunțați dacă nu o puteți înțelege în prima dată. Rețineți că setul de replici este important în administrarea MongoDB, deoarece deschide posibilitatea de a adăuga funcții avansate, cum ar fi balanța de încărcare.