Umgebung: Ubuntu 11.10, MySQL 5.1.58
Ich habe eine kleine Datenbank mit Ansichten. Wenn ich versuche zu dumpen und wiederherzustellen, bekomme ich
%Vor%Ich kann jedoch eine Verbindung zur teilweise wiederhergestellten Datenbank herstellen und die Ansicht selbst erstellen. Daher vermute ich, dass die Fehlermeldung aus einem Problem resultiert, das nicht mit der Ansicht selbst zusammenhängt (sondern eher, wie sie vielleicht wiederhergestellt wird).
Hier ist der einfache Ansatz, mit dem ich das Problem demonstriere:
%Vor%Es gibt viele andere Online-Berichte über ähnliche Probleme. Die mysqldump-Manpage enthält eine kryptische Notiz über Fehler beim Sichern von Ansichten, aber sie ist eher als ein historisches Problem als ein aktuelles Problem beschrieben.
Die Frage ist also: Kann MySQL Backups, die Views enthalten oder nicht, zuverlässig wiederherstellen? Wenn es kann, wie? Wenn nicht, was machen die Leute als Workaround?
Danke, Reece
Ich habe das Problem in meinem Fall gefunden. Ich bin mir nicht sicher, ob es ähnliche Berichte im Web löst.
Dies war im Grunde ein Berechtigungsproblem, das sich aus dem Versuch ergab, diese Datenbank unter einem neuen Namen zu kopieren. Für diesen Benutzer und dieses Schema (Lokus auf Kuration2) waren keine Berechtigungen vorhanden. Ich habe manuell "GRANT ALL ON curation2. * TO locus" hinzugefügt (locus ist der Benutzer, der in dem Fehler gemeldet wurde). Nachdem dies getan wurde, funktionierte die obige Befehlszeile gut.
Die Lektion ist, dass man beim Erstellen einer neuen Datenbank die erforderlichen Berechtigungen für die Zieldatenbank und die Tabellen manuell erteilen muss.
Diese Frage ist ein bisschen alt, aber ich habe nur ein paar Stunden vergeudet, um das genau gleiche Problem zu lösen, also denke ich, dass eine klare Erklärung für jemanden in der Zukunft nützlich sein könnte ...
Um in die Chase zu schneiden: Das Problem liegt im DEFINER-Feld in Ihrem mysql-Dump. Es sieht ungefähr so aus:
%Vor%Das Problem ist, dass * some_user @ localhost * immer mit dem Benutzerkonto festgeschrieben ist, mit dem die Ansicht in der ursprünglichen DB erstellt wurde und NICHT der Benutzer, den Sie zum Exportieren verwendet haben oder importiere die Datenbank wie man es erwarten würde (oder zumindest ich). Und später, während des Imports, wird dieser Benutzer verwendet, um die Ansicht neu zu erstellen.
Sie können also als Root exportieren / importieren, aber wenn die ursprüngliche Datenbank unter einem anderen Benutzer ausgeführt wird und keine CREATE VIEW-Rechte in der neuen Datenbank hat, schlägt der Import fehl.
Sie haben zwei einfache Lösungen:
some_user @ localhost in Ihrer Speicherauszugsdatei mit Ihrem neuen Benutzer (den Sie zum Importieren des Speicherauszugs verwenden, z. B. root @ localhost) In jedem Fall wird das Problem behoben, aber ich denke, der erste Ansatz ist viel besser und sauberer, da Sie sich in Zukunft nicht um mehrere Benutzer kümmern müssen.
Was ich gefunden habe, um das Problem zu lösen, ist die Verwendung des 'sql security invoker' beim ersten Erstellen der Ansicht.
%Vor%Er definiert den Zugriff auf die Ansicht durch den Aufrufer und nicht den Definierer.
Wenn die Dump-Datei geladen ist, wird die Ansicht korrekt erstellt.
Mit Amazon RDS:
Damit dies mit Amazon RDS funktioniert, das keinen privilegierten Zugriff erlaubt (was für das obige Vorgehen erforderlich ist), kann dieser Befehl in der Dump-Datei ausgeführt werden:
%Vor%Wenn die Dump-Datei in ein RDS geladen wird, wird die Ansicht korrekt erstellt.
Ein paar Dinge:
1.) Ja, Sie können die Ansichten mit einem Client erstellen, ABER vielleicht ist der Eigentümer der Tabellen nicht der Eigentümer der Ansicht, was zu
führt2.) Das Erstellen von Backups von Views in mysql beinhaltet normalerweise "nutzlosen Müll" wie
%Vor%und dieser Benutzer enthält häufig den IP- oder Computernamen, mit dem sich der Benutzer beim Erstellen der Ansicht anmeldete ... SO wird die Ansicht nicht ordnungsgemäß erstellt. Überprüfen Sie das, könnte Ihnen helfen.
Tags und Links mysql mysqldump mysql-management