mirror/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-01-24 15:54:37 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
mariadb/mysql-test/include/uninstall_semisync.inc

30 lines
820 B
PHP
Raw Normal View History

Bug#15948818-SEMI-SYNC ENABLED MASTER CRASHES WHEN EVENT SCHEDULER DROPS EVENTS Problem: On a semi sync enabled server (Master/Slave), if event scheduler drops an event after completion, server crashes. Analaysis: If an event is created with "ON COMPLETION NOT PRESERVE" clause, event scheduler deletes the event upon event completion(expiration) and the thread object will be destroyed. In the destructor of the thread object, mysys_var member is set to zero explicitly. Later from the same destructor call(same execution path), incase of semi sync enabled server, while cleanup is called, THD::mysys_var member is accessed by THD::enter_cond() function which causes server to crash. Fix: mysys_var should not be explicitly set to zero and also it is not required. sql/sql_class.cc: mysys_var should not be explicitly set to zero.
2013-03-29 09:28:31 +05:30
#
# Copyright (c) 2013, Oracle and/or its affiliates. All rights reserved.
#
--let $include_filename= uninstall_semisync.inc
--source include/begin_include_file.inc
--disable_query_log
--connection slave
--source include/stop_slave_io.inc
# Uninstall rpl_semi_sync_slave first
--disable_warnings
UNINSTALL PLUGIN rpl_semi_sync_slave;
--connection master
Bug#17638477 UNINSTALL AND INSTALL SEMI-SYNC PLUGIN CAUSES SLAVES TO BREAK Problem: Uninstallation of semi sync plugin causes replication to break. Analysis: A semisync enabled replication is mutual agreement between Master and Slave when the connection (I/O thread) is established. Once I/O thread is started and if semisync is enabled on both master and slave, master appends special magic header to events using semisync plugin functions and sends it to slave. And slave expects that each event will have that special magic header format and reads those bytes using semisync plugin functions. When semi sync replication is in use if users execute uninstallation of the plugin on master, slave gets confused while interpreting that event's content because it expects special magic header at the beginning of the event. Slave SQL thread will be stopped with "Missing magic number in the header" error. Similar problem will happen if uninstallation of the plugin happens on slave when semi sync replication is in in use. Master sends the events with magic header and slave does not know about the added magic header and thinks that it received a corrupted event. Hence slave SQL thread stops with "Found corrupted event" error. Fix: Uninstallation of semisync plugin will be blocked when semisync replication is in use and will throw 'ER_UNKNOWN_ERROR' error. To detect that semisync replication is in use, this patch uses semisync status variable values. > On Master, it checks for 'Rpl_semi_sync_master_status' to be OFF before allowing the uninstallation of rpl_semi_sync_master plugin. >> Rpl_semi_sync_master_status is OFF when >>> there is no dump thread running >>> there are no semisync slaves > On Slave, it checks for 'Rpl_semi_sync_slave_status' to be OFF before allowing the uninstallation of rpl_semi_sync_slave plugin. >> Rpl_semi_sync_slave_status is OFF when >>> there is no I/O thread running >>> replication is asynchronous replication.
2014-05-05 22:22:15 +05:30
# After BUG#17638477 fix, uninstallation of rpl_semi_sync_master
# is not allowed when there are semi sync slaves. Hence kill
# all dump threads before uninstalling it.
SET GLOBAL rpl_semi_sync_master_enabled = OFF;
--source include/stop_dump_threads.inc
Bug#15948818-SEMI-SYNC ENABLED MASTER CRASHES WHEN EVENT SCHEDULER DROPS EVENTS Problem: On a semi sync enabled server (Master/Slave), if event scheduler drops an event after completion, server crashes. Analaysis: If an event is created with "ON COMPLETION NOT PRESERVE" clause, event scheduler deletes the event upon event completion(expiration) and the thread object will be destroyed. In the destructor of the thread object, mysys_var member is set to zero explicitly. Later from the same destructor call(same execution path), incase of semi sync enabled server, while cleanup is called, THD::mysys_var member is accessed by THD::enter_cond() function which causes server to crash. Fix: mysys_var should not be explicitly set to zero and also it is not required. sql/sql_class.cc: mysys_var should not be explicitly set to zero.
2013-03-29 09:28:31 +05:30
UNINSTALL PLUGIN rpl_semi_sync_master;
--enable_warnings
--connection slave
START SLAVE IO_THREAD;
--source include/wait_for_slave_io_to_start.inc
--enable_query_log
--source include/end_include_file.inc
Reference in a new issue Copy permalink