Compartir a través de

Conmutación por error y recuperación de bases de datos reflejadas en una única granja de servidores

  • Artículo

En este artículo se describe cómo conmutar por error y recuperar una granja de servidores de Microsoft Office SharePoint Server 2007 que está configurada para usar el reflejo de base de datos de alta disponibilidad, siguiendo los procedimientos descritos en el artículo Configuración de la disponibilidad en una única granja de servidores mediante la creación de reflejo de la base de datos de SQL Server.

En este artículo se incluyen las siguientes secciones:

  • Proceso de conmutación automática por error para una base de datos reflejada

  • Proceso de conmutación por error manual para una base de datos reflejada

  • Supervisión y alertas en la conmutación por error de reflejo

  • Trabajo: Conmutación por error de todas las bases de datos restantes

  • Trabajo: Actualización de los alias de conexión

  • Conmutación por recuperación

  • Resumen

Cuando se produce la conmutación por error en un entorno de Office SharePoint Server 2007 que ejecuta bases de datos reflejadas, debe producirse el siguiente proceso:

  • Una o varias bases de datos del servidor principal conmuta por error en el servidor reflejado, ya sea automáticamente o manualmente.

  • Se fuerza la conmutación por error en todas las otras bases de datos del servidor principal.

    Se recomienda usar alertas y trabajos de Microsoft SQL Server 2005 para supervisar el reflejo y forzar la conmutación por error de todas las bases de datos.

  • Los alias de conexión de todos los equipos y los servidores cliente web que hacen referencia a las bases de datos se restablecen para señalar al servidor reflejado.

Proceso de conmutación automática por error para una base de datos reflejada

La conmutación automática por error se produce cuando un servidor principal ha perdido la comunicación con el resto de la configuración de reflejo de base de datos, y el servidor reflejado y el servidor testigo retienen la comunicación.

Nota

Si todas las instancias de servidor pierden la comunicación, no se produce la conmutación automática por error, aunque el servidor testigo y el servidor reflejado vuelvan a recibir la comunicación más adelante.

Cuando se desencadena la conmutación automática por error, se produce el siguiente proceso:

  1. Si el servidor principal sigue ejecutándose, cambia el estado de la base de datos principal a DESCONECTADO y desconecta todos los clientes de la base de datos principal.

  2. El servidor testigo y el servidor reflejado registran que el servidor principal no está disponible.

  3. Si hay registros esperando en la cola Rehacer, el servidor reflejado finaliza la puesta al día de la base de datos reflejada. El tiempo necesario para aplicar el registro depende de la velocidad del sistema, la carga de trabajo reciente y el tamaño de los registros de la cola Rehacer.

  4. Cuando el servidor principal anterior vuelve a entrar en la sesión, reconoce que su servidor asociado de conmutación por error es el propietario de la función principal. El servidor principal anterior adopta la función de servidor reflejado y la base de datos principal anterior se convierte en la base de datos reflejada. El nuevo servidor reflejado sincroniza la nueva base de datos reflejada con la base de datos principal lo más rápido posible. En cuanto el nuevo servidor reflejado vuelva a sincronizar las bases de datos, podrá producirse de nuevo la conmutación por error, pero en el sentido inverso.

