Commit graph

1259 commits

Author SHA1 Message Date
Nuno Carvalho
61827c669f WL#7266: Dump-thread additional concurrency tests
Merge from mysql-5.1 into mysql-5.5.
2013-10-14 15:51:09 +01:00
Nuno Carvalho
3399194cef WL#7266: Dump-thread additional concurrency tests
This worklog aims at testing the two following scenarios:

1) Whenever the mysql_binlog_send method (dump thread)
reaches the end of file when reading events from the binlog, before
checking if it should wait for more events, there was a test to
check if the file being read was still active, i.e, it was the last
known binlog. However, it was possible that something was written to
the binary log and then a rotation would happen, after EOF was
detected and before the check for active was performed. In this
case, the end of the binary log would not be read by the dump
thread, and this would cause the slave to lose updates.
This test verifies that the problem has been fixed. It waits during
this window while forcing a rotation in the binlog.

2) Verify dump thread can send events in active file, correctly after
encountering an IO error.
2013-10-14 15:45:12 +01:00
Shivji Kumar Jha
d4011a6144 BUG#16580366- MTR TESTS FAILING SPORADICALLY ON PB2 (5.5, 5.6 AND 5.7)
DURING INNODB RECOVERY

Problem:
=======
The connection 'master' is dropped by mysqltest after
rpl_end.inc. At this point, dropping temporary tables
at the connection 'master' are not synced at slave.
So, the temporary tables replicated from master remain
on slave leading to an inconsistent close of the test.
The following test thus complains about the presence of
temporary table(s) left over from the previous test.

Fix:
===
- Put explicit drop commands in replication tests so
  that the temporary tables are dropped at slave as well.
- Added the check for Slave_open_temp_tables in
  mtr_check.sql to warn about the remaining temporary
  table, if any, at the close of a test.
2013-09-27 01:24:16 +05:30
Libing Song
aff9f26290 Bug#17402313 DUMP THREAD SENDS SOME EVENTS MORE THAN ONCE
Postfix, suppress the new warning generated by the bug's fix.
2013-09-10 16:12:25 +08:00
Venkatesh Duggirala
eb152f86af BUG#16290902 DROP TEMP TABLE IF EXISTS CAN CAUSE POINT
IN TIME RECOVERY FAILURE ON SLAVES

Problem:
DROP TEMP TABLE IF EXISTS commands can cause point
in time recovery (re-applying binlog) failures.

Analyses:
In RBR, 'DROP TEMPORARY TABLE' commands are
always binlogged by adding 'IF EXISTS' clauses.
Also, the slave SQL thread will not check replicate.* filter
rules for "DROP TEMPORARY TABLE IF EXISTS" queries.
If log-slave-updates is enabled on slave, these queries
will be binlogged in the format of "USE `db`;
DROP TEMPORARY TABLE IF EXISTS `t1`;" irrespective
of filtering rules and irrespective of the `db` existence.
When users try to recover slave from it's own binlog,
use `db` command might fail if `db` is not present on slave.

Fix:
At the time of writing the 'DROP TEMPORARY TABLE
IF EXISTS' query into the binlog, 'use `db`' will not be
present and the table name in the query will be a fully
qualified table name.
Eg:
'USE `db`; DROP TEMPORARY TABLE IF EXISTS `t1`;'
will be logged as
'DROP TEMPORARY TABLE IF EXISTS `db`.`t1`;'.
2013-07-27 17:35:02 +05:30
Sujatha Sivakumar
e3c201d705 Merge from mysql-5.1 to mysql-5.5 2013-03-27 11:59:40 +05:30
Sujatha Sivakumar
0e763f4db5 Bug#11829838: ALTER TABLE NOT BINLOGGED WITH
--BINLOG-IGNORE-DB AND FULLY QUALIFIED TABLE
      
Problem:
=======
An ALTER TABLE statement is not written to binlog if server
started with "--binlog-ignore-db some database" and 'fully
qualified' table names are used in the ALTER TABLE statement
altering table different from current database context.
      
Analysis:
========
The above mentioned problem not only affects "ALTER TABLE"
statements but also to all kind of statements. Once the 
current default database becomes "NULL" none of the 
statements will be binlogged.
      
