Кратко

  • RFC 3384 требовал, чтобы мультимастерные реплики пришли к одному живому состоянию, но вытесненная разрешением конфликта информация сохранялась отдельно, а администратор получал уведомление и возможность пересмотра.
  • Порядок прихода изменений не мог назначать окончательного победителя. Сходимость показа и сохранность свидетельства о разногласии были разными обязательствами.

Два главных сервера во время разрыва связи приняли разные изменения одного атрибута. После восстановления сети читателю нужен один действующий ответ, поэтому механизм репликации должен выбрать победителя. Но выбор не делает вторую запись ложной задним числом. RFC 3384 провёл границу именно здесь: единое текущее состояние нельзя покупать уничтожением другой допустимой истории.

Документ вышел в октябре 2002 года как Informational RFC. Он собирал фундаментальные требования к совместимой репликации каталогов LDAPv3, а не задавал завершённый протокол или единственный алгоритм конфликта. Из него также нельзя выводить внедрение конкретным продуктом. Это карта обязательных свойств приемлемого решения, а не отчёт о его распространении.

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

Область репликации определялась как настраиваемая часть Directory Information Tree. Области могли пересекаться и вкладываться. Реплика была экземпляром области, а группа реплик объединяла державшие её серверы. Соглашение задавало область, доступ, учётные данные, конфиденциальность и распространение. Поэтому слово «синхронизировано» всегда относится к конкретному охвату и договорённости.

RFC 3384 рассматривал пять моделей согласованности. Транзакционная модель обещала свойства ACID, но сложность распределённого двухфазного подтверждения привела к тому, что тогда её не развивали. Основные требования относились к eventual consistency и её варианту с ограниченными усилиями. Временное расхождение во время разделения сети было частью модели, а не автоматическим провалом.

Однако временность не означала произвол. M3 требовал, чтобы атрибут в итоге имел один и тот же набор значений во всех репликах с этой записью. MM6 повторял обязательство для атрибутов и записей в мультимастерной среде. Разрыв мог отсрочить общее состояние, но не отменить путь к нему.

Конфликт возникал из самой доступности нескольких мастеров. Каждый мог принять запись, не связавшись сначала с остальными. Это сохраняло локальную работу, но позволяло двум допустимым изменениям затронуть одни данные до обмена. После встречи требовалось детерминированно выбрать живое состояние.

Детерминизм не равнялся правилу «последним пришедший победил». Две реплики способны получить один набор обновлений в обратном порядке. Если каждая выберет свою последнюю доставку, победители останутся разными. MM7 запрещал ставить eventual convergence в зависимость от последовательного прихода изменений. Случайный маршрут пакета не должен создавать постоянную власть.

Документ не выбирал универсальные логические часы, временную метку или приоритет сервера. Он закреплял более глубокое свойство: независимые реплики в поддерживаемой модели должны прийти к одному результату при разных последовательностях доставки. Технический выбор оставался открытым, но корректность нельзя было доверить неподконтрольному порядку.

MM5 добавлял решающее требование. Мультимастерная репликация не должна терять информацию. Если разрешение конфликта всё же удаляло данные каталога из сошедшегося живого состояния, процесс обязан был сохранить их, уведомить администратора о конфликте и потере и предоставить механизм возможной административной отмены.

Это не означало, что оба несовместимых значения остаются действующими. Тогда решение просто перекладывалось бы на клиентов. Требование разделяло единую рабочую поверхность и слой свидетельств. На втором сохранялось то, что вытеснило автоматическое правило, чтобы человек мог понять выбор и при необходимости заменить победителя.

Поэтому визуальное равенство реплик не доказывает целостность. Оно показывает текущее видимое значение. Оно не говорит, верен ли победитель, доступна ли проигравшая версия и получил ли кто-нибудь сигнал. Полностью зелёная панель сходимости может скрывать неудовлетворительную подотчётность.

M12 ставил границу повторной доставке. Получение одного обновления несколько раз не должно давать иной результат, чем однократное получение. Соединение может оборваться после применения и до подтверждения. Поставщик повторяет сообщение, не зная исхода. Без идемпотентности восстановление само превращается в порчу данных.

P6 сохранял атомарность операций LDAP при переносе. Части одной операции не должны становиться видимыми отдельно из-за транспорта. Но две целые атомарные операции всё равно способны конфликтовать. Атомарность защищает от разорванной записи, а не выбирает между двумя завершёнными намерениями.

Конфликт начала репликации имел другую природу. Если несколько мастеров одновременно открывали цикл с одной репликой, MM4 требовал автоматического разрешения или предотвращения. Занятый потребитель, потеря соединения и перепланирование относятся к координации сессии. Несогласие значений относится к данным. Им нужны разные процедуры и свидетельства.

Администрирование входило в совместимость. AM2 требовал от каждой реплики историю аудита серверов, с которыми она обменивалась. AM4 и AM5 предусматривали сравнение и исправление различий без запуска нового цикла. Пустая реплика должна была инициализироваться полным обновлением. Примирение копий оставалось наблюдаемой операцией, а не скрытым обещанием.

Общий порядок прихода не выбирал победителя, но явная причинность оставалась важной. AM6 требовал сохранять последовательность между сведениями контроля доступа и управляемыми ими данными. Если данные приходят раньше защищающего правила, промежуточное состояние может иметь другой смысл безопасности. Случайная доставка и необходимая зависимость — разные вещи.

Несоответствия схемы требовалось обрабатывать и сообщать о них. Репликация охватывала определения схемы, имена и значения атрибутов, контроль доступа, знания каталога и пространство имён. Специфические служебные атрибуты DSA как таковые исключались. Частичные реплики допускались, но соглашение должно было ясно очертить их области, записи и атрибуты.

В безопасности аутентификация, авторизация, целостность и конфиденциальность не сливались. Поддерживались взаимная аутентификация, взаимная проверка полномочий и защищённая передача. Документ требовал также анонимные сессии репликации. Это не делало их равными доверенным, а заставляло протокол выразить разные режимы политики.

Более поздние RFC уточняют хронологию, но не доказывают полное исполнение требований. RFC 4510, RFC 4511 и RFC 4512 перестроили техническую спецификацию LDAP. RFC 4533 описал синхронизацию содержимого, RFC 5805 — транзакции. Тематическое соседство не позволяет приписывать им всю мультимастерную модель RFC 3384.

Сравнение с RFC 3383 показывает две разные поверхности координации. RFC 3383 распределял политики регистрации идентификаторов расширений LDAP и предотвращал коллизии имён. RFC 3384 рассматривал столкновение легитимных изменений во времени. Первый управлял входом имени, второй — сохранением доказательства вытесненного состояния.

Взгляд Lu Heng на минимальную начальную спецификацию объясняет ценность требований без единого алгоритма. Документ мог запретить недопустимый вред — власть порядка доставки, молчаливую потерю и отсутствие пересмотра — сохранив локальный выбор будущих методов. Открытость механизма не означала открытости ущерба.

Его подход к слоям реальности разделяет принятую запись, перенесённое обновление, обнаруженный конфликт, живого победителя, сохранённого проигравшего, уведомление и человеческую отмену. Это разные факты. Слово «сошлось» описывает лишь один слой и не может без доказательств говорить за всю систему управления.

Исторический урок RFC 3384 — подозревать слишком чистую сходимость. Распределённая система может получить один ответ, уничтожив материал для его оспаривания. Сохранение проигравшего значения превратило молчаливую перезапись в проверяемое решение. Реплики могли согласиться, не притворяясь, что никогда не расходились.

Источники