MongoDB, часто переключающий основные устройства

Мы выполняем набор копии за 2,6 монго с 3 участниками: основной, вторичный, арбитр. Почти каждый день наш MongoDB переключается, какой сервер является основным, и это заставляет все соединения со что DB быть прерванными. Это прекрасно подошло бы, если бы это делало это, потому что один из серверов действительно снизился, проблема состоит в том, что в каждом случае кажется, как будто "вниз" сервер на самом деле не снизился. Это было все время.

Вот то, что мы знаем:

  1. mongod процесс на всех 3 серверах не перезапускал или понижался.
  2. Серверы все еще сообщали Новому Пережитку обо всем времени.
  3. От журнала монго мы видим частые отказы процесса биений.
  4. Серверы действительно не являются объектом очень высокой загрузки ни в какой точке. Я вижу пик нагрузки ЦП каждый час приблизительно 10 минут мимо часа, но это аккуратно не выстраивается в линию с отказами.

Следующее является результатом show log rs в то время как shell'd в к текущему основному устройству.

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

Вы видите, что мы получаем частые отказы процесса биений и вниз уведомления, но в каждом случае сервер пошел бы от вниз для резервного копирования в секундах каждый раз. Я не действительно уверен, где даже начать смотреть рядом с, пытаются выяснить то, что могло вызывать проблему.

2
задан 4 June 2015 в 19:15
2 ответа

Эта проблема устранена. Основная проблема заключалась в том, что наш хостинг-провайдер запускал моментальные снимки VMWare в качестве механизма резервного копирования. Эти снимки заставляли виртуальную машину временно переходить в период застоя, я полагаю, технический термин заключается в том, что виртуальная машина находится в состоянии покоя.

После того, как эти снимки были отключены, у нас больше не было никаких проблем.

0
ответ дан 3 December 2019 в 11:37

Я часто вижу это, и это всегда вне процесса mongod . Проблемы с преобразователем DNS, проблемы со стеком TCP / IP, сетевые ссылки, физическое оборудование и т. Д. Выбирайтесь из процесса mongod . Проверьте сетевые ошибки в ОС вашего хоста, проверьте физические ссылки (если в уравнении есть физические), проверьте своего облачного провайдера между двумя серверами, если вы охватываете регионы. По всей вероятности, это что-то в ОС хоста и не имеет ничего общего с самой MongoDB.

2
ответ дан 3 December 2019 в 11:37

Теги

Похожие вопросы