add homewort 6.6: task 1

readme.md

@@ -29,3 +29,4 @@
 * [6.3. MySQL](/src/homework/06-database/6.3)
 * [6.4. PostgreSQL](/src/homework/06-database/6.4)
 * [6.5. Elasticsearch](/src/homework/06-database/6.5)
+* [6.6. Troubleshooting](/src/homework/06-database/6.6)

src/homework/06-database/6.6/readme.md

@@ -0,0 +1,87 @@
+Выполнение [домашнего задания](https://github.com/netology-code/virt-homeworks/blob/master/06-db-06-troobleshooting/README.md)
+по теме "6.6. Troubleshooting".
+
+## Q/A
+
+### Задача 1
+
+> Перед выполнением задания ознакомьтесь с документацией по [администрированию MongoDB](https://docs.mongodb.com/manual/administration/).
+> 
+> Пользователь (разработчик) написал в канал поддержки, что у него уже 3 минуты происходит CRUD операция в MongoDB и её
+> нужно прервать.
+> 
+> Вы как инженер поддержки решили произвести данную операцию:
+> - напишите список операций, которые вы будете производить для остановки запроса пользователя
+> - предложите вариант решения проблемы с долгими (зависающими) запросами в MongoDB
+
+Первым шагом будет найти операцию, которую необходимо остановить. Для этого необходимо выполнить запрос на получение всех операций
+в определённой БД, которые выполняются дольше 3 минут (180 секунд):
+
+```javascript
+db.currentOp(
+   {
+     "active" : true,
+     "secs_running" : { "$gt" : 180 },
+     "ns" : /^db1\./
+   }
+)
+```
+
+В полученном массиве нужно найти нужную операцию и взять её `opid`. Затем полученный параметр подставить в команду:
+
+```javascript
+db.killOp(opid)
+```
+
+Самый оптимальный вариант решения проблемы: добавить ограничение на длительность выполняемого запроса. 
+Это можно настроить непосредственно для каждого запроса/операции, указав либо ключ `maxTimeMS`, либо вызвав метод `maxTimeMS()`,
+в зависимости от контекста. А затем уже необходимо настраивать мониторинг, чтобы понять, почему конкретно операции выполняются долго.
+
+### Задача 2
+
+> Перед выполнением задания познакомьтесь с документацией по [Redis latency troobleshooting](https://redis.io/topics/latency).
+> 
+> Вы запустили инстанс Redis для использования совместно с сервисом, который использует механизм TTL.
+> Причем отношение количества записанных key-value значений к количеству истёкших значений есть величина постоянная и
+> увеличивается пропорционально количеству реплик сервиса.
+> 
+> При масштабировании сервиса до N реплик вы увидели, что:
+> - сначала рост отношения записанных значений к истекшим
+> - Redis блокирует операции записи
+> 
+> Как вы думаете, в чем может быть проблема?
+
+// todo
+
+### Задача 3
+
+> Перед выполнением задания познакомьтесь с документацией по [Common Mysql errors](https://dev.mysql.com/doc/refman/8.0/en/common-errors.html).
+> 
+> Вы подняли базу данных MySQL для использования в гис-системе. При росте количества записей, в таблицах базы,
+> пользователи начали жаловаться на ошибки вида:
+> ```python
+> InterfaceError: (InterfaceError) 2013: Lost connection to MySQL server during query u'SELECT..... '
+> ```
+> 
+> Как вы думаете, почему это начало происходить и как локализовать проблему?
+> 
+> Какие пути решения данной проблемы вы можете предложить?
+
+// todo
+
+### Задача 4
+
+> Перед выполнением задания ознакомьтесь со статьей [Common PostgreSQL errors](https://www.percona.com/blog/2020/06/05/10-common-postgresql-errors/) из блога Percona.
+> 
+> Вы решили перевести гис-систему из задачи 3 на PostgreSQL, так как прочитали в документации, что эта СУБД работает с
+> большим объемом данных лучше, чем MySQL.
+> 
+> После запуска пользователи начали жаловаться, что СУБД время от времени становится недоступной. В dmesg вы видите, что:
+> 
+> `postmaster invoked oom-killer`
+> 
+> Как вы думаете, что происходит?
+> 
+> Как бы вы решили данную проблему?
+
+// todo