False failovers on heavy CPU bound loads
Текущая реализация failover плохо работает при CPU bound нагрузке. Однако это произошло не столько из-за недостатков алгоритма, а из-за однопоточной природы Picodata. Но однопоточная природа - это половина беды. Вторая половина беды - это то, что у нас нет детерминированных критериев времени прокрутки евент лупа. Проще сказать - неочевидно, что плохо, а что хорошо: условный while true - плохо, а долгий запрос в таблицу - да можно и потерпеть.
При текущей реализации sentinel ходит по нодам и пингует их через rpc. Ответ на этот rpc формируется так же как и раньше в TX треде, сохраняя для нас весь спектр проблем, что был.
Что предлагается: у нас есть конечное число кейсов, которые мы считаем ложно положительными, при которых готовы потерпеть. Большая часть этих кейсов лежит в месте взаимодействия с базой данных. Поэтому надо отвечать на пинги не из TX треда, а из соседнего. Для того, что бы этот тред понимал, что вообще происходит в TX треде, надо из него на каждом шаге евент лупа выставлять флаг в шаред мемори с типом последней операции и её таймстемпом или инкрементальным счётчиком. Таким образом тред сможет:
- вообще системно определить вращался ли евент луп, а не попасть на два пика подряд
- понять чем евентлуп занимается последнее время Если на эти события навесить веса, то можно реагировать на действительные отказы лупа, а долгие селекты терпеть.
Как развитие фичи можно дать пользователю какой-то апи и конфигурацию, что бы взводить свои флаги на какие-то свои действия.
Предложение преследует следующие цели:
- Сделать проверку живости евент-лупа асинхронной, так как нас на деле не интересует доступность евент-лупа в указанный момент времени или даже какой-то промежуток тайм-аута в 1-5с. Нас интересует ретроспективная оценка по какому-то более длинному интервалу времени. Так же практика показала, что не любое залипание - это плохо. Эта плохость всё таки имеет разную цену.
- Мы когда-то сделали предположение, что вращение евент-лупа является критерием живости узла. Но оно слишком флаки. При этом основной наш положительный кейс переключений фейловером - это не залипание евент лупа, а отказ инстанса или тачки под ним. А если уж подходить совсем формально, то это отказ в рамках различных тестов.
Поэтому также предлагается сделать отвечающий тред высокодоступным, что бы он не отвечал на запрос губернатора только в случае полного отказа. А что отвечать получал из евент-лупа ретроспективно в нотации: "последний раз евент луп передал контекст в такой-то момент времени, такому-то коду". Такой механизм снизит ложноположительные переключения до минимума не затронув основной кейс переключения по отказу.