Joey Yi Zhao's questions

Estou lendo a documentação do Postgres 7.3 para adicionar uma restrição a uma tabela do PostgreSQL.

Diz:

Para adicionar uma restrição não nula, que não pode ser escrita como uma restrição de tabela, use esta sintaxe:

ALTER TABLE produtos ALTER COLUMN product_no SET NOT NULL;

A restrição será verificada imediatamente, portanto, os dados da tabela devem satisfazer a restrição antes que possam ser adicionados.

Eu não entendo o que significa "o que não pode ser escrito como uma restrição de tabela" ?

O que é restrição de tabela? Que restrição não é verificada imediatamente?

Estou usando o driver nodejs mongodb para conectar a uma instância mongodb autoassinada. A versão do MongoDB e do Mongo Shell é 4.0.0. Abaixo está o comando para iniciar uma instância mongodb autoassinada:

mongod --port 27018 --sslMode requireSSL --sslPEMKeyFile mongodb.pem  --dbpath data

quando me conecto a este servidor com o shell mongo, posso usar o comando abaixo sem o arquivo pem:

mongo --port 27018 --ssl --sslAllowInvalidCertificates

Gostaria de saber para que o arquivo PEM é usado na conexão.

Um dos novos recursos do MongoDB 3.6 é o validador jsonSchema. Eu posso criar uma coleção com um validador como:

{
  "validator": {
    "$jsonSchema": {
      "properties": {
        "name": {
          "bsonType": "string",
          "description": "name"
        },
        "age": {
          "bsonType": "int",
          "minimum": 10,
          "maximum": 30
        }
      },
      "required": ["name", "age"],
      "bsonType": "object"
    }
  }
}

Mas e se a coleção já existisse com alguns documentos, que não preenchem o esquema de validação? Como posso descobrir todos os documentos inválidos com base no validador?

Estou usando o mongodb 3.6 e tenho o validador abaixo para a studentscoleção:

rs1:PRIMARY> db.getCollectionInfos({name: 'students'})
[
    {
        "name" : "students",
        "type" : "collection",
        "options" : {
            "validator" : {
                "$jsonSchema" : {
                    "properties" : {
                        "name" : {
                            "bsonType" : "string",
                            "description" : "name"
                        },
                        "age" : {
                            "bsonType" : "int",
                            "minimum" : 10,
                            "maximum" : 30
                        }
                    },
                    "required" : [
                        "name",
                        "age"
                    ],
                    "bsonType" : "object"
                }
            },
            "validationLevel" : "strict",
            "validationAction" : "error"
        },
        "info" : {
            "readOnly" : false,
            "uuid" : BinData(4,"111r7z+rQpGoebZ1jAHO4g==")
        },
        "idIndex" : {
            "v" : 2,
            "key" : {
                "_id" : 1
            },
            "name" : "_id_",
            "ns" : "test.students"
        }
    }
]

requer duas propriedades namee age. O nome deve ser uma string e a idade deve estar entre 10 e 30. Mas por que a inserção abaixo falha?

rs1:PRIMARY> db.students.insert({age: 11, name: 'Mike'})
WriteResult({
    "nInserted" : 0,
    "writeError" : {
        "code" : 121,
        "errmsg" : "Document failed validation"
    }
})

Estou usando db.setProfilingLevel(1, 1000)para definir o nível de perfil para cada banco de dados. Vejo que o nível pode ser definido para cada banco de dados, mas slowmsé um estado global. Existe alguma maneira de definir esse valor para cada banco de dados individual?

Se eu não puder defini-lo para cada banco de dados individual, por que existe um método que db.setProfilingLevel(level, slowms)aceita o segundo parâmetro como slowms. Parece que esse parâmetro é para valor global em vez de valor do banco de dados. O que é confuso é que esse método é específico para definir um único nível de perfil de banco de dados, mas por alguns motivos ele também define slowms na configuração global.

Eu tenho um mongos que se conecta a três clusters de fragmentos. Eu tenho alguns bancos de dados e coleções nesta instância mongos. Todas as outras coleções funcionam bem, exceto uma com um problema de desempenho. Demora 45 minutos para executar abaixo do comando

db.orders.find().explain('executionStats')

