Cómo implementar cambios en la base de datos en un servidor en vivo?

Question

Tengo un script que es parte de mi proceso de implementación para enviar cambios de base de datos al servidor de producción. Si la secuencia de comandos corrompe mis datos por alguna razón (una mala actualización), es difícil de recuperar.

Una forma de resolver esto es cerrar la aplicación a los usuarios durante la actualización, por lo que si ocurre un problema, simplemente regrese a la copia de seguridad que hice antes de implementar.

Pero he oído de otros que implementan y mantienen su sitio en vivo ... ¿cómo harían esto, y si fallaron, cómo podrían recuperar los datos que ingresaron desde que tomó su copia de seguridad antes de implementar?

Answer 1

Esto es un problema difícil en general, como con muchas cosas en la administración de la base de datos. Básicamente hay tres formas de abordar esto:

1. Evite fallas a toda costa.
2. Bloquea todo (y realiza la actualización realmente rápido).
3. Está bien perder datos.

Si tiene un sistema complejo, aísle sus componentes según estas o categorías similares.

Dispones de un sistema de clasificación para probar las actualizaciones. El sistema de etapas es más o menos una copia del sistema de producción; está separado del sistema de prueba. Otra cosa es tener un sistema de auditoría o registro al que pueda consultar si necesita volver a reproducir los datos.

El problema real es si nota mucho más tarde que su actualización fue defectuosa. Entonces estás bastante jodido.

Answer 2

¿Qué tan grande es su base de datos? ¿Puede permitirse perder datos que se actualizaron mientras el cliente los estaba usando y antes de que tuviera que ir a la copia de seguridad? Cada plan de implementación implica algunos compromisos en alguna parte, y usted debe decidir qué compromisos son los menos dolorosos para lo que quiere hacer.

Para sitios web simples que solo ejecutan pgsql, puede desconectar clientes y ejecutar toda la actualización en una transacción grande. Si alguna parte falla, todo se revierte y es como si nunca hubieras hecho nada. Lamentablemente, esto no funciona exactamente igual para otros dbs, pero con flashback o lo que sea que Oracle lo llame, puede obtener algo similar.

Para sitios web más grandes y complejos que se ejecutan sobre un conjunto de servidores de bases de datos replicadas, las cosas se vuelven mucho más complejas mucho más rápidamente. Donde he trabajado, hemos utilizado Slony, y no se lleva bien jugar con otras personas cuando está implementando cambios de DDL, y prácticamente TIENE que desconectar a todos los clientes mientras se implementa DDL. Sin embargo, el tiempo de inactividad se mide en minutos para nosotros, incluso con bases de datos que se aproximan a 1TB de tamaño.