Почему paxos в прыжке репликации группы mysql готовят фазу？

Question

Я вижу такой сегмент кода в proposer_task(xcom_base.c)

if(threephase || ep->p->force_delivery){
    push_msg_3p(ep->site, ep->p, ep->prepare_msg, ep->msgno, normal);
}else{
    push_msg_2p(ep->site, ep->p);
}

threepahse является int const threephase = 0 а также force_delivery == 0 Вот

push_msg_eq это нормальные paxos включают подготовить, принять и изучить фазу

но push_msg_2p пропустит этап подготовки и отправит запрос на принятие

Я хочу знать почему, большое спасибо.

Answer 1

Если вы посмотрите на бумагу Paxos Made Simple, то в пункте 3 говорится:

Вновь выбранный лидер выполняет фазу 1 для бесконечного числа экземпляров алгоритма консенсуса [...]

Тогда параграф 4:

Поскольку отказ лидера и выбор нового должны быть редкими событиями, эффективная стоимость выполнения команды конечного автомата, то есть достижения консенсуса по команде / значению, - это стоимость выполнения только фазы 2 согласованного алгоритма., Можно показать, что фаза 2 алгоритма консенсуса Paxos имеет минимально возможную стоимость любого алгоритма для достижения соглашения при наличии ошибок. Следовательно, алгоритм Паксоса по существу оптимален.

Это говорит о том, что лидер только готовит во время восстановления после отказа лидера. После этого он принимает сообщения. Затем он имеет "оптимальный обмен сообщениями" в том смысле, что лидеру требуется только одна передача в оба конца, чтобы узнать, какое значение выбрано (сообщение о принятии и его подтверждение).

В кластере с тремя узлами лидер принимает сообщения самостоятельно, а затем для получения большинства требуется только одно подтверждение приема от второго узла. Затем он знает, что значение выбрано, не ожидая ответа от 3-го узла (который может быть недоступен). Это настолько эффективно, насколько вы можете получить. Известно, что значение принимается во втором узле с сильной согласованностью.

Учитывая то, как paxos работает для достижения максимальной эффективности, мы должны ожидать, что mysql xcom имеет режим, который пропускает фазу подготовки сообщения в устойчивом состоянии.

Вы можете прочитать больше о методах Paxos Made Simple в моем блоге здесь.

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