¿Cómo actualiza su base de código de producción / esquema de base de datos sin causar tiempo de inactividad?

42

¿Cuáles son algunas técnicas para actualizar el esquema de base de datos / base de código de un servidor de producción sin causar ningún tiempo de inactividad?

deployment

— Olivier Lalonde
fuente

1

Buena pregunta porque veo que mucha gente pasa por alto esto. El tiempo es dinero y el tiempo de inactividad nunca se ve bien para los usuarios finales, independientemente de cuán legítimo sea el motivo.

— Dan McGrath el

@Dan McGrath: lo que supone que en realidad puede tener un tiempo de inactividad, trabajo para un sistema que (normalmente) está inactivo solo 4 veces al año (interrupción trimestral) y durante 15 minutos como máximo cada vez (tiempo durante el cual el tráfico está en cola). .. los cambios en la base de datos son muy analizados :)

— Matthieu M.

2

Esta sería una gran pregunta para dba.stackexchange.com , que entra en versión beta pública en unas pocas horas.

— Larry Coleman

20

En general, los sitios web en los que he trabajado que tenían este tipo de requisitos estaban todos detrás de equilibradores de carga o tenían ubicaciones de conmutación por error separadas. En este ejemplo, supondré que tiene un solo equilibrador de carga, 2 servidores web (A y B) y 2 servidores de bases de datos (M y N, por lo general, los servidores de bases de datos están vinculados mediante logshipping, al menos en el mundo de SQL Server )

El servidor web A se desconectará del equilibrador de carga (por lo que todo el tráfico entrante va a B).
El envío de registros se detiene (DB Server M se actualizará primero).
Actualizar el servidor web A. Apunte la configuración a DB Server M.
Pruebe y verifique que la actualización funcionó (por lo general, las personas están presionando la dirección IP directamente).
Configure el equilibrador de carga para que las sesiones existentes continúen yendo a B. Las nuevas sesiones van a A.
Espere a que caduquen todas las sesiones en B (puede ser media hora o más, generalmente observamos el tráfico y tenemos un descanso de 1 hora programado).
Actualización B y N.
Pruebe y verifique que la actualización funcionó.
Configure el envío de registros nuevamente y pruebe que funciona.
Establezca el equilibrador de carga en funcionamiento normal.

En aplicaciones web muy complicadas, lo que se describe como los pasos 1-5 puede llevar toda la noche y ser una hoja de cálculo Excel de 50 páginas con horas y números de contacto de emergencia. En tales situaciones, la actualización de la mitad del sistema está programada de 6 p.m. a 6 a.m., mientras que el sistema está disponible para los usuarios. El manejo de la actualización para el sitio de DR generalmente está programado para la noche siguiente, solo espero que nada se rompa el primer día.

Cuando el tiempo de actividad es un requisito, los parches se prueban primero en el entorno de control de calidad, que idealmente es el mismo hardware que la producción. Si no muestran interrupción, se pueden aplicar en el horario regular, que generalmente es el fin de semana.

— Tangurena
fuente

77

¿Cómo propone fusionar nuevos datos de DB M y DB N? Ambos tendrán registros nuevos, actualizados y eliminados que el otro no tiene.

— sixtyfootersdude

@Tangurena, ¿puedes responder el comentario anterior?

— sino

9

Para bases de datos típicas (Oracle, por ejemplo) es posible alterar el esquema de la base de datos mientras se siguen ejecutando consultas en paralelo. Sin embargo, requiere una planificación anticipada.

Hay algunas restricciones para que se aplique el cambio:

debería funcionar con el código existente, lo que significa que el código debe tratar con las versiones antiguas y nuevas del esquema
no debería incurrir en tal carga en el DB que las transacciones se detendrían (te estoy mirando CREATE INDEX)
no debe incurrir en la pérdida de datos (no puede descartar y volver a crear una tabla)

Para que el esquema sea compatible con versiones anteriores, generalmente puede AGREGAR o MODIFICAR una columna, solo puede COLOCAR algo si el código existente ya no lo usa.

Si su código no puede manejar el cambio de manera transparente, cambie el código antes de cambiar la base de datos.

Consejos simples sobre planificación anticipada: siempre explique los nombres de columna en sus solicitudes de base de datos (no usar SELECT * FROM). De esta manera, no aparecerá columnas nuevas en solicitudes antiguas.

— Matthieu M.
fuente

1

En realidad, para una planificación y adaptabilidad avanzadas, seleccionar * de es infinitamente mejor que listar columnas manualmente. El uso de nombres de columna explícitos genera una gran deuda técnica en la mayoría de los casos. Si su código se rompe de nuevas columnas, su código ya está roto.

— Morg

@Morg .: No realmente. Por seguridad, debe usar variables de enlace, que en el marco que uso (al menos) requiere proporcionar las variables para escribir, y debe haber exactamente tantas variables como columnas de salida, por select *lo que el código se rompe si un se agrega una nueva columna (por falta de una variable para escribirla). Por supuesto, esto puede ser el resultado del uso de un lenguaje fuertemente tipado.

