sql >> Database >  >> NoSQL >> MongoDB

MongoDB-replicasets in de cloud onderhouden met Ansible

Replicatie wordt op grote schaal toegepast in databasesystemen om een ​​hoge beschikbaarheid van gegevens te garanderen door redundantie te creëren. Het is in feite een strategie om een ​​kopie te maken van dezelfde gegevens op verschillende actieve servers die zich op verschillende machines kunnen bevinden, zodat, in het geval dat de hoofdserver uitvalt, een andere kan worden ingeschakeld om door te gaan met het serveren.

Een replicaset is een groep MongoDB-instanties die dezelfde set gegevens onderhouden. Ze vormen de basis van productie-implementaties. Replicatie is voordelig door het feit dat gegevens altijd beschikbaar zijn vanaf een andere server voor het geval het hoofdserversysteem uitvalt. Bovendien verbetert het de leesdoorvoer doordat een client een leesverzoek naar verschillende servers kan sturen en antwoord krijgt van de dichtstbijzijnde.

Een replicaset bestaat uit verschillende gegevensdragende knooppunten die op verschillende machines en een arbiterknooppunt kunnen worden gehost. Een van deze gegevensdragende knooppunten wordt aangeduid als de primaire, terwijl de andere secundaire knooppunten zijn. Het primaire knooppunt ontvangt alle schrijfbewerkingen en repliceert vervolgens de gegevens naar de andere knooppunten nadat de schrijfbewerking is voltooid en de wijzigingen zijn vastgelegd in een oplog.

Een arbiter is een extra instantie die geen dataset onderhoudt, maar een quorum in een replicaset biedt door te reageren op hartslag- en verkiezingsverzoeken van andere replicasetleden. Ze verlagen dus de kosten van het onderhouden van een replicaset in plaats van een volledig functionele replicasetlid met een dataset.

Automatische failover

Een primair knooppunt kan om een ​​aantal redenen uitvallen, zoals stroomuitval of netwerkverbinding, waardoor het niet in staat is om met de andere leden te communiceren. Als de communicatie wordt onderbroken voor meer dan de geconfigureerde verkiezingTimeoutMillis-periode, roept een van de secundairen op tot een verkiezing om zichzelf te nomineren als de nieuwe primaire. Als de verkiezing is voltooid en succesvol is, gaat het cluster verder met de normale bewerking. Gedurende deze periode kunnen er geen schrijfbewerkingen worden uitgevoerd. De leesquery's kunnen echter zo worden geconfigureerd dat ze normaal werken op de secundairen terwijl de primaire offline is.

Voor een optimaal replicatieproces moet de mediane tijd voordat het cluster een nieuwe primaire kiest, maximaal 12 seconden zijn met standaard replicatieconfiguratie-instellingen. Dit kan worden beïnvloed door factoren zoals netwerklatentie die de tijd kan verlengen, daarom moet men rekening houden met de architectuur van het cluster om ervoor te zorgen dat deze tijd niet te hoog wordt ingesteld.

De waarde voor electieTimeoutMillis kan worden verlaagd van de standaard 10000 (10 seconden), dus de primaire kan als eerste worden gedetecteerd tijdens zeer snel. Dit kan echter de verkiezingen vaak oproepen voor zelfs kleine factoren, zoals tijdelijke netwerklatentie, ook al is het primaire knooppunt in orde. Dit zal leiden tot problemen zoals het terugdraaien van schrijfbewerkingen.

Ansible voor replicasets

Zoals vermeld, kan een replicaset leden van verschillende hostmachines hebben, waardoor het complexer wordt om het cluster te onderhouden. We hebben één platform nodig van waaruit deze replicaset gemakkelijk kan worden onderhouden. Ansible is een van de tools die een beter overzicht geeft voor het configureren en beheren van een replicaset. Als ansible nieuw voor je is, neem dan een korte samenvatting van dit artikel om de basisprincipes te begrijpen, zoals het maken van een playbook.

