Guía rápida para usar ¨direct seeding¨ en sql server 2016 y posterior
La característica del producto:
SQL Server 2016 SP1 introdujo ¨Direct Seeding¨ para configuraciones de alta disponibilidad estilo ¨Always ON AG¨. Esta es una pequeña guía de como entender que es y algunas recomendaciones de uso
El Problema:
En versiones anteriores a 2016, para configurar una replica en AG, se tenía que seguir un proceso un tanto manual, sacar un backup de la base de datos productiva, luego un par de backups de la bitácora de transacciones, copiar estos archivos al nodo secundario y ejecutar una recuperación de la base de datos usando la opción ¨no recovery¨.
Finalmente abrir el wizard de configuración y seguir los pasos en pantalla esperando que el instalador identificara que todos estos pasos fueron ejecutados exitosamente. Si tienes muchas bases de datos, tendrás que hacer esto una y otra vez con todas.
La solución:
Esta nueva funcionalidad trabaja así: configuras el grupo de AG, y cada vez que agregas una base de datos al grupo, inmediatamente se replicará la base de datos a los nodos secundarios, será solo un cascarón vació, que ser irá llenando de forma paulatina.
SQL server se encargará de hacerlo de forma asincrónica para no afectar la base de datos productiva. De esta forma ya no tienes que hacer backups, copias, restores, etc.
Para utilizar esta opción yo siempre uso TSQL, y es solo de asegurarse que al crear el grupo configures la propiedad “SEEDING_MODE”, algo así:
USE master
GO
CREATE AVAILABILITY GROUP AGG01
FOR
REPLICA ON
N‘DB1’
WITH (ENDPOINT_URL = N‘TCP:// DB1.MyDomain.COM:5022’,
FAILOVER_MODE = AUTOMATIC,
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
BACKUP_PRIORITY = 50,
SECONDARY_ROLE(ALLOW_CONNECTIONS = NO),
SEEDING_MODE = AUTOMATIC)
Luego solo debes agregar las bases de datos al grupo de esta forma:
ALTER AVAILABILITY GROUP AGG01 JOIN ALTER AVAILABILITY GROUP AGG01 GRANT CREATE ANY DATABASE; GO
ALTER AVAILABILITY GROUP AGG01 ADD DATABASE DB1;
GO
Más detalles de como implementar en este link:
Y esto es todo, SQL Server hará la carga pesada por ti. Sin embargo, te menciono algunas alertas de uso:
- Si tienes bases de datos gigantes, toda la data viajará por la red, así que el proceso podría durar horas/días para escenarios de múltiples terabytes.
- Revisa también la latencia entre nodos, si tienes nodos secundarios en otra ubicación remota esto podría afectarte. La compresión de este proceso de copia no está habilitada por defecto, podrás habilitarlo con el traceflag 9567.
- Una base de datos que esté en medio proceso de copia no puede truncar su bitácora de transacciones, así que durante este periodo tu base de datos productiva tendrá un crecimiento en su disco de bitácora, debes planear tener suficiente disco libre para esto.
A continuación, unas vistas de sistema que te permitirán revisar el estado de la copia entre nodos de forma fácil:
sys.dm_hadr_automatic_seeding
sys.dm_hadr_physical_seeding_stats
CONCLUSIÓN:
La funcionalidad ¨direct seeding¨ te reduce el costo administrativo cuando quieres configurar un SQL Server en alta disponibilidad.
Sin embargo, cuando tienes bases de datos muy grandes ( VLD ) es mejor seguir el proceso usual a menos que estés seguro de contar con una red de alto rendimiento.
Sea parte de nuestra comunidad y suscríbase a nuestro blog