| Bug #44331 | Restore of database with events produces warning in replication | ||
|---|---|---|---|
| Submitted: | 16 Apr 2009 23:22 | Modified: | 16 Sep 2009 9:45 |
| Reporter: | Hema Sridharan | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Replication | Severity: | S3 (Non-critical) |
| Version: | 5.1, 6.0, mysql-6.0-backup | OS: | Any |
| Assigned to: | Daogang Qu | CPU Architecture: | Any |
[16 Apr 2009 23:27]
Hema Sridharan
Test file (rpl_backup_events.test)
Attachment: rpl_backup_events.test (application/test, text), 1.01 KiB.
[28 Apr 2009 20:38]
Sveta Smirnova
Thank you for the report.
Verified as described.
But real problem is not backup, but what EVENTs replicated without any definer.
Test case:
--source include/master-slave.inc
connection master;
CREATE DATABASE db1;
CREATE TABLE db1.t12(details CHAR(30));
CREATE EVENT db1.e1 ON SCHEDULE AT CURRENT_TIMESTAMP
ON COMPLETION PRESERVE DISABLE
DO INSERT INTO db1.t12 VALUES('event e1 fired');
SHOW CREATE EVENT db1.e1;
select EVENT_SCHEMA, EVENT_NAME, DEFINER from information_schema.events;
sync_slave_with_master;
connection slave;
SHOW CREATE EVENT db1.e1;
select EVENT_SCHEMA, EVENT_NAME, DEFINER from information_schema.events;
Result:
stop slave;
drop table if exists t1,t2,t3,t4,t5,t6,t7,t8,t9;
reset master;
reset slave;
drop table if exists t1,t2,t3,t4,t5,t6,t7,t8,t9;
start slave;
CREATE DATABASE db1;
CREATE TABLE db1.t12(details CHAR(30));
CREATE EVENT db1.e1 ON SCHEDULE AT CURRENT_TIMESTAMP
ON COMPLETION PRESERVE DISABLE
DO INSERT INTO db1.t12 VALUES('event e1 fired');
SHOW CREATE EVENT db1.e1;
Event sql_mode time_zone Create Event character_set_client collation_connection Database Collation
e1 SYSTEM CREATE DEFINER=`root`@`localhost` EVENT `e1` ON SCHEDULE AT '2009-04-28 23:37:06' ON COMPLETION PRESERVE DISABLE DO INSERT INTO db1.t12 VALUES('event e1 fired') latin1 latin1_swedish_ci latin1_swedish_ci
select EVENT_SCHEMA, EVENT_NAME, DEFINER from information_schema.events;
EVENT_SCHEMA EVENT_NAME DEFINER
db1 e1 root@localhost
SHOW CREATE EVENT db1.e1;
Event sql_mode time_zone Create Event character_set_client collation_connection Database Collation
e1 SYSTEM CREATE DEFINER=``@`` EVENT `e1` ON SCHEDULE AT '2009-04-28 23:37:06' ON COMPLETION PRESERVE DISABLE ON SLAVE DO INSERT INTO db1.t12 VALUES('event e1 fired') latin1 latin1_swedish_ci latin1_swedish_ci
select EVENT_SCHEMA, EVENT_NAME, DEFINER from information_schema.events;
EVENT_SCHEMA EVENT_NAME DEFINER
db1 e1 @
[28 Apr 2009 21:27]
Sveta Smirnova
According to internal discussion this is not a bug. Explanation. See bug #42217 about similar problem, but with stored procedures. If you create EVENT/SP without DEFINER clause set explicitly CURRENT_USER will be written into the binary log unless it is superuser. In case of superuser ''@'' would be written into binary log. So slave has DEFINER ''@'' clause. When you restore backup made on slave you get error shown. Workaround: specify DEFINER explicitly when create EVENT.
[28 Apr 2009 21:34]
Hema Sridharan
I would not change the status of this bug to "not a bug" unless I have a valid reason to accept this behaviour. Also this needs to be documented before closing the defect. Therefore, changing the status to verified again.
[16 Jun 2009 7:04]
Jørgen Løland
Unassigned since this is a replication issue, not backup issue.
[7 Jul 2009 5:35]
Daogang Qu
Why the backup command don't work? Must I install the mysql with version >= 6.0?
mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
Query OK, 0 rows affected (0.00 sec)
mysql> CREATE DATABASE db1;
Query OK, 1 row affected (0.01 sec)
mysql> CREATE TABLE db1.t12(details CHAR(30));
Query OK, 0 rows affected (0.07 sec)
mysql> CREATE EVENT db1.e1 ON SCHEDULE AT CURRENT_TIMESTAMP
-> ON COMPLETION PRESERVE DISABLE
-> DO INSERT INTO db1.t12 VALUES('event e1 fired');
Query OK, 0 rows affected (0.03 sec)
mysql> BACKUP DATABASE db1 TO 'db1m.bak';
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'DATABASE db1 TO 'db1m.bak'' at line 1
mysql> BACKUP DATABASE db1 TO 'db1m.bak';
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'DATABASE db1 TO 'db1m.bak'' at line 1
mysql>
mysql>
mysql> select @@global.version;
+------------------+
| @@global.version |
+------------------+
| 5.1.37-debug-log |
+------------------+
1 row in set (0.00 sec)
mysql>
[10 Jul 2009 8:48]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/78350 2994 Dao-Gang.Qu@sun.com 2009-07-10 Bug #44331 Restore of database with events produces warning in replication The real problem is that If the user create EVENT without DEFINER clause set explicitly, the CURRENT_USER is set to DEFINER in current thread. The CURRENT_USER is mysqld startup user on master, but the CURRENT_USER is empty on slave for replication. So the definer is not coincident between master and slave. For fixing the problem, the CURRENT_USER will be written into the binary log as default definer for replication on master, If the user create EVENT without DEFINER clause set explicitly. @ mysql-test/suite/rpl/r/rpl_restore_event_warning.result Add test result for bug#44331 @ mysql-test/suite/rpl/t/rpl_restore_event_warning.test Add test file for bug#44331 @ sql/events.cc The "create_query_string(...)" is added for generating the CREATE query string from the thd information. Added a new parameter "definer_exist" to 'Events::create_event(...)' function for handling the case that the user create EVENT without DEFINER clause set explicitly. the CURRENT_USER will be written into the binary log as default definer for replication. @ sql/events.h Added a new parameter "definer_exist" with default actual parameter to 'Events::create_event(...)' function declaration. @ sql/sql_parse.cc Add a new local variable "definer_exist" to "mysql_execute_command(THD *thd)" function to indicate if the definer has been specified by user.
[20 Jul 2009 13:27]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/79007 2994 Dao-Gang.Qu@sun.com 2009-07-20 Bug #44331 Restore of database with events produces warning in replication The real problem is that if the EVENT is created without DEFINER clause set explicitly or the definer is set to CURRENT_USER, the definer is not consistent between master and slave. Because the DEFINER is set to CURRENT_USER of the current thread. The CURRENT_USER is mysqld startup user on master, but the CURRENT_USER is empty on slave for slave SQL thread. For fixing the problem, the the value of CURRENT_USER will be written into the binary log as default definer for slave SQL thread on master if the EVENT is created without DEFINER clause set explicitly or the definer is set to CURRENT_USER. @ mysql-test/suite/rpl/r/rpl_events.result Test result of Bug#44331 @ mysql-test/suite/rpl/t/rpl_events.test This test verifies if the definer is consistent between master and slave when the event is created without DEFINER clause set explicitly or the DEFINER is set to CURRENT_USER @ sql/events.cc The "create_query_string" function is added for creating a new query string and insert the DEFINER clause to it. Added a new parameter "definer_set_mode" to 'Events::create_event' function for indicating the mode of the definer is set. The value of CURRENT_USER will be written into the binary log as default definer for slave SQL thread. @ sql/events.h Added a new parameter "definer_exist" with default actual parameter to 'Events::create_event(...)' function declaration.
[24 Jul 2009 7:24]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/79230 3034 Dao-Gang.Qu@sun.com 2009-07-24 Bug #44331 Restore of database with events produces warning in replication The real problem is that if the EVENT is created without DEFINER clause set explicitly or the definer is set to CURRENT_USER, the definer is not consistent between master and slave. Because the DEFINER is set to CURRENT_USER of the current thread. The CURRENT_USER is mysqld startup user on master, but the CURRENT_USER is empty on slave for slave SQL thread. For fixing the problem, the the value of CURRENT_USER will be written into the binary log as default definer for slave SQL thread on master if the EVENT is created without DEFINER clause set explicitly or the definer is set to CURRENT_USER. @ mysql-test/suite/rpl/r/rpl_drop_if_exists.result The DEFINER=`root`@`localhost` has been added by running "./mtr rpl_drop_if_exists --record" command for adapting the updated code. @ mysql-test/suite/rpl/r/rpl_events.result Test result of Bug#44331 @ mysql-test/suite/rpl/r/rpl_innodb_mixed_dml.result The DEFINER=`root`@`localhost` has been added by running "./mtr rpl_innodb_mixed_dml --record" command for adapting the updated code. @ mysql-test/suite/rpl/t/rpl_events.test This test verifies if the definer is consistent between master and slave when the event is created without DEFINER clause set explicitly or the DEFINER is set to CURRENT_USER @ sql/events.cc The "create_query_string" function is added for creating a new query string and insert the DEFINER clause to it. Added a new parameter "definer_set_mode" to 'Events::create_event' function for indicating the mode of the definer is set. The value of CURRENT_USER will be written into the binary log as default definer for slave SQL thread. @ sql/events.h Added a new parameter "definer_exist" with default actual parameter to 'Events::create_event(...)' function declaration.
[30 Jul 2009 8:24]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/79605 3034 Dao-Gang.Qu@sun.com 2009-07-30 Bug #44331 Restore of database with events produces warning in replication The real problem is that if the EVENT is created without DEFINER clause set explicitly or the definer is set to CURRENT_USER, the definer is not consistent between master and slave. Because the DEFINER is set to CURRENT_USER of the current thread. The CURRENT_USER is mysqld startup user on master, but the CURRENT_USER is empty on slave for slave SQL thread. To fix the problem, if definer is not set explicitly, a DEFINER clause will be added when writing the query into binlog; if 'CURRENT_USER' is used as the DEFINER, it will be replaced with the value of current user before writing to binlog. @ mysql-test/suite/rpl/r/rpl_drop_if_exists.result Updated the result file after fixing bug#44331 @ mysql-test/suite/rpl/r/rpl_events.result Test result of Bug#44331 @ mysql-test/suite/rpl/r/rpl_innodb_mixed_dml.result Updated the result file after fixing bug#44331 @ mysql-test/suite/rpl/t/rpl_events.test Added test to verify if the definer is consistent between master and slave when the event is created without DEFINER clause set explicitly or the DEFINER is set to CURRENT_USER @ sql/events.cc The "create_query_string" function is added for creating a new query string and insert the DEFINER clause to it. Added a new parameter "definer_using_cur_user" to 'Events::create_event' function for indicating the mode of the definer is set. The value of CURRENT_USER will be written into the binary log as default definer for slave SQL thread. @ sql/sql_lex.h Added the offset variable to LEX for recording the current offset address.
[3 Aug 2009 3:14]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/79855 3034 Dao-Gang.Qu@sun.com 2009-08-03 Bug #44331 Restore of database with events produces warning in replication The real problem is that if the EVENT is created without DEFINER clause set explicitly or the definer is set to CURRENT_USER, the definer is not consistent between master and slave. Because the DEFINER is set to CURRENT_USER of the current thread. The CURRENT_USER is mysqld startup user on master, but the CURRENT_USER is empty on slave for slave SQL thread. To fix the problem, if definer is not set explicitly, a DEFINER clause will be added when writing the query into binlog; if 'CURRENT_USER' is used as the DEFINER, it will be replaced with the value of current user before writing to binlog. @ mysql-test/suite/rpl/r/rpl_drop_if_exists.result Updated the result file after fixing bug#44331 @ mysql-test/suite/rpl/r/rpl_events.result Test result of Bug#44331 @ mysql-test/suite/rpl/r/rpl_innodb_mixed_dml.result Updated the result file after fixing bug#44331 @ mysql-test/suite/rpl/t/rpl_events.test Added test to verify if the definer is consistent between master and slave when the event is created without DEFINER clause set explicitly or the DEFINER is set to CURRENT_USER @ sql/events.cc The "create_query_string" function is added for creating a new query string and insert the DEFINER clause to it. Added a new parameter "definer_set_mode" to 'Events::create_event' function for indicating the mode of the definer is set. The value of CURRENT_USER will be written into the binary log as default definer for slave SQL thread.
[5 Aug 2009 6:35]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/80118 3034 Dao-Gang.Qu@sun.com 2009-08-05 Bug #44331 Restore of database with events produces warning in replication If an EVENT is created without the DEFINER clause set explicitly or with it set to CURRENT_USER, the master and slaves become inconsistent. This issue stems from the fact that in both cases, the DEFINER is set to the CURRENT_USER of the current thread. On the master, the CURRENT_USER is the mysqld's user, while on the slave, the CURRENT_USER is empty for the SQL Thread which is responsible for executing the statement. To fix the problem, we do what follows. If the definer is not set explicitly, a DEFINER clause is added when writing the query into binlog; if 'CURRENT_USER' is used as the DEFINER, it is replaced with the value of the current user before writing to binlog. @ mysql-test/suite/rpl/r/rpl_drop_if_exists.result Updated the result file after fixing bug#44331 @ mysql-test/suite/rpl/r/rpl_events.result Test result of Bug#44331 @ mysql-test/suite/rpl/r/rpl_innodb_mixed_dml.result Updated the result file after fixing bug#44331 @ mysql-test/suite/rpl/t/rpl_events.test Added test to verify if the definer is consistent between master and slave when the event is created without the DEFINER clause set explicitly or the DEFINER is set to CURRENT_USER @ sql/events.cc The "create_query_string" function is added to create a new query string and insert the DEFINER clause to it. Added a new parameter "definer_set_mode" to 'Events::create_event' function to indicate the mode of the definer. The value of CURRENT_USER will be written into the binary log as default definer for the SQL thread.
[16 Aug 2009 9:53]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/80857 3034 Dao-Gang.Qu@sun.com 2009-08-16 Bug #44331 Restore of database with events produces warning in replication If an EVENT is created without the DEFINER clause set explicitly or with it set to CURRENT_USER, the master and slaves become inconsistent. This issue stems from the fact that in both cases, the DEFINER is set to the CURRENT_USER of the current thread. On the master, the CURRENT_USER is the mysqld's user, while on the slave, the CURRENT_USER is empty for the SQL Thread which is responsible for executing the statement. To fix the problem, we do what follows. If the definer is not set explicitly, a DEFINER clause is added when writing the query into binlog; if 'CURRENT_USER' is used as the DEFINER, it is replaced with the value of the current user before writing to binlog. @ mysql-test/suite/rpl/r/rpl_drop_if_exists.result Updated the result file after fixing bug#44331 @ mysql-test/suite/rpl/r/rpl_events.result Test result of Bug#44331 @ mysql-test/suite/rpl/r/rpl_innodb_mixed_dml.result Updated the result file after fixing bug#44331 @ mysql-test/suite/rpl/t/rpl_events.test Added test to verify if the definer is consistent between master and slave when the event is created without the DEFINER clause set explicitly or the DEFINER is set to CURRENT_USER @ sql/events.cc The "create_query_string" function is added to create a new query string for removing executable comments. @ sql/sql_yacc.yy The remember_name token was added for recording the offset of EVENT_SYM.
[29 Aug 2009 18:28]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/81935 3561 Dao-Gang.Qu@sun.com 2009-08-30 [merge] Bug #44331 Restore of database with events produces warning in replication If an EVENT is created without the DEFINER clause set explicitly or with it set to CURRENT_USER, the master and slaves become inconsistent. This issue stems from the fact that in both cases, the DEFINER is set to the CURRENT_USER of the current thread. On the master, the CURRENT_USER is the mysqld's user, while on the slave, the CURRENT_USER is empty for the SQL Thread which is responsible for executing the statement. To fix the problem, we do what follows. If the definer is not set explicitly, a DEFINER clause is added when writing the query into binlog; if 'CURRENT_USER' is used as the DEFINER, it is replaced with the value of the current user before writing to binlog. @ mysql-test/suite/rpl/r/rpl_backup_extra.result Updated the result file after fixing bug#44331 @ mysql-test/suite/rpl/r/rpl_backup_multi.result Updated the result file after fixing bug#44331 @ mysql-test/suite/rpl/r/rpl_create_if_not_exists.result Updated the result file after fixing bug#44331 @ mysql-test/suite/rpl/r/rpl_drop_if_exists.result Updated the result file after fixing bug#44331 @ mysql-test/suite/rpl/r/rpl_events.result Test result of Bug#44331 @ mysql-test/suite/rpl/r/rpl_innodb_mixed_dml.result Updated the result file after fixing bug#44331 @ mysql-test/suite/rpl/t/rpl_events.test Added test to verify if the definer is consistent between master and slave when the event is created without the DEFINER clause set explicitly or the DEFINER is set to CURRENT_USER @ sql/events.cc The "create_query_string" function is added to create a new query string for removing executable comments. @ sql/sql_yacc.yy The remember_name token was added for recording the offset of EVENT_SYM.
[31 Aug 2009 2:27]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/81971 3092 Dao-Gang.Qu@sun.com 2009-08-31 Bug #44331 Restore of database with events produces warning in replication Update the test case for BUG#44331 to fix the push build failure.
[31 Aug 2009 2:42]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/81972 3565 Dao-Gang.Qu@sun.com 2009-08-31 [merge] Bug #44331 Restore of database with events produces warning in replication Update the test case for BUG#44331 to fix the push build failure.
[2 Sep 2009 16:41]
Bugs System
Pushed into 5.1.39 (revid:joro@sun.com-20090902154533-8actmfcsjfqovgsb) (version source revid:dao-gang.qu@sun.com-20090831022601-h2ikk473x5njqq29) (merge vers: 5.1.39) (pib:11)
[8 Sep 2009 19:06]
Jon Stephens
Documented bugfix in the 5.1.39 changelog as follows:
Creating a scheduled event whose DEFINER clause was either set
to CURRENT_USER or not set explicitly caused the master and the
slave to become inconsistent. This issue stems from the fact
that, in both cases, the DEFINER is set to the CURRENT_USER of
the current thread. (On the master, the CURRENT_USER is the
mysqld user; on the slave, the CURRENT_USER is empty.)
This behavior has been modified as follows:
·If CURRENT_USER is used as the DEFINER, it is replaced with
the *value* of CURRENT_USER before the
CREATE EVENT statement is written to the binary log.
·If the definer is not set explicitly, a DEFINER clause using
the value of CURRENT_USER is added to the CREATE EVENT
statement before it is written to the binary log.
Set status to NDI, waiting on push to 5.4 tree.
[14 Sep 2009 16:05]
Bugs System
Pushed into 5.4.4-alpha (revid:alik@sun.com-20090914155317-m1g9wodmndzdj4l1) (version source revid:alik@sun.com-20090914155317-m1g9wodmndzdj4l1) (merge vers: 5.4.4-alpha) (pib:11)
[16 Sep 2009 9:45]
Jon Stephens
Bugfix also documented in the 5.4.4 changelog. Closed.
[1 Oct 2009 5:59]
Bugs System
Pushed into 5.1.39-ndb-6.3.28 (revid:jonas@mysql.com-20091001055605-ap2kiaarr7p40mmv) (version source revid:jonas@mysql.com-20091001055605-ap2kiaarr7p40mmv) (merge vers: 5.1.39-ndb-6.3.28) (pib:11)
[1 Oct 2009 7:25]
Bugs System
Pushed into 5.1.39-ndb-7.0.9 (revid:jonas@mysql.com-20091001072547-kv17uu06hfjhgjay) (version source revid:jonas@mysql.com-20091001071652-irejtnumzbpsbgk2) (merge vers: 5.1.39-ndb-7.0.9) (pib:11)
[1 Oct 2009 13:25]
Bugs System
Pushed into 5.1.39-ndb-7.1.0 (revid:jonas@mysql.com-20091001123013-g9ob2tsyctpw6zs0) (version source revid:jonas@mysql.com-20091001123013-g9ob2tsyctpw6zs0) (merge vers: 5.1.39-ndb-7.1.0) (pib:11)
[2 Oct 2009 0:15]
Paul DuBois
Moved 5.4 changelog entry from 5.4.4 to 5.4.3.
[5 Oct 2009 10:50]
Bugs System
Pushed into 5.1.39-ndb-6.2.19 (revid:jonas@mysql.com-20091005103850-dwij2dojwpvf5hi6) (version source revid:jonas@mysql.com-20090930185117-bhud4ek1y0hsj1nv) (merge vers: 5.1.39-ndb-6.2.19) (pib:11)
Description: * Set up 2 servers to act as master and slave * Create database, table and events in master * Execute backup in slave(db12s.bak) and copy the backup image file to master server * Perform restore from (db1s.bak) master server * Note that restore will produce warning message in master and slave servers. How to repeat: In master ========= mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%'; Query OK, 0 rows affected (0.00 sec) mysql> CREATE DATABASE db1; Query OK, 1 row affected (0.01 sec) mysql> CREATE TABLE db1.t12(details CHAR(30)); Query OK, 0 rows affected (0.00 sec) mysql> CREATE EVENT db1.e1 ON SCHEDULE AT CURRENT_TIMESTAMP -> ON COMPLETION PRESERVE DISABLE -> DO INSERT INTO db1.t12 VALUES('event e1 fired'); Query OK, 0 rows affected (0.00 sec) mysql> BACKUP DATABASE db1 TO 'db1m.bak'; +-----------+ | backup_id | +-----------+ | 270 | +-----------+ 1 row in set (0.34 sec) In slave ======== mysql> BACKUP DATABASE db1 TO 'db1s.bak'; +-----------+ | backup_id | +-----------+ | 270 | +-----------+ 1 row in set (0.36 sec) mysql> SHOW CREATE EVENT db1.e1; Event sql_mode time_zone Create Event character_set_client collation_connection Database Collation e1 SYSTEM CREATE DEFINER=``@`` EVENT `e1` ON SCHEDULE AT '2009-04-17 02:13:46' ON COMPLETION PRESERVE DISABLE ON SLAVE DO INSERT INTO db1.t12 VALUES('event e1 fired') latin1 latin1_swedish_ci latin1_swedish_ci Note that definer is not root user in slave and shows '@' Now copy the backup image file from slave to master server From master =========== mysql> restore from 'db1s.bak' overwrite; +-----------+ | backup_id | +-----------+ | 272 | +-----------+ 1 row in set, 1 warning (0.11 sec) mysql> show warnings; +-------+------+--------------------------------------------------------+ | Level | Code | Message | +-------+------+--------------------------------------------------------+ | Note | 1449 | The user specified as a definer (''@'') does not exist | +-------+------+--------------------------------------------------------+ 1 row in set (0.00 sec) mysql> restore from 'db1m.bak' overwrite; +-----------+ | backup_id | +-----------+ | 273 | +-----------+ 1 row in set (0.10 sec) mysql> show warnings; Empty set (0.00 sec)