Details
-
Type:
Technical task
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 10.0.10
-
Component/s: None
-
Labels:None
Description
If CREATE OR REPLACE fails on CREATE stage, the table is still dropped, but nothing is written to the binlog. Obviously, it will cause further inconsistencies between master and slave, or upon restoring from binlog.
MariaDB [test]> create table t1 (i int); Query OK, 0 rows affected (1.17 sec) MariaDB [test]> create or replace table t1; ERROR 1113 (42000): A table must have at least 1 column MariaDB [test]> show binlog events; +----------------------+-----+-------------------+-----------+-------------+-----------------------------------------------------+ | Log_name | Pos | Event_type | Server_id | End_log_pos | Info | +----------------------+-----+-------------------+-----------+-------------+-----------------------------------------------------+ | wheezy-64-bin.000001 | 4 | Format_desc | 1 | 248 | Server ver: 10.0.7-MariaDB-debug-log, Binlog ver: 4 | | wheezy-64-bin.000001 | 248 | Gtid_list | 1 | 273 | [] | | wheezy-64-bin.000001 | 273 | Binlog_checkpoint | 1 | 316 | wheezy-64-bin.000001 | | wheezy-64-bin.000001 | 316 | Gtid | 1 | 354 | GTID 0-1-1 | | wheezy-64-bin.000001 | 354 | Query | 1 | 440 | use `test`; create table t1 (i int) | +----------------------+-----+-------------------+-----------+-------------+-----------------------------------------------------+ 5 rows in set (0.00 sec) MariaDB [test]> show tables; Empty set (0.00 sec)
Test case that shows the consequent replication failure:
--source include/master-slave.inc
create table t1 (i int);
--error ER_TABLE_MUST_HAVE_COLUMNS
create or replace table t1;
show binlog events;
show tables;
create table t1 (j int);
--sync_slave_with_master
Last_SQL_Errno 1050 Last_SQL_Error Error 'Table 't1' already exists' on query. Default database: 'test'. Query: 'create table t1 (j int)'
revision-id: monty@askmonty.org-20140129123724-hl8iop8cpxbk67r5 revno: 3970 branch-nick: mariadb-monty
Gliffy Diagrams
Attachments
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
Fixed and pushed into 10.0
This is fixed by writing the failing create table select followed by rollback to the log.
This should be good enough for gamma.
The one disadvantage of this approach is that in case of row based logging and
CREATE OR REPLACE TABLE xxx ... SELECT
that fails (for example because of duplicate key) the table xxx will be left on the slave while on the master it will be deleted.
I plan to fix this by for this case write DROP TABLE IF EXISTS xxx to the binary log.
This will ensure that the master and slave will be consistent in all cases.