Commit graph

58207 commits

Author SHA1 Message Date
Sven Sandberg
00a65bd421 BUG#39934 - post-push fixes.
The rpl_ndb/combinations file was introduced as part of the fix.
The file contained an error: ndb suites shall not run with
binlog_format=mixed. Removed that combination.
2009-10-19 10:52:14 +02:00
Sven Sandberg
7890e8b66d BUG#39934: Slave stops for engine that only support row-based logging
post-push fixes. the test case tried to use a udf that had not been loaded. removed the udf.
2009-10-19 10:26:22 +02:00
He Zhenxing
ae107c5581 Manual merge 5.1-rep+2 to 5.1-rep+3 2009-10-18 11:57:38 +08:00
Sven Sandberg
73b296c4c4 BUG#39934: Slave stops for engine that only support row-based logging
Post-push fix.
Problem: After the original bugfix, if a statement is unsafe,
binlog_format=mixed, and engine is statement-only, a warning was
generated and the statement executed. However, it is a fundamental
principle of binlogging that binlog_format=mixed should guarantee
correct logging, no compromise. So correct behavior is to generate
an error and don't execute the statement.
Fix: Generate error instead of warning.
Since issue_unsafe_warnings can only generate one error message,
this allows us to simplify the code a bit too:
decide_logging_format does not have to save the error code for
issue_unsafe_warnings
2009-10-14 18:32:08 +02:00
He Zhenxing
c1584c9801 Postfix after merge semi-sync with heartbeat
Use ev_offset instead of 1 as the packet header offset when getting
log position from events for heartbeat

call reset_transmit_packet before calling send_heartbeat_event
2009-10-14 13:24:47 +08:00
He Zhenxing
b289e515aa Auto merge 5.1-rep-semisync 2009-10-13 10:28:02 +08:00
He Zhenxing
dab1162b53 Backport post fix for semisync
Remove functions that no longer needed
Fix warning suppressions
2009-10-12 21:21:13 +08:00
He Zhenxing
b92ec52915 Backport BUG#47298 Semisync: always wait until timeout if no semi-sync slave available
Add an option to control whether the master should keep waiting
until timeout when it detected that there is no semi-sync slave
available.

The bool option 'rpl_semi_sync_master_wait_no_slave' is 1 by
defalt, and will keep waiting until timeout. When set to 0, the
master will switch to asynchronous replication immediately when
no semi-sync slave is available.
2009-10-12 21:15:32 +08:00
He Zhenxing
64fc766c93 BUG#45674 FLUSH STATUS does not reset semisynchronous counters
Semi-sync status were not reset by FLUSH STATUS, this was because
all semi-sync status variables are defined as SHOW_FUNC and FLUSH
STATUS could only reset SHOW_LONG type variables.

This problem is fixed by change all status variables that should
be reset by FLUSH STATUS from SHOW_FUNC to SHOW_LONG.

After the fix, the following status variables will be reset by
FLUSH STATUS:
  Rpl_semi_sync_master_yes_tx
  Rpl_semi_sync_master_no_tx

Note: normally, FLUSH STATUS itself will be written into binlog
and be replicated, so after FLUSH STATS, one of
  Rpl_semi_sync_master_yes_tx
  Rpl_semi_sync_master_no_tx
can be 1 dependent on the semi-sync status. So it's recommended
to use FLUSH NO_WRITE_TO_BINLOG STATUS to avoid this.
2009-10-12 21:03:04 +08:00
He Zhenxing
7d3d0fc303 Backport Bug#45852 Semisynch: Last_IO_Error: Fatal error: Failed to run 'after_queue_event' hook
Errors when send reply to master should never cause the IO thread
to stop, because master can fall back to async replication if it
does not get reply from slave.

The problem is fixed by deliberately ignoring the return value of
slaveReply.
2009-10-12 20:57:30 +08:00
He Zhenxing
55842061e7 Backport BUG#45848 Semisynchronous replication internals are visible in SHOW PROCESSLIST and logs
Semi-sync uses an extra connection from slave to master to send
replies, this is a normal client connection, and used a normal
SET query to set the reply information on master, which is visible
to user and may cause some confusion and complaining.

This problem is fixed by using the method of sending reply by
using the same connection that is used by master dump thread to
send binlog to slave. Since now the semi-sync plugins are integrated
with the server code, it is not a problem to use the internal net
interfaces to do this.

