Migración y Upgrade con Database Mirroring

 

El objetivo de este post es auto-documentar un proceso de migración y upgrade de una base de datos SQL Server 2014 a un nuevo servidor con SQL Server 2017 que tuve a cargo. Durante este proceso tuve que solucionar una serie de problemas los cuales también hago referencia en este post por si a alguien también le sucede. El requerimiento principal era minimizar el tiempo de desconexión de las aplicaciones con la base de datos. Documentación y blogs sobre este tema hay muchos, pero la gran mayoría en ingles por eso me anime también a documentarlo en español.

“Mirroring” es una tecnología que ha estado en SQL Server desde hace ya muchos años y ha sido marcada como deprecada desde la versión de SQL Server 2012, sin embargo hasta hoy no ha sido removida del motor, y según mi opinión personal no será removida aun en las futuras versiones debido a que es ideal para la migración y upgrade de versiones inferiores, especialmente a versiones menores a SQL Server 2012 ya que en esa versión nace lo que conocemos como Always On, lo que vendría a ser la evolución de “Mirroring”.

Bueno, configurar “Mirroring” es bastante sencillo, en mi caso particular solo tendré 2 instancias, la principal será un SQL Server 2014 y la “mirror” o destino será una instancia SQL Server 2017, felizmente el “upgrade” entre estas 2 instancias es directo y no tendre que hacer un “upgrade” intermedio.

Es muy importante conocer que, si intentamos hacer este “upgrade” a la instancia SQL Server 2017 recién instalada, es decir en la versión RTM (14.0.1000.169), no podrá sincronizarse con su base de datos principal y obtendrán un estado como el siguiente. La solución es parchar la instancia SQL Server 2017 hasta su último CU (Cumulative Update), que en este momento es el CU7 (14.0.3026.27).

WINWORD_2018-06-05_11-52-01

Estos son los pasos a seguir para configurar “mirroring” entre estas 2 instancias:

  • Asegurarnos que la base de datos a migrar se encuentre en modelo de recuperación Full, aqui pueden encontrar un post que tengo sobre los modelos de recuperación.
  • Obtener un backup full y al menos 1 backup de log de la base de datos principal, pueden ser mas de un backup de log, la idea es que estos backups nos permitirán restaurar la base de datos en el servidor destino al estado más reciente de esta.
  • Si se tiene un firewall en el medio de los dos servidores verificar que se encuentren abiertos los puertos por los cuales el “Mirroring” se comunicará. Por defecto Mirroring sugiere el uso del puerto 5022.
  • Restaurar los backups Full y de Log en la instancia destino, pero dejar la base de datos en modo no recovery. Para esto es importante incluir la opción “WITH NORECOVERY” al momento de hacer la restauración de ambos backups, o asegurarse de seleccionar la opción correcta desde el wizard.

2018-06-04_11-40-16

  • Luego de terminar los “restores” en la instancia destino, la base de datos deberia estar en un estado “Restoring”, en este estado no podra ser accedida por un usuario normal. Esto es un requerimiento para la configuración de “Mirroring”.

2018-06-04_11-43-21

Hasta este punto tenemos casi todo listo para crear el “Mirroring” entre ambas bases de datos, esto se puede hacer de la manera gráfica a través del Wizard que nos ofrece SSMS, pero para serles sincero, cada vez que intento configurarlo con mi SSMS 17.7 obtengo errores como este:

“Database ‘xxx’ cannot be opened. It is in the middle of a restore. (Microsoft SQL Server, Error: 927)”

2018-06-04_11-51-33

Imagino que con un SSMS de alguna versión inferior esto quizás si hubiera sido posible, pero para mi caso particular decidí dejar ese problema atrás y hacerlo de la manera manual, es decir con T-SQL. Entonces para proceder debemos primero crear los “endpoints”, estos son los “listeners” que utilizara el proceso de “mirroring” para la comunicación entre las instancias, estos “endpoints” escucharan en un puerto determinado que por defecto es 5022, pero puede ser a cualquier otro que este libre en el servidor. Los “endpoints” deben ser creados en ambos servidores, tanto en el principal (SQL 2014) como en el destino (SQL 2017), en el siguiente código crearemos el “endpoint” en estado encendido, ya que esto también es requerimiento.

CREATE ENDPOINT [Mirroring]
STATE = STARTED
AS TCP (LISTENER_PORT = 5022)
FOR DATA_MIRRORING (ROLE = PARTNER, ENCRYPTION = REQUIRED ALGORITHM RC4)
GO

Podemos verificar el estado de los “endpoints” con la siguiente consulta:

select state_desc, role_desc
from sys.database_mirroring_endpoints

RDCMan_2018-06-04_12-07-25

Ahora, debemos crear un “login” para el usuario que ejecuta los servicios de SQL Server dentro de las instancias de base de datos. Lo ideal y lo que paso en mi caso es utilizar un usuario de dominio para ejecutar el servicio de SQL Server, como lo indicamos acá y acá, Este usuario debe tener permisos de conexión a la instancia y al “endpoint” que creamos en el paso anterior.