O número total de documentos nesta coleção é 111898400. Cada cluster de estilhaços tem aproximadamente 30000000documentos. Eu sei que não executei essa consulta na chave de fragmentação, mas gostaria de saber se esse é o motivo pelo qual demora tanto. Espero que leve alguns minutos no máximo, mas não 45 minutos.

Abaixo estão as estatísticas de execução do comando acima. Como posso perfilá-lo mais para descobrir por que demora tanto?

"executionStats" : {
        "nReturned" : 111432926,
        "executionTimeMillis" : 2727745,
        "totalKeysExamined" : 0,
        "totalDocsExamined" : 111899059,
        "executionStages" : {
            "stage" : "SHARD_MERGE",
            "nReturned" : 111432926,
            "executionTimeMillis" : 2727745,
            "totalKeysExamined" : 0,
            "totalDocsExamined" : 111899059,
            "totalChildMillis" : NumberLong(6550367),
            "shards" : [
                {
                    "shardName" : "s0",
                    "executionSuccess" : true,
                    "executionStages" : {
                        "stage" : "SHARDING_FILTER",
                        "nReturned" : 36545358,
                        "executionTimeMillisEstimate" : 2723505,
                        "works" : 36613353,
                        "advanced" : 36545358,
                        "needTime" : 67994,
                        "needYield" : 0,
                        "saveState" : 321990,
                        "restoreState" : 321990,
                        "isEOF" : 1,
                        "invalidates" : 0,
                        "chunkSkips" : 67993,
                        "inputStage" : {
                            "stage" : "COLLSCAN",
                            "nReturned" : 36613351,
                            "executionTimeMillisEstimate" : 2689811,
                            "works" : 36613353,
                            "advanced" : 36613351,
                            "needTime" : 1,
                            "needYield" : 0,
                            "saveState" : 321990,
                            "restoreState" : 321990,
                            "isEOF" : 1,
                            "invalidates" : 0,
                            "direction" : "forward",
                            "docsExamined" : 36613351
                        }
                    }
                },
                {
                    "shardName" : "s1",
                    "executionSuccess" : true,
                    "executionStages" : {
                        "stage" : "SHARDING_FILTER",
                        "nReturned" : 36423091,
                        "executionTimeMillisEstimate" : 1647595,
                        "works" : 36423093,
                        "advanced" : 36423091,
                        "needTime" : 1,
                        "needYield" : 0,
                        "saveState" : 305586,
                        "restoreState" : 305586,
                        "isEOF" : 1,
                        "invalidates" : 0,
                        "chunkSkips" : 0,
                        "inputStage" : {
                            "stage" : "COLLSCAN",
                            "nReturned" : 36423091,
                            "executionTimeMillisEstimate" : 1614736,
                            "works" : 36423093,
                            "advanced" : 36423091,
                            "needTime" : 1,
                            "needYield" : 0,
                            "saveState" : 305586,
                            "restoreState" : 305586,
                            "isEOF" : 1,
                            "invalidates" : 0,
                            "direction" : "forward",
                            "docsExamined" : 36423091
                        }
                    }
                },
                {
                    "shardName" : "s2",
                    "executionSuccess" : true,
                    "executionStages" : {
                        "stage" : "SHARDING_FILTER",
                        "nReturned" : 38464477,
                        "executionTimeMillisEstimate" : 2166740,
                        "works" : 38862619,
                        "advanced" : 38464477,
                        "needTime" : 398141,
                        "needYield" : 0,
                        "saveState" : 331525,
                        "restoreState" : 331525,
                        "isEOF" : 1,
                        "invalidates" : 0,
                        "chunkSkips" : 398140,
                        "inputStage" : {
                            "stage" : "COLLSCAN",
                            "nReturned" : 38862617,
                            "executionTimeMillisEstimate" : 2128083,
                            "works" : 38862619,
                            "advanced" : 38862617,
                            "needTime" : 1,
                            "needYield" : 0,
                            "saveState" : 331525,
                            "restoreState" : 331525,
                            "isEOF" : 1,
                            "invalidates" : 0,
                            "direction" : "forward",
                            "docsExamined" : 38862617
                        }
                    }
                }
            ]
        }
    },

