MongoDB
 sql >> Datenbank >  >> NoSQL >> MongoDB

Selbst gehostete MongoDB

Sie hosten Ihre MongoDB wahrscheinlich bei einem zuverlässigen Cloud-Service-Anbieter, wie zum Beispiel Atlas, weil Sie sich wirklich auf Ihre Idee konzentrieren und alle subtilen Schlüsselverwaltungsbereiche wie Netzwerk, Speicherung, Zugriff usw. delegieren möchten.

Am Anfang sieht alles gut aus, bis aus Ihrer kleinen Idee ein Geschäft wird und die Kosten in die Höhe schnellen. Auch wenn dies nicht der Fall ist, gibt Ihnen dieser Beitrag dennoch einen allgemeinen Überblick über die damit verbundene technische Komplexität (und das gesparte Geld!), wenn Sie zu einer selbst gehosteten Lösung migrieren würden.

Übrigens, von wie viel Ersparnis reden wir? Lassen Sie uns einen schnellen Vergleich zwischen einem Atlas durchführen -Instanz und eine selbst gehostete MongoDB auf AWS .

Atlas (~166 $/Monat)

0,23 $/Stunde basierend auf den oben ausgewählten Anforderungen (~ cloud.mongodb.com)



AWS (~$36/Monat)

0,0416 $/Stunde für die Instanz und zusätzliche Preise basierend auf dem EBS-Typ und Speicher (~calculator.aws)

Es ist fast eine 4,5-fache Ersparnis allein in Bezug auf die Infrastruktur!

Jetzt, da Sie die wichtigsten Gründe kennen und diesen Beitrag immer noch lesen, lassen Sie uns ohne weiteres in die Technik eintauchen.

Gliederung

  1. Einrichten der Infrastruktur
  2. Einrichten von MongoDB
  3. Massenmigration
  4. Delta-Sync zur Überbrückung der Verbindungswechsellatenz (gilt nicht für veraltete Cluster)

Da der gesamte Inhalt an einer Stelle etwas anstrengend sein kann, werde ich dies in 2 verwandte Beiträge aufteilen.

1. Einrichten der Infrastruktur

Ich werde unten die Anleitung zum Einrichten einer Instanz erwähnen, auf der RedHat Enterprise Linux 8 ausgeführt wird auf AWS. Dies liegt daran, dass MongoDB im Allgemeinen mit dem xfs-Dateisystem besser abschneidet. Hier ist ein Artikel, um es besser zu verstehen.

Hochfahren einer EC2-Instanz

Ich habe ein t3.small verwendet Instanz mit 2 vCPUs und 2 GB RAM Sie können jedoch eine beliebige Instanz Ihrer Wahl auswählen.

Es wird empfohlen, dass Ihre Datenbank Zugriff auf mindestens 1 GB RAM haben sollte und 2 echte Kerne da sich dies direkt auf die Leistung während der Caching- und Parallelitätsmechanismen auswirkt, wie sie von der Standard-Engine WiredTiger gehandhabt werden . Weitere Informationen zu den Produktionshinweisen zu den RAM- und CPU-Anforderungen finden Sie hier .

Konfigurationsübersicht:

  • Betriebssystem:Redhat Enterprise Linux 8 (x64 Intel-basiert)
  • Instanztyp:t3.small
  • Speicher:10 GB (os) + 30 GB (Daten) + 3 GB (Protokolle) von EBS d.h. 3 separate Bände

Ich gehe davon aus, dass Sie mit dem Erstellen einer VM auf AWS vertraut sind.

Weisen Sie nun, sobald die Instanz ausgeführt wird, eine Elastic IP zu dazu und führen Sie dann einfach eine Remote-Anmeldung bei der Maschine durch.

Wir benötigen die Elastic IP um einen öffentlichen Hostnamen für die Instanz einzurichten

$ ssh -i <PEM_FILE> ec2-user@<ELASTIC_IP>

Lade zusätzliche Volumes ein

Wir haben 2 zusätzliche EBS-Volumes außer dem Root FS für Daten und Protokolle hinzugefügt, die noch gemountet werden müssen (Erinnern Sie sich an die 30 GB und 3 GB? ). Sie können die Volume-Blöcke mit ,

auflisten
$ sudo lsblk

Die zusätzlichen Volumes werden direkt nach dem Root-Block aufgelistet (siehe Pfeile)

In der Abbildung oben sehen Sie, dass die zusätzlichen Volumes benannt sind

  1. xvdb (30 GB Speicherplatz zum Speichern von Daten)
  2. xvdc (3 GB Speicherplatz zum Speichern von Protokollen)

Lassen Sie uns nun die Dateisysteme in diesen Volumes erstellen.

$ sudo mkfs.xfs -L mongodata /dev/xvdb
$ sudo mkfs.xfs -L mongologs /dev/xvdc

-L ist eine Alias-Option zum Festlegen der Volumenbezeichnung

Und mounten Sie dann die Volumes.

$ sudo mount -t xfs /dev/xvdb /var/lib/mongo
$ sudo mount -t xfs /dev/xvdc /var/log/mongodb

Damit diese Änderungen übernommen werden, muss das System neu gestartet werden. Daher brauchen wir jetzt auch die Partitionspersistenz, damit wir im Falle eines unbeabsichtigten Neustarts den Datenbankspeicher nicht verlieren.

