Implementación de tiempo de inactividad cero - Esquema transicional Db

13

Lograr la implementación de cero tiempos de inactividad tocó el mismo problema pero necesito algunos consejos sobre Una estrategia que estoy considerando.

Contexto

Una aplicación basada en web con Apache / PHP para el procesamiento del lado del servidor y MySQL DB / sistema de archivos para la persistencia.

Actualmente estamos construyendo la infraestructura. Todo el hardware de red tendrá redundancia y todos los cables de red principales se utilizarán en pares unidos para la tolerancia a fallos. Los servidores se configuran como pares de alta disponibilidad para la tolerancia a fallos del hardware y se equilibrarán la carga tanto para la tolerancia a fallos de la máquina virtual como para el rendimiento general.

Mi intención es que podamos aplicar actualizaciones a la aplicación sin ningún tiempo de inactividad. Me esforcé mucho al diseñar la infraestructura para garantizar que puedo proporcionar el 100% del tiempo de actividad; sería extremadamente decepcionante tener un tiempo de inactividad de 10 a 15 minutos cada vez que se aplicara una actualización. Esto es particularmente importante ya que tenemos la intención de tener un ciclo de lanzamiento muy rápido (a veces puede llegar a uno o más lanzamientos por día.

Topología de red

Este es un resumen de la red:

                      Load Balancer
             |----------------------------|
              /       /         \       \  
             /       /           \       \ 
 | Web Server |  DB Server | Web Server |  DB Server |
 |-------------------------|-------------------------|
 |   Host-1   |   Host-2   |   Host-1   |   Host-2   |
 |-------------------------|-------------------------|
            Node A        \ /        Node B
              |            /            |
              |           / \           |
   |---------------------|   |---------------------|
           Switch 1                  Switch 2

   And onward to VRRP enabled routers and the internet

Nota: los servidores de bases de datos utilizan la replicación maestro-maestro

Estrategia sugerida

Para lograr esto, actualmente estoy pensando en dividir los scripts de actualización de esquema DB en dos partes. La actualización se vería así:

  1. El servidor web en el nodo A se toma fuera de línea; el tráfico continúa siendo procesado por el servidor web en el nodo B.
  2. Los cambios del esquema de transición se aplican a los servidores de base de datos
  3. Servidor web Se actualiza una base de código, se borran las cachés y se realizan otras acciones de actualización.
  4. El servidor web A se pone en línea y el servidor web B se desconecta.
  5. La base del código del servidor web B se actualiza, las cachés se borran y se realizan otras acciones de actualización.
  6. El servidor web B se pone en línea.
  7. Los cambios del esquema final se aplican a DB

'Esquema de transición' se diseñaría para establecer una base de datos compatible con varias versiones. En su mayoría, se utilizarían vistas de tabla que simulan el esquema de la versión anterior, mientras que la tabla misma se modificará al nuevo esquema. Esto permite que la versión anterior interactúe con la base de datos de manera normal. Los nombres de las tablas incluirían números de versión de esquema para garantizar que no haya confusión sobre en qué tabla escribir.

'Esquema final' eliminaría la compatibilidad con versiones anteriores y ordenaría el esquema.

Pregunta

En resumen, ¿funcionará esto?

más específicamente:

  1. ¿Habrá problemas debido al potencial de escrituras concurrentes en el punto específico del cambio del esquema de transición? ¿Hay alguna forma de asegurarse de que el grupo de consultas que modifican la tabla y crean la vista compatible con versiones anteriores se ejecutan de forma consecutiva? es decir, con cualquier otra consulta que se mantenga en el búfer hasta que se completen los cambios del esquema, que generalmente solo será de milisegundos.

  2. ¿Existen métodos más simples que proporcionen este grado de estabilidad y también permitan actualizaciones sin tiempo de inactividad? También es preferible evitar la estrategia de esquema "evolutivo", ya que no deseo quedar atrapado en la compatibilidad de esquemas hacia atrás.

pregunta Marvin 27.01.2016 - 17:14

2 respuestas

4

Parece que lo que realmente estás buscando no es tanto de alta disponibilidad como lo que necesitarías Disponibilidad continua .

Esencialmente, su plan funcionará, pero parece que se ha dado cuenta de que la falla principal en su configuración es que los cambios en el esquema de la base de datos en una versión podrían ocasionar un tiempo de inactividad o la falla de un nodo aún disponible para funcionar correctamente. El enfoque de disponibilidad continua resuelve esto al crear esencialmente una serie de entornos de producción.

Producción uno

Este entorno es su versión actual en vivo del software que utilizan los usuarios. Tiene sus propios servidores web, servidores de aplicaciones, servidores de bases de datos y espacios de tabla. Funciona independientemente de cualquier otro entorno. El Load Balancer que posee el punto final de resolución de dominio para estos servicios apunta actualmente a estos servidores web.

Producción dos

Este es básicamente un entorno de prueba de lanzamiento que es idéntico a Production One. Puede realizar las actualizaciones de su versión aquí y realizar las pruebas de cordura antes de su evento en vivo. Esto también le permite realizar con seguridad los cambios de su base de datos en este entorno. El equilibrador de carga no apunta a este entorno actualmente.

DR de producción

Este es otro duplicado en un centro de datos separado que se encuentra en una región diferente del mundo. Esto le permite conmutar por error en caso de un evento catastrófico al hacer un cambio de DNS en el equilibrador de carga.

Go Live

Este evento es esencialmente la actualización del registro DNS para pasar a la Producción Dos desde la Producción Uno o viceversa. Esto toma un tiempo para propagarse a través de los servidores DNS del mundo, por lo que deja ambos entornos funcionando por un tiempo. Algunos usuarios PUEDEN estar trabajando en sesiones existentes en la versión anterior de su software. La mayoría de los usuarios establecerán nuevas sesiones en la versión actualizada de su software.

Migración de datos

El único inconveniente aquí es que no todos los datos durante esa ventana están disponibles para todos los usuarios en ese momento. Hay datos de usuario claramente importantes en la base de datos de la versión anterior que ahora deben migrarse de manera segura al nuevo esquema de base de datos. Esto se puede lograr con un script de exportación de datos y migración bien probado, un trabajo por lotes o un proceso ETL similar.

Conclusión

Una vez que haya completado completamente su evento de lanzamiento, Production Two es ahora su principal y usted comienza a trabajar en la instalación del próximo lanzamiento en Production One para el próximo ciclo de implementación.

Inconvenientes

Esta es una configuración de entorno compleja y requiere una gran cantidad de recursos del sistema, a menudo dos o tres veces los recursos del sistema para hacerlo con éxito. Operar de esta manera puede ser costoso, especialmente si tiene sistemas de uso intensivo muy grandes.

    
respondido por el maple_shaft 27.01.2016 - 19:47
2

Tu estrategia es sólida. Solo ofrecería considerar la posibilidad de expandir el "Esquema de transición" en un conjunto completo de "tablas de transacciones".

Con las tablas de transacciones, los SELECT (consultas) se realizan contra las tablas normalizadas para asegurar la corrección. Pero todas las inserciones de la base de datos, las ACTUALIZACIONES y las BORRADAS siempre se escriben en las tablas de transacciones desnormalizadas.

Luego, un proceso simultáneo y separado aplica esos cambios (tal vez utilizando procedimientos almacenados) a las tablas normalizadas según las reglas comerciales y los requisitos de esquema establecidos.

La mayoría de las veces, esto sería prácticamente instantáneo. Pero separar las acciones permite que el sistema acomode una actividad excesiva y retrasos en la actualización del esquema.

Durante los cambios de esquema en la base de datos (B), las actualizaciones de datos en la base de datos activa (A) entrarán en sus tablas de transacciones y se aplicarán de inmediato a sus tablas normalizadas.

En la copia de seguridad de la base de datos (B), las transacciones de (A) se le aplicarían escribiéndolas en las tablas de transacciones de (B). Una vez que se hace esa parte, (A) se puede bajar y los cambios de esquema se aplican allí. (B) terminaría de aplicar las transacciones de (A), mientras que también manejaría sus transacciones en vivo que se pondrían en cola al igual que (A) y las "transacciones en vivo" se aplicarían de la misma manera cuando (A) volviera a activarse.

Una fila de la tabla de transacciones podría verse algo así como ...

| ROWID | TRANSNR | DB | TABLE | SQL STATEMENT
    0        0       A    Name   INSERT INTO Name ...
    1        0       A    Addr   INSERT INTO Addr ...
    2        0       A    Phone  INSERT INTO Phone ...
    3        1       A    Stats   UPDATE Stats SET NrOfUsers=...

Las "tablas" de transacciones podrían ser filas en una base de datos NoSQL separada o incluso archivos secuenciales, según los requisitos de rendimiento. Una ventaja adicional es que la codificación de la aplicación (sitio web en este caso) se simplifica un poco, ya que solo se escribe en las tablas de transacciones.

La idea sigue los mismos principios que la contabilidad de doble entrada, y por razones similares.

Las tablas de transacciones son análogas a un "diario" de contabilidad. Las tablas completamente normalizadas son análogas a un "libro mayor" de contabilidad, y cada tabla es algo así como una "cuenta" de contabilidad.

En la contabilidad, cada transacción obtiene dos entradas en el diario. Uno para la cuenta contable "debitada", y el otro para la cuenta "acreditada".

En un RDBMS, un "diario" (tabla de transacciones) obtiene una entrada para que cada tabla normalizada sea alterada por esa transacción.

La columna DB en la ilustración de la tabla anterior indica en qué base de datos se originó la transacción, lo que permite que las filas en cola de la otra base de datos se filtren y no se vuelvan a aplicar cuando la segunda base de datos vuelva a aparecer.

    
respondido por el DocSalvager 29.01.2016 - 10:59

Lea otras preguntas en las etiquetas