MySQL può ripristinare in modo affidabile i backup che contengono viste o no?

Question

Ambiente: Ubuntu 11.10, MySQL 5.1.58

Ho un piccolo database con visualizzazioni. Quando provo a scaricare e ripristinare, ottengo

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 

tuttavia, posso connettersi al database parzialmente ripristinato e creare la vista io stesso. Pertanto, sospetto che il messaggio di errore sia il risultato di un problema non correlato alla vista stessa (ma piuttosto a come è stato ripristinato, forse).

Ecco l'approccio semplice che uso per dimostrare il problema:

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

Ci sono molti altri rapporti in linea di problemi simili. La pagina man mysqldump ha una nota criptica sui bug con le viste di backup, ma è scritta come un problema storico piuttosto che uno attuale.

Quindi, la domanda è: MySQL può ripristinare in modo affidabile i backup che contengono viste o no? Se può, come? In caso contrario, cosa fanno le persone come soluzione alternativa?

Grazie, Reece

Answer 1

Ho trovato il problema nel mio caso. Non sono sicuro che risolva report simili sul web.

Questo era fondamentalmente un problema di autorizzazione che risultava dal tentativo di copiare questo database in un nuovo nome. Le autorizzazioni non esistevano per questo utente e schema (locus on curation2). Ho aggiunto manualmente 'GRANT ALL ON on curation2. * TO locus' (il locus è l'utente segnalato nell'errore). Dopo aver fatto ciò, la linea di comando sopra funzionava bene.

La lezione è che è necessario concedere manualmente le autorizzazioni necessarie al database di destinazione e alle tabelle durante la creazione di un nuovo database.

Answer 2

paio di cose:

1.) Sì, è possibile creare le viste utilizzando qualche cliente, ma forse il proprietario delle tabelle non è il proprietario della vista, che porta a

2.) di solito, fare copie di backup dei viste in MySQL include alcuni "spazzatura inutile" come

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

e che l'utente spesso include l'IP o il nome della macchina che l'utente ha effettuato l'accesso durante la creazione della vista ... COSÌ, la vista non verrà creata correttamente. Dai un'occhiata, potrebbe aiutarti.

Answer 3

Questa domanda è un po 'vecchio, ma ho appena sprecato un paio di ore cercando di risolvere il problema esattamente lo stesso, quindi credo che una spiegazione chiara potrebbe rivelarsi utile a qualcuno in futuro ...

Per tagliare all'inseguimento: il problema è nel campo DEFINER nel tuo dump mysql. Sembra qualcosa di simile:

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

Il problema è che questo * some_user @ localhost * sarà sempre hardcoded per l'account utente che è stato utilizzato per creare la vista in originale DB e NON l'utente che si' Ho usato per esportare o importare il database come ci si aspetterebbe (o almeno lo feci). E più tardi, durante l'importazione, questo utente verrà utilizzato per ricreare la vista.

Quindi è possibile esportare/importare come root, ma se il DB originale è in esecuzione con un altro utente e non ha diritti CREATE VIEW nel nuovo database, l'importazione avrà esito negativo.

si hanno due soluzioni semplici:

1. cercare e sostituire tutti i riferimenti a some_user @localhost nel file dump con il nuovo utente (quello che si usa per importare la discarica, ad esempio root @ localhost)
2. Oppure si può concedere * some_user * diritti sul nuovo database in modo che le opinioni possono essere creati sotto il suo conto

in entrambi i casi sarà risolvere il problema, ma penso che il primo approccio è il modo migliore e più pulita, come y Non devi preoccuparti di più utenti in futuro.

Answer 4

Quello che ho trovato per risolvere il problema è utilizzare il "sql security invoker" quando si crea inizialmente la vista.

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

Definisce l'accesso alla vista dall'invocatore e non dal definitore.

Quindi, quando viene caricato il file di dettagli, la vista viene creata correttamente.

Con Amazon RDS:

per fare questo lavoro con Amazon RDS, che non consente Super priv (che è necessario per fare quanto sopra) si può eseguire questo comando per il file dump:

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

Quindi, quando il file di dump viene caricato in un RDS, la vista viene creata correttamente.