2010-10-03 22 views
41

¿Existe alguna forma más rápida de transferir mi base de datos de producción a una aplicación de prueba?transferir db de una aplicación heroku a otra más rápido

Actualmente estoy haciendo un heroku db:pull en mi máquina local luego heroku db:push --app testapp pero esto lleva tiempo. Tengo algunos datos iniciales, pero no es tan preciso como simplemente probar con mis datos del mundo real. Y dado que ambos están almacenados en una nube vecina de AWS, debe haber una forma más rápida de mover los datos.

Pensé en usar un paquete heroku, pero noté que el comando animado se había ido?

bundles:animate <bundle>  # animate a bundle into a new app 
+0

Nota al margen: manojos Heroku y Bündler son conceptos distintos y no relacionados. – tfe

+0

ah sí, ni siquiera estaba pensando en esa posible confusión cuando lo escribí. – holden

Respuesta

0
psql -h test_host -c 'drop database test_db_name; create database test_db_name;' 

pg_dump -h production_host production_db_name | psql -h test_host test_db_name` 

Esto se puede hacer en production_host o en test_host — va a funcionar en ambos sentidos.

+0

Esto será muy lento a menos que las dos bases de datos y la máquina ejecuten 'pg_dump ... | psql ... 'están en la misma región EC2. – jelder

0

No lo he probado, pero podría funcionar.

hacen esto para obtener la URL de su base de datos fuente:

heroku console "ENV['DATABASE_URL']" --app mysourceapp 

A continuación, intente ejecutar db:push con eso.

heroku db:push database_url_from_before --app mytargetapp 

Esto podría no funcionar si Heroku no permite el acceso a las máquinas DB desde fuera de su red, que es probablemente el caso. Tal vez podrías intentar usar los grifos (gema que heroku db comandos usa internamente) desde el código de tu aplicación en algún lugar (tal vez una tarea de rake). Esto sería incluso más rápido que el enfoque anterior porque todo se mantiene completamente dentro de AWS.

Editar:

Aquí está una manera (la verdad hacky) para hacer lo que he descrito anteriormente:

Grab la URL base de datos como en el primer fragmento de código anterior. Luego, desde una tarea de rake (puede hacerlo en la consola pero corre el riesgo de alcanzar el límite de tiempo de espera de 30 segundos en los comandos de la consola), ejecute un comando de shell para tocar (no podría determinar fácilmente si es posible usar los grifos directamente desde Ruby; docs muestran el uso de la CLI):

`taps pull database_url_from_source_app #{ENV['DATABASE_URL']}` 

Los backticks son importantes; así es como Ruby denota un comando de shell, que toca. Esperemos que el comando de grifos sea accesible desde la aplicación. Esto evita el problema de acceder a la máquina de la base de datos desde fuera de Heroku, ya que está ejecutando este comando desde su aplicación.

+0

Taps ha quedado obsoleto desde hace mucho tiempo. – jelder

86

Es bastante común migrar bases de datos entre escenarios, pruebas y entornos de producción para aplicaciones Rails. Y heroku db:pull/push es dolorosamente lento. La mejor manera que he encontrado hasta ahora es usar Heroku PG Backups add-on y it's free. He seguido los pasos siguientes para migrar base de datos de producción para servidor de ensayo:

1) Crear la copia de seguridad de la base de datos de producción aplicación

heroku pg:backups capture --app production-app 

Esto generará el archivo de copia de seguridad B001 de la base de datos principal (db producción por lo general en base de datos.yml)

2) Para ver todos los respaldos (OPCIONAL)

heroku pg:backups --app production-app 

3) Ahora utilice el PG: copias de seguridad restaurar comando para poblar la organización de la base de datos del servidor desde el último archivo de respaldo en el servidor de producción

heroku pg:backups restore $(heroku pg:backups public-url --app production-app) DATABASE_URL --app staging-app 

Recuerde que la restauración es una operación destructiva, eliminará los datos existentes antes de reemplazarlos con el contenido del archivo de copia de seguridad.

+4

Nota rápida, este proceso no se cae y vuelve a crear el esquema. Esto significa que si tiene tablas adicionales en etapas, seguirán allí después de la restauración. Necesita hacer un db: schema: load (u otros comandos) para volver a crear el esquema si desea que las tablas desaparezcan. – Mainguy

+1

¡Entiendo! Copia de seguridad no encontrada al hacer esta operación. ¿Sabes cuál es el problema? – patrick

+0

@patrick Puede omitir DATABASE si su aplicación de ensayo solo tiene 1 base de datos. – ckbhodge

13

Así las cosas son incluso más fácil ahora .. pago y envío del comando de transferencia como parte de pgbackups

heroku pgbackups:transfer HEROKU_POSTGRESQL_PINK sushi-staging::HEROKU_POSTGRESQL_OLIVE -a sushi 

https://devcenter.heroku.com/articles/upgrading-heroku-postgres-databases#4b-alternative-transfer-data-between-applications

Esto ha funcionado muy bien para mí tomar el código de producción de nuevo a mi sitio de ensayo.

+3

Sí, pero esto destruirá el db original. Yo usaría pg: copy en su lugar – blushrt

+0

'pg: backups restore' destruye también el archivo original (ver [aquí] (https://devcenter.heroku.com/articles/heroku-postgres-backups#restoring-backups)):" A diferencia con los comandos pgbackups previos, no puede restaurar una copia de seguridad parcial en una base de datos existente. Cuando ejecuta pg: restores restore, todos los datos se eliminan de la base de datos de destino antes de restaurar la copia de seguridad. " – gabe

+0

@gabe 'pg: backups restore' NO destruye el DB original. La cita que mencionaste dice que eliminará todos los datos del * target * DB, no de la fuente. – jhirsch

0

Heroku le permite bifurcar aplicaciones existentes en producción. Utilice el tenedor heroku para copiar una aplicación existente, incluidos los complementos, las variables de configuración y los datos de Heroku Postgres.

Siga las instrucciones en Heroku: https://devcenter.heroku.com/articles/fork-app

+0

Esto casi no se puede usar en aplicaciones de cualquier escala significativa. Es costoso y toma mucho tiempo copiar sus (potencialmente muchas) bases de datos. – jelder

10

Actualización para mediados de 2015 ...

Los pgbackups complemento se considera obsoleta. No más pgbackups:transfer. pg:copy es ideal para este escenario.

Para copiar una base de datos de yourapp (ejemplo nombre db: HEROKU_POSTGRESQL_PINK_URL a yourapp_staging (ejemplo nombre db: HEROKU_POSTGRESQL_WHITE_URL)

# turn off the web dynos in staging 
heroku maintenance:on -a yourapp-staging 

# if you have non-web-dynos, do them too 
heroku ps:scale worker=0 -a yourapp-staging 

# backup the staging database if you are paranoid like me (optional) 
heroku pg:backups capture -a yourapp-staging 

# execute the copy to splat over the top of the staging database 
heroku pg:copy yourapp::HEROKU_POSTGRESQL_PINK_URL HEROKU_POSTGRESQL_WHITE_URL -a yourapp-staging 

Entonces cuando es completa, a su vez puesta en escena de nuevo en:

# this is if you have workers, change '1' to whatever 
heroku ps:scale worker=1 -a yourapp-staging 

heroku maintenance:off -a yourapp-staging 

Recordatorio: puede usar heroku pg:info -a yourapp-staging (y yourapp) para obtener las constantes de la base de datos.

(fuente: https://devcenter.heroku.com/articles/upgrading-heroku-postgres-databases#upgrade-with-pg-copy-default)

Cuestiones relacionadas