Сохранение целостности транзакций

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

Рис. 1.5.3.4.1. Репликация транзакций:

а) без соблюдения свойства атомарности транзакций;

б) с соблюдением свойства атомарности транзакций.

В данном случае транзакция, состоящая на исходном сайте из нескольких операций обновления данных в различных таблицах (А, В, С), в процессе репликации преобразовалась в серию отдельных (трёх) транзакций, каждая из которых обновляла данные в одной из таблиц. Если часть этих транзакций на целевом сайте завершилась успешно (первая и вторая), а остальная часть (третья транзакция) – нет, то согласованность (целостность) информации в двух базах данных утрачивалась (рис. 1.5.3.4.1,а).

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

Моментальные снимки таблиц

Метод моментальных снимков таблиц позволяет асинхронно распространять результаты изменений, выполненных в отдельных таблицах, группах таблиц, представлениях или фрагментах таблиц в соответствии с заранее установленным графиком (например, ежедневно в 23.00). Реализован в СУБД Oracle 8.

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

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

Различные СУБД реализуют механизм моментальных снимков по-разному: в некоторых случаях данный процесс является частью самого сервера СУБД, тогда как в других случаях он реализуется как независимый внешний сервер.

Триггеры базы данных

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

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

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

1. Отслеживание запуска и выполнения триггерных процедур создает дополнительную нагрузку на систему.

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

3. Триггеры не могут выполняться в соответствии с некоторым графиком. Онивыполняютсявтотмомент, когдапроисходитобновлениеданныхвведущейтаблице. Моментальные снимки могут создаваться в соответствии с установленным графиком или даже вручную. В любом случае это позволяет исключить дополнительную нагрузку от репликации данных в периоды пиковой нагрузки на систему.

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

5. Аннулирование результатов выполнения триггерной процедуры в случае отмены или отката транзакции – достаточно сложная задача.