Administrar una base de datos de Publicador replicada como parte de un grupo de disponibilidad Always On

Se aplica a:SQL Server

En este tema se tratan consideraciones especiales para mantener una base de datos de publicación cuando se usan grupos de disponibilidad AlwaysOn.

Mantener una base de datos publicada en un grupo de disponibilidad

El mantenimiento de una base de datos de publicación AlwaysOn se realiza básicamente de la misma forma que para una base de datos de publicación estándar, con las siguientes salvedades:

La administración debe producirse en el host de réplica principal. En SQL Server Management Studio, las publicaciones aparecen bajo la carpeta de Publicaciones locales para el host de réplica principal y también para las réplicas secundarias legibles. Después de la conmutación por error, puede que tenga que actualizar manualmente Management Studio para que el cambio quede reflejado si el elemento secundario promovido a principal no era legible.
El Monitor de replicación siempre muestra la información de la publicación bajo el publicador original. Sin embargo, esta información se puede ver en el Monitor de replicación de cualquier réplica al agregar el publicador original como servidor.
Al usar procedimientos almacenados o Replication Management Objects (RMO) para administrar la replicación en el servidor principal actual, en los casos en los que se especifica el nombre del Publicador, debe especificarse el nombre de la instancia en la que la base de datos se configuró para la replicación (el publicador original). Para determinar el nombre correcto, use la función PUBLISHINGSERVERNAME . Cuando una base de datos de publicación se une a un grupo de disponibilidad, los metadatos de replicación almacenados en las réplicas de la base de datos secundaria son idénticos a los de la principal. En consecuencia, para las bases de datos de publicación habilitadas para replicación en la entidad principal, el nombre de la instancia del publicador que está almacenado en las tablas del sistema en la entidad secundaria es el nombre de la entidad principal en lugar del nombre de la entidad secundaria. Esto afecta a la configuración y al mantenimiento de la replicación si la base de datos de publicación conmuta por error a una base de datos secundaria. Por ejemplo, si va a configurar la replicación con procedimientos almacenados en una entidad secundaria después de la conmutación por error y quiere una suscripción de extracción a una base de datos de publicación que se ha habilitado en otra réplica, debe especificar el nombre del publicador original en lugar del publicador actual como parámetro @publisher de sp_addpullsubscription o osp_addmergepulllsubscription. Sin embargo, si habilita una base de datos de publicación después de la conmutación por error, el nombre de la instancia del publicador almacenado en las tablas del sistema es el nombre del host primario actual. En este caso, usaría el nombre de host de réplica principal actual para el parámetro @publisher .

Nota:

En algunos procedimientos, como sp_addpublication, el parámetro @publisher solo se admite para publicadores que no sean instancias de SQL Server; en estos casos, no es relevante para SQL Server AlwaysOn.
Para sincronizar una suscripción en Management Studio después de una conmutación por error, sincronice las suscripciones de extracción desde el suscriptor y las suscripciones de inserción desde el publicador activo.

Quitar una base de datos publicada de un grupo de disponibilidad

Tenga en cuenta las siguientes cuestiones si se quita una base de datos publicada de un grupo de disponibilidad o si se elimina un grupo de disponibilidad que tiene una base de datos miembro publicada.

Si la base de datos de publicación del publicador original se quita de la réplica principal de un grupo de disponibilidad, debe ejecutar sp_redirect_publisher sin especificar un valor para el parámetro @redirected_publisher a fin de quitar el redireccionamiento del par publicador y base de datos.
```
EXEC sys.sp_redirect_publisher   
    @original_publisher = 'MyPublisher',  
    @published_database = 'MyPublishedDB';  
```
La base de datos se quedará en el estado de recuperación en el servidor principal y debe restaurarse. Una vez que hayas hecho esto, la replicación debería funcionar sin cambios contra el Publicador original.
Si la base de datos de publicación conmuta por error desde el publicador original a una réplica y la base de datos se quita de la réplica principal del grupo de disponibilidad, use el procedimiento almacenado sp_redirect_publisher para redirigir explícitamente el publicador original al nuevo publicador. La base de datos se quedará en el estado de recuperación y debe restaurarse. Una vez hecho esto, la replicación debería seguir funcionando igual que lo hacía en el grupo de disponibilidad.
```
EXEC sys.sp_redirect_publisher   
    @original_publisher = 'MyPublisher',  
    @published_database = 'MyPublishedDB',  
    @redirected_publisher = 'MyNewPublisher';  
```
No elimine el servidor remoto del publicador original en el distribuidor, aunque ya no se pueda acceder a él. Los metadatos de servidor del publicador original son necesarios en el distribuidor para satisfacer las consultas de los metadatos de la publicación.
Si se quita un grupo de disponibilidad completo, el comportamiento con respecto a una base de datos replicada de miembros es el mismo que cuando se quita una base de datos publicada de un grupo de disponibilidad. La replicación se puede reanudar desde el último servidor principal tan pronto como se haya restaurado la base de datos y se haya modificado la redirección. Si la base de datos se restaura en su servidor publicador original, debe quitarse la redirección. Si la base de datos se restaura en un host diferente, la redirección debe dirigirse explícitamente al nuevo host.

Nota:

Cuando se quita un grupo de disponibilidad que contiene bases de datos miembro publicadas, o se quita de un grupo de disponibilidad una base de datos publicada, todas las copias de las bases de datos publicadas quedarán en estado de recuperación. Si se restaura, cada una aparecerá como base de datos publicada. Solo se debe conservar una copia con los metadatos de la publicación. Para deshabilitar la replicación de una copia publicada de una base de datos, primero, elimine todas las suscripciones y publicaciones de la base de datos.

Ejecute sp_dropsubscription para quitar las suscripciones de publicaciones. Asegúrese de establecer el parámetro ignore_distributor en 1 para mantener los metadatos de la base de datos de publicación activa en el distribuidor.
```
USE MyDBName;  
GO  

EXEC sys.sp_dropsubscription   
    @subscriber = 'MySubscriber',  
    @publication = 'MyPublication',  
    @article = 'all',  
    @ignore_distributor = 1;  
```
Ejecute sp_droppublication para quitar todas las publicaciones. De nuevo, establezca el parámetro @ignore_distributor en 1 para mantener los metadatos de la base de datos de publicación activa en el distribuidor.
```
EXEC sys.sp_droppublication   
    @publication = 'MyPublication',  
    @ignore_distributor = 1;  
```
Ejecute sp_replicationdboption para deshabilitar la replicación de la base de datos.
```
EXEC sys.sp_replicationdboption  
    @dbname = 'MyDBName',  
    @optname = 'publish',  
    @value = 'false';  
```
En este momento, la copia de la base de datos publicada se puede conservar o quitar.

Eliminación del publicador original

Puede haber instancias (reemplazo del servidor anterior, actualización del sistema operativo, etc.) donde desee quitar un publicador original de un grupo de disponibilidad Always On. Siga los pasos de esta sección para quitar el publicador del grupo de disponibilidad.

Supongamos que tiene los servidores N1, N2 y D1, donde N1 y N2 son la réplica principal y secundaria del grupo de disponibilidad AG1, N1 es el publicador original de una publicación transaccional y D1 es el distribuidor. Quiere reemplazar el publicador original N1 por el nuevo publicador N3.

Para quitar el publicador, siga estos pasos:

Instale y configure SQL Server en el nodo N3. La versión de SQL Server debe ser la misma que la del publicador original.
En el servidor de distribuidor D1, agregue N3 como publicador mediante sp_adddistpublisher.
Configure N3 como publicador con D1 como su distribuidor.
Agregue N3 como una réplica al grupo de disponibilidad AG1.
En la réplica N3, compruebe que los suscriptores push de la publicación aparecen como servidores vinculados. Use sp_addlinkedserver o SQL Server Management Studio.
Una vez que N3 esté sincronizado, realice la conmutación por error del grupo de disponibilidad a N3 para que sea el principal.
Quite N1 del grupo de disponibilidad AG1.

Tenga en cuenta lo siguiente:

No quite el servidor remoto del publicador original (en este caso, N1) ni los metadatos asociados a él del distribuidor, aunque ya no se pueda acceder al servidor. Los metadatos de servidor del publicador original son necesarios en el distribuidor para satisfacer las consultas de los metadatos de la publicación y, sin ellos, la replicación fallará.
Para SQL Server 2014, una vez que se haya quitado el publicador original, no podrá usar el nombre del publicador original para administrar la replicación en el monitor de replicación. Si intenta registrar nuevas réplicas como publicador en el monitor de replicación, la información no se mostrará ya que no hay metadatos asociados a él. Para administrar la replicación en este escenario, tendrá que hacer clic con el botón derecho en las publicaciones y suscripciones individuales en SQL Server Management Studio (SSMS).
Para SQL Server 2016 SP2-CU3, SQL Server 2017 CU6 y versiones posteriores, registre el agente de escucha del publicador del grupo de disponibilidad en el Monitor de replicación para administrar la replicación con SQL Server Management Studio versión 17.7 o posterior.

Tareas relacionadas

Comentaris

Us ha resultat útil aquesta pàgina?

Last updated on 2026-08-24