@Sergepetrenko Какой шанс на успех, по вашим оценкам на то, что

если добиться follow на всех 2.8 нодах(держится гдето минуту) и на всех оставшихся 4-х 1.10 обновить до 2.8 и рестартануть ноды, что репликация больше не будет спотыкаться?

Главное уже поднимать со снапшота всех сразу на 2.8, чтобы не получилось такой же ситуации как сейчас

Продолжаем войну с репликой. 1) Обновить в лоб все и рестартануть - не вышло. После 1,5 минут follow репликация встала; 2) Взяли эталонный снашот, остальные очистили. Присоединили 1 ноду к реплике(всего стало 2), все хорошо. Но как только добавили еще 1(стало 3), эта последняя присоединенная нода остановила репликацию, при этом первые 2 продолжили нормально работать follow; 3) Собрали вообще пустой репликасет из 11 нод. Все 11 follow. Залили данные. Все хорошо, реплика держится. Добавили 12 пустую ноду. Все хорошо, реплика идет. Но стоило добавить 13 пустую ноду, как все повторилось. Те же ошибки и реплика встала. Вот что в логах ТТ: box.cc:508 E> XlogError: found a first global row in a transaction with LSN/TSN mismatch main/116/applier/user@x.x.x.x:3001 applier.cc:689 E> ER_PROTOCOL: Transaction id must be equal to LSN of the first row in the transaction. main/103/node_3001 C> failed to synchronize with 11 out of 12 replicas По итогу имеем, что на 2.8.4 одна реплика не хочет разворачиваться с нашими данными и сейчас из 13 нод, 12 видят только одну ноду а с остальными нет синхронизации

Если вкратце, в 2.2 (или около того) появились границы транзакций. До 2.2 репликация работала так: приняли одну строку - применили соответствующую операцию. То есть мастер выполнял набор операций транзакционно, а реплика - построчно. Начиная же с 2.2 отдельные строки, приходящие в репликационном потоке, на реплике собираются обратно в транзакции перед применением. Соответственно транзакция, пришедшая по репликации либо применяется целиком, либо не применяется. Эти "границы транзакций" - это по сути дополнительные поля в каждой строке. 1.10 не знает про эти дополнительные поля, поэтому при чтении их игнорирует, а значит у себя применяет приходящие транзакции как раньше. Построчно. Теперь, в целом когда реплики соединены в full mesh, обычно транзакции каждого из узлов попадают на реплику прямо от этого узла. Но вполне возможно, что в какой-то момент промежуточная нода пришлёт транзакции мастера реплике быстрее, чем это сделает сам мастер. Это нормально, реплика точно так же их применит. Интересная ситуация возникает, когда у вас часть нод — 1.10, а часть 2.х Представим, что есть две ноды 2.х и одна 1.10. Соединены все со всеми. Для простоты будем считать, что одна из 2.х — мастер, а остальные — реплики. Репликация от мастера идёт к реплике напрямую (2.х -> 2.х), и применяется транзакционно. Параллельно тот же поток идёт через 3-ю ноду (2.х -> 1.10 -> 2.x). В одном потоке репликация транзакционная, в другом — построчная (поскольку 1.10 принимает транзакционный поток, но не умеет с ним работать, и превращает его в обычный построчный). На реплике постоянно переключаются файберы, читающие потоки: первый дочитал всё, что пришло в сокет — даёт почитать второму. И обратно. В момент очередного переключения с построчного потока на транзакционный, оказывается, что мы прочитали и применили первую строку очередной транзакции. А теперь должны применить оставшуюся её часть. Первая строка уже записана в журнал как самостоятельная транзакция, а то, что пришло через транзакционный поток — попадает в журнал как "транзакция без головы". Дальше при попытке подключить ещё одну реплику к нашей реплике мы получим ошибку ER_PROTOCOL: Transaction id must be equal to LSN of the first row in the transaction. А при попытке перезапустить нашу реплику — XlogError: found a first global row in a transaction with LSN/TSN mismatch Обе ошибки про одно и то же: наткнулись в потоке на "хвост" транзакции, но не видели "голову". Надеюсь, понятно. Теперь про XlogError: found a first global row in a transaction with LSN/TSN mismatch — такое было возможно на 2.8.3 и без нод 1.10 в кластере: там нужно было в триггере на вставку в один спейс вставлять что-то в другой спейс, и при этом делать вставки из любого коннектора (не из хранимой процедуры). Это была деградация внутри одной версии. На 2.8.2 всё было хорошо, и в 2.8.3-1 и выше всё тоже хорошо/

Хорошо, но надеюсь больше не будет такого! Итак слишком много нервных клеток полегло😁 в процессе обновления

Я тоже надеюсь!

👍