Configurar el trasvase de registros en SharePoint Server

SE APLICA A:yes-img-132013 yes-img-162016 yes-img-192019 yes-img-seSubscription Edition no-img-sopSharePoint en Microsoft 365

Con el trasvase de registros, se hace una copia de seguridad de los registros de transacciones de una base de datos principal en una base de datos secundaria en una instancia independiente de SQL Server. En el escenario descrito aquí, SQL Server trasvase de registros se usa junto con replicación del sistema de archivos distribuido (DFSR) para copiar bases de datos y registros de transacciones en la granja de servidores de recuperación de Microsoft Azure, como se muestra a continuación.

En este escenario de recuperación ante desastres, la granja de servidores de producción de SharePoint Server se encuentra en el entorno local y la granja de servidores de recuperación se encuentra en Azure. También puede adaptar las instrucciones de este tema a otros tipos de escenarios de recuperación ante desastres.

Elementos de una solución de espera semiactiva en Azure

Elementos de una solución de espera semiactiva en Azure

En la ilustración:

  • Se ilustran dos entornos en paralelo: la granja de SharePoint local y la granja de recuperación (modo de espera) en Azure.

  • Cada entorno incluye un recurso compartido de archivos.

  • El trasvase de registros se usa para copiar registros desde el servidor de la base de datos secundaria en el entorno local al recurso compartido de archivos local.

  • DFSR copia archivos desde el recurso compartido de archivos del entorno local hacia el recurso compartido de archivos en el entorno de Azure. En un escenario WAN, resulta más eficaz usar DFSR que trasvasar los registros directamente al servidor secundario en Azure.

  • El trasvase de registros reproduce los registros del recurso compartido de archivos en el entorno de Azure en la réplica principal del grupo de disponibilidad SQL Server Always On en el entorno de recuperación.

  • Las bases de datos de registros trasvasados no se asocian a la granja de SharePoint Server hasta que se realice un ejercicio de recuperación.

En el diagrama siguiente se muestran las siete fases que contiene la recuperación ante desastres completa de SharePoint Server en la solución de Azure. La fase 6, Configuración del trasvase de registros para la granja de recuperación, aparece en este diagrama y se explica en las siguientes secciones.

Mapa de ruta de la solución de recuperación tras desastres

Uso del trasvase de registros para la recuperación ante desastres

El trasvase de registros permite enviar automáticamente archivos de registro de transacciones a las bases de datos desde una instancia de servidor de base de datos principal hasta una instancia de servidor de base de datos secundaria. En nuestro entorno de prueba local, usamos Always On grupos de disponibilidad con dos réplicas para lograr alta disponibilidad. Hemos configurado el trasvase de registros en ambas réplicas. Cada réplica debe ser capaz de enviar registros de transacciones. Solo la réplica que está activa y posee la base de datos puede enviar registros. Sin embargo, si ocurriera un evento de conmutación por error y la réplica secundaria se volviera activa, tendría que enviar registros de transacciones en lugar de la réplica errónea.

Una vez recibidos los registros de transacciones en el entorno de Azure, se restauran, de uno en uno, en cada base de datos de SharePoint del servidor de base de datos secundario. Para obtener más información sobre nuestro entorno de prueba, vea Entorno de prueba de concepto de Microsoft.

Nota:

Algunas organizaciones usan un tercer servidor de bases de datos para supervisar el registro del historial y del estado de la copia de seguridad y restaurar operaciones. El servidor de supervisión opcional crea alertas cuando se produce un error en las operaciones de copia de seguridad.

Para ver información detallada sobre el trasvase de registros, vea los artículos que se enumeran en la siguiente tabla.

Tabla: Artículos de referencia sobre el trasvase de registros

URL Descripción
Información sobre el trasvase de registros (SQL Server)
Se describen las copias de seguridad de los registros de transacciones y el trasvase de registros, así como las opciones que están disponibles.
Configurar el trasvase de registros (SQL Server)
Se explica cómo configurar el trasvase de registros en SQL Server 2012 mediante SQL Server Management Studio o Transact-SQL.
Ver el informe de trasvase de registros (SQL Server Management Studio)
Explica cómo ver el informe estado de trasvase de registros de transacciones en SQL Server Management Studio. Puede ejecutar un informe de estado en un servidor de supervisión, servidor principal o servidor secundario.

