5 распространенных сценариев устранения неполадок MongoDB и быстрые исправления

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

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

1. Медленная производительность запросов

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

Диагностика: Использование explain()

Первый шаг в диагностике медленного запроса — понять, почему он медленный. Метод explain() в MongoDB — это важнейший инструмент для такого анализа. Он показывает план выполнения, детализируя, какие индексы были использованы (или не использованы).

Пример команды:

db.collection.find({ field: 'value' }).explain('executionStats')

Проанализируйте вывод, обращая особое внимание на:

• winningPlan.stage: Если стадия — COLLSCAN, MongoDB читает каждый документ. Это часто указывает на отсутствующий или непригодный для использования индекс.
• executionStats.nReturned в сравнении с executionStats.totalKeysExamined и executionStats.totalDocsExamined.

Быстрые исправления

1. Создайте правильный индекс: Если план запроса показывает сканирование коллекции, добавьте индекс, соответствующий шаблону фильтрации и сортировки. Например, если ваше приложение часто ищет заказы по user_id и самому новому timestamp, создайте составной индекс:

db.orders.createIndex({ user_id: 1, timestamp: -1 }) ``` 2. Уточните запрос: Проверьте, не получаете ли вы слишком много данных. Используйте проекцию, чтобы возвращать только те поля, которые действительно нужны странице или задаче. 3. Просмотрите журналы медленных запросов: Используйте профилировщик или журнал медленных запросов с порогом, соответствующим вашей рабочей нагрузке. Относитесь к любому точному порогу как к эксплуатационному выбору, а не универсальному правилу.

Совет: Индексы улучшают скорость чтения, но немного замедляют запись. Индексируйте только те поля, которые часто используются в предикатах запросов (find()), операциях сортировки (sort()) или запросах диапазона.

2. Задержка репликации в наборах реплик

Задержка репликации возникает, когда вторичные члены набора реплик значительно отстают от основного члена в применении операций из oplog (журнала операций).

Диагностика: Проверка replSetGetStatus

Используйте команду replSetGetStatus на любом члене набора реплик, чтобы проверить состояние здоровья и синхронизации всех членов.

Пример команды:

rs.printReplicationInfo()
// Или прямой запрос статуса:
rs.status()

Найдите optimeDate для основного и вторичных членов. Разница между optime основного и optime вторичного члена указывает на задержку, обычно отображаемую в поле secsBehind для каждого члена.

Быстрые исправления

1. Проверьте задержку в сети: Высокая задержка между членами может замедлить передачу oplog.
2. Проверьте отстающий вторичный член: Высокая загрузка ЦП, медленный ввод-вывод диска или рабочие нагрузки "шумных соседей" могут помешать вторичному члену применять записи достаточно быстро.
3. Проверьте покрытие oplog: Если задержка серьезная, вторичный член может больше не иметь необходимых записей oplog. В этом случае вам может потребоваться повторная синхронизация или перестроение этого члена.

3. Ошибки подключения и сбои аутентификации

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

Диагностика: Проверка журналов и сети

Сначала убедитесь, что сервер MongoDB прослушивает ожидаемый IP-адрес и порт. Проверьте журналы сервера MongoDB на наличие конкретных ошибок.

Распространенные ошибки в журналах:

• Address already in use: Другой процесс использует порт.
• Connection refused: Серверный процесс не работает, заблокирован или прослушивает другой порт.
• Authentication failed: Неверное имя пользователя, пароль, база данных аутентификации или назначение роли.

Быстрые исправления

1. Проверьте правила брандмауэра: Убедитесь, что порт MongoDB, часто 27017, доступен с хостов приложений.
2. Проверьте bindIp: Если в mongod.conf указана привязка только к 127.0.0.1, удаленные клиенты не смогут подключиться. По возможности привязывайтесь к конкретному частному интерфейсу. Избегайте 0.0.0.0, если только сетевые средства контроля и аутентификация уже не настроены.
3. Проверьте authSource: Если пользователь был создан в admin, строка подключения может нуждаться в ?authSource=admin.

4. Нехватка дискового пространства

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

Диагностика: Мониторинг и db.stats()

Используйте инструменты мониторинга ОС (df -h в Linux) для проверки общего использования диска. Внутри MongoDB используйте команду db.stats(), чтобы увидеть, сколько места потребляют отдельные базы данных.

Пример команды:

db.stats()

Обратите особое внимание на поля storageSize и dataSize.

Быстрые исправления

1. Выиграйте время, если запись не удается: Остановите неважные задания, удалите посторонние временные файлы или расширьте том, если ваша платформа это поддерживает.
2. Удалите неиспользуемые данные: Удаляйте старые коллекции или базы данных только после того, как убедитесь, что они больше не нужны и существуют резервные копии.
3. Выполняйте compact осторожно: Для коллекций с большим количеством удалений или обновлений compact может освободить зарезервированное место, но это может быть разрушительно. Проверьте влияние для вашей версии MongoDB и механизма хранения:

db.myCollection.runCommand({ compact: 'myCollection' }) ``` 4. Увеличьте емкость хранилища: Долгосрочное решение обычно заключается в увеличении дисков, улучшении правил хранения или отдельном хранилище для журналов и резервных копий.

Предупреждение: Если диск заполнится полностью, MongoDB прекратит запись, чтобы предотвратить повреждение данных. Вы должны решить проблемы с пространством, прежде чем пытаться возобновить нормальную работу.

5. Ошибки кластера шардирования (устаревшие маршрутизаторы/серверы конфигурации)

В шардированных средах проблемы с подключением или состоянием серверов конфигурации (config servers) или маршрутизаторов запросов (mongos instances) могут остановить всю систему.

Диагностика: Проверка состояния кластера

Команда sh.status(), выполненная на экземпляре mongos, является основным диагностическим инструментом для проверки состояния шардирования.

Пример действенной команды:

sh.status()

Ключевые области для проверки в выводе включают:

• Серверы конфигурации: Убедитесь, что набор реплик сервера конфигурации имеет работоспособное большинство.
• Шарды: Проверьте, что каждый перечисленный шард подключен и сообщает корректно.
• Устаревший статус: Ищите предупреждения о том, что маршрутизатор или шард имеют устаревшие метаданные.

Быстрые исправления

1. Перезапустите mongos при необходимости: Если один маршрутизатор устарел или не отвечает, его перезапуск может принудительно установить новое подключение к серверам конфигурации.
2. Сначала исправьте состояние сервера конфигурации: Если набор реплик сервера конфигурации не имеет работоспособного большинства, операции с метаданными шарда могут завершаться ошибкой.
3. Устраните проблемы на уровне шарда: Если шард не работает из-за нехватки дискового пространства или задержки репликации, сначала устраните эту первопричину, прежде чем искать симптомы маршрутизатора.

Когда обращаться к профессионалу

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

Вывод

Начинайте устранение неполадок MongoDB с симптома, наиболее близкого к влиянию на пользователя: медленная страница, неудачное подключение, остановленная запись, отстающий вторичный член или ошибка шардированного кластера. Затем используйте explain(), rs.status(), db.stats() и sh.status(), чтобы подтвердить причину, прежде чем изменять индексы, перезапускать маршрутизаторы или перестраивать члены.