Двунаправленная репликация между двумя базами (постановка)

Версия 15:34, 1 сентября 2009

На основе подробно рассмотренной схемы однонаправленной репликации построим схему, в которой базы A и B равноправны в плане изменения данных.

Как и раньше, базы обмениваются между собой сообщениями в асинхронном режиме, т.е. база A может посылать сообщения в тот момент, когда база B недоступна и наоборот. Порядок выполнения действий над объектами на базе A должен строго сохраняться при переносе на базу B и наоборот. Транспорт передачи сообщений не гарантирует нам ни сохранности и целости конкретного сообщения, ни сохранения порядка при передаче нескольких сообщений.

В один момент времени изменение объектов возможно только на одной из баз, которая называется Активной базой данных (АБД). Активная база данных в начальный момент времени называется Главной базой данных (ГБД). Статус активности передается по запросу от одной базы данных к другой.

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

Ниже представлена концептуальная схема организации репликации. Нюансы конкретной реализации рассмотрены в главе "Особенности физической реализации" в конце статьи.

Состояния объекта в БД

Каждый объект в базе данных находится в определенном состоянии. В таблице ниже перечислены возможные состояния, а также определены допустимые переходы из одного состояния в другое. Состояние объекта влияет на блокировку действий по его изменению или удалению.

Лог изменений

Фиксирование изменений состояния объекта осуществляется в логе, который заполняется триггерами и содержит:

• целочисленный порядковый номер изменения (начиная с единицы),
• идентификатор объекта,
• тип объекта,
• вид операции (создание, изменение, удаление),
• состояние объекта,
• дата и время изменения состояния.

В дальнейшем, символом N мы будем обозначать номер изменения, а символом М -- максимальный номер изменения в логе. М принимается равным нулю, если лог пуст.

Состояние базы данных

Мы будем называть целое число S состоянием базы данных. Если S = М, значит все изменения переданы. Если S < M, -- необходимо осуществить передачу. Ситуация, когда S > M означает серьезный сбой в данных репликации, нарушение логической целостности.

В начальный момент времени:

 S = M = 0

Базы данных А и B находятся в идентичном состоянии, если M_a = S_b.

Состояние БД увеличивается на единицу каждый раз, когда подтверждается передача очередного объекта или принимается и успешно записывается в БД объект. S равно максимальному номеру записи в логе в состоянии C или R.

В начальный момент времени базы данных находятся в идентичном состоянии и выполняется равенство:

 Sa = Sb = Мa = Мb = 0

Связь в асинхронном режиме

В том случае, если при обмене данными между базами нет постоянного канала связи, мы будем использовать следующие параметры:

 Tr -- Допустимое время ожидания ответа на посланное сообщение.
 Ts -- Время простоя БД с момента обработки последнего сообщения до отсылки запроса о состоянии противоположной базы.
 Ti -- Период с которым БД осуществляет проверку очереди сообщений и отсылку изменений.

Критерий идентичности баз в асинхронном режиме

УБД знает о том, что она идентична ЦБД, если S_a=M_a. Т.е. нет объектов в состоянии L, B или S.

ЦБД знает о том, что она идентичная УБД, если получено сообщение "Состояние УБД" (ответ на сообщение "Запрос состояния УБД") из которого следует что M_a=S_b.

Запрос состояния УБД

Когда база B хочет узнать текущее состояние синхронизации с базой А, она посылает специальное сообщение "Запрос состояния УБД" и фиксирует время его отправки. Получив данное сообщение, база А действует в соответствии со своим логом. Если он содержит записи, подлежащие отправке, то формируются и посылаются соответствующие сообщения. Непосредственного ответа на "Запрос состояния УБД" в этом случае не отсылается. Если лог не содержит записей для отправки, то формируется специальное сообщение "Состояние УБД", которым передается число M_a. После отсылки запроса База B периодически проверяет свою очередь сообщений. Если в течение заданного тайм-аута в очередь не поступило ни одного ответа от базы А, то системный администратор оповещается о возможном нарушении канала связи или неполадках на УБД. Если поступил ответ "Состояние УБД", то M_a сверяется с S_b. При их равенстве базы данных считаются идентичными (синхронизированными). Если M_a > S_b, то база B отсылает сообщение "Запрос на передачу объекта" с указанием номера S_b + 1. Состояние, когда M_a < S_b, свидетельствует о серьезной рассинхронизации двух баз данных и требует немедленного информирования системного администратора.

