Cómo aplicar parches de DB en PROD?

nV8x #1 Nov '23

He buscado un poco y preguntado también a chatgpt pero no encuentro nada satisfactorio. Asi que pregunto por aquí.

La cuestión es que me gustaría saber cuál es la manera que tienen las grandes compañías de software a la hora de aplicar parches de migración a sus bases de datos de forma segura? Hay algún artículo que hable de ello? Cuál ha sido vuestra experiencia?

Nosotros (developers), hicimos un SQL procedure para una migración de datos, y sugerimos que ese otro equipo de mantenimiento se encargasen de decidir y planear una estrategia sólida para aplicar dicha migración de forma segura y controlada. Como adivinaréis, no tienen ni puta idea y con el cliente acordaron aplicarlo en vivo mientras la aplicación sigue operando. Es una migración que ya se ha testeado en otros entornos y estimamos que llevaría alrededor de un mes en completarse.

El procedure fue diseñado para ser re-ejecutado multiples veces para poder procesar el delta (datos insertados a posteriori desde la ejecución inicial de la mgiración), por lo que un simple backup no nos sirve aquí.

Nosotros les sugerimos que aplicaran la migración a una DB espejo (un clon en vivo), sin impactar a la DB original, y que al finalizar hicieran un switch. Y aunque sí tienen esa DB espejo, según ellos no sería posible, porque Oracle no se lo permite blabla... Dicen que los cambios se reflejarían en las 2 DB al mismo tiempo.

aren-pulid0 #2 Nov '23

Tener una bbdd réplica y ejecutar Flyway u otro gestor de migraciones

1 respuesta

nV8x #3 Nov '23

#2 entonces según tú, ésto

Y aunque sí tienen esa DB espejo, según ellos no sería posible, porque Oracle no se lo permite blabla... Dicen que los cambios se reflejarían en las 2 DB al mismo tiempo.

también crees que es un farol?

sasher #4 Nov '23

Te la están colando. De todas formas, me parece que estás exagerando un poco el proceso. No sé que tipo de migraciones estáis aplicando, normalmente con que la gestión la haga el ORM y bloquee con un lock la base de datos mientras se aplica la migración tenéis de sobra.

Para migraciones más complejas que necesiten tratamiento de datos especial o lo que sea → modo mantenimiento de la app y se lanza mediante un proceso independiente desde tu backend. No creo que necesitéis un uptime del copón.

1 respuesta

Wei-Yu #5 Nov '23

si tienes cientos de millones de updates me pensaría lo de la réplica, si no batcheando y usando staging tables vas sobrado (y con cientos de millones de updates dependiendo de tu throughput, cardinalidades y relaciones probablemente con esa combinación vayas sobradísimo también a poco que tengas una db bien dimensionada para vuestro uso), pero ahí hay que barajar cómo de crítica es la migración para el negocio o si puede tomarse como algo asíncrono

lo normal es no bloquear o parar nada porque tengas que migrar, las migraciones se hacen al vuelo siempre... hay casos muy concretos que no hay forma de evitarlo y ahí o tienes mucha escala o tragas con tener una ventana de mantenimiento breve (minimizando lo que obliga a tener esa ventana todo lo posible)

locks en la db nunca y mucho menos table locks porque eso efectivamente es ventana de mantenimiento para el servicio/componente/subcomponente que requiera esos datos

sobre sistemas para migrar, flyway como comentaron ya y otras herramientas parecidas (muchas veces si el ORM es potentillo te sobra)

1 respuesta

nV8x #6 Nov '23

#4sasher:

me parece que estás exagerando un poco el proceso.

#4sasher:
No creo que necesitéis un uptime del copón.

vale bro xD

#5

La migración ya está en marcha. Llevamos 1 semana habiendo procesado 7 años de datos. Faltan otros 9 años, siendo los últimos con más registros. Para que te hagas una idea de la escala. Hasta el momento solo hubo problemas con un job ETL externo que consumía de la base de datos que se había quedado stuck que no habíamos previsto, y ya les dijimos que lo suspendan. Por lo demás, va bien.

Lo que igualmente no me parece aceptable que se apliquen migraciones directamente al BD de producción, porque pasa cualquier cosa y se va casi todo al garete. Voy a intentar sonsacarles cuales son los motivos por lo que no se puede aplicar cambios a una DB replica, porque en el futuro tendremos más migraciones. Lo que sí me gustaría es pasarles un articulo o algo donde se explique que ésto sea factible y estandard.

2 respuestas

RaymaN #7 Nov '23 Sureño

#6 hombre, al garete se irá la migración, es complicado que te deje la DB en un estado inservible, pero aún así, evidentemente, debéis tener backups diarios u horarios si vuestro producto es crítico xD

Lo que mejor me ha funcionado a mí es la migración por partes, adaptando la app antes o después de la migración según el caso. Si tienes que cambiar una columna y es compleja, es mejor crear una columna nueva y luego actualizar la app para usarla, y pasado un tiempo quitas la vieja. Lo mismo para tablas completas.

Wei-Yu #8 Nov '23

