centos7, mysql

НАСТРОЙКА МАСШТАБИРУЕМОЙ БАЗЫ ДАННЫХ MONGODB (Настройка репликации)

Thank you for reading this post, don't forget to subscribe!

MongoDB — это систе­ма управ­ле­ния база­ми дан­ных (СУБД) NoSQL с боль­шим коли­че­ством встро­ен­ных функ­ций, сре­ди кото­рых репли­ка­ция и сег­мен­ти­ро­ва­ние. Бла­го­да­ря этим функ­ци­ям БД мож­но мас­шта­би­ро­вать на необ­хо­ди­мое коли­че­ство сер­ве­ров путём рас­про­стра­не­ния кон­тен­та меж­ду ними.

Преж­де чем при­сту­пить к уста­нов­ке MongoDB и её зави­си­мо­стей, нуж­но убе­дить­ся, что сер­вер и уста­нов­лен­ное на нём ПО под­го­тов­ле­ны и кор­рект­но настроены.

Жесткие диски

Если у вас есть воз­мож­ность выбрать жёст­кий диск, выби­рай­те SSD кор­по­ра­тив­но­го уров­ня RAID 1, посколь­ку они эко­ном­ны и высокопроизводительны.

Отре­дак­ти­руй­те файл /etc/fstab систе­мы Linux и отклю­чи­те веде­ние жур­на­ла вре­ме­ни досту­па. Добавь­те noatime в чет­вер­тый стол­бец. Повтор­но смон­ти­руй­те раздел:

[root@mongodb1 ~]# mount -o remount /

Убе­ди­тесь, что новые настрой­ки всту­пи­ли в исполнение:

[[root@mongodb1 ~]# mount
/dev/sda on / type ext4 (rw,noatime)

Оптимизация

На дан­ном эта­пе нуж­но опти­ми­зи­ро­вать запро­сы к базе данных:

  • Добавь­те индек­сы для наи­бо­лее часто иско­мых или рас­пре­де­лен­ных запросов.
  • Исполь­зуй­те коман­ду MongoDB explain().
  • Огра­ничь­те вывод резуль­та­тов и полей поиска.

===============================

MongoDB в отли­чии от MySQL под­дер­жи­ва­ет 2 фор­мы репликации:
— реп­ли­се­ты (Replica Sets)
— веду­щий-ведо­мый (Master-Slave)

Настройка репликации базы данных по типу Master-Slave

ПРИМЕЧАНИЕ
MongoDB начи­ная с вер­сии 4.0 уби­ра­ет под­держ­ку репли­ка­ции master-slave.

Изме­ним домаш­нюю дирек­то­рию для хра­не­ния баз, для это­го созда­дим директорию:
mkdir /home/mongodb
chown mongod:mongod /home/mongodb/

Стан­дарт­ная пап­ка где хра­нят­ся базы — /var/lib/mongo и мож­но исполь­зо­вать имен­но ее.

Я в самом кон­фи­ге ниче­го не менял, оста­вил как и было.

Запуск Master 

Запус­ка­ем  Mongo демон как мастер:
# mongod --master·--dbpath /home/mongodb --bind_ip 192.168.13.161 --port 27001·--fork --logpath /var/log/mongodb/Master.log --pidfilepath /var/run/mongodb/Master.pid

Про­ве­ря­ем что все стартануло:
# ps uax | grep -E "mongod" | grep -Ev "grep"
root 51599 1.8 4.2 394848 42468 ? Sl 18:01 0:00 mongod --master --dbpath /home/mongodb --bind_ip 192.168.13.161 --port 27001 --fork --logpath /var/log/mongodb/Master.log --pidfilepath /var/run/mongodb/Master.pid
Видим, что все запу­сти­лось отлично.

Под­клю­ча­ем­ся на слейв:

# mongo --host 192.168.13.161 --port 27001
Про­ве­ря­ем ста­тус Master-а:
> rs.printReplicationInfo()
configured oplog size: 990MB
log length start to end: 0secs (0hrs)
oplog first event time: Mon Apr 17 2019 12:47:07 GMT+0300 (EEST)
oplog last event time: Mon Apr 17 2019 12:47:07 GMT+0300 (EEST)
now: Mon Apr 17 2019 19:14:07 GMT+0300 (EEST)
>
И:
> db.serverStatus()

Вот и все.

Запуск Slave 

Про­ве­ря­ем доступ­ность master-а со slave:

$ ·telnet·192.168.13.161 27001
Вид­но что име­ет­ся под­клю­че­ние. Идем далее……

Оста­нав­ли­ва­ем сер­вер с монгой:

# service mongod stop
# ps -aux | grep mongod| grep -Ev "grep"

Запус­ка­ем slave сервер:

# mongod --slave --dbpath /home/mongodb --bind_ip 192.168.13.147 --port 27001 --fork --logpath /var/log/mongodb/Slave.log --pidfilepath /var/run/mongodb/Slave.pid --source 192.168.13.161:27001
Про­ве­ря­ем что все запустилось:
# ps -aux | grep mongo | grep -Ev "grep"
Вывод:
root 4967 5.5 4.6 301064 46696 ? Sl 18:34 0:00 mongod --slave --dbpath /home/mongodb --bind_ip 192.168.13.147 --port 27001 --fork --logpath /var/log/mongodb/Slave.log --pidfilepath /var/run/mongodb/Slave.pid
Под­клю­ча­ем­ся на слейв:
# mongo --host 192.168.13.147 --port 27001
Настра­и­ва­ем репли­ка­цию master-slave:
> use local
> db.sources.find()
> db.sources.insert( { host:"192.168.13.161:27001" } );
WriteResult({ "nInserted" : 1 })
>
И, смот­рим что получилось:
> show dbs
Про­ве­ря­ем ста­тус Slave:
> rs.printSlaveReplicationInfo()
source: 192.168.13.161:27001
syncedTo: Mon Apr 17 2019 19:21:21 GMT+0300 (EEST)
25 secs (0.01 hrs) behind the freshest member (no primary available at the moment)
source: 192.168.13.161:27001
doing initial sync
Мож­но еще:
> rs.printReplicationInfo()
И:
> db.serverStatus()
Вам может потре­бо­вать­ся запу­стить син­хро­ни­за­цию для вос­ста­нов­ле­ния репликации:
> use admin
> db.runCommand( { resync: 1 } )
Что­бы поту­шить ноду, используйте:
> db.adminCommand({shutdown : 1, force : true})

Replica Set

Replica Set – это набор/группа сер­ве­ров, кото­рые обслу­жи­ва­ют один и тот же набор данных
В такой груп­пе содер­жит­ся один мастер(первичный) и несколь­ко слейв(вторичный) серверов.
Так­же в Replica Set может исполь­зо­вать­ся арбитр. Это сер­вер, на кото­ром нет базы дан­ных, а его назна­че­ние – участ­во­вать в голо­со­ва­нии при выбо­ре ново­го масте­ра, созда­вать кво­рум необ­хо­ди­мый для голосования.

Первичный/мастер сер­вер обслу­жи­ва­ет все запро­сы на запись, а так­же запи­сы­ва­ет эти запро­сы в свой лог-файл(oplog).
Вторичные/слейв сер­ве­ра реп­ли­ци­ру­ют oplog пер­вич­но­го сер­ве­ра и при­ме­ня­ют опе­ра­ции к сво­им набо­рам дан­ных. Репли­ка­ция явля­ет­ся асинхронной.
Если пер­вич­ный сер­вер не обща­ет­ся с дру­ги­ми чле­на­ми репли­ки в тече­ние вре­ме­ни ,опре­де­лен­но­го пара­мет­ром electionTimeoutMillis (по умол­ча­нию 10 секунд), то в резуль­та­те голо­со­ва­ния выби­ра­ет­ся новый пер­вич­ный сер­вер из соста­ва теку­щих вто­рич­ных серверов.
Replica set не может обслу­жи­вать запро­сы на запись, до тех пор, пока выбо­ры и назна­че­ние ново­го масте­ра не закон­чат­ся успешно.
С настрой­ка­ми по умол­ча­нию сред­нее вре­мя на выбор ново­го масте­ра состав­ля­ет 12 секунд
Это вклю­ча­ет обна­ру­же­ние недо­ступ­но­сти мастера(10 секунд по умол­ча­нию) и выбор ново­го мастера.
При необ­хо­ди­мо­сти мож­но изме­нить зна­че­ние пара­мет­ра electionTimeoutMillis.

По умол­ча­нию запро­сы на чте­ния от кли­ен­тов обра­ба­ты­ва­ют­ся толь­ко масте­ром, но мож­но настро­ить, что­бы запро­сы на чте­ние посы­ла­лись и обра­ба­ты­ва­лись вто­рич­ны­ми серверами.
Т.к. исполь­зу­ет­ся асин­хрон­ная репли­ка­ция меж­ду пер­вич­ным и вто­рич­ны­ми сер­ве­ра­ми, то вто­рич­ные сер­ве­ра могут отда­вать кли­ен­там уста­рев­шие дан­ные по срав­не­нию с теми дан­ны­ми, кото­рые содер­жат­ся на масте­ре в дан­ный момент

 

Суть ReplicaSet заклю­ча­ет­ся в том, что она в себе сохра­ня­ет оди­на­ко­вые набо­ры дан­ных. Один сер­вер, дол­жен высту­пать в каче­стве основ­но­го сер­ве­ра ( на него будут посту­пать все дан­ные — он же веду­щий, он же  PRIMARY), а все осталь­ные — явля­ют­ся вто­рич­ны­ми ( они сохра­ня­ют копии дан­ных с  PRIMARY — они же ведо­мые, они же SECONDARYs).

Мож­но настро­ить дан­ную Репли­ку­Сет несколь­ки­ми способами:

  • Исполь­зо­вать 1 сер­вер и запу­стить 3 экзем­пля­ра самой mongoDB.
  • Исполь­зо­вать 3 сер­ве­ра с mongoDB.

И так, для пра­виль­но рабо­ты ReplicaSet необ­хо­ди­мо 3 запу­щен­ных экзем­пля­ра или сер­ве­ра с монгой:

  • Одна нода будет высту­пать как арбитр и не будет при­ни­мать на себя ника­кие дан­ные. Его рабо­та, заклю­ча­ет­ся в том, что­бы выбрать того, кто будет сер­ве­ром PRIMARY (Высту­па­ет как балан­си­ров­щик- это не совсем пра­виль­но, но похоже).
  • Один сер­вер высту­па­ет в каче­стве PRIMARY сервера.
  • Один сер­вер высту­па­ет в каче­стве SECONDARY сервера.

 

СПОСОБ 1 — используем один сервер

 

В целом, мой кон­фиг выгля­дит сле­ду­ю­щим образом:

cat /etc/mongod.conf

[codesyntax lang="php" blockstate="collapsed"]

[/codesyntax]

 

Каж­дый экзем­пляр мон­ги, будет созда­вать­ся со сво­им про­цес­сом, выде­лен­ным пор­том и сво­ей базой. Нач­нем с БД, созда­ем папки:

mkdir /var/lib/mongo/{my_database_1,my_database_2,my_database_3}
Созда­ние самих баз и уста­нов­ка необ­хо­ди­мо­го владельца:
chown mongod:mongod /var/lib/mongo/{my_database_1,my_database_2,my_database_3}
Запус­ка­ем сер­вер в каче­стве PRIMARY (Мастер):
mongod --dbpath /var/lib/mongo/my_database_1 --port 27001 --replSet My_Replica_Set --fork --logpath /var/log/mongodb/my_database_1.log
about to fork child process, waiting until server is ready for connections.
forked process: 53147
child process started successfully, parent exiting

Запус­ка­ем сер­вер в каче­стве SECONDARY (слейв):
mongod --dbpath /var/lib/mongo/my_database_2 --port 27002 --replSet My_Replica_Set --fork --logpath /var/log/mongodb/my_database_2.log

about to fork child process, waiting until server is ready for connections.
forked process: 53175
child process started successfully, parent exiting
Запус­ка­ем сер­вер в каче­стве арбит­ра (не при­ни­ма­ю­щим данных):
mongod --dbpath /var/lib/mongo/my_database_3 --port 27003 --replSet My_Replica_Set --fork --logpath /var/log/mongodb/my_database_3.log
about to fork child process, waiting until server is ready for connections.
forked process: 53207
child process started successfully, parent exiting
  • —dbpath — Дан­ная опция ука­зы­ва­ет на пап­ку где лежат ( будут лежать) базы данных.
  • —port — Дан­ная опция зада­ет порт для под­клю­че­ния клиентов.
  • —replSet — Дан­ная опция слу­жит в каче­стве назва­ния самой РС и долж­но быть оди­на­ко­во для всех нод/экземпляров mongod
  • —fork — Дан­ная опция запус­ка­ет mongod в режи­ме демона.
  • —logpath — Дан­ная опция ука­зы­ва­ет в какой файл будет пере­на­прав­лят­ся вывод.

Про­ве­ря­ем, стар­та­ну­ли ли все экземпляры:

ps aux | grep mongo| grep -Ev "grep"

[codesyntax lang="php" blockstate="collapsed"]

[/codesyntax]

 

Как вид­но с выво­да, все чет­ко запустилось.

 

Настрой­ка PRIMARY сервера


Под­клю­ча­ем­ся к серверу:
mongo --host 127.0.0.1 --port 27001

Про­ве­ря­ем ста­тус RS:
> rs.status()

Полу­ча­ем ошибку:
[codesyntax lang="php" blockstate="collapsed"]

[/codesyntax]
Так как РС еще не настро­е­на, полу­чи­ли ошиб­ку. Сей­час настро­им ее:
> rs.initiate({"_id" : "My_Replica_Set", members : [ {"_id" : 0, priority : 3, host : "127.0.0.1:27001"}, {"_id" : 1, host : "127.0.0.1:27002"},
{"_id" : 2, host : "127.0.0.1:27003", arbiterOnly : true} ] });
И, про­ве­ря­ем ста­тус Replica_Set снова:

[codesyntax lang="php" blockstate="collapsed"]

[/codesyntax]

Что­бы вый­ти, используйте:
>·quit()

про­ве­ря­ем осталь­ные ноды. Под­клю­ча­ем­ся к SECONDARY серверу:
# mongo --host 127.0.0.1 --port 27002
Вывод:
MongoDB shell version v4.2.1
connecting to: mongodb://127.0.0.1:27002/?compressors=disabled&gssapiServiceName=mongodb
Implicit session: session { "id" : UUID("ddfc569c-2e26-4e3e-a60d-3051fffe44a7") }
MongoDB server version: 4.2.1
Соб­ствен­но, вид­но что все в поряд­ке на сервере.
Про­ве­ря­ем статус:
 rs.status()Полу­ча­ем оди­на­ко­вый вывод. Мож­но с него вый­ти уже. 

Под­клю­ча­ем­ся к арбит­ру серверу:
# mongo --host 127.0.0.1 --port 27003

Вывод:
MongoDB shell version v4.2.1
connecting to: mongodb://127.0.0.1:27003/?compressors=disabled&gssapiServiceName=mongodb
Implicit session: session { "id" : UUID("9866925c-04d8-4307-b45a-7c2f740a6726") }
MongoDB server version: 4.2.1
My_Replica_Set:ARBITER>

Ана­ло­гич­но с арбит­ром. Видим что каж­дый из 3-х экзем­пля­ров, высту­па­ет как часть My_Replica_Set репликасет-а.

Но сей­час, про­те­сти­ру­ем паде­ние (отказ от рабо­ты) PRIMARY сер­ве­ра. Для нача­ла, смот­рим какие соеди­не­ния открыты:

netstat -lntpu | grep mongod

[codesyntax lang="php" blockstate="collapsed"]

[/codesyntax]

 

Видим, что PRIMARY сер­вер исполь­зу­ет 53147 PID, завер­шим его:

# kill -9 53147
И так, про­цесс завер­шен. Под­клю­ча­ем­ся к арбитру:
# mongo --host 127.0.0.1 --port 27003
И, про­ве­ря­ем ста­тус репликасета:

[codesyntax lang="php" blockstate="collapsed"]

[/codesyntax]

Нагляд­но вид­но, что  основ­ной сер­вер в дауне  («stateStr» : «(not reachable/healthy)»), а сер­вер с id 1 стал PRIMARY. Сно­ва запус­ка­ем упав­ший сер­вак ( экземпляр):

mongod --dbpath /var/lib/mongo/my_database_1 --port 27001 --replSet My_Replica_Set --fork --logpath /var/log/mongodb/my_database_1.log

 

И смот­рим что гово­рит нам арбитр:
mongo --host 127.0.0.1 --port 27003

[codesyntax lang="php" blockstate="collapsed"]

[/codesyntax]

Смот­рим какой кон­фиг име­ет наша репликасет:

[codesyntax lang="php" blockstate="collapsed"]

[/codesyntax]

С выво­дом уже ста­но­вит­ся понят­ным, что все воз­вра­ти­лось восво­я­си. Т.к я исполь­зо­вал одну маши­ну и запу­стил 3 экзем­пля­ра с mongoDB, то я очи­щу. Для это­го — под­клю­ча­ем­ся к основ­но­му серверу:
mongo --host 127.0.0.1 --port 27001
И, выпол­ня­ем:
My_Replica_Set:PRIMARY> use admin
switched to db admin
My_Replica_Set:PRIMARY> db.shutdownServer()

Завер­шит­ся 1-й сер­вер. Ана­ло­гич­ные дей­ствия выпол­ня­ем с остальными.

PS: Необ­хо­ди­мо поту­шить арбитра,а потом 2-й сервер!

mongo --host 127.0.0.1 --port 27003
MongoDB shell version v4.2.1
connecting to: mongodb://127.0.0.1:27003/?compressors=disabled&gssapiServiceName=mongodb
Implicit session: session { "id" : UUID("dc67e627-051c-4276-9338-bbece1282199") }
MongoDB server version: 4.2.1

My_Replica_Set:ARBITER> use admin
switched to db admin
My_Replica_Set:ARBITER> db.shutdownServer()

2019-12-01T14:23:15.457+0600 I NETWORK [js] DBClientConnection failed to receive message from 127.0.0.1:27003 - HostUnreachable: Connection closed by peer
server should be down…
2019-12-01T14:23:15.460+0600 I NETWORK [js] trying reconnect to 127.0.0.1:27003 failed
2019-12-01T14:23:15.460+0600 I NETWORK [js] reconnect 127.0.0.1:27003 failed failed
2019-12-01T14:23:15.462+0600 I NETWORK [js] trying reconnect to 127.0.0.1:27003 failed
2019-12-01T14:23:15.462+0600 I NETWORK [js] reconnect 127.0.0.1:27003 failed failed

 

теперь тушим вто­рой сервер:

mongo --host 127.0.0.1 --port 27002
MongoDB shell version v4.2.1
connecting to: mongodb://127.0.0.1:27002/?compressors=disabled&gssapiServiceName=mongodb
Implicit session: session { "id" : UUID("66eae0aa-1390-4f99-bc89-9f9f05685ec1") }
MongoDB server version: 4.2.1

 

My_Replica_Set:SECONDARY> use admin
switched to db admin
My_Replica_Set:SECONDARY> db.shutdownServer()
2019-12-01T14:24:39.601+0600 I NETWORK [js] DBClientConnection failed to receive message from 127.0.0.1:27002 - HostUnreachable: Connection closed by peer
server should be down…
2019-12-01T14:24:39.605+0600 I NETWORK [js] trying reconnect to 127.0.0.1:27002 failed
2019-12-01T14:24:39.606+0600 I NETWORK [js] reconnect 127.0.0.1:27002 failed failed
2019-12-01T14:24:39.608+0600 I NETWORK [js] trying reconnect to 127.0.0.1:27002 failed
2019-12-01T14:24:39.609+0600 I NETWORK [js] reconnect 127.0.0.1:27002 failed failed

 

Выпол­ня­ем проверку:

ps aux | grep mongod | grep -Ev "grep"
долж­но быть пусто

уда­ля­ем создан­ные базы:

rm -rf /var/lib/mongo/{my_database_1,my_database_2,my_database_3}

 

СПОСОБ 2 — используем мульти-ноды

 

У меня, в каче­стве при­ме­ра, используется:

  • PRIMARY       — 192.168.13.161    mongodb0
  • SECONDARY — 192.168.13.147      mongodb1
  • ARBITER        — 192.168.13.142    mongodb2

Выпол­ня­ем уста­нов­ку мон­ги на каж­дой из нод и при­сту­па­ем к настройке.

Созда­ем пап­ку где будут лежать базы:
mkdir /home/mongodb

На создан­ную пап­ку выстав­ля­ем необ­хо­ди­мо­го владельца:
chown mongod:mongod /home/mongodb

PS: Стан­дарт­ная пап­ка где хра­нят­ся базы — /var/lib/mongo и мож­но исполь­зо­вать имен­но ее.

Я в самом кон­фи­ге ниче­го не менял, оста­вил как и было.

Запус­ка­ем сервер:

systemctl restart mongod

PS: на каж­дой ноде!

 

 

Запуск PRIMARY сервера

И так, запус­ка­ем экземпляр:

mongod --dbpath /home/mongodb --bind_ip 192.168.13.161 --port 27001 --replSet My_Replica_Set --fork --logpath /var/log/mongodb/My_Replica_Set_PRIMARY.log --pidfilepath /var/run/mongodb/My_Replica_Set_PRIMARY.pid
about to fork child process, waiting until server is ready for connections.
forked process: 50619
child process started successfully, parent exiting

Смот­рим что­бы дан­ный экзем­пляр, запустился:
ps uax | grep -E "mongod" | grep -Ev "grep"

Полу­ча­ем:
root 50619 2.6 4.1 406696 41800 ? Sl 12:20 0:00 mongod --dbpath /home/mongodb --bind_ip 192.168.13.161 --port 27001 --replSet My_Replica_Set --fork --logpath /var/log/mongodb/My_Replica_Set_PRIMARY.log --pidfilepath /var/run/mongodb/My_Replica_Set_PRIMARY.pid

Как вид­но с выво­да, все чет­ко работает.

 

Запуск SECONDARY сервера

И так, запус­ка­ем экземпляр:
mongod --dbpath /home/mongodb --bind_ip 192.168.13.147 --port 27001 --replSet My_Replica_Set --fork --logpath /var/log/mongodb/My_Replica_Set_SECONDARY.log --pidfilepath /var/run/mongodb/My_Replica_Set_SECONDARY.pid

Если необ­хо­ди­мо, выпол­ня­ем проверку.

 

Запуск ARBITER сервера

И так, запус­ка­ем экземпляр:

mongod --dbpath /home/mongodb --bind_ip 192.168.13.142 --port 27001 --replSet My_Replica_Set --fork --logpath /var/log/mongodb/My_Replica_Set_ARBITER.log
Если необ­хо­ди­мо, выпол­ня­ем проверку.

 

 

Настрой­ка реплики
Под­клю­ча­ем­ся к серверу:

mongo --host 192.168.13.161 --port 27001
Про­ве­ря­ем ста­тус RS:
> rs.status()
СПОСОБ 1 — про­пи­сать сра­зу все хосты

Так как РС еще не настро­е­на, полу­чи­ли ошиб­ку. Сей­час настро­им ее:

> rs.initiate({"_id" : "My_Replica_Set", members : [ {"_id" : 0, priority : 3, host : "192.168.13.161:27001"}, {"_id" : 1, host : "192.168.13.147:27001"},
{"_id" : 2, host : "192.168.13.142:27001", arbiterOnly : true} ] });
СПОСОБ 1 — про­пи­сать хосты постепенно

ини­ци­а­ли­зи­ру­ем толь­ко один сервер:

>rs.initiate( {
_id : "My_Replica_Set",
members: [ { _id : 0, host : "192.168.13.161:27001" } ]
})
Потом, про­пи­сы­ва­ем еще один хост:
> rs.add("192.168.13.147:27001")
PS: Если нуж­но уда­лить, используем:
> rs.remove("192.168.13.147:27001")
И, нам нужен еще арбитр, по это­му, прописываем:
> rs.addArb("192.168.13.142:27001")

 

Про­вер­ка SECONDARY сер­ве­ра
Под­клю­ча­ем­ся сно­ва и про­ве­ря­ем ста­тус. У меня все зара­бо­та­ло. Оста­лось про­ве­рить на осталь­ных серверах
mongo --host 192.168.13.147 --port 27001

Про­ве­ря­ем ста­тус RS:
> rs.status()
Про­вер­ка ARBITER сер­ве­ра

Под­клю­ча­ем­ся сно­ва и про­ве­ря­ем ста­тус. У меня все зара­бо­та­ло. Оста­лось про­ве­рить на осталь­ных серверах
mongo --host 192.168.13.142 --port 27001

Про­ве­ря­ем ста­тус RS:
> rs.status()
И, про­ве­ря­ем ста­тус Replica_Set снова.

При такой настрой­ке име­ет­ся и недо­стат­ки — напри­мер, когда сер­вер упа­дет, то он не поды­мит­ся авто­ма­ти­че­ски. Есть костыль­ное реше­ние — создать bash скрипт, кото­рый будет про­ве­рять PID файл про­цес­са. Если его не ока­жет­ся, то он будет запус­кать экзем­пляр монги.

 

==================================================

Обновление MongoDB на нодах,которые находятся в Replica Set

Обнов­ле­ние Secondary-нод
1.На одной из Secondary-нод оста­нав­ли­ва­ем mongodb-службу

2. Обнов­ля­ем паке­ты Mongodb

3.Запускаем mongodb-служ­бу

Про­ве­ря­ем кор­рект­ность запуска

4. На Primary-ноде проверяем,что обнов­лен­ная Secondary-нода добав­ле­на в Replica Set

Ана­ло­гич­но обнов­ля­ем все осталь­ные Secondary-ноды

Обнов­ле­ние Primary Node
На Primary-ноде выполняем
1.Принудительный пере­вод Primary-ноды в Secondary

2.Проверяем,что была выбра­на новая Primary-нода и все Secondary-ноды сей­час реп­ли­ци­ру­ют­ся с новой Primary-нодой.
Дождать­ся окон­ча­ния про­цес­са син­хро­ни­за­ции всех Secondary-нод с новой Primary-нодой

3.Выполняем на быв­шей Primary-ноде(сейчас она уже Secondary-нода) те же команды,что выпол­ня­лись для обнов­ле­ния Secondary-нод
4. На Primary-ноде проверяем,что обнов­лен­ная Secondary-нода добав­ле­на в Replica Set

Таким обра­зом все ноды в Replica Set были обновлены

Полез­ные коман­ды Репликация/Replica Set в MongoDB

 

Про­смотр кон­фи­гу­ра­ции репликации

Про­смотр состо­я­ния репликации

Про­смотр чле­нов репликации

Keep an eye on the configVersion key of each member. Every
change in the replica set’s configuration increments the value of
configVersion by one. This can be handy for a members’s current
configuration state.

Проверка,выступает ли нода масте­ром репликации