Configuratieparameters

  • arbiter_at_index: dit definieert de positie van de arbiter in de lijst met leden van de replicaset. Een arbiter onthoudt geen gegevens zoals de andere leden en kan niet worden gebruikt als het primaire knooppunt. Het is alleen beschikbaar om een ​​quorum te creëren tijdens de verkiezing. Als je bijvoorbeeld een even aantal leden hebt, is het goed om een ​​arbiter toe te voegen zodat als de stemmen gelijk zijn, deze een 1 toevoegt om een ​​winnend lid te maken. De toe te wijzen waarde moet een geheel getal zijn.
  • chaining_allowed: Dit neemt een booleaanse waarde en definieert of de andere secundaire leden moeten repliceren van de andere secundaire leden als chaining _allowed =true. Anders, als chaining _allowed =false, kunnen de andere secundaire leden alleen repliceren vanuit de primaire. De standaardwaarde is waar.
  • election_timeout_secs: standaard is de waarde 10000 (hiervoor is een geheel getal nodig). Het is de tijd in milliseconden om te detecteren wanneer het primaire knooppunt niet bereikbaar is of liever niet communiceert met de andere leden, waardoor een verkiezing wordt geactiveerd. Stel dit in op een mediaanwaarde van 12 seconden. Als deze te hoog is ingesteld, duurt het lang voordat de primaire fout wordt gedetecteerd en dus langer om een ​​verkiezing te doen. Aangezien dit van invloed is op de schrijfbewerking, kunt u in die periode veel gegevens kwijtraken. Aan de andere kant, als het te laag wordt ingesteld, zal er vaak een verkiezing worden gestart, zelfs als de zaak niet zo ernstig is en de primaire nog steeds bereikbaar is. Als gevolg hiervan zul je zoveel terugdraaiingen hebben voor schrijfbewerkingen die op een gegeven moment kunnen leiden tot slechte gegevensintegriteit of inconsistentie.
  • heartbeat_timeout_secs: Replica-sets moeten vóór een verkiezing met elkaar communiceren door een signaal te verzenden dat een hartslag wordt genoemd. De leden moeten dan binnen een bepaalde periode op deze signalering reageren die standaard op 10 seconden is ingesteld. Heartbeat_timeout_secs is het aantal seconden dat leden van de replicaset wachten op een succesvolle hartslag van elkaar en als een lid niet reageert, wordt het gemarkeerd als ontoegankelijk. Dit is echter alleen van toepassing op protocolversie 0. De waarde hiervoor is daarom een ​​geheel getal.
  • login_host: Dit is de host die de login-database huisvest. Standaard voor MongoDB is localhost.
  • login_database: de standaard is de beheerder en hier worden inloggegevens opgeslagen. (neemt een tekenreekswaarde)
  • login_user: de gebruikersnaam waarmee de authenticatie moet worden gedaan.(neemt een stringwaarde)
  • login_password: het wachtwoord om de gebruiker te authenticeren. (neemt een tekenreekswaarde aan)
  • login_port: Dit is de MongoDB-poort waarop de host kan inloggen. (neemt een geheel getal)
  • leden: definieert een lijst met leden van de replicaset. Het is een string gescheiden door komma's of een yaml-lijst, bijv. mongodb0:27017,mongodb2:27018,mongodb3:27019... Als er geen poortnummer is, wordt aangenomen dat de 27017 is.
  • protocol_version: neemt een geheel getal dat de versie van het replicatieproces definieert. Ofwel 0 of 1
  • replica_set: dit is een tekenreekswaarde die de naam van de replicaset definieert.
  • ssl: booleaanse waarde die bepaalt of een SSL-verbinding moet worden gebruikt bij het verbinden met de database of niet.
  • ssl_certs_reqs: dit geeft aan of een certificaat vereist is vanaf de andere kant van de verbinding en of het moet worden gevalideerd indien verstrekt. De keuzes hiervoor zijn CERT_NONE, CERT_OPTIONAL en CERT_REQUIRED. De standaardwaarde is CERT_REQUIRED.
  • valideren: neemt een booleaanse waarde die bepaalt of er een basisvalidatie moet worden uitgevoerd op de opgegeven replicasetconfiguratie. De standaardwaarde is waar.

Een MongoDB-replicaset maken met Ansible

Hier is een eenvoudig voorbeeld van taken voor het instellen van een replicaset in ansible. Laten we dit bestand taken.yaml noemen

# Create a replicaset called 'replica0' with the 3 provided members
- name: Ensure replicaset replica0 exists
  mongodb_replicaset:
    login_host: localhost
    login_user: admin
    login_password: root
    replica_set: replica0
    arbiter_at_index:2
    election_timeout_secs:12000
    members:
    - mongodb1:27017
    - mongodb2:27018
    - mongodb3:27019
  when: groups.mongod.index(inventory_hostname) == 0

# Create two single-node replicasets on the localhost for testing
- name: Ensure replicaset replica0 exists
  mongodb_replicaset:
    login_host: localhost
    login_port: 3001
    login_user: admin
    login_password: root
    login_database: admin
    replica_set: replica0
    members: localhost:3000
    validate: yes

- name: Ensure replicaset replica1 exists
  mongodb_replicaset:
    login_host: localhost
    login_port: 3002
    login_user: admin
    login_password: secret
    login_database: root
    replica_set: replica1
    members: localhost:3001
    validate: yes

In ons playbook kunnen we de taken noemen zoals

---
- hosts: ansible-test
  remote_user: root
  become: yes
  Tasks:
- include: tasks.yml

Als je dit uitvoert in je playbook, ansible-playbook -i inventory.txt -c ssh mongodbcreateReplcaSet.yaml, krijg je een reactie te zien of de replicaset is gemaakt of niet. Als de sleutel mongodb_replicaset wordt geretourneerd met een waarde van succes en een beschrijving van de replicaset die is gemaakt, bent u klaar om te gaan.

Conclusie

In MongoDB is het over het algemeen vervelend om een ​​replicaset te configureren voor de mongod-instanties die door verschillende machines kunnen worden gehost. Ansible biedt echter een eenvoudig platform om hetzelfde te doen door slechts een paar parameters te definiëren, zoals hierboven besproken. Replicatie is een van de processen die zorgt voor een continue werking van de applicatie en moet daarom goed worden geconfigureerd door een meervoudig aantal leden in de productiewereld in te stellen. Een arbiter wordt gebruikt om een ​​quorum te creëren tijdens het verkiezingsproces en moet daarom worden opgenomen in het configuratiebestand door zijn positie te definiëren.


  1. Hoe een gebruiker in mongodb te maken met docker-compose

  2. Is er een insluitbaar Java-alternatief voor Redis?

  3. Een item bijwerken in een array dat zich in een array bevindt

  4. Inleiding tot gedistribueerde cache in Hadoop