Installazione e configurazione di MongoDB in Replica Set su Ubuntu 18.04

In questo articolo andremo a descrivere come realizzare un cluster in MongoDB in modalità replica su Ubuntu 18.04.

Consideriamo di creare due macchine virtuali Ubuntu 18.04 ( qui per l’installazione) ed aggiorniamole

sudo apt-get update

sudo apt-get upgrade

consideriamo di nominare le due macchine virtuali come mongoserver1 e mongoserver2 ed aggiungiamo la mappattura sul file hosts

vim /etc/hosts

ip_server1   mongoserver1

ip_server2  mongoserver2

ed installiamo su entrambi i nodi MongoDB, iniziamo con mongoserver1

sudo apt-get install mongodb

ed impostiamo il demone all’ avvio automatico

sudo systemctl enable mongodb

A questo punto iniziamo la configurazione del primo nodo mongoserver1 che diventerà il primario, creiamo una regola sul firewall per abilitare la comunicazione tra un nodo e l’altro

sudo ufw allow 27017

e modifichiamo il file di configurazione di MongoDB

vim /etc/mongodb.conf

impostando i seguenti paramentri

bind_ip = ip_server1

port = 27017

replSet = myreplica

a questo punto riavviamo il demone di MongoDB

sudo systemctl restart mongodb

e verifichiamo che lo stato sia ok

sudo systemctl status mongodb