Consideraciones de rendimiento

El trasvase de registros consiste en tres trabajos. Cada trabajo realiza una de las siguientes operaciones:

  1. Hace una copia de seguridad del registro de transacciones en la instancia del servidor principal.

  2. Copia el archivo de registro de transacciones en la instancia del servidor secundario.

  3. Restaura la copia de seguridad de registros en la instancia del servidor secundario.

Cada trabajo opera de acuerdo a una programación y se ejecuta en un intervalo, que puede tener un impacto significativo en el servidor de bases de datos y, de manera predeterminada, en el rendimiento de la granja de SharePoint.

Para establecer correctamente la copia de seguridad, copiar y restaurar los intervalos de los trabajos, debe analizar la cantidad de datos cuyos registros se están enviando. La cantidad de datos con trasvase de registros se ve afectada por la cantidad diaria de cambios en las bases de datos de contenido. El porcentaje de cambio puede variar enormemente según el contenido, los cambios de mantenimiento y el uso máximo.

Para obtener un porcentaje preciso de cambio, calcule la suma de cambios en las copias de seguridad de los registros de transacciones en cada base de datos de contenido para la que hace trasvase de registros en un intervalo determinado. Use estos datos para calcular el porcentaje de cambio comparado con la base de datos principal.

Las siguientes instrucciones se derivan de la experiencia de trasvase de registros del personal de campo de Microsoft con diversas versiones de SharePoint Server.

  • Evite la degradación del rendimiento debido a todos los trabajos que se inician al mismo tiempo asegurándose de que todos los trabajos de trasvase de registros se desplacen con al menos un retraso de un minuto con respecto al trabajo anterior.

  • Es mejor hacer una copia de seguridad y copiar varios registros de transacciones pequeños que unos cuantos registros de transacciones grandes.

  • Programe copias de seguridad de registros y copiado a intervalos frecuentes. Puede restaurar los registros de transacciones a intervalos menos frecuentes. Por ejemplo, empiece usando intervalos de copia y copia de seguridad de cinco minutos y un intervalo de restauración de 15 minutos.

Requisitos previos para configurar el trasvase de registros

Asegúrese de que cumple los siguientes requisitos previos para usar el trasvase de registros para una solución de recuperación ante desastres.

  • Los inicios de sesión SQL Server son cuentas de dominio que tienen los niveles de permisos necesarios para el trasvase de registros. Los procedimientos almacenados de trasvase de registros requieren pertenencia en el rol de servidor fijo sysadmin.

  • La base de datos principal debe ser el modelo de recuperación completo u optimizado para cargas masivas de registros.

    Precaución

    Si cambia la base de datos a una recuperación simple, el trasvase de registros dejará de funcionar.

  • Antes de poder configurar el trasvase de registros, debe crear un recurso compartido para poner las copias de seguridad de registros de transacciones a disposición del servidor secundario. Se trata de un recurso compartido del directorio en el que se generan las copias de seguridad de los registros de transacciones.

Además de los objetivos de punto de recuperación, asegúrese de que los datos de la granja recuperada estén lo más completos y sin dañar como sea posible. Para lograr estos objetivos, debe planear y programar con cuidado cada aspecto del trasvase de registros.

Infraestructura del trasvase de registros

La infraestructura del trasvase de registros utilizada para nuestro entorno de la solución de recuperación ante desastres se muestra en el siguiente diagrama.

Flujo de datos e infraestructura del trasvase de registros

La infraestructura de trasvase de registros y el flujo direccional entre las granjas de servidores locales y de Azure.

El diagrama anterior muestra el flujo de datos y la infraestructura del trasvase de registros. En el diagrama se muestran los servidores de bases de datos de SQL Server y los servidores de archivos de la granja de servidores de producción y la granja de servidores de recuperación de Azure. Estas granjas de servidores son casi idénticas y cada una contiene una réplica principal y secundaria para cada Always On grupo de disponibilidad. Los servidores de archivos, FIL1 y AZ-FIL1, están configurados de la misma forma, incluido el número de discos duros y tamaños de disco. No se muestran los servidores adicionales en la granja.

