Есть очередь транзакций, ожидающих применения к целевой БД. Есть две возможности:

1) Ставить новую транзакцию в очередь только после того, как было подтверждено применение
предыдущей;
2) Не ожидать подтверждения и завивать очередь транзакциями по мере их получения.

В первом случае ошибка при применении транзакции остановит весь процесс, данные в БД будут
устаревшими, но гарантированно целостными (поскольку при следующем запуске репликации она
будет продолжена с того же места хотя, возможно, опять упадёт с той же ошибкой).

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

Какой из вариантов предпочтительнее с точки практического применения?

Сразу оговорюсь, что ключ конфигурации, управляющий поведением, возможен, но только как
крайнее средство.
Posted via ActualForum NNTP Server 1.5

Ivan_PisarevskyЕсли пришли к тому ч на истотчнике транзакция прошла, а на реплике обломалась (причем
повторно), то капец уже наступил и боржоми пить уже поздно.

И это нормально класть весь кластер одной (возможно, злодейски сформированной) транзакцией?
Posted via ActualForum NNTP Server 1.5

Гаджимурадов РустамА она многопоточная или однопоточная?

Пока не выявлено, что модуль Apply является узким местом - однопоточная.
Posted via ActualForum NNTP Server 1.5

Смотри: в очереди стоят транзакции 1,2,3,4. Транзакция 1 обломалась. Что делать?

Вариант 1: запротоколировать, забыть.
Вариант 2: поставить снова в очередь в надежде, что где-то в 2,3 или 4 придёт что-то,
устраняющее ошибку и транзакция 1 применится после 4 успешно.
Вариант 3: с шумом упасть, и больше ничего не делать.

Текущий реализованный вариант - номер 3 и Иван утверждает, что он - единственно правильный.
Posted via ActualForum NNTP Server 1.5

Ivan_PisarevskyЕсли ошибка с консистентностью данных, то главный вопрос: как она смогла отработать на
источнике?

Наитривиальнейший пример: на одной ноде добавили мастер-запись, отреплицировали на вторую,
там добавили деталь-запись, потом эти две транзакции пошли на третью, но вторая успела
чуть-чуть раньше.
Posted via ActualForum NNTP Server 1.5

Гаджимурадов РустамЭто как раз твой косяк - мог бы время/номера отслеживать.

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

Собственно топик возник как раз при ловле бага, когда транзакция отправлялась на apply
сразу после её прихода из network, поскольку она имела как раз подходящий для этого номер
(следующий после последней применённой).
Posted via ActualForum NNTP Server 1.5

Ivan_PisarevskyГотов послушать твой вариант решения проблемы.

Если бы у меня было решение проблемы, я бы не начинал этот топик. На данный момент есть
два костыля:
1) Реализованный. В очереди может быть только по одной транзакции от каждой ноды. При
некоторых ошибках транзакции даётся второй шанс: она снова ставится в конец очереди. Если
транзакции с других нод из очереди сделают что-то, решающее проблему, прежде чем данная
вернётся - хорошо. Нет - падаем с шумом. При этом последовательность транзакций одной ноды
сохраняется.
2) Планируемый. При нарушении FK обработка транзакций этой ноды приостанавливается и
посылается запрос пирам "пришлите недостающую мастер-запись". Этот вариант опробован
softwarer-ом, который утверждает, что он работоспособен. У меня есть теоретической
подозрение, что в худшем случае он может надолго приостановить применений транзакций вообще.
Posted via ActualForum NNTP Server 1.5