Compartir a través de

Réplica y trasvase de registros

  • Artículo

Actualizado: 14 de abril de 2006

El trasvase de registros incluye dos copias de una sola base de datos que suelen residir en diferentes equipos. En cada momento, sólo una copia de la base de datos está disponible para los clientes. Esta copia se conoce como la base de datos primaria. Las actualizaciones realizadas por los clientes en la base de datos primaria se propagan mediante el trasvase de registros a la otra copia de la base de datos, conocida como la base de datos secundaria. El trasvase de registros incluye la aplicación a la base de datos secundaria del registro de transacciones con todas las inserciones, actualizaciones o eliminaciones efectuadas en la base de datos primaria.

El trasvase de registros se puede usar conjuntamente con la réplica, con el siguiente comportamiento:

  • La réplica no continúa después de producirse una conmutación por error de trasvase de registros. Si se produce una conmutación por error, los agentes de réplica no se conectan a la base de datos secundaria, de modo que no se replican transacciones en los suscriptores. Si se produce una conmutación por recuperación en la base de datos primaria, se reanuda la réplica. Todas las transacciones que el trasvase de registros vuelve a copiar desde la base de datos secundaria a la base de datos primaria se replican en los suscriptores.
  • Si la base de datos primaria se pierde de forma permanente, se puede cambiar el nombre de la base de datos secundaria de manera que se pueda continuar con la réplica. En el resto de este tema, se describen los requisitos y procedimientos necesarios para abordar este escenario. El ejemplo presentado corresponde a la base de datos de publicaciones, que es la base de datos a la que se aplica el trasvase de registros con mayor frecuencia, aunque también se puede aplicar un proceso similar a las bases de datos de suscripciones y de distribución.

Para obtener información sobre la recuperación de las bases de datos involucradas en la réplica sin necesidad de reconfigurar la réplica, vea Realizar copias de seguridad de bases de datos de réplica y restaurarlas.

[!NOTA] Se recomienda utilizar la creación de reflejo de la base de datos, en lugar del trasvase de registros, para proporcionar disponibilidad a la base de datos de publicaciones. Para obtener más información, vea Réplica y creación de reflejo de la base de datos.

Requisitos y procedimientos para replicar desde la base de datos secundaria si se pierde la base de datos primaria

Se deben tener en cuenta los siguientes requisitos y consideraciones:

  • Si la base de datos primaria contiene más de una base de datos de publicaciones, trasvase los registros de todas las bases de datos de publicaciones a la misma base de datos secundaria.
  • La ruta de instalación de la instancia del servidor secundario debe ser la misma que la del primario. Las ubicaciones de las bases de datos de usuario en el servidor secundario deben ser las mismas que las del primario.
  • Haga una copia de seguridad de la clave maestra de servicio en la base de datos primaria. Esta clave se restaurará en la base de datos secundaria. Para obtener más información, vea BACKUP SERVICE MASTER KEY (Transact-SQL).
  • El trasvase de registros no garantiza que no se produzca una pérdida de datos. Un error en la base de datos primaria puede originar la pérdida de los datos que aún no tienen una copia de seguridad o la pérdida de copias de seguridad durante la ejecución del error.

Trasvase de registros con la réplica transaccional

En la réplica transaccional, el comportamiento del trasvase de registros depende de la opción sync with backup. Esta opción se puede establecer en la base de datos de publicaciones y en la base de datos de distribución. En lo que respecta al trasvase de registros para el publicador, sólo tiene relevancia la configuración de la base de datos de publicaciones.

La configuración de esta opción en la base de datos de publicaciones garantiza que las transacciones no se entreguen a la base de datos de distribución hasta que se haya hecho una copia de seguridad de ellas en la base de datos de publicaciones. La última copia de seguridad de la base de datos de publicaciones se puede restaurar posteriormente en el servidor secundario sin que exista ninguna posibilidad de que la base de datos de distribución contenga transacciones que no existan en la base de datos de publicaciones restaurada. Esta opción garantiza que si el publicador genera un error en el servidor secundario, se mantendrá la coherencia entre el publicador, el distribuidor y los suscriptores. La latencia y el rendimiento se verán afectados porque no será posible entregar transacciones a la base de datos de distribución hasta que se haya hecho una copia de seguridad de ellas en el publicador. Si la aplicación puede tolerar esta latencia, se recomienda establecer esta opción en la base de datos de publicaciones. Si no se establece la opción sync with backup, los suscriptores podrían recibir cambios que ya no están incluidos en la base de datos recuperada en el servidor secundario. Para obtener más información, vea Estrategias para hacer copias de seguridad y restaurar la réplica de instantáneas o transaccional.

