2011-03-19 32 views
6

Tengo un db postgresql con más de 85 tablas. Realizo copias de seguridad regularmente usando pg_dump (a través de php-pgadmin) en modo copia y el tamaño del archivo de copia de seguridad es de casi 10-12 MB. Ahora el problema al que me enfrento es que cada vez que trato de restaurar la base de datos, se produce un problema de restricción de clave externa. El escenario es el siguiente:Restaurar PostgreSQL db desde la copia de seguridad sin problema de restricción de clave foránea

Hay dos tablas: 1) users y 2) zones. He almacenado la identificación de la zona en la tabla users para identificar la zona del usuario y establecerla como clave externa.

Cuando tomo el volcado de base de datos, las entradas de la tabla zones aparecen solo después de la tabla users. Creo que es debido a la primera letra del nombre de la tabla: u viene antes de z, y por lo tanto, cuando restauro la base de datos, ocurre un problema de restricción de clave externa y la ejecución se detiene. El mismo problema ocurre cuando trato de restaurar la estructura db, dice que la tabla zones no existe en la base de datos ya que la estructura de zones viene después de users en el archivo de volcado.

¿Hay alguna solución para esto? ¿Hay algún otro método de respaldo factible?

+0

En realidad envío el volcado que obtuve de phppgadmin como sql a través de la propia interfaz de phppgadmin ..... –

Respuesta

6

Suena como que está recibiendo un volcado SQL en lugar de una copia binaria de pg_dump. Eso le daría una gran pila de SQL con el esquema (incluidos los FK) en la parte superior seguido de un grupo de INSERT para volver a cargar los datos. Un volcado binario de pg_dump te serviría mejor, parece que necesitas un poco de configuración adicional para decirle a PhpPgAdmin dónde está pg_dump. Entonces será que alimenta volcado binario en pg_restorepg_restore y que reconstruir todo en el orden correcto para evitar problemas de integridad referencial (o, más exactamente, pg_restore sería restaurar todos los datos a continuación, añadir las restricciones).

PhpPgAdmin seems to want to work with plain SQL dumps en lugar de pg_restore. Encuentro esto difícil de creer pero no puedo encontrar nada en la documentación sobre la invocación de pg_restore. Si esto es cierto, probablemente tendrá que editar a mano el volcado de SQL y mover todos los FK al final.

También podría intentar agregar SET CONSTRAINTS ALL DEFERRED; en la parte superior de su volcado SQL, que debe retrasar la comprobación de restricciones hasta el final de la transacción, también querrá asegurarse de que todo el bloque de insertos está contenida dentro de una transacción.

Si PhpPgAdmin realmente no puede invocar pg_restore, entonces es mejor usar usando pg_dumppg_restore y con la mano para que tenga el control necesario sobre sus procedimientos de reserva. Lo siento, pero cualquier herramienta de administración de bases de datos que no puede manejar la copia de seguridad de una base de datos con FK es peor que inútil. Esperemos que alguien que conoce bien PhpPgAdmin aparezca y nos deje saber cómo usar pg_restore con PhpPgAdmin.

+0

Sí, pg_restore era lo que quería ... Ahora la migración de datos funciona bien pero ahora hay un problema nuevo ... cuando importo la estructura de db, y el usuario pg_restore para restaurarlo a una nueva base de datos, error como "la secuencia X ya existe" "aparece ... encontré que el problema es que el tipo de datos de los campos de auto-incremento son bigserial en el volcado de db, por lo que postgres crea automáticamente una secuencia basada en el nombre de la columna ... pero debajo de la declaración de crear tabla el volcado tiene una creación enunciado de secuencia que crea una secuencia con el mismo nombre que el auto generado por postgres y esto arroja un error ... ¿alguna solución? –

+1

@Midhun: Debería restaurar en una base de datos vacía, luego 'pg_restore' configurará todo. O bien, si ya tiene el esquema en su lugar pero no tiene datos, puede decir 'pg_restore' para restaurar los datos. Parece que el esquema ya está allí y tu restauración también intenta restaurar el esquema. –

1

usando pgdump (a través de php-pgadmin)

¿Seguro PhpPgAdmin está utilizando pg_dump para crear copias de seguridad? Nunca he visto ningún vuelco hecho por pg_dump, teniendo problemas con claves externas al restaurar el volcado.

PhpPgAdmin es sólo un script PHP y en la mayoría de los casos, no tendrá permisos para iniciar un programa como pg_dump.

+0

creía que PhpPgAdmin utiliza pgdump para hacer copias de seguridad ... ¿estoy equivocado? [link] http://en.wikipedia.org/wiki/PhpPgAdmin [link] dice que puede usar pg_dump ... pero no estoy seguro si la interfaz usa pg_dump cuando se realiza el dumping ... ¿Alguien puede confirmarlo? –

0

Eliminaría la creación fk en el frente y la agregaría al final del script.

3

Si ayuda a alguien: ninguna de las soluciones anteriores sugeridas funcionó para mí (hubo algunos INSERT realizados haciendo referencia a los datos que se volcaron más tarde, independientemente si estaba en formato binario, o consultas SQL simples).

Lo que hice: utilicé schemaspy, un script que, entre otras características, como un diagrama html realmente útil del modelo ER subyacente, genera dos listas muy útiles: un "orden de inserción" (donde todas sus las tablas se enumeran como un orden óptimo para realizar inserciones, teniendo en cuenta las restricciones y dependencias existentes), y una "orden de eliminación" (muy útil para las tablas DROP).

Si desea una muestra, consulte este http://schemaspy.sourceforge.net/sample/. En particular, hay dos listas de muestra que mencioné anteriormente (intenté publicar enlaces directos, pero el mecanismo de prevención de spam me permite publicar solo 2 enlaces).

+0

estas son las listas de muestras! http://schemaspy.sourceforge.net/sample/insertionOrder.txt http://schemaspy.sourceforge.net/sample/deletionOrder.txt – jquinter

Cuestiones relacionadas