Para obtener una descripción más detallada de la conmutación automática por error, vea el tema sobre conmutación automática por error (https://go.microsoft.com/fwlink/?linkid=83690&clcid=0xC0A).

Proceso de conmutación por error manual para una base de datos reflejada

La conmutación por error manual suele ocurrir cuando el servidor principal y el servidor reflejado se están ejecutando. El administrador toma la decisión deliberada de cambiar la base de datos activa del servidor principal al servidor reflejado.

Durante una conmutación por error manual se produce el siguiente proceso:

  1. El administrador se conecta al servidor principal y emite los siguientes comandos de Transact-SQL para cada base de datos:

    USE master;
ALTER DATABASE <database_name> SET PARTNER FAILOVER; -- where database_name is the mirrored database.

    Esta instrucción inicia una transición inmediata del servidor reflejado a la función principal.

  2. En el servidor principal anterior, los clientes se desconectan de la base de datos y se revierten las transacciones no confirmadas.

Cuando se ejecuta una conmutación por error manual con una configuración de conmutación automática por error que incluye un servidor testigo, el servidor principal y el servidor reflejado cambian automáticamente las funciones.

Supervisión y alertas en la conmutación por error de reflejo

Use las alertas de SQL Server para supervisar el reflejo y ejecute trabajos que fuercen la conmutación por error. Los trabajos y las alertas deberán usarse tanto en la instancia principal como en la reflejada del servidor SQL Server.

Alerta: Detección del cambio de una sola base de datos de principal a reflejada

Dentro de la alerta, se usa un comando de Transact-SQL para detectar si cualquiera de las bases de datos ha cambiado a la base de datos reflejada correspondiente.

SELECT * FROM Database_MIRRORING_STATE_CHANGE 
WHERE State=8 AND (databasename='Central Administration' OR databasename='Configuration' 
ORdatabasename='SSP' 
OR databasename=’SSP Content' 
OR databasename='SSP Search' 
OR databasename='WSS Search' 
OR databasename='Content_<port>' )

Trabajo: Conmutación por error de todas las bases de datos restantes

Después de que se produzca la alerta de detección, ejecute un trabajo para conmutar por error todas las bases de datos a las bases de datos reflejadas correspondientes.

En el siguiente ejemplo se proporciona un script de Transact-SQL que puede usar dentro de un trabajo para conmutar por error todas las bases de datos reflejadas:

USE master;
DECLARE i CURSOR
READ_ONLY
FOR 
SELECT name FROM sys.databases WHERE database_id IN
(SELECT database_id FROM sys.database_mirroring WHERE mirroring_state=4)

DECLARE @name varchar(255)
DECLARE @cmd varchar(1000)
OPEN i

FETCH NEXT FROM i INTO @name
WHILE (@@fetch_status <> -1)
BEGIN
IF (@@fetch_status <> -2)
BEGIN
set @cmd = 'ALTER Database [' + @name + '] SET PARTNER FAILOVER;'
exec (@cmd)

DECLARE @message varchar(100)
SELECT @message = 'Failover for : ' + @name
PRINT @message
END
FETCH NEXT FROM i INTO @name
END

CLOSE i
DEALLOCATE i
GO

Trabajo: Actualización de los alias de conexión

Tras la conmutación por error, el nombre del servidor de base de datos asociado al alias de conexión de SQL Server debe cambiarse del servidor principal al servidor reflejado en todos los equipos que ejecuten Office SharePoint Server 2007.

Nota

La referencia dentro de cada aplicación web no cambia. Por tanto, no es necesario realizar ninguna tarea en Office SharePoint Server 2007 tras la conmutación por error.

Cree un trabajo de SQL Server para que se ejecute cuando se complete la conmutación por error. Dentro del trabajo, ejecute un comando que cambie el valor de configuración del Registro para el valor del alias al reflejo:

\Registry\Machine\SOFTWARE\Microsoft\MSSQLServer\Client\ConnectTo
<alias> = REG_SZ DBMSSOCN,DBMirror

Nota

La cuenta que use para ejecutar los trabajos y las alertas de SQL Server debe tener los permisos adecuados para cambiar los valores del Registro en los equipos que ejecutan Office SharePoint Server 2007. Para obtener más información, vea el tema sobre asignación de permisos a una clave del Registro (https://go.microsoft.com/fwlink/?linkid=116137&clcid=0xC0A).

Para obtener un ejemplo de cómo crear este trabajo, vea Caso práctico de alta disponibilidad para SharePoint mediante la creación de reflejo de la base de datos (notas del producto).

Conmutación por recuperación

Para conmutar por recuperación al servidor principal, debe conmutar por recuperación las bases de datos manualmente. Puede usar los mismos trabajos de SQL Server para automatizar la conmutación por recuperación y restablecer los alias de conexión del cliente SQL Server. Debe cambiar los valores de los trabajos antes de ejecutarlos.

Resumen

Después de configurar el reflejo en un entorno de una única granja de servidores, se recomienda probar los procesos, las alertas, los trabajos y los scripts para la conmutación por error y la conmutación por recuperación. Si una sola base de datos conmuta por error, es posible que desee escribir scripts que intenten realizar primero la conmutación por recuperación al servidor principal, antes de realizar la conmutación por error de todas las otras bases de datos del servidor reflejado.

Descargar este libro

En este tema se incluye el siguiente libro descargable para facilitar la lectura y la impresión: