Compartir a través de

Mantenimiento de una base de datos de publicación AlwaysOn (SQL Server)

En este tema se describen 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

Mantener una base de datos de publicación AlwaysOn es básicamente la misma que mantener una base de datos de publicación estándar, con las siguientes consideraciones:

  • 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 muestra siempre la información de publicación en 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.

  • Si se utilizan procedimientos almacenados o Replication Management Objects (RMO) para administrar la replicación en la réplica principal actual, en los casos en que se especifica el nombre del publicador, se debe especificar el nombre de la instancia en la que la base de datos se habilitó para la replicación (el publicador original). Para determinar el nombre adecuado, use la PUBLISHINGSERVERNAME función . 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 se produce la conmutación por error de la base de datos de publicación a la entidad secundaria. Por ejemplo, si va a configurar la replicación con procedimientos almacenados en una base de datos secundaria después de la conmutación por error, y desea crear una suscripción de extracción a una base de datos de publicación que se haya habilitado en una réplica diferente, debe especificar el nombre del editor original en lugar del editor actual como el parámetro @publisher de sp_addpullsubscription o sp_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 principal 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 son instancias de SQL Server; en estos casos, no es relevante para SQL Server AlwaysOn.

  • Para sincronizar una suscripción en Management Studio tras una conmutación por error, sincronice las suscripciones de extracción del suscriptor y sincronice las suscripciones de inserción del publicador activo.

Quitar una base de datos publicada de un grupo de disponibilidad

Tenga en cuenta los siguientes problemas si quita una base de datos publicada de un grupo de disponibilidad, o si quita un grupo de disponibilidad que tiene una base de datos de miembros publicada.

  • Si la base de datos de publicación del publicador original se quita de una réplica principal del grupo de disponibilidad, debe ejecutar sp_redirect_publisher sin especificar un valor para el parámetro @redirected_publisher para quitar el redireccionamiento del par publicador/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 haya realizado esto, la replicación debe funcionar sin cambios en 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 sp_redirect_publisher almacenado 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 que haya realizado esto, la replicación debe continuar funcionando como lo hizo con el grupo de disponibilidad.

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

    No quite el servidor remoto para el publicador original del distribuidor, incluso si ya no se puede tener acceso 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.

  • Si se quita un grupo de disponibilidad completo, el comportamiento con respecto a una base de datos replicada miembro 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 publicador original, debe quitase la redirección. Si la base de datos se restaura en un host diferente, la redirección debe ejecutarse explícitamente el nuevo host.

    Nota:

    Cuando se quita un grupo de disponibilidad que ha publicado bases de datos de miembros o una base de datos publicada de un grupo de disponibilidad, todas las copias de las bases de datos publicadas se dejará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 para una copia de la base de datos publicada, primero debe quitar todas las suscripciones y publicaciones de la base de datos.

    Ejecute sp_dropsubscription para quitar las suscripciones de publicación. Asegúrese de establecer el parámetro @ignore_distributributor en 1 para conservar 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.

Tareas relacionadas

Véase también

Requisitos previos, restricciones y recomendaciones para grupos de disponibilidad AlwaysOn (SQL Server)
Información general de los grupos de disponibilidad AlwaysOn (SQL Server)
Grupos de disponibilidad AlwaysOn: interoperabilidad (SQL Server)
Replicación de SQL Server

  • Last updated on