Actualización de la base de datos IIS WebSite y SQL Server de producción sin detener

Question

Hay un servidor de prueba que usa la base de datos de prueba. Probamos el sitio web en el servidor de prueba. Si está bien, actualizamos el sitio web y el esquema de la base de datos desde el servidor de prueba al servidor de producción. Pero este método es muy doloroso y arriesgado.

Primero, tenemos que redireccionar a los usuarios a una página de mantenimiento, por lo que el sitio web está en pausa por un tiempo.

En segundo lugar, si algo sale mal al actualizar, tenemos que volver al sitio web anterior, porque no podemos poner el sitio web en modo de mantenimiento durante mucho tiempo.

Así que estoy buscando una solución sólida para actualizar un sitio web de IIS y una base de datos de servidor Sql sin pérdida de datos y utilizando el modo de mantenimiento. ¿Hay alguna manera de hacer esto? Cómo hacen los grandes sitios web sin perder datos y pausar.

Hemos pensado utilizar un sitio web de lanzamiento de candidato. Hemos planeado usar este sitio web de RC por temporario. Primero, actualizamos el sitio de RC, luego intercambiamos los enlaces entre RC y el sitio web de producción. Pero esta vez la base de datos es un problema. Porque podemos cambiar el esquema de la base de datos, y el anterior no puede funcionar con la nueva base de datos. Entonces, si usamos un sitio temporal con temp db, habrá pérdida de datos. Además, el sitio web actualizado no funcionará con la base de datos anterior si el sitio temporal usa una base de datos de producción anterior. Entonces necesito una solución sólida y práctica para este problema.

Answer 1

Esto es varios órdenes de magnitud más complicado de lo que se imagina. Esto específicamente es no sobre HA ni sobre la integración contigua. Ninguno de los dos proporcionará lo que necesita, solo son piezas del rompecabezas mucho más complejo.

Simplemente no es posible escribir cambios de código de forma transparente/ajena a los cambios de esquema cuando ocurren. En el mejor de los casos, puede escribir el código de una manera que admita el esquema en v. N y en v. N + 1, que en sí mismo es un gran desafío. Pero es imposible escribir el código de una manera que sea compatible con el esquema , ya que transiciones de v. N a v. N + 1. El cambio de esquema inducido por una implementación tiene que ser atómico para el código que opera en el esquema. Desde el propio cambio de esquema no puede ser atómica, cabe afirmar que la actualización tiene dos vías posibles:

• desconectar el código durante el cambio de esquema. Esto es lo que estás haciendo ahora y es el enfoque más seguro.Por supuesto, implica el tiempo de inactividad del servicio y ejecuta los riesgos que ya experimentó (reversión de la actualización fallida, actualización prolongada, etc.). Una variante de este enfoque es redirigir el servicio a una copia de solo lectura de los datos y ofrecer una experiencia de servicio degradada (no son posibles cambios durante el tiempo de inactividad) que puede o no ser aceptable, dependiendo de las especificaciones del negocio.

• actualización en modo de espera. Esto implica que usted toma una instantánea de los datos del servicio (varias soluciones de HA pueden proporcionar una instantánea de espera lista para usar, por ejemplo, envío de registro). Actualice la instantánea y luego aplique todas las transacciones que ocurrieron en los datos del servicio real a la instantánea actualizada. Esto siempre es complicado, ya que requiere una tecnología para detectar, capturar y aplicar los cambios (por ejemplo, cambio de seguimiento, replicación, solución personalizada, etc.) y requiere transformar cada cambio en el esquema nuevo y actualizado. Una vez que el esquema actualizado está actualizado con los cambios del servicio principal, el servicio puede redirigirse al esquema actualizado. Esta redirección es mucho más compleja de lo que parece. Para uno elegir el momento cuando cortar el esquema anterior y dejar de aceptar nuevos cambios, mientras se aseguraba de que todos los cambios se aplicaran al nuevo esquema actualizado DB es un desafío en sí mismo. Otro desafío es resolver el conflicto del código entendiendo las versiones de esquema previas y posteriores a la actualización. El código de desarrollo que maneja ambos es, como dije, problemático y propenso a errores, por lo que una solución es, de nuevo, desconectar el servicio por un período breve y reemplazar el código. Otra solución es tener un servicio en espera, ejecutando el código que maneja el esquema DB posterior a la actualización y está conectado a la base de datos posterior a la actualización, y redirige las solicitudes activas a su servicio en espera, actualizado.

Y ni siquiera tocar el espinoso tema de la interacción de servicio, cuando un servicio particular de una solución implementada mucho más grande tiene que ser actualizado. Aquí es cuando service API protocol back compatibility juega el papel principal para permitir que el servicio posterior a la actualización juegue junto con sus servicios pares.

En última instancia, simplemente no hay ninguna bala de plata. He sido testigo de implementaciones de grandes DB en una sola máquina que tomaron semanas para implementar la versión N + 1, con la replicación transcripcional que alimenta contiguamente el esquema DB posterior a la actualización con los cambios de la base de datos previa a la actualización. Y fui testigo de despliegues de miles de máquinas que implementan la versión N + 1 en etapas, como un baile complicado de cambios de códigos y datos en el transcurso de varios días para alcanzar la funcionalidad completa de la actualización posterior. Este problema es simplemente difícil.

Answer 2

Está describiendo una solución de alta disponibilidad (HA). Las soluciones de alta disponibilidad son costosas y pueden ser exageradas rápidamente. necesitaría redundancia para su aplicación y servidores db, lo que significa configurar un clúster db. Todo esto aumenta la cantidad de tiempo que pasaría implementando cambios, pero la compensación es que su aplicación siempre está disponible.

Lo principal de la implementación es tener un proceso repetible. Así que mi mejor recomendación es guiar o automatizar tanto como sea posible.

Answer 3

Esto es para lo que Azure es fantástico. La plataforma Azure Cloud permite servidores de etapas y servidores de producción. Puede configurarlo para que, una vez que haya enviado sus cambios a Git o TFS, lo envíe automáticamente a un servidor de producción o de producción. También puede configurar para presionar manualmente los cambios. La mayoría de las bibliotecas ORM como Entity Framework tienen soporte de migración.

hay mucha más información que hay sobre este tema como: Azure seamless upgrade when database schema changes Staging or Production Instance?