The master dump thread will mark the event requires a reply and
wait for the reply when the event just sent is the last event
of a transaction and semi-sync status is ON; And the slave will
send a reply to master when it received such an event that requires
a reply.
2009-10-12 20:55:01 +08:00
Serge Kozlov
2151a821aa Bug#42891: Tests cleanup
Fix for backport into mysql-5.1-rep+2
2009-10-10 14:27:07 +04:00
Andrei Elkin
124ad21d01 backporting fixes of bug@45940 to 5.1-rpl+2 to cover failures rpl_heartbeat_* as well. 2009-10-09 16:26:37 +03:00
Luis Soares
75a4dd3e6a BUG#40611, BUG#44779: reverted in mysql-5.1-rep+2. 2009-10-07 22:13:07 +01:00
Serge Kozlov
6507f04de2 WL#4641, Bug#43828: fix for rpl_heartbeat_basic.test:
The issue appears when number of heartbeat events non-zero before start of test
block. But really we need to check that no new events has received during test block.
So I did following:
1. Replace absolute values by diff of values
2. Increase heartbeat period from 1.5 to 5 sec
2009-10-07 19:44:01 +04:00
Andrei Elkin
e4abe4eb3c correcting rpl_partition.result 2009-10-07 01:05:27 +03:00
Serge Kozlov
d77bd29c69 WL#3788
It is backport patch.
This adds new test case for testing affects of some variables to replication.
2009-10-03 22:21:44 +04:00
He Zhenxing
62d218edfe Manual merge semi-sync to 5.1-rep+2 2009-10-03 18:50:25 +08:00
He Zhenxing
d8b4e637a0 Fix semisync master/slave status always showed as OFF on sparc
On sparc, semisync master/slave status is always showed as OFF, this
is fixed by change rpl_semisync_master/slave_status variables from
long to char.
2009-10-03 13:00:05 +08:00
He Zhenxing
e9ba06009d Auto merge 2009-10-03 10:07:03 +08:00
He Zhenxing
ab6d244f51 Post fix result file 2009-10-03 09:40:32 +08:00
Serge Kozlov
87a5e68634 WL#4641 Heartbeat testing
This is backport for next-mr.

The patch adds new test cases that cover replication heartbeat testing.
2009-10-02 23:24:40 +04:00
Andrei Elkin
d0c5656eb8 fixing tests results: rpl_ndb_log, rpl_ndb_multi, sp_trans_log; adding replicate-ignore_server_ids specific tests 2009-10-02 16:15:54 +03:00
He Zhenxing
04c6e8ff07 Post fix SEMISYNC_PLUGIN_OPT when semi-sync plugins are not found 2009-10-02 19:16:06 +08:00
He Zhenxing
0ec47798fd Backport fixes for the follow tests
binlog_tmp_table
rpl_row_sp006_InnoDB
rpl_slave_status
2009-10-02 17:24:21 +08:00
He Zhenxing
fa7395c9a1 Backport Post fix of result files after push of BUG#34227 2009-10-02 17:12:10 +08:00
He Zhenxing
1b3300d5e9 Backport BUG#34227 Replication permission error message is misleading
According to Jon's comment, add (at least one of) to the error message.
2009-10-02 16:50:05 +08:00
He Zhenxing
b92d459d11 Backport post fix compiler warnings and test failures for BUG#25192 BUG#12190 2009-10-02 16:40:06 +08:00
He Zhenxing
79faadd54d Backport BUG#12190 CHANGE MASTER has differ path requiremts on MASTER_LOG_FILE and RELAY_LOG_FILE
CHANGE MASTER TO command required the value for RELAY_LOG_FILE to
be an absolute path, which was different from the requirement of
MASTER_LOG_FILE.

This patch fixed the problem by changing the value for RELAY_LOG_FILE
to be the basename of the log file as that for MASTER_LOG_FILE.
2009-10-02 16:35:03 +08:00
He Zhenxing
86c36aa1fd Backport BUG#25192 Using relay-log and relay-log-index without values produces unexpected results.
Options loaded from config files were added before command line
arguments, and they were parsed together, which could interprete
the following:
option-a
option-b
as --option-a=--option-b if 'option-a' requires a value, and 
caused confusing.

Because all options that requires a value are always given in
the form '--option=value', so it's an error if there is no 
'=value' part for such an option read from config file.

This patch added a separator to separate the arguments from 
config files and that from command line, so that they can be
handled differently. And report an error for options loaded
from config files that requires a value and is not given in the
form '--option=value'.
2009-10-02 16:25:53 +08:00
He Zhenxing
4354cfd404 Backport BUG#38468 Memory leak detected when using mysqlbinlog utility
There were two memory leaks in mysqlbinlog command, one was already
fixed by previous patches, another one was that defaults_argv was
set to the value of argv after parse_args, in which called
handle_options after calling load_defaults and changed the value
of argv, and caused the memory allocated for defaults arguments
not freed.

Fixed the problem by setting defaults_argv right after calling
load_defaults.
2009-10-02 16:18:40 +08:00
He Zhenxing
494adde6fb Backport BUG#41613 Slave I/O status inconsistent between SHOW SLAVE STATUS and START SLAVE
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'.
2009-10-02 16:07:33 +08:00
He Zhenxing
c1e2b14714 Backport BUG#41013 main.bootstrap coredumps in 6.0-rpl
When a storage engine failed to initialize before allocated slot number,
the slot number would be 0, and when later finalizing this plugin, it would
accidentally unplug the storage engine currently uses slot 0.