Para configurar la réplica transaccional y el trasvase de registros con la opción sync with backup:

  1. Si la opción sync with backup no está establecida en la base de datos de publicaciones, ejecute sp_replicationdboption '<publicationdatabasename>', 'sync with backup', 'true'. Para obtener más información, vea sp_replicationdboption (Transact-SQL).
  2. Configure el trasvase de registros para la base de datos de publicaciones. Para obtener más información, vea Configurar el trasvase de registros.
  3. Si se produce un error en el publicador, restaure el último registro de la base de datos en el servidor secundario mediante la opción KEEP_REPLICATION de RESTORE LOG. De esta manera se conservará toda la configuración de la réplica correspondiente a la base de datos. Para obtener más información, vea Realizar una conmutación por error a una base de datos secundaria de trasvase de registros y RESTORE (Transact-SQL).
  4. Restaure la base de datos msdb y las bases de datos master del servidor primario al secundario. Para obtener más información, vea Consideraciones para restaurar el modelo y las bases de datos msdb y Consideraciones para Restaurar la base de datos master. Si la base de datos primaria también era un distribuidor, restaure la base de datos de distribución del servidor primario al secundario.
    Las bases de datos deben ser coherentes con la base de datos de publicaciones del servidor primario en lo que respecta a las opciones de configuración de la réplica.
  5. En el servidor secundario, cambie el nombre del equipo y, a continuación, cambie el nombre de la instancia de Microsoft SQL Server de manera que coincida con el nombre del servidor primario. Para obtener información sobre cómo cambiar el nombre del equipo, vea la documentación de Windows. Para obtener información sobre cómo cambiar el nombre del servidor, vea Cómo cambiar el nombre de un equipo que aloja una instancia independiente de SQL Server 2005 y Cómo cambiar el nombre de un servidor virtual SQL Server 2005.
  6. En el servidor secundario, restaure la clave maestra de servicio que se copió desde el servidor primario. Para obtener más información, vea RESTORE SERVICE MASTER KEY (Transact-SQL).

Para configurar la réplica transaccional y el trasvase de registros sin la opción sync with backup

  1. Configure el trasvase de registros para la base de datos de publicaciones. Para obtener más información, vea Configurar el trasvase de registros.
  2. Si se produce un error en el publicador, restaure el último registro de la base de datos en el servidor secundario mediante la opción KEEP_REPLICATION de RESTORE LOG. De esta manera se conservará toda la configuración de la réplica correspondiente a la base de datos. Para obtener más información, vea Realizar una conmutación por error a una base de datos secundaria de trasvase de registros y RESTORE (Transact-SQL).
  3. Restaure la base de datos msdb y las bases de datos master del servidor primario al secundario. Para obtener más información, vea Consideraciones para restaurar el modelo y las bases de datos msdb y Consideraciones para Restaurar la base de datos master. Si la base de datos primaria también era un distribuidor, restaure la base de datos de distribución del servidor primario al secundario.
    Las bases de datos deben ser coherentes con la base de datos de publicaciones del servidor primario en lo que respecta a las opciones de configuración de la réplica.
  4. En el servidor secundario, cambie el nombre del equipo y, a continuación, cambie el nombre de la instancia de SQL Server de manera que coincida con el nombre del servidor primario. Para obtener información sobre cómo cambiar el nombre del equipo, vea la documentación de Windows. Para obtener información sobre cómo cambiar el nombre del servidor, vea Cómo cambiar el nombre de un equipo que aloja una instancia independiente de SQL Server 2005 y Cómo cambiar el nombre de un servidor virtual SQL Server 2005.
    Es probable que reciba un mensaje de error del Agente de registro del LOG comunicándole que la base de datos de publicaciones y la base de datos de distribución no están sincronizadas.
  5. En el servidor secundario, restaure la clave maestra de servicio que se copió desde el servidor primario. Para obtener más información, vea RESTORE SERVICE MASTER KEY (Transact-SQL).
  6. Ejecute sp_replrestart. Este procedimiento almacenado se puede utilizar para forzar que el Agente de registro del LOG omita todas las transacciones replicadas anteriormente en el registro de la base de datos de publicaciones. Las transacciones aplicadas tras la finalización del procedimiento almacenado se procesan mediante el Agente de registro del LOG. Para obtener más información, vea sp_replrestart (Transact-SQL).
  7. Reinicie el Agente de registro del LOG después de que el procedimiento almacenado se haya ejecutado correctamente. Para obtener más información, vea Cómo iniciar y detener un agente de réplica (SQL Server Management Studio).
  8. Las transacciones que ya se distribuyeron al suscriptor podrían aplicarse al publicador. Para asegurarse de que el Agente de distribución no genere un error cuando intente volver a aplicar estas transacciones en el suscriptor, especifique el perfil de agente llamado Continuar después de errores de coherencia de datos. Para obtener más información, vea Omitir errores en la réplica transaccional.

