Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 5.5.28a-galera
-
Fix Version/s: 5.5.28a-galera
-
Component/s: None
-
Labels:None
Description
It is a regression in revno 3352 (works on revno 3351, doesn't work on 3352).
If a table is created as CREATE TABLE ... AS SELECT ..., normally it should trigger two events in the row binary log: one for CREATE DDL (statement format), and another one for Write_rows. It was so in revno 3351, but not anymore:
revno 3352 (wrong):
create table t1 as select 1; Query OK, 1 row affected (0.31 sec) Records: 1 Duplicates: 0 Warnings: 0 show binlog events; +-------------------+-----+-------------+-----------+-------------+-----------------------------------------------------+ | Log_name | Pos | Event_type | Server_id | End_log_pos | Info | +-------------------+-----+-------------+-----------+-------------+-----------------------------------------------------+ | master-bin.000001 | 4 | Format_desc | 1 | 245 | Server ver: 5.5.27-MariaDB-debug-log, Binlog ver: 4 | | master-bin.000001 | 245 | Query | 1 | 318 | BEGIN | | master-bin.000001 | 318 | Table_map | 1 | 359 | table_id: 33 (test.t1) | | master-bin.000001 | 359 | Write_rows | 1 | 393 | table_id: 33 flags: STMT_END_F | | master-bin.000001 | 393 | Xid | 1 | 420 | COMMIT /* xid=2 */ | +-------------------+-----+-------------+-----------+-------------+-----------------------------------------------------+ 5 rows in set (0.01 sec)
revno 3351 (OK):
create table t1 as select 1; Query OK, 1 row affected (0.34 sec) Records: 1 Duplicates: 0 Warnings: 0 show binlog events; +-------------------+-----+-------------+-----------+-------------+---------------------------------------------------------------------+ | Log_name | Pos | Event_type | Server_id | End_log_pos | Info | +-------------------+-----+-------------+-----------+-------------+---------------------------------------------------------------------+ | master-bin.000001 | 4 | Format_desc | 1 | 245 | Server ver: 5.5.27-MariaDB-debug-log, Binlog ver: 4 | | master-bin.000001 | 245 | Query | 1 | 318 | BEGIN | | master-bin.000001 | 318 | Query | 1 | 441 | use `test`; CREATE TABLE `t1` ( `1` int(1) NOT NULL DEFAULT '0' ) | | master-bin.000001 | 441 | Table_map | 1 | 482 | table_id: 33 (test.t1) | | master-bin.000001 | 482 | Write_rows | 1 | 516 | table_id: 33 flags: STMT_END_F | | master-bin.000001 | 516 | Xid | 1 | 543 | COMMIT /* xid=1 */ | +-------------------+-----+-------------+-----------+-------------+---------------------------------------------------------------------+ 6 rows in set (0.00 sec)
It means that if the binlog is used to replicate (or recreate) the data, the process will fail immediately on the Write_rows event, because the table won't exist.
The problem is reproducible even if wsrep provider is not set.
Gliffy Diagrams
Attachments
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
Fix was merged as part of revision: http://bazaar.launchpad.net/~maria-captains/maria/maria-5.5-galera/revision/3355
CTAS processing was refactored in upstream based on tracker: https://bugs.launchpad.net/codership-mysql/+bug/1052002