Репликация данных. Виды и свойства репликации. Сравнение механизмов репликации в MS SQL Server 2005 и ORACLE Server 10g.Одной из основных характеристик хранилища данных является модель его непротиворечивости, в которой определяются какие правила необходимо соблюдать, чтобы хранилище возвращало разным процессам правильные результаты. Выделяют следующие модели непротиворечивости[1]: строгая, линеаризуемая, последовательная, причинная, FIFO, слабая, свободная и поэлементная. Рассматривается репликативный аспект последовательной, слабой и FIFO моделей непротиворечивости. Этот выбор обусловлен тем, что первые две модели обеспечивают глобальную сериализуемость операций, а последняя - довольно легко реализуема и является менее жесткой, чем первые две. В [1] приведены определения всех вышеперечисленных моделей непротиворечивости, здесь же приводятся определения только рассматриваемых моделей, необходимые для дальнейшего изложения.
Последовательная непротиворечивость определяется следующим правилом:
Результат любого действия такой же, как если бы операции (чтения и записи) всех процессов в хранилище данных выполнялись бы в некотором последовательном порядке, причем операции каждого отдельного процесса выполнялись бы в некотором последовательном порядке, определяемом его программой.
Непротиворечивость FIFO определяется следующим правилом:
Операции записи, осуществляемые единичным процессом, наблюдаются всеми остальными процессами в том порядке, в котором они осуществляются, но операции записи, происходящие в различных процессах, могут наблюдаться разными процессами в разном порядке.
Слабая непротиворечивость
Для определения слабой непротиворечивости вводится понятие переменной синхронизации. Переменная синхронизации (S) имеет ассоциированный с ней набор реплицируемых данных и позволяет выполнять над собой единственную операцию synchronize(S). В ходе выполнения этой операции изменения сделанные процессом в локальной копии данных распространяются на все остальные копии данных, ассоциированные с переменной синхронизации. Также в ходе этой операции локальная копия обновляется данными из остальных копий.
Модель слабой непротиворечивости имеет три свойства:
- Доступ к переменным синхронизации, ассоциированными с хранилищем данных, осуществляется на условиях последовательной непротиворечивости.
- С переменной синхронизации не может быть произведена ни одна операция до полного и повсеместного завершения предшествующих ей операций чтения и записи над элементами данных.
- С элементами данных не может быть произведена ни одна операция до полного завершения всех операций с переменными синхронизации.
Протокол непротиворечивости представляет собой конкретную реализацию соответствующей модели. Принято выделять следующие группы протоколов непротиворечивости[1]: на базе первичной копии, реплицируемой записи, согласования кэшей.
Протоколы на базе первичной копии, подразумевающие репликацию данных
Все протоколы на базе первичной копии подразумевают наличии для каждого элемента данных Х, ассоциированного с ним первичного элемента данных, который отвечает за координацию операций записи. В [1] выделяется два протокола поддерживающих репликацию:
Протокол первичного архивирования с удаленной записью
Описание протокола:
Расшифровка обозначений:
W1 - запрос на запись
W2 - пересылка запроса на сервер
W3 - сигнал на обновление резервных копий
W4 - подтверждение выполнения обновления
W5 - подтверждение выполнения записи
R1 - запрос на чтение
R2 - ответ для чтения
При реализации этого протокола необходимо гарантировать, что в каждый момент времени только один узел имеет доступ к первичной копии, тем самым, имея возможность изменять данные. Существует асинхронный вариант, при котором подтверждение о выполнение записи посылается сразу после обновления первичной копии (не дожидаясь обновления всех копий). Это повышает производительность операции записи, однако требует дополнительных действий для обеспечения: гарантированного обновления всех реплик (защита от сбоев при распространении) и согласованного чтения для узла, инициировавшего обновление (он не должен иметь возможность считать значение, который имел элемент данных до записи). В случае если все первичные копии находятся на одном узле, имеем реализацию последовательной непротиворечивости, иначе не предпринимая дополнительных мер можно говорить только о непротиворечивости FIFO.
Протокол первичного архивирования с локальной записью
Описание протокола:
Расшифровка обозначений:
W1 - запрос на запись
W2 - перемещение элемента данных х на новый первичный сервер
W3 - подтверждение завершения записи
W4 - сигнал на обновление резервных копий
W5 - подтверждение обновления
R1 - запрос на чтение
R2 - ответ для чтения
В протоколе подразумевается асинхронное обновление остальных копий. Здесь также необходимо предпринимать дополнительные меры, чтобы гарантировать обновление остальных реплик, однако проблемы согласованного чтения для узла, инициировавшего обновление, здесь не возникает. Без дополнительных мер протокол реализует FIFO непротиворечивость, реализовав полностью упорядоченную групповую рассылку (с помощью отметок времени Лампорта)[1], можно получить реализацию последовательной непротиворечивости. Поскольку в протоколе допускается перемещение первичной копии то необходимо решить задачи поиска узла, содержащего первичную копию и смены владельца.
Пример решения задач поиска и смены владельца первичной копии
В СУБД Oracle существует метод репликации данных, предотвращающий возникновение конфликтов[2,3], и который содержит решения двух рассматриваемых задач. В [2] он определяется как dynamic ownership with token passing (динамическое владение с переходящим маркером). В этом методе подразумевается наличие нескольких реплик табличных данных, расположенных на разных узлах, на каждом из которых установлена СУБД Oracle. К реплицируемой таблице добавляется два столбца, первый из которых содержит имя узла (owner), который владеет строкой данных, а второй номер версии строки данных (epoch). Столбец epoch используется для предотвращения конфликтов упорядочивания при асинхронной рассылке изменений.
Алгоритм поиска первичной копии
Поиск начинается с локально узла. Считывается значение столбца owner для заданной строки данных, идентифицируемой своим ключом. Если значение owner совпадает с именем локального узла (того на котором осуществляется чтение), то узел является владельцем первичной копии и поиск заканчивается. Если не совпадает, то считывается значение из строки, находящейся на узле, имя которого было считано на предыдущем этапе. Этот процесс продолжается до тех пора не будет найден узел владелец.
Алгоритм смены владельца первичной копии
Предполагается, что владелец был найден с помощью предыдущего алгоритма. Строка, владелец которой изменяется, блокируется на узле текущего владельца. На обоих узлах изменяются значения owner и epoch. Owner меняется на имя узла, инициировавшего смену владельца, а epoch увеличивается на единицу. После этого остальным узлам асинхронно рассылаются новые значения owner и epoch. Такой алгоритм гарантирует, что в каждый момент времени только один узел считает себя владельцем строки.
Протоколы реплицируемой записи
В протоколах реплицируемой записи операции записи могут осуществляться на нескольких репликах, а не на одной, как в случае протоколов на базе первичной копии. Существуют две основные разновидности, рассматриваемые ниже.
Активная репликация
Активная репликация подразумевает возможность обновления произвольной реплики с последующей рассылкой обновлений другим репликам (с помощью команд обновления или самих обновленных данных). Для того чтобы с помощью активной репликации можно было реализовать модель последовательной непротиворечивости, необходимо гарантировать одинаковую последовательность выполнения всех операций записи на всех машинах. Это можно обеспечить с помощью упорядоченной групповой рассылки, построенной с помощью отметок времени Лапорта, либо с помощью выделения специального узла (секвенсора), который будет упорядочивать все операции записи, за счет присвоения им последовательного уникального идентификатора. Последнее решение, однако, приближает активную репликацию к протоколам на базе первичной копии. Также возможно предстоит решить проблему реплицированных обращений, смысл которой состоит в следующем: если объект А обращается к реплицированному объекту В, который при этом обращается к объекту С, то объект С получит несколько обращений вместо одного.
Протоколы кворума
Основная идея, лежащая в основе протоколов кворума состоит в том, чтобы запрашивать разрешение на проведение операций чтения и записи у нескольких серверов, образующих кворум. Существуют кворум записи и кворум чтения. Эти кворумы надо собрать перед выполнением соответствующих операций. При этом с каждой операцией записи одних и тех же данных сопоставляется последовательно возрастающий номер версии. Пусть разделяемый ресурс имеет N реплик, тогда кворум чтения Nr (количество реплик, к которым выполняется запрос на чтение) и кворум записи Nw (количество реплик, в которое осуществляется запись) определяются из следующих двух условий:
- Nr + Nw > N
- Nw > N/2
Смысл этих ограничений состоит в следующем: первое ограничение гарантирует, что при опросе Nr серверов, хотя бы один из них содержит последнюю версию запрашиваемых данных, второе ограничение устраняет конфликт двойной записи, т.е. делает невозможных существование различающихся копий одних и тех же данных, имеющих одинаковую версию. В предельном случае, когда Nr = 1 Nw = N, все операции чтения могут быть осуществлены локально, однако операция обновления должна быть произведена на всех репликах.
Замечания по поводу реализации свободной непротиворечивости
Протоколы на базе первичной копии плохо подходят для реализации свободной непротиворечивости. Это объясняется тем, что в них операция записи, автоматически порождает выполнение синхронизации реплик, тогда как при свободной непротиворечивости подразумевается независимое выполнение операций синхронизации. Протоколы реплицируемой записи (активная репликация) куда лучше подходят для реализации данной модели. Для реализации активной репликации нужна полностью упорядоченная групповая рассылка. Поскольку в модели слабой непротиворечивости подразумевается доступ к переменным синхронизации согласно последовательной непротиворечивости, то упорядоченная групповая рассылка может быть использована для организации доступа к переменным синхронизации.
Задача получения новой непротиворечивой реплики
Рассматривается распределенное хранилище данных (РХД), состоящие из N узлов, каждый их которых содержит реплики данных. Стоит задача получения непротиворечивой реплики для нового N+1 узла.
Существует два различных подхода к решению этой задачи:
- Перевод распределенного хранилища данных в состояние, в котором выполнение операций изменения данных запрещено, с последующим копированием всех необходимых данных в новую реплику
- Получение новой реплики без приостановки выполнения операций изменения, при этом распределенное хранилище данных продолжает функционировать в обычном режиме
Алгоритм, иллюстрирующий 1-ый подход
Узел, инициирующий операцию по переводу хранилища данных в особое состояние, посылает всем остальным узлам сообщение о запрете инициировать новые изменения. В ответ на это сообщение каждый из узлов, помечает все сообщения, инициатором которых он является, и которые уже находятся в его локальной очереди, но еще не обработаны. Далее каждый узел продолжает обрабатывать все поступающие от других узлов сообщения и свои помеченные сообщения. После того как будет обработано последнее помеченное сообщение, каждый узел посылает сообщение узлу инициатору о завершение выполнения своих операций. После того как узел инициатор получит такие сообщения от всех узлов, РХД будет находиться в специальном состоянии и можно начинать операции копирования для получения новой реплики.
Алгоритм получения глобального состояния системы
В [1] приводится алгоритм получения глобального состояния. Узел, инициирующий получение глобального состояния системы, выполняет локальное копирование и посылает всем остальным узлам запрос на проведение операции получения глобального состояния. Каждый узел, получив такой запрос, делает одно из двух:
1) Если запрос получен впервые, то он записывает свое локальное состояние и пересылает запрос всем остальным узлам. После этого он начинает протоколировать все входящие сообщения от всех узлов
2) Иначе он сохраняет список всех сообщений полученных от узла источника (узел, от которого ему пришел запрос) за время протоколирования сообщений и перестает протоколировать сообщения этого узла. После того как будут получены сообщения от всех узлов, узлу, инициировавшему получение глобального состояния, посылается записанное локальное состояние и все сохраненные списки сообщений.
На основании алгоритма получения глобального состояния системы можно предложить алгоритм получения новой реплики для РХД, в котором все изменения выполняются с помощью распределенных транзакций, без приостановления выполнения операций изменения.
Алгоритм, иллюстрирующий 2-ой подход
Узел, для которого получается новая реплика (Узел N), вовлекается в выполнение распределенных транзакций. Для каждого запроса на проведение распределенной транзакции он подтверждает выполнение своей части, реально не выполняя никаких действий. Далее он рассылает всем узлам сообщение на получение глобального состояния. Каждый узел, получив это сообщение, выполняет те же действия, что и в алгоритме 2. Завершив формирование свой части глобального состояния, каждый из узлов посылает его узлу N. Узел N получит, таким образом, два сообщения от каждого из остальных узлов: 1-ое после того как узел сохранит свое локальное состояние (посылается при 1-ом действии по алгоритму 2) и 2-ое, содержащее часть глобального состояния (посылается при 2-ом действии по алгоритму 2). После получения 1-ого сообщения от некоторого узла M, узел N начинает протоколировать все последующие сообщения от этого узла, до тех пор пока не получит сообщение 2 от всех узлов. После этого узел N имеет в своем распоряжении глобальное состояние и список сообщений от каждого из узлов, которые были посланы узлу N, после сохранения ими своего локально состояния. Этих данных достаточно, чтобы получить новую непротиворечивую реплику.
Если принять дополнительные предположения о РХД, например, что все реплики содержат одни и те же данные или что все изменения осуществляются с помощью распределенных транзакций, то можно модифицировать алгоритм 3, повысив его эффективность за счет уменьшения количества пересылаемых сообщений. Это является предметом дальнейшей разработки.
В результате дальнейшей работы предполагается адаптировать рассмотренные в статье алгоритмы для распределенного хранилища данных, все реплики которого содержат одни и те же данные, все обновления одновременно осуществляются на всех узлах с помощью распределенных транзакций. За основу реализации предполагается взять протокол первичного архивирования с удаленной записью. Первичные копии всех данных предполагается разместить на сервере БД, работающим под управлением СУБД Oracle.
Сравнение механизмов репликации в MS SQL Server 2005 и ORACLE Server 10g
В настоящее время технологии репликации данных в информационных системах уделяется все большее внимание. Это обусловлено тем, что предлагаемые разработчиками механизмы репликации данных, не всегда удовлетворяют все возрастающим потребностям распределенных приложений, как в стратегии синхронизации данных, так и в способах разрешения неизбежных конфликтов.
Под конфликтом репликации данных обычно понимаются изменения, сделанные в одних и тех же данных (репликах), находящихся на разных узлах, за промежуток времени между двумя последними сеансами синхронизации данных. Выделяют три типа конфликтов: конфликт обновления, конфликт уникальности, конфликт удаления. Конфликт обновления происходит, когда две транзакции, исходящие с разных узлов, обновляют данные в одной и той строке за промежуток времени между двумя последними сеансами синхронизации данных. Конфликт уникальности происходит, когда две транзакции, исходящие с разных узлов, добавляют строки, в результате чего нарушаются ограничения целостности PRIMARY KEY или UNIQUE. Конфликт удаления происходит, когда транзакция на одном узле удаляет строку, а транзакция на другом узле обновляет или удаляет туже самую строку.
Известны стратегии синхронизации данных, которые исключают возможность возникновения конфликтов, например, синхронная репликация в Oracle, или применение распределенных транзакций в MS SqlServer. Конфликты не могут возникать, потому что изменения происходят одновременно во всех репликах. Однако реализация этих стратегий требует наличие постоянных, надежных, скоростных каналов связи между узлами репликации, что приводит к существенному снижению уровня автономности каждого из узлов. Чтобы повысить уровень автономности каждого из узлов применяются другие стратегии, например, «репликация слияния» в MS SqlServer и «асинхронная репликации на уровне строк» в Oracle.
Возможность возникновения конфликта может быть исключена также за счет использования той или иной модели владения данных. Владение может быть статическим или динамическим. При статическом владении для всех данных жестко определяется единственный узел, который имеет возможность обновлять данные, остальным узлам эти данные доступны только для чтения. Например, в Oracle можно разграничить доступ на обновление таблицы на основании горизонтального(селекции) или вертикального(проекции) разбиения. При динамическом владение, в каждый момент времени, только один узел имеет возможность обновлять данные, однако это право может делегироваться от узла к узлу. Примером подобного подхода являются «модель динамического владения, основанная на последовательности выполняемых действий (workflow)» и «модель динамического владения с передачей маркера (token Passing)» применяемые в Oracle. Первый метод состоит в том, что выделяются атрибуты, значения которых определяют узел, который имеет право обновлять данные. При этом предполагается, что право на обновление будет последовательно переходить от одного узла к другому, после того как будут сделаны все обновления и изменены значения выделенных атрибутов. Суть второго метода состоит в добавление к таблице скрытых от пользователя атрибутов, которые содержат информацию о текущем владельце соответствующих кортежей. Таким образом, решение о возможности обновления данных принимается СУБД на основе информации содержащейся в этих добавленных атрибутах. В этом методе существует возможность передачи права владения от одного узла к другому.
Также существуют возможности предотвращения конфликтов уникальности и конфликтов удаления. Возникновения конфликта уникальности можно избежать, если добавлять к значению, на которое накладывается ограничение уникальности, специальный префикс, который позволяет различать значения, добавленные на разных узлах. В качестве этого префикса может выступать глобальное имя узла. Также возникновение конфликта можно избежать, если поделить множество значений межу узлами непересекающимся образом. Третий способ состоит в использование глобально уникальных значений (в Oracle его можно получить с помощью функции SYS_GUID). Возникновение конфликта удаления можно избежать, если вместо явного удаления строки, делать пометку о ее удаление, а затем в специальном режиме (например, используя процедурную репликацию Oracle) выполнять непосредственное удаление строк.
В том случае, если избежать возможности возникновения конфликта невозможно, необходимо принять меры для разрешения конфликтов. Прежде всего, необходим способ идентификации конфликта. Конфликт уникальности проявляется, когда в результате синхронизации изменений нарушается ограничение целостности. Конфликт удаления выявляется, когда в результате синхронизации изменений, выясняется, что данных, которые должны быть изменены, не существует. Для определения конфликта обновления необходимо определить, какие именно изменения данных считаются конфликтными. В MS SqlServer различаются конфликты на уровне строк и конфликты на уровне столбцов. Конфликт первого типа возникает, когда одна и та же строка была исправлена в различных репликах, при этом, не важно были ли исправлены данные в одних и тех же столбцах или в разных столбцах. Конфликт второго типа возникает в том случае, если были изменены данные в одних и тех же столбцах. В Oracle применяется более гибкий подход, основанный на выделение групп атрибутов. Конфликт фиксируется, если произошли изменения данных, входящих в одну группу атрибутов. В предельных случаях, если имеется только одна группа, получаем аналог определения конфликта на уровне строк в MS SqlServer, в случае, если каждый столбец выделен в отдельную группу, получаем аналог определения конфликта на уровне столбцов в MS SqlServer.
В Oracle и MS SqlServer существуют разные способы диагностики изменений в атрибутах. В Oracle используется сравнение текущего значения на изменяемом узле с эталонным, расположенном на узле, инициирующем обновление. Если эти значения различаются, то фиксируется конфликт. В MS SqlServer для определения изменений используются множественные версии данных атрибутов, которые сравниваются при каждом сеансе синхронизации. Конфликт фиксируется при различии в версиях данных. Сами версии хранятся в специальных таблицах.
В обеих СУБД имеется широкий набор, встроенных методов разрешения конфликтов которые можно использовать. Эти методы описаны ниже.
Методы разрешения конфликтов уникальности
В Oracle существует три способа разрешения конфликтов уникальности:
- Добавление глобального имени узла источника к значению столбца, полученного от узла источника.
- Добавление значения, сгенерированного с помощью последовательности, к значению столбца, полученного от узла источника.
- Отбрасывание строки, полученной от узла источника, которая вызвала конфликт.
Первые два метода направлены на максимальное распространение данных, возможно, в ущерб непротиворечивости. Последний метод, наоборот, препятствует распространению данных, пока не будет достигнута их непротиворечивость.
Методы разрешения конфликтов удаления
Ни Oracle ни MS SqlServer не имеют средств для разрешения конфликтов удаления.
Методы разрешения конфликтов обновления
Приоритет узла (Site priority в Oracle и MS SqlServer)
При разрешении конфликта выбирается обновление, которое сделано на узле с наибольшим приоритетом.
В Oracle это метод является разновидностью более общего метода «группа приоритетов» (Priority group). В MS SqlServer этот метод является методом разрешения конфликта по умолчанию.
В Oracle для использования этого метода необходимо в системной таблицы задать значения приоритетов для всех узлов в среде репликации, а также в реплицируемой таблице создать столбец, который будет хранить имя узла. В SqlServer также необходимо задать приоритеты узлов. Это можно сделать явно(глобальная подписка) или неявно(локальная подписка). В случае использования локальной подписки при расчете приоритета используется приоритет узла издателя (Publisher). В Oracle метод может применяться для любых групп столбцов. В MS SqlServer метод может применяться как в случае отслеживания изменений на уровне столбцов(column-level tracking), так и при отслеживании изменений на уровне строк(row-level tracking).
Сложение(Additive в Oracle и MS SqlServer)
Данный метод не выбирает одно из конфликтующих обновлений, а вместо этого объединяет результаты обновление в одно результирующие значение. В Oracle результат рассчитывается по формуле: current value = current value + (new value - old value), где current value - значение на узле приемнике (destination site), а new value и old value - соответственно новое и старое значение на узле источнике (originating site). Таким образом, к значению на узле приемнике добавляется изменение, сделанные на узле источнике за время, прошедшее после последнего сеанса синхронизации. В MS SqlServer результат рассчитывается по формуле: current value = current value + new value. Т.е. результат является простой суммой конфликтующих обновлений.
Применение этого метода требует наличие в таблице столбца целочисленного типа. В Oracle метод может применяться только для групп столбцов состоящих из одного столбца. В MS SqlServer метод может применяться, только если изменения отслеживаются на уровне столбцов.
Усреднение(Average в Oracle и MS SqlServer)
Данный метод также не выбирает одно из конфликтующих обновлений, а вместо этого объединяет результаты обновление в одно результирующие значение, путем усреднения, т.е. по формуле current value = (current value + new value)/2.
Ограничения на применения метода такие же, как и для предыдущего метода.
Последняя временная метка(Latest Timestamp в Oracle, DATETIME (Earlier Wins) в MS SqlServer)
В результате разрешения конфликта этим методом, выигрывает обновление, имеющие более позднюю временную метку. Сравнение значений осуществляется непосредственно, без учета различий во временных зонах. В случае совпадения значений временных меток метод не может разрешить конфликт.
Применение этого метода требует наличие в таблице столбца, для хранений значения времени обновления, а также специальной логики для формирования этого значения для каждой операции обновления или удаления. В Oracle метод может применяться для любых групп столбцов. В MS SqlServer метод может применяться как в случае отслеживания изменений на уровне столбцовтак и при отслеживании изменений на уровне строк.
Первая временная метка(Earliest Timestamp в Oracle, DATETIME (LaterWins) в
MS SqlServer)
В результате разрешения конфликта этим методом, выигрывает обновление, имеющие более раннюю временную метку.
Ограничения на применения метода и замечания, связанные с его применением, такие же, как и для предыдущего метода.
Максимальное значение (Maximum в Oracle и MS SqlServer)
При разрешении конфликта из конфликтующих обновлений выбирается обновление с максимальным значением. В случае совпадения значений метод не может разрешить конфликт.
Для применения метода в таблице должен быть столбец, тип данных которого допускает операцию сравнения. В Oracle метод может применяться для любых групп столбцов. В MS SqlServer метод может применяться как в случае отслеживания изменений на уровне столбцовтак и при отслеживании изменений на уровне строк.
Минимальное значение (Minimum в Oracle и MS SqlServer)
При разрешении конфликта из конфликтующих обновлений выбирается обновление с минимальным значением. В случае совпадения значений метод не может разрешить конфликт.
Ограничения на применения метода такие же, как и для предыдущего метода.
Текстовое слияние (Merge Text в MS SqlServer)
Этот метод подобно методам «сложение» и «усреднение» не выбирает одно из конфликтующих обновлений, а вместо этого объединяет результаты обновление в одно результирующие значение. Осуществляется это следующим образом: сначала идет общий префикс, затем значение источника, и в конце значение приемника.
Для применения метода в таблице должен быть столбец текстового типа. Метод может применяться, только если изменения отслеживаются на уровне столбцов.
Подписчик всегда выигрывает (Subscriber Always Wins в MS SqlServer)
Обновление от Подписчика всегда побеждает в конфликте, не зависимо от того является ли подписчик источником или приемником.
Метод может применяться для всех типов конфликтов.
Группа приоритетов (Priority group в Oracle)
Каждому допустимому значению домена столбца ставится в соответствие приоритет. При разрешении конфликта выбирается обновление, которое имеет наибольший приоритет.
Для применения метода в системной таблице необходимо задать имя группы приоритетов и значение приоритета для каждого из возможных значений домена столбца. Метод может применяться для любых групп столбцов.
Отбрасывание(Discard в Oracle)
В результате разрешение конфликта эти методом значение, полученное от узла источника, отбрасывается, т.е. значение на узле приемнике остается неизмененным.
Никаких дополнительных условий для применения метода не требуется. Метод может применяться для любых групп столбцов.
Перезапись (Overwrite в Oracle)
В результате разрешение конфликта эти методом значение, значение на узле приемнике перезаписывается значением от узла источника.
Никаких дополнительных условий для применения метода не требуется. Метод может применяться для любых групп столбцов.
Также обе СУБД позволяют задать собственные методы разрешения конфликтов.
Однако, несмотря на то, что в современных СУБД существуют развитые средства, позволяющие как предотвращать возникновение конфликтов, так и разрешать возникающие конфликты, возникают задачи, которые требуют разработки и реализации новых методов предотвращения и разрешения конфликтов.