Alterar tabla en bases de datos de producción en vivo

¿Cómo maneja la mayoría de los sistemas de bases de datos "populares" (MySQL, Postgres ...) la alteración de tablas en bases de datos de producción en vivo (como agregar, eliminar o cambiar el tipo de columnas)?

Sé que la forma correcta es hacer una copia de seguridad de todo el tiempo de inactividad programado y luego hacer los cambios.

Pero ... ¿algún sistema de base de datos actual admite hacer estas cosas "en línea" sin detener nada? (tal vez solo retrase las consultas que hacen referencia a una columna que se está modificando / eliminando)

¿Y qué sucede cuando solo hago una ALTER TABLE...en una base de datos en vivo? ¿Todo se detiene cuando esto sucede? ¿Se pueden corromper los datos? etc.

Nuevamente, me refiero principalmente a Postgres o MySQL, ya que estos son los que encuentro.

(Y sí, cada vez que tenía que hacer esto antes de hacerlo "de la manera correcta", respaldando cosas, programando una baja, etc. ... pero solo quiero saber si es posible hacer este tipo y cosas "rápido y sucio "o si hay algún sistema de base de datos que realmente admita cambios de esquema" rápidos, en vivo y sucios ")

Alguien acaba de sugerir el Cambio de esquema en línea para MySQL desde el script de Facebook (con un tutorial aquí y una fuente aquí ) ... parece una buena manera de automatizar un conjunto de formas "hacky" para hacerlo ... ¿alguien lo ha usado alguna vez en algo parecido a la produccion?

Cuando emite un ALTER TABLEarchivo en PostgreSQL , se ACCESS EXCLUSIVEbloqueará todo lo que incluye todoSELECT . Sin embargo, este bloqueo puede ser bastante breve si la tabla no requiere reescritura, no es nueva UNIQUE, CHECKo si las FOREIGN KEYrestricciones necesitan escaneos caros de tabla completa para verificar, etc.

En caso de duda, generalmente puede probarlo. Todo DDL en PostgreSQL es transaccional, por lo que está muy bien cancelar un mensaje ALTER TABLEsi tarda demasiado y comienza a retener otras consultas. Los niveles de bloqueo requeridos por varios comandos están documentados en la página de bloqueo .

Algunas operaciones normalmente lentas se pueden acelerar para que sean seguras de realizar sin tiempo de inactividad. Por ejemplo, si tiene una tabla ty desea cambiar la columna customercode integer NOT NULLa textporque el cliente ha decidido que todos los códigos de cliente ahora deben comenzar con un X, puede escribir:

ALTER TABLE t ALTER COLUMN customercode TYPE text USING ( 'X'||customercode::text );

... pero eso bloquearía toda la tabla para la reescritura. Entonces, agregar una columna con a DEFAULT. Se puede hacer en un par de pasos para evitar el bloqueo prolongado, pero las aplicaciones deben poder hacer frente a la duplicación temporal:

ALTER TABLE t ADD COLUMN customercode_new text;
BEGIN;
LOCK TABLE t IN EXCLUSIVE MODE;
UPDATE t SET customercode_new = 'X'||customercode::text;
ALTER TABLE t DROP COLUMN customercode;
ALTER TABLE t RENAME COLUMN customercode_new TO customercode;
COMMIT;

Esto sólo evitará que las escrituras a tdurante el proceso; el nombre de la cerradura EXCLUSIVEes algo engañoso porque excluye todo exceptoSELECT ; el ACCESS EXCLUSIVEmodo es el único que excluye absolutamente todo. Ver modos de bloqueo . Existe el riesgo de que esta operación pueda anular el bloqueo debido a la actualización de bloqueo requerida por el ALTER TABLE, pero en el peor de los casos, solo tendrá que volver a hacerlo.

Incluso se puede evitar que la cerradura y hacer todo esto en vivo mediante la creación de una función de disparo en tque cada vez que una INSERTo UPDATEentra, rellena automáticamente customercode_newdesde customercode.

