netology-devops/src/homework/06-database/6.6

Выполнение домашнего задания по теме "6.6. Troubleshooting".

Q/A

Задача 1

Перед выполнением задания ознакомьтесь с документацией по администрированию MongoDB.

Пользователь (разработчик) написал в канал поддержки, что у него уже 3 минуты происходит CRUD операция в MongoDB и её нужно прервать.

Вы как инженер поддержки решили произвести данную операцию:

• напишите список операций, которые вы будете производить для остановки запроса пользователя
• предложите вариант решения проблемы с долгими (зависающими) запросами в MongoDB

Первым шагом будет найти операцию, которую необходимо остановить. Для этого необходимо выполнить запрос на получение всех операций в определённой БД, которые выполняются дольше 3 минут (180 секунд):

db.currentOp(
   {
     "active" : true,
     "secs_running" : { "$gt" : 180 },
     "ns" : /^db1\./
   }
)

В полученном массиве нужно найти нужную операцию и взять её opid. Затем полученный параметр подставить в команду:

db.killOp(opid)

Самый оптимальный вариант решения проблемы: добавить ограничение на длительность выполняемого запроса. Это можно настроить непосредственно для каждого запроса/операции, указав либо ключ maxTimeMS, либо вызвав метод maxTimeMS(), в зависимости от контекста. А затем уже необходимо настраивать мониторинг, чтобы понять, почему конкретно операции выполняются долго.

Задача 2

Перед выполнением задания познакомьтесь с документацией по Redis latency troobleshooting.

Вы запустили инстанс Redis для использования совместно с сервисом, который использует механизм TTL. Причем отношение количества записанных key-value значений к количеству истёкших значений есть величина постоянная и увеличивается пропорционально количеству реплик сервиса.

При масштабировании сервиса до N реплик вы увидели, что:

• сначала рост отношения записанных значений к истекшим
• Redis блокирует операции записи

Как вы думаете, в чем может быть проблема?

Данная ситуация, скорее всего связана с проблемой, описанной в параграфе Latency generated by expires документации redis. Если кратко, то большое количество ключей, чьё время жизни истекает в одно время могут привести к тому, что redis заблокирует доступ для произведения очистки.

По умолчанию redis настроен на удаление 200 истёкших ключей в секунду. При этом алгоритм адаптивный и будет зацикливаться, если обнаружит, что более 25% процентов ключей уже истекли. Изначальное значение можно увеличить через конфигурацию ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP.

Задача 3

Перед выполнением задания познакомьтесь с документацией по Common Mysql errors.

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

InterfaceError: (InterfaceError) 2013: Lost connection to MySQL server during query u'SELECT..... '

Как вы думаете, почему это начало происходить и как локализовать проблему?

Какие пути решения данной проблемы вы можете предложить?

Данная проблема, скорее всего, происходит по причине, что по запросу выбирается очень большое количество строк (исчисляется миллионами). Варианты решения проблемы:

• Переписать запрос на выборку результатов, добавив какие-либо ограничения (например, limit);
• Увеличить значение net_read_timeout со значения по умолчанию до 60 секунд или больше.

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

Задача 4

Перед выполнением задания ознакомьтесь со статьей Common PostgreSQL errors из блога Percona.

Вы решили перевести гис-систему из задачи 3 на PostgreSQL, так как прочитали в документации, что эта СУБД работает с большим объемом данных лучше, чем MySQL.

После запуска пользователи начали жаловаться, что СУБД время от времени становится недоступной. В dmesg вы видите, что:

postmaster invoked oom-killer

Как вы думаете, что происходит?

Как бы вы решили данную проблему?

Данная проблема возникает из-за недостатка оперативной памяти. OOM Killer - это компонент ядра Linux, призванный решать проблему недостатка памяти. Таким образом, если настроен OOM Killer, то он будет "убивать" процессы, если ОС недостаточно RAM (включая swap).

В таком случае есть несколько вариантов решения:

1. Ограничить количество потребляемой оперативной памяти инстансом БД. Например, следуя следующим рекомендациям.
2. Увеличить количество оперативной памяти для машины. Данный способ, скорее всего, будет являться временным, так как с увеличением количества данных будет увеличиваться и количество потребляемой оперативной памяти.