• unknown's avatar
    BUG#36197: flush tables (or little table cache) can cause crash on slave · dac6ffb9
    unknown authored
    When flushing tables, there were a slight chance that the flush was occuring
    between processing of two table map events. Since the tables are opened
    one by one, it might result in that the tables were not valid and that sub-
    sequent locking of tables would cause the slave to crash.
    
    The problem is solved by opening and locking all tables at once using
    simple_open_n_lock_tables(). Also, the patch contain a change to open_tables()
    so that pre-locking only takes place when the trg_event_map is not zero, which
    was not the case before (this caused the lock to be placed in thd->locked_tables
    instead of thd->lock since the assumption was that triggers would be called
    later and therefore the tables should be pre-locked).
    
    
    mysql-test/suite/rpl/r/rpl_found_rows.result:
      Result change
    mysql-test/suite/rpl/r/rpl_row_inexist_tbl.result:
      Result change
    mysql-test/suite/rpl/t/rpl_found_rows.test:
      Adding drop of table that was created in test.
    mysql-test/suite/rpl/t/rpl_slave_status.test:
      Adding waits for slave start and stop to ensure that test works.
    sql/log_event.cc:
      Replacing table-by-table open and lock with a single call
      to simple_open_n_lock_tables(), which in turn required some
      changes to other code.
    sql/log_event_old.cc:
      Replacing table-by-table open and lock with a single call
      to simple_open_n_lock_tables(), which in turn required some
      changes to other code.
    sql/sql_base.cc:
      Extending check inside open_tables() so that pre-locking in only done if
      tables->trg_egent_map is non-zero.
    mysql-test/include/wait_for_slave_sql_to_start.inc:
      New BitKeeper file ``mysql-test/include/wait_for_slave_sql_to_start.inc''
    dac6ffb9
rpl_slave_status.test 1.57 KB
--source include/master-slave.inc

############################################################################
# Test case for BUG#10780
#
# REQUIREMENT
#   A slave without replication privileges should have Slave_IO_Running = No

# 1. Create new replication user
connection master;
grant replication slave on *.* to rpl@127.0.0.1 identified by 'rpl';

connection slave;
stop slave;
change master to master_user='rpl',master_password='rpl';
start slave;

# 2. Do replication as new user
connection master;
--disable_warnings
drop table if exists t1;
--enable_warnings
create table t1 (n int);
insert into t1 values (1);
save_master_pos;
connection slave;
sync_with_master;
select * from t1;

# 3. Delete new replication user
connection master;
delete from mysql.user where user='rpl';
flush privileges;
connection slave;

# 4. Restart slave without privileges
# (slave.err will contain access denied error for this START SLAVE command)
stop slave;
source include/wait_for_slave_to_stop.inc;
start slave;
source include/wait_for_slave_sql_to_start.inc;

# 5. Make sure Slave_IO_Running = No
--replace_result $MASTER_MYPORT MASTER_MYPORT
# Column 1 is replaced, since the output can be either
# "Connecting to master" or "Waiting for master update"
--replace_column 1 # 7 # 8 # 9 # 22 # 23 # 35 # 36 #
query_vertical show slave status;

# Cleanup (Note that slave IO thread is not running)
connection slave;
drop table t1;
delete from mysql.user where user='rpl';
# cleanup: slave io thread has been stopped "irrecoverably"
# so we clean up mess manually

connection master;
drop table t1;

# end of 4.1 tests