— Matthieu M.

Sí, realmente, no hay seguridad adicional para evitar seleccionar *. No tiene nada que ver con lenguajes fuertemente tipados y todo que ver con un diseño muy malo. Si su marco no puede manejar el cambio sin problemas, es inútil. Cuando cambio una columna, mi aplicación nunca deja de funcionar. Cuando lo haces se rompe. No creo que haya dudas sobre cuál es más confiable o seguro.

— Morg

@Morg .: No veo cómo select *es más confiable y seguro. Si solía tener, select one, two from ...entonces solo estaba usando oney two; si thirdse agrega a la tabla, entonces no tiene uso (aquí), por lo que no hay razón para recuperarlo. Y si necesita usarlo de repente, entonces modificará el código, ¡así que también podría modificar la consulta en este punto!

— Matthieu M.

@Morg .: Bueno, parece que estamos hablando unos de otros, probablemente porque nuestras experiencias difieren. Trabajo en productos donde el rendimiento es una propiedad primordial, y esto significa que selectdebe ser lo más selectivo posible (y cubierto por un índice), de lo contrario estoy brindis (incluso antes de las uniones obligatorias). Lamento decirlo, pero el enfoque que está describiendo fue un fracaso total en esos productos.

— Matthieu M.

5

No todos los sistemas pueden, tiene que configurarse de una manera que lo admita.

Por ejemplo, uno de nuestros sistemas principales que ayudé a actualizar hace unos años debería estar disponible las 24 horas, los 7 días de la semana. Consistía en múltiples niveles, incluido un nivel de comunicación puro entre la capa de interfaz de usuario externa y la capa empresarial. Debido a la forma en que se codificó la capa de comunicación, cualquier cambio futuro en el esquema de Business Layer o DB podría implementarse sin una interrupción real. En el peor de los casos, un usuario experimentaría una pausa de 10-30 segundos a medida que los cambios surtieran efecto.

Si los cambios fueran puramente cambios de código en la capa empresarial, podrían ponerse en cola y 'ciclarse' con solo un retraso de milisegundos.

Podría hacer esto porque:

La capa de comunicación podría contener mensajes. Esto nos permitió tener una interrupción real en cualquiera de los niveles que no sean la capa de interfaz de usuario sin necesidad de derribar la interfaz de usuario.
La capa empresarial manejada por el MVDB se llama UniData . Esto contiene todo el código en la memoria. Después de compilar el código, puede usar un comando para forzar el nuevo código objeto en la memoria, reemplazando el antiguo.

Otras técnicas implican la replicación de transacciones a otro espejo del sistema existente. Al aplicar la actualización a uno, cambiar y reproducir todas las transacciones realizadas entre la actualización y el cambio. Sin embargo, YMMV depende de sus sistemas.

— Dan McGrath
fuente

1

Aquí hay una perspectiva diferente, del mundo de los sistemas de bases de datos y sistemas integrados. Los sistemas integrados incluyen varios equipos de infraestructura de red / telecomunicaciones, y en este ámbito a menudo hablan del 99,999% (cinco 9s) de tiempo de actividad.

Nosotros (McObject) somos el proveedor de la familia eXtremeDB de productos de sistemas de bases de datos integradas, incluida eXtremeDB High Availability.

Primero, comprenda que "base de datos incrustada" significa que el sistema de base de datos es una biblioteca que se compila y se vincula con su código de aplicación; en ese sentido, está "incrustado" en su aplicación.

Con eXtremeDB High Availability, hay una instancia MASTER de su aplicación (que podría ser uno o varios procesos) y una o más instancias REPLICA de su aplicación. Cuando una réplica establece una conexión con el maestro, recibe una copia de la base de datos del maestro a través de un proceso llamado "sincronización inicial". Esto se puede hacer mientras la aplicación maestra continúa su trabajo. Una vez sincronizado, recibe las transacciones del maestro a través de la replicación. Por lo tanto, una réplica siempre tiene datos actuales y puede hacerse cargo (a través de un proceso llamado conmutación por error) en caso de que falle el maestro.

Una característica de la sincronización inicial se llama "evolución del esquema binario". En inglés simple, esto significa que el proceso de completar la base de datos de la réplica tendrá en cuenta las diferencias entre el esquema de la base de datos de la réplica y el esquema de la base de datos del maestro.

En la práctica, esto significa que puede construir una versión más nueva de su aplicación (con tablas nuevas / descartadas, campos nuevos / descartados / modificados, índices nuevos / descartados), adjuntar esa nueva versión de su aplicación a un maestro y luego provocar que la réplica más nueva para convertirse en el nuevo maestro (es decir, forzar una conmutación por error a la nueva réplica para que se convierta en el maestro y el viejo maestro se apague). Voila, ha migrado su aplicación de la versión N a N + 1, sin interrumpir la disponibilidad de su sistema. Ahora puede continuar con la actualización del antiguo maestro y cualquier otra réplica a la versión N + 1.