También hay herramientas integradas como CREATE INDEX CONCURRENTLYy que están ALTER TABLE ... ADD table_constraint_using_indexdiseñadas para permitir que los DBA reduzcan las duraciones de bloqueo exclusivas haciendo un trabajo más lento de una manera amigable con la concurrencia.

La pg_reorgherramienta o su sucesor también pg_repackse pueden utilizar para algunas operaciones de reestructuración de tablas.

Percona tiene su propia herramienta para realizar cambios de esquema en línea

La herramienta se llama pt-online-schema-change

Implica desencadenantes, así que lea la documentación detenidamente.

Según la documentación, las principales operaciones realizadas son

• Controles de cordura
• Fragmentado
• Cambio de esquema en línea
  • Crear y modificar una tabla temporal
  • Capture los cambios de la tabla a la tabla temporal.
  • Copiar filas de la tabla a la tabla temporal
  • Sincronice la tabla y la tabla temporal.
  • Cambiar / renombrar la tabla y la tabla temporal
  • Limpiar

Apagar el sistema y hacer todos los cambios a la vez puede ser muy arriesgado. Si algo sale mal, y con frecuencia sucede, no hay un camino fácil de regreso.

Como desarrollador ágil, a veces necesito refactorizar tablas sin ningún tiempo de inactividad, ya que esas tablas se están modificando y leyendo.

El siguiente enfoque tiene bajo riesgo, porque el cambio se realiza en varios pasos de bajo riesgo que son muy fáciles de revertir:

• Asegúrese de que todos los módulos que acceden a la tabla estén bien cubiertos con pruebas automatizadas.
• Crea una nueva tabla. Modifique todos los procedimientos que modifican la tabla anterior, de modo que modifiquen las tablas antiguas y nuevas.
• Migre los datos existentes a una nueva estructura. Hágalo en lotes pequeños, para que no afecte seriamente el rendimiento general del servidor.
• Verifique que la migración de datos haya sido exitosa.
• Redireccione algunos de los procedimientos de selección de la tabla anterior a los nuevos. Utilice pruebas automatizadas para asegurarse de que los módulos modificados siguen siendo correctos. Asegúrese de que su desempeño sea aceptable. Implemente los procedimientos alterados.
• Repita el paso anterior hasta que todos los informes usen la nueva tabla.
• Cambie los procedimientos que modifican las tablas, para que solo accedan a la nueva tabla.
• Archive la tabla anterior y elimínela del sistema.

Hemos utilizado este enfoque muchas veces para cambiar grandes tablas de producción en vivo sin tiempo de inactividad, sin ningún problema.

Sí, muchas bases de datos modernas le permitirán simplemente agregar una columna o cambiar las características de una columna, como agregar o quitar valores anulables.

Si suelta una columna, se perderán datos, pero no hay mucho miedo a la corrupción.

La herramienta Percona usa disparadores para ayudar a alterarla, y no funciona bien si su mesa ya tiene disparadores existentes. Terminé teniendo que escribir uno que realmente maneje bien los desencadenantes existentes, ya que son súper importantes para nuestra base de datos https://github.com/StirlingMarketingGroup/smg-live-alter

Para abordar la pregunta sobre qué sucede con una ALTER TABLEdeclaración, depende de la extensión de sus cambios. En casos específicos, si agrega una nueva columna, al menos en MS SQL Server, el motor creará una copia temporal de la tabla, mientras crea la nueva definición de la tabla, y luego inserta los datos allí. Mientras dure el cambio, la tabla sería inaccesible para los usuarios.

Un ejemplo de las operaciones específicas para el servidor MSSQL está aquí: http://support.microsoft.com/kb/956176/en-us

Supongo que otros RMDB tienen métodos similares, aunque la implementación exacta sería algo que tendría que verificar con la documentación del proveedor.