Стратегия резервного копирования и восстановления из копии для репликации слиянием
Для репликации слиянием регулярно создавайте резервные копии следующих баз данных:
База данных публикаций на издателе.
База данных распространителя на распространителе.
База данных подписок на каждом подписчике.
Системные базы данных master и msdb на издателе, распространителе и на всех подписчиках. Резервные копии этих баз данных и копия соответствующей базы данных репликации должны быть сделаны одновременно. Например, создавайте резервную копию баз данных master и msdb на издателе одновременно с резервной копией базы данных публикаций. Если база данных публикаций восстановлена, убедитесь, что базы данных master и msdb согласованы с базой данных публикаций по настройке и конфигурации репликации.
Если резервное копирование журналов выполняется регулярно, любые изменения, касающиеся репликации, будут заноситься в резервные копии журнала. Если резервные копии журналов не создаются, резервное копирование следует выполнять при каждом изменении параметров репликации. Дополнительные сведения см. в разделе Общие действия, для которых необходима обновленная резервная копия.
Выберите один из описываемых далее подходов к резервному копированию и восстановлению базы данных публикаций, затем следуйте рекомендациям, приведенным для базы данных распространителя и базы данных подписок.
Резервное копирование и восстановление базы данных публикаций
Существует два подхода к восстановлению базы данных публикаций слиянием. После восстановления базы данных публикаций из резервной копии следует:
Либо синхронизировать базу данных публикаций с базой данных подписок.
Либо повторно инициализировать все подписки на публикации в базе данных публикаций.
Применение любого их этих методов гарантирует, что после восстановления издатель и все подписчики будут синхронизированы.
.gif "Примечание") Примечание |
|---|
Если какие-либо таблицы содержат столбцы идентификаторов, следует обеспечить после восстановления назначение правильных диапазонов идентификаторов. Дополнительные сведения см. в разделе Репликация столбцов идентификаторов. |
Синхронизация базы данных публикаций
Синхронизация базы данных публикаций с базой данных подписок позволяет загружать из одной или нескольких баз данных подписок те изменения, которые были сделаны ранее в базе данных публикаций, но не были представлены в восстановленной резервной копии. Передаваемые данные зависят от того, как отфильтрованы публикации:
Если публикации не отфильтрованы, должна существовать возможность обновления базы данных публикаций посредством синхронизации с самым обновленным подписчиком.
Если же публикация отфильтрована, то базу данных публикации, возможно, не удастся обновить. Продумайте таблицу, которая разделена так, что каждая подписка получает данные клиентов только из одного региона: север, восток, юг и запад. Если существует по крайней мере один подписчик из каждой секции данных, синхронизация с подписчиком из каждой секции должна обновить базу данных публикаций. Однако если данные в западной секции, например не были реплицированы на какие-либо подписчики, эти данные на издателе невозможно будет обновить.
.gif "Важное примечание") Важно! |
|---|
Результатом синхронизации базы данных публикаций с базой данных подписок может быть восстановление опубликованных таблиц до более современного состояния, чем состояние других неопубликованных таблиц, восстановленных из резервной копии. |
Если выполняется синхронизация с подписчиком, использующим версию MicrosoftSQL Server, предшествующую MicrosoftSQL Server 2005, то подписка не может быть анонимной; это должна быть клиентская или серверная подписка (называвшиеся в предыдущих версиях локальными и глобальными подписками).
Синхронизация подписки
MicrosoftSQL Server Management Studio: Как синхронизировать принудительную подписку (среда SQL Server Management Studio)
SQL Server Management Studio: Как синхронизировать подписку по запросу (среда SQL Server Management Studio)
Программирование репликации на языке Transact-SQL: Как синхронизировать принудительную подписку (программирование репликации)
Программирование репликации на языке Transact-SQL: Как синхронизировать подписку по запросу (программирование репликации)
Повторная инициализация всех подписок
Повторная инициализация всех подписок гарантирует, что все подписчики находятся в состоянии, согласованном с восстановленной базой данных публикаций. Такой подход следует применять, если требуется вернуть всю топологию в предыдущее состояние, представленное резервной копией базы данных публикаций. Например, повторная инициализация всех подписок может потребоваться, если восстановление базы данных публикаций до более ранней точки используется в качестве механизма возврата из ошибочно выполненной пакетной операции.
Если выбран данный вариант, создайте новый моментальный снимок для его доставки на повторно инициализированные подписчики сразу после восстановления базы данных публикаций.
Повторная инициализация подписки
SQL Server Management Studio: Как повторно инициализировать подписку (среда SQL Server Management Studio)
Программирование репликации с помощью Transact-SQL. Как повторно инициализировать подписку (программирование репликации на языке Transact-SQL)
Создание и применение моментального снимка
SQL Server Management Studio: Как создать и применить исходный моментальный снимок (среда SQL Server Management Studio)
Программирование репликации с помощью Transact-SQL. Как создать исходный моментальный снимок (программирование репликации на языке Transact-SQL)
SQL Server Management Studio: Как создать моментальный снимок для публикации слиянием с параметризованными фильтрами (среда SQL Server Management Studio)
Программирование репликации на языке Transact-SQL: Как создать моментальный снимок в публикации слиянием с параметризованными фильтрами (программирование репликации на языке Transact-SQL)
Резервное копирование и восстановление базы данных распространителя
При репликации слиянием база данных распространителя должна регулярно подвергаться резервному копированию, и она может быть восстановлена без дополнительных условий до тех пор, пока время, истекшее с момента создания используемой резервной копии, не превышает кратчайший срок хранения всех публикаций, использующих распространитель. Например, если есть три публикации со сроками хранения 10, 20 и 30 дней соответственно, то используемая резервная копия не должна быть старше 10 дней. База данных распространителя играет ограниченную роль в репликации слиянием: она не хранит данных, используемых для отслеживания изменений, и не служит временным хранилищем изменений репликации слиянием, которые должны пересылаться в базы данных подписок (как это делается при репликации транзакций).
Резервное копирование и восстановление базы данных подписок
Чтобы гарантировать успешное восстановление базы данных подписок, подписчики должны синхронизироваться с издателем до резервного копирования базы данных подписок; подписчики также должны синхронизироваться после восстановления базы данных подписок.
Синхронизация с издателем до резервного копирования базы данных подписок гарантирует, что если подписчик восстанавливается из резервной копии, подписки все равно будут находиться в пределах срока хранения публикации. Например, предположим, что срок хранения публикации равен 10 дням. Последняя синхронизация была 8 дней назад, а теперь выполняется резервное копирование. Если через 4 дня будет произведено восстановление из резервной копии, то последняя синхронизация окажется 12-дневной давности, то есть за пределами срока хранения публикации. В этом случае потребуется повторная инициализация подписчика. Если подписчик был синхронизован перед резервным копированием, база данных подписок будет находиться в пределах срока хранения публикации.
Время с момента создания резервной копии не должна превышать кратчайший срок хранения всех публикаций, на которые подписывается подписчик. Например, если подписчик подписывается на три публикации со сроками хранения 10, 20 и 30 дней соответственно, то резервная копия, используемая для восстановления, не должна быть старше 10 дней.
Синхронизация базы данных подписок с каждой из ее публикаций после восстановления гарантирует, что подписчик обновлен в соответствии со всеми изменениями издателя.
Установка срока хранения публикации
SQL Server Management Studio: Как установить срок действия подписок (среда SQL Server Management Studio)
Программирование репликации с помощью Transact-SQL. Как установить срок действия подписок (программирование репликации на языке Transact-SQL)
Синхронизация подписки
SQL Server Management Studio: Как синхронизировать принудительную подписку (среда SQL Server Management Studio)
SQL Server Management Studio: Как синхронизировать подписку по запросу (среда SQL Server Management Studio)
Программирование репликации на языке Transact-SQL: Как синхронизировать принудительную подписку (программирование репликации)
Программирование репликации на языке Transact-SQL: Как синхронизировать подписку по запросу (программирование репликации)
Резервное копирование и восстановление переиздаваемой базы данных
Когда база данных подписывается на данные издателя и в свою очередь публикует те же самые данные для других баз данных подписок, ее называют переиздающей базой данных. При восстановлении переиздающей базы данных следуйте инструкциям, описанным в подразделах «Резервное копирование и восстановление базы данных публикаций» и «Резервное копирование и восстановление базы данных подписок» этого раздела.
См. также