Compartir vía

Acerca del trasvase de registros (SQL Server)

Se aplica a:SQL Server

SQL Server El trasvase de registros permite enviar automáticamente copias de seguridad del registro de transacciones desde una base de datos principal de una instancia del servidor principal a una o varias bases de datos secundarias en instancias independientes del servidor secundario . Las copias de seguridad del registro de transacciones se aplican a cada una de las bases de datos secundarias de forma individual. En una tercera instancia de servidor opcional, denominado servidor de supervisión, se registra el historial y el estado de las operaciones de copias de seguridad y restauración y, opcionalmente, se activan alertas si estas operaciones no se producen según lo programado.

Información general de trasvase de registros

El trasvase de registros consta de tres operaciones:

  1. Realizar una copia de seguridad del registro de transacciones en la instancia del servidor principal.
  2. Copiar el archivo de registro de transacciones en la instancia del servidor secundario.
  3. Restaurar la copia de seguridad de registros en la instancia del servidor secundario.

El registro se puede trasvasar a varias instancias del servidor secundario En ese caso, las operaciones 2 y 3 se repiten para cada instancia del servidor secundario.

Una configuración de trasvase de registros no conmuta por error automáticamente desde el servidor principal al servidor secundario. Si la base de datos principal deja de estar disponible, cualquiera de las bases de datos secundarias se puede poner en línea manualmente.

Puede utilizar una base de datos secundaria para la generación de informes.

Además, puede configurar alertas para la configuración de trasvase de registros.

Una configuración de trasvase de registros típica

La siguiente ilustración muestra una configuración de trasvase de registros con la instancia del servidor principal, tres instancias del servidor secundario y una instancia del servidor de supervisión. La ilustración presenta los pasos realizados por los trabajos de copia de seguridad, copia y restauración del siguiente modo:

  1. La instancia del servidor principal ejecuta el trabajo de copia de seguridad del registro de transacciones en la base de datos principal. A continuación, esta instancia de servidor coloca la copia de seguridad del registro en un archivo principal de copias de seguridad de registros que se envía a la carpeta de copia de seguridad. En esta ilustración, la carpeta de copia de seguridad es un directorio compartido: el recurso compartido de copia de seguridad.

  2. Cada una de las tres instancias del servidor secundario ejecuta su propio trabajo de copia para copiar el archivo principal de copia de seguridad de registros a su propia carpeta de destino local.

  3. Cada instancia del servidor secundario ejecuta su propio trabajo de restauración para restaurar la copia de seguridad del registro desde la carpeta de destino local a la base de datos secundaria local.

Las instancias del servidor principal y secundario envían su propio historial y estado a la instancia del servidor de supervisión.

Diagrama de la configuración en el que se muestran trabajos de copia de seguridad, copia y restauración.

Aplicación del cifrado TLS 1.3

SQL Server 2025 (17.x) presenta compatibilidad con TDS 8.0 para el trasvase de registros. El protocolo TDS 8.0 proporciona seguridad y cifrado mejorados para los datos transmitidos entre los servidores principales y secundarios de una topología de trasvase de registros. Elija entre aplicar cifrado obligatorio o estricto para la comunicación entre servidores.

En SQL Server 2025 (17.x), el trasvase de registros usa Microsoft OLE DB Driver for SQL Server como versión predeterminada para los servidores vinculados, que tiene un valor predeterminado Encrypt de Mandatory.

Para usar el cifrado TLS 1.3 en la configuración de trasvase de registros existente, quite y vuelva a crear la topología mediante los nuevos parámetros TLS 1.3 en los procedimientos almacenados de trasvase de registros.

La supervisión del envío de registros podría fallar si el monitor es una instancia remota de SQL Server 2025

La supervisión del trasvase de registros puede interrumpirse si el monitor es una instancia remota de SQL Server 2025 (17.x), cuando otras instancias de SQL Server de la topología de trasvase de registros usan una versión anterior. Es posible que reciba uno de los siguientes errores:

OLE DB provider "MSOLEDBSQL19" for linked server "<server>" returned message "Client unable to establish connection. For solutions related to encryption errors, see https://go.microsoft.com/fwlink/?linkid=2227882.".

O:

Msg 32055, Level 16, State 2, Procedure master.dbo.sp_add_log_shipping_primary_database, Line 325 [Batch Start Line 10]
There was an error configuring the remote monitor server.

Para solucionar este problema, elimine y vuelva a crear la configuración de envío de registros en ambas réplicas, la principal y la secundaria. Hay disponible un script de ejemplo en Uso de un monitor remoto con opciones de conectividad.

