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

Мақала
04/26/2023

Область применения: 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 после отработки отказа, синхронизируйте подписки на извлечение из подписчика и синхронизируйте push-подписки с активного издателя.

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

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

Если база данных публикации на уровне первоначального издателя удаляется из первичной реплики группы доступности, следует выполнить процедуру 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.

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

Установите и настройте SQL Server на узле N3. Версия SQL Server должна совпадать с версией исходного издателя.
На сервере распространителя D1 добавьте N3 в качестве издателя с помощью хранимой процедуры sp_adddistpublisher.
Настройте N3 в качестве издателя, используя в качестве его распространителя D1.
Добавьте N3 в качестве реплики в группу доступности AG1.
В реплике N3 убедитесь, что подписчики push-уведомлений для публикации отображаются как связанные серверы. Используйте либо sp_addlinkedserver, либо SQL Server Management Studio.
После синхронизации N3 группа доступности не будет передаваться в качестве основной реплики в N3.
Удалите 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 и выше.

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

См. также

Предварительные требования, ограничения и рекомендации для групп доступности AlwaysOn (SQL Server)
Обзор групп доступности Always On (SQL Server)
Группы доступности Always On: взаимодействие (SQL Server)
Репликация SQL Server

Бөлісу құралы: