Bug #22296 no schemaops are tallyed in cluster.binlog_index.
Submitted: 13 Sep 2006 6:34 Modified: 28 Oct 2010 8:29
Reporter: Matthew Montgomery Email Updates:
Status: Duplicate Impact on me:
None 
Category:MySQL Cluster: Replication Severity:S2 (Serious)
Version:mysql-5.1 OS:Linux (Linux )
Assigned to: CPU Architecture:Any
Tags: 5.1.11, cluster replication

[13 Sep 2006 6:34] Matthew Montgomery
Description:
No CREATE TABLE, DROP TABLE, ALTER TABLE, TRUNCATE TABLE commands are being logged as `schemaops` in the `cluster`.`binlog_index` table.

Their absence causes the `cluster`.`apply_status` to show incorrect or no position information for what is currently applied against the slave.

How to repeat:
At initial startup of cluster replication you should see 

mysqlM> select * from cluster.binlog_index;
Empty set (0.00 sec)

mysqlS> select * from cluster.apply_status;
Empty set (0.00 sec)

To test:

mysqlM> use test;
Database changed
mysqlM> create table t1 (id int auto_increment primary key) engine=ndbcluster;
Query OK, 0 rows affected (0.99 sec)

mysqlM> select * from cluster.binlog_index;
Empty set (0.00 sec)

mysqlS> use test;
Database changed
mysqlS> select * from cluster.apply_status\G
Empty set (0.00 sec)

mysqlS> show tables;
+----------------+
| Tables_in_test |
+----------------+
| t1             |
+----------------+
1 row in set (0.00 sec)

mysqlM> insert into t1 values(NULL);
Query OK, 1 row affected (0.04 sec)

mysqlM> select * from cluster.binlog_index;
+----------+-----------------------+-------+---------+---------+---------+-----------+
| Position | File                  | epoch | inserts | updates | deletes | schemaops |
+----------+-----------------------+-------+---------+---------+---------+-----------+
|      310 | ./ndbsup-1-bin.000001 |   321 |       1 |       0 |       0 |         0 |
+----------+-----------------------+-------+---------+---------+---------+-----------+
1 row in set (0.00 sec)

mysqlS> select * from t1;
+----+
| id |
+----+
|  1 |
+----+
1 row in set (0.04 sec)

mysqlS> select * from cluster.apply_status;
+-----------+-------+
| server_id | epoch |
+-----------+-------+
|         1 |   321 |
+-----------+-------+
1 row in set (0.05 sec)

mysqlM> drop table t1;
Query OK, 0 rows affected (0.81 sec)

mysqlM> select * from cluster.binlog_index;
+----------+-----------------------+-------+---------+---------+---------+-----------+
| Position | File                  | epoch | inserts | updates | deletes | schemaops |
+----------+-----------------------+-------+---------+---------+---------+-----------+
|      310 | ./ndbsup-1-bin.000001 |   321 |       1 |       0 |       0 |         0 |
+----------+-----------------------+-------+---------+---------+---------+-----------+
1 row in set (0.00 sec)

mysqlS> show tables;
Empty set (0.01 sec)

mysqlS> select * from cluster.apply_status;
+-----------+-------+
| server_id | epoch |
+-----------+-------+
|         1 |   321 |
+-----------+-------+
1 row in set (0.04 sec)

mysqlM> show binlog events;
+---------------------+-----+-------------+-----------+-------------+-----------------------------------------------------------------------------------+
| Log_name            | Pos | Event_type  | Server_id | End_log_pos | Info                                                                              |
+---------------------+-----+-------------+-----------+-------------+-----------------------------------------------------------------------------------+
| ndbsup-1-bin.000001 |   4 | Format_desc |         1 |         102 | Server ver: 5.1.11-beta-debug-log, Binlog ver: 4                                  |
| ndbsup-1-bin.000001 | 102 | Query       |         1 |         178 | use `test`; drop table t1                                                         |
| ndbsup-1-bin.000001 | 178 | Query       |         1 |         310 | use `test`; create table t1 (id int auto_increment primary key) engine=ndbcluster |
| ndbsup-1-bin.000001 | 310 | Query       |         1 |         374 | BEGIN                                                                             |
| ndbsup-1-bin.000001 | 374 | Table_map   |         1 |          39 | table_id: 20 (test.t1)                                                            |
| ndbsup-1-bin.000001 | 413 | Table_map   |         1 |          92 | table_id: 16 (cluster.apply_status)                                               |
| ndbsup-1-bin.000001 | 466 | Write_rows  |         1 |         134 | table_id: 16                                                                      |
| ndbsup-1-bin.000001 | 508 | Write_rows  |         1 |         168 | table_id: 20 flags: STMT_END_F                                                    |
| ndbsup-1-bin.000001 | 542 | Query       |         1 |         607 | COMMIT                                                                            |
| ndbsup-1-bin.000001 | 607 | Query       |         1 |         683 | use `test`; drop table t1                                                         |
+---------------------+-----+-------------+-----------+-------------+-----------------------------------------------------------------------------------+
10 rows in set (0.00 sec)

Suggested fix:
Include `schemaops` in binlog_index and apply_status.
[8 Feb 2007 9:31] Tomas Ulin
Matthew,

unfortunately there is no relation between schema operations and epochs, so the apply_status table cannot really be used.

I think we need a different functionality to convey this information.

And we don't have one.  Right now I'm inclined to set this bug in "won't fix", because I don's see how we can solve it.  The user will have to rely on the "old fashionded way", check the "show slave status", to see where the replication stopped :(

If you have a solution please let us know.

I'm assuming you are looking for the failover scenario, where one slave takes over from another?

The solution I would really sugggest is to have schemas replicated out of bound from the binlog...

BR,

Tomas
[23 Oct 2007 7:23] Magnus BlÄudd
BUG#27960 is not a duplicate but very similar, solving that one would also solve this, See comment in other bug report.
[28 Oct 2010 8:29] Geert Vanderkelen
Bug #54854 is duplicate, but closing this bug #22296 instead.