SQL.RU
 client/server technologies
 Главная | Документация | Статьи | Книги | Форум | Блоги | Опросы | Гостевая | Рассылка | Работа | Поиск | FAQ |

Резервное копирование в репликации SQL Server

ПУБЛИКАЦИИ  

Автор Александр Гладченко. SQL Server MVP.

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

Стратегии резервирования

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

  • Публикуемые базы, master и msdb
  • Публикуемые базы, distributor, master и msdb
  • Публикуемые базы, подписываемые базы, master и msdb
  • Публикуемые базы, подписываемые базы, distributor, master и msdb

Эти стратегии могут быть расширены за счёт вовлечения в резервирование системных баз данных подписчиков или дистрибутора, если он работает на выделенном сервере.
Создание полных резервных копий публикуемых баз данных на издателе и использование имеющейся в репликации SQL Server возможности повторной инициализации одной или нескольких подписок, является наиболее простой стратегией резервирования. Эта стратегия может использоваться при большом числе обычных или мобильных подписчиков, администрирование баз данных которых затруднено или невозможно. Для полного восстановления репликации, достаточно будет иметь полную резервную копию публикуемых баз и заскриптовать саму репликацию. Главным недостатком этой стратегии является то, что в случае отказа дистрибутора или издателя придётся заново устанавливать репликацию.
Более надёжной (но всё ещё простой) стратегией является резервирование издателя и дистрибутора в тот момент, когда они синхронизированы. Эта стратегия также позволяет полностью восстанавливать репликацию. Резервное копирование подписчиков является не обязательным, но оно может уменьшить время возобновления работы подписчиков.
Если ваша бизнес - логика приложений требует немедленного восстановления репликации, можно рассмотреть более сложные схемы резервирования и стратегии восстановления, которые будут описаны ниже в этой статье.
В большинстве сценариев резервирования, публикуемые базы данных и дистрибутор должны резервироваться сразу после добавления или изменения объектов репликации, например, статей и подписок или после того, как вносятся изменения в схему, затрагивающие репликацию. Если база данных дистрибутора будет восстановлена на тот момент времени, когда такие изменения ещё небыли внесены, необходимо восстановить публикуемую базу данных на этот же момент времени. Из этого можно сделать вывод, что время серверов, участвующих в репликации должно автоматически синхронизироваться. Для синхронизации времени серверов можно использовать возможности службы времени операционных систем Windows 2000/2003/XP или мультисерверное администрирование SQL Server 2000.
Как часть любой стратегии резервирования, всегда сохраняйте текущие скрипты репликации и параметры её настройки (профили, параметры запуска агентов, скрипты заданий запускающих агентов и т.п.) в надёжном и безопасном месте. Также очень полезно иметь скрипты создания и удаления репликации.
В SQL Server 2000 появилась возможность восстановления издаваемых или подписанных баз данных на другом сервере или на том же сервере, но с другим именем. Для этого в команду RESTORE нужно добавить опцию KEEP_REPLICATION. По умолчанию, при восстановлении издаваемой или подписанной в репликации слиянием базы данных на другом сервере вся информация о репликации будет утеряна. Если же нужно наоборот, удалить информацию о репликации после восстановления на том же сервере, запустите системную хранимую процедуру sp_restoredbreplication, которая удалит все относящиеся к репликации метаданные.

[В начало]

Резервное копирование издателя

Публикуемые базы данных являются наиболее важным и уязвимым звеном топологии репликации, поэтому, даже самый простой план резервирования должен включить полное резервное копирование издателей. Резервное копирование издателя должно быть регулярным и кроме полной копии издаваемой базы должно включать резервирование журнала транзакций и/или дифференциальное резервирование. Также можете копировать базы master и msdb, чтобы обезопасится от полной потери системы, а не только пользовательских баз данных. Если используется Log Shipping, обязательно регулярно копируете системную базу данных msdb (которая используется для учёта передачи копий журнала). Также, нужно делать резервные копии после внесения любых изменений в публикации или выполнения процедур по обслуживанию публикуемой базы данных.
Перед тем, как приступить к восстановлению издателя после полного системного краха или потери издаваемых баз данных, нужно с помощью системной хранимой процедуры sp_replicationdboption отметить восстанавливаемые базы данных, как участвующие в репликации соответствующего типа. Если этого не сделать, то информация о принадлежности к репликации не будет восстановлена.

[В начало]

Резервное копирование дистрибутора