Wir können dies erreichen, indem wir die Mount-Regeln in der fstab-Datei angeben. Hier können Sie mehr darüber lesen.

Kopieren wir vorher die UUID der obigen Partitionen (weil sie einzigartig sind und sich bei einem Systemneustart nicht ändern )

$ sudo blkid

Kopieren Sie die für /dev/xvdb aufgelisteten UUIDs und /dev/xvdc . Siehe "LABEL" zur Blockidentifikation

Öffnen Sie nun die /etc/fstab Datei und fügen Sie die Konfiguration im folgenden Format ein.

UUID=<COPIED_UUID_FOR_DATA> /var/lib/mongo xfs defaults,nofail 0 0
UUID=<COPIED_UUID_FOR_LOGS> /var/log/mongodb xfs defaults,nofail 0 0

Hostnamen aktualisieren

Der Hostname wird verwendet, um Ihren Datenbankserver im Netzwerk zu identifizieren. Sie können entweder die oben zugewiesene Elastic IP verwenden oder Domänenname (falls verfügbar). Öffnen Sie /etc/hostname Datei und fügen Sie den Eintrag hinzu. Zum Beispiel

ip-xx.us-east-2.compute.internal **<ELASTIC_IP> <DOMAIN_1> <DOMAIN_2>** ...

Aktualisieren Sie die Prozesslimits (optional)

Dies ist optional erforderlich, um die maximale Anzahl akzeptabler Verbindungen zu kontrollieren und gleichzeitig das System stabil zu halten. Öffnen Sie die /etc/security/limits.conf Datei und fügen Sie die folgenden Einträge hinzu.

* soft nofile 64000
* hard nofile 64000
* soft nproc 32000
* hard nproc 32000

Jetzt, da alle Infrastrukturvoraussetzungen sortiert sind, reboot die Instanz und fahren Sie mit der Installation von MongoDB fort.

1. MongoDB einrichten

Fügen Sie die Repo-Quelle hinzu

Erstellen Sie eine Datei /etc/yum.repos.d/mongodb-org.4.2.repo und fügen Sie die folgenden Paket-Repository-Details hinzu.

[mongodb-org-4.2]
name=MongoDB Repository
baseurl=https://repo.mongodb.org/yum/redhat/$releasever/mongodb-org/4.2/x86_64/
gpgcheck=1
enabled=1
gpgkey=https://www.mongodb.org/static/pgp/server-4.2.asc

Lassen Sie uns nun MongoDB installieren.

$ sudo yum -y install mongodb-org

Verzeichnisse erstellen und Berechtigungen einrichten

MongoDB verwendet standardmäßig die folgenden Pfade zum Speichern der Daten und der internen Protokolle:

/var/lib/mongo → Daten
/var/log/mongodb → Protokolle

Erstellen Sie die Verzeichnisse

$ sudo mkdir /var/lib/mongo
$ sudo mkdir /var/log/mongodb

Benutzer- und Gruppenberechtigungen ändern

$ sudo chown mongod:mongod /var/lib/mongo
$ sudo chown mongod:mongod /var/log/mongod

Erstellen Sie einen Admin-Benutzer

Der mongod-Daemon/-Dienst muss zuerst ausgeführt werden, bevor wir mit der Erstellung eines Benutzers fortfahren. Verwenden wir die Standardkonfiguration (gespeichert in /etc/mongod.conf). ) und starten Sie den Daemon-Prozess.

$ sudo -u mongod mongod -f /etc/mongod.conf

Der obige Befehl startet den Mongod-Daemon im Fork-Modus (Standard).

Melden wir uns jetzt beim Server an und erstellen unseren ersten Admin-Benutzer.

Öffne eine Mongo-Muschel

$ mongo

Verwenden Sie die "admin"-Datenbank, um den Root-Admin zu erstellen

> use admin

Erstellen Sie den Admin-Benutzer

> db.createUser({user: "admin", pwd: "password", roles: [{role: "root", db: "admin"}]})

Erstellen Sie einen regulären Benutzer

> db.createUser({user: "normal_user", pwd: "password", roles: [{role: "readWriteAnyDatabase", db: "admin"}]})

Fahren Sie den Server vorerst herunter. Wir werden mit der geänderten Konfiguration neu starten

> db.shutDownServer()

Authentifizierung einrichten

Hier aktivieren wir die Datenbankauthentifizierung und ändern die Bindungsadresse für unseren Server, damit er in der öffentlichen Domäne zugänglich ist. Öffnen Sie /etc/mongod.conf und nehmen Sie die folgenden Änderungen vor.

# network interfaces
net:
  port: 27017
  bindIp: 0.0.0.0 # accessible on the network address
security:
  authorization: enabled # creds will be required for making db operations

Speichern Sie die Konfiguration und neu starten der Server.

$ sudo -u mongod mongod -f /etc/mongod.conf

Anmeldung testen

Sie können überprüfen, ob die Anmeldeinformationen funktionieren, indem Sie,

verwenden
$ mongo -u admin -p password

Das war's mit der Ersteinrichtung! Bitte bleiben Sie dran für meinen nächsten verwandten Beitrag über den detaillierten Migrationsprozess und Tipps, wie Sie die DB produktionsbereit halten.

P.S. Vielen Dank an Piyush Kumar für die Hilfe beim Kuratieren dieses Beitrags!