Início / server / Perguntas / 951640
Accepted
Alex
Asked: 2019-01-31 23:40:28 +0800 CST

O mecanismo de armazenamento WiredTiger relata um grande número de reversões no MongoDB

  • 772

Temos um conjunto de replicação do MongoDB composto por três membros:

        "members" : [
                {
                        "_id" : 6,
                        "host" : "10.0.0.17:27017",
                        "arbiterOnly" : false,
                        "buildIndexes" : true,
                        "hidden" : false,
                        "priority" : 2,
                        "tags" : {
                        },
                        "slaveDelay" : NumberLong(0),
                        "votes" : 1
                },
                {
                        "_id" : 7,
                        "host" : "10.0.0.18:27017",
                        "arbiterOnly" : false,
                        "buildIndexes" : true,
                        "hidden" : false,
                        "priority" : 2,
                        "tags" : {
                        },
                        "slaveDelay" : NumberLong(0),
                        "votes" : 1
                },
                {
                        "_id" : 8,
                        "host" : "10.0.0.19:27017",
                        "arbiterOnly" : false,
                        "buildIndexes" : true,
                        "hidden" : false,
                        "priority" : 2,
                        "tags" : {
                        },
                        "slaveDelay" : NumberLong(0),
                        "votes" : 1
                }
        ],

O cluster está sob carga moderada, não mais do que algumas dezenas de solicitações por segundo. db.serverStatus()em um relatório principal que quase todas as transações são revertidas:

"transaction begins" : 2625009877,
"transaction checkpoint currently running" : 0,
"transaction checkpoint generation" : 22618,
"transaction checkpoint max time (msecs)" : 5849,
"transaction checkpoint min time (msecs)" : 153,
"transaction checkpoint most recent time (msecs)" : 1869,
"transaction checkpoint scrub dirty target" : 0,
"transaction checkpoint scrub time (msecs)" : 0,
"transaction checkpoint total time (msecs)" : 11017082,
"transaction checkpoints" : 22617,
"transaction checkpoints skipped because database was clean" : 0,
"transaction failures due to cache overflow" : 0,
"transaction fsync calls for checkpoint after allocating the transaction ID" : 22617,
"transaction fsync duration for checkpoint after allocating the transaction ID (usecs)" : 354402,
"transaction range of IDs currently pinned" : 0,
"transaction range of IDs currently pinned by a checkpoint" : 0,
"transaction range of IDs currently pinned by named snapshots" : 0,
"transaction range of timestamps currently pinned" : 8589934583,
"transaction range of timestamps pinned by the oldest timestamp" : 8589934583,
"transaction sync calls" : 0,
"transactions committed" : 30213144,
"transactions rolled back" : 2594972913,
"update conflicts" : 578

Gráfico de transações do Grafana

Basicamente, minhas perguntas são: O que está acontecendo aqui? É normal ter tantas transações e tantos rollbacks? Se não, qual é a causa raiz e quente para corrigi-lo?

Atualizado : Atualizamos para 3.6.8-2.0(este foi o pacote Percona mais recente na série 3.6) e o problema persistiu.

mongodb

1 respostas

  1. Best Answer

    Muitas das métricas db.serverStatus().wiredTigerpodem ser confusas, pois refletem as métricas e a terminologia subjacentes do mecanismo de armazenamento WiredTiger, em vez da API do MongoDB. Termos como transações , sessões e reversões têm um contexto diferente para internos de armazenamento do que os recursos do MongoDB do usuário final. Algumas das métricas expostas não são muito úteis para o monitoramento do usuário final, mas podem fornecer informações de diagnóstico para desenvolvedores familiarizados com a API de armazenamento subjacente.

    O que está acontecendo aqui?

    O mecanismo de armazenamento WiredTiger usa o Multiversion Concurrency Control (MVCC) para fornecer acesso simultâneo a threads internos que estão lendo e gravando dados. O servidor MongoDB possui uma camada de integração que implementa comandos expostos por meio da API do MongoDB (usada pelos drivers) usando a API do mecanismo de armazenamento subjacente.

    Na API do WiredTiger existem sessões e transações internas para que os threads internos possam trabalhar com um instantâneo consistente de dados. Uma transação interna pode terminar sendo confirmada (os dados foram gravados) ou revertida (transação abortada intencionalmente ou devido a um erro).

    É normal ter tantas transações e tantos rollbacks?

    Sim, isso é normal. As consultas somente leitura por meio da camada de integração do MongoDB usam a API de transação WiredTiger para leituras consistentes, mas como nunca têm dados para confirmar, as transações são abortadas intencionalmente e serão adicionadas à métrica "transações revertidas".

    A métrica "transações revertidas" também pode ser incrementada para outros casos de uso, como conflitos de gravação (atualizações internas simultâneas para o mesmo documento que serão repetidas de forma transparente).

    Se não, qual é a causa raiz e como corrigi-la?

    Essa métrica não deve ser um foco específico para preocupação ou monitoramento.

    • 2

relate perguntas