Procedura per gestire un MongoDB danneggiato nel set di repliche Mongo CPS

Introduzione

In questo documento viene descritta la procedura per gestire un database MongoData danneggiato nei set di repliche di Cisco Policy Suite (CPS).

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

• Linux
• CPS
• MongoDB

Nota: Cisco consiglia di disporre del privilegio di accesso root alla CLI di CPS.

Componenti usati

Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:

• CPS 20.2
• MongoDB v3.6.17
• UCS-B

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Premesse

MongoDB è un programma per database orientato ai documenti (DB, Document-Oriented Database) multipiattaforma disponibile all'origine. Classificato come programma di database NoSQL. MongoDB è ampiamente utilizzato in CPS per gestire i suoi diversi tipi di DB, ad esempio SESSION, Subscriber Profile Repository (SPR), Balance e così via.

Problema

MongoDB viene danneggiato quando si esegue una deframmentazione errata del database mentre aido_client è ancora attivo all'interno di sessionmgr.

Questo fa sì che MongoDB conservi i dati in memoria ma non sia in grado di scriverli localmente sui percorsi del database. 

Ciò può causare la perdita di dati se il membro primario (istanza mongo) viene riavviato nel set di repliche interessato o se la VM sessionmgr viene riavviata.

Per comprendere come un membro del database sembra essere danneggiato, è possibile accedere a uno dei membri che presentano problemi ed eseguire i controlli forniti.

Passaggio 1. Quando si esegue il comando show dbs, non viene restituito alcun output di DB list. Quando tuttavia si controlla il conteggio all'interno del DB noto, viene restituito il conteggio.

[root@lab-1-pcrfclient01 ~]# mongo --host sessionmgr05:27737
MongoDB shell version v3.6.17
connect to: mongodb://sessionmgr05:27737/?gssapiServiceName=mongodb
Implicit session: session { "id" : UUID("a8f9b0eb-6e78-4bcd-bd63-60a9a9d813d0") }
MongoDB server version: 3.6.17
Server has startup warnings:
2022-03-09T00:53:26.910-0300 I CONTROL  [initandlisten]
2022-03-09T00:53:26.910-0300 I CONTROL  [initandlisten] ** WARNING: Access control is not enabled for the database.
2022-03-09T00:53:26.910-0300 I CONTROL  [initandlisten] **          Read and write access to data and configuration is unrestricted.
2022-03-09T00:53:26.910-0300 I CONTROL  [initandlisten] ** 
2022-03-09T00:53:26.910-0300 I CONTROL  [initandlisten]
2022-03-09T00:53:26.949-0300 I REPL     [replexec-0]
2022-03-09T00:53:26.949-0300 I REPL     [replexec-0] ** WARNING: This replica set uses arbiters, but readConcern:majority is enabled
2022-03-09T00:53:26.949-0300 I REPL     [replexec-0] **          for this node. This is not a recommended configuration. Please see
2022-03-09T00:53:26.949-0300 I REPL     [replexec-0] **          
2022-03-09T00:53:26.949-0300 I REPL     [replexec-0]
set01e:PRIMARY>
set01e:PRIMARY> show dbs  ## "no dbs reported"
set01e:PRIMARY> use session_cache  ## "Switched to a known DB"
switched to db session_cache
set01e:PRIMARY> db.session.count()
223037     ## "DB has the content inside, hence the total record count is shown"
set01e:PRIMARY> use session_cache_2
switched to db session_cache_2
set01e:PRIMARY> db.session.count()
223643
set01e:PRIMARY> use session_cache_3
switched to db session_cache_3
set01e:PRIMARY> db.session.count()
222939
set01e:PRIMARY> use session_cache_4
switched to db session_cache_4
set01e:PRIMARY> db.session.count()
223692
set01e:PRIMARY>
set01e:PRIMARY> exit
bye

Passaggio 2. Quando si esegue diagnostics.sh —get_shard, i dati vengono visualizzati in condivisione applicazioni. Questo viene archiviato in memoria e non nel DBPATH della macchina virtuale (VM) di Sessionmgr.

[root@lab-1-pcrfclient01 ~]# diagnostics.sh --get_shard
CPS Diagnostics GR Multi-Node Environment

|----------------------------------------------------------------------------------------------------------------------------------------|
|                                       SHARD STATUS INFORMATION                                   Date : 2022-03-09 11:00:23         |
|----------------------------------------------------------------------------------------------------------------------------------------|

Shard Id    Mongo DB                              State     Backup DB    Removed    Session Count
43          sessionmgr01:27717/session_cache      online    false        false      223873
1           sessionmgr01:27717/session_cache_2    online    false        false      222918
2           sessionmgr01:27717/session_cache_3    online    false        false      223720
3           sessionmgr01:27717/session_cache_4    online    false        false      223393
8           sessionmgr05:27737/session_cache      online    false        false      223188
9           sessionmgr05:27737/session_cache_2    online    false        false      223554
10          sessionmgr05:27737/session_cache_3    online    false        false      222920
11          sessionmgr05:27737/session_cache_4    online    false        false      223562
12          sessionmgr07:27747/session_cache      online    false        false      222663
13          sessionmgr07:27747/session_cache_2    online    false        false      222599
14          sessionmgr07:27747/session_cache_3    online    false        false      222475
15          sessionmgr07:27747/session_cache_4    online    false        false      223446
16          sessionmgr09:27757/session_cache      online    false        false      223246
17          sessionmgr09:27757/session_cache_2    online    false        false      223669
18          sessionmgr09:27757/session_cache_3    online    false        false      223711
19          sessionmgr09:27757/session_cache_4    online    false        false      223311
35          sessionmgr13:27717/session_cache      online    true         false      0
36          sessionmgr13:27717/session_cache_2    online    true         false      0
37          sessionmgr13:27717/session_cache_3    online    true         false      0
38          sessionmgr13:27717/session_cache_4    online    true         false      0

Rebalance Status: Rebalanced

Passaggio 3. Questo output mostra che nel percorso del database non è presente alcun contenuto in cui si suppone che vengano archiviati i dati effettivi.

[SESSION-SET3]
SETNAME=set01e
OPLOG_SIZE=5120
ARBITER=lab-1-arb-sessmgr15:27737
ARBITER_DATA_PATH=/var/data/sessions.1/set01e
PRIMARY-MEMBERS
MEMBER1=lab-1-sessionmgr05:27737
MEMBER2=lab-1-sessionmgr06:27737
SECONDARY-MEMBERS
MEMBER3=lab-2-sessionmgr05:27737
MEMBER4=lab-2-sessionmgr06:27737
DATA_PATH=/var/data/sessions.1/set01e ## "DB DATA Path of set01e replicaset"
[SESSION-SET3-END]

Collegare Secure Shell (SSH) al dispositivo sessionmgr associato e selezionare il percorso DB_PATH indicato nella configurazione mongo. Il contenuto di DB_PATH è vuoto.

[root@lab-1-sessionmgr05 ~]# cd /var/data/sessions.1/set01e
[root@lab-1-sessionmgr05 ~]# ls -lrt
total 0
[root@lab-1-sessionmgr05 ~]# 

Con questi controlli, si può arrivare alla conclusione che MongoDB è danneggiato.

Procedura per il ripristino del membro del database danneggiato

Passaggio 1. SSH sui membri primari del set di repliche con problemi.
Passaggio 2. Arrestare aido_client (assicurarsi di arrestare il client aido su tutti i membri del set di repliche che appartiene a set01e).
Passaggio 3. Connettersi alla shell mongo di set01e ed eseguire la procedura seguente.

     # mongo --port 27737
     # show dbs                          # Ensure this returns empty output.
     # use admin
     # db.repairDatabase()
     # use config
     # db.repairDatabase()
     # exit

