Antonios's questions

Recentemente, notei que um parâmetro fromRouter" : true existe nas agregações do mongoDB. Pesquisei a documentação do MongoDB e pesquisei no Google, mas não encontrei nada sobre ele. Alguém pode explicar o que é esse parâmetro ou compartilhar algum recurso útil para ele ?

"op" : "command",
"ns" : "database_name.$cmd",
"command" : {
    "aggregate" : "collection",
    "pipeline" : [...erase them to make the post smaller...],
    "fromRouter" : true,
    "$queryOptions" : {
        "$readPreference" : {
            "mode" : "primary"
        }
    }
},
"ntoreturn" : 1,
"keyUpdates" : 0,
"numYield" : 440,
"lockStats" : {
    "timeLockedMicros" : {
        "r" : NumberLong(3106252),
        "w" : NumberLong(0)
    },
    "timeAcquiringMicros" : {
        "r" : NumberLong(5302577),
        "w" : NumberLong(6145)
    }
},

Existe alguma maneira de desabilitar o thread de exclusão de TTL no mongoDB?

Eu sei que você pode modificar o valor expireAfterSeconds do índice ttl para um número alto para impedir "tecnicamente" a exclusão de ttl, mas estou interessado em desabilitar o thread ttl completamente por algum tempo e ativá-lo mais tarde.

desde já, obrigado

Quando insiro dados em um cluster fragmentado mongo, ele mostra 2 atualizações nas primárias (verifique localhost:55030). Alguém sabe de onde vêm essas atualizações? Eu só faço inserções usando for (var i = 1; i <= 1000000; i++) { db.testData.insert( { x : i , y : (i+10)/2}, {z:2},{w :3} ) }

            insert  query update delete getmore command flushes mapped  vsize    res  faults  locked db idx miss %     qr|qw   ar|aw  netIn netOut  conn  set repl       time 
            localhost:55027     *0     *0     *0     *0       0     3|0       0  1.53g  5.58g   871m      0  test:0.0%          0       0|0     0|0   178b     4k     9 rs01  SEC   13:01:28 
            localhost:55028     *0     *0     *0     *0       0     5|0       0  1.53g  5.58g   872m      0  test:0.0%          0       0|0     0|0   452b     4k     9 rs01  SEC   13:01:28 
             localhost:55029        *0     *0     *0     *0       2     3|0       0  1.53g  5.62g   900m      0  test:0.0%          0       0|0     0|0   272b     4k    24 rs01  PRI   13:01:28 
             localhost:55030       427     *0      2     *0     807   801|0       0  1.28g  5.13g   548m     23 admin:0.9%          0       0|0     0|0   276k   239k    25 rs02  PRI   13:01:28 
             localhost:55031      *428     *0     *0     *0       0     1|0       0  1.28g  5.06g   501m     25 local:3.8%          0       0|0     0|0    62b     3k     9 rs02  SEC   13:01:28 
              localhost:55032     *429     *0     *0     *0       0     1|0       0  1.28g  5.06g   501m     25     .:3.4%          0       0|0     0|0    62b     3k     9 rs02  SEC   13:01:28 
               localhost:61027     423      0      0      0       0     424                 2.42g    16m      0                                            57k    24k     3       RTR   13:01:28 

Atualizei há 3 meses um cluster fragmentado mongoDB de 2.4.9 para 2.6.1. Não enfrentei nenhum problema com a atualização e meu cluster funcionando bem, mas ainda vejo o bloqueio inicial necessário para atualizar os metadados para v5 em meus servidores de configuração.

     "_id" : "configUpgrade",
    "process" : "pgdb2:27017:1399361525:1804289383",
    "state" : 0,
    "ts" : ObjectId("53688ff569fb6f34e9a2d398"),
    "when" : ISODate("2014-05-06T07:32:05.343Z"),
    "who" : "pgdb2:27017:1399361525:1804289383:mongosMain:846930886",
    "why" : "upgrading config database to new format v5"

Alguém sabe se isso é um bug ou se afetará qualquer operação futura?

Estou executando o mongo 2.6.1 em um cluster de 3 estilhaços.

A configuração é: 3 nós de dados e 2 árbitros.

O único nó de dados é ocultado e atrasado por 3 horas (slavedelay).

Ocultei o nó para iniciar/parar durante o backup e o atraso de 3 horas é para segurança durante novas implantações.

O problema que estou enfrentando é: durante o fim de semana não há operações de gravação no cluster (essa é a natureza do aplicativo). Na manhã de segunda-feira, quando as gravações começam, o sistema de monitoramento informa que o nó de dados atrasado está atrasado há mais de 40 horas.

Eu acho que é porque o oplog que não tem registros durante o fim de semana e quando chega um registro na segunda-feira, precisa de 3 horas para chegar ao escravo atrasado.

Por favor, compartilhe sua opinião sobre o assunto, meus pensamentos estão corretos aqui ou devo verificar em uma direção diferente?