MongoDB Replica Set очень медленно работает, когда член становится недоступным

Question

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

Настройка:

• MongoDB2.0.1
• Реплика Устанавливает охват 5 серверов с одним предпочтительным приложением PHP
• с использованием основного драйвера PHP версии 1.2.6
• Одна коллекция с примерно 3 миллионами записей
• Для SlaveOkay установлено значение true для каждого соединения
• Строка подключения для MongoDB включает все пять серверов из набора реплик

Проблема:

Вчера один из вторичных серверов внезапно умер (аппаратный сбой) и стал полностью недоступен.С этого момента многим операциям чтения, выполняемым из драйвера PHP, потребовалось более 30 секунд для завершения (прежде чем это редко занимало 0,1 секунды).

• rs.status () явно сообщал, что отказавший вторичный сервербыл NOK и недоступен.
• все те же запросы, отправленные напрямую через консоль на первичный или любой вторичный сервер, были обработаны менее чем за 0,1 секунды (как и ожидалось)

В начале у менявзяла ссылку на отказавший вторичный объект из строки подключения в PHP, но это не дало никаких изменений в общей производительности.Только когда я сделал явное rs.remove (hostname_port) из набора реплик, производительность вернулась к нормальной.

Я полагаю, это не ожидаемое поведение?Можем ли мы защитить себя от чего-то подобного в будущем?

Answer 1

По крайней мере, одна значительная ошибка связана с наборами реплик с драйвером php V1.2.6. Вы можете обновить драйвер до новой версии?

Answer 2

У меня тоже недавно была такая же проблема.

Решение состоит в том, чтобы установить параметр монго " timeout " в php.

Однако причина в другом - когда один из серверов mongodb не работает, другой компьютер Linux пытается установить TCP-соединение с недоступным экземпляром mongo.ОС будет отправлять несколько пакетов SYN с использованием предварительно определенных интервалов, пытаясь установить соединение.Вы можете увидеть количество повторов по "cat / proc / sys / net / ipv4 / tcp_syn_retries " (см. Подробнее на http://www.sekuda.com/overriding_the_default_linux_kernel_20_second_tcp_socket_connect_timeout). Соответственно без монго " timeout"приложению php придется подождать" время попытки подключения к ОС ", что значительно увеличивает время загрузки.
Если tcp_sync_retreis слишком велико, PHP может достичь значения по умолчанию" timeout "mongo (равногоPHP default_socket_timeout) до того, как ОС завершит попытку подключения. PHP отключит тайм-аут, и веб-сервер может вернуть ошибку 504 Gateway Timeout (в нашем случае это было с nginx & php-fpm).

Answer 3

У меня вчера была эта проблема

Сценарий: репликация PHP 5.4 + mongodb 2.4.8 с 3 серверами

Когда демон mongodb был недоступен, но сеть того же сервера Linux работала для приложения php проблем не было.

Когда сервер linux любого из трех серверов mongodb в репликационном сервере был недоступен, загрузка страницы длилась вечно, очень медленно для php .

Я пришел к выводу, что это не было связано с mongodb, это была проблема сети .

Итак, я только что установил параметр timeout в хэше параметров соединения с репликацией, например:

$options = [
    "replicaSet"     => $_ENV['MONGODB_REPLICA'], 
    "readPreference" => \MongoClient::RP_SECONDARY_PREFERRED,
    "timeout"        => 1000
];
self::$mongoClient = new \MongoClient($_ENV['MONGODB_URI'], $options);

И это решение устранило проблему для меня. Я надеюсь, что это может помочь вам, ребята.

Answer 4

Вы решили эту проблему?

У нас что-то похожее, и, похоже, оно связано с порядком узлов в строке соединения.

Если ваш отключенный сервер находится первым в строке подключения, драйвер PHP будет ожидать истечения времени ожидания попытки подключения, прежде чем пытаться использовать второй сервер и так далее. Если для вашего тайм-аута по умолчанию установлено значение 20 секунд, это приводит к огромной задержке.

У нас пока нет решения.