• Artículo

Replicación y trasvase de registros

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 principal. Las actualizaciones realizadas por los clientes en la base de datos principal 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 principal.

El trasvase de registros se puede usar conjuntamente con la replicación, con el siguiente comportamiento:

  • La replicación 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 replicación 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 principal, se reanuda la replicación. Todas las transacciones que el trasvase de registros vuelve a copiar desde la base de datos secundaria a la base de datos principal se replican en los suscriptores.

  • Si la base de datos principal se pierde de forma permanente, se puede cambiar el nombre de la base de datos secundaria de manera que se pueda continuar con la replicación. En el resto de este tema, se describen los requisitos y procedimientos necesarios para abordar este caso. 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 replicación sin necesidad de reconfigurar la replicación, vea Realizar copias de seguridad de bases de datos de replicación 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 Replicación 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 principal

Se deben tener en cuenta los siguientes requisitos y consideraciones:

  • Si la base de datos principal 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 principal. 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 principal 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 replicación transaccional

En la replicación 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 replicación de instantáneas o transaccional.

Para configurar la replicación 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 Implementar 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 replicación 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 principal al secundario. Para obtener más información, vea Consideraciones para restaurar las bases de datos model y msdb y Consideraciones para restaurar la base de datos maestra. Si la base de datos principal también era un distribuidor, restaure la base de datos de distribución del servidor principal al secundario.

    Las bases de datos deben ser coherentes con la base de datos de publicaciones del servidor principal en lo que respecta a las opciones de configuración de la replicación.

  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 principal. 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 hospeda una instancia independiente de SQL Server y Cómo cambiar el nombre de una instancia de clúster de conmutación por error de SQL Server.

  6. En el servidor secundario, restaure la clave maestra de servicio que se copió desde el servidor principal. Para obtener más información, vea RESTORE SERVICE MASTER KEY (Transact-SQL).

Para configurar la replicación 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 Implementar 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 replicación 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 principal al secundario. Para obtener más información, vea Consideraciones para restaurar las bases de datos model y msdb y Consideraciones para restaurar la base de datos maestra. Si la base de datos principal también era un distribuidor, restaure la base de datos de distribución del servidor principal al secundario.

    Las bases de datos deben ser coherentes con la base de datos de publicaciones del servidor principal en lo que respecta a las opciones de configuración de la replicación.

  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 principal. 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 hospeda una instancia independiente de SQL Server y Cómo cambiar el nombre de una instancia de clúster de conmutación por error de SQL Server.

    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 principal. 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 replicación (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 replicación transaccional.

Trasvase de registros con la replicación de mezcla

Realice los pasos del siguiente procedimiento para configurar la replicación de mezcla y el trasvase de registros.

Para configurar la replicación 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 Implementar 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 replicación 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 principal al secundario. Para obtener más información, vea Consideraciones para restaurar las bases de datos model y msdb y Consideraciones para restaurar la base de datos maestra. Si la base de datos principal también era un distribuidor, restaure la base de datos de distribución del servidor principal al secundario.

    Las bases de datos deben ser coherentes con la base de datos de publicaciones del servidor principal en lo que respecta a las opciones de configuración de la replicación.

  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 principal. 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 hospeda una instancia independiente de SQL Server y Cómo cambiar el nombre de una instancia de clúster de conmutación por error de SQL Server.

  5. En el servidor secundario, restaure la clave maestra de servicio que se copió desde el servidor principal. 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 de forma que cada suscripción reciba únicamente datos de clientes de una región: norte, este, sur y oeste. Si hay al menos un suscriptor para cada partición de datos, al sincronizar cada partición con un suscriptor se debería 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.