[root@lab-1-sessionmgr05 set01e]# mongo --port 27737
MongoDB shell version v3.6.17
connect to: mongodb://127.0.0.1:27737/?gssapiServiceName=mongodb
Implicit session: session { "id" : UUID("ff9df861-0b42-4e8a-99c1-3583670e1926") }
MongoDB server version: 3.6.17
Server has startup warnings:
2022-03-09T00:53:26.910-0300 I CONTROL  [initandlisten]
2022-03-09T00:53:26.910-0300 I CONTROL  [initandlisten] ** WARNING: Access control is not enabled for the database.
2022-03-09T00:53:26.910-0300 I CONTROL  [initandlisten] **          Read and write access to data and configuration is unrestricted.
2022-03-09T00:53:26.910-0300 I CONTROL  [initandlisten] ** 
2022-03-09T00:53:26.910-0300 I CONTROL  [initandlisten]
2022-03-09T00:53:26.949-0300 I REPL     [replexec-0]
2022-03-09T00:53:26.949-0300 I REPL     [replexec-0] ** WARNING: This replica set uses arbiters, but readConcern:majority is enabled
2022-03-09T00:53:26.949-0300 I REPL     [replexec-0] **          for this node. This is not a recommended configuration. Please see
2022-03-09T00:53:26.949-0300 I REPL     [replexec-0] **          
2022-03-09T00:53:26.949-0300 I REPL     [replexec-0]
set01e:PRIMARY> use admin
switched to db admin
set01e:PRIMARY> db.repairDatabase()
{
"ok" : 1,
"operationTime" : Timestamp(1647319246, 352),
"$clusterTime" : {
"clusterTime" : Timestamp(1647319246, 352),
"signature" : {
"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
"keyId" : NumberLong(0)
}
}
}
set01e:PRIMARY>
set01e:PRIMARY> use config
switched to db config
set01e:PRIMARY> db.repairDatabase()
{
"ok" : 1,
"operationTime" : Timestamp(1647319301, 218),
"$clusterTime" : {
"clusterTime" : Timestamp(1647319301, 218),
"signature" : {
"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
"keyId" : NumberLong(0)
}
}
}
set01e:PRIMARY> show dbs
admin   0.031GB
config  0.031GB
set01e:PRIMARY> exit

Passaggio 4. Connettersi nuovamente allo stesso istante di replica ed eseguire questi comandi su tutti session_cache_dbs. Di seguito è riportato un esempio di database session_cache.

     # mongo --port 27737
     # use session_cache
     # db.session.count()                # Use this to check that session counts are still intact
     # db.stats(1024*1024*1024)   # Use this to verify that the storage size is proper
     # db.repairDatabase()
     # exit

[root@lab-1-sessionmgr05 set01e]# mongo --port 27737
MongoDB shell version v3.6.17
connect to: mongodb://127.0.0.1:27737/?gssapiServiceName=mongodb
Implicit session: session { "id" : UUID("73794d11-0785-4520-ba82-19f0d2bba338") }
MongoDB server version: 3.6.17
Server has startup warnings:
2022-03-09T00:53:26.910-0300 I CONTROL  [initandlisten]
2022-03-09T00:53:26.910-0300 I CONTROL  [initandlisten] ** WARNING: Access control is not enabled for the database.
2022-03-09T00:53:26.910-0300 I CONTROL  [initandlisten] **          Read and write access to data and configuration is unrestricted.
2022-03-09T00:53:26.910-0300 I CONTROL  [initandlisten] ** 
2022-03-09T00:53:26.910-0300 I CONTROL  [initandlisten]
2022-03-09T00:53:26.949-0300 I REPL     [replexec-0]
2022-03-09T00:53:26.949-0300 I REPL     [replexec-0] ** WARNING: This replica set uses arbiters, but readConcern:majority is enabled
2022-03-09T00:53:26.949-0300 I REPL     [replexec-0] **          for this node. This is not a recommended configuration. Please see
2022-03-09T00:53:26.949-0300 I REPL     [replexec-0] **          
2022-03-09T00:53:26.949-0300 I REPL     [replexec-0]
set01e:PRIMARY>
set01e:PRIMARY>
set01e:PRIMARY>
set01e:PRIMARY> show dbs
admin   0.031GB
config  0.031GB
set01e:PRIMARY> use session_cache
switched to db session_cache
set01e:PRIMARY>
set01e:PRIMARY> db.stats(1024*1024*1024)
{
"db" : "session_cache",
"collections" : 3,
"views" : 0,
"objects" : 212467,
"avgObjSize" : 8175.252062673262,
"dataSize" : 1.6176805645227432,
"storageSize" : 2.471107453107834,
"numExtents" : 22,
"indexes" : 3,
"indexSize" : 0.30870679020881653,
"fileSize" : 0,
"nsSizeMB" : 16,
"extentFreeList" : {
"num" : 0,
"totalSize" : 0
},
"dataFileVersion" : {
"major" : 4,
"minor" : 22
},
"fsUsedSize" : 38.36811065673828,
"fsTotalSize" : 47.044921875,
"ok" : 1,
"operationTime" : Timestamp(1647321405, 102),
"$clusterTime" : {
"clusterTime" : Timestamp(1647321405, 103),
"signature" : {
"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
"keyId" : NumberLong(0)
}
}
}
set01e:PRIMARY> db.repairDatabase()
{
"ok" : 1,
"operationTime" : Timestamp(1647321444, 84),
"$clusterTime" : {
"clusterTime" : Timestamp(1647321444, 84),
"signature" : {
"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
"keyId" : NumberLong(0)
}
}
}
set01e:PRIMARY> show dbs
admin          0.031GB
config         0.031GB
session_cache  2.499GB

