Cero tiempo de inactividad con Hibernate

Question

¿Qué cambios en una base de datos (MySQL en este caso) sobrevive Hibernate (datos, esquema, ...)?

Pido esto porque no hay tiempo de inactividad con Hibernate.

Cambie la base de datos, divida los servidores de aplicaciones en dos grupos, vuelva a implementar la aplicación en uno de los grupos y cambie la aplicación.

Gracias Stephan

Answer 1

Responderé a esto desde la experiencia personal y no desde una perspectiva especial de hibernación. Así que toma esto con un grano de sal. También parece un poco vaga la pregunta, agregue comentarios donde sea apropiado. :)

En primer lugar, cambiar / agregar / eliminar elementos al esquema que no está asignado en hibernación nunca causará ningún problema. Todo lo que Hibernate realmente hace es generar consultas, ya que traduce muchas cosas a SQL, su aplicación simplemente continuará funcionando mientras esas consultas sigan funcionando. Esto significa que agregar columnas a una tabla o agregar tablas no es un problema, eliminar columnas que no haya asignado no es un problema, etc., etc.

Lo que es más problemático son los cambios en las cosas que se asignan. Supongamos que cambia un número (10,0) a un número (11,0), esto generalmente funcionará. Si comienza a hacer cosas como cambiar un campo CHAR (1) a un campo BIT o algo similar, necesitará ciertos cambios en sus asignaciones de hibernación, que harán que una implementación existente falle. Esto es el sentido común. Si tiene que hacer cambios como este, la ejecución de ALTER TABLE en un servidor de base de datos normal probablemente bloqueará la tabla de todos modos, por lo que reiniciar la aplicación no es su mayor problema.

Tratar con los principales cambios de esquema bajo alta disponibilidad no es algo que hibernación deba tratar directamente. Hibernate asume una base de datos relacional tradicional donde los cambios de esquema suelen ser muy costosos.

Los otros tres problemas que mencionas:

• cambio de fuentes de datos: probablemente requiera reiniciar la aplicación
• división del servidor de aplicaciones: si te refieres a lo que creo que quieres decir, simplemente puedes implementar en diferentes servidores de aplicaciones. Si los cambios son requeridos, use algo entre su aplicación web y el cliente para manejarlos, es decir, un equilibrador de carga a nivel de IP o similar.
• cambio de datos: se aplican los problemas normales con bases de datos transaccionales y múltiples escritores. Hibernate podría terminar con una vista inconsistente de la base de datos. Puede sobrescribir los cambios realizados por otros usuarios y, en algunos casos, esto puede generar algunas excepciones, pero debería ser posible anticiparse y actuar en situaciones como estas AFAICT.