Para proporcionar alta disponibilidad, cada réplica en un grupo de disponibilidad almacena una copia de seguridad (completa, diferencial y registros de transacciones) de la otra réplica.

Las réplicas principales y secundarias (SQL-HA1 y SQL-HA2, respectivamente) crean copias de seguridad que se almacenan en su socio del grupo de disponibilidad.

El trasvase de transacciones se configura en la réplica secundaria para minimizar el impacto de las copias de seguridad en las bases de datos de producción. Estos registros de transacciones se escriben en una carpeta compartida en el servidor de archivos local (FIL1). El servicio de replicación del sistema de archivos distribuido (DFS) de Windows Server copia los registros de transacciones de FIL1 a AZ-FIL1. Los registros de transacciones en AZ-FIL1 se restauran en AZ-SQL-HA1, la réplica principal del grupo de disponibilidad en la granja de recuperación.

Pasos necesarios para configurar y validar el trasvase de registros

Los pasos necesarios para configurar, ejecutar y validar el trasvase de registros se resumen en la siguiente lista:

  1. Realice una copia de seguridad de la base de datos.

  2. Configure las copias de seguridad completas y diferenciales en una carpeta local y también una carpeta compartida en el servidor de archivos.

  3. Compruebe que las copias de seguridad se hayan realizado tanto en la carpeta local como en la carpeta compartida.

  4. Configure y pruebe la replicación del Sistema de archivos distribuido (DFS).

  5. Cree espacio de nombre y replicación para transferir los registros de transacciones y los archivos de copia de seguridad entre las granjas locales y de Azure en la carpeta compartida del servidor de archivos.

  6. Compruebe todas las transferencias después de que se ejecute el trasvase de registros.

  7. Configure y pruebe el trasvase de registros.

  8. Configure el trasvase de registros en el servidor de la base de datos principal mediante el siguiente script: Primary-Logshippingsetupparameter. Este script crea trabajos de copia de seguridad, los programa para el trasvase de registros y después inicia los trabajos.