USE [master]
GO
CREATE LOGIN [YOURDOMAIN\SQLServiceUser] FROM WINDOWS WITH DEFAULT_DATABASE=[master]
GO
GRANT CONNECT SQL TO [YOURDOMAIN\SQLServiceUser]
GO
GRANT CONNECT ON ENDPOINT::[Mirroring] TO [YOURDOMAIN\SQLServiceUser]
GO

Para estar 100% seguros que los permisos estan OK, podemos utilizar la siguiente consulta que nos permitirá ver los permisos que le otorgamos al usuario:

select sp.permission_name, sp.class_desc, ep.name as [endpoint]
from sys.server_permissions sp
left join sys.database_mirroring_endpoints ep
on sp.major_id = ep.endpoint_id
where suser_name(SP.grantee_principal_id) = 'YOURDOMAIN\SQLServiceUser'

RDCMan_2018-06-04_12-26-14

Finalmente debemos activar la comunicación entre ambas bases de datos utilizando la siguiente sentencia. Es importante hacer esto primero en el servidor “Mirror” (destino), en mi caso seria en la instancia SQL Server 2017, y luego en el servidor principal, en mi caso el SQL Server 2014. Para activar la comunicación se debe ejecuar la siguiente instrucción:

ALTER DATABASE [YourDatabase] SET PARTNER = N'TCP://servidor_contrarior.tudominio.com:5022'

Si esto se hace en el orden incorrecto podemos encontrar errores como el siguiente:

Msg 1416, Level 16, State 31, Line 27
Database “YourDatabase” is not configured for database mirroring.

Una vez que se ha activado la comunicación entre las dos bases de datos, estas se mostraran como sigue:

2018-06-04_15-17-082018-06-04_15-17-18

Ahora que ya están listas las bases de datos, cada modificación que se haga en la base de datos principal será enviada por medio de un registro de log de transacciones hacia la base de datos “mirror”. Cuando finalmente se tenga todo listo para la migración de la base de datos, simplemente debemos hacer un proceso de “failover” y automáticamente SQL Server cambiara el rol entre las bases de datos, en mi caso, colocando como principal la instancia de SQL Server 2017 y como “mirror” la de SQL 2014. Esta operación de “failover” se puede hacer desde el mismo “wizard” de “mirroring” o a través de un comando T-SQL:

2018-06-05_14-13-19

USE master
GO
ALTER DATABASE [YourDatabase] SET PARTNER FAILOVER
GO

Terminado el proceso de “failover” y como nuestra base de datos original era de versión SQL Server 2014, es decir inferior a la actual principal (SQL Server 2017), entonces el proceso de “mirroring” quedara como suspendido ya que no habra manera de regresar al servidor anterior debido a que la base de datos ha sufrido el proceso de “upgrade” en el momento del “failover” y no sera posible hacerle un proceso de “downgrade”.

WINWORD_2018-06-05_14-25-34

3 comentarios sobre “Migración y Upgrade con Database Mirroring

  1. Buenas tardes

    Quiero hacer mirror todo en 2 servidores con sql server 2016, efectivamente si lo hago por el ambiente grafico me sale el mismo mensaje que tu describes, asi que segui tu procedimiento por transact, todo esta aparentemente bien hasta la parte en que dices que ya debemos establecer la comunicacion con este comando ALTER DATABASE [YourDatabase] SET PARTNER = N’TCP://servidor_contrarior.tudominio.com:5022′
    Efectivamente lo corro primero en el secundario pero me sale el siguiente error que nada tiene que ver con el que especificas, te aclaro que yo no quiero usar testigo, solo quiero usar dos servidores, el mensaje es el siguiente: Msg 1431, Level 16, State 4, Line 2
    Neither the partner nor the witness server instance for database “novaprueba” is available. Reissue the command when at least one of the instances becomes available.
    El comando lo estoy ejecutando asi
    ALTER DATABASE [prueba] SET PARTNER = N’TCP://drift.com:5022′ de acuerdo a lo que dijiste,

    ALTER DATABASE [YourDatabase] SET PARTNER = N’TCP://servidor_contrarior.tudominio.com:5022′

    No se si me puedes dar alguna indicación de que estará haciendose mal.

    Gracias por tu colaboración

    1. Hola Fabio, por el error que me describes, me da la impresión que ambas instancias de base de datos no pueden comunicarse, has verificado que el firewall entre ambos servidores permiten el acceso a través de los puertos indicados, o en todo caso sugiero bajar completamente el firewall de ambos servidores para que se pueda probar la conectividad entre ambas instancias.

      1. Hola, gracias por responder, no creo que sea el problema pues los dos firewall los tengo abajo y puedo hacer telnet tranquilamente a los puertos desde ambos servidores. Los endpoint se crean correctamente pero al final nunca puedo hacer el mirror. La verdad no se que hacer no me funciona por entorno grafico ni tampoco por transact.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Salir /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Salir /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Salir /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Salir /  Cambiar )

Conectando a %s