Nota: Ripetere il passaggio 4 per gli altri database session_cache.

Passaggio 5. Verificare che il comando show dbs ora elenchi tutti i database quando si connette nuovamente la stessa istanza mongo.

mongo --port 27737
set01e:PRIMARY> show dbs
admin 0.031GB
config 0.031GB
session_cache 2.499GB
session_cache_2 2.499GB
session_cache_3 2.499GB
session_cache_4 2.499GB

Passaggio 6. Verificare che il percorso del database ora contenga tutti i dati localmente all'interno di sessionmgr. È possibile controllare il percorso dei dati del set di repliche. In questo caso, è /var/data/session.1/set01e.

[root@lab-1-sessionmgr05 set01~]# cd /var/data/sessions.1/set01e
[root@lab-1-sessionmgr05 set01e]# ls
admin session_cache session_cache_2.1 session_cache_2.7 session_cache_3.1 session_cache_3.7 session_cache_4.1 session_cache_4.7 session_cache.8
admin.0 session_cache.0 session_cache_2.2 session_cache_2.8 session_cache_3.2 session_cache_3.8 session_cache_4.2 session_cache_4.8 session_cache.ns
admin.ns session_cache.1 session_cache_2.3 session_cache_2.ns session_cache_3.3 session_cache_3.ns session_cache_4.3 session_cache_4.ns _tmp
config session_cache.2 session_cache_2.4 session_cache.3 session_cache_3.4 session_cache.4 session_cache_4.4 session_cache.5
config.0 session_cache_2 session_cache_2.5 session_cache_3 session_cache_3.5 session_cache_4 session_cache_4.5 session_cache.6
config.ns session_cache_2.0 session_cache_2.6 session_cache_3.0 session_cache_3.6 session_cache_4.0 session_cache_4.6 session_cache.7

Passaggio 7. SSH sullo stesso membro secondario del sito ed esecuzione della sincronizzazione locale del percorso dati con il membro primario.

         ssh  to lab-1-sessionmgr06   (Secondary member)
         Ensure to stop aido_client

           # monit stop aido_client

         Ensure to stop mongo processes

           # /etc/init.d/sessionmgr-27737 stop    # Wait for 10 seconds and start the service back on

