Mover bases de datos a nuevos centros de datos

Mi empresa está trasladando nuestra infraestructura a un nuevo centro de datos y estoy tratando de encontrar la mejor manera de mantener la base de datos en el nuevo servidor sincronizada con la base de datos de producción actual hasta que los nuevos entornos estén listos para funcionar. Al no ser un DBA a tiempo completo, investigué un poco y, según lo que he leído, parece que una configuración de replicación transnacional satisfaría mejor nuestras necesidades.

Algunos detalles: el DB de producción tiene un tamaño de alrededor de 90 GB y el uso de Robocopy tardó aproximadamente 9 horas en mover una copia de él a uno de los nuevos servidores. La base de datos de producción actual deberá permanecer en línea y accesible durante todo el proceso de migración. Está en recuperación simple, por lo que la duplicación de la base de datos no está disponible.

¿Es una replicación transaccional el mejor método para mantener las bases de datos sincronizadas?

Mi plan:

1. (Listo) Transfiera la base de datos actual e inicie sesión en el nuevo servidor y adjúntelo a la nueva instancia de SQL Server
2. Configure un distribuidor en nuestra máquina de base de datos de desarrollo y publíquelo desde la base de datos de producción
3. Cree un suscriptor en la nueva máquina de base de datos que aceptará actualizaciones que se envían desde el distribuidor, una vez cada noche

Hay dos cosas en mi mente. La replicación transaccional requiere que cada tabla publicada tenga una clave primaria y muchas de las tablas en la base de datos de producción no tienen claves primarias definidas. No creo que esto sea un problema demasiado grande ya que mi principal preocupación es simplemente sincronizar las bases de datos. Probaremos las diferentes aplicaciones que utilizan la base de datos en un momento posterior, pero me gustaría asegurarme de que no sea un problema grave. En segundo lugar, ¿debo mover también cualquier base de datos del sistema asociada de la instancia original, como master? Nos estamos moviendo a una configuración de Active Directory en el nuevo entorno, por lo que no me importan los usuarios y demás, pero no estoy seguro de la necesidad de las bases de datos del sistema.

Y solo en general, ¿estoy captando estos conceptos correctamente?

Tu situación actual:

• Base de datos de 90 GB que desea mover a un nuevo centro de datos.
• La base de datos está en recuperación simple.
• Está pensando en usar T-Rep para mantener los datos sincronizados.
• Hay muchas tablas en la base de datos que no tienen Clave primaria; este es un requisito para que cualquier tabla se publique.
• Ya tiene una copia de seguridad copiada en el centro de datos de destino.

Veo muchos inconvenientes en su enfoque:

• T-Rep no es fácil de configurar en comparación con otras tecnologías. Si hay algún cambio en el esquema, entonces se requiere una nueva instantánea.
• Si va a utilizar T-REP, debe realizar cambios en el esquema: agregue la clave principal a las tablas que no lo tienen.
• Al hacer cualquier cambio en su base de datos existente, su aplicación tiene que ser completamente probada para evitar cualquier comportamiento inesperado.
• Si su base de datos tiene una gran cantidad de transacciones y depende del ancho de banda de la red entre los 2 centros de datos, también habrá latencia de replicación.

Según mi experiencia, a continuación es mi recomendación:

• Cambie su base de datos a recuperación completa. Este no es un impacto importante en comparación con la creación de PK.
• Envíe la copia de seguridad completa de la base de datos de origen: realice una copia de seguridad con compresión y active la inicialización instantánea de archivos. Esto lo ayudará a reducir el tiempo de restauración en el centro de datos de destino.
• Restaurar la base de datos en el servidor de destino WITH NORECOVERY.
• Implemente Logshipping e inicialícelo desde la copia de seguridad.
• Haga que el envío de registros envíe los registros cada 1 minuto.
• Durante el día de la conmutación por error, realice una última copia de seguridad del registro de cola en el origen y restaúrela en el destino utilizando WITH RECOVERY. Esto traerá la base de datos de destino en línea.
• Una vez que la base de datos de destino está en línea, debe sincronizar los usuarios .
• Debe cambiar su web.config para apuntarlo al nuevo servidor.

No tiene que mover ninguna base de datos del sistema. Asegúrese de hacer todo el trabajo de preparación antes de escribir manualmente los inicios de sesión, trabajos, paquetes ssis, etc. y créelos en el servidor de destino.

Consulte esta respuesta para conocer los pasos posteriores a la restauración y otras prácticas recomendadas .

Nota: También puede implementar la creación de reflejo de la base de datos (SYNC o ASYNC dependiendo de la edición del servidor sql que esté utilizando), pero el registro de registros es simple de implementar y si lo prueba, no lo decepcionará. He movido con éxito la base de datos de terabytes de un centro de datos a otro utilizando la técnica anterior y funciona perfectamente bien.

La base de datos de producción actual deberá permanecer en línea y accesible durante todo el proceso de migración.

Siempre habrá un tiempo de inactividad y deberá programarlo. Incluso si invierte pagando una gran cantidad de dinero en soluciones como la agrupación, cuando realice la conmutación por error, habrá algún tiempo de inactividad. Debe equilibrar cuánto puede invertir su empresa para tener un tiempo de inactividad cercano a cero frente a lo que está disponible con un tiempo de inactividad aceptable.

No tuve la oportunidad de usar esto yo mismo y creo que todavía está en la vista previa, pero SQL Data Sync en la plataforma Azure podría ser una opción potencial:

https://azure.microsoft.com/en-gb/documentation/articles/sql-database-get-started-sql-data-sync/

Funciona con bases de datos in situ, así como con Azure SQL, y parece una herramienta útil para mantener las bases de datos sincronizadas.