Репликация и доставка журналов (SQL Server)
Доставка журналов использует две копии одной базы данных, которые обычно хранится на разных компьютерах. В любой момент только одна копия базы данных доступна клиентам. Эта копия известна как база данных-источник. Обновления, вносимые клиентами в базу данных-источник, распространяются при помощи доставки журналов в другую копию базы данных, которая называется база данных-получатель. Доставка журналов включает применение каждой вставки, обновления или удаления, сделанных в базе данных-источнике, к базе данных-получателю с помощью журнала транзакций.
Доставка журналов может использоваться совместно с репликацией со следующими особенностями.
Репликация не продолжается после отработки отказа доставки журналов. В случае отработки отказа агенты репликации не подключаются к базе данных-получателю, поэтому транзакции не реплицируются подписчикам. Если происходит автоматический возврат на базу данных-источник, репликация возобновляется. Все транзакции, которые при доставке журналов копируются из базы данных-получателя в базу данных-источник, реплицируются подписчикам.
Если база данных-источник потеряна безвозвратно, базу данных-получатель можно переименовать, чтобы продолжить репликацию. Далее описываются требования и процедуры, которым необходимо следовать при обработке данного случая. В качестве примера описывается база данных публикации, которая чаще всего используется для доставки журналов, но такой же процесс может быть применен и к базе данных подписки, и к базе данных распространителя.
Сведения о восстановлении баз данных, задействованных в процессе репликации, без изменения настроек репликации см. в разделе Создание резервной копии и восстановление из копий реплицируемых баз данных.
.gif "Примечание") Примечание |
|---|
В целях обеспечения доступности базы данных публикации рекомендуется использовать зеркальное отображение базы данных, а не доставку журналов. Дополнительные сведения см. в разделе Зеркальное отображение и репликация баз данных (SQL Server). |
Требования и процедуры для репликации из базы данных-получателя в случае утери базы данных-источника
Учитывайте следующие требования и замечания.
Если на сервере-источнике содержится несколько баз данных публикации, доставьте журналы всех баз данных публикации на один сервер-получатель.
Путь установки экземпляра сервера-получателя должен совпадать с путем установки сервера-источника. Места нахождения баз данных пользователя на сервере-получателе должны совпадать с местами нахождения на сервере-источнике.
Создайте резервную копию главного ключа службы на сервере-источнике. Данный ключ будет восстановлен на сервере-получателе. Дополнительные сведения см. в разделе BACKUP SERVICE MASTER KEY (Transact-SQL).
Доставка журналов не гарантирует сохранности данных. Сбой базы данных-источника может вызвать потерю тех данных, для которых не была создана резервная копия, а также данных, резервные копии которых были утеряны из-за сбоя.
Доставка журналов при репликации транзакций
Для репликации транзакций способ доставки журналов зависит от параметра sync with backup. Данный параметр устанавливается в базе данных публикации и базе данных распространителя. При доставке журналов издателю учитывается только параметр в базе данных публикации.
Установка этого параметра в базе данных публикации гарантирует, что транзакции не будут доставлены в базу данных распространителя до тех пор, пока их резервная копия не будет сохранена в базе данных публикации. Затем последняя резервная копия базы данных публикации может быть восстановлена на сервере-получателе, при этом в базе данных распространителя не будет транзакций, отсутствующих в восстановленной базе данных публикации. Данный параметр гарантирует, что в случае перехода издателя на сервер-получатель обеспечивается согласованность между издателем, распространителем и подписчиком. Затрагиваются задержка и пропускная способность, так как транзакции нельзя доставить в базу данных распространителя до тех пор, пока для них не созданы резервные копии на издателе. Если ваше приложение может работать с такой задержкой, рекомендуется установить этот параметр в базе данных публикации. Если параметр sync with backup не установлен, подписчики могут получать изменения, которые более не включены в восстановленную базу данных на сервере-получателе. Дополнительные сведения см. в разделе Стратегии резервного копирования и восстановления из копии репликации моментальных снимков и репликации транзакций.
Настройка репликации транзакций и доставки журналов с параметром «sync with backup»
Если параметр «sync with backup» не установлен в базе данных публикации, выполните sp_replicationdboption '<publicationdatabasename>', 'sync with backup', 'true'. Дополнительные сведения см. в разделе sp_replicationdboption (Transact-SQL).
Настройте доставку журналов для базы данных публикации. Дополнительные сведения см. в разделе Настройка доставки журналов (SQL Server).
Если издатель поврежден, восстановите последний журнал базы данных на сервере-получателе, используя параметр KEEP_REPLICATION инструкции RESTORE LOG. Это действие сохранит все настройки репликации для базы данных. Дополнительные сведения см. в разделах Переход на вторичный сервер доставки журналов (SQL Server) и RESTORE (Transact-SQL).
Восстановите и перенесите базы данных msdb и master с сервера-источника на сервер-получатель. Дополнительные сведения см. в разделе Резервное копирование и восстановление системных баз данных (SQL Server). Если сервер-источник был также и распространителем, необходимо восстановить и перенести базу данных распространителя с сервера-источника на сервер-получатель.
Эти базы данных должны быть согласованы по конфигурации и настройкам репликации с базой данных публикации сервера-источника.
Переименуйте компьютер сервера-получателя, а затем переименуйте экземпляр SQL Server, чтобы имя совпадало с именем сервера-источника. Сведения о переименовании компьютера см. в документации по операционной системе Windows. Сведения о переименовании сервера см. в разделах Переименование компьютера, на который установлен изолированный экземпляр SQL Server и переименовать экземпляр отказоустойчивого кластера SQL Server.
На сервере-получателе восстановите главный ключ службы, резервная копия которого была получена с сервера-источника. Дополнительные сведения см. в разделе Инструкция RESTORE SERVICE MASTER KEY (Transact-SQL).
Настройка репликации транзакций и доставки журналов без параметра «sync with backup»
Настройте доставку журналов для базы данных публикации. Дополнительные сведения см. в разделе Настройка доставки журналов (SQL Server).
Если издатель поврежден, восстановите последний журнал базы данных на сервере-получателе, используя параметр KEEP_REPLICATION инструкции RESTORE LOG. Это действие сохранит все настройки репликации для базы данных. Дополнительные сведения см. в разделах Переход на вторичный сервер доставки журналов (SQL Server) и RESTORE (Transact-SQL).
Восстановите и перенесите базы данных msdb и master с сервера-источника на сервер-получатель. Дополнительные сведения см. в разделе Резервное копирование и восстановление системных баз данных (SQL Server). Если сервер-источник был также и распространителем, необходимо восстановить и перенести базу данных распространителя с сервера-источника на сервер-получатель.
Эти базы данных должны быть согласованы по конфигурации и настройкам репликации с базой данных публикации сервера-источника.
Переименуйте компьютер сервера-получателя, а затем переименуйте экземпляр SQL Server, чтобы имя совпадало с именем сервера-источника. Сведения о переименовании компьютера см. в документации по операционной системе Windows. Сведения о переименовании сервера см. в разделах Переименование компьютера, на который установлен изолированный экземпляр SQL Server и переименовать экземпляр отказоустойчивого кластера SQL Server.
Возможно, будет получено сообщение об ошибке от агента чтения журнала, в котором указывается на отсутствие синхронизации базы данных публикации с базой данных распространителя.
На сервере-получателе восстановите главный ключ службы, резервная копия которого была получена с сервера-источника. Дополнительные сведения см. в разделе Инструкция RESTORE SERVICE MASTER KEY (Transact-SQL).
Выполните sp_replrestart. Данную хранимую процедуру можно использовать для принудительного пропуска агентом чтения журнала всех предыдущих реплицированных транзакций в журнале базы данных публикации. Транзакции, примененные после завершения хранимой процедуры, обрабатываются агентом чтения журнала. Дополнительные сведения см. в разделе sp_replrestart (Transact-SQL).
Перезапустите агент чтения журнала после того, как хранимая процедура будет успешно выполнена. Дополнительные сведения см. в разделе Запуск и остановка агента репликации (среда SQL Server Management Studio).
Транзакции, которые уже распространены на подписчике, могут применяться на издателе. Чтобы агент распространителя при повреждении не выдал сообщения об ошибке при попытке повторного применения этих транзакций на подписчике, укажите профиль агента Продолжать при возникновении ошибок согласованности данных.
Доставка журналов при репликации слиянием
Выполните указанную ниже последовательность действий, чтобы настроить репликацию слиянием и доставку журналов.
Настройка репликации слиянием и доставки журналов
Настройте доставку журналов для базы данных публикации. Дополнительные сведения см. в разделе Настройка доставки журналов (SQL Server).
Если издатель завершает работу по ошибке, переименуйте компьютер сервера-получателя, а затем переименуйте экземпляр SQL Server, чтобы имя совпадало с именем сервера-источника. Сведения о переименовании компьютера см. в документации по операционной системе Windows. Сведения о переименовании сервера см. в разделах Переименование компьютера, на который установлен изолированный экземпляр SQL Server и переименовать экземпляр отказоустойчивого кластера SQL Server.
Восстановите последний журнал базы данных на сервере-получателе, используя параметр KEEP_REPLICATION инструкции RESTORE LOG. Это действие сохранит все настройки репликации для базы данных. Дополнительные сведения см. в разделах Переход на вторичный сервер доставки журналов (SQL Server) и RESTORE (Transact-SQL).
Восстановите и перенесите базы данных msdb и master с сервера-источника на сервер-получатель. Дополнительные сведения см. в разделе Резервное копирование и восстановление системных баз данных (SQL Server). Если сервер-источник был также и распространителем, необходимо восстановить и перенести базу данных распространителя с сервера-источника на сервер-получатель.
Эти базы данных должны быть согласованы по конфигурации и настройкам репликации с базой данных публикации сервера-источника.
На сервере-получателе восстановите главный ключ службы, резервная копия которого была получена с сервера-источника. Дополнительные сведения см. в разделе Инструкция RESTORE SERVICE MASTER KEY (Transact-SQL).
Синхронизируйте базу данных публикации с одной или несколькими базами данных подписки. Это позволит провести передачу изменений, сделанных в базе данных публикации, но не представленных в восстановленной резервной копии. Передаваемые данные зависят от того, как отфильтрованы публикации:
Если публикации не отфильтрованы, должна существовать возможность обновления базы данных публикаций посредством синхронизации с самым обновленным подписчиком.
Если же публикация отфильтрована, то базу данных публикации, возможно, не удастся обновить. Продумайте таблицу, которая разделена так, что каждая подписка получает данные клиентов только из одного региона: север, восток, юг и запад. Если существует по крайней мере один подписчик из каждой секции данных, синхронизация с подписчиком из каждой секции должна обновить базу данных публикаций. Однако, если данные в западной секции, например не были реплицированы на какие-либо подписчики, эти данные на издателе невозможно будет обновить. В таком случае рекомендуется провести повторную инициализацию всех подписок, чтобы добиться конвергенции данных на издателе и подписчиках. Дополнительные сведения см. в разделе Повторная инициализация подписок.
При синхронизации с подписчиком, на котором запущена версия SQL Server, предшествующая SQL Server 2005, подписка не может быть анонимной. Это должна быть клиентская или серверная подписка (в предыдущих версиях такие подписки называются локальными или глобальными). Дополнительные сведения см. в разделе Синхронизация данных.