Однонаправленная репликация между двумя базами (постановка)
SYSDBA (обсуждение | вклад) |
SYSDBA (обсуждение | вклад) |
||
| Строка 1: | Строка 1: | ||
| − | Рассмотрим вариант однонаправленной репликации между двумя базами A и B. База B работает в режиме только для чтения. Все изменения осуществляются на базе A. В дальнейшем, мы будем использовать термины " | + | Рассмотрим вариант однонаправленной репликации между двумя базами A и B. База B работает в режиме только для чтения. Все изменения осуществляются на базе A. В дальнейшем, мы будем использовать термины "Удаленная база данных (УБД)" для базы А и "Центральная база данных (ЦБД)" для B. |
Базы обмениваются между собой сообщениями. Канал связи между базами может быть непостоянным. Т.е. база A может посылать сообщения в тот момент, когда база B недоступна и наоборот. Порядок выполнения действий над объектами на базе A должен сохраняться при переносе на базу B. Транспорт передачи сообщений не гарантирует нам ни сохранности и целости конкретного сообщения, ни сохранения порядка при передаче нескольких сообщений. | Базы обмениваются между собой сообщениями. Канал связи между базами может быть непостоянным. Т.е. база A может посылать сообщения в тот момент, когда база B недоступна и наоборот. Порядок выполнения действий над объектами на базе A должен сохраняться при переносе на базу B. Транспорт передачи сообщений не гарантирует нам ни сохранности и целости конкретного сообщения, ни сохранения порядка при передаче нескольких сообщений. | ||
| Строка 5: | Строка 5: | ||
В начальный момент времени базы данных находятся в идентичном состоянии. | В начальный момент времени базы данных находятся в идентичном состоянии. | ||
| − | Фиксирование изменений, произведенных в базе A, осуществляется в логе, специальной таблице. В логе фиксируется тип и идентификатор объекта, вид операции, порядковый номер изменения. Заполнение лога осуществляется с помощью системы триггеров. | + | Фиксирование изменений, произведенных в базе A, осуществляется в логе, специальной таблице. В логе фиксируется: |
| + | * тип и идентификатор объекта, | ||
| + | * вид операции (создание, изменение, удаление), | ||
| + | * порядковый номер изменения, | ||
| + | * состояние записи. | ||
| + | Заполнение лога осуществляется с помощью системы триггеров. | ||
Запись в логе находится в определенном состоянии. | Запись в логе находится в определенном состоянии. | ||
| Строка 11: | Строка 16: | ||
Первоначальное состояние -- L (Logged). Записи с таким статусом считаются подготовленными к отправке. | Первоначальное состояние -- L (Logged). Записи с таким статусом считаются подготовленными к отправке. | ||
| − | Объект может быть заблокирован, состояние B (Blocked) записи в логе. В этом случае он не передается, а так как мы не можем нарушать последовательность выполнения операций на конечной базе данных, то нет смысла передавать операции после заблокированной записи. Пользователь должен быть уведомлен о том, какая именно запись вызвала остановку процедуры передачи данных. | + | Объект может быть заблокирован, состояние B (Blocked) записи в логе. В этом случае он не передается, а так как мы не можем нарушать последовательность выполнения операций на конечной базе данных, то нет смысла передавать операции после заблокированной записи. Пользователь должен быть уведомлен о том, какая именно заблокированная запись вызвала остановку процедуры передачи данных. |
Поскольку мы не храним полного состояния объекта в логе, а только ссылку на него, то любое последующее изменение объекта должно быть заблокировано, пока предыдущие изменения не будут успешно переданы на конечную базу данных. Исключение составляют два и более последовательных изменения одного и того же объекта. | Поскольку мы не храним полного состояния объекта в логе, а только ссылку на него, то любое последующее изменение объекта должно быть заблокировано, пока предыдущие изменения не будут успешно переданы на конечную базу данных. Исключение составляют два и более последовательных изменения одного и того же объекта. | ||
| Строка 22: | Строка 27: | ||
# Исходная база проверяет лог. При наличии записей в состоянии L для каждой из них формируется отдельное сообщение для передачи на конечную базу данных. | # Исходная база проверяет лог. При наличии записей в состоянии L для каждой из них формируется отдельное сообщение для передачи на конечную базу данных. | ||
| − | # Конечная база данных проверяет наличие сообщений в очереди. | + | # Конечная база данных проверяет наличие сообщений в очереди. При наличии сообщений они сортируются в порядке возрастания номера. Проверяется номер первого сообщения. |
| + | ## Если он соответствует ожидаемому, то происходит считывание и обработка сообщения. | ||
| + | ## Если номер первого сообщения в очереди меньше ожидаемого, то просто игнорируем его (удаляем). | ||
| + | ## Если номер первого сообщения в очереди больше ожидаемого, то посылаем запрос на пересылку сообщений с нужными номерами. Останавливаем дальнейшую обработку очереди. Ждем ответа от исходной базы. | ||
| + | # | ||
[[Category:Постановка]] | [[Category:Постановка]] | ||
| + | [[Category:Репликация]] | ||
Версия 20:43, 16 августа 2009
Рассмотрим вариант однонаправленной репликации между двумя базами A и B. База B работает в режиме только для чтения. Все изменения осуществляются на базе A. В дальнейшем, мы будем использовать термины "Удаленная база данных (УБД)" для базы А и "Центральная база данных (ЦБД)" для B.
Базы обмениваются между собой сообщениями. Канал связи между базами может быть непостоянным. Т.е. база A может посылать сообщения в тот момент, когда база B недоступна и наоборот. Порядок выполнения действий над объектами на базе A должен сохраняться при переносе на базу B. Транспорт передачи сообщений не гарантирует нам ни сохранности и целости конкретного сообщения, ни сохранения порядка при передаче нескольких сообщений.
В начальный момент времени базы данных находятся в идентичном состоянии.
Фиксирование изменений, произведенных в базе A, осуществляется в логе, специальной таблице. В логе фиксируется:
- тип и идентификатор объекта,
- вид операции (создание, изменение, удаление),
- порядковый номер изменения,
- состояние записи.
Заполнение лога осуществляется с помощью системы триггеров.
Запись в логе находится в определенном состоянии.
Первоначальное состояние -- L (Logged). Записи с таким статусом считаются подготовленными к отправке.
Объект может быть заблокирован, состояние B (Blocked) записи в логе. В этом случае он не передается, а так как мы не можем нарушать последовательность выполнения операций на конечной базе данных, то нет смысла передавать операции после заблокированной записи. Пользователь должен быть уведомлен о том, какая именно заблокированная запись вызвала остановку процедуры передачи данных.
Поскольку мы не храним полного состояния объекта в логе, а только ссылку на него, то любое последующее изменение объекта должно быть заблокировано, пока предыдущие изменения не будут успешно переданы на конечную базу данных. Исключение составляют два и более последовательных изменения одного и того же объекта.
На конечной базе данных также ведется лог принятых сообщений. Как и в случае с базой А, каждая запись в логе имеет определенное состояние.
Запись об успешно принятом объекте имеет состояние R (Received).
Последовательность обмена сообщениями между исходной и конечной базами данных выглядит следующим образом:
- Исходная база проверяет лог. При наличии записей в состоянии L для каждой из них формируется отдельное сообщение для передачи на конечную базу данных.
- Конечная база данных проверяет наличие сообщений в очереди. При наличии сообщений они сортируются в порядке возрастания номера. Проверяется номер первого сообщения.
- Если он соответствует ожидаемому, то происходит считывание и обработка сообщения.
- Если номер первого сообщения в очереди меньше ожидаемого, то просто игнорируем его (удаляем).
- Если номер первого сообщения в очереди больше ожидаемого, то посылаем запрос на пересылку сообщений с нужными номерами. Останавливаем дальнейшую обработку очереди. Ждем ответа от исходной базы.
