Automatic peer availability detection

Currently grade Offline for an instance is only set in response to a proc_update_peer rpc request, which is only sent from the on_shutdown trigger. So basically only the best-case scenario is covered.

We need to implement an automated system which detects if an instance stops responding and sets it's grade to Offline (or something).

Related #211

changed milestone to %23.12.0

According to my own experience a lot of Cartridge cluster's catastrophes have the following scenario:

1. Event loop is stuck on master due to some reason (it could be background job / some unpredicted query / etc)
2. Cartridge healthchecks (membership lib to be exact) are performed in the same TX thread as any other user code
3. Due to stuck EV membership perceives node as dead, cause it is unable to handle healthcheck pings
4. Automatic failover happens
5. Node unstucks and return to cluster
6. Replication explodes (i can come up with several scenarios of replication failure here, but I will include one of post mortems later)
7. Replicaset in not RW

@rosik what do you think about implementing healthchecks in different (not TX) thread? What complications does it imply? What are the trade-offs?

added 1 deleted label

added 1 deleted label

План такой:

• Мы заводим файбер sentinel по аналогии с governor.
• Мы делаем хранимку .proc_healthcheck, с результатом Ok/Err.
• Сентинел работает на raft-лидере и дергает хелсчеки на всех инстансах.
• Если какой-то из инстансов перестает на них отвечать, сентинел пытается закоммитить target_grade: Failed для этого инстанса. Остальную работу по фейловеру проделает говернор.
• Политика реагирования настраивается глобальными опциями _pico_property sentinel_healthcheck_period и sentinel_failover_timeout

what do you think about implementing healthchecks in different (not TX) thread? What complications does it imply? What are the trade-offs?

@vifley см план выше. Все сводится к вопросу - считаем ли мы, что инстанс с залипшим TX тредом надо фейловерить? Мне кажется, что надо.

Теперь что касается tx треда.

Давай посмотрим какой путь проделывает netbox.call('.proc_healthcheck'), который делает сентинел:

При желании мы можем реализовать другие хелсчеки, например завернуть петельку в iproto треде. Или наоборот, дорисовать другие компоненты справа.

mentioned in issue #82 (closed)

marked this issue as related to #82 (closed)

В raft-rs уже есть direct failure detector. Его дожлно быть достаточно. Надо научиться подписываться на его статусы. свой пингер устраивать не нужно. В остальном всё ок.

Комментарий про залип tx треда: спастись от него можно только fencing. Мы fencing прорабатывали уже. Другие реплики должны дропать коннекты с залипшей реплики, чтобы, когда она отдуплит, она им не портила жизнь. это задача на ядро. Указание дропнуть коннекты будет отдавать говернор.

Фейл детектор из рафта нам не подходит. Он же на фолловерах мониторит лидера, а нам наоборот с лидера надо мониторить фолловеров. Есть конечно прогресс трекер фолловеров на лидере, но он кмк собой пинги не заменит, и таймауты на него навесить невозможно будет.

Он с лидера мониторит фолловеров тоже. Посмотри трафик tcp dump. Причём доставляется это в raft state machine, то есть в tx thread

Мне тоже кажется, что должен быть способ подписаться на результат хартбитов от лидера к репликам. Я не пользовался raft-rs и не знаю, есть ли у него расхождения с папирой рафта, но кмк хартбиты передаются через AppendEntries RPC, а значит, должен быть и ответ.

marked this issue as related to #297 (closed)

Результат хартбитов в рафт ноду попадает при вызове report_unreachable, который должен вызывать пользователь библиотеки явно. То есть мы должны вызывать, но пока не вызываем, а стоит, потому что в результате у нас рафт нода продлжает слать MsgAppend на отвалившиеся инстансы. Это не сложно исправить, на уровне ConnectionPool стоит перестать игнорировать сфейлившиеся отправки сообщений и, во-первых, оповещать о фейлах рафт ноду, во-вторых, гавернора, чтобы тот инстансам грейды менял. Можно конечно и добавить промежуточное звено между нодой и гавернором в виде файбера sentinel, но пока не понятно, какую он будет пользу нести

А как у нас вообще перевыборы лидера тогда работают? Только на демо? Ведь если рафт нода не видит что кто-то умер через report unreachable, она может затупить и не начать выборы...

Перевыборы не опираются на report_unreachable. Рафт нода сама начнёт голосование, если не получит хартбит от лидера на протяжении какого-то времени. То есть критерий начала выборов это отсутствие коммуникации от лидера. report_unreachable нужен, чтобы лидер перестал спамить в ноду, которая сдохла

assigned to @gmoshkin

mentioned in merge request !624 (merged)

added in-progress label