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


Ich benutze die automysqlbackup Skript, um meine mysql-Datenbanken auszugeben, aber ich möchte einen schreibgeschützten Benutzer haben, damit ich mein Passwort für die Root-Datenbank nicht in einer Klartextdatei speichern kann.

Ich habe einen Benutzer wie folgt erstellt:

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

Wenn ich renne mysqldump (entweder durch automysqlbackup oder direkt) bekomme ich folgende Warnung:

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

Mache ich es falsch? Brauche ich zusätzliche Zuschüsse für meinen Readonly-Benutzer? Oder kann nur root Schließ das information_schema Tabelle? Was ist los?

Bearbeiten:

GAH und jetzt funktioniert es. Ich habe FLUSH PRIVILEGES vorher vielleicht nicht ausgeführt.

Nebenbei, wie oft geschieht das automatisch?

Bearbeiten:

Nein, es funktioniert nicht. Laufen mysqldump -u username -p --all-databases > dump.sql manuell erzeugt keinen Fehler, aber dump information_schema nicht. automysqlbackup verursacht einen Fehler.


12
2018-03-07 05:59


Ursprung


Hoppla ... von der Manpage für mysqldump: mysqldump gibt die Datenbank INFORMATION_SCHEMA nicht aus. Wenn Sie diese Datenbank explizit in der Befehlszeile benennen, ignoriert mysqldump diese implizit. Scheint, dass entweder die man-Seite veraltet ist (und es eine Warnung auslöst), oder automysqlbackup führt einige zusätzliche Überprüfungen für den Dump durch information_schema. Nicht sicher, was es ist, aber es ist nicht mit Benutzerzuschüssen verbunden. - stickmangumby
Es ist kein GRANT-Problem. Sie müssen INFORMATION_SCHEMA nicht sichern (siehe: dev.mysql.com/doc/refman/5.0/de/information-schema.html) - SmallClanger
Um dem hinzuzufügen, was SmallClanger gesagt hat, ist die INFORMATION_SCHEMA eine virtuelle Datenbank, die bei jedem Neustart von MySQL neu erstellt wird. Es macht also keinen Sinn, sie zu sichern, da sie nicht wiederhergestellt werden kann. - John Gardeniers


Antworten:


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

Da Sie LOCK TABLES erteilt haben und es bei LOCK TABLES fehlerhaft ist, scheinen die Berechtigungen inkonsistent zu sein. Hast du einen Lauf gemacht? FLUSH PRIVILEGES?


4
2018-03-07 06:08





Hoppla ... 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 so, als ob entweder die man-Seite veraltet ist (und es eine Warnung auslöst), oder automysqlbackup führt einige zusätzliche Überprüfungen für den Dump durch information_schema.

Nicht sicher, was es ist, aber es ist nicht mit Benutzerzuschüssen verbunden.

Bearbeiten

Ja, es ist ein Fehler in automysqlbackup Version 2.5.1 (mit MySQL 5.1.41 unter Ubuntu 10.04) - versucht es zu sichern information_schema wenn es nicht sollte.

FIX: Hinzufügen information_schema zu DBEXCLUDE in Zeile 76 des Skripts.


1
2018-03-07 07:32



Es ist kein GRANT-Problem. Sie müssen INFORMATION_SCHEMA nicht sichern (siehe: dev.mysql.com/doc/refman/5.0/de/information-schema.html) - SmallClanger
Um dem hinzuzufügen, was SmallClanger gesagt hat, ist die INFORMATION_SCHEMA eine virtuelle Datenbank, die bei jedem Neustart von MySQL neu erstellt wird. Es macht also keinen Sinn, sie zu sichern, da sie nicht wiederhergestellt werden kann. - John Gardeniers