SET NOCOUNT ON
USE MSDB
GO
--@PrimServer : Primary Server name
--@SecServer  : DR/Secondary Server Name
--@SecInstance : DR/Secondary FQDN
--@Domain  : Domain Name
--@BkpDrive : Production Backup server Name
--@DBName : DatabaseName
DECLARE @LS_BackupJobIdAS uniqueidentifier,  @LS_PrimaryIdAS uniqueidentifier , @SP_Add_RetCode As int 
DECLARE @Time as nvarchar(10),@SecInstance as nvarchar(250), @PrimServer as nvarchar(50),@SecServer as nvarchar(50),
@Domain as nvarchar(50),@DBName as nvarchar(max),@BkpDrive as nvarchar(250),@CMD as nvarchar(max),@Counter int
----------------------------------------------------------------------------
IF OBJECT_ID ('tempdb.DBO.#LogShipping','U') IS NOT NULL DROP TABLE #LogShipping
Create table #LogShipping ( LSDBs nvarchar(max))
Set @PrimServer ='SQL1'
Set @SecServer ='SQL2'
Set @SecInstance ='SQL2.corp.adventureworks.com'
Set @Domain ='corp.adventureworks.com'
Set @BkpDrive ='FS1.corp.adventureworks.com'
Set @DBName = 'Social_DB'
Set @Time = '0130'
SET @DBName = UPPER(REPLACE(@DBName, ' ', ''))
SET @DBName = '''' + REPLACE(@DBName, ',', ''', ''') + ''''
Set @CMD =   ' Select ' +
'''DECLARE  @SP_Add_RetCode As int, @LS_BackupJobIdAS uniqueidentifier,  @LS_PrimaryIdAS uniqueidentifier
EXEC @SP_Add_RetCode = master.dbo.sp_add_log_shipping_primary_database ' + CHAR(10) +
'@database = ''''''  + db.Name + ''''''' + CHAR(10) +
',@backup_directory = ''''\\' + @BkpDrive + '\LS\' + ''' + db.Name + ''''' + '''' + CHAR(10) +
',@backup_share = ' + '''''\\' + @BkpDrive + '\LS\' + ''' + db.Name + ''''' + ''''  + CHAR(10) +
',@backup_job_name = ''''' + 'LSBackup_' + ''' + db.Name + ''''' + '''' + CHAR(10) +
',@backup_retention_period = 4320
,@backup_compression = 1
,@backup_threshold = 180 
,@threshold_alert_enabled = 1
,@history_retention_period = 5760 
,@backup_job_id = @LS_BackupJobId OUTPUT 
,@primary_id = @LS_PrimaryId OUTPUT 
,@overwrite = 1 ' +
'IF (@@ERROR = 0 AND @SP_Add_RetCode = 0) 
BEGIN 
DECLARE @LS_BackUpScheduleUIDAs uniqueidentifier ,@LS_BackUpScheduleIDAS int 
EXEC msdb.dbo.sp_add_schedule 
@schedule_name = ''''' + 'LSBackupSchedule_'+ @PrimServer + '_' + ''' + db.Name + ''''' + ''''  + CHAR(10) +
',@enabled = 1 
,@freq_type = 4 
,@freq_interval = 1 
,@freq_subday_type = 4 
,@freq_subday_interval = 13 
,@freq_recurrence_factor = 0 
,@active_start_date = 20090506 
,@active_end_date = 99991231 
,@active_start_time = ' + @Time  + CHAR(10) +
',@active_end_time = 235900 
,@schedule_uid = @LS_BackUpScheduleUID OUTPUT 
,@schedule_id = @LS_BackUpScheduleID OUTPUT 
EXEC msdb.dbo.sp_attach_schedule @job_id = @LS_BackupJobId ,@schedule_id = @LS_BackUpScheduleID  
EXEC msdb.dbo.sp_update_job @job_id = @LS_BackupJobId ,@enabled = 1 
END 
EXEC master.dbo.sp_add_log_shipping_alert_job 
EXEC master.dbo.sp_add_log_shipping_primary_secondary 
@primary_database = '''  + ''''' + db.Name + ''''' + ''''  + CHAR(10) + 
',@secondary_server = ''''' + @SecInstance + ''''''  + CHAR(10) +
',@secondary_database = ''' + ''''' + db.Name + ''''' + ''''  + CHAR(10) +
',@overwrite = 1 ''' +
' [LSDBs] FROM sys.databases db  where name in (' + @DBName + ')' +
'and    db.name  not in (''master'',''model'',''msdb'',''tempdb'',''metricsops'',''periscope'' )
and   Not (exists (select lss.Secondary_database from msdb.dbo.log_shipping_Secondary_databases lss where  db.Name = lss.Secondary_database)
or exists (select lsp.primary_database from msdb.dbo.log_shipping_primary_databases lsp where  db.Name = lsp.primary_database)
   )'
Insert #LogShipping (LSDBs)
Exec ( @CMD)
Set @Counter = @@rowcount
While (@counter > 0)
  Begin
  select top 1  @CMD = LSDBs from #LogShipping
  exec sp_executesql @CMD
  set @counter = @counter - 1
  delete top (1) from #LogShipping
  End
IF OBJECT_ID ('tempdb.DBO.#LogShipping','U') IS NOT NULL DROP TABLE #LogShipping
-- ****** End: Script to be run at Primary: [DB1-PSMSQL-01] ******
  1. Configure el trasvase de registros en un servidor de base de datos secundaria mediante el siguiente script: Secondary-Logshippingsetupparameter. En nuestro entorno de laboratorio, el servidor de base de datos secundario está en la granja de servidores de recuperación ubicada en Azure.
