Чтобы изменения могли быть реплицированы на другой сервер, они предварительно должны быть зафиксированы. Механизм репликации в IS-Builder фиксирует изменения на уровне логической структуры данных, т.е. фиксируется изменение не отдельной записи в таблице базы данных, а изменение группы записей, относящихся к изменяемой записи в компоненте. Введем новые понятия, которые помогут более детально описать механизм репликации.

Передающий сервер

Сервер, передающий пакет репликации. Передающим может быть и главный, и вторичный сервер.

Принимающий сервер

Сервер, принимающий пакет репликации. Принимающим может быть и главный, и вторичный сервер.

Действие

Совокупность запросов к SQL-серверу на изменение, добавление или удаление записи компоненты, рассматриваемая как атомарная единица репликации. Например, при изменении некоторой записи справочника будут зафиксированы изменения, произведенные в таблицах MBAnalit, MBAnValR, MBAnValR2-MBAnValR24 и все эти изменения будут рассматриваться как одно действие, которое на принимающем сервере будет или принято целиком, или не принято совсем.

Конфликт

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

Наведенный конфликт

Конфликт, возникший в результате предыдущего конфликта.

Действие-исправление

Действие, сформированное принимающим сервером для передающего сервера при возникновении конфликта приема действия. При выполнении действия-исправления на передающем сервере значения реквизитов записи, над которой было произведено непринятое действие, приводятся в соответствие со значениями реквизитов этой же записи на принимающем сервере. Тип действия-исправления может принимать одно из трех значений: Добавление, Изменение, Удаление.

Тип действия-исправления определяется на основании типа действия, для которого формируется действие-исправление:

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

Ответ

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

Буфер действий

Протокол изменения данных на передающем сервере в разрезе действий, произведенных с момента последнего сеанса репликации.

Буфер действий ведется независимо для каждого принимающего сервера. Буфер действий содержит в себе уникальный номер действия, тип действия (Изменение, Добавление или Удаление), состояние действия (Передано или Не передано) и ссылку на запись компоненты, над которой произведено действие. В случае, когда одна и та же запись компоненты с момента последней передачи данных изменяется несколько раз (под изменением понимается добавление, или удаление, или собственно изменение), то действия по изменению записи, еще не переданные на принимающий сервер, сливаются в одно действие с номером первого не переданного действия и определением нового типа действия по схеме:

Аналогичное слияние действий происходит при обработке ответов. Под обработкой ответов понимается удаление принятых действий из буфера действий. В случае, когда по результатам обработки ответа в буфере действий оказалось два действия (а это может случиться, если ответ «Не принято»), то они сливаются в одно действие с новым типом, определяемым по вышеописанной схеме. Таким образом, обеспечивается, что в каждом сеансе репликации передается только одно действие над одной записью, а не вся история изменений этой записи. Данная схема может привести к нарушению хронологии при приеме данных, что может привести к конфликтам приема объектов из-за отсутствия на момент приема в данных принимающего сервера объектов, на которые есть ссылки в принимаемом объекте. Для исключения таких конфликтов прием данных ведется итерационно. В каждой итерации обрабатываются действия, которые еще не были успешно приняты на предыдущих итерациях. Итерации заканчиваются, когда количество ошибок на очередной итерации равно количеству ошибок на предыдущей итерации либо ошибки отсутствуют.

Действия, описанные в таблице в строках № 3, 7, 8, 9, могут возникнуть при конфликтах репликации.

Буфер исправлений

Буфер для ручных действий-исправлений или для не выполнившихся автоматических (при невозможности выполнения автоматического действия-исправления оно приравнивается к ручному), полученных от принимающего сервера в ответ на конфликты приема действий.

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

© Компания DIRECTUM, 2018

Сообщество пользователей DIRECTUM