Trasvase de registros con la réplica de mezcla

Realice los pasos del siguiente procedimiento para configurar la réplica de mezcla y el trasvase de registros.

Para configurar la réplica de mezcla y el trasvase de registros

  1. Configure el trasvase de registros para la base de datos de publicaciones. Para obtener más información, vea Configurar el trasvase de registros.
  2. Si se produce un error en el publicador, restaure el último registro de la base de datos en el servidor secundario mediante la opción KEEP_REPLICATION de RESTORE LOG. De esta manera se conservará toda la configuración de la réplica correspondiente a la base de datos. Para obtener más información, vea Realizar una conmutación por error a una base de datos secundaria de trasvase de registros y RESTORE (Transact-SQL).
  3. Restaure la base de datos msdb y las bases de datos master del servidor primario al secundario. Para obtener más información, vea Consideraciones para restaurar el modelo y las bases de datos msdb y Consideraciones para Restaurar la base de datos master. Si la base de datos primaria también era un distribuidor, restaure la base de datos de distribución del servidor primario al secundario.
    Las bases de datos deben ser coherentes con la base de datos de publicaciones del servidor primario en lo que respecta a las opciones de configuración de la réplica.
  4. En el servidor secundario, cambie el nombre del equipo y, a continuación, cambie el nombre de la instancia de SQL Server de manera que coincida con el nombre del servidor primario. Para obtener información sobre cómo cambiar el nombre del equipo, vea la documentación de Windows. Para obtener información sobre cómo cambiar el nombre del servidor, vea Cómo cambiar el nombre de un equipo que aloja una instancia independiente de SQL Server 2005 y Cómo cambiar el nombre de un servidor virtual SQL Server 2005.
  5. En el servidor secundario, restaure la clave maestra de servicio que se copió desde el servidor primario. Para obtener más información, vea RESTORE SERVICE MASTER KEY (Transact-SQL).
  6. Sincronice la base de datos de publicaciones con una o más bases de datos de suscripciones. Esto permite cargar los cambios realizados anteriormente en la base de datos de publicaciones, pero que no se muestran en la copia de seguridad restaurada. Los datos que se pueden cargar dependen de la manera en que se filtre una publicación:
    • Si la publicación no está filtrada, se podrá actualizar la base de datos de publicaciones sincronizándola con el suscriptor más actualizado.
    • Si la publicación está filtrada, probablemente no se pueda actualizar la base de datos de publicaciones. Considere una tabla dividida en particiones de manera tal que cada suscripción recibe datos de clientes sólo para una región: norte, este, sur y oeste. Si existe por lo menos un suscriptor para cada partición de datos, la sincronización con un suscriptor para cada partición debería ser suficiente para actualizar la base de datos de publicaciones. Sin embargo, si los datos de la partición norte, por ejemplo, no se replicaron en ningún suscriptor, no se podrán actualizar estos datos en el publicador. En este caso, se recomienda reinicializar todas las suscripciones de manera que los datos del publicador y de los suscriptores converjan. Para obtener más información, vea Reinicializar una suscripción.
      Si se sincroniza con un suscriptor que ejecute una versión de SQL Server anterior a SQL Server 2005, la suscripción no puede ser anónima, sino que debe ser una suscripción de cliente o de servidor (llamadas suscripciones locales y suscripciones globales en versiones anteriores). Para obtener más información, vea Sincronizar datos.

Vea también

Conceptos

Réplica y creación de reflejo de la base de datos

Otros recursos

Implementar la réplica
Trasvase de registros

Ayuda e información

Obtener ayuda sobre SQL Server 2005