-- ****** Begin: Script to be run at Secondary:  9.3 BUILD******
SET NOCOUNT ON
USE MSDB
GO
--@PrimServer : Primary Server name
--@SecServer  : DR/Secondary Server Name
--@SecInstance : DR/Secondary FQDN
--@Domain  : Domain Name
--@PrimaryBkpDrive : Production Backup server Name
--@BkpDrive : Secondary Backup server Name
--@DBName : DatabaseName
DECLARE @LS_BackupJobIdAS uniqueidentifier,  @LS_PrimaryIdAS uniqueidentifier , @SP_Add_RetCode As int 
DECLARE @Time as nvarchar(10),@SecInstance as nvarchar(250), @PrimServer as nvarchar(50),@SecServer as nvarchar(50),
@Domain as nvarchar(50),@DBName as nvarchar(max),@PrimaryBkpDrive as nvarchar(250),@BkpDrive as nvarchar(250),@CMD as nvarchar(max),@CMD2 as nvarchar(max),@Counter int
DECLARE  @Delimeter char(1),@DB nvarchar(200), @StartPos int, @Length int
IF OBJECT_ID ('tempdb.DBO.#LogShipping','U') IS NOT NULL DROP TABLE #LogShipping
Create table #LogShipping ( LSDBs nvarchar(max))
IF OBJECT_ID ('tempdb.DBO.#DBs','U') IS NOT NULL DROP TABLE #DBs
Create TABLE #DBs (Name nvarchar(200))
Set @PrimServer ='az-sql-ha1'
Set @SecServer =' az-sql-ha2'
Set @SecInstance ='SQL1.corp.adventureworks.com'
Set @Domain =' corp.adventureworks.com '
SET @PrimaryBkpDrive = 'fs1.corp.adventureworks.com'
Set @BkpDrive =' az-sp-fs.corp.adventureworks.com '
Set @DBName = 'Social_DB'
Set @Time = '0130'
--Parsing Function
SET @Delimeter = ','
WHILE LEN(@DBName) > 0
  BEGIN
    SET @StartPos = CHARINDEX(@Delimeter, @DBName)
    IF @StartPos < 0 SET @StartPos = 0
    SET @Length = LEN(@DBName) - @StartPos - 1
    IF @Length < 0 SET @Length = 0
    IF @StartPos > 0
      BEGIN
        SET @DB = Rtrim(Ltrim(SUBSTRING(@DBName, 1, @StartPos - 1)))
        SET @DBName = SUBSTRING(@DBName, @StartPos + 1, LEN(@DBName) - @StartPos)
      END
    ELSE
      BEGIN
        SET @DB = Rtrim(Ltrim(@DBName))
        SET @DBName = ''
      END
    INSERT #DBs (Name) VALUES(@DB)
