BUG#50364: FLUSH LOGS crashes the server (rpl.rpl_heartbeat_basic
fails in PB sporadically) The IO thread can concurrently access the relay log IO_CACHE while another thread is performing an FLUSH LOGS procedure. FLUSH LOGS closes and reopens the relay log and while doing so it (re)initializes its IO_CACHE. During this procedure the IO_CACHE mutex is also reinitialized, which can cause problems if some other thread (namely the IO THREAD) is concurrently accessing it at the time . This patch fixes the problem by extending the interface of the flush_master_info function to also include a second paramater, "need_relay_log_lock", stating whether the thread should grab the relay log lock or not before actually flushing the relay log. Also, IO thread now calls flush_master_info with this flag set when it flushes master info with in the event read_event loop. Finally, we also increase loop time in rpl_heartbeat_basic test case, so that the number of calls to flush logs doubles, stressing this part of the code a little more. mysql-test/suite/rpl/t/rpl_heartbeat_basic.test: Doubled the number of iterations on the FLUSH LOGS loop by doubling the time available to perform all iterations. sql/repl_failsafe.cc: Updating flush_master_info call so that it uses two parameters instead of one. sql/rpl_mi.cc: Updating flush_master_info call so that it uses two parameters instead of one. sql/rpl_mi.h: Changed flush_master_info interface. Now takes a second parameter instead of just one. The second parameter is: need_lock_relay_log. sql/rpl_rli.cc: Small fix in comment. sql/slave.cc: Updating flush_master_info call so that it uses two parameters instead of one. sql/sql_repl.cc: Updating flush_master_info call so that it uses two parameters instead of one.
Showing
Please register or sign in to comment