Не только поэтому. Они будут просто его игнорировать. Даже асинхронные транзакции. Короче, данные с не-лидера на остальных не попадут.
Но ro старый лидер может и не стать

хорошо... а что при это будет в upstream status ?  и что делать тем кто пользовался wait lsn

Upstream status на остальных? Или на старом лидере?

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

там будет lsn не продвигаться

У него downstream lag будет расти. А ошибок не будет. Если он по апстриму соединён с остальными, то он от них новый терм получит и станет ro

чето как то странно ,  ошибок типа нет , но реплики не принимают wal  ,  че делать системе мониторинга?

Возможно сделаем посылку ошибки в ответ на данные от старого лидера. Звучит разумно

Не, там будет проблема, что будет развал репликации практически при любых перевыборах

А так можно смотреть на ту часть кластера, в которой есть лидер && самый большой терм. То есть старый лидер останется с термом 5, а все остальные будут в терме 6

Игнор сделан в одну сторону. Этот узел отставший от лидера все еще данные получает. И он увидит, что он не лидер

Если коннект есть, то узел увидит, что он не лидер. И либо станет фоловером, и будет работать нормально, либо будет ошибка, если у него уже накоммичено что-то несовместимое. Например, асинхронные транзакции

Если коннекта нет, то так и так будет ошибка в репликации видна

"Возможно стоит объединить параметры таймаутов,"  

что значит объединить?   они же точно должны быть разными,    время когда  фенсинг загасит rw   точно должно быть  меньше времени пока начнутся новые перевыборы,    


и что такое FENCING_PAUSE ?

Вечер добрый, подскажите пожалуйста, как можно ускорить или обратить внимание на созданную проблему? https://github.com/tarantool/memcached/issues/64

если интересно то напишу прям сюда, т.к. проблема носит очень высокий приоритет для меня, т.к. функциональность не правильная:

Здравствуйте.
Заметил, что не правильно реплицируются данные, добавленные в memcached при работе тарантула как master-master.
По логике самым приоритетным значением, которое должно иметь вес должно быть то, которое добавлено самое последнее по времени.
Пример:
имеем два сервера s1 и s2.
Оба сервера ОНЛАЙН.
Отключаем интернет на s2.
На s1 добавляем две переменные:
q1 = 11
q2 = 22
Отключаем интернет на s1.
Включаем интернет на s2.
На s2 добавляем переменную q1 = 12345
Включаем интернет на s1.
Сервера реплицируются.
Считываем переменные с обоих серверов
На s1:
q1 = 12345 (правильно)
q2 = 22
На s2:
q1 = 11 (НЕ правильно)
q2 = 22

Т.к. последним была добавлена переменная q1=12345 на s2, то это значение и должно реплицироваться на все сервера.
s1 сервер считал q1 значение с s2, но s2 счёл за приоритет значение из s1 сервера, а оно уже УСТАРЕВШЕЕ! Что не правильно по логике.
Я прав и логика репликации не верная или всё таки я не правильно рассуждаю?

конфиги выложил тут https://github.com/tarantool/memcached/issues/64

Включаем интернет на s2.
На s2 добавляем переменную q1 = 12345

между этими двумя строчками нету "Сервера реплицируются."

напишите себе тригерров beforereplace и выставляйте тапл в наиболее актуальный ,

1 - мы обсуждали возможность вытащить в апи только один из них, а второй сделать просто *2

пауза это период проверки кворума.

Включаем интернет на s2.
На s2 добавляем переменную q1 = 12345

Отключаем интернет на s1.
Включаем интернет на s2.

После того как отключить интернет на s1 - оба сервера будут в оффлайн. И они не смогут среплицироваться. Всё верно. Я воспроизвёл возможный вариант работы серверов, который был в моей практике.

1.  "просто *2"  -  это годное решение....

" период проверки кворума."  -    это время ведь тоже учитывается?      тоесть FAILOVER_TIMEOUT  >   FENCING_TIMEOUT  + FENCING_PAUSE  

или я както неправильно понял описание