Wie erstelle ich mit mysqldump einen schreibgeschützten MySQL-Benutzer für Sicherungszwecke?

13

Ich verwende das automysqlbackupSkript, um meine MySQL-Datenbanken zu sichern, aber ich möchte einen schreibgeschützten Benutzer, der dies ausführt, damit ich mein Root-Datenbankkennwort nicht in einer Klartextdatei speichere.

Ich habe einen Benutzer wie folgt erstellt:

grant select, lock tables on *.* to 'username'@'localhost' identified by 'password';

Beim Ausführen mysqldump(entweder durch automysqlbackupoder direkt) erhalte ich die folgende Warnung:

mysqldump: Got error: 1044: Access denied for user 'username'@'localhost' to database 'information_schema' when using LOCK TABLES

Mache ich es falsch? Benötige ich zusätzliche Stipendien für meinen schreibgeschützten Benutzer? Oder kann man rootden information_schemaTisch nur abschließen ? Was ist los?

Bearbeiten:

GAH und jetzt funktioniert es. Ich habe FLUSH PRIVILEGES möglicherweise noch nicht ausgeführt.

Wie oft geschieht dies übrigens automatisch?

Bearbeiten:

Nein, das geht nicht. Das mysqldump -u username -p --all-databases > dump.sqlmanuelle Ausführen generiert keinen Fehler, gibt jedoch kein information_schema aus. automysqlbackuplöst einen Fehler aus.

— stickmangumby
quelle

Hoppla ... von der Manpage für mysqldump: mysqldump speichert die INFORMATION_SCHEMA-Datenbank nicht. Wenn Sie diese Datenbank explizit in der Befehlszeile benennen, ignoriert mysqldump sie unbemerkt. Es scheint, als sei die Manpage veraltet (und es wird eine Warnung ausgegeben), oder automysqlbackupes werden einige zusätzliche Überprüfungen des Speicherauszugs für durchgeführt information_schema. Nicht sicher, welches es ist, aber es hängt nicht mit Benutzerbewilligungen zusammen.

— Stickmangumby

1

Es ist kein GRANT-Problem. Sie müssen INFORMATION_SCHEMA nicht sichern (Siehe dev.mysql.com/doc/refman/5.0/en/information-schema.html )

— SmallClanger

1

Um SmallClanger zu ergänzen, ist INFORMATION_SCHEMA eine virtuelle Datenbank, die bei jedem Neustart von MySQL neu erstellt wird. Es macht also keinen Sinn, sie zu sichern, da Sie sie ohnehin nicht wiederherstellen können.

— John Gardeniers

4

Diese Berechtigungen sollten alles sein, was für den mysqldump benötigt wird.

Da Sie LOCK TABLES gewährt haben und es auf LOCK TABLES fehlerhaft ist, scheinen die Berechtigungen inkonsistent zu sein. Hast du einen laufen lassen FLUSH PRIVILEGES?

— Shane Madden
quelle

1

Ups ... von der Manpage für mysqldump:

mysqldump does not dump the INFORMATION_SCHEMA database. If you name that database explicitly on the command line, mysqldump silently ignores it

Scheint, als ob die Manpage veraltet ist (und eine Warnung auslöst) oder automysqlbackupzusätzliche Überprüfungen des Dumps für ausführt information_schema.

Nicht sicher, welches es ist, aber es hängt nicht mit Benutzerbewilligungen zusammen.

Bearbeiten

Ja, es ist ein Fehler in automysqlbackupVersion 2.5.1 (mit MySQL 5.1.41 unter Ubuntu 10.04) - es versucht zu sichern, information_schemawenn es nicht sollte.

UPDATE: Fügen Sie information_schemazu DBEXCLUDEZeile 76 des Skripts hinzu.

— stickmangumby
quelle

Es ist kein GRANT-Problem. Sie müssen INFORMATION_SCHEMA nicht sichern (Siehe dev.mysql.com/doc/refman/5.0/en/information-schema.html )

— SmallClanger

Um SmallClanger zu ergänzen, ist INFORMATION_SCHEMA eine virtuelle Datenbank, die bei jedem Neustart von MySQL neu erstellt wird. Es macht also keinen Sinn, sie zu sichern, da Sie sie ohnehin nicht wiederherstellen können.

— John Gardeniers