☰

MongoDB trocando frequentemente de primário

tag-icon • tag-icon vmware-esxi redhat mongodb
MongoDB trocando frequentemente de primário

Estamos executando um conjunto de réplicas do Mongo 2.6 com 3 membros: primário, secundário e árbitro. Quase todos os dias nosso MongoDB muda qual servidor é primário e isso faz com que todas as conexões com esse banco de dados sejam interrompidas. Seria perfeitamente normal se isso acontecesse porque um dos servidores realmente estava inativo. O desafio é que, em cada caso, parece que o servidor "inativo" não estava realmente inativo. Estava ativo o tempo todo.

Aqui está o que sabemos:

  1. O mongodprocesso em todos os três servidores não foi reiniciado ou caiu.
  2. Os servidores ainda reportavam à New Relic o tempo todo.
  3. No log do mongo, estamos vendo falhas frequentes de pulsação.
  4. Os servidores não estão sob uma carga muito alta em nenhum momento. Estou vendo um pico de CPU a cada hora, cerca de 10 minutos após a hora, mas isso não se alinha perfeitamente com as falhas.

A seguir está o resultado do show log rswhile inserido no primário atual.

2015-05-17T15:05:49.339+0000 [rsBackgroundSync] replSet sync source problem: 10278 dbclient error communicating with server: server1:27017
2015-05-17T15:05:49.358+0000 [rsBackgroundSync] replSet syncing to: server1:27017
2015-05-17T15:05:56.444+0000 [rsBackgroundSync] replset setting syncSourceFeedback to server1:27017
2015-05-17T22:11:36.638+0000 [rsHealthPoll] replSet info server1:27017 is down (or slow to respond):
2015-05-17T22:11:36.644+0000 [rsHealthPoll] replSet member server1:27017 is now in state DOWN
2015-05-17T22:11:37.495+0000 [rsMgr] not electing self, we are not freshest
2015-05-17T22:11:38.656+0000 [rsHealthPoll] replSet member server1:27017 is up
2015-05-17T22:11:38.656+0000 [rsHealthPoll] replSet member server1:27017 is now in state PRIMARY
2015-05-17T22:11:39.140+0000 [rsBackgroundSync] replSet syncing to: server1:27017
2015-05-17T22:11:39.147+0000 [rsBackgroundSync] replset setting syncSourceFeedback to server1:27017
2015-05-17T23:05:47.431+0000 [rsBackgroundSync] replSet sync source problem: 10278 dbclient error communicating with server: server1:27017
2015-05-17T23:05:47.431+0000 [rsBackgroundSync] replSet syncing to: server1:27017
2015-05-17T23:05:47.876+0000 [rsBackgroundSync] replset setting syncSourceFeedback to server1:27017
2015-05-18T10:05:46.821+0000 [rsBackgroundSync] replSet sync source problem: 10278 dbclient error communicating with server: server1:27017
2015-05-18T10:05:46.822+0000 [rsBackgroundSync] replSet syncing to: server1:27017
2015-05-18T10:05:51.014+0000 [rsBackgroundSync] replset setting syncSourceFeedback to server1:27017
2015-05-18T22:12:11.433+0000 [rsHealthPoll] replSet info server1:27017 is down (or slow to respond):
2015-05-18T22:12:11.434+0000 [rsHealthPoll] replSet member server1:27017 is now in state DOWN
2015-05-18T22:12:11.507+0000 [rsMgr] replSet info electSelf 3
2015-05-18T22:12:14.708+0000 [rsMgr] replSet PRIMARY
2015-05-18T22:12:14.709+0000 [rsHealthPoll] replSet member server1:27017 is up
2015-05-18T22:12:14.709+0000 [rsHealthPoll] replSet member server1:27017 is now in state PRIMARY
2015-05-18T22:12:21.610+0000 [rsHealthPoll] replSet member server1:27017 is now in state ROLLBACK
2015-05-18T22:12:23.612+0000 [rsHealthPoll] replSet member server1:27017 is now in state SECONDARY
2015-05-19T22:13:13.004+0000 [rsHealthPoll] couldn't connect to server1:27017: couldn't connect to server server1:27017 (x.x.x.x), connection attempt failed
2015-05-19T22:13:24.127+0000 [rsHealthPoll] couldn't connect to server1:27017: couldn't connect to server server1:27017 (x.x.x.x) failed, connection attempt failed
2015-05-19T22:13:29.267+0000 [rsHealthPoll] replset info server1:27017 just heartbeated us, but our heartbeat failed: , not changing state
2015-05-20T22:14:35.832+0000 [rsHealthPoll] replset info server1:27017 just heartbeated us, but our heartbeat failed: , not changing state

Você pode ver que estamos recebendo falhas frequentes de pulsação e notificações de inatividade, mas em cada caso o servidor iria de inativo para backup em segundos a cada vez. Não tenho certeza de onde começar a procurar para tentar descobrir o que pode estar causando o problema.

Responder1

Vejo isso com frequência e está sempre fora do mongodprocesso. Problemas mongodde resolução de DNS, problemas de pilha TCP/IP, links de rede, hardware físico, etc. Verifique os erros de rede no sistema operacional host, verifique os links físicos (se o físico estiver na equação), verifique o seu provedor de nuvem entre os dois servidores se você estiver abrangendo regiões. Muito provavelmente, isso é algo no sistema operacional host e não tem nada a ver com o próprio MongoDB.

Responder2

Isso foi resolvido. O principal problema era que nosso provedor de hospedagem estava executando snapshots VMWare como mecanismo de backup. Esses instantâneos estavam fazendo com que a VM entrasse temporariamente em um período de estagnação. Acredito que o termo técnico seja que a VM seja desativada.

Depois que esses instantâneos foram desativados, não tivemos mais problemas.

informação relacionada