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

¿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?

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 )

1. El servidor web A se desconectará del equilibrador de carga (por lo que todo el tráfico entrante va a B).
2. El envío de registros se detiene (DB Server M se actualizará primero).
3. Actualizar el servidor web A. Apunte la configuración a DB Server M.
4. Pruebe y verifique que la actualización funcionó (por lo general, las personas están presionando la dirección IP directamente).
5. Configure el equilibrador de carga para que las sesiones existentes continúen yendo a B. Las nuevas sesiones van a A.
6. 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).
7. Actualización B y N.
8. Pruebe y verifique que la actualización funcionó.
9. Configure el envío de registros nuevamente y pruebe que funciona.
10. 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.

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.

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.

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.