Репликация и доставка журналов (SQL Server)

Область применения:SQL Server

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

Доставка журналов транзакций может использоваться вместе с репликацией; при этом наблюдается следующее поведение:

• Репликация не продолжается после отработки отказа доставки журналов. Если происходит переключение при отказе, агенты репликации не подключаются к вторичной реплике, поэтому транзакции не реплицируются на подписчики. При обратном переключении на основной узел репликация возобновляется. Все транзакции, которые при доставке журналов транзакций копируются обратно со вторичной базы данных на основную, реплицируются на подписчиков.

• Если основная реплика безвозвратно потеряна, вторичную реплику можно переименовать, чтобы репликация могла продолжаться. Далее описываются требования и процедуры, которым необходимо следовать при обработке данного случая. В качестве примера приводится база данных публикаций, которая чаще всего используется для регистрации отправки, но аналогичный процесс может быть применён и к базам данных подписки и распространения.

Сведения о восстановлении баз данных, задействованных в процессе репликации, без изменения настроек репликации см. в статье Создание резервной копии и восстановление из копий реплицируемых баз данных.

Примечание.

Используйте группы доступности Always On, а не доставку журналов транзакций, для обеспечения доступности базы данных публикации. Дополнительные сведения см. в разделе Настройка репликации с группами доступности Always On.

Требования и процедуры для репликации со вторичной базы данных в случае потери основной базы данных

Учитывайте следующие требования и замечания.

• Если на основном сервере имеется несколько баз данных публикаций, настройте доставку журналов для всех баз данных публикаций на один и тот же вспомогательный сервер.

• Путь установки вторичного экземпляра сервера должен совпадать с путем установки первичного экземпляра. Места нахождения баз данных пользователя на сервере-получателе должны совпадать с местами нахождения на сервере-источнике.

• Создайте резервную копию главного ключа службы на основном сервере. Этот ключ будет восстановлен на вторичном сервере. Дополнительные сведения см. в разделе BACKUPSERVICEBACKUP SERVICE MASTER KEY (Transact-SQL).

• Доставка журналов не гарантирует сохранности данных. Сбой базы данных-источника может вызвать потерю тех данных, для которых не была создана резервная копия, а также данных, резервные копии которых были утеряны из-за сбоя.

Доставка журналов транзакций с транзакционной репликацией

Для репликации транзакций способ доставки журналов зависит от параметра sync with backup . Этот параметр можно задать в базе данных публикаций и в базе данных распространения; при пересылке журналов транзакций для Издателя имеет значение только параметр, заданный в базе данных публикаций.

Установка этого параметра для базы данных публикации гарантирует, что транзакции не будут доставлены в базу данных распространителя до тех пор, пока не будет создана их резервная копия в базе данных публикации. Затем последняя резервная копия базы данных публикации может быть восстановлена на сервере-получателе, при этом в базе данных распространителя не будет транзакций, отсутствующих в восстановленной базе данных публикации. Этот параметр гарантирует, что при аварийном переключении Издателя на резервный сервер сохраняется согласованность между Издателем, Распространителем и Подписчиками. Затрагиваются задержка и пропускная способность, так как транзакции нельзя доставить в базу данных распространителя до тех пор, пока для них не созданы резервные копии на издателе. Если ваше приложение может работать с такой задержкой, рекомендуется установить этот параметр в базе данных публикации. Если параметр sync with backup не установлен, подписчики могут получать изменения, которые более не включены в восстановленную базу данных на сервере-получателе. Дополнительные сведения см. в статье Стратегии резервного копирования и восстановления репликации моментальных снимков и репликации транзакций.

Настройка репликации транзакций и доставки журналов с параметром «sync with backup»

1. Если параметр «синхронизация с резервной копией» не задан для базы данных публикации, выполните sp_replicationdboption '<publicationdatabasename>', 'sync with backup', 'true'. Дополнительные сведения см. в статье sp_replicationdboption (Transact-SQL).

2. Настройте доставку журналов транзакций для базы данных публикаций. Дополнительные сведения см. в разделе Настройка доставки журналов (SQL Server).

3. Если Publisher выходит из строя, восстановите на вторичный сервер последнюю резервную копию журнала транзакций базы данных, используя параметр KEEP_REPLICATION команды RESTORE LOG. Это действие сохранит все настройки репликации для базы данных. Дополнительные сведения см. в разделе Переключение на дополнительный сервер доставки журналов (SQL Server) и RESTORE (Transact-SQL).

4. Восстановите базы данных msdb и master с основного сервера на дополнительный. Дополнительные сведения см. в статье Резервное копирование и восстановление системных баз данных (SQL Server). Если первичный сервер также был Распространителем, восстановите базу данных распространения с первичного сервера на вторичный.

   Эти базы данных должны соответствовать базе данных публикации на основном сервере по конфигурации и параметрам репликации.

5. На вторичном сервере переименуйте компьютер, а затем переименуйте экземпляр SQL Server в соответствии с именем сервера-источника. Сведения о переименовании компьютера см. в документации по операционной системе Windows. Сведения о переименовании сервера см. в разделах Переименование компьютера, на который установлен изолированный экземпляр SQL Server и Переименование экземпляра отказоустойчивого кластера SQL Server.

6. На сервере-получателе восстановите главный ключ службы, резервная копия которого была получена с сервера-источника. Дополнительные сведения см. в разделе RESTORESERVICERESTORE SERVICE MASTER KEY (Transact-SQL).

Настройка репликации транзакций и доставки журналов без параметра «sync with backup»

1. Настройте доставку журналов транзакций для базы данных публикаций. Дополнительные сведения см. в разделе Настройка доставки журналов (SQL Server).

2. Если Publisher выходит из строя, восстановите на вторичный сервер последнюю резервную копию журнала транзакций базы данных, используя параметр KEEP_REPLICATION команды RESTORE LOG. Это действие сохранит все настройки репликации для базы данных. Дополнительные сведения см. в разделе Переключение на дополнительный сервер доставки журналов (SQL Server) и RESTORE (Transact-SQL).

3. Восстановите базы данных msdb и master с основного сервера на дополнительный. Дополнительные сведения см. в статье Резервное копирование и восстановление системных баз данных (SQL Server). Если основной сервер также был распространителем, необходимо восстановить базу данных распространения с основного сервера на вторичный сервер.

   Эти базы данных должны совпадать с базой данных публикации на основном сервере по конфигурации и параметрам репликации.

4. На вторичном сервере переименуйте компьютер, а затем переименуйте экземпляр SQL Server в соответствии с именем сервера-источника. Сведения о переименовании компьютера см. в документации по операционной системе Windows. Сведения о переименовании сервера см. в разделах Переименование компьютера, на который установлен изолированный экземпляр SQL Server и Переименование экземпляра отказоустойчивого кластера SQL Server.

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

5. На сервере-получателе восстановите главный ключ службы, резервная копия которого была получена с сервера-источника. Дополнительные сведения см. в разделе RESTORESERVICERESTORE SERVICE MASTER KEY (Transact-SQL).

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

7. Перезапустите агент чтения журнала после того, как хранимая процедура будет успешно выполнена. Дополнительные сведения см. в статье Запуск и остановка агента репликации (среда SQL Server Management Studio).

8. Транзакции, которые уже были доставлены Подписчику, могут быть применены у Издателя. Чтобы агент распространения не завершался с ошибкой при попытке повторно применить эти транзакции у подписчика, укажите профиль агента с именем Continue On Data Consistency Errors.

Доставка журналов транзакций при репликации слиянием

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

Настроить репликацию слиянием и доставку журналов

1. Настройте доставку журналов транзакций для базы данных публикаций. Дополнительные сведения см. в разделе Настройка доставки журналов (SQL Server).

2. Если издатель выходит из строя, на вторичном сервере переименуйте компьютер, а затем переименуйте экземпляр SQL Server так, чтобы его имя совпадало с именем основного сервера. Сведения о переименовании компьютера см. в документации по операционной системе Windows. Сведения о переименовании сервера см. в разделах Переименование компьютера, на который установлен изолированный экземпляр SQL Server и Переименование экземпляра отказоустойчивого кластера SQL Server.

3. Восстановите последний журнал транзакций базы данных на вторичный сервер, используя параметр KEEP_REPLICATION команды RESTORE LOG. Это действие сохранит все настройки репликации для базы данных. Дополнительные сведения см. в разделе Переключение на дополнительный сервер доставки журналов (SQL Server) и RESTORE (Transact-SQL).

4. Восстановите базы данных msdb и master с основного сервера на дополнительный. Дополнительные сведения см. в статье Резервное копирование и восстановление системных баз данных (SQL Server). Если основной сервер также был распространителем, восстановите базу данных распространения с основного сервера на вторичный сервер.

   Эти базы данных должны соответствовать базе данных публикации на основном сервере по конфигурации и параметрам репликации.

5. На сервере-получателе восстановите главный ключ службы, резервная копия которого была получена с сервера-источника. Дополнительные сведения см. в разделе RESTORESERVICERESTORE SERVICE MASTER KEY (Transact-SQL).

6. Синхронизируйте базу данных публикации с одной или несколькими базами данных подписки. Это позволит провести передачу изменений, сделанных в базе данных публикации, но не представленных в восстановленной резервной копии. Передаваемые данные зависят от того, как отфильтрованы публикации:

   • Если публикации не отфильтрованы, должна существовать возможность обновления базы данных публикаций посредством синхронизации с самым обновленным подписчиком.

   • Если же публикация отфильтрована, то базу данных публикации, возможно, не удастся обновить. Продумайте таблицу, которая разделена так, что каждая подписка получает данные клиентов только из одного региона: север, восток, юг и запад. Если существует по крайней мере один подписчик из каждой секции данных, синхронизация с подписчиком из каждой секции должна обновить базу данных публикаций. Однако, если данные, например, в западном разделе не были реплицированы ни на один подписчик, то эти данные у Издателя невозможно привести в актуальное состояние. В таком случае рекомендуется провести повторную инициализацию всех подписок, чтобы добиться конвергенции данных на издателе и подписчиках. Дополнительные сведения см. в статье Повторная инициализация подписок.

   Если вы синхронизируете с подписчиком, выполняющим версию SQL Server до SQL Server 2005 (9.x), подписка не может быть анонимной; она должна быть клиентской подпиской или подпиской сервера (например, локальными подписками и глобальными подписками в предыдущих выпусках). Дополнительные сведения см. в разделе Синхронизация данных.

См. также

Репликация SQL Server
Сведения о доставке журналов транзакций (SQL Server)Настройка репликации с помощью групп доступности Always On