The current behaviour is such that if the user has specified
restrictions on which database needs to be replicated and the
default db is not specified, then do not replicate.
This means that "NULL" is considered to be equivalent to
everything (default db = null implied ignore don't log the
statement).
      
Fix:
===
"NULL" should not be considered as equivalent to everything.
Since the filtering criteria is not equal to "NULL" the
statement should be logged into binlog.

mysql-test/suite/rpl/r/rpl_loaddata_m.result:
  Earlier when defalut database was "NULL" DROP TABLE
  was not getting logged. Post this fix it will be logged
  and the DROP will fail at slave as the table creation
  was skipped by master as --binlog-ignore-db=test.
mysql-test/suite/rpl/t/rpl_loaddata_m.test:
  Earlier when defalut database was "NULL" DROP TABLE
  was not getting logged. Post this fix it will be logged
  and the DROP will fail at slave as the table creation
  was skipped by master as --binlog-ignore-db=test.
sql/rpl_filter.cc:
  Replaced DBUG_RETURN(0) with DBUG_RETURN(1).
2013-03-27 11:53:01 +05:30
Shivji Kumar Jha
85c299dd98 BUG#15965353- RPL.RPL_ROW_UNTIL FAILS ON PB2,
PLATFORM= MACOSX10.6 X86_64 MAX

            post push fix
2013-02-19 01:58:57 +05:30
Shivji Kumar Jha
ae5951d395 BUG#15965353- RPL.RPL_ROW_UNTIL FAILS ON PB2,
PLATFORM= MACOSX10.6 X86_64 MAX

bzr merge 5.1=>5.5
2013-02-17 01:45:10 +05:30
Shivji Kumar Jha
5fcf40a2aa BUG#15965353- RPL.RPL_ROW_UNTIL FAILS ON PB2,
PLATFORM= MACOSX10.6 X86_64 MAX

Problem: The test was failing on pb2's mac machine because
         it was not cleaned up properly. The test checks if
         the command 'start slave until' throws a proper
         error when issued with a wrong number/type of
         parameters. After this,the replication stream was
         stopped using the include file 'rpl_end.inc'.
         The errors thrown earlier left the slave in an
         inconsistent state to be closed by the include
         file which was caught by the mac machine.

Fix: Started slave by invoking start_slave.inc to have a
     working slave before calling rpl_reset.inc

Problem: The test file was not in a good shape. It tested
         start slave until relay log file/pos combination 
         wrongly. A couple of commands were executed at 
         master and replicated at slave. Next, the 
         coordinates in terms of relay log file and pos 
         were noted down followed by reset slave and start
         slave until saved relay log file/pos. Reset slave
         deletes  all relay log files and makes the slave 
         forget its replication position. So, using the 
         saved coordiantes after reset slave is wrong.

Fix: Split the test in two parts:
     a) Test for start slave until master log file/pos and
        checking for correct errors in the failure 
        scenarios.
     b) Test for start slave until relay log file/pos.

Problem: The variables auto_increment_increment and 
         auto_increment_offset were set in the the include
         file rpl_init.inc. This was only configured for 
         some connections that are rarely used by test 
         cases, so likely that it will cause confusion. 
         If replication tests want to setup these variables
         they should do so explicitly.

Fix:
     a) Removed code to set the variables
        auto_increment_increment and auto_increment_offset
        in the include file.
     b) Updated tests files using the same.
2013-02-17 01:42:28 +05:30
Shivji Kumar Jha
a6a86f8880 BUG#12359942- REPLICATION TEST FROM ENGINE SUITE RPL_ROW_UNTIL TIMES OUT
post push fix: 
rpl_stm_until.test was disabled because of
this bug. Enabled and fixed it.

Removed a part of the test that was obsolete.
It tested replication from 4.0 master to 5.0
slave.
2013-02-15 00:40:32 +05:30
Shivji Kumar Jha
eb3814b0b3 BUG#12359942- REPLICATION TEST FROM ENGINE SUITE RPL_ROW_UNTIL TIMES OUT
post push fix: 
rpl_stm_until.test was disabled because of
this bug. Enabled and fixed it.