● mongodb.service – An object/document-oriented database
Loaded: loaded (/lib/systemd/system/mongodb.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2019-06-25 11:41:57 CEST; 3h 7min ago
Docs: man:mongod(1)
Main PID: 1986 (mongod)
Tasks: 74 (limit: 1128)
CGroup: /system.slice/mongodb.service
└─1986 /usr/bin/mongod –unixSocketPrefix=/run/mongodb –config /etc/mongodb.conf

giu 25 11:41:57 mongoserver1 systemd[1]: Started An object/document-oriented database.

adesso eseguiamo le medesime operazioni sul secondo nodo mongoserver2, a partire dall’installazione di MongoDB la differenza sarà la configurazione

vim /etc/mongodb.conf

bind_ip = ip_server2

port = 27017

replSet = myreplica

Ritornando sul primo nodo, mongoserver1 ed inizializziamo il cluster

mongo ip_server1

avremo

MongoDB shell version v3.6.3
connecting to: mongodb://ip_server1:27017/test
MongoDB server version: 3.6.3
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:
2019-06-25T11:05:49.708+0200 I STORAGE [initandlisten]
2019-06-25T11:05:49.708+0200 I STORAGE [initandlisten] ** WARNING: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine
2019-06-25T11:05:49.708+0200 I STORAGE [initandlisten] ** See http://dochub.mongodb.org/core/prodnotes-filesystem
2019-06-25T11:05:50.688+0200 I CONTROL [initandlisten]
2019-06-25T11:05:50.688+0200 I CONTROL [initandlisten] ** WARNING: Access control is not enabled for the database.
2019-06-25T11:05:50.688+0200 I CONTROL [initandlisten] ** Read and write access to data and configuration is unrestricted.
2019-06-25T11:05:50.688+0200 I CONTROL [initandlisten]

quando viene restituito il prompt

>rs.initiate()

{
“info2” : “no configuration specified. Using a default configuration for the set”,
“me” : “ip_server1:27017”,
“ok” : 1,
“operationTime” : Timestamp(1561454427, 1),
“$clusterTime” : {
“clusterTime” : Timestamp(1561454427, 1),
“signature” : {
“hash” : BinData(0,”AAAAAAAAAAAAAAAAAAAAAAAAAAA=”),
“keyId” : NumberLong(0)
}
}
}

il campo evidenziato indica la creazione della replica set, successivamente aggiungiamo il secondo nodo considerando che il MongoDB sia attivo

myreplica:PRIMARY> rs.add("mongoserver2")

avremo

{
“ok” : 1,
“operationTime” : Timestamp(1561455852, 1),
“$clusterTime” : {
“clusterTime” : Timestamp(1561455852, 1),
“signature” : {
“hash” : BinData(0,”AAAAAAAAAAAAAAAAAAAAAAAAAAA=”),
“keyId” : NumberLong(0)
}
}
}

verifichiamo lo stato del cluster

myreplica:PRIMARY> rs.status()

{
“set” : “myreplica”,
“date” : ISODate(“2019-06-25T09:48:30.617Z”),
“myState” : 1,
“term” : NumberLong(2),
“heartbeatIntervalMillis” : NumberLong(2000),
“optimes” : {
“lastCommittedOpTime” : {
“ts” : Timestamp(1561456109, 1),
“t” : NumberLong(2)
},
“readConcernMajorityOpTime” : {
“ts” : Timestamp(1561456109, 1),
“t” : NumberLong(2)
},
“appliedOpTime” : {
“ts” : Timestamp(1561456109, 1),
“t” : NumberLong(2)
},
“durableOpTime” : {
“ts” : Timestamp(1561456109, 1),
“t” : NumberLong(2)
}
},
“members” : [
{
“_id” : 0,
“name” : “ip_server1:27017”,
“health” : 1,
“state” : 1,
“stateStr” : “PRIMARY”,
“uptime” : 393,
“optime” : {
“ts” : Timestamp(1561456109, 1),
“t” : NumberLong(2)
},
“optimeDate” : ISODate(“2019-06-25T09:48:29Z”),
“electionTime” : Timestamp(1561455718, 1),
“electionDate” : ISODate(“2019-06-25T09:41:58Z”),
“configVersion” : 2,
“self” : true
},
{
“_id” : 1,
name” : “mongoserver2:27017”,
“health” : 1,
“state” : 2,
stateStr” : “SECONDARY”,
“uptime” : 258,
“optime” : {
“ts” : Timestamp(1561456099, 1),
“t” : NumberLong(2)
},
“optimeDurable” : {
“ts” : Timestamp(1561456099, 1),
“t” : NumberLong(2)
},
“optimeDate” : ISODate(“2019-06-25T09:48:19Z”),
“optimeDurableDate” : ISODate(“2019-06-25T09:48:19Z”),
“lastHeartbeat” : ISODate(“2019-06-25T09:48:28.620Z”),
“lastHeartbeatRecv” : ISODate(“2019-06-25T09:48:29.763Z”),
“pingMs” : NumberLong(0),
“syncingTo” : “ip_server1:27017”,
“configVersion” : 2
}
],
“ok” : 1,
“operationTime” : Timestamp(1561456109, 1),
“$clusterTime” : {
“clusterTime” : Timestamp(1561456109, 1),
“signature” : {
“hash” : BinData(0,”AAAAAAAAAAAAAAAAAAAAAAAAAAA=”),
“keyId” : NumberLong(0)
}
}
}

configurazione finita del cluster. Adesso verifichiamo il tutto con un database di esempio, in particolare aggiungendo una collezione

myreplica:PRIMARY> use test

switched to db test

myreplica:PRIMARY> db.users.save( {username:"test1"} )

WriteResult({ “nInserted” : 1 })

verifichiamo se sul secondo nodo è presente il database test

mongo ip_server2

MongoDB shell version v3.6.3
connecting to: mongodb://ip_server2:27017/test
MongoDB server version: 3.6.3
Server has startup warnings:
2019-06-25T11:42:01.351+0200 I STORAGE [initandlisten]
2019-06-25T11:42:01.351+0200 I STORAGE [initandlisten] ** WARNING: Using the XFS filesystem is strongly recommended
2019-06-25T11:42:01.351+0200 I STORAGE [initandlisten] ** See http://dochub.mongodb.org/core/prodnotes-file
2019-06-25T11:42:02.486+0200 I CONTROL [initandlisten]
2019-06-25T11:42:02.486+0200 I CONTROL [initandlisten] ** WARNING: Access control is not enabled for the database.
2019-06-25T11:42:02.486+0200 I CONTROL [initandlisten] ** Read and write access to data and configuration i
2019-06-25T11:42:02.486+0200 I CONTROL [initandlisten]

myreplica:SECONDARY> show dbs

admin 0.000GB
config 0.000GB
local 0.000GB
test 0.000GB

myreplica:SECONDARY> use test

switched to db test

myreplica:SECONDARY> db.users.find( {username:"test1"} )

{ “_id” : ObjectId(“5d11efc570907dfe9b0b8935”), “username” : “test1” }

In generale, quando si realizza un cluster su MongoDB conviene utilizzare 3 di nodi, in quando un nodo fa da Arbitro per poter elevare un nodo secondario a primario nel caso di crash di un nodo primario iniziale. Per avere maggiori informazioni sulla replica di MongoDB è necessario utilizzare la documentazione ufficiale al seguente link.

 

Potrebbero interessarti anche...