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

En general, los sitios web en los que he trabajado que tenían este tipo de requisito estaban todos detrás de los balanceadores de carga o tenían ubicaciones de conmutación por error separadas. En este ejemplo, presumiré que tiene un solo equilibrador de carga, 2 servidores web (A y B) y 2 servidores de base de datos (M & N: por lo general, los servidores de base de datos están vinculados a través de registro), al menos en el SQL Mundo del servidor).

1. El servidor web A se desconectará del equilibrador de carga (por lo tanto, todo el tráfico entrante va a B).
2. El envío de registros está detenido (el Servidor DB M se actualizará primero).
3. Actualice el servidor web A. Dirija la configuración al DB Server M.
4. Pruebe y verifique que la actualización haya funcionado (por lo general, la gente está recibiendo directamente la dirección IP).
5. Establezca el equilibrador de carga para que las sesiones existentes continúen yendo a B. Las nuevas sesiones van a A.
6. Espere a que todas las sesiones expiren en B (puede ser una media hora o más, por lo general observamos el tráfico y tenemos un descanso de 1 hora programado).
7. Actualiza B y N.
8. Pruebe y verifique que la actualización haya funcionado.
9. Configura el envío de registros nuevamente y prueba que funcione.
10. Establezca el equilibrador de carga en funcionamiento normal.

En una aplicación web muy complicada, lo que se describe como los pasos 1 a 5 podría durar toda la noche y ser una hoja de cálculo de Excel de 50 páginas con horarios y números de contacto de emergencia. En tales situaciones, la actualización de la mitad del sistema está programada para las 6 p. 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 ninguna interrupción, pueden aplicarse en el horario regular, que suele ser el fin de semana.

Para las bases de datos típicas (por ejemplo, Oracle) 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 tanto la versión anterior como la nueva del esquema
• no debería incurrir en tal carga en la base de datos que las transacciones se paralizarían (te estoy mirando CREATE INDEX )
• no debe incurrir en la pérdida de datos (no puede eliminar y volver a crear una tabla)

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

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

Consejo simple sobre planificación a futuro: siempre explícita los nombres de columna en sus solicitudes de base de datos (no use SELECT * FROM ). De esta manera, no tendrá nuevas columnas en las solicitudes antiguas.

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

Por ejemplo, uno de nuestros principales sistemas que ayudé a actualizar hace unos años debería estar disponible 24/7. Consistía en varios niveles, incluido un nivel de comunicación pura entre la capa de interfaz de usuario y la capa de negocio fuera del sitio. Debido a la forma en que se codificó la capa de comunicación, cualquier cambio futuro en la capa empresarial o el esquema de base de datos podría implementarse sin una interrupción real. En el peor de los casos, un usuario experimentará una pausa de 10 a 30 segundos a medida que los cambios surtan efecto.

Si los cambios fueran puramente cambios de código en la capa de negocios, se podrían poner en cola y "alternar" 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 sea la capa UI sin necesidad de reducir la interfaz de usuario.
• La capa empresarial manejada por la MVDB denominada UniData . Esto guarda todo el código en la memoria. Después de compilar el código, puede usar un comando para forzar el nuevo código de objeto en la memoria, reemplazando el antiguo.

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

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

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

Primero, entienda que "base de datos integrada" significa que el sistema de base de datos es una biblioteca compilada y enlazada con el código de su aplicación; en ese sentido, está "integrado" en su aplicación.

Con eXtremeDB High Availability, hay una instancia MASTER de su aplicación (que puede 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 failover) en caso de que falle el maestro.

Una característica de la sincronización inicial se llama "evolución del esquema binario". En un lenguaje sencillo, esto significa que el proceso de rellenar la base de datos de la réplica acomodará 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 crear una versión más nueva de su aplicación (con tablas nuevas / eliminadas, campos nuevos / eliminados / modificados, índices nuevos / eliminados), adjuntar esa nueva versión de su aplicación a un maestro, y luego haga que la nueva réplica se convierta en el nuevo maestro (es decir, fuerce una conmutación por error a la nueva réplica para que se convierta en el maestro y el antiguo 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 actualizar el maestro antiguo y cualquier otra réplica a la versión N + 1.