Eu tenho um cluster de estilhaços: um mongos, três conjuntos de réplicas de estilhaços e um conjunto de réplicas de configuração. Meu aplicativo fala apenas com o mongosfor read/write to mongodb. Gostaria de saber se posso fazer a mongosréplica. O que quero dizer com isso é que, em caso de mongosqueda, preciso de um escravo dos mongos para se tornar o principal. Existe um --replSetparâmetro ligado , mongodmas mongosnão tem esse parâmetro. Como posso fazer isso em mongos?

Eu tenho um cluster de fragmentos mongo e uma instância mongos. Esses servidores estão sendo executados no MongoDB 3.4.0. Quando uso o mongo shell 3.4.0 para me conectar aos mongos, obtive a saída abaixo de sh.isBalancerRunning(),

mongos> sh.isBalancerRunning()
false

mas obtive um resultado diferente quando uso o mongo shell 3.2.13:

mongos> sh.isBalancerRunning()
true

Isso é algo não compatível entre as versões do mongo? Se sim, por que outros comandos funcionam bem, apenas este comando não?

Estou usando esta conexão uri para conectar ao mongodb: mongodb://user:password@localhost/admin. Ele usará admincomo autenticação de bot e banco de dados de destino. Como posso fazer o uri usar admincomo autenticação, mas permitir que eu me conecte a um banco de dados diferente? Por favor, veja o comando abaixo como um exemplo:

mongo --host localhost -u user -p password --authentication admin test

o comando acima usará admincomo banco de dados de autenticação, mas se conectará ao testbanco de dados. como posso fazer a mesma coisa em uri?

Eu quero configurar um usuário no MongoDB. Este usuário não terá acesso ao banco de dados de administrador. Mas usa admin como banco de dados de autenticação. Ele falhará ao conectar o mongoDB por este comando mongo --host localhost admin. Em vez disso, ele pode usar este comando para se conectar ao testbanco de dados: mongo --host localhost --authenticationDatabases admin test. Como posso restringir a permissão neste caso?

Eu tentei abaixo do comando para criar um usuário:

db.createUser({user: 'testUser', pwd: '123456', roles: [{role:'readWrite', db: 'SampleCollections'}]})

quando uso essa conta de usuário para fazer login no shell do mongo, consigo listar as coleções no adminbanco de dados. Como posso restringir o usuário apenas no SampleCollectionsbanco de dados não admin?

Eu configurei um cluster de fragmentos do MongoDB. Ele tem três réplicas de estilhaços, cada réplica tem três instâncias do mongo. E tem uma réplica de 3 servidores de configuração do mongo. E um mongo. Funciona bem no início, mas a conexão da réplica de configuração falhou após alguns dias de execução. Quando eu faço login em cada instância mongo do servidor de configuração, abaixo está a rs.status()saída do comando:

Configurar servidor1:

OTHER> rs.status()
{
    "state" : 10,
    "stateStr" : "REMOVED",
    "uptime" : 121353,
    "optime" : {
        "ts" : Timestamp(1504367995, 1),
        "t" : NumberLong(3)
    },
    "optimeDate" : ISODate("2017-09-02T15:59:55Z"),
    "ok" : 0,
    "errmsg" : "Our replica set config is invalid or we are not a member of it",
    "code" : 93,
    "codeName" : "InvalidReplicaSetConfig"
}

Configure o Servidor 2:

OTHER> rs.status()
{
    "state" : 10,
    "stateStr" : "REMOVED",
    "uptime" : 121421,
    "optime" : {
        "ts" : Timestamp(1504367995, 1),
        "t" : NumberLong(3)
    },
    "optimeDate" : ISODate("2017-09-02T15:59:55Z"),
    "ok" : 0,
    "errmsg" : "Our replica set config is invalid or we are not a member of it",
    "code" : 93,
    "codeName" : "InvalidReplicaSetConfig"
}

Configure o servidor 3:

