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