Verificare che il percorso dati /var/data/sessions.1/set01e sia vuoto e, in caso contrario, rimuoverlo utilizzando rm -rf /var/data/sessions.1/set01e/*, quindi avviare il processo mongo.

# /etc/init.d/sessionmgr-27737 start

[root@lab-1-sessionmgr06 ~]# monit stop aido_client
[root@lab-1-sessionmgr06 ~]# monit status aido_client
Monit 5.26.0 uptime: 52d 20h 59m

Process 'aido_client'
status                 Not monitored
monitoring status      Not monitored
monitoring mode        active
on reboot              start
data collected         Wed, 23 Mar 2022 08:08:46

[root@lab-1-sessionmgr06 ~]#
[root@lab-1-sessionmgr06 ~]# /etc/init.d/sessionmgr-27737 stop
stop sessionmgr-27737 (via systemctl): [ OK ]
[root@lab-1-sessionmgr06 ~]# rm -rf /var/data/sessions.1/set01e/*
[root@lab-1-sessionmgr06 ~]# cd /var/data/sessions.1/set01e/
[root@lab-1-sessionmgr06 set01e]# ls
[root@lab-1-sessionmgr06 set01e]# 
[root@lab-1-sessionmgr06 set01e]# /etc/init.d/sessionmgr-27737 start
Starting sessionmgr-27737 (via systemctl): [ OK ]

Passaggio 8. Verificare che i dati siano ora copiati localmente in /var/data/sessions.1/set01e.

[root@lab-1-sessionmgr06 ~]# cd /var/data/sessions.1/set01e/
[root@lab-1-sessionmgr06 set01e]# ls
admin.0 local.1 local.3 local.7 mongod.lock session_cache_2.3 session_cache_2.7 session_cache_3.1 session_cache_3.5 session_cache_3.ns
admin.ns local.10 local.4 local.8 session_cache_2.0 session_cache_2.4 session_cache_2.8 session_cache_3.2 session_cache_3.6 storage.bson
diagnostic.data local.11 local.5 local.9 session_cache_2.1 session_cache_2.5 session_cache_2.ns session_cache_3.3 session_cache_3.7 _tmp
local.0 local.2 local.6 local.ns session_cache_2.2 session_cache_2.6 session_cache_3.0 session_cache_3.4 session_cache_3.8
[root@lab-1-sessionmgr06 set01e]# 

Nota: Ripetere i passaggi 7 e 8 per i membri secondari del sito geo. Qui in laboratorio, i membri sono lab-2-sessionmgr05 e lab-2-sessionmgr06.

Passaggio 9. Dopo aver ripristinato tutti i database secondari (sito locale e geografico), riavviare il servizio mongo sul membro primario.

[root@lab-1-sessionmgr05 ~]# /etc/init.d/sessionmgr-27737 stop
stop sessionmgr-27737 (via systemctl): [ OK ]

 Attendere 10 secondi e verificare che lo switch primario sia stato eseguito correttamente.

[root@lab-1-sessionmgr06 ~]# mongo --port 27737
MongoDB shell version v3.6.17
connect to: mongodb://127.0.0.1:27737/?gssapiServiceName=mongodb
Implicit session: session { "id" : UUID("ba8e49fa-ad0f-4ac6-8ef8-b4da0a88fe33") }
MongoDB server version: 3.6.17
Server has startup warnings: 
2022-03-15T02:54:29.546-0300 I CONTROL [initandlisten] 
2022-03-15T02:54:29.546-0300 I CONTROL [initandlisten] ** WARNING: Access control is not enabled for the database.
2022-03-15T02:54:29.546-0300 I CONTROL [initandlisten] ** Read and write access to data and configuration is unrestricted.
2022-03-15T02:54:29.546-0300 I CONTROL [initandlisten] ** 
2022-03-15T02:54:29.546-0300 I CONTROL [initandlisten] 
set01e:PRIMARY> 
set01e:PRIMARY> 
set01e:PRIMARY> show dbs
admin 0.031GB
config 0.031GB
local 5.029GB
session_cache 2.499GB
session_cache_2 2.499GB
session_cache_3 2.499GB
session_cache_4 2.499GB
set01e:PRIMARY> show dbs
admin 0.031GB
config 0.031GB
local 5.029GB
session_cache 2.499GB
session_cache_2 2.499GB
session_cache_3 2.499GB
session_cache_4 2.499GB
set01e:PRIMARY> rs.status()
{
"set" : "set01e",
"date" : ISODate("2022-03-15T06:13:19.991Z"),
"myState" : 1,
"term" : NumberLong(36),
"syncingTo" : "",
"syncSourceHost" : "",
"syncSourceId" : -1,
"heartbeatIntervalMillis" : NumberLong(2000),
"optimes" : {
"lastCommittedOpTime" : {
"ts" : Timestamp(1647324799, 335),
"t" : NumberLong(36)
},
"readConcernMajorityOpTime" : {
"ts" : Timestamp(1647324799, 335),
"t" : NumberLong(36)
},
"appliedOpTime" : {
"ts" : Timestamp(1647324799, 338),
"t" : NumberLong(36)
},
"durableOpTime" : {
"ts" : Timestamp(0, 0),
"t" : NumberLong(-1)
}
},
"members" : [
{
"_id" : 0,
"name" : "lab-2-sessionmgr06:27737",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 486,
"optime" : {
"ts" : Timestamp(1647324799, 94),
"t" : NumberLong(36)
},
"optimeDurable" : {
"ts" : Timestamp(0, 0),
"t" : NumberLong(-1)
},
"optimeDate" : ISODate("2022-03-15T06:13:19Z"),
"optimeDurableDate" : ISODate("1970-01-01T00:00:00Z"),
"lastHeartbeat" : ISODate("2022-03-15T06:13:19.267Z"),
"lastHeartbeatRecv" : ISODate("2022-03-15T06:13:18.270Z"),
"pingMs" : NumberLong(0),
"lastHeartbeatMessage" : "",
"syncingTo" : "lab-1-sessionmgr06:27737",
"syncSourceHost" : "lab-1-sessionmgr06:27737",
"syncSourceId" : 4,
"infoMessage" : "",
"configVersion" : 8
},
{
"_id" : 1,
"name" : "lab-1-sessionmgr05:27737",
"health" : 1,
"state" : 2,
"stateStr" : "SECONDARY",
"uptime" : 885,
"optime" : {
"ts" : Timestamp(1647324799, 96),
"t" : NumberLong(36)
},
"optimeDurable" : {
"ts" : Timestamp(0, 0),
"t" : NumberLong(-1)
},
"optimeDate" : ISODate("2022-03-15T06:13:19Z"),
"optimeDurableDate" : ISODate("1970-01-01T00:00:00Z"),
"lastHeartbeat" : ISODate("2022-03-15T06:13:19.270Z"),
"lastHeartbeatRecv" : ISODate("2022-03-15T06:13:18.270Z"),
"pingMs" : NumberLong(0),
"lastHeartbeatMessage" : "",
"syncingTo" : "lab-1-sessionmgr06:27737",
"syncSourceHost" : "lab-1-sessionmgr06:27737",
"syncSourceId" : 4,
"infoMessage" : "",
"configVersion" : 8
},
{
"_id" : 2,
"name" : "lab-1-arb-sessmgr15:27737",
"health" : 1,
"state" : 7,
"stateStr" : "ARBITER",
"uptime" : 1130,
"lastHeartbeat" : ISODate("2022-03-15T06:13:19.240Z"),
"lastHeartbeatRecv" : ISODate("2022-03-15T06:13:18.856Z"),
"pingMs" : NumberLong(0),
"lastHeartbeatMessage" : "",
"syncingTo" : "",
"syncSourceHost" : "",
"syncSourceId" : -1,
"infoMessage" : "",
"configVersion" : 8
},
{
"_id" : 3,
"name" : "lab-1-sessionmgr05:27737",
"health" : 0,
"state" : 8,
"stateStr" : "(not reachable/healthy)",
"uptime" : 0,
"optime" : {
"ts" : Timestamp(0, 0),
"t" : NumberLong(-1)
},
"optimeDurable" : {
"ts" : Timestamp(0, 0),
"t" : NumberLong(-1)
},
"optimeDate" : ISODate("1970-01-01T00:00:00Z"),
"optimeDurableDate" : ISODate("1970-01-01T00:00:00Z"),
"lastHeartbeat" : ISODate("2022-03-15T06:13:19.299Z"),
"lastHeartbeatRecv" : ISODate("2022-03-15T06:11:58.086Z"),
"pingMs" : NumberLong(0),
"lastHeartbeatMessage" : "Connection refused",
"syncingTo" : "",
"syncSourceHost" : "",
"syncSourceId" : -1,
"infoMessage" : "",
"configVersion" : -1
},
{
"_id" : 4,
"name" : "lab-1-sessionmgr06:27737",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 1130,
"optime" : {
"ts" : Timestamp(1647324799, 338),
"t" : NumberLong(36)
},
"optimeDate" : ISODate("2022-03-15T06:13:19Z"),
"syncingTo" : "",
"syncSourceHost" : "",
"syncSourceId" : -1,
"infoMessage" : "",
"electionTime" : Timestamp(1647324719, 72),
"electionDate" : ISODate("2022-03-15T06:11:59Z"),
"configVersion" : 8,
"self" : true,
"lastHeartbeatMessage" : ""
}
],
"ok" : 1,
"operationTime" : Timestamp(1647324799, 338),
"$clusterTime" : {
"clusterTime" : Timestamp(1647324799, 338),
"signature" : {
"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
"keyId" : NumberLong(0)
}
}
}

Passaggio 10. Riavviare il servizio mongo su lab-1-sessionmgr05, che era il membro primario in precedenza.

[root@lab-1-sessionmgr05 ~]# /etc/init.d/sessionmgr-27737 start
Starting sessionmgr-27737 (via systemctl): [ OK ] 

Passaggio 11. Avviare aido_client su tutti i membri di replica del set di repliche set01e interrotto nel passaggio 2.