SECONDARY> rs.status()
{
    "set" : "cnf-serv",
    "date" : ISODate("2017-09-04T01:45:05.842Z"),
    "myState" : 2,
    "term" : NumberLong(3),
    "configsvr" : true,
    "heartbeatIntervalMillis" : NumberLong(2000),
    "optimes" : {
        "lastCommittedOpTime" : {
            "ts" : Timestamp(0, 0),
            "t" : NumberLong(-1)
        },
        "appliedOpTime" : {
            "ts" : Timestamp(1504367995, 1),
            "t" : NumberLong(3)
        },
        "durableOpTime" : {
            "ts" : Timestamp(1504367995, 1),
            "t" : NumberLong(3)
        }
    },
    "members" : [
        {
            "_id" : 0,
            "name" : "172.19.0.10:27017",
            "health" : 1,
            "state" : 2,
            "stateStr" : "SECONDARY",
            "uptime" : 121454,
            "optime" : {
                "ts" : Timestamp(1504367995, 1),
                "t" : NumberLong(3)
            },
            "optimeDate" : ISODate("2017-09-02T15:59:55Z"),
            "configVersion" : 403866,
            "self" : true
        },
        {
            "_id" : 1,
            "name" : "172.19.0.7:27017",
            "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("2017-09-04T01:45:02.312Z"),
            "lastHeartbeatRecv" : ISODate("1970-01-01T00:00:00Z"),
            "pingMs" : NumberLong(0),
            "lastHeartbeatMessage" : "Connection refused",
            "configVersion" : -1
        },
        {
            "_id" : 2,
            "name" : "172.19.0.4:27017",
            "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("2017-09-04T01:45:02.310Z"),
            "lastHeartbeatRecv" : ISODate("1970-01-01T00:00:00Z"),
            "pingMs" : NumberLong(0),
            "lastHeartbeatMessage" : "Connection refused",
            "configVersion" : -1
        }
    ],
    "ok" : 1
}

Parece que as duas primeiras instâncias foram removidas e o terceiro servidor de configuração é secundário. Com base no meu entendimento, se houver um desligamento de instância em uma réplica, outra instância íntegra deverá ser selecionada para se tornar primária. Por que a terceira instância não se tornou primária em minha réplica?

Todas as instâncias do mongo estão usando a versão 3.4.4.

Abaixo está o comando que usei para iniciar o servidor de configuração do mongod:

mongod --replSet cnf-serv --rest --configsvr --port 27017 --oplogSize 16 --noprealloc --smallfiles

FYI, no primeiro log de duas instâncias, vejo a mensagem de erro abaixo:

2017-09-04T01:39:23.006+0000 I SHARDING [shard registry reload] Periodic reload of shard registry failed  :: caused by :: 134 could not get updated shard list from config server due to Read concern majority reads are currently not possible.; will retry after 30s
2017-09-04T01:39:53.006+0000 I SHARDING [shard registry reload] Periodic reload of shard registry failed  :: caused by :: 134 could not get updated shard list from config server due to Read concern majority reads are currently not possible.; will retry after 30s
2017-09-04T01:40:23.006+0000 I SHARDING [shard registry reload] Periodic reload of shard registry failed  :: caused by :: 134 could not get updated shard list from config server due to Read concern majority reads are currently not possible.; will retry after 30s
2017-09-04T01:40:53.006+0000 I SHARDING [shard registry reload] Periodic reload of shard registry failed  :: caused by :: 134 could not get updated shard list from config server due to Read concern majority reads are currently not possible.; will retry after 30s

Estou executando um comando de explicação em um cluster de fragmentos no shell do mongodb. stageNa saída , vejo que o primeiro inputStageé PROJECTION. Eu não entendo muito bem o que essa fase significa. E não consegui encontrá-lo no site mongodb. Existe uma definição para esta fase?

