DBAtlas · Atlas de operaciones de bases de datos

Asistente de actualización de versión

¿Parche o versión mayor, en el sitio o mediante migración? Planifique la actualización paso a paso; cada rama cubre las comprobaciones previas, el método y el trabajo posterior a la actualización. Ensáyela aquí antes de tocar producción.

¿Qué tipo de actualización está haciendo?

Una versión de parche/menor (dentro de la misma versión mayor, p. ej., 16.2 -> 16.4, o un CU de SQL Server) es de bajo riesgo y suele hacerse in situ. Una versión mayor (p. ej., 15 -> 16) puede implicar cambios en el formato de los datos y requiere una planificación más cuidadosa.

SELECT * FROM v$version;
SELECT patch_id, action, status FROM dba_registry_sqlpatch ORDER BY action_time DESC;
  • Versión menor / parche (misma versión mayor, CU)
  • Versión mayor (cambia la versión mayor)
  • No conozco la diferencia; explíquela

¿Parche o versión mayor?

Parche: la versión mayor no cambia (16.2 -> 16.4); el formato de los datafiles no cambia, normalmente se cambian los binarios + reinicio. Mayor: cambia la versión mayor (15 -> 16); el catálogo/formato puede cambiar, se requiere pg_upgrade / AutoUpgrade / dump-restore y hay que probar la compatibilidad de la aplicación.

  • El mío es un parche (misma versión mayor)
  • El mío es una versión mayor (cambia la versión mayor)

¿Están listos el backup y el plan de vuelta atrás?

Aunque un parche es de bajo riesgo, la regla de oro de toda actualización es: primero un backup completo (y un snapshot si es posible). Necesita un punto al que volver si algo sale mal.

  • Sí, backup + vuelta atrás están listos
  • No, todavía no

Primero backup + plan de vuelta atrás

Prepare la red de seguridad antes de empezar la actualización.

Aplicar el parche

Un parche dentro de la misma versión mayor. Aplicarlo de forma rolling en un clúster (empezando por las réplicas) reduce el tiempo de inactividad.

Método de actualización mayor

Dos caminos principales: (1) In situ: convertir en el servidor existente (pg_upgrade, Oracle AutoUpgrade/DBUA, MySQL in-place). Rápido pero difícil de revertir. (2) Mediante migración: montar un servidor nuevo con la nueva versión, mover los datos (con dump/restore o replicación) y luego hacer el corte. Más seguro, con un tiempo de inactividad mínimo.

  • Quiero hacer primero una comprobación de preparación/compatibilidad
  • In situ
  • Migrando a un servidor nuevo (tiempo de inactividad mínimo)

Comprobación de compatibilidad / preparación

Antes de actualizar, recopile los avisos de la versión de destino: funcionalidades eliminadas (obsoletas), objetos no válidos, nivel de compatibilidad.

-- AutoUpgrade analyze mode: java -jar autoupgrade.jar -config cfg -mode analyze
  • Salida limpia, continuar
  • Hay avisos/incompatibilidades

Corrija primero los avisos

Resuelva todos los avisos del informe ANTES de actualizar; de lo contrario la actualización puede fallar a mitad o la aplicación puede romperse.

Actualización de versión mayor in situ

Convertir en el servidor existente. Rápido, pero la vuelta atrás suele implicar restaurar desde backup, así que un snapshot es imprescindible.

Actualización mediante migración (tiempo de inactividad mínimo)

Monte un servidor nuevo con la nueva versión, mueva los datos y luego cambie con un corte breve. El método más seguro; el sistema antiguo queda intacto.

Abrir en DBAtlas →