Para obtener más información, consulte Comportamiento de validación de certificados y cifrado.

Ventajas

  • Proporciona una solución de recuperación ante desastres para una sola base de datos principal y una o más bases de datos secundarias, cada una en una instancia independiente de SQL Server.

  • Admite acceso limitado de solo lectura a bases de datos secundarias (durante el intervalo entre los trabajos de restauración).

  • Permite un retraso especificado por el usuario entre el momento en que el servidor principal realiza una copia de seguridad del registro de la base de datos principal y el momento en que los servidores secundarios deben restaurar (aplicar) la copia de seguridad de registros. Un retraso más largo puede ser útil, por ejemplo, si los datos se cambian en la base de datos principal de manera accidental. Si se detecta rápidamente el cambio accidental, un retraso puede permitirle recuperar los datos aún sin modificar de una base de datos secundaria antes de que el cambio se refleje en ella.

Términos y definiciones

  • servidor principal: La instancia de SQL Server que es el servidor de producción.

  • base de datos principal: La base de datos del servidor principal de la que desea realizar una copia de seguridad en otro servidor. Toda la administración de la configuración de trasvase de registros mediante SQL Server Management Studio se realiza en la base de datos principal.

  • servidor secundario: La instancia de SQL Server donde desea mantener una copia en estado de espera activa de la base de datos principal.

  • base de datos secundaria: La copia en estado de espera activa de la base de datos principal. La base de datos secundaria puede estar en estado DE RECUPERACIÓN o en estado STANDBY , lo que deja la base de datos disponible para acceso limitado de solo lectura.

  • monitor de supervisión: Una instancia opcional de SQL Server que realiza un seguimiento de todos los detalles del trasvase de registros, como:

    • Cuándo se realizó por última vez una copia de seguridad del registro de transacciones de la base de datos principal.
    • Cuándo se realizó por última vez la copia y restauración de los archivos de copia de seguridad en los servidores secundarios.
    • Información acerca de las alertas de error de copia de seguridad.

    Importante

    Una vez configurado el servidor de supervisión, no se puede cambiar sin quitar primero el trasvase de registros.

  • trabajo de copia de seguridad: Un trabajo del Agente SQL Server que lleva a cabo la operación de copia de seguridad, registra el historial en el servidor local y el servidor de supervisión, y elimina los archivos de copia de seguridad y la información de historial antiguos. La categoría de trabajo "Copia de seguridad de trasvase de registros" se crea en la instancia del servidor principal al habilitar el trasvase de registros.

  • trabajo de copia: Un trabajo del Agente de SQL Server que copia los archivos de copia de seguridad del servidor principal en un destino configurable del servidor secundario y registra el historial en el servidor secundario y el servidor de supervisión. La categoría de trabajo "Copia de seguridad de trasvase de registros" se crea en cada servidor secundario en una configuración de trasvase de registros al habilitar el trasvase de registros.

  • trabajo de restauración: Un trabajo del Agente de SQL Server que restaura los archivos de copia de seguridad copiados en las bases de datos secundarias. Registra el historial en el servidor local y el servidor de supervisión, y elimina los archivos de copia de seguridad y la información de historial antiguos. La categoría de trabajo "Restauración de trasvase de registros" se crea en la instancia del servidor secundario al habilitar el trasvase de registros en una base de datos.

  • trabajo de alerta: un trabajo del Agente SQL Server que genera alertas para las bases de datos principales y secundarias cuando una operación de copia de seguridad o restauración no se completa correctamente dentro de un umbral especificado. La categoría de trabajo "Alerta de trasvase de registros" se crea en la instancia del servidor de supervisión al habilitar el trasvase de registros en una base de datos.

    Sugerencia

    Para cada alerta, debe especificar un número de alerta. Además, asegúrese de configurar la alerta para notificar a un operador cuándo se activa una alerta.

Interoperabilidad

El trasvase de registros se puede usar con las siguientes características o componentes de SQL Server:

Nota:

Grupos de disponibilidad AlwaysOn y la creación de reflejo de la base de datos son mutuamente excluyentes. Una base de datos configurada para una de estas características no se puede configurar para la otra.

Precaución

Problema conocido: en el caso de las bases de datos con tablas optimizadas para memoria, realizar una copia de seguridad del registro transaccional sin recuperación y, posteriormente, ejecutar una restauración del registro de transacciones con recuperación, podría dar lugar a un proceso de restauración de base de datos que no responde. Este problema también puede afectar a la funcionalidad de trasvase de registros. Para solucionar este problema, se puede reiniciar la instancia de SQL Server antes de iniciar el proceso de restauración.

Contenido relacionado

  • Last updated on