¿Puede MySQL restaurar de manera confiable las copias de seguridad que contienen vistas o no?

Question

Entorno: Ubuntu 11.10, MySQL 5.1.58

Tengo una pequeña base de datos con vistas. Cuando trato de volcar y restaurar, recibo

ERROR 1356 (HY000) at line 1693: View 'curation2.condition_reference_qrm_v' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them 

Sin embargo, puede conectarse a la base de datos parcialmente restaurado y crear la vista de mí mismo. Por lo tanto, sospecho que el mensaje de error es el resultado de un problema que no está relacionado con la vista en sí (sino cómo se restaura, quizás).

Aquí está el enfoque simple que utilizo para demostrar el problema:

MYSQL_PWD='xxx' mysqldump -u root --routines -B curation \ 
| perl -pe 's/`curation`/`curation2`/' \ 
| MYSQL_PWD='xxx' mysql -u root 

Hay muchos otros informes en línea de problemas similares. La página man de mysqldump tiene una nota críptica sobre errores con vistas de respaldo, pero está escrito como un problema histórico en lugar de uno actual.

Entonces, la pregunta es: ¿MySQL puede restaurar de manera confiable las copias de seguridad que contienen vistas o no? Si puede, ¿cómo? Si no, ¿qué hace la gente como solución alternativa?

Gracias, Reece

Answer 1

Encontré el problema en mi caso. No estoy seguro de que resuelva informes similares en la web.

Esto fue fundamentalmente un problema de permiso que resultó de intentar copiar esta base de datos a un nuevo nombre. Los permisos no existían para este usuario y esquema (locus en curation2). Agregué manualmente 'GRANT ALL ON curation2. * TO locus' (locus es el usuario informado en el error). Después de hacer esto, la línea de comando anterior funcionó bien.

La lección es que uno debe otorgar manualmente los permisos necesarios a la base de datos y las tablas de destino cuando se crea una nueva base de datos.

Answer 2

par de cosas:

1.) Sí, puede crear las vistas utilizando algún cliente, pero tal vez el propietario de las tablas no es el propietario de la vista, lo que conduce a

2.) Por lo general, hacer copias de seguridad de vistas en MySQL incluye un poco de "basura inútil" como

create algorithm xxx definer=<USER> sql security view <view_name> as .... 

y que incluye a menudo el usuario el nombre de la IP o la máquina con la que el usuario inició sesión al crear la vista ... ASÍ, la vista no se creará correctamente. Compruébalo, podría ayudarte.

Answer 3

Esta pregunta es un poco viejo, pero me acaba de perder un par de horas tratando de resolver el problema exactamente el mismo, así que supongo una clara explicación podría ser útil a alguien en el futuro ...

Para ir al grano: el problema está en el campo DEFINER en tu volcado mysql. Se ve algo como:

/*!50013 DEFINER=`some_user`@`localhost` SQL SECURITY DEFINER */ 

El problema es que este * some_user @ localhost * siempre será codificada para la cuenta de usuario que se utilizó para crear la vista en el original DB y NO el usuario que' he usado para exportar o importar la base de datos como uno esperaría (o al menos yo lo hice). Y luego, durante la importación, este usuario se usará para volver a crear la vista.

Para exportar/importar como root, pero si el DB original se ejecuta bajo otro usuario y no tiene derechos CREATE VIEW en la nueva base de datos, la importación fallará.

usted tiene dos soluciones simples:

1. buscar y reemplazar todas las referencias a some_user @localhost en su archivo de volcado con su nuevo usuario (el que se utiliza para importar el volcado, por ejemplo root @ localhost)
2. O puede conceder * some_user * derechos correspondientes en la nueva base de datos para que las opiniones pueden ser creados bajo su cuenta

de cualquier manera se solucionará el problema, pero creo que el primer enfoque es mucho mejor y más limpia, como y No tiene que preocuparse por usuarios múltiples en el futuro.

Answer 4

Lo que encontré para resolver el problema es utilizar el 'invocador de seguridad sql' al crear la vista inicialmente.

create or replace sql security invoker view <VIEW_NAME> as select ... 

Define el acceso a la vista por el invocador, y no por el definidor.

Luego, cuando se carga el archivo de volcado, la vista se crea correctamente.

Con Amazon RDS:

para hacer este trabajo con Amazon RDS, que no permite súper priv (que se necesita para hacer lo anterior) se puede ejecutar este comando para el archivo de volcado:

# Remove DEFINER statement from VIEWS in Dump file 
sed -i 's/\sDEFINER=`[^`]*`@`[^`]*`//' $DUMPFILE_NAME 

Luego, cuando el archivo de volcado se carga en un RDS, la vista se crea correctamente.