Cero tiempo de inactividad (o cerca de cero) Cambios en el esquema db

Question

Me preguntaba cómo y si las personas han trabajado con los cambios de esquema db que, de lo contrario, provocarían la caída de un sistema de producción. Parece que los cambios aditivos que están restringidos de alguna manera (por ejemplo, restricción única) serían difíciles de realizar a través de la aplicación y la base de datos debe cambiar al mismo tiempo; de lo contrario, se producirán errores en los datos o en la aplicación.

He pensado quizás en cambiar a un esclavo db (usando la replicación de mysql) y ejecutar los cambios de esquema en el maestro, pero luego tendría que capturar las consultas de actualización aplicadas al esclavo que no se aplicaban al maestro y correría el riesgo de no tener un servidor de respaldo.

¿Qué técnicas han utilizado las personas para solucionar estos problemas?

Gracias, Manish

Answer 1

yo diría que está cerca de la idea; efectivamente, tendría un maestro y esclavo, con el maestro siendo vivo, y el esclavo teniendo los cambios replicados en él; pause la replicación en el esclavo, y luego realice los cambios de esquema en el esclavo, y una vez que los cambios de esquema hayan finalizado, reanude la duplicación; una vez que se complete todo el proceso, detenga al maestro por un período de tiempo muy corto para asegurarse de que los cambios replicados se descarguen en el esclavo y luego cambie el maestro y el esclavo. Eso debería hacer lo que necesita.

Tenga en cuenta que esto solo funciona si los cambios que está realizando en el esquema no son tocados por los comandos de replicación pendientes; esto generalmente se hace mejor en tiempos de poco tráfico para asegurar que la colisión sea poco probable. Tenga en cuenta que debido a que esto no realiza cambios en el maestro hasta que el esclavo haya actualizado completamente el esquema y haya replicado los cambios, es muy seguro en el maestro.

Answer 2

Depende de cómo realice sus cambios de esquema, anteriormente intentaríamos asegurarnos de que los cambios de esquema implementados fueran retrocompatibles con la versión anterior de la aplicación. Esto funcionó bien para proyectos menores (y bastante importantes). También significaba que si teníamos un problema serio de rendimiento con la aplicación (perecer el pensamiento), entonces, deshacer el código era una tarea simple, en lugar de ardua.

Answer 3

La única manera real de evitar esto es tener una base de datos de clúster, o un maestro/esclavo como sugirió. Por lo general, desconecta un nodo y realiza las actualizaciones. Una vez que se ha logrado, normalmente ejecuta una sincronización desde el maestro actual hasta el sistema recientemente actualizado que comprende cómo traducir los datos del esquema anterior al nuevo. (Durante la sincronización, el maestro puede ponerse brevemente en modo de solo lectura.)

Luego, cambia las funciones maestro/esclavo y actualiza el otro esquema de base de datos. Sincronícelos de nuevo y vuelva a conectar el esclavo actualizado.

En la práctica, puede ser muy difícil hacerlo bien, especialmente si tiene cambios importantes en el esquema.