List:Commits« Previous MessageNext Message »
From:Frazer Clement Date:March 28 2012 11:01pm
Subject:bzr push into mysql-5.1-telco-7.0 branch (frazer.clement:4908 to 4909)
View as plain text  
 4909 Frazer Clement	2012-03-29
      Attempt testcase stability fix for ndb_binlog_index

    modified:
      mysql-test/suite/ndb_binlog/t/ndb_binlog_index.test
 4908 Frazer Clement	2012-03-28
      Bug#54854 / Bug#11762277 CAN'T FIND GOOD POSITION FOR REPLICATION BREAK BETWEEN DDL STATEMENTS 
      
      Problem
      -------
      
      Replication channel cutover uses the last applied epoch on the slave to determine where
      to begin replication from on the new Master.
      
      The last applied epoch is obtained from the Slave's mysql.ndb_apply_status table.
      The new Master's mysql.ndb_binlog_index table is queried to find the first epoch *after* the
      Slave's last applied epoch, the binlog file and offset of this epoch are used to start
      replication from the new master.
      
      Issues : 
       1) There may be *no* epoch after the last applied epoch
          If log-empty-epochs=0, and even in normal cases, where the slave is up-to-date and
          no new epoch has been finalised on the Master.
       2) As epochs are not continuously numbered, there may be a gap between the last applied
          epoch and the next.  It is not possible to determine what the next epoch number will
          be.  If the new Master is missing some epochs, the current cutover mechanism will 
          silently skip over them and jump to the first available epoch 
       3) Where there is DDL between the last applied epoch and the next epoch, the cutover mechanism
          will skip the DDL.  If the DDL has been applied then this is ok, if it has not, then it
          is silently skipped.
      
      Solution
      --------
      
      This series implements a more precise mechanism for performing replication channel cutover.
      This allows us to ensure that a replication channel cutover begins replication precisely
      after the end of the last committed epoch on the Slave.
      
      This involves :
        - Modifications to the MySQL Server Binlog code to record the next position in the Binlog
          after the COMMIT event at the end of an epoch transaction
        - Modifications to the mysql.ndb_binlog_index table schema to include next_file and next_position
          columns
        - Modifications to the Ndb Binlog injector to set the next_file and next_position columns in
          the mysql.ndb_binlog_index table.
      
      The existing replication channel cutover mechanism continues to work, with the same limitations
      as before.
      A new channel cutover mechanism is defined, making use of the new columns.
      
      Old channel cutover mechanism, given a last applied epoch from the slave.
      
        SELECT File, position from mysql.ndb_binlog_index where epoch > <last_applied_epoch>;
      
      New channel cutover mechanism :
        SELECT next_file, next_position from mysql.ndb_binlog_index where epoch = <last_applied_epoch>;
      
      Note that i) This statement uses the last applied epoch directly - there is no dependency on there
      being a following epoch, ii) There is no risk of silently 'jumping' over an epoch gap during 
      replication channel cutover, iii) Any DDL after the last applied epoch will be (re)applied.
      
      Reapplying inter-epoch DDL can result in errors on the Slave.  This is considered better than the
      old channel cutover mechanism which can result in silently skipping DDL.  A separate patch series
      implements 'DDL ignore existance errors' handling.
      
      This series includes a testcase which verifies the correctness of the next_position under 
      multithreaded Binlog inserts etc.

    added:
      mysql-test/suite/ndb_binlog/r/ndb_binlog_index.result
      mysql-test/suite/ndb_binlog/t/ndb_binlog_check_binlog_index.inc
      mysql-test/suite/ndb_binlog/t/ndb_binlog_index.test
      mysql-test/suite/ndb_binlog/t/ndb_binlog_index_test_schema_independent.inc
    modified:
      mysql-test/suite/ndb_binlog/r/ndb_binlog_ignore_db.result
      mysql-test/suite/ndb_binlog/t/ndb_binlog_ignore_db.test
      mysql-test/suite/ndb_rpl/r/ndb_rpl_idempotent.result
      mysql-test/suite/ndb_rpl/r/ndb_rpl_sync.result
      mysql-test/suite/ndb_rpl/t/ndb_rpl_idempotent.test
      scripts/mysql_system_tables.sql
      scripts/mysql_system_tables_fix.sql
      sql/ha_ndbcluster_binlog.cc
      sql/log.cc
      sql/log.h
      sql/log_event.h
      sql/rpl_injector.cc
      sql/rpl_injector.h
      sql/sql_class.cc
      sql/sql_class.h
=== modified file 'mysql-test/suite/ndb_binlog/t/ndb_binlog_index.test'
--- a/mysql-test/suite/ndb_binlog/t/ndb_binlog_index.test	2012-03-28 15:17:32 +0000
+++ b/mysql-test/suite/ndb_binlog/t/ndb_binlog_index.test	2012-03-28 23:00:01 +0000
@@ -1,6 +1,10 @@
 --source include/have_ndb.inc
 --source include/have_log_bin.inc
 
+--disable_query_log
+reset master;
+--enable_query_log
+
 --echo -------------------------------------------------
 --echo First run using ndb_binlog_index table containing
 --echo  epoch end position information

No bundle (reason: useless for push emails).
Thread
bzr push into mysql-5.1-telco-7.0 branch (frazer.clement:4908 to 4909) Frazer Clement29 Mar