"winningPlan" : {
                        "stage" : "SUBPLAN",
                        "inputStage" : {
                            "stage" : "PROJECTION",
                            "transformBy" : {
                                "body" : 1,
                                "headers.Date" : 1
                            },
                            "inputStage" : {
                                "stage" : "SHARDING_FILTER",
                                "inputStage" : {
                                    "stage" : "FETCH",
                                    "inputStage" : {
                                        "stage" : "OR",
                                        "inputStages" : [
                                            {
                                                "stage" : "IXSCAN",
                                                "keyPattern" : {
                                                    "filename" : 1
                                                },
                                                "indexName" : "filename_1",
                                                "isMultiKey" : false,
                                                "multiKeyPaths" : {
                                                    "filename" : [ ]
                                                },
                                                "isUnique" : false,
                                                "isSparse" : false,
                                                "isPartial" : false,
                                                "indexVersion" : 2,
                                                "direction" : "forward",
                                                "indexBounds" : {
                                                    "filename" : [
                                                        "[\"1046\", \"1046\"]"
                                                    ]
                                                }
                                            },
                                            {
                                                "stage" : "IXSCAN",
                                                "keyPattern" : {
                                                    "headers.From" : 1
                                                },
                                                "indexName" : "headers.From_1",
                                                "isMultiKey" : false,
                                                "multiKeyPaths" : {
                                                    "headers.From" : [ ]
                                                },
                                                "isUnique" : false,
                                                "isSparse" : false,
                                                "isPartial" : false,
                                                "indexVersion" : 2,
                                                "direction" : "forward",
                                                "indexBounds" : {
                                                    "headers.From" : [
                                                        "[\"[email protected]\", \"[email protected]\"]"
                                                    ]
                                                }
                                            }
                                        ]
                                    }
                                }
                            }
                        }
                    },
                    "rejectedPlans" : [ ]
                }

O comando de consulta que usei é:

db.testmsg.find(
{
  $or: [ { "filename": "1046"}, {"headers.From":"[email protected]"}]
},{
  "body": 1, "headers.Date": 1
  }).explain();

Configurei um cluster de fragmentos, mas há alguns erros na réplica do servidor de configuração. Abaixo está meu status de réplica do servidor de configuração:

cnf-serv:SECONDARY> rs.status()
{
    "set" : "cnf-serv",
    "date" : ISODate("2017-08-21T01:28:00.926Z"),
    "myState" : 2,
    "term" : NumberLong(1),
    "configsvr" : true,
    "heartbeatIntervalMillis" : NumberLong(2000),
    "optimes" : {
        "lastCommittedOpTime" : {
            "ts" : Timestamp(0, 0),
            "t" : NumberLong(-1)
        },
        "appliedOpTime" : {
            "ts" : Timestamp(1502320369, 1),
            "t" : NumberLong(1)
        },
        "durableOpTime" : {
            "ts" : Timestamp(1502320369, 1),
            "t" : NumberLong(1)
        }
    },
    "members" : [
        {
            "_id" : 0,
            "name" : "172.19.0.13:27017",
            "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("2017-08-21T01:28:00.831Z"),
            "lastHeartbeatRecv" : ISODate("1970-01-01T00:00:00Z"),
            "pingMs" : NumberLong(0),
            "lastHeartbeatMessage" : "Connection refused",
            "configVersion" : -1
        },
        {
            "_id" : 1,
            "name" : "172.19.0.4:27017",
            "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("2017-08-21T01:28:00.831Z"),
            "lastHeartbeatRecv" : ISODate("1970-01-01T00:00:00Z"),
            "pingMs" : NumberLong(0),
            "lastHeartbeatMessage" : "Connection refused",
            "configVersion" : -1
        },
        {
            "_id" : 2,
            "name" : "172.19.0.7:27017",
            "health" : 1,
            "state" : 2,
            "stateStr" : "SECONDARY",
            "uptime" : 119601,
            "optime" : {
                "ts" : Timestamp(1502320369, 1),
                "t" : NumberLong(1)
            },
            "optimeDate" : ISODate("2017-08-09T23:12:49Z"),
            "configVersion" : 185982,
            "self" : true
        }
    ],
    "ok" : 1
}

Eu posso ver no comando acima que dois membros de réplica não são alcançáveis ​​e o único membro alcançável é um secundário. Portanto, preciso tornar o membro secundário primário para que a réplica de configuração funcione. Eu tentei abaixo do comando no secundário, mas não funciona:

cnf-serv:SECONDARY> rs.slaveOk()
cnf-serv:SECONDARY> var cfg = rs.config();
cnf-serv:SECONDARY> cfg.members[0].priority=0.5
0.5
cnf-serv:SECONDARY> cfg.members[1].priority=0.5
0.5
cnf-serv:SECONDARY> cfg.members[2].priority=1
1
cnf-serv:SECONDARY> rs.reconfig(cfg, {force: true})
{ "ok" : 1 }

depois de fazer essa alteração, o secundário ainda é secundário. Não se tornou o principal. Como posso corrigir esse problema de conjunto de réplicas?