#6 ah vale que es más data engineering que el lifecycle normal de los datos y la app... de todas formas también te diría que en la medida de lo posible los procesos de ETL deberían ser idempotentes para que no puedas reventar nada si hay algún fallo (claro que esto se dice más fácil de lo que se hace)

tener réplicas es algo viable y razonable sí, no se la docu de oracle cómo lo reflejará pero si buscas por replication, master/slave read-write replicas y cosas así deberías encontrar cosas

si se ponen pesados yo intentaría escalarlo y dejar claros los riesgos, pero es algo que se tendría que haber hecho antes durante el planning tbh, al final los plannings son para identificar cosas así

1

pantocreitor #9 Nov '23

A ver, si hay que hacer una migración hay que hacerla y punto. Con tantos datos es un puto coñazo pero los datos antiguos los podéis hacer poco a poco y cuando lleguen los datos recientes que pueden estar siendo usados pues mantenimiento, lock o lo que elijáis para hacerlo.

Lo de la base de datos espejo me suena más a replicacion que a entorno de prueba, pero si debería haber una base de datos de prueba (preproduccion o similar) para poder ejecutar todas las pruebas necesarias previas a la ejecución en producción.

GaN2 #10 Nov '23 Inocente

Estas mezclando parcheo con migracion cuando son dos tareas completamente diferentes, incluso podemos meternos en temas de upgrade que son ligeramente diferentes a parcheos. Si es migracion pura ( mover de A a B ) sin subida de version en Oracle puedes hacer una replica en standby con log shipping y el dia de la migracion basicamente cortas la replicacion, levantas la standby que se convierte en primaria y redireccionas tu aplicacion a la nueva primaria. Casi todos las BBDD tienen algo similar con replicacion entre primario/secundario.

Sobre migracion + upgrade, es un pelin mas complicado y basicamente depende de la tecnologia de base de datos que uses. En SAP HANA se que puedes crear una replica de primaria a standby, hacer upgrade en la standby, aplicar los cambios que se han producido en la primera a la standby mientras se hacia el upgrade y finalmente hacer el switchover de primaria a standby activando la standby/rompiendo replicadion y redireccionando el trafico de la aplicacion a la nueva primaria. En Oracle tres cuartos de lo mismo porque hasta hace dos dias nuestros DBAs seguian un procedimiento similar con el Exadata que administraban.

Que migracion estais haciendo exactamente? Mover la BBDD de un servidor a otro? Mover y hacer upgrade? Migrar datos de una BBDD a otra en tecnologias diferentes? Leyendote no me queda muy claro y veo que hablas de un SQL procedure para migracion de datos lo cual me da entender de que se puede tratar de una migracion entre BBDD de tecnologia diferente (MS SQL Server a Oracle por ejemplo).

1 1 respuesta

nV8x #11 Nov '23

#10 sí perdon, tienes razón.

El proceso es cambiar el particionado para poder hacer queries más eficientemente:

Cambiar la partición de la tabla principal del esquema -> creando una tabla nueva vacía con el nuevo tipo de partición, e importando los datos (con impdp) de la tabla "vieja". Ésto es lo que dio algunos problemas al principio pero ya se completó.
En las tablas satelites, añadir una columna nueva y rellenarla -> SQL Procedure que va por periodos. Se puede reanudar en caso de problemas y está pensado para re-ejecutarse para procesar los deltas (Registros nuevos que se van insertando de mientras).
Añadir índice y particionado a esas tablas satelites usando la columna nueva -> se hace online, en las tablas mismas

(downtime)

Hacer el switch de tablas del paso 1 y deployar nueva versión de la aplicación

2 1 respuesta

JuAn4k4 #12 Nov '23

Facebook Saco su herramienta como open source

https://github.com/facebook/mysql-5.6/wiki/Schema-Changes

1

GaN2 #13 Nov '23 Inocente

#11 vale aclarado, es básicamente mover datos de tabla no particionada a tabla particionada y añadir columna nueva.

En Oracle nunca lo he hecho pero en otras bases de datos puedes particionada una tabla sin tener que recrearla/migrarla a una nueva creada como particionada. En cualquier caso creo que el plan que has puesto tiene su lógica y se aproxima a la realidad, lo único que le dará es en el downtime añadir un tiempo X para terminar de hacer la replicacion de los datos de la tabla antigua a la nueva porque si no se puede dar el caso de que la tabla este en uso constantemente y no llegues a replicarla completamente. Los índices se pueden crear online pero creo recordar que dependiendo del tamaño del índice podría dar problemas y poner la tabla en una especie de lock, en cualquier caso se pueden crear al comienzo antes de replicar datos y luego hacer un rebuild durante el downtime.

Sobre lo que preguntabas sobre hacer la migración en una DB espejo, creo recordar que en Oracle no puedes tener réplicas vivas en activo sin que lo que hagas en la secundaria impacte en la primaria así que te va a dar igual. El único problema que podrías tener durante el movimiento de los datos a la nueva tabla es que impactarás en el rendimiento de las lecturas/escrituras de la tabla original mientras dure la migración. A nivel de consistencia del dato tengo algunas dudas como por ejemplo cómo replicáis los cambios que se hayan producido en una entrada que se haya migrado a la nueva tabla.

Cómo aplicar parches de DB en PROD?

Usuarios habituales

Tags