Rails: la mejor manera de realizar cambios en una base de datos de producción

Question

Necesito hacer cambios en una base de datos de producción en uso. Solo agrego algunas columnas. He realizado los cambios en la base de datos de desarrollo con migraciones. ¿Cuál es la mejor manera de actualizar la base de datos de producción mientras se preservan los datos existentes y no se interrumpe demasiado la operación?

Es MYSQL y necesitaré agregar datos a las columnas también para registros ya existentes. Una columna puede tener un valor predeterminado (es booleano) pero la otra es una indicación de fecha y hora y debe tener un valor arbitrario con retroceso. Los recuentos de filas no son enormes.

Entonces, si uso migraciones, ¿cómo agrego datos y cómo hago que solo haga las dos (o tres? Agrego migraciones más recientes de datos en la base de datos de producción cuando no se creó inicialmente a través de migraciones (creo usaron el esquema en su lugar)?

Answer 1

Parece que estás en un estado en el que el esquema de producción db no coincide exactamente con lo que estás usando en el desarrollo (aunque no está totalmente claro). Dibujaría una línea en la arena y conseguiría ese producto en mejor estado. Esencialmente, lo que desea hacer es asegurarse de que el prod db tenga un & Quot; schema_info & Quot; tabla que enumera las migraciones que usted > don't < Alguna vez has querido correr en producción. Luego puede agregar migraciones al contenido de su corazón y funcionarán contra la base de datos de producción.

Una vez que haya hecho eso, puede escribir migraciones que agreguen cambios de esquema o datos, pero una cosa de la que debe tener mucho cuidado es que si agrega datos mediante una migración, debe definir el modelo dentro de la migración misma. , así:

class AddSomeColumnsToUserTable < ActiveRecord::Migration
  class User < ActiveRecord::Base; end
  def self.up
    add_column :users, :super_cool, :boolean, :default => :false
    u = User.find_by_login('cameron')
    u.super_cool = true
    u.save
  end

  def self.down
    remove_column :users, :super_cool
  end
end

La razón de esto es que en el futuro, puede eliminar el modelo por completo, durante una refactorización u otra. Si no define la clase de usuario en la línea & Quot; User.find_by_login ... & Quot; la migración arrojará una excepción que es un gran dolor.

Answer 2

Siempre sigo este procedimiento:

• Volcar la base de datos de productos con el comando mysqldump
• Rellene la base de datos de desarrollo / prueba con volcado utilizando el comando mysql
• Ejecutar migraciones en dev / test
• Comprobar migración funcionó
• Volcar la base de datos prod con el comando mysqldump (ya que puede haber cambiado) manteniendo la copia de seguridad en el servidor
• Ejecutar migraciones en prod (usando capristano)
• La migración de prueba ha funcionado en prod
• Beber cerveza (mientras mira los registros de errores)

Answer 3

¿Hay alguna razón por la que no está utilizando las mismas migraciones que utilizó en su entorno de desarrollo?

Answer 4

Agregar una columna con add_column en una migración no debe ser destructivo: generará una & "; ALTER TABLE &"; declaración. Si sabe lo que va a poner en las columnas una vez creadas, puede completar los valores dentro de la migración (puede elegir una alternativa que requiera menos tiempo si el recuento de filas es grande).

La eliminación o alteración de la definición de una columna es, creo, dependiente de la plataforma: algunos permitirán la eliminación de una columna en su lugar, otros realizarán una secuencia de comandos renombrar-crear-seleccionar-soltar.

Para ser más específicos, necesitamos más información: ¿qué tipo de migración está mirando, en qué plataforma se está ejecutando? ¿Necesita establecer valores como parte de la migración? Cosas así ayudarían mucho: solo edite la pregunta, lo que la empujará a la lista.