There was an erroneous parameter when calling flush_master_info
from write_ignored_events_info_to_relay_log which could lead to a
server crash. This happens because the I/O thread releases the
log_lock before calling the flush_master_info.
Set the function to call flush_master_info with third parameter
to true, so that the mutex is properly taken.
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.
Until-pos guarding did not distiguish the master originated events from ones that the slave
can introduce to the relay log e.g Rotate to the next relay log at slave restarting.
The local Rotate's coordinate are incomparable with the Until-master-pos.
That led to the unexpectable stop this bug describes.
Fixed with to avoid Until-master-pos comparison for a local slave's event.
Notice that if --replicate-same-server is true such event is treated as coming from
the master side.
mysql-test/r/rpl_until.result:
results changed.
mysql-test/t/rpl_until.test:
regression test for bug#47210 is added.
sql/slave.cc:
st_relay_log_info::is_until_satisfied() is augmented with avoidance of
Until-master-pos comparison for a local slave's event.
if --replicate-same-server is true such event is treated as coming from
the master side.
sql/slave.h:
signature of is_until_satisfied() changed to supply THD and Event to the routine.
Conflicts
=========
Text conflict in .bzr-mysql/default.conf
Text conflict in libmysqld/CMakeLists.txt
Text conflict in libmysqld/Makefile.am
Text conflict in mysql-test/collections/default.experimental
Text conflict in mysql-test/extra/rpl_tests/rpl_row_sp006.test
Text conflict in mysql-test/suite/binlog/r/binlog_tmp_table.result
Text conflict in mysql-test/suite/rpl/r/rpl_loaddata.result
Text conflict in mysql-test/suite/rpl/r/rpl_loaddata_fatal.result
Text conflict in mysql-test/suite/rpl/r/rpl_row_create_table.result
Text conflict in mysql-test/suite/rpl/r/rpl_row_sp006_InnoDB.result
Text conflict in mysql-test/suite/rpl/r/rpl_stm_log.result
Text conflict in mysql-test/suite/rpl_ndb/r/rpl_ndb_circular_simplex.result
Text conflict in mysql-test/suite/rpl_ndb/r/rpl_ndb_sp006.result
Text conflict in mysql-test/t/mysqlbinlog.test
Text conflict in sql/CMakeLists.txt
Text conflict in sql/Makefile.am
Text conflict in sql/log_event_old.cc
Text conflict in sql/rpl_rli.cc
Text conflict in sql/slave.cc
Text conflict in sql/sql_binlog.cc
Text conflict in sql/sql_lex.h
21 conflicts encountered.
NOTE
====
mysql-5.1-rpl-merge has been made a mirror of mysql-next-mr:
- "mysql-5.1-rpl-merge$ bzr pull ../mysql-next-mr"
This is the first cset (merge/...) committed after pulling
from mysql-next-mr.
2630.39.1, 2630.28.29, 2630.34.3, 2630.34.2, 2630.34.1, 2630.29.29,
2630.29.28, 2630.31.1, 2630.28.13, 2630.28.10, 2617.23.14 and
some other minor revisions.
This patch implements:
WL#4264 "Backup: Stabilize Service Interface" -- all the
server prerequisites except si_objects.{h,cc} themselves (they can
be just copied over, when needed).
WL#4435: Support OUT-parameters in prepared statements.
(and all issues in the initial patches for these two
tasks, that were discovered in pushbuild and during testing).
Bug#39519: mysql_stmt_close() should flush all data
associated with the statement.
After execution of a prepared statement, send OUT parameters of the invoked
stored procedure, if any, to the client.
When using the binary protocol, send the parameters in an additional result
set over the wire. When using the text protocol, assign out parameters to
the user variables from the CALL(@var1, @var2, ...) specification.
The following refactoring has been made:
- Protocol::send_fields() was renamed to Protocol::send_result_set_metadata();
- A new Protocol::send_result_set_row() was introduced to incapsulate
common functionality for sending row data.
- Signature of Protocol::prepare_for_send() was changed: this operation
does not need a list of items, the number of items is fully sufficient.
The following backward incompatible changes have been made:
- CLIENT_MULTI_RESULTS is now enabled by default in the client;
- CLIENT_PS_MULTI_RESUTLS is now enabled by default in the client.
include/mysql.h:
Add a new flag to MYSQL_METHODS::flush_use_result
function pointer. This flag determines if all results
should be flushed or only the first one:
- if flush_all_results is TRUE, then cli_flush_use_result()
will read/flush all pending results. I.e. it will read
all packets while server status attribute indicates that
there are more results. This is a new semantic, required
to fix the bug.
- if flush_all_results is FALSE, the old sematic
is preserved -- i.e. cli_flush_use_result() reads data
until first EOF-packet.
include/mysql.h.pp:
Update the ABI with new calls (compatible changes).
include/mysql_com.h:
Add CLIENT_PS_OUT_PARAMS -- a client capability indicating that the client supportsю
libmysql/libmysql.c:
Add mysql_stmt_next_result() -- analogue of mysql_next_result() for binary protocol.
Fix a minor bug in alloc_fields() -- not all members were copied over,
and some only shallow-copied (catalog).
Flush all results in mysql_stmt_close() (Bug#39519).
libmysqld/lib_sql.cc:
Rename send_fields() -> send_result_set_metadata().
Refactoring: change prepare_for_send() so that it accepts only
what it really needs -- a number of elements in the list.
mysql-test/r/ps.result:
Update results: WL#4435.
mysql-test/t/ps.test:
WL#4435: A test case for an SQL-part of the problem.
sql-common/client.c:
Bug#39519.
Implement new functionality in cli_flush_use_result():
if flush_all_delete is TRUE, then it should read/flush
all pending results.
sql/Makefile.am:
Add a new header sql_prepare.h to the list
of build headers.
sql/events.cc:
Rename: Protocol::send_fields() ->
Protocol::send_result_set_metadata().
sql/handler.cc:
Rename: Protocol::send_fields() ->
Protocol::send_result_set_metadata().
sql/mysql_priv.h:
Move sql_prepare.cc-specific declarations to a new
header - sql_prepare.h.
sql/procedure.h:
Rename: Protocol::send_fields() ->
Protocol::send_result_set_metadata().
sql/protocol.cc:
Move the logic responsible for sending of one result
set row to the Protocol class. Define a template
for end-of-statement action.
Refactoring: change prepare_for_send() so that it accepts
only what it really needs -- a number of elements in the list.
Rename send_fields() to send_result_set_metadata().
sql/protocol.h:
Update with new declarations (WL#4435).
Rename send_fields() -> send_result_set_metadata().
prepare_for_send() only needs the number of columns to send,
and doesn't use the item list - update signature to require
only what's needed.
Add a new protocol type -- Protocol_local.
sql/repl_failsafe.cc:
Rename: Protocol::send_fields() ->
Protocol::send_result_set_metadata().
sql/slave.cc:
Rename: Protocol::send_fields() ->
Protocol::send_result_set_metadata().
sql/sql_acl.cc:
Rename: Protocol::send_fields() ->
Protocol::send_result_set_metadata().
sql/sql_base.cc:
Include sql_prepare.h (for Reprepare_observer).
sql/sql_cache.cc:
Extend the query cache flags block to be able
to store a numeric id for the result format,
not just a flag binary/non-binary.
sql/sql_class.cc:
Update to use the rename of Protocol::send_fields()
to Protocol::send_result_set_metadata().
Use Protocol::send_one_result_set_row().
sql/sql_class.h:
Move the declaration of Reprepare_observer to the
new header - sql_prepare.h.
Update to the new signature of class Protocol::send_fields().
sql/sql_connect.cc:
Use a protocol template method instead of
raw NET layer API at the end of a statement.
sql/sql_cursor.cc:
Rename: Protocol::send_fields() ->
Protocol::send_result_set_metadata().
sql/sql_error.cc:
Rename: Protocol::send_fields() ->
Protocol::send_result_set_metadata().
sql/sql_handler.cc:
Rename: Protocol::send_fields() ->
Protocol::send_result_set_metadata().
Use new method Protocol::send_one_result_set_row().
sql/sql_help.cc:
Rename: Protocol::send_fields() ->
Protocol::send_result_set_metadata().
sql/sql_lex.cc:
Initialize multi_statements variable.
Add a handy constant for empty lex
string.
sql/sql_lex.h:
Add a separate member for a standalone
parsing option - multi-statements support.
sql/sql_list.cc:
sql_list.h is a standalone header now,
no need to include mysql_priv.h.
sql/sql_list.h:
Make sql_list.h a stand-alone header.
sql/sql_parse.cc:
Include sql_prepare.h for prepared
statements- related declarations.
Use a new Protocol template method to end
each statement (send OK, EOF or ERROR to
the client).
sql/sql_prepare.cc:
Implement Execute Direct API (WL#4264),
currently unused. It will be used by the service
interface (Backup).
Use a new header - sql_prepare.h.
Add support for OUT parameters in the
binary and text protocol (prepared statements
only).
sql/sql_prepare.h:
Add a new header to contain (for now)
all prepared statement- external
related declarations.
sql/sql_profile.cc:
Rename: Protocol::send_fields() ->
Protocol::send_result_set_metadata().
sql/sql_repl.cc:
Rename: Protocol::send_fields() ->
Protocol::send_result_set_metadata().
sql/sql_select.cc:
Rename: Protocol::send_fields() ->
Protocol::send_result_set_metadata().
sql/sql_show.cc:
Rename: Protocol::send_fields() ->
Protocol::send_result_set_metadata().
sql/sql_string.h:
Add a way to convert a String to LEX_STRING.
sql/sql_table.cc:
Rename: Protocol::send_fields() ->
Protocol::send_result_set_metadata().
sql/sql_update.cc:
Remove an extraneous my_error(). The error
is already reported in update_non_unique_table_error().
sql/sql_yacc.yy:
Support for multi-statements is an independent
property of parsing, not derived from
the protocol type.
tests/mysql_client_test.c:
Add tests for WL#4435 (binary protocol).
Implemented the server infrastructure for the fix:
1. Added a function LEX_STRING *thd_query_string(THD) to return
a LEX_STRING structure instead of char *.
This is the function that must be called in innodb instead of
thd_query()
2. Did some encapsulation in THD : aggregated thd_query and
thd_query_length into a LEX_STRING and made accessor and mutator
methods for easy code updating.
3. Updated the server code to use the new methods where applicable.
The BINLOG statement was sharing too much code with the slave SQL thread, introduced with
the patch for Bug#32407. This caused statements to be logged with the wrong server_id, the
id stored inside the events of the BINLOG statement rather than the id of the running
server.
Fix by rearranging code a bit so that only relevant parts of the code are executed by
the BINLOG statement, and the server_id of the server executing the statements will
not be overrided by the server_id stored in the 'format description BINLOG statement'.
mysql-test/extra/binlog_tests/binlog.test:
Added test to verify if the server_id stored in the 'format
description BINLOG statement' will override the server_id
of the server executing the statements.
mysql-test/suite/binlog/r/binlog_row_binlog.result:
Test result for bug#46640
mysql-test/suite/binlog/r/binlog_stm_binlog.result:
Test result for bug#46640
sql/log_event.cc:
Moved rows_event_stmt_clean() call from update_pos() to apply_event(). This in any case
makes more sense, and is needed as update_pos() is no longer called when executing
BINLOG statements.
Moved setting of rli->relay_log.description_event_for_exec from
Format_description_log_event::do_update_pos() to
Format_description_log_event::do_apply_event()
sql/log_event_old.cc:
Moved rows_event_stmt_clean() call from update_pos() to apply_event(). This in any case
makes more sense, and is needed as update_pos() is no longer called when executing
BINLOG statements.
sql/slave.cc:
The skip flag is no longer needed, as the code path for BINLOG statement has been
cleaned up.
sql/sql_binlog.cc:
Don't invoke the update_pos() code path for the BINLOG statement, as it contains code
that is redundant and/or harmful (especially setting thd->server_id).
mysql-test/suite/rpl/r/rpl_stop_middle_group.result:
the new result file
mysql-test/suite/rpl/t/rpl_stop_middle_group.test:
renamed from rpl_row_stop_middle_update and added a regression test for bug#45940.
There are three internal status for slave I/O thread, both
MYSQL_SLAVE_RUN_NOT_CONNECT and MYSQL_SLAVE_NOT_RUN are reported
as 'No' for Slave_IO_running of command SHOW SLAVE STATUS.
Change MYSQL_SLAVE_RUN_NOT_CONNECT to be reported as 'Connecting'.
NOTE: Backporting the patch to next-mr.
The slave was crashing while failing to execute the init_slave() function.
The issue stems from two different reasons:
1 - A failure while allocating the master info structure generated a
segfault due to a NULL pointer.
2 - A failure while recovering generated a segfault due to a non-initialized
relay log file. In other words, the mi->init and rli->init were both set to true
before executing the recovery process thus creating an inconsistent state as the
relay log file was not initialized.
To circumvent such problems, we refactored the recovery process which is now executed
while initializing the relay log. It is ensured that the master info structure is
created before accessing it and any error is propagated thus avoiding to set mi->init
and rli->init to true when for instance the relay log is not initialized or the relay
info is not flushed.
The changes related to the refactory are described below:
1 - Removed call to init_recovery from init_slave.
2 - Changed the signature of the function init_recovery.
3 - Removed flushes. They are called while initializing the relay log and master
info.
4 - Made sure that if the relay info is not flushed the mi-init and rli-init are not
set to true.
In this patch, we also replaced the exit(1) in the fault injection by DBUG_ABORT()
to make it compliant with the code guidelines.
On Mac OS X or Windows, sending a SIGHUP to the server or a
asynchronous flush (triggered by flush_time), would cause the
server to crash.
The problem was that a hook used to detach client API handles
wasn't prepared to handle cases where the thread does not have
a associated session.
The solution is to verify whether the thread has a associated
session before trying to detach a handle.
mysql-test/r/federated_debug.result:
Add test case result for Bug#47525
mysql-test/t/federated_debug-master.opt:
Debug point.
mysql-test/t/federated_debug.test:
Add test case for Bug#47525
sql/slave.cc:
Check whether a the thread has a associated session.
sql/sql_parse.cc:
Add debug code to simulate a reload without thread session.
NOTE: Backporting the patch to next-mr.
The fix proposed in BUG#35542 and BUG#31665 introduces a performance issue
when fsyncing the master.info, relay.info and relay-log.bin* after #th events.
Although such solution has been proposed to reduce the probability of corrupted
files due to a slave-crash, the performance penalty introduced by it has
made the approach impractical for highly intensive workloads.
In a nutshell, the option --syn-relay-log proposed in BUG#35542 and BUG#31665
simultaneously fsyncs master.info, relay-log.info and relay-log.bin* and
this is the main source of performance issues.
This patch introduces new options that give more control to the user on
what should be fsynced and how often:
1) (--sync-master-info, integer) which syncs the master.info after #th event;
2) (--sync-relay-log, integer) which syncs the relay-log.bin* after #th
events.
3) (--sync-relay-log-info, integer) which syncs the relay.info after #th
transactions.
To provide both performance and increased reliability, we recommend the following
setup:
1) --sync-master-info = 0 eventually the operating system will fsync it;
2) --sync-relay-log = 0 eventually the operating system will fsync it;
3) --sync-relay-log-info = 1 fsyncs it after every transaction;
Notice, that the previous setup does not reduce the probability of
corrupted master.info and relay-log.bin*. To overcome the issue, this patch also
introduces a recovery mechanism that right after restart throws away relay-log.bin*
retrieved from a master and updates the master.info based on the relay.info:
4) (--relay-log-recovery, boolean) which enables a recovery mechanism that
throws away relay-log.bin* after a crash.
However, it can only recover the incorrect binlog file and position in master.info,
if other informations (host, port password, etc) are corrupted or incorrect,
then this recovery mechanism will fail to work.
when compiled with Sun Studio compiler).
The thing is that Sun Studio compiler calls destructor of stack
objects when pthread_exit() is called. That triggered an assertion
in DBUG_ENTER()/DBUG_RETURN() validation logic (if DBUG_ENTER() is
used in the beginning of function, all returns should be replaced
by DBUG_RETURN/DBUG_VOID_RETURN macros).
A fix is to explicitly use DBUG_LEAVE macro.
But there is no Last_IO_Error reported.
On the master, if a binary log event is larger than max_allowed_packet,
ER_MASTER_FATAL_ERROR_READING_BINLOG and the specific reason of this error is
sent to a slave when it requests a dump from the master, thus leading
the I/O thread to stop.
On a slave, the I/O thread stops when receiving a packet larger than max_allowed_packet.
In both cases, however, there was no Last_IO_Error reported.
This patch adds code to report the Last_IO_Error and exact reason before stopping the
I/O thread and also reports the case the out memory pops up while
handling packets from the master.
sql/sql_repl.cc:
The master send the Specific reasons instead of "error reading log entry" to the slave which is requesting a dump.
if an fatal error is returned by read_log_event function.
If the SQL Thread fails to execute an event due to a temporary error (e.g.
ER_LOCK_DEADLOCK) and the option "--slave_transaction_retries" is set the SQL
Thread should not be aborted and the transaction should be restarted from the
beginning and re-executed.
Unfortunately, a wrong interpretation of the THD::is_fatal_error was preventing
this behavior. In a nutshell, "this variable is set to TRUE if an execution of a
compound statement cannot continue. In particular, it is used to disable access
to the CONTINUE or EXIT handlers of stored routines. So even temporary errors
may have this variable set.
To fix the bug, we have done what follows:
DBUG_ENTER("has_temporary_error");
- if (thd->is_fatal_error)
- DBUG_RETURN(0);
-
DBUG_EXECUTE_IF("all_errors_are_temporary_errors",
if (thd->main_da.is_error())
{
Bug#45243: crash on win in sql thread clear_tables_to_lock() -> free()
Bug#45242: crash on win in mysql_close() -> free()
Bug#45238: rpl_slave_skip, rpl_change_master failed (lost connection) for STOP SLAVE
Bug#46030: rpl_truncate_3innodb causes server crash on windows
Bug#46014: rpl_stm_reset_slave crashes the server sporadically in pb2
When killing a user session on the server, it's necessary to
interrupt (notify) the thread associated with the session that
the connection is being killed so that the thread is woken up
if waiting for I/O. On a few platforms (Mac, Windows and HP-UX)
where the SIGNAL_WITH_VIO_CLOSE flag is defined, this interruption
procedure is to asynchronously close the underlying socket of
the connection.
In order to enable this schema, each connection serving thread
registers its VIO (I/O interface) so that other threads can
access it and close the connection. But only the owner thread of
the VIO might delete it as to guarantee that other threads won't
see freed memory (the thread unregisters the VIO before deleting
it). A side note: closing the socket introduces a harmless race
that might cause a thread attempt to read from a closed socket,
but this is deemed acceptable.
The problem is that this infrastructure was meant to only be used
by server threads, but the slave I/O thread was registering the
VIO of a mysql handle (a client API structure that represents a
connection to another server instance) as a active connection of
the thread. But under some circumstances such as network failures,
the client API might destroy the VIO associated with a handle at
will, yet the VIO wouldn't be properly unregistered. This could
lead to accesses to freed data if a thread attempted to kill a
slave I/O thread whose connection was already broken.
There was a attempt to work around this by checking whether
the socket was being interrupted, but this hack didn't work as
intended due to the aforementioned race -- attempting to read
from the socket would yield a "bad file descriptor" error.
The solution is to add a hook to the client API that is called
from the client code before the VIO of a handle is deleted.
This hook allows the slave I/O thread to detach the active vio
so it does not point to freed memory.
server-tools/instance-manager/mysql_connection.cc:
Add stub method required for linking.
sql-common/client.c:
Invoke hook.
sql/client_settings.h:
Export hook.
sql/slave.cc:
Introduce hook that clears the active VIO before it is freed
by the client API.
procedures causes crashes!
The problem of that bugreport was mostly fixed by the
patch for bug 38691.
However, attached test case focused on another crash or
valgrind warning problem: SHOW PROCESSLIST query accesses
freed memory of SP instruction that run in a parallel
connection.
Changes of thd->query/thd->query_length in dangerous
places have been guarded with the per-thread
LOCK_thd_data mutex (the THD::LOCK_delete mutex has been
renamed to THD::LOCK_thd_data).
sql/ha_myisam.cc:
Bug #38816: kill + flush tables with read lock + stored
procedures causes crashes!
Modification of THD::query/query_length has been guarded
with the a THD::set_query() method call/LOCK_thd_data
mutex.
Unnecessary locking with the global LOCK_thread_count
mutex has been removed.
sql/log_event.cc:
Bug #38816: kill + flush tables with read lock + stored
procedures causes crashes!
Modification of THD::query/query_length has been guarded
with the THD::set_query()) method call/LOCK_thd_data
mutex.
sql/slave.cc:
Bug #38816: kill + flush tables with read lock + stored
procedures causes crashes!
Modification of THD::query/query_length has been guarded
with the THD::set_query() method call/LOCK_thd_data mutex.
The THD::LOCK_delete mutex has been renamed to
THD::LOCK_thd_data.
sql/sp_head.cc:
Bug #38816: kill + flush tables with read lock + stored
procedures causes crashes!
Modification of THD::query/query_length has been guarded
with the a THD::set_query() method call/LOCK_thd_data
mutex.
sql/sql_class.cc:
Bug #38816: kill + flush tables with read lock + stored
procedures causes crashes!
The new THD::LOCK_thd_data mutex and THD::set_query()
method has been added to guard modifications of THD::query/
THD::query_length fields, also the Statement::set_statement()
method has been overloaded in the THD class.
The THD::LOCK_delete mutex has been renamed to
THD::LOCK_thd_data.
sql/sql_class.h:
Bug #38816: kill + flush tables with read lock + stored
procedures causes crashes!
The new THD::LOCK_thd_data mutex and THD::set_query()
method has been added to guard modifications of THD::query/
THD::query_length fields, also the Statement::set_statement()
method has been overloaded in the THD class.
The THD::LOCK_delete mutex has been renamed to
THD::LOCK_thd_data.
sql/sql_insert.cc:
Bug #38816: kill + flush tables with read lock + stored
procedures causes crashes!
Modification of THD::query/query_length has been guarded
with the a THD::set_query() method call/LOCK_thd_data
mutex.
sql/sql_parse.cc:
Bug #38816: kill + flush tables with read lock + stored
procedures causes crashes!
Modification of THD::query/query_length has been guarded
with the a THD::set_query() method call/LOCK_thd_data mutex.
sql/sql_repl.cc:
Bug #38816: kill + flush tables with read lock + stored
procedures causes crashes!
The THD::LOCK_delete mutex has been renamed to
THD::LOCK_thd_data.
sql/sql_show.cc:
Bug #38816: kill + flush tables with read lock + stored
procedures causes crashes!
Inter-thread read of THD::query/query_length field has
been protected with a new per-thread LOCK_thd_data
mutex in the mysqld_list_processes function.
The "get_master_version_and_clock(...)" function in sql/slave.cc ignores
error and passes directly when queries fail, or queries succeed
but the result retrieved is empty.
The "get_master_version_and_clock(...)" function should try to reconnect master
if queries fail because of transient network problems, and fail otherwise.
The I/O thread should print a warning if the some system variables do not
exist on master (very old master)
mysql-test/extra/rpl_tests/rpl_get_master_version_and_clock.test:
Added test file for bug #45214
mysql-test/suite/rpl/r/rpl_get_master_version_and_clock.result:
Added test result for bug #45214
mysql-test/suite/rpl/t/rpl_get_master_version_and_clock.test:
Added test file for bug #45214
sql/slave.cc:
The 'is_network_error()' function is added for checking if the error is caused by network.
Added a new return value (2) to 'get_master_version_and_clock()' function result set
to indicate transient network errors when queries fail, and the caller should
try to reconnect in this case.
timeout
In STMT and MIXED modes, a statement that changes both non-transactional and
transactional tables must be written to the binary log whenever there are
changes to non-transactional tables. This means that the statement gets into the
binary log even when the changes to the transactional tables fail. In particular
, in the presence of a failure such statement is annotated with the error number
and wrapped in a begin/rollback. On the slave, while applying the statement, it
is expected the same failure and the rollback prevents the transactional changes
to be persisted.
Unfortunately, statements that fail due to concurrency issues (e.g. deadlocks,
timeouts) are logged in the same way causing the slave to stop as the statements
are applied sequentially by the SQL Thread. To fix this bug, we automatically
ignore concurrency failures on the slave. Specifically, the following failures
are ignored: ER_LOCK_WAIT_TIMEOUT, ER_LOCK_DEADLOCK and ER_XA_RBDEADLOCK.
The reason for the crash was rotate_relay_log (mi=0x0) did not verify
the passed value of active_mi. There are more cases where active_mi
is supposed to be non-zero e.g change_master(), stop_slave(), and it's
reasonable to protect from a similar crash all of them with common
fixes.
Fixed with spliting end_slave() in slave threads release and slave
data clean-up parts (a new close_active_mi()). The new function is
invoked at the very end of close_connections() so that all users of
active_mi are proven to have left.
sql/mysqld.cc:
added the 2nd part (data) of the slave's clean up.
sql/slave.cc:
end_slave() is split in two part to release the slave threads and the remained
resources separately.
The new close_active_mi() should be called after all possible users ofactive_mi
has left, i.e at the very end of close_connections().
sql/slave.h:
interface to the new end_active_mi() function is added.
with gcc 4.3.2
Compiling MySQL with gcc 4.3.2 and later produces a number of
warnings, many of which are new with the recent compiler
versions.
This bug will be resolved in more than one patch to limit the
size of changesets. This is the first patch, fixing a number
of the warnings, predominantly "suggest using parentheses
around && in ||", and empty for and while bodies.
with gcc 4.3.2
Compiling MySQL with gcc 4.3.2 and later produces a number of
warnings, many of which are new with the recent compiler
versions.
This bug will be resolved in more than one patch to limit the
size of changesets. This is the first patch, fixing a number
of the warnings, predominantly "suggest using parentheses
around && in ||", and empty for and while bodies.
The server was not cleaning the last IO error and error number when
resetting slave.
This patch addresses this issue by backporting into 5.1 part of the
patch in BUG 34654. A fix for this issue had already been pushed into
6.0 as part of the aforementioned bug, however the patch also included
some refactoring. The fix for 5.1 does not take into account the
refactoring part.
mysql-test/extra/rpl_tests/rpl_reset_slave.test:
Backported the test case and improved with deploying include/start_slave.inc
in relevant spots.
sql/slave.cc:
Backported part of patch from 6.0 that includes cleaning
mi->clear_error() at:
1. beginning of handle_slave_io
2. on successful connection
Also, backported the assertion added in the original patch.
sql/sql_repl.cc:
Backported the call to mi->clear_error() on reset_slave().