"Запрос состояния УБД" отсылается автоматически по истечении заданного интервала времени с момента обработки последнего сообщения от УБД или с момента отправки предыдущего запроса на состояние, на который не поступило ответа.

Журнал репликации

Журнал используется системным администратором для выявления проблем и/или профилирования репликации. В журнал заносятся:

• Информативные сообщения
• Предупреждения
• Критические ошибки

Последовательность обмена сообщениями

Последовательность обмена сообщениями между исходной и конечной базами данных выглядит следующим образом:

База А

Проверяется очередь сообщений:

1. Очередь сообщений пуста:
   1. Для объектов в состоянии S, с момента отправки которых прошло времени больше чем T_r, на ЦБД отсылаем сообщение "Запрос подтверждения передачи объекта" с указанием идентификаторов объектов. Одновременно в журнале отражаем факт превышения времени ожидания ответа на сообщение "Передача объекта".
   2. Для каждого объекта в состоянии L формируется и посылается отдельное сообщение "Передача объекта". После формирования и успешной отправки сообщения, запись в логе переводится в состояние S.
2. Если в очереди присутствуют только сообщения типа "Запрос состояния УБД", отвечаем сообщением "Состояние УБД" и очищаем очередь.
3. Если в очереди присутствуют сообщения, сортируем их по порядковому номеру. В процессе сортировки удаляем сообщения типа "Запрос состояния УБД". Обрабатываем последовательно:
   1. "Подтверждение передачи объекта":
      1. Если номер изменения из сообщения соответствует номеру первого объекта со статусом S (в порядке очередности записей в логе), то переводим объект в состояние C. Удаляем сообщение из очереди и продолжаем обрабатывать список.
      2. Если номер из сообщения меньше номера первого объекта со статусом S, то игнорируем такое сообщение. Удаляем сообщение из очереди и продолжаем обрабатывать список. Заносим в журнал информацию о получении лишнего подтверждения.
      3. Если номер из сообщения больше номера первого объекта со статусом S:
         1. Еще не истек допустимый интервал времени с момента отправки первого объекта в состоянии S. Сообщение из очереди не удаляем. Продолжаем обрабатывать список, пропуская все последующие сообщения типа "Подтверждение передачи объекта".
         2. Истекло время, отпущенное ЦБД на ответ. Отсылаем на сервер сообщение "Запрос подтверждения передачи объекта" с указанием идентификаторов всех объектов, для которых с момента отправки прошло времени больше чем T_r. Сообщение из очереди не удаляем. Продолжаем обрабатывать список, пропуская все сообщения типа "Подтверждение передачи объекта". Помещаем информацию о недошедшем подтверждении в журнал.
   2. "Запрос на передачу объекта":
      1. Если запрашиваемый объект находится в состоянии S, то передаем его на ЦБД. Удаляем сообщение из очереди и продолжаем обрабатывать список. Помещаем в журнал информацию о повторной передаче объекта.
      2. Если запрашиваемый объект находится в состоянии L или C, или вообще отсутствует в списке, то игнорируем сообщение и удаляем его из очереди, а в журнал помещаем запись с информацией о запросе на передачу ранее переданного и подтвержденного объекта.

База B

Если в логе ЦБД присутствует запись в состоянии F, т.е. была ошибка при загрузке объекта, то репликация останавливается. Обработка очереди сообщений не производится.

Проверяется наличие сообщений в очереди.

