Añadir ficheros en AlwaysOn con rutas diferentes

Las arquitecturas que utilizan la tecnología AlwaysON son bastante flexibles y se puede llegar a configurar un escenario en el que todos los nodos de tu solución estén montados con letras de unidad diferente, produciendo que las bases de datos estén sobre rutas distintas entre cada nodo. Esta situación no tiene nigún problema de rendimiento, pero si que nos fuerza a llevar un control algo especial sobre las operaciones de mantenimiento que impliquen modificar de ubicación ficheros de nuestras BBDD.  En este post veremos cómo proceder a añadir un fichero sobre una solución AlwaysON donde nuestra BBDD esté ubicada sobre rutas diferentes en cada uno de nuestros nodos.

Un escenario común con el que nos podemos topar cuando trabajamos con bases de datos es el de tener que crear nuevos ficheros para hacer particionado físico, añadir filestream…No es nada raro el tener que hacerlo, pero si que hay que tener en cuenta que la cosa cambia cuando tenemos entre manos un AlwaysON en el que no se tienen las mismas rutas entre nuestros nodos.

Partiré del entorno MultiSite que preparé para la guia de instalación de entornos MultiSite con AlwaysON que puedes leer aquí , a la que he modificado simplemente añadiendo unas cuantas unidades de disco diferentes a cada nodo para que tengamos el escenario propuesto

Partimos por tanto de un AlwaysON con estas características:

Donde, recordando la arquitectura sobre la que está montado tenemos 3 nodos en AlwaysON, estando W2K8R2N1SQL2012_HADR1 y W2K8R2N2SQL2012_HADR2 en un CPD y en otro CPD diferente con otro direccionamiento IP tendremos a la instancia W2K8R2MS1SQL2012

[box type=”info”] Para mas detalles lee mi post “Implementación de un Sistema de Alta Disponibilidad en SQL Server 2012 con AlwaysON“[/box]

Si nos centramos en la BBDD MyDatabase, veremos que en cada una de las instancias, las rutas de los ficheros de datos son diferentes:

 

Si lo que queremos es por tanto añadir un nuevo fichero a nuestra BBDD, veremos que dependiendo de la instancia deberemos añadirlo en R:Data, S:Data o T:Data dependiendo de en qué instancia estemos. Si no hacemos nada, ocurrirá un error puesto que se replicará el comando de añadir el fichero sobre la unidad que hayamos elegido y se parará el AlwaysON para nuestra BBDD. Si estás en esa situación, la solución pasa por volver a empezar la sincronización de 0 de toda la base de datos.

[learn_more caption=”Si tu AlwaysON está caido”] Si no leíste este post antes de realizar el comando ADD FILE y por tanto tienes tu AlwaysON de BBDD parado, aquí puedes encontrar la forma de resolver tu situación: https://msdn.microsoft.com/es-es/library/hh510190.aspx[/learn_more]

Si por el contrario has leído este post antes de realizar el comando ADD FILE, los pasos son los siguientes:

-- Nos conectamos al nodo que esté trabajando como nodo PRINCIPAL
:connect W2K8R2N1SQL2012_HADR1
USE [master]
GO

--1 Eliminamos del Grupo de disponibilidad la BBDD sobre la que queremos añadir un nuevo fichero
--
ALTER AVAILABILITY GROUP [MultiSiteTestAG]
REMOVE DATABASE [MyDatabase];
GO

-- 2 Hacemos la tarea de mantenimiento que sea, en este caso hemos puesto de ejemplo añadir un fichero
--
-- Añadimos el fichero en la BBDD principal
--
USE [master]
GO
ALTER DATABASE [MyDatabase] ADD FILE ( NAME = N'MyNewFile', 
FILENAME = N'R:DataMyNewFile.ndf' , 
SIZE = 5120KB , FILEGROWTH = 1024KB ) 
TO FILEGROUP [PRIMARY]
GO

-- 3 Ahora importante es hacer un backup del log, que llevará dentro el nuevo fichero
-- IMPORTANTE: Recuerda que durante este proceso no puede haber ningun otro backup, puesto que si lo hay deberemos hacernos cargo de él.
--
BACKUP LOG [MyDatabase] 
TO  DISK = N'R:Databk.log' 
WITH NOFORMAT, NOINIT,  NAME = N'MyDatabase-Transaction Log  Backup', 
SKIP, NOREWIND, NOUNLOAD,  STATS = 10
GO

Una vez hecho esto, tendremos nuestro AlwaysON desconectado (pero solo para la BBDD en cuestión) y la idea es que sea por un muy breve espacio de tiempo. Estaremos por tanto en esta situación en la que tenemos el resto de BBDD funcionando en AlwaysON, pero la nuestra estará fuera del grupo de disponibilidad, aunque obviamente no se ha borrado.

Una cosa que debes saber es que ahora no podrás restaurar el log de transacciones que hemos creado en el paso anterior mediante el asistente de SSMS, porque por error detecta que estamos en LSN diferente, pero es un error de GUI simplemente. Si intentas hacerlo recibiras este error:

No te preocupes porque lo vamos a hacer manualmente.

--  Nos conectamos a uno de nuestros nodos secundarios y actualizamos el log de transacciones
--  Puesto que en dicho log viene la operacion de creación de nuevo fichero, debemos decirle en cada caso
-- sobre qué ruta queremos el fichero, que obviamente no podrá ser R, sino S o T en nuestro caso
--
:Connect W2K8R2N2SQL2012_HADR2
restore filelistonly from disk = N'S:Databk.log'

RESTORE DATABASE MyDatabase
FROM DISK = N'S:Databk.log'
 WITH NORECOVERY,
 MOVE 'MyNewFile'
  TO 'S:DataMyNewFile.ndf'


:Connect W2K8R2MS1SQL2012
restore filelistonly from disk = N'T:Databk.log'

RESTORE DATABASE MyDatabase
FROM DISK = N'T:Databk.log'
 WITH NORECOVERY,
 MOVE 'MyNewFile'
  TO 'T:DataMyNewFile.ndf'

Una vez hecho esto, ya podremos resincronizar nuestro AlwaysON con normalidad

Y la seleccionamos finalmente:

Continuando por tanto con total normalidad en nuestra Arquitectura AlwaysON

[box type=”info”] Todo el proceso es ONLINE, por lo que las aplicaciones pueden trabajar con nuestra BBDD principal. Recuerda no obstante que la BBDD en los nodos secundarios estará durante un periodo de tiempo en modo NORECOVERY por lo que tus aplicaciones deberán conectar contra el nodo principal.[/box]