What are the minimum privilege required for a mysql db user to use the mysqldump file and restore.
Cannot use root db user in my case.
Have taken full backup of all schemas in a dump file using mysqldump utility.
Need to know minimum required privileges to be given to a db user(other than root db user) so that it can be used to do restore from mysqldump file.
It is not possible to restore a complete, unmodified dump file to a MySQL Server without the SUPER privilege.
The "root" user is not a magical user. It just happens to be a user that is created by default and has GRANT ALL PRIVILEGES ON *.* ... WITH GRANT OPTION. Another user can be given the same privileges.
Restoring a database essentially means obliterating everything on a server and replacing it with something else, including all the user accounts so SUPER is required.
More limited privileges can be used if certain modifications to the dump file are made, such as removing all DEFINER statements, and modifying the way the mysql schema is handled, but those modifications are an advanced topic with system-specific considerations.
I've started with SUPER, INSERT, & ALTER and tried repeatedly adding new ones until the restore finished successfully.
This is what I've ended up with:
SUPER
ALTER
INSERT
CREATE
DROP
LOCK TABLES
REFERENCES
SELECT
If you have routines and triggers then you'll need these two additionally:
CREATE ROUTINE
TRIGGER
Hope this helps.
From the Mysql official site:
mysqldump requires at least the SELECT privilege for dumped tables,
SHOW VIEW for dumped views, TRIGGER for dumped triggers, and LOCK
TABLES if the --single-transaction option is not used. Certain options
might require other privileges as noted in the option descriptions.
--single-transaction
This option sets the transaction isolation mode to REPEATABLE READ and
sends a START TRANSACTION SQL statement to the server before dumping
data. It is useful only with transactional tables such as InnoDB,
because then it dumps the consistent state of the database at the time
when START TRANSACTION was issued without blocking any applications.
In conclusion, privileges are:
select (required)
lock tables (required)
show views and trigger (optional)
Related
What's the difference between
mysqldump database > dump.sql
mysqldump -u user -p database > dump_with_user.sql
?
They both exported sql, so what's the interest to specify the user and the password ? Will there be a difference when import ?
My guess is that you are connected as root user and your server is unsecurely configured (that is, with no password given for the root user).
The implicit user used by the mysqldump utility will be the user used by the underlying shell (in my guess, root)
Since no password has been given and you are able to dump the database without providing neither the user nor the password, I conclude the mysql account has no password associated.
User and password arguments to mysqldump are mysql's ones : the user must have priviledges associated to at least view the schema and select the data.
From the reference manual :
mysqldump requires at least the SELECT privilege for dumped tables, SHOW VIEW for dumped views, TRIGGER for dumped triggers, and LOCK TABLES if the --single-transaction option is not used. Certain options might require other privileges as noted in the option descriptions.
So, even in your situation you didn't need to provide neither user nor password, using real-life (!) databases you will have to specify them.
I'm using the mysqlcheck command for an automated script. I want to give, the user running the script, the minimum permissions required to be able to successfully run the command with the --all-databases and --repair arguments.
A quick excerpt from the documentation page of mysqlcheck:
mysqlcheck uses the SQL statements CHECK TABLE, REPAIR TABLE, ANALYZE TABLE, and OPTIMIZE TABLE in a convenient way for the user.
The documentation page of CHECK TABLE specifies:
To check a table, you must have some privilege for it.
The documentation pages of REPAIR TABLE, ANALYZE TABLE, and OPTIMIZE TABLE specify:
This statement requires SELECT and INSERT privileges for the table.
I think the conclusion is obvious: grant the user only the SELECT and INSERT global privileges to be able to successfully run mysqlcheck --repair --all-databases.
I have an application that stores its data in an MySQL database. The application is using a specific DB account with full access, the indivdual user rights are maintained on application level. Apart from root there is no other user with access to that database.
In order to install the application on a computer I need an sql script that creates the database, the application user, all tables without data, views, triggers, stored procedures, etc.
mysqldump --no-data --routines --add-drop-database --databases dbname > sqlfile will do almost all these things but I could not find any option to include the creation of the user having access to that database. Any hints?
The reason that mysqldump doesn't dump user information is because that is stored in a different database name mysql rather than in the database for your applicaation.
You cannot add this information manually to the generated sql dump either. You have two options. Create a shell script or create a separate sql file that contains user creation information. In either case your file will include statements like
GRANT ALL ON appdb.* TO 'pb_skat'#'localhost';
http://dev.mysql.com/doc/refman/5.7/en/grant.html
Before introducing the application dump to your database.
First list down the users which all are available with you:
SELECT User, Host, Password FROM mysql.user;
Check if that user has permissions using "show grants" command to perform the operation, else provide the permissions to do so.
GRANT ALL PRIVILEGES ON . TO 'root'#'localhost' WITH GRANT OPTION
Create the database name where you want to introduce the dump.
I have a PHP script that calls MySQL's LOAD DATA INFILE to load data from CSV files. However, on production server, I ended up with the following error:
Access denied for user ... (using password: yes)
As a quick workaround, I changed the command to LOAD DATA LOCAL INFILE which worked. However, the same command failed on client's server with this message:
The used command is not allowed with this MySQL version
I assume this has something to do with the server variable: local_infile = off as described here.
Please suggest a workaround that does not involve changing server settings. Note that phpMyAdmin utility installed on the same server appears to accept CSV files though I am not sure it it uses LOAD DATA (LOCAL) INFILE.
Ran into the same issue as root and threw me for a moment
could be an issue with your server settings set with compile
to test login to console with the same user and try your load data command
if you get the same error, try closing console and running
mysql -u USER -p --local-infile=1 DATABASE
now try running load data command again
if it works then you're going to need to restart mysqld with command line option or re-install with configuration option
references (references are for 5.0 but worked for me with 5.5):
http://dev.mysql.com/doc/refman/5.0/en/load-data-local.html
http://dev.mysql.com/doc/refman/5.0/en/mysql-command-options.html#option_mysql_local-infile
I found that I need to connect to database like this:
$dbh=mysql_connect($server,$dbuser,$dbpass,false,128);
Passing 128 in the flags parameter is the key.
See http://www.php.net/manual/en/mysql.constants.php#mysql.client-flags to read more about the flags.
take a look to this permission list, you can add them separately, IE. you can insert but not update, or you can delete but not select, etc...
ALL [PRIVILEGES] Grant all privileges at specified access level except GRANT OPTION
ALTER Enable use of ALTER TABLE
ALTER ROUTINE Enable stored routines to be altered or dropped
CREATE Enable database and table creation
CREATE ROUTINE Enable stored routine creation
CREATE TEMPORARY TABLES Enable use of CREATE TEMPORARY TABLE
CREATE USER Enable use of CREATE USER, DROP USER, RENAME USER, and REVOKE ALL PRIVILEGES
CREATE VIEW Enable views to be created or altered
DELETE Enable use of DELETE
DROP Enable databases, tables, and views to be dropped
EVENT Enable use of events for the Event Scheduler
EXECUTE Enable the user to execute stored routines
FILE Enable the user to cause the server to read or write files
GRANT OPTION Enable privileges to be granted to or removed from other accounts
INDEX Enable indexes to be created or dropped
INSERT Enable use of INSERT
LOCK TABLES Enable use of LOCK TABLES on tables for which you have the SELECT privilege
PROCESS Enable the user to see all processes with SHOW PROCESSLIST
REFERENCES Not implemented
RELOAD Enable use of FLUSH operations
REPLICATION CLIENT Enable the user to ask where master or slave servers are
REPLICATION SLAVE Enable replication slaves to read binary log events from the master
SELECT Enable use of SELECT
SHOW DATABASES Enable SHOW DATABASES to show all databases
SHOW VIEW Enable use of SHOW CREATE VIEW
SHUTDOWN Enable use of mysqladmin shutdown
SUPER Enable use of other administrative operations such as CHANGE MASTER TO, KILL, PURGE BINARY LOGS, SET GLOBAL, and mysqladmin debug command
TRIGGER Enable trigger operations
UPDATE Enable use of UPDATE
USAGE Synonym for “no privileges”
I think you have permision to select, delete, insert, update, but no to do other stuff,
use this command:
SHOW GRANTS
he will show you what you are able to to, in my case.
jcho360> show grants;
+-------------------------------------------------------+
| Grants for jbolivar#localhost |
+-------------------------------------------------------+
| GRANT ALL PRIVILEGES ON *.* TO 'jbolivar'#'localhost' |
+-------------------------------------------------------+
1 row in set (0.00 sec)
I'm new to MySQL and I'm figuring out the best way to perform an on-line hot logical backup using mysqldump. This page suggests this command line:
mysqldump --single-transaction --flush-logs --master-data=2
--all-databases > backup_sunday_1_PM.sql
but... if you read the documentation carefully you find that:
While a --single-transaction dump is in process, to ensure a valid dump file
(correct table contents and binary log position), no other connection should use
the following statements: ALTER TABLE, DROP TABLE, RENAME TABLE, TRUNCATE TABLE. A
consistent read is not isolated from those statements, so use of them on a table to
be dumped can cause the SELECT performed by mysqldump to retrieve the table contents
to obtain incorrect contents or fail.
So, is there any way to prevent this possible dump corruption scenario?
I.e. a commands that could block those statements temporarily.
PS: MySQL bug entry on this subject http://bugs.mysql.com/bug.php?id=27850
Open a mysql command window and issue this command:
mysql> FLUSH TABLES WITH READ LOCK;
This will lock all tables in all databases on this MySQL instance until you issue UNLOCK TABLES (or terminate the client connection that holds these read locks).
To confirm this, you can open another command window and try to do an ALTER, DROP, RENAME or TRUNCATE. These commands hang, waiting for the read lock to be released. Hit Ctrl-C to terminate the waiting.
But while the tables have a read lock, you can still perform a mysqldump backup.
The FLUSH TABLES WITH READ LOCK command may be the same as using the --lock-all-tables option of mysqldump. It's not totally clear, but this doc seems to support it:
Another use for UNLOCK TABLES is to
release the global read lock acquired
with FLUSH TABLES WITH READ LOCK.
Both FLUSH TABLES WITH READ LOCK and --lock-all-tables use the phrase "global read lock," so I think it's likely that these do the same thing. Therefore, you should be able to use that option to mysqldump and protect against concurrent ALTER, DROP, RENAME, and TRUNCATE.
Re. your comment: The following is from Guilhem Bichot in the MySQL bug log that you linked to:
Hi. --lock-all-tables calls FLUSH
TABLES WITH READ LOCK. Thus it is
expected to block ALTER, DROP, RENAME,
or TRUNCATE (unless there is a bug or
I'm wrong). However, --lock-all-tables
--single-transaction cannot work (mysqldump throws an error message):
because lock-all-tables locks all
tables of the server against writes
for the duration of the backup,
whereas single-transaction is intended
to let writes happen during the backup
(by using a consistent-read SELECT in
a transaction), they are incompatible
in nature.
From this, it sounds like you cannot get concurrent access during a backup, and simultaneously block ALTER, DROP, RENAME and TRUNCATE.
I thought the same thing reading that part of the documentation though, I found more information:
4.5.4. mysqldump — A Database Backup Program
http://dev.mysql.com/doc/en/mysqldump.html
For InnoDB tables, mysqldump provides a way of making an online
backup:
shell> mysqldump --all-databases --single-transaction > all_databases.sql
This backup acquires a global read lock on all tables (using FLUSH
TABLES WITH READ LOCK) at the beginning of the dump. As soon as this
lock has been acquired, the binary log coordinates are read and the
lock is released. If long updating statements are running when the
FLUSH statement is issued, the MySQL server may get stalled until
those statements finish. After that, the dump becomes lock free and
does not disturb reads and writes on the tables. If the update
statements that the MySQL server receives are short (in terms of
execution time), the initial lock period should not be noticeable,
even with many updates.
There is a conflict with the --opt and --single-transaction options:
--opt
This option is shorthand. It is the same as specifying
--add-drop-table --add-locks --create-options --disable-keys --extended-insert --lock-tables --quick --set-charset. It should give you a fast dump operation and produce a dump file that can be reloaded
into a MySQL server quickly.
The --opt option is enabled by default. Use --skip-opt to disable it.
If I understand your question correctly you want the actual data and the DDL (Data Definition Language) together, because if you only want the DDL you would use --no-data. More information about this can be found at:
http://dev.mysql.com/doc/workbench/en/wb-reverse-engineer-create-script.html
Use the --databases option with mysqldump if you wish to create the
database as well as all its objects. If there is no CREATE DATABASE
db_name statement in your script file, you must import the database
objects into an existing schema or, if there is no schema, a new
unnamed schema is created.
As suggested by The Definitive Guide to MySQL 5 By Michael Kofler I would suggest the follow options:
--skip-opt
--single-transaction
--add-drop-table
--create-options
--quick
--extended-insert
--set-charset
--disable-keys
Additionally, not mentioned is --order-by-primary
Also if you are using the --databases option, you should also use --add-drop-database especially if combined with this answer If you are backing up databases that are connect on different networks you may need to use the --compress option.
So a mysqldump command (without using the --compress, --databases, or --add-drop-database options) would be :
mysqldump --skip-opt --order-by-primary --single-transaction --add-drop-table --create-options --quick --extended-insert --set-charset -h db_host -u username --password="myPassword" db_name | mysql --host=other_host db_name
I removed the reference to --disable-keys that was given in the book as it is not effective with InnoDB as i understand it. The MySql manual states:
For each table, surround the INSERT statements with /*!40000 ALTER
TABLE tbl_name DISABLE KEYS /; and /!40000 ALTER TABLE tbl_name
ENABLE KEYS */; statements. This makes loading the dump file faster
because the indexes are created after all rows are inserted. This
option is effective only for nonunique indexes of MyISAM tables.
I also found this bug report http://bugs.mysql.com/bug.php?id=64309 which has comments on the bottom from Paul DuBois who also wrote a few books to which I have no reference on this specific issue other than those comments found within that bug report.
Now to create the "Ultimate Backup" I would suggest to consider something along the lines of this shell script
https://github.com/red-ant/mysql-svn-backup/blob/master/mysql-svn.sh
You can't get a consistent dump without locking tables. I just do mine during a time of day that the 2 minutes it takes to do the dump isn't noticed.
One solution is to do replication, then back up the slave instead of the master. If the slave misses writes during the backup, it will just catch up later. This will also leave you with a live backup server in case the master fails. Which is nice.
Hi that's late for any answer but the solution arrived in MariaDB with BACKUP STAGE, open source time is relativist :)