Мы запускаем набор реплик Mongo 2.6 с 3 участниками: первичным, вторичным и арбитром. Почти каждый день наша MongoDB переключает сервер, который является основным, и это приводит к прерыванию всех подключений к этой БД. Было бы прекрасно, если бы он делал это из-за того, что один из серверов действительно не работал, проблема в том, что в каждом случае кажется, что «неработающий» сервер на самом деле не отключился. Это было все время.
Вот что мы знаем:
mongod
процесс на всех 3-х серверах не перезагружался и не падал.Следующее - результат 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
Вы можете видеть, что мы получаем частые сбои пульса и уведомления об отключении, но в каждом случае сервер будет каждый раз переходить от сбоя к резервному копированию за секунды. Я не совсем уверен, с чего начать искать дальше, чтобы попытаться выяснить, что может быть причиной проблемы.
Я вижу это часто, и это всегда за пределами mongod
обработать. Проблемы с преобразователем DNS, проблемы со стеком TCP / IP, сетевые ссылки, физическое оборудование и т. Д. Выбирайтесь из mongod
обработать. Проверьте сетевые ошибки в ОС вашего хоста, проверьте физические ссылки (если в уравнении есть физические), проверьте своего облачного провайдера между двумя серверами, если вы охватываете регионы. По всей вероятности, это что-то в ОС хоста и не имеет ничего общего с самой MongoDB.
Это было решено. Основная проблема заключалась в том, что наш хостинг-провайдер запускал моментальные снимки VMWare в качестве механизма резервного копирования. Эти снимки заставляли виртуальную машину временно переходить в период застоя, я считаю, что технический термин заключается в том, что виртуальная машина находится в состоянии покоя.
После того как эти снимки были отключены, у нас больше не было никаких проблем.