END
--SET @DBName = UPPER(REPLACE(@DBName, ' ', ''))
--SET @DBName = '''' + REPLACE(@DBName, ',', ''', ''') + ''''
Set @CMD = 'Select ' +
''' DECLARE @LS_Secondary__CopyJobId AS uniqueidentifier, @LS_Secondary__RestoreJobId AS uniqueidentifier ,@LS_Secondary__SecondaryId AS uniqueidentifier , @LS_Add_RetCode As int ,@LS_Add_RetCode2 As int 
  DECLARE @LS_SecondaryCopyJobScheduleUIDAs uniqueidentifier ,@LS_SecondaryCopyJobScheduleIDAS int, @LS_SecondaryRestoreJobScheduleUIDAs uniqueidentifier ,@LS_SecondaryRestoreJobScheduleIDAS int 
  EXEC @LS_Add_RetCode = master.dbo.sp_add_log_shipping_secondary_primary 
@primary_server = ''''' + @PrimServer + ''''''+  CHAR(10) +
',@primary_database = '' + ' +  ''''''''' + db.Name + ''''''''' +  CHAR(10) +
' + '',@backup_source_directory = ' + '''''\\' + @PrimaryBkpDrive + '\LS\'' + db.Name + ''''''' +  CHAR(10) +
' ,@backup_destination_directory =  ' + '''''\\' + @BkpDrive + '\LS\'' + db.Name + ''''''' +  CHAR(10) +
',@copy_job_name = ''''LSCopy_DB1-PSMSQL-01_'' + db.Name + ''''''' +  CHAR(10) +
',@restore_job_name = ''''LSRestore_'+ @PrimServer + '_'' + db.Name + ''''''' +  CHAR(10) +
',@file_retention_period = 4320 
,@overwrite = 1 
,@copy_job_id = @LS_Secondary__CopyJobId OUTPUT 
,@restore_job_id = @LS_Secondary__RestoreJobId OUTPUT 
,@secondary_id = @LS_Secondary__SecondaryId OUTPUT 
IF (@@ERROR = 0 AND @LS_Add_RetCode = 0) 
BEGIN 
EXEC msdb.dbo.sp_add_schedule 
@schedule_name =''''DefaultCopyJobSchedule'''' 
,@enabled = 1 
,@freq_type = 4 
,@freq_interval = 1 
,@freq_subday_type = 4 
,@freq_subday_interval = 15 
,@freq_recurrence_factor = 0 
,@active_start_date = 20090506 
,@active_end_date = 99991231 
,@active_start_time = ' + @Time + ' 
,@active_end_time = 235900 
,@schedule_uid = @LS_SecondaryCopyJobScheduleUID OUTPUT 
,@schedule_id = @LS_SecondaryCopyJobScheduleID OUTPUT 
EXEC msdb.dbo.sp_attach_schedule 
@job_id = @LS_Secondary__CopyJobId 
,@schedule_id = @LS_SecondaryCopyJobScheduleID  
EXEC msdb.dbo.sp_add_schedule 
@schedule_name =''''DefaultRestoreJobSchedule'''' 
,@enabled = 1 
,@freq_type = 4 
,@freq_interval = 1 
,@freq_subday_type = 4 
,@freq_subday_interval = 15 
,@freq_recurrence_factor = 0 
,@active_start_date = 20090506 
,@active_end_date = 99991231 
,@active_start_time = ' + @Time + '
,@active_end_time = 235900 
,@schedule_uid = @LS_SecondaryRestoreJobScheduleUID OUTPUT 
,@schedule_id = @LS_SecondaryRestoreJobScheduleID OUTPUT 
EXEC msdb.dbo.sp_attach_schedule 
@job_id = @LS_Secondary__RestoreJobId 
,@schedule_id = @LS_SecondaryRestoreJobScheduleID  
END 
IF (@@ERROR = 0 AND @LS_Add_RetCode = 0) 
BEGIN 
EXEC @LS_Add_RetCode2 = master.dbo.sp_add_log_shipping_secondary_database 
@secondary_database = ' +  ''''''' + db.Name + ''''''' +  CHAR(10) + '
,@primary_server = ''''' + @PrimServer + '''''
,@primary_database = '+  ''''''' + db.Name + ''''''' +  CHAR(10) +
',@restore_delay = 0 
,@restore_mode = 1 
,@disconnect_users= 1 
,@restore_threshold = 180   
,@threshold_alert_enabled = 1 
,@history_retention_period= 5760 
,@overwrite = 1 
END 
IF (@@error = 0 AND @LS_Add_RetCode = 0) 
BEGIN 
EXEC msdb.dbo.sp_update_job @job_id = @LS_Secondary__CopyJobId ,@enabled = 0 
EXEC msdb.dbo.sp_update_job @job_id = @LS_Secondary__RestoreJobId ,@enabled = 1 
END '''  + '[LSDBs] FROM #DBs db'
--Print @CMD
Insert #LogShipping (LSDBs)
Exec ( @CMD)
Set @Counter = @@rowcount
While (@counter > 0)
  Begin
  select top 1  @CMD = LSDBs from #LogShipping
  exec sp_executesql @CMD
  set @counter = @counter - 1
  delete top (1) from #LogShipping
  End
IF OBJECT_ID ('tempdb.DBO.#LogShipping','U') IS NOT NULL DROP TABLE #LogShipping
IF OBJECT_ID ('tempdb.DBO.#DBs','U') IS NOT NULL DROP TABLE #DBs
-- ****** End: Script to be run at Secondary:  9.3 Build ******
  1. Compruebe que los registros de transacciones se envían al recurso compartido y que DFS está replicando estos registros en el recurso compartido en el servidor de archivos de Azure. Abra el Monitor de actividad de trabajo en SQL Server para comprobar que los registros de transacciones se enviaron correctamente. Abra las carpetas compartidas en ambos servidores de archivos de la producción y las granjas de Servidores de Azure para comprobar que DFS transfiere los registros de transacciones.

Vea también

Conceptos

Configuración de grupos de disponibilidad de SQL Server Always On para SharePoint Server

Otros recursos

Acerca del trasvase de registros (SQL Server)

Tutoriales de replicación