Резервное копирование дистрибутора подразумевает резервное копирование базы данных distribution и системных баз данных msdb и master. Это позволяет восстановить его работоспособность практически после любого его отказа, без необходимости пересоздания публикаций или реконфигурации репликации.
Резервное копирование дистрибутора позволяет хранить данные о моментальных снимках публикаций, о хронологии сеансов репликации, об ошибках и другую информацию агентов репликации. Имея такую копию, можно ускорить восстановление издателя и дистрибутора, поскольку не потребуется переустанавливать репликацию. Особенностью в репликации транзакций является то, что её стратегия резервирования требует координации между резервным копированием баз данных публикаций и дистрибуторов. SQL Server 2000 умеет выполнять такую координацию автоматически. Резервируйте базу distribution, а затем делайте резервные копии журнала транзакций и дифференциальные резервные копии этой базы данных. Восстанавливать базу данных дистрибуции нужно синхронно с восстановлением издаваемой базой данных. После восстановления базы дистрибуции стоит проверить параметры профилей используемых агентов репликации, чтобы убедиться в их соответствии бизнес - требованиям приложения.
На одном сервере, исполняющем роль дистрибутора, может находиться несколько баз данных дистрибуции для разных издателей. В такой конфигурации, важно следить за координацией резервирования издателей и базы дистрибутора, что бы за счёт этого сократить время на реинициализацию подписчиков.

[В начало]

Резервное копирование подписчика

Простая стратегия резервирования может основываться на реинициализации подписок вместо восстановления их из резервной копии, и может быть расширена за счёт добавления в план резервирования создания полных резервных копий каждой подписанной базы данных и системных баз подписчика msdb и master. Базы данных msdb и master необходимо копировать, если используется pull - подписка и это потребуется только при восстановлении после потери всей системы.
Нужно делать полную резервную копию подписанной базы данных, а затем делать резервные копии журнала транзакций и дифференциальные копии базы.
Обратите внимание на то, что резервное копирование каждого подписчика не является обязанным для восстановления репликации после отказа. В большинстве случаев, регулярное резервирование издателя и дистрибутора достаточно для решения этой задачи. Если затраты на реинициализацию подписчика значительно больше чем на его восстановление из резервной копии, и сложность управления резервным копирование в масштабе всего предприятия не велика, Вы можете рассмотреть возможность расширения схемы резервирования резервным копированием подписчиков. Кроме того, если в репликации задействовано только несколько статей и на подписчике существуют таблицы, которые не могут быть реинициализированы, Вам также потребуется резервировать базы данных на подписчиках. Понадобится это и при переиздании участвующих в репликации статей.

[В начало]

Резервирование баз данных master model, msdb и distribution

Базы данных master, model, msdb и distribution резервируются так же, как и пользовательские базы, и для них (если имеются изменения) эта операция тоже должна выполняться регулярно. Во избежание конкуренции с системными объектами, не рекомендуется создавать в этих базах пользовательские объекты. Также, следует быть осторожным при использовании утилиты восстановления системных баз данных rebuildm.exe, т.к. в процессе её работы все системные базы данных заменяются шаблонами из дистрибутива и хранимая в системных базах информация будет утеряна. При выборе стратегии резервирования, нужно учитывать тот факт, что базы master, model, msdb и distribution поддерживают все существующие модели резервирования, от полной до простой.
База данных master издателя хранит в таблице sysservers информацию о подписчиках. В такой же таблице базы данных master на дистрибуторе хранится информация об издателях. Для обеспечения возможности восстановления репликации после потери издателя или дистрибутора, делайте резервные копии их баз master после изменений числа подписчиков или издателей. Наиболее важной таблицей базы данных master является sysdatabases, т.к. от того, сохранятся ли правильные значения в поле category для реплицируемых баз, зависит успешность их дальнейшего восстановления без потери настроек публикаций. Для репликации транзакций или моментальных снимков это поле должно содержать единицу, а для репликации слиянием - четвёрку. При восстановлении базы данных на тот же сервер, где была выполнена её копия, SQL Server анализирует установленное для этой базы в поле master.dbo.sysdatabases.category значение, по которому ему становится ясно, нужно ли сохранять настройки репликации при восстановлении. Для того, что бы явно указать, что восстанавливаемая база данных является публикуемой в репликации транзакций или слиянием, нужно использовать системную хранимую процедуру sp_replicationdboption.
База данных msdb используется SQL Server Agent, Enterprise Manager и SQL Server для хранения информации о заданиях и их расписаниях, о резервных копиях и их хронологии. Информация в этой базе изменяется при планировании заданий, при сохранении DTS пакетов, при резервировании и восстановлении, а также во время сеансов репликации. SQL Server автоматически сохраняет данные о выполненном резервном копировании и хронологию восстановления данных в базе msdb. Запоминается, кто выполнил резервирование, в какое время и в каких устройствах или файлах хранится резервная копия. Именно эту информацию использует Enterprise Manager для вычисления плана восстановления базы данных с учётом необходимой для правильного восстановления хронологии восстановления копий журнала транзакций и дифференциальных копий. Операция резервного копирования для любых баз данных запоминаются, даже если они были выполнены из других приложений, не поставляемых в дистрибутиве сервера баз данных (например, использующих для этого SQL-DMO).
Если Вы используете для резервирования и/или восстановления информацию о хронологии из базы msdb, рекомендуется установить для неё полную модель резервирования (Full Recovery model). В дополнение к этому, стоит разместить журнал транзакций базы msdb на устойчивой к сбоям дисковой подсистеме.
Если база данных msdb будет повреждена, и не будет актуальной резервной копии, то вся информация планировщика SQL Server Agent будет потеряна и её придётся восстанавливать вручную. Также будет утеряна информация о хронологии резервирования.
База данных distribution используется такими компонентами репликации SQL Server, как агент дистрибуции (Distribution Agent), агенты чтения журнала транзакций (Log Reader Agents), агент создания моментальных снимков (Snapshot Agent) и агент репликации слиянием (Merge Agent). Она хранит информацию о транзакциях, моментальных снимках, о состоянии синхронизации, и о хронологии репликации. Такая база данных располагается на сервере, который исполняет роль дистрибутора или совмещает эту роль с ролью издателя. Меньше всего от базы данных distribution зависит репликация слиянием (merge).
Если база данных distribution будет повреждена, и не будет актуальной резервной копии, то вся информация о репликации, используемая утилитами репликации SQL Server, будет потеряна и её придётся восстанавливать вручную. По этой причине, рекомендуется установить для базы distribution модель резервирования Full Recovery и расположить её журнал транзакций на устойчивой к сбоям дисковой подсистеме.
База данных model является шаблоном, используемым SQL Server при создании других баз данных, например, tempdb или пользовательских баз. После создания базы данных, все объекты базы данных model, включая её настройки, будут скопированы в новую базу данных.
База данных model непосредственно не задействуется в репликации, но нужна при создании новых баз с преопределёнными в ней настройками. Поэтому, резервную копию этой базы достаточно создавать при внесении в неё изменений.
Если база данных model будет повреждена, и не окажется её актуальной резервной копии, все изменения шаблона создания пользовательских баз данных будут потеряны и их придётся восстанавливать вручную.