Removed a part of the test that was obsolete.
It tested replication from 4.0 master to 5.0
slave.
2013-02-15 00:38:42 +05:30
Mattias Jonsson
e96182824d Bug#16274455: CAN NOT ACESS PARTITIONED TABLES WHEN
DOWNGRADED FROM 5.6.11 TO 5.6.10

Problem was new syntax not accepted by previous version.

Fixed by adding version comment of /*!50531 around the
new syntax.

Like this in the .frm file:
'PARTITION BY KEY /*!50611 ALGORITHM = 2 */ () PARTITIONS 3'
and also changing the output from SHOW CREATE TABLE to:
CREATE TABLE t1 (a INT)
/*!50100 PARTITION BY KEY */ /*!50611 ALGORITHM = 1 */ /*!50100 ()
PARTITIONS 3 */

It will always add the ALGORITHM into the .frm for KEY [sub]partitioned
tables, but for SHOW CREATE TABLE it will only add it in case it is the non
default ALGORITHM = 1.

Also notice that for 5.5, it will say /*!50531 instead of /*!50611, which
will make upgrade from 5.5 > 5.5.31 to 5.6 < 5.6.11 fail!
If one downgrades an fixed version to the same major version (5.5 or 5.6) the
bug 14521864 will be visible again, but unless the .frm is updated, it will
work again when upgrading again.

Also fixed so that the .frm does not get updated version
if a single partition check passes.
2013-02-14 17:03:49 +01:00
Mattias Jonsson
d92a7cb76a Bug#14521864: MYSQL 5.1 TO 5.5 BUGS PARTITIONING
Due to an internal change in the server code in between 5.1 and 5.5
(wl#2649) the hash function used in KEY partitioning changed
for numeric and date/time columns (from binary hash calculation
to character based hash calculation).

Also enum/set changed from latin1 ci based hash calculation to
binary hash between 5.1 and 5.5. (bug#11759782).

These changes makes KEY [sub]partitioned tables on any of
the affected column types incompatible with 5.5 and above,
since the calculation of partition id differs.

Also since InnoDB asserts that a deleted row was previously
read (positioned), the server asserts on delete of a row that
is in the wrong partition.

The solution for this situation is:

1) The partitioning engine will check that delete/update will go to the
partition the row was read from and give an error otherwise, consisting
of the rows partitioning fields. This will avoid asserts in InnoDB and
also alert the user that there is a misplaced row. A detailed error
message will be given, including an entry to the error log consisting
of both table name, partition and row content (PK if exists, otherwise
all partitioning columns).


2) A new optional syntax for KEY () partitioning in 5.5 is allowed:
[SUB]PARTITION BY KEY [ALGORITHM = N] (list_of_cols)
Where N = 1 uses the same hashing as 5.1 (Numeric/date/time fields uses
binary hashing, ENUM/SET uses charset hashing) N = 2 uses the same
hashing as 5.5 (Numeric/date/time fields uses charset hashing,
ENUM/SET uses binary hashing). If not set on CREATE/ALTER it will
default to 2.

This new syntax should probably be ignored by NDB.


3) Since there is a demand for avoiding scanning through the full
table, during upgrade the ALTER TABLE t PARTITION BY ... command is
considered a no-op (only .frm change) if everything except ALGORITHM
is the same and ALGORITHM was not set before, which allows manually
upgrading such table by something like:
ALTER TABLE t PARTITION BY KEY ALGORITHM = 1 () or
ALTER TABLE t PARTITION BY KEY ALGORITHM = 2 ()


4) Enhanced partitioning with CHECK/REPAIR to also check for/repair
misplaced rows. (Also works for ALTER TABLE t CHECK/REPAIR PARTITION)

CHECK FOR UPGRADE:
If the .frm version is < 5.5.3
and uses KEY [sub]partitioning
and an affected column type
then it will fail with an message:
KEY () partitioning changed, please run:
ALTER TABLE `test`.`t1`  PARTITION BY KEY ALGORITHM = 1 (a)
PARTITIONS 12
(i.e. current partitioning clause, with the addition of
ALGORITHM = 1)

CHECK without FOR UPGRADE:
if MEDIUM (default) or EXTENDED options are given:
Scan all rows and verify that it is in the correct partition.
Fail for the first misplaced row.

REPAIR:
if default or EXTENDED (i.e. not QUICK/USE_FRM):
Scan all rows and every misplaced row is moved into its correct
partitions.


5) Updated mysqlcheck (called by mysql_upgrade) to handle the
new output from CHECK FOR UPGRADE, to run the ALTER statement
instead of running REPAIR.

This will allow mysql_upgrade (or CHECK TABLE t FOR UPGRADE) to upgrade
a KEY [sub]partitioned table that has any affected field type
and a .frm version < 5.5.3 to ALGORITHM = 1 without rebuild.


Also notice that if the .frm has a version of >= 5.5.3 and ALGORITHM
is not set, it is not possible to know if it consists of rows from
5.1 or 5.5! In these cases I suggest that the user does:
(optional)
LOCK TABLE t WRITE;
SHOW CREATE TABLE t;
(verify that it has no ALGORITHM = N, and to be safe, I would suggest
backing up the .frm file, to be used if one need to change to another
ALGORITHM = N, without needing to rebuild/repair)
ALTER TABLE t <old partitioning clause, but with ALGORITHM = N>;
which should set the ALGORITHM to N (if the table has rows from
5.1 I would suggest N = 1, otherwise N = 2)
CHECK TABLE t;
(here one could use the backed up .frm instead and change to a new N
and run CHECK again and see if it passes)
and if there are misplaced rows:
REPAIR TABLE t;
(optional)
UNLOCK TABLES;
2013-01-30 17:51:52 +01:00
Shivji Kumar Jha
51d43baa66 BUG#12359942 - REPLICATION TEST FROM ENGINE SUITE
RPL_ROW_UNTIL TIMES OUT
 
 patch to fix post push falures in pb2 

mysql-test/suite/rpl/r/rpl_row_until.result:
  changes to account for the changes made in
  corresponding test file.
mysql-test/suite/rpl/t/disabled.def:
  disabled test in macosx
mysql-test/suite/rpl/t/rpl_row_until.test:
  replaced static relayy log file by an mtr variable
  which saves the name of relay log file.
2012-12-09 15:50:32 +05:30
Shivji Kumar Jha
195e731edb BUG#12359942 - REPLICATION TEST FROM ENGINE SUITE RPL_ROW_UNTIL TIMES OUT
bzr merge 5.1->5.5
2012-12-05 10:24:45 +05:30
Pedro Gomes
86718b969c Bug#13545447 RPL_ROTATE_LOGS FAILS DUE TO CONCURRENCY ISSUES IN REP. CODE
RPL_ROTATE_LOGS has been failing sporadically in what seems a
problem related to routines that update the coordinates. However,
the test lacks proper assert statments and because of this the
debug information upon failure simply points to the content
mismatch between the test and the result file.

Not as a solution, but as a improvement to the test to better
debug this failure, new assert statments were added to the test.

@rpl_rotate_logs.test
  Added new assert statments reducing the
  dependency on the result file.

@rpl_rotate_logs.result
  Added new content to the result file to
  match the test changes
2012-12-04 16:09:48 +00:00
Manish Kumar
14b18b2785 BUG#13812374 - RPL.RPL_REPORT_PORT FAILS OCCASIONALLY ON PB2
Problem: The problem with the test is that the slave returns 
         from start_slave.inc call too early before the list
         is actually actualised. This caused the slave stale 
         data to be reported.

Fix: Added a wait in the test till the slave's IO status is 
     changed to "Waiting for master to send event" which 
     which ensures the list is correctly updated.
2012-12-04 18:14:01 +05:30
Shivji Kumar Jha
07ffa9c767 BUG#12359942 - REPLICATION TEST FROM ENGINE SUITE RPL_ROW_UNTIL TIMES OUT
=== Problem ===

The test is dependent on binlog positions and checks
to see if the command 'START SLAVE' functions correctly
with the 'UNTIL' clause added to it. The 'UNTIL' clause
is added to specify that the slave should start and run
until the SQL thread reaches a given point in the master
binary log or in the slave relay log.

The test uses hard coded values for MASTER_LOG_POS and
RELAY_LOG_POS, instead of extracting it using
query_get_value() function. There is a test
'rpl.rpl_row_until' which does the similar thing but uses 
query_get_value() function to set the values of
MASTER_LOG_POS/ RELAY_LOG_POS. To be precise,
rpl.rpl_row_until is a modified version of
engines/func.rpl_row_until.test.

The use of hard coded values may lead the slave to stop at a position
which may differ from the expected position in the binlog file,
an example being the failure of engines/funcs.rpl_row_until in 
mysql-5.1 given as: 
"query 'select * from t2' failed. Table 'test.t2' doesn't exist".
In this case, the slave actually ran a couple of extra commands
as a result of which the slave first deleted the table and then
ran a select query on table, leading to the above mentioned failure.

=== Fix ===

1) Fixed the code for failure seen in rpl.rpl_row_until.
   This test was also failing although the symptoms of
   failure were different.
2) Copied the contents from rpl.rpl_row_until into
   into engines/funcs.rpl.rpl_row_until.
3) Updated engines/funcs.rpl_row_until.result accordingly.

mysql-test/suite/engines/funcs/r/rpl_row_until.result:
  modified to accomodate the changes in corresponding
  test file.
mysql-test/suite/engines/funcs/t/disabled.def:
  removed from the list of disabled tests.
mysql-test/suite/engines/funcs/t/rpl_row_until.test:
  fixed rpl.rpl_row_until and copied its content to
  engines/funcs.rpl_row_until. The reason being both
  are same tests but rpl.rpl_row_until is an
  updated version.
mysql-test/suite/rpl/t/disabled.def:
  removed from the list of disabled tests.
sql/sql_repl.cc:
  Added a check to catch an improper combination
  of arguements passed to 'START SLAVE UNTIL'. Earlier,
  START SLAVE UNTIL MASTER_LOG_FILE='master-bin.000001',
  MASTER_LOG_POS=561, RELAY_LOG_POS=12;
  passed. It is now detected and an error is reported.
2012-11-30 12:12:33 +05:30
Nuno Carvalho
fb313032a6 BUG#15891524: RLI_FAKE MODE IS NOT UNSET AFTER BINLOG REPLAY
When a binlog is replayed into a server, e.g.:
  $ mysqlbinlog binlog.000001 | mysql
it sets a pseudo slave mode on the client connection in order to server
be able to read binlog events, there is, a format description event is
needed to correctly read following events.
Also this pseudo slave mode applies to the current connection
replication rules that are needed to correctly apply binlog events.

If a binlog dump is sourced on a connection, this pseudo slave mode will
remains after it, what will apply unexpected rules from customer
perspective to following commands.

Added a new SET statement to binlog dump that will unset pseudo slave
mode at the end of dump file.
2012-11-20 12:37:23 +00:00
Rohit Kalhans
5530c5e38d BUG#14548159: NUMEROUS CASES OF INCORRECT IDENTIFIER
QUOTING IN REPLICATION 

Problem: Misquoting or unquoted identifiers may lead to
incorrect statements to be logged to the binary log.

Fix: we use specialized functions to append quoted identifiers in
the statements generated by the server.
2012-09-22 17:50:51 +05:30
Serge Kozlov
7dbada1674 BUG#12604949. Increased timeout for switching sync->async. Number of iterations for loops sets 10. 2012-10-02 22:05:51 +04:00
Rohit Kalhans
4802faad3f upmerge to bug#14548159 2012-09-22 18:07:04 +05:30
Nuno Carvalho
8dc96fc7aa BUG#14310067: RPL_CANT_READ_EVENT_INCIDENT AND RPL_BUG41902 FAIL ON 5.5
rpl_cant_read_event_incident:
Slave applies updates from bug11747416_32228_binlog.000001 file which 
contains a CREATE TABLE t statement and an incident, when SQL thread is
running slowly IO thread may reach the incident before SQL thread
executes the create table statement. 
Execute "drop table if exists t" and also perform a RESET MASTER to
clean slave binary logs.

rpl_bug41902:
Error "MYSQL_BIN_LOG::purge_logs was called with file
./master-bin.000001 not listed in the index." suppression is not 
considering windows path, there is ".\master-bin.000001".
Changed suppression to: "MYSQL_BIN_LOG::purge_logs was called with file
..master-bin.000001 not listed in the index", to match ".\" and "./".
2012-07-13 10:04:59 +01:00
Manish Kumar
db982ec87f BUG#12400221 - 60926: BINARY LOG EVENTS LARGER THAN MAX_ALLOWED_PACKET
Upmerge from mysql-5.1 -> mysql-5.5
2012-06-12 12:59:56 +05:30
Annamalai Gurusami
8aedf7d30f After the fix for Bug #12752572, there is a pb2 failure. Fixing it by
updating the result file.  Because a multi-row insert now reserves the
auto increment values before hand, if any explicitly specified auto
increment values are there, then some of the reserved values are lost.
2012-05-23 10:12:52 +05:30
Manish Kumar
1605b7f68f BUG#12400221 - 60926: BINARY LOG EVENTS LARGER THAN MAX_ALLOWED_PACKET
Problem
========
            
SQL statements close to the size of max_allowed_packet produce binary
log events larger than max_allowed_packet.
              
The reason why this failure is occuring is because the event length is
more than the total size of the max_allowed_packet + max_event_header
length. Now since the event length exceeds this size master Dump
thread is unable to send the packet on to the slave.
                      
That can happen e.g with row-based replication in Update_rows event.
            
Fix
====
          
The problem was fixed by increasing the max_allowed_packet for the
slave's threads (IO/SQL) by increasing it to 1GB.
This is done using the new server option included which is used to
regulate the max_allowed_packet of the slave thread (IO/SQL).
This causes the large packets to be received by the slave and apply
it successfully.

sql/log_event.h:
  Added the new option in the log_event.h file.
sql/mysqld.cc:
  Added a new option to the server.
sql/slave.cc:
  Increasing the session max_allowed_packet to a large value ,
  i.e. not taking global(max_allowed) into consideration, for the slave's threads.
2012-05-21 12:57:39 +05:30
Nuno Carvalho
5d8b38df4c BUG#11754117 - 45670: INTVAR_EVENTS FOR FILTERED-OUT QUERY_LOG_EVENTS ARE EXECUTED
Improved random number filtering verification on
rpl_filter_tables_not_exist test.
2012-05-15 22:06:48 +01:00
Nuno Carvalho
f0e93ac2bf BUG#11754117 - 45670: INTVAR_EVENTS FOR FILTERED-OUT QUERY_LOG_EVENTS ARE EXECUTED
Automerge from mysql-5.1 into mysql-5.5.
2012-05-15 22:18:59 +01:00
Joerg Bruehe
5be07ceadd Merge 5.5.24 back into main 5.5.
This is a weave merge, but without any conflicts.
In 14 source files, the copyright year needed to be updated to 2012.
2012-05-07 22:20:42 +02:00
Manish Kumar
3f98e95354 BUG#13812374 - RPL.RPL_REPORT_PORT FAILS OCCASIONALLY ON PB2
Problem - The failure on PB2 is possbily due to the port number being still in
          use even after the server restarts which is not reflected in the
          server restart.
      
Fix - The problem is fixed by starting the servers forcefully using the option
      file and also the parameters for the server restart is passed correctly.

mysql-test/suite/rpl/t/rpl_report_port-master.opt:
  Option file for the master.
2012-04-26 19:34:03 +05:30
Andrei Elkin
f189ccf530 merge from 5.1 repo 2012-04-23 12:05:05 +03:00
Andrei Elkin
bd0c38064f BUG#11754117
rpl_auto_increment_bug45679.test is refined due to not fixed in 5.1 Bug11749859-39934.
2012-04-23 11:51:19 +03:00
Andrei Elkin
6d74c922af merge bug11754117-45670 fixes from 5.1: fixing result files. 2012-04-21 14:19:06 +03:00
Andrei Elkin
14de6de946 merge bug11754117-45670 fixes from 5.1. 2012-04-21 13:24:39 +03:00
Nuno Carvalho
d3968407e6 BUG#13979418: SHOW BINLOG EVENTS MAY CRASH THE SERVER
Merge from 5.1 into 5.5.

Conflicts:
 * sql/log.h
 * sql/sql_repl.cc
2012-04-20 23:35:53 +01:00
Nuno Carvalho
cdaae1692b BUG#13979418: SHOW BINLOG EVENTS MAY CRASH THE SERVER
The function mysql_show_binlog_events has a local stack variable
'LOG_INFO linfo;', which is assigned to thd->current_linfo, however
this variable goes out of scope and is destroyed before clean
thd->current_linfo.

The problem is solved by moving 'LOG_INFO linfo;' to function scope.
2012-04-20 22:25:59 +01:00
Andrei Elkin
49e484c8cd BUG#11754117 incorrect logging of INSERT into auto-increment
BUG#11761686 insert_id event is not filtered.
  
Two issues are covered.
  
INSERT into autoincrement field which is not the first part in the composed primary key 
is unsafe by autoincrement logging design. The case is specific to MyISAM engine
because Innodb does not allow such table definition.
  
However no warnings and row-format logging in the MIXED mode was done, and
that is fixed.
  
Int-, Rand-, User-var log-events were not filtered along with their parent
query that made possible them to screw up execution context of the following
query.
  
Fixed with deferring their execution until the parent query.

******
Bug#11754117 

Post review fixes.

mysql-test/suite/rpl/r/rpl_auto_increment_bug45679.result:
  a new result file is added.
mysql-test/suite/rpl/r/rpl_filter_tables_not_exist.result:
  results updated.
mysql-test/suite/rpl/t/rpl_auto_increment_bug45679.test:
  regression test for BUG#11754117-45670 is added.
mysql-test/suite/rpl/t/rpl_filter_tables_not_exist.test:
  regression test for filtering issue of BUG#11754117 - 45670 is added.
sql/log_event.cc:
  Logics are added for deferring and executing events associated 
  with the Query event.
sql/log_event.h:
  Interface to deferred events batch execution is added.
sql/rpl_rli.cc:
  initialization for new RLI members is added.
sql/rpl_rli.h:
  New members to RLI are added to facilitate deferred events gathering
  and execution control;
  two general character RLI cleanup methods are constructed.
sql/rpl_utility.cc:
  Deferred_log_events methods are difined.
sql/rpl_utility.h:
  A new class Deferred_log_events is defined to implement
  IRU events gathering, execution and cleanup.
sql/slave.cc:
  Necessary changes to initialize `rli->deferred_events' and prevent
  deferred event deletion in the main read-exec branch.
sql/sql_base.cc:
  A new safe-check function for multi-part pk with auto-increment is defined
  and deployed in lock_tables().
sql/sql_class.cc:
  Initialization for a new member and replication cleanups are added
  to THD class.
sql/sql_class.h:
  THD class receives a new member to hold a specific execution
  context for slave applier.
sql/sql_parse.cc:
  Execution of the deferred event in started prior to its parent query.
2012-04-20 19:41:20 +03:00
Georgi Kodinov
a84ca72224 merge mysql-5.5->mysql-5.5-security 2012-04-12 14:04:12 +03:00
Sujatha Sivakumar
64e74d484f BUG#12662190:COM_COMMIT IS NOT INCREMENTED FROM THE BINARY LOGS ON SLAVE, COM_BEGIN IS
PROBLEM:

--------

When binary log statements are replayed on the slave, BEGIN is represented

in com_counters but COMMIT is not. Similarly in 'ROW' based replication

'INSERT','UPDATE',and 'DELETE' com_counters are not getting incremented

when the binary log statements are replayed at slave.

ANALYSIS:
---------

In 'ROW' based replication for COMMIT,INSERT,UPDATE and DELETE operations
following special events are invoked.
Xid_log_event,Write_rows_log_event,Update_rows_log_event,Update_rows_log_event.

The above mentioned events doesn't go through the parser where the
'COM_COUNTERS' are incremented.


FIX:
-----
Increment statements are added at appropriate events.
Respective functions are listed below.

'Xid_log_event::do_apply_event'
'Write_rows_log_event::do_before_row_operations'
'Update_rows_log_event::do_before_row_operations'
'Delete_rows_log_event::do_before_row_operations' 

sql/log_event.cc:
  Added code to increment counts for 'COM_INSERT','COM_UPDATE',
  'COM_DELETE' and 'COM_COMMIT'during ROW based replicaiton
2012-04-12 11:07:39 +05:30
Georgi Kodinov
7fa28bcf56 merge mysql-5.5->mysql-5.5-security 2012-04-10 14:23:17 +03:00
Manish Kumar
20459a71e3 BUG#13812374 - RPL.RPL_REPORT_PORT FAILS OCCASIONALLY ON PB2
Problem - this failure occured in the test added for the fix of the 
          bug-13333431. The basic problem of the failure was the 
          value of the report_port which persisted even after the end 
          of the test (ie. rpl_end.inc). So this causes the assertion 
          in the test to fail if it is executed again.

Fix - restarted the server with the default value being passed to the 
      report_port after testing the two expected case so that in the 
      next run of the test we will not encounter the previous value of
      report_port.



mysql-test/suite/rpl/r/rpl_report_port.result:
  Updated the corresponding result file.
mysql-test/suite/rpl/t/rpl_report_port-slave.opt:
  Removed the slave option file.
mysql-test/suite/rpl/t/rpl_report_port.test:
  Added the restart server option before ending the test.
2012-04-10 11:44:17 +05:30
Rohit Kalhans
1a02c266d1 BUG#11765650 - 58637: MARK UPDATES THAT DEPEND ON ORDER OF TWO KEYS UNSAFE
Description: When the table has more than one unique or primary key, 
 INSERT... ON DUP KEY UPDATE statement is sensitive to the order in which
 the storage engines checks the keys. Depending on this order, the storage
 engine may determine different rows to mysql, and hence mysql can update
 different rows on master and slave.
      
 Solution: We mark INSERT...ON DUP KEY UPDATE on a table with more than on unique
 key as unsafe therefore the event will be logged in row format if it is available
 (ROW/MIXED). If only STATEMENT format is available, a warning will be thrown. 

mysql-test/suite/binlog/r/binlog_unsafe.result:
  Updated result file
mysql-test/suite/binlog/t/binlog_unsafe.test:
  Added test to check  for warning being thrown when the unsafe statement is executed
mysql-test/suite/rpl/r/rpl_known_bugs_detection.result:
  Updated result file
sql/share/errmsg-utf8.txt:
  Added new warning message
sql/sql_base.cc:
  check for tables in the query with more than one UNIQUE KEY and INSERT ON DUPLICATE KEY UPDATE, and mark such statements unsafe.
2012-03-30 18:35:53 +05:30
Jon Olav Hauglid
29443d085c Merge from mysql-5.5 to mysql-5.5-security
No conflicts
2012-03-15 11:25:53 +01:00
Luis Soares
4977b60e59 BUG#12400313
Automerging from mysql-5.1.
2012-03-12 23:26:00 +00:00
Luis Soares
7f84e70b86 BUG#12400313
Adding missing sync_slave_with_master to the test case.
2012-03-12 23:23:40 +00:00
Luis Soares
66a306e6e2 BUG#12400313
Fixing waiting condition. "enter_cond" text changed in 5.5+ (when the SQL thread
is waiting for more events).
2012-03-12 23:21:03 +00:00
Luis Soares
9794750125 BUG#12400313
Automerge changes to the test case from mysql-5.1.
2012-03-12 23:18:24 +00:00
Luis Soares
9eedf9b452 BUG#12400313
Hardening the test case:
  - including a diff_tables at the end.
  - increasing the tolerance on the relay limit size.
2012-03-12 23:15:01 +00:00
Luis Soares
549a5fa249 BUG#12400313
Manual merge from mysql-5.1 into mysql-5.5.

CONFLICTS
=========
  Text conflict in sql/log.cc
  Text conflict in sql/slave.cc
2012-03-12 22:02:50 +00:00