Persist _pico_replicaset.promotion_vclock

Данный тикет является частью #856 (closed) "Governor refactoring" (epic).

В репликасет необходимо добавить новое поле promotion_vclock — это vclock с которого current_master переходит в read_only=false. Новое поле используется для бережного переключения мастера в репликасете, а также для удаления реплики после неудачного аварийного переключения.

Поле должно изменяться атомарно вместе с current_master_id.

Концепт алгоритма:

Консистентное переключение (governor step ReplicasetMasterConsistentSwitchover)

• pool.call current_master_id box.cfg.read_only(true); return vclock1
• UPDATE _pico_replicaset SET current_master_id = ..., promotion_vclock = vclock1
• pool.call target_master_id proc_wait_vclock(vclock1); box.cfg.read_only(false)

Аварийное переключение (governor step ReplicasetMasterReplaceFailed)

• UPDATE _pico_replicaset SET target_master_id = ... // choose a new one
• pool.call target_master_id return vclock
• UPDATE _pico_replicaset SET current_master_id = ..., promotion_vclock = ... // data loss
• pool.call target_master_id box.cfg.read_only(false)

mentioned in issue #856 (closed)

marked this issue as related to #856 (closed)

Georgy Moshkin, [20/08/2024 19:02]

Консистентное переключение (governor step ReplicasetMasterConsistentSwitchover)

• pool.call current_master_id box.cfg.read_only(true); return vclock1
• UPDATE _pico_replicaset SET current_master_id = ..., promotion_vclock = vclock1
• pool.call target_master_id proc_wait_vclock(vclock1); box.cfg.read_only(false)

смотри, я понимаю, почему read_only=false, новый мастер должен делать в последний момент. Но тут возникает другая проблема: если губернатор умрёт между 2м и 3м шагом, то никто не скажет новому мастеру, что ему пора делать read_only=false

это конечно лучше альтернативы, когда у нас 2 реплики думают, что они мастер, но с другой стороны какой выход?

Поправочка:

-UPDATE _pico_replicaset SET current_master_id = ..., promotion_vclock = vclock1
+UPDATE _pico_replicaset SET current_master_id = ..., promotion_vclock = vclock1, target_replication_config_version += 1

Соответвенно pool.call target_master_id proc_wait_vclock(vclock1); box.cfg.read_only(false) — это часть шага SetupReplication (сейчас по коду просто Replication, но я предлагаю переименовать без лишнего шума)

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

Для поддержки консистентного переключения мастера придётся добавить какой-то признак того, что promotion_vclock уже обновлён, но смена мастера ещё не завершена.

• PrepareMasterSwitchover:
  • вызов proc_replication_demote -> vclock на старого мастера
  • сохранение promotion_vclock и признака, что он сохранён
• MasterSwitchover:
  • вызов proc_sync_and_promote на новом мастере
  • сохранение target_master_id = current_master_id, и target_replication_config_version += 1

assigned to @gmoshkin

changed milestone to %24.6 - Plugins and Tiers

mentioned in merge request !1230 (merged)

closed with merge request !1230 (merged)

changed milestone to %24.5 - Lowercase