Вызывает ли это реальную проблему, когда я использую Raft, никогда не фиксирует записи журнала из предыдущих условий путем подсчета правила реплик в этой ситуации?

В настоящее время я сам реализую алгоритм консенсуса Raft и сталкиваюсь со следующей проблемой. Предположим, что имеется 4 узла (A, B, C и D), поэтому запись в журнале может быть зафиксирована более чем двумя голосами. Теперь мы запускаем кластер и выбираем лидера А с помощью term = 0. Затем происходит следующее:

1. Отсоединение ведомого B / D.
2. Лидер A создать LogEntry X.
3. Лидер A пытается реплицироваться на все узлы и в конечном итоге терпит неудачу, потому что только 2 узла (A и C).
4. Узел B повторно подключается и истекает время ожидания, он начинает выборы с новым term = 1.
5. Узел A потерял лидерство, потому что получил RequestVote RPC узла B.
6. Узел B не может победить на выборах, потому что у него нет LogEntry X. Итак, в кластере нет лидера.
7. Узел Тайм-аут и снова быть избранным лидером.
8. Лидер A успешно реплицирует LogEntry X в B.
9. # P2 #

   # P3 #

10. Предположим, что от клиента больше нет LogEntry для репликации, поэтому LogEntry X остается незафиксированным.

Мои вопросы:

1. Это настоящая проблема?
2. Есть ли какие-то решения для этого? Фактически, уже есть несколько сообщений о SoF, которые подчеркивают важность этого правила. И в этом сообщении мы, кажется, может создать копию Y из X и реплицировать Y. Работает ли это или, может быть, существует общее решение?