[В начало]

Стратегии для репликации моментальных снимков

Стратегии резервирования/восстановления в репликации моментальных снимков являются самыми лёгкими для реализации и сопровождения. К тому же, поскольку этот тип репликации создаёт моментальные снимки публикаций, которые содержат не только данные, но и схему, нет необходимости резервировать публикуемую базу так же часто, как это делается в репликации транзакций или репликации слиянием. Хорошей практикой является резервное копирование публикуемой базы данных сразу после внесения изменений в настройки или схему существующих публикаций или после добавления новых.
Вместе с издателем нужно резервировать и дистрибутора, что бы при необходимости восстановления они были синхронны. Во время их резервирования нельзя создавать новые моментальные снимки, публикации или добавлять подписчиков. Перед резервным копированием дистрибутора, полезно запустить на исполнение автоматически создаваемую мастерами репликации задачу Distribution Cleanup, после чего из базы данных дистрибутора будет удалена уже ненужная информация. Это может позволить сократить время генерации снимков и создания резервных копий базы distribution.
Во всём остальном, стратегия резервирования участвующих в репликации моментальных снимков баз данных не отличается от стратегии резервирования обычных пользовательских баз.

[В начало]

Стратегии для репликации транзакций

В отличие от более ранних версий, в SQL Server 2000 существует возможность восстановления издаваемых баз и базы дистрибутора, без необходимости реинициализации подписчиков или отключения/реконфигурации публикаций и дистрибутора. После восстановления, SQL Server 2000 автоматически скоординирует эти базы данных. Ещё одним нововведением SQL Server 2000 является возможность совместного использования без необходимости специальных настроек репликации транзакций и службы синхронизации журнала с резервным сервером (log shipping).
Для обеспечения возможности восстановления издателя и дистрибутора на любой, заданный момент времени, необходимо для этих баз данных SQL Server 2000 включить опцию синхронизации реплицируемой базы данных с резервной копией. Делается это с помощью системной хранимой процедуры sp_replicationdboption, синтаксис вызова которой следующий:


EXEC sp_replicationdboption '<имя базы данных>', 'sync with backup', 'true'

При этом, Log Reader Agent, даже работая в непрерывном режиме, будет предоставлять дистрибутору для тиражирования только те транзакции, которые уже были скопированы из журнала транзакций в резервную копию. Т.о. нужно учитывать этот факт при задании расписания запуска резервного копирования журнала транзакций, что бы оно выполнялось достаточно часто, в соответствии с бизнес - требованиями приложения ко времени тиражирования транзакций дистрибутором подписчикам. Этот механизм позволяет иметь в резервной копии издаваемой базы данных все необходимые для синхронного восстановления с дистрибутором транзакции.
Проверить, включена ли опция синхронизации с резервной копией можно с помощью системной функции DATABASEPROPERTYEX, например так:


SELECT DATABASEPROPERTYEX('<имя базы данных>', 'IsSyncWithBackup')

Из логики работы описываемого механизма следует, что издаваемые базы данных и база дистрибутора должны иметь полную модель резервирования, т.е. нужно отключить опцию trunc. log on chkpt.
В случае если Вы не включаете опцию синхронизации с резервной копией или не можете это сделать по каким либо причинам, восстановление издаваемых баз и базы дистрибутора возможно, но без реинициализации подписчиков может быть нарушена целостность тиражируемых данных, а данные издателя и подписчиков могут оказаться не синхронными. После восстановления издаваемой базы из резервной копии, запуск Log Reader - агента будет сопровождаться ошибкой, вызванной несогласованным состоянием с базой данных дистрибутора. Вызвав без параметров системную процедуру sp_replrestart, можно принудительно возобновить репликацию, а за счёт добавления параметра запуска агента дистрибуции (Distribution Agent) -SkipError, можно добиться работы этого агента с игнорированием ошибок, вызванных потерей синхронности с подписчиками.
Восстановление базы данных на подписчике тоже может быть выполнено без необходимости его реинициализации. Для этого, нужно установить для дистрибутора равный, по умолчанию, нулю период хранения тиражируемых транзакций (minimum transaction retention period) на такой срок, что бы он был заведомо больше времени между резервными копиями журнала транзакций подписанной базы.
Каждая подписанная база данных содержат таблицу MSreplication_subscriptions, в которой хранятся данные о последних тиражированных подписчику транзакциях. Информация из этой таблицы используется для синхронизации версий реплицируемых объектов. После восстановления базы данных подписчика на том же сервере, версия которого отличается от сохранённой в резервной копии, для синхронизации версий объектов нужно выполнить системную хранимую процедуру sp_vupgrade_subscription_tables.

[В начало]

Стратегии репликации слиянием

Базы данных, участвующие в репликации слиянием, тоже могут быть восстановлены без необходимости последующей реинициализации подписчиков и настройки публикации и подписок. Для этого используются последние данные, имеющихся на других серверах, которые можно синхронизировать с изменениями, не сохранёнными в последней резервной копии. Этот тип репликации также можно совмещать со службой синхронизации журнала транзакций и резервного сервера (log shipping).
В репликации слиянием, все изменения данных фиксируются только в системных таблицах метаданных в публикуемой базе и в базах подписчиков, вследствие чего, отпадает необходимость в согласованности данных издателя и дистрибутора. Таблицы метаданных попадают в резервную копию так же, как и другие таблицы издаваемой или подписанной базы и поэтому отражаемое метаданными состояние синхронизации подписчиков и издателя будет восстановлено в том виде, в каком оно попало в резервную копию. При этом гарантируется конвергенция данных во всех резервных копиях участвующих в репликации баз.
После восстановления издаваемой базы данных, можно просто реинициализировать всех подписчиков, что позволит привести их данные в соответствии с новым состоянием издателя. Однако, до реинициализации, можно синхронизировать издателя с теми подписчиками, у которых имеются последние данные, отсутствующие в резервной копии издателя. Т.о. потери данных не будет. Такую предварительную загрузку недостающих изменений можно сделать только с тех подписчиков, которые не являются анонимными и имеют полный комплект метаданных. Метод реинициализации применим и в том случае, если восстановление издателя выполняется на заданный момент времени, предшествующий выполненным в базе ошибочным действиям. После восстановления правильного состояния, создания моментального снимка и реинициализации всех подписчиков, все участвующие в репликации базы данные будут тоже приведены к правильному состоянию.
Резервную копию базы подписчика нужно создавать после успешной синхронизации с издателем. Если такая синхронизация, по каким либо причинам, выполнялась давно, возрастает вероятность того, что относящиеся к актуальному на момент резервирования состоянию метаданные будут автоматически очищены (превышен retention period). В таком случае, синхронизировать данные подписчика с издателем без реинициализации будет невозможно. Если же резервная копия подписчика достаточно актуальна, то после восстановления по имеющимся метаданным подписчику будут переданы все изменения, которые происходили в реплицируемых данных после последней резервной копии подписчика. При этом реинициализация не потребуется.
В случае переиздания подписанной базы или использования базы данных подписчика в качестве альтернативного партнёра репликации, стратегия её резервирования должна удовлетворять изложенным выше требованиям к издаваемой базе и базе подписчика.
Поскольку в репликации слиянием нет существенных отличий между базами данных издателя и подписчиков, требования по резервированию и восстановлению у них практически одинаковы.

[В начало]

Автор: Александр Гладченко  2004г.

Rambler's Top100 Рейтинг@Mail.ru  Administrator: Обратная связь 
Copyright: SQL.Ru 2000-2013