1. Очередь пуста:
   1. Ранее было отправлено сообщение "Запрос состояния УБД":
      1. Если интервал времени на ответ не истек, то продолжаем ожидать.
      2. Интервал времени истек. Информируем системного администратора. Повторяем "Запрос состояния УБД".
   2. Если истек интервал проверки связи и состояния УБД, то отсылаем "Запрос состояния УБД".
2. Очередь содержит только сообщения типа "Состояние УБД". Берем последнее из них в хронологическом порядке:
   1. Если M_a = S_b, базы в идентичном состоянии. Очищаем очередь сообщений.
   2. Если M_a > S_b, есть объекты к передаче с УБД на ЦБД. Отсылаем запрос на передачу объекта. Очищаем очередь сообщений.
   3. Если M_a < S_b, серьезный сбой. Информируем системного администратора.
3. Очередь не пуста.
   1. Сортируем сообщения в порядке номеров изменений. Выкидываем все сообщения "Состояние УБД". Обрабатываем в порядке очередности.
      1. Если номер изменения первого сообщения в очереди равен S_b + 1, то загружаем объект. Удаляем текущее сообщение и продолжаем обрабатывать очередь.
      2. Если номер изменения первого сообщения в очереди меньше S_b + 1, то игнорируем такое сообщение. Удаляем его и продолжаем обрабатывать очередь. В журнал помещаем запись о несанкционированной повторной передаче уже принятого объекта.
      3. Если номер изменения первого сообщения в очереди больше S_b + 1, то прекращаем обработку очереди. Текущее сообщение не удаляем. На УБД отсылаем сообщение "Запрос на передачу объекта", где указываем диапазон изменений, которые нас интересуют: с S_b до номера изменения первого сообщения в очереди, не включая границы.
   2. По окончании обработки очереди (не важно, полной или частичной), отсылаем на УБД сообщение "Подтверждение передачи объектов" с указанием номеров изменений, успешно записанных в ЦБД.
   3. При возникновении конфликта записи объекта в ЦБД останавливаем обработку очереди. В лог ЦБД заносим пометку номера изменения и ставим ему статус F. Информируем системного администратор о серьезном сбое репликации.

Структура сообщения

Каждое сообщение содержит постоянную часть (заголовок) и данные, которые зависят от типа сообщения:

• Заголовок
  • Тип сообщения
  • Дата и время отправки
  • Отправитель
  • Получатель
  • Контрольная сумма
• Данные, в зависимости от типа сообщения. Для сообщений некоторых типов данные могут отсутствовать:
  • "Передача объекта"
    • Номер изменения в логе.
    • Поток данных объекта.
  • "Запрос подтверждения передачи объекта"
    • Диапазон номеров изменений в логе.
  • "Состояние УБД"
    • Число M_a.
  • "Запрос состояния УБД"
    • Нет данных.
  • "Подтверждение передачи объекта"
    • Диапазон номеров изменений в логе.
  • "Запрос на передачу объекта"
    • Диапазон от S_b + 1 до наименьшего номера изменения, переданного в сообщении "Передача объекта".

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

Особенности физической реализации

Очередность сохранения объектов и формирование потока

Механизм сохранения в поток платформы Гедымин рекурсивно обходит все ссылки, от которых зависит сохраняемый объект. Возможна ситуация, когда в логе будут находиться последовательно изменения объектов A, B, C. Объект А зависит от С. Тогда, при сохранении в поток объекта A, через ссылки, сохранится и объект C. Это приведет к нарушению строгой очередности передачи объектов в соответствии с порядком изменений в логе. В таком случае, в момент формирования потока при сохранении объекта А, необходимо остановить процесс и информировать системного администратора.

Регистрация несущественных изменений

Триггеры регистрации в логе изменений не должны реагировать на изменение только значений технических полей (например, LB и RB для интервальных деревьев).

Изменение объекта и регистрация изменения на одной транзакции

Во избежание рассинхронизации реального состояния объекта с информацией в логе, изменение объекта и регистрация в логе его нового состояния должны происходить на одной транзакции.