Управление реплицированной базой данных издателя в рамках группы доступности Always On

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

В этом разделе рассматриваются специальные рекомендации в отношении обслуживания базы данных публикации при использовании групп доступности AlwaysOn.

Обслуживание опубликованной базы данных в группе доступности

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

  • Администрирование выполняется на узле первичной реплики. В SQL Server Management Studio публикации отображаются в папке "Локальные публикации" для узла первичной реплики , а также для доступных для чтения вторичных реплик. После переключения при отказе может потребоваться вручную обновить Management Studio, чтобы это изменение отобразилось, если вторичная реплика, повышенная до основной, не была доступна для чтения.

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

  • Если для администрирования репликации на текущей первичной реплике используются хранимые процедуры или объекты RMO, то для случаев, когда указывается имя издателя, необходимо указать имя экземпляра, на котором база данных активирована для репликации (первоначальный издатель). Чтобы определить соответствующее имя, воспользуйтесь функцией PUBLISHINGSERVERNAME . Когда база данных публикации входит в группу доступности, метаданные репликации, хранящиеся во вторичных репликах базы данных, идентичны метаданным в первичной реплике. Поэтому для баз данных публикаций, настроенных для репликации на первичном сервере, имя экземпляра издателя, сохранённое в системных таблицах на вторичном сервере, является именем первичного, а не вторичного сервера. Это отрицательно повлияет на настройку и обслуживание репликации, если в результате сбоя база данных публикации перейдет на вторичный сервер. Например, если вы настраиваете репликацию с помощью хранимых процедур на вторичной реплике после аварийного переключения и хотите создать подписку по запросу на базу данных публикации, которая была включена на другой реплике, необходимо указать в качестве параметра @publisher процедуры sp_addpullsubscription или sp_addmergepullsubscription имя исходного издателя, а не текущего. Тем не менее, если включить базу данных публикации после отработки отказа, в системных таблицах в качестве имени экземпляра издателя будет сохранено имя текущего основного узла. В этом случае для параметра @publisher лучше использовать имя узла текущей первичной реплики.

    Примечание.

    Для некоторых процедур, таких как sp_addpublication, параметр @publisher поддерживается только для издателей, которые не являются экземплярами SQL Server. В этом случае это не имеет отношения к SQL Server Always On.

  • Чтобы синхронизировать подписку в Management Studio после переключения при отказе, синхронизируйте подписки с извлечением на подписчике, а подписки с отправкой — на активном издателе.

Удаление опубликованной базы данных из группы доступности

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

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

    EXEC sys.sp_redirect_publisher   
    @original_publisher = 'MyPublisher',  
    @published_database = 'MyPublishedDB';

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

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

    EXEC sys.sp_redirect_publisher   
    @original_publisher = 'MyPublisher',  
    @published_database = 'MyPublishedDB',  
    @redirected_publisher = 'MyNewPublisher';

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

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

    Примечание.

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

    Выполните процедуру sp_dropsubscription , чтобы удалить подписки на публикацию. Убедитесь в том, что для параметра @ignore_distributor задано значение 1, чтобы метаданные сохранялись для активной базы данных публикации на уровне распространителя.

    USE MyDBName;  
GO  

EXEC sys.sp_dropsubscription   
    @subscriber = 'MySubscriber',  
    @publication = 'MyPublication',  
    @article = 'all',  
    @ignore_distributor = 1;

    Выполните процедуру sp_droppublication для удаления всех публикаций. Еще раз задайте для параметра @ignore_distributor значение 1, чтобы метаданные сохранялись для активной базы данных публикации на уровне распространителя.

    EXEC sys.sp_droppublication   
    @publication = 'MyPublication',  
    @ignore_distributor = 1;

    Выполните процедуру sp_replicationdboption , чтобы отключить репликацию для базы данных.

    EXEC sys.sp_replicationdboption  
    @dbname = 'MyDBName',  
    @optname = 'publish',  
    @value = 'false';

    На этом этапе копию опубликованной базы данных можно сохранить или удалить.

Удаление исходного издателя

Существуют случаи (замена старого сервера, обновление ОС и т. д.), когда вам нужно удалить исходный издатель из группы доступности Always On. Выполните действия, описанные в этом разделе, чтобы удалить издатель из группы доступности.

Предположим, что у вас есть серверы N1, N2 и D1, где N1 и N2 являются первичной и вторичной репликой группы доступности AG1. N1 также является исходным издателем публикации транзакций, а D1 — распространителем. Вы хотите заменить исходный издатель N1 новым издателем N3.

Чтобы удалить издатель, выполните следующие действия.

  1. Установите и настройте SQL Server на узле N3. Версия SQL Server должна совпадать с версией исходного издателя.
  2. На сервере распространителя D1 добавьте N3 в качестве издателя с помощью хранимой процедуры sp_adddistpublisher.
  3. Настройте N3 в качестве издателя, используя в качестве его распространителя D1.
  4. Добавьте N3 в качестве реплики в группу доступности AG1.
  5. В реплике N3 убедитесь, что подписчики push-уведомлений для публикации отображаются как связанные серверы. Используйте либо sp_addlinkedserver, либо SQL Server Management Studio.
  6. После синхронизации N3 выполните отработку отказа группы доступности на N3, сделав его основной репликой.
  7. Удалите N1 из группы доступности AG1.

Учтите следующее:

  • Не удаляйте удаленный сервер исходного издателя (в этом случае — N1) или метаданные, связанные с ним из распространителя, даже если сервер больше не доступен. Метаданные сервера исходного издателя нужны распространителю для обработки запросов к метаданным публикации. Без них репликация завершиться ошибкой.
  • После удаления исходного издателя в SQL Server 2014 вы не сможете использовать имя исходного издателя для администрирования репликации в Мониторе репликации. При попытке зарегистрировать новые реплики в качестве издателя в Мониторе репликации информация не будет отображаться, так как с ней не связаны метаданные. Чтобы администрировать репликацию при таком сценарии, вам потребуется щелкнуть правой кнопкой мыши отдельные публикации и подписки в SQL Server Management Studio (SSMS).
  • Для SQL Server 2016 с пакетом обновления 2 (SP2) CU3, SQL Server 2017 CU6 и более поздних версий зарегистрируйте прослушиватель издателя группы доступности в Мониторе репликации, чтобы администрировать репликацию с помощью SQL Server Management Studio версии 17.7 и выше.

Связанные задачи

Связанные материалы

  • Last updated on