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

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

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

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

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

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

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

Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. На сервере-получателе восстановите главный ключ службы, резервная копия которого была получена с сервера-источника. Дополнительные сведения см. в статье RESTORE SERVICE MASTER KEY (Transact-SQL).

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

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

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

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

См. также

Репликация SQL Server
Сведения о доставке журналов (SQL Server)Настройка репликации с группами доступности AlwaysOn