Eu tenho um despejo de dados muito grande (18 GB) precisa restaurar. Eu tentei usar mongorestorepara restaurar os dados para um conjunto de réplicas. Mas o processo de restauração foi cancelado por causa do error restoring from orders.bson: insertion error: not master. Eu acho que isso é porque o mestre é alterado no conjunto de réplicas. Existe uma maneira de restaurar os dados e parar de alterar o primário nas funções do conjunto de réplicas?

Eu configurei um conjunto de réplicas e quero adicioná-lo em um mongos. Mas eu tenho o erro abaixo no mongos:

mongos> sh.addShard("rs3/172.19.0.12:27017,172.19.0.6:27017,172.19.0.5:27017")
{
    "code" : 11000,
    "ok" : 0,
    "errmsg" : "E11000 duplicate key error collection: admin.system.version index: _id_ dup key: { : \"shardIdentity\" }"
}

da mensagem acima, ele diz que admin.system.versiontem erro de chave duplicada. A coleção admin.system.versiondeve ser definida pelo mongodb. Eu não entendo porque ele tem uma chave duplicada.

Todas as instâncias do mongo são da versão 3.4.4.

Abaixo está o status do conjunto de réplicas:

rs3:PRIMARY> rs.status()
{
    "set" : "rs3",
    "date" : ISODate("2017-07-09T02:13:37.146Z"),
    "myState" : 1,
    "term" : NumberLong(10),
    "heartbeatIntervalMillis" : NumberLong(2000),
    "optimes" : {
        "lastCommittedOpTime" : {
            "ts" : Timestamp(0, 0),
            "t" : NumberLong(-1)
        },
        "appliedOpTime" : {
            "ts" : Timestamp(1499566407, 1),
            "t" : NumberLong(10)
        },
        "durableOpTime" : {
            "ts" : Timestamp(1499563905, 1),
            "t" : NumberLong(9)
        }
    },
    "members" : [
        {
            "_id" : 0,
            "name" : "172.19.0.12:27017",
            "health" : 1,
            "state" : 1,
            "stateStr" : "PRIMARY",
            "uptime" : 2493,
            "optime" : {
                "ts" : Timestamp(1499566407, 1),
                "t" : NumberLong(10)
            },
            "optimeDate" : ISODate("2017-07-09T02:13:27Z"),
            "electionTime" : Timestamp(1499563936, 1),
            "electionDate" : ISODate("2017-07-09T01:32:16Z"),
            "configVersion" : 414750,
            "self" : true
        },
        {
            "_id" : 1,
            "name" : "172.19.0.5:27017",
            "health" : 1,
            "state" : 2,
            "stateStr" : "SECONDARY",
            "uptime" : 1403,
            "optime" : {
                "ts" : Timestamp(1499566407, 1),
                "t" : NumberLong(10)
            },
            "optimeDurable" : {
                "ts" : Timestamp(1499563905, 1),
                "t" : NumberLong(9)
            },
            "optimeDate" : ISODate("2017-07-09T02:13:27Z"),
            "optimeDurableDate" : ISODate("2017-07-09T01:31:45Z"),
            "lastHeartbeat" : ISODate("2017-07-09T02:13:35.870Z"),
            "lastHeartbeatRecv" : ISODate("2017-07-09T02:13:35.854Z"),
            "pingMs" : NumberLong(0),
            "syncingTo" : "172.19.0.12:27017",
            "configVersion" : 414750
        },
        {
            "_id" : 2,
            "name" : "172.19.0.6:27017",
            "health" : 1,
            "state" : 3,
            "stateStr" : "RECOVERING",
            "uptime" : 2487,
            "optime" : {
                "ts" : Timestamp(1499070510, 1000),
                "t" : NumberLong(3)
            },
            "optimeDurable" : {
                "ts" : Timestamp(1499070510, 1000),
                "t" : NumberLong(3)
            },
            "optimeDate" : ISODate("2017-07-03T08:28:30Z"),
            "optimeDurableDate" : ISODate("2017-07-03T08:28:30Z"),
            "lastHeartbeat" : ISODate("2017-07-09T02:13:35.865Z"),
            "lastHeartbeatRecv" : ISODate("2017-07-09T02:13:36.965Z"),
            "pingMs" : NumberLong(0),
            "configVersion" : 414750
        }
    ],
    "ok" : 1
}