This patch fixed this problem by add a new macro value HA_SLOT_UNDEF to
distinguish undefined slot number from slot 0.
2009-10-02 13:59:42 +08:00
He Zhenxing
15c63309d4 Post fix backporting wl#1720
Fix mtr semisync plugin option paths
2009-10-02 12:11:50 +08:00
Andrei Elkin
6d1ad12428 merge from 5.1-rpl+2 repo to a local branch with HB and bug@27808 fixes 2009-10-01 20:22:44 +03:00
Andrei Elkin
f68119a745 backporting bug@27808 fixes 2009-10-01 19:44:53 +03:00
Luis Soares
266d53b5d2 Partial backport for BUG#41399, more precisely, the changes to
wait_until_disconnected.inc.
2009-10-01 00:32:15 +01:00
Alfranio Correia
9682ff8a26 BUG#43075 rpl.rpl_sync fails sporadically on pushbuild
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.
2009-09-30 22:41:05 +01:00
Luis Soares
959d147716 Fixes tree_name for tree mysql-5.1-rep+3. 2009-09-30 17:53:58 +01:00
Luis Soares
9581d6280e BUG#47749: rpl_slave_skip fails sporadically on PB2 (mysql-5.1-rep+2 tree).
rpl_slave_skip fails randomly on PB2. This patch fixes the failure by
setting explicit wait for SQL thread to stop, instead of the 
wait_for_slave_to_stop mysqltest command, after a start until command 
is executed.
2009-09-30 17:42:25 +01:00
Sven Sandberg
430cf40425 post-merge fixes to make tests pass after merging BUG#39934 to 5.1-rep+3. 2009-09-30 18:20:52 +02:00
Sven Sandberg
31193a632e merged fixes for BUG#39934 to 5.1-rpl+3
Also renamed current_stmt_binlog_row_based to
current_stmt_binlog_format_row for consistency
2009-09-30 18:00:22 +02:00
Alfranio Correia
2108eea562 BUG#47741 rpl_ndb_extraCol fails in next-mr (mysql-5.1-rep+2) in RBR
This is a temporary fix.

NOTE: Backporting the patch to next-mr.
2009-09-30 16:25:01 +01:00
Alfranio Correia
47599b5db2 Post-fix for BUG#43789
NOTE: Backporting the patch to next-mr.
2009-09-30 15:17:15 +01:00
Luis Soares
19e6d1c596 Automerge: mysql-5.1-rep+2 (local backports) --> mysql-5.1-rep+2 (local latest) 2009-09-30 12:48:22 +01:00
He Zhenxing
b3ece14b3a Backporting BUG#40244 Optimized build of mysqld crashes when built with Sun Studio on SPARC 2009-09-30 19:36:35 +08:00
He Zhenxing
7771b90295 Back porting the test case for semi-sync 2009-09-30 16:09:31 +08:00
Alfranio Correia
a48ff22004 BUG#40337 Fsyncing master and relay log to disk after every event is too slow
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.
2009-09-29 15:40:52 +01:00
Alfranio Correia
4e0cb6dbb7 BUG#35542 Add option to sync master and relay log to disk after every event
BUG#31665 sync_binlog should cause relay logs to be synchronized

NOTE: Backporting the patch to next-mr.
      
Add sync_relay_log option to server, this option works for relay log 
the same as option sync_binlog for binlog. This option also synchronize
master info to disk when set to non-zero value.
            
Original patches from Sinisa and Mark, with some modifications
2009-09-29 15:27:12 +01:00
Alfranio Correia
63278c561c BUG#43789 different master/slave table defs cause crash: text/varchar null
vs not null

NOTE: Backporting the patch to next-mr.
                        
The replication was generating corrupted data, warning messages on Valgrind
and aborting on debug mode while replicating a "null" to "not null" field.
Specifically the unpack_row routine, was considering the slave's table
definition and trying to retrieve a field value, where there was nothing to be
retrieved, ignoring the fact that the value was defined as "null" by the master.
                        
To fix the problem, we proceed as follows:
                        
1 - If it is not STRICT sql_mode, implicit default values are used, regardless
if it is multi-row or single-row statement.
                        
2 - However, if it is STRICT mode, then a we do what follows:
                        
2.1 If it is a transactional engine, we do a rollback on the first NULL that is
to be set into a NOT NULL column and return an error.
                        
2.2 If it is a non-transactional engine and it is the first row to be inserted
with multi-row, we also return the error. Otherwise, we proceed with the
execution, use implicit default values and print out warning messages.
                  
Unfortunately, the current patch cannot mimic the behavior showed by the master
for updates on multi-tables and multi-row inserts. This happens because such
statements are unfolded in different row events. For instance, considering the
following updates and strict mode:
                  
(master)
create table t1 (a int);
create table t2 (a int not null);
insert into t1 values (1);
insert into t2 values (2);
update t1, t2 SET t1.a=10, t2.a=NULL;
                  
t1 would have (10) and t2 would have (0) as this would be handled as a
multi-row update. On the other hand, if we had the following updates:
                  
(master)
create table t1 (a int);
create table t2 (a int);
                  
(slave)
create table t1 (a int);
create table t2 (a int not null);
                  
(master)
insert into t1 values (1);
insert into t2 values (2);
update t1, t2 SET t1.a=10, t2.a=NULL;
                  
On the master t1 would have (10) and t2 would have (NULL). On
the slave, t1 would have (10) but the update on t1 would fail.
2009-09-29 15:18:44 +01:00