Схема репликации данных
Тиражирование данных в системе построено по схеме с одним сервером подписки (центральный сервер) и множеством серверов репликации (районы).
Рис.2.6. Организация репликации данных.
Данные на центральном сервере доступны только для чтения чтобы избежать конфликтов по модификации записи.
Рис.2.7. Подробная схема репликации данных.
Схема репликации приведена на рис.2.7. Рассмотрим процесс передачи изменений подробнее:
1. При изменении данных в реплицируемой таблице новые данные через триггер записываются в журнал изменений. Кроме того, туда заносится имя таблицы, код сделанного изменения и первичный ключ измененной записи.
2. При возникновении в базе определенного события (например при большом количестве записей в журнале изменений) или в определенный момент времени коммуникационный сервис запускает процесс репликации.
3. Процесс репликации устанавливает соединение с сервером подписки и начинает синхронизацию данных.
4. Сервер подписки принимает измененную запись и модифицирует соответствующим образом таблицу на своей стороне.
5. Если в процессе изменения записи был сгенерирован новый ключ, то он передается на сервер репликации.
6. Сервер репликации заменяет первичный ключ реплицируемой записи на ключ, возвращаемый с сервера подписки и удаляет соответствующую запись из журнала изменений.
При передаче изменений коммуникационным сервисом используется протокол двухфазной фиксации транзакций (Two-phase commit transactions), что позволяет застраховаться от ошибок.
При синхронизации данных подобным методом процесс репликации может быть прерван в любой момент времени и продолжен позднее с той же точки. Данная особенность позволяет использовать такую схему тиражирования даже на очень плохих каналах связи.
