Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Se aplica a:SQL Server
La creación de reflejo de bases de datos se puede usar conjuntamente con la replicación para mejorar la disponibilidad de la base de datos de publicación. La duplicación de la base de datos implica dos copias de una misma base de datos que normalmente se encuentran en equipos distintos. En cada momento, solo una copia de la base de datos está disponible para los clientes. Esta copia se conoce como la base de datos principal. Las actualizaciones realizadas por los clientes en la base de datos principal se aplican en la otra copia de la base de datos, conocida como la base de datos reflejada. La creación de reflejo implica aplicar a la base de datos reflejada el registro de transacciones correspondiente a cada inserción, actualización o eliminación realizada en la base de datos principal.
La conmutación por error de replicación a una base de datos reflejada es totalmente compatible para las bases de datos de publicación, pero solo tiene compatibilidad limitada para las bases de datos de suscripción. La creación de reflejo de la base de datos no se admite para la base de datos de distribución. Para obtener información sobre la recuperación de una base de datos de distribución o una base de datos de suscripciones sin necesidad de volver configurar la replicación, vea Back Up and Restore Replicated Databases (Realizar copias de seguridad y restaurar bases de datos replicadas).
Nota
Después de una conmutación por error, el servidor reflejado pasa a ser el principal. En este tema, «principal» y «réplica» siempre se refieren al principal y la réplica originales.
Requisitos y consideraciones para usar la replicación con la duplicación de la base de datos
Tenga en cuenta los siguientes requisitos y consideraciones al utilizar la replicación con el reflejo de la base de datos:
El principal y el reflejo deben compartir un Distribuidor. Se recomienda que este sea un Distribuidor remoto, ya que proporciona una mayor tolerancia a fallos si el Publicador experimenta una conmutación por error imprevista.
La replicación admite la creación de un reflejo de la base de datos de publicación para la replicación de mezcla y para la replicación transaccional con suscriptores de solo lectura o con suscriptores con actualización en cola. No se admiten suscriptores de actualización inmediata, publicadores de Oracle, publicadores en una topología punto a punto ni republicación.
Los metadatos y los objetos que existen fuera de la base de datos, incluidos los inicios de sesión, los trabajos y los servidores vinculados, entre otros, no se copian en la copia reflejada. Si necesita los metadatos y los objetos en la réplica, debe copiarlos manualmente. Para obtener más información, vea Administración de inicios de sesión y trabajos tras la conmutación de roles (SQL Server).
Configurar la replicación con el reflejo de la base de datos
La configuración de la replicación y la duplicación de la base de datos implica cinco pasos. Cada paso se describe en detalle en la siguiente sección.
Configurar el publicador.
Configurar el reflejo de la base de datos.
Configure el servidor reflejado para que use el mismo Distribuidor que el principal.
Configurar los agentes de replicación para la conmutación por error
Agregue el principal y el servidor reflejado al Monitor de replicación.
El orden de los pasos 1 y 2 se puede invertir.
Para configurar la creación de reflejo de una base de datos de publicación
Configure el publicador:
Se recomienda el uso de un distribuidor remoto. Para obtener más información sobre cómo configurar la distribución, vea Configure Distribution (Configurar la distribución).
Se puede habilitar una base de datos para publicaciones transaccionales y de instantáneas y/o para publicaciones de combinación. Para las bases de datos reflejadas que incluirán más de un tipo de publicación, se debe habilitar la base de datos para ambos tipos en el mismo nodo mediante sp_replicationdboption. Por ejemplo, podría ejecutar las siguientes llamadas al procedimiento almacenado en el principal:
exec sp_replicationdboption @dbname='<PublicationDatabase>', @optname='publish', @value=true; exec sp_replicationdboption @dbname='<PublicationDatabase>', @optname='mergepublish', @value=true;Para obtener más información sobre la creación de publicaciones, vea Publish Data and Database Objects (Publicar datos y objetos de base de datos).
Configurar la duplicación de la base de datos. Para obtener más información, vea Establecer una sesión de creación de reflejo de la base de datos mediante la autenticación de Windows (SQL Server Management Studio) y Configurar la creación de reflejo de la base de datos (SQL Server).
Configurar la distribución para el espejo. Indique el nombre del servidor reflejado como el Publicador y especifique el mismo Distribuidor y la misma carpeta de instantáneas que utiliza el principal. Por ejemplo, si está configurando la replicación con procedimientos almacenados, ejecute sp_adddistpublisher en el distribuidor y, después, ejecute sp_adddistributor en la entidad reflejada. Para sp_adddistpublisher:
Establezca el valor del parámetro @publisher en el nombre de red de la entidad reflejada.
Establezca el valor del parámetro @working_directory en la carpeta de instantáneas utilizada por el principal.
Especifique el nombre de la entidad reflejada para el parámetro de agente - PublisherFailoverPartner. Agente Este parámetro es necesario para que los siguientes agentes identifiquen el servidor reflejado después de una conmutación por error:
Agente de instantáneas (para todas las publicaciones)
Agente de lectura del registro (para todas las publicaciones transaccionales)
Agente de lectura de cola (para las publicaciones transaccionales que admiten suscripciones de actualización en cola)
Agente de combinación (para suscripciones de combinación)
Agente de escucha de replicación de SQL Server (replisapi.dll: para suscripciones de combinación sincronizadas mediante sincronización web)
Control ActiveX de mezcla de SQL (para suscripciones de mezcla sincronizadas con el control)
El Agente de distribución y el control ActiveX Distribución no tienen este parámetro porque no se conectan al Publicador.
Los cambios en los parámetros del agente tendrán efecto la próxima vez que se inicie el agente. Si el agente se ejecuta sin interrupción, debe detenerlo y reiniciarlo. Los parámetros se pueden especificar en perfiles de agente y desde el símbolo del sistema. Para más información, consulte:
Se recomienda agregar el parámetro -PublisherFailoverPartner a un perfil de agente y, después, especificar el nombre del reflejo en el perfil. Por ejemplo, si configura la replicación con procedimientos almacenados:
-- Execute sp_help_agent_profile in the context of the distribution database to get the list of profiles. -- Select the profile id of the profile that needs to be updated from the result set. -- In the agent_type column returned by sp_help_agent_profile: -- 1 = Snapshot Agent; 2 = Log Reader Agent; 3 = Distribution Agent; 4 = Merge Agent; 9 = Queue Reader Agent. exec sp_help_agent_profile; -- Setting the -PublisherFailoverPartner parameter in the default Snapshot Agent profile (profile 1). -- Execute sp_add_agent_parameter in the context of the distribution database. exec sp_add_agent_parameter @profile_id = 1, @parameter_name = N'-PublisherFailoverPartner', @parameter_value = N'<Failover Partner Name>'; -- Setting the -PublisherFailoverPartner parameter in the default Merge Agent profile (profile 6). -- Execute sp_add_agent_parameter in the context of the distribution database. exec sp_add_agent_parameter @profile_id = 6, @parameter_name = N'-PublisherFailoverPartner', @parameter_value = N'<Failover Partner Name>';Agregue el principal y el servidor reflejado al Monitor de replicación. Para obtener más información, vea Agregar y quitar publicadores del Monitor de replicación.
Mantener una base de datos de publicación reflejada
El mantenimiento de una base de datos de publicación reflejada se realiza básicamente de la misma forma que para una base de datos no reflejada, con las siguientes salvedades:
La administración y la supervisión deben tener lugar en el servidor activo. En SQL Server Management Studio, las publicaciones aparecen debajo de la carpeta Publicaciones locales solo para el servidor activo. Por ejemplo, si se conmuta por error al servidor reflejado, las publicaciones se muestran en el servidor reflejado y ya no se muestran en el servidor principal. Si se produce la conmutación por error de la base de datos a la entidad reflejada, puede que sea necesario actualizar manualmente Management Studio y el Monitor de replicación para que se refleje el cambio.
El Monitor de replicación muestra los nodos del publicador en el árbol de objetos tanto para el principal como para el servidor reflejado. Si el servidor principal es el servidor activo, la información de publicación solo se muestra debajo del nodo principal en el Monitor de replicación.
Si el servidor espejo es el servidor activo:
Si un agente presenta un error, este solo se indica en el nodo principal, no en el nodo espejo.
Si el principal no está disponible, los nodos principales y de espejo muestran listas idénticas de publicaciones. Las publicaciones del nodo espejo deben monitorizarse.
Si se utilizan procedimientos almacenados o Replication Management Objects (RMO) para administrar la replicación en la entidad reflejada, 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. Para determinar el nombre correcto, use la función publishingservername.
Cuando se refleja una base de datos de publicación, los metadatos de replicación almacenados en la base de datos reflejada son idénticos a los metadatos almacenados en la base de datos principal. En consecuencia, para las bases de datos de publicación habilitadas para la replicación en el principal, el nombre de la instancia del Publicador almacenado en las tablas del sistema del reflejo es el nombre del principal, no el del reflejo. 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 la base de datos reflejada. Por ejemplo, si está configurando la replicación con procedimientos almacenados en el servidor reflejado después de una conmutación por error, y quiere agregar una suscripción de extracción a una base de datos publicada que estaba habilitada en el principal, debe especificar el nombre del principal en lugar del nombre del reflejado para el parámetro @publisher de sp_addpullsubscription o sp_addmergepullsubscription.
Si habilita una base de datos de publicación en el servidor reflejado después de una conmutación por error al servidor reflejado, el nombre de la instancia del publicador almacenado en las tablas del sistema es el nombre del servidor reflejado; en ese caso, debe usar el nombre del servidor reflejado para el parámetro @publisher.
Nota
En algunos casos, por ejemplo sp_addpublication, el parámetro @publisher solo se admite para publicadores que no sean de SQL Server. En estos casos, no es relevante para la creación de reflejo de la base de datos de SQL Server.
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 sincronice las suscripciones de inserción desde el publicador activo.
Comportamiento de la replicación si se elimina la duplicación
Tenga en cuenta los siguientes problemas si se elimina la creación de reflejo de la base de datos de una base de datos publicada:
Si la base de datos de publicación del principal ya no está duplicada, la replicación continúa funcionando sin cambios con el principal original.
Si se produce una conmutación por error de la base de datos de publicación del servidor principal al servidor reflejado y posteriormente se deshabilita o se quita la relación de reflejo, los agentes de replicación no funcionarán en el servidor reflejado. Si el principal se pierde de forma permanente, deshabilite la replicación y vuelva a configurarla con el servidor reflejado especificado como Publicador.
Si se elimina por completo la duplicación de la base de datos, la base de datos reflejada quedará en estado de recuperación y deberá restaurarse para volver a estar operativa. El comportamiento de la base de datos recuperada con respecto a la replicación depende de si se ha especificado la opción KEEP_REPLICATION. Esta opción obliga a la operación de restauración a conservar la configuración de la replicación cuando restaure una base de datos publicada en un servidor distinto del servidor en el que se creó la copia de seguridad. Utilice la opción KEEP_REPLICATION solo cuando la otra base de datos de publicación no esté disponible. Esta opción no es compatible si la otra base de datos de publicación sigue intacta y continúa con la replicación. Para obtener más información sobre KEEP_REPLICATION, vea RESTORE (Transact-SQL).
Comportamiento del agente lector de registros
En la siguiente tabla se describe el comportamiento del Agente Lector de registros en los distintos modos de funcionamiento de la duplicación de la base de datos.
| Modo de funcionamiento | Comportamiento del agente lector de registros si la réplica no está disponible |
|---|---|
| Modo de alta seguridad con conmutación automática ante fallos | Si el servidor espejo no está disponible, Log Reader Agent propaga comandos a la base de datos de distribución. El servidor principal no puede conmutar por error al servidor reflejado hasta que este vuelva a estar en línea y tenga todas las transacciones del servidor principal. |
| Modo de alto rendimiento | Si el servidor reflejo no está disponible, la base de datos principal se ejecuta expuesta (es decir, sin reflejo). Sin embargo, el Agente Lector de registros solo replica aquellas transacciones que están confirmadas en el servidor reflejado. Si se fuerza el servicio y el servidor espejo asume el rol de principal, el Agente de lectura del registro funcionará en el servidor espejo y empezará a captar las nuevas transacciones. Tenga en cuenta que la latencia de replicación aumentará si la réplica espejo se retrasa respecto al principal. |
| Modo de alta seguridad sin conmutación automática en caso de fallo | Se garantiza que todas las transacciones confirmadas queden almacenadas de forma persistente en disco en la réplica. El Agente Lector del Registro solo replica aquellas transacciones que están confirmadas en el servidor reflejado. Si el servidor reflejado no está disponible, el servidor principal no permite más actividad en la base de datos; por lo tanto, el Log Reader Agent no tendrá transacciones que replicar. |
Consulte también
Replicación de SQL Server
Trasvase de registros y replicación (SQL Server)