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

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

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

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

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

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

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

Помните о следующих требованиях и рекомендациях.

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

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

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

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

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

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

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

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

1. Если параметр синхронизации с параметром резервного копирования не установлен в базе данных публикации, выполните команду 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 Stand-Alone» и «Переименование экземпляра отказоустойчивого кластера SQL Server».

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

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

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

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

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

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

4. На вторичном сервере переименуйте компьютер, а затем переименуйте экземпляр SQL Server в соответствии с именем сервера-источника. Сведения о переименовании компьютера см. в документации по Windows. Сведения о переименовании сервера см. в статьях «Переименование компьютера с экземпляром Stand-Alone 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. Сведения о переименовании сервера см. в статьях «Переименование компьютера, который размещает экземпляр Stand-Alone 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. Синхронизация базы данных публикации с одной или несколькими базами данных подписки. Это позволяет передавать эти изменения, внесенные ранее в базу данных публикации, но не представленную в восстановленной резервной копии. Передаваемые данные зависят от способа фильтрации публикации:

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

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

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

См. также

Репликация SQL Server
Сведения о доставке журналов (SQL Server)
Зеркалирование базы данных и репликация (SQL Server)