Commit graph

116 commits

Author SHA1 Message Date
Andrei Elkin
1944f98a1a merging 5.1-bt to a local tree. 2008-12-08 21:26:32 +02:00
Andrei Elkin
ca25988f6e Bug #40221 Replication failure on RBR + UPDATE the primary key
Extending bug#40221 regression test: 1. include INSERT 2. convert prim key + autoinc to
unique.
2008-12-08 17:07:08 +02:00
Mats Kindahl
82757fdfc0 Bug #40116: Uncommited changes are replicated and stay on slave
after rollback on master

When starting a transaction with a statement containing changes
to both transactional tables and non-transactional tables, the
statement is considered as non-transactional and is therefore
written directly to the binary log. This behaviour was present
in 5.0, and has propagated to 5.1.

If a trigger containing a change of a non-transactional table is
added to a transactional table, any changes to the transactional
table is "tainted" as non-transactional.

This patch solves the problem by removing the existing "hack" that
allows non-transactional statements appearing first in a transaction
to be written directly to the binary log. Instead, anything inside
a transaction is treaded as part of the transaction and not written
to the binary log until the transaction is committed.
2008-12-03 20:55:49 +01:00
Andrei Elkin
40889f9ea6 Bug #40221 Replication failure on RBR + UPDATE the primary key
A transaction could result in having an extra event after a query that
errored e.g because of a dup key. Such a query is rolled back in
innodb, as specified, but has not been in binlog.
It appeares that the binlog engine did not always register for a query
(statement) because the previous query had not reset at its statement
commit time. Because of that fact there was no roll-back to the
trx_data->before_stmt_pos position and a the pending event of the
errorred query could become flushed to the binlog file.

Fixed with deploying the reset of trx_data->before_stmt_pos at the end
of the query processing.
2008-12-02 19:32:07 +02:00
Mats Kindahl
66a3dbceff Merging with 5.1-5.1.29-rc. 2008-10-03 09:36:22 +02:00
Mats Kindahl
43fb8633b0 Bug #38360: BLACKHOLE replication with RBR is broken
The Blackhole engine did not support row-based replication
since the delete_row(), update_row(), and the index and range
searching functions were not implemented.

This patch adds row-based replication support for the
Blackhole engine by implementing the two functions mentioned
above, and making the engine pretend that it has found the
correct row to delete or update when executed from the slave
SQL thread by implementing index and range searching functions.

It is necessary to only pretend this for the SQL thread, since
a SELECT executed on the Blackhole engine will otherwise never
return EOF, causing a livelock.
2008-10-02 11:02:38 +02:00
Ramil Kalimullin
0be194e5c3 Merge 2008-10-02 10:56:07 +05:00
Georgi Kodinov
435f54fce0 merged 5.1-5.1.29-rc -> 5.1-bugteam 2008-10-01 12:47:25 +03:00
Davi Arnaut
35ffaf10e3 Bug#34306: Can't make copy of log tables when server binary log is enabled
The problem is that when statement-based replication was enabled,
statements such as INSERT INTO .. SELECT FROM .. and CREATE TABLE
.. SELECT FROM need to grab a read lock on the source table that
does not permit concurrent inserts, which would in turn be denied
if the source table is a log table because log tables can't be
locked exclusively.

The solution is to not take such a lock when the source table is
a log table as it is unsafe to replicate log tables under statement
based replication. Furthermore, the read lock that does not permits
concurrent inserts is now only taken if statement-based replication
is enabled and if the source table is not a log table.
2008-09-29 10:53:40 -03:00
Patrick Crews
92a3b67393 Bug#37312 Make tests binlog_row_innodb_stat and binlog_stm_innodb_stat more robust
Trimmed some error-prone and variable portions of the test and added 'flush status' to ensure deterministic test
2008-09-22 15:15:52 -04:00
Chad MILLER
edf10751ef Merge Bug#37312. 2008-09-18 03:57:59 -04:00
Mats Kindahl
69a8281c41 Bug #39106:
SUPER is not required to change binlog format for session

A user without SUPER privileges can change the value of the
session variable BINLOG_FORMAT, causing problems for a DBA.

This changeset requires a user to have SUPER privileges to
change the value of the session variable BINLOG_FORMAT, and
not only the global variable BINLOG_FORMAT.
2008-09-09 12:19:31 +02:00
Chad MILLER
60cca234e2 Bug#37312: Make test binlog_{row,stm}_innodb_stat more robust
The size of the Innodb_buffer_pool_pages differs by one byte on row versus statement
log, so neuter the last position of the stringified decimal representation.  Innobase
says the size isn't very important in any case.

Also, split out the "mixed" format to its own file, as mtr seems to dislike having only 
stm and row but not mix.
2008-09-08 16:23:55 -04:00
Mats Kindahl
dd34cceb4c Result file change. 2008-08-27 16:17:55 +02:00
Mats Kindahl
f1b8441e02 Merge b38773-5.1-rpl-merge into 5.1-rpl-merge 2008-08-27 11:02:37 +02:00
Mats Kindahl
6461089817 Bug #38773: DROP DATABASE cause switch to stmt-mode when there are temporary
tables open

When executing a DROP DATABASE statement in ROW mode and having temporary
tables open at the same time, the existance of temporary tables prevent
the server from switching back to row mode after temporarily switching to
statement mode to handle the logging of the statement.

Fixed the problem by removing the code to switch to statement mode and added
code to temporarily disable the binary log while dropping the objects in the
database.
2008-08-27 10:40:11 +02:00
Sven Sandberg
1562db45f1 merge 5.1 main -> 5.1-rpl-testfixes
all changes automerged without conflicts
2008-07-29 19:55:46 +02:00
Sven Sandberg
3d5289c2dd BUG#38068: binlog_stm_binlog fails sporadically in pushbuild
Post-push fix: updated some result files that were affected
by the previous fix to this bug.
2008-07-29 17:36:13 +02:00
Sven Sandberg
fc0f24812f BUG#38068: binlog_stm_binlog fails sporadically in pushbuild
Problem: binlog_stm_binlog runs INSERT DELAYED queries, and
then prints the contents of the binlog. Before checking the
contents of the binlog, the test waits until the rows have
appeared in the table. However, this is not enough, since
INSERT DELAYED does not write rows to the binlog at the same
time as it writes them to the table. So there is a race.
Fix: Add a FLUSH TABLES before SHOW BINLOG EVENTS. That
waits until the insert_delayed thread is done.
2008-07-23 18:56:39 +02:00
Mats Kindahl
2a089557a6 BUG#37426: RBR breaks for CHAR() UTF-8 fields > 85 chars
In order to handle CHAR() fields, 8 bits were reserved for
the size of the CHAR field. However, instead of denoting the
number of characters in the field, field_length was used which
denotes the number of bytes in the field.

Since UTF-8 fields can have three bytes per character (and
has been extended to have four bytes per character in 6.0),
an extra two bits have been encoded in the field metadata
work for fields of type Field_string (i.e., CHAR fields).

Since the metadata word is filled, the extra bits have been
encoded in the upper 4 bits of the real type (the most 
significant byte of the metadata word) by computing the
bitwise xor of the extra two bits. Since the upper 4 bits
of the real type always is 1111 for Field_string, this 
means that for fields of length <256, the encoding is
identical to the encoding used in pre-5.1.26 servers, but
for lengths of 256 or more, an unrecognized type is formed,
causing an old slave (that does not handle lengths of 256
or more) to stop.
2008-06-30 22:11:18 +02:00
cmiller@zippy.cornsilk.net
1e5fc1089f Fix merge problems and re-record output for legitimate changes. 2008-05-16 11:35:15 -04:00
gkodinov/kgeorge@magare.gmz
0463ba57a5 Merge bk-internal:/home/bk/mysql-5.1
into  magare.gmz:/home/kgeorge/mysql/work/merge-build-5.1-bugteam
2008-03-31 11:57:18 +03:00
aelkin/andrei@mysql1000.(none)
ba7b1a7e55 Bug #35675 reset master finds assert if a binlog file can not be deleted
If a binlog file is manually replaced with a namesake directory the internal purging did
not handle the error of deleting the file so that eventually
a post-execution guards fires an assert.

Fixed with reusing a snippet of code for bug@18199 to tolerate lack of the file but no other error 
at an attempt to delete it.
The same applied to the index file deletion.

The cset carries pieces of manual merging.
2008-03-30 00:54:08 +02:00
aelkin/andrei@mysql1000.(none)
d3d0a00635 Merge mysql1000.(none):/home/andrei/MySQL/MERGE/5.0-main2rpl
into  mysql1000.(none):/home/andrei/MySQL/MERGE/5.1-main2rpl
2008-03-29 15:00:12 +02:00
aelkin/andrei@mysql1000.(none)
22536fc53e Merge mysql1000.(none):/home/andrei/MySQL/BARE/mysql-5.1
into  mysql1000.(none):/home/andrei/MySQL/MERGE/5.1-main2rpl
2008-03-29 14:19:53 +02:00
mats@mats-laptop.(none)
476a7bf2d7 Post-merge fixes to remove test failures resulting from merge. 2008-03-28 18:56:43 +01:00
mats@mats-laptop.(none)
c14426aefe Merge mkindahl@bk-internal.mysql.com:/home/bk/mysql-5.1-bugteam
into  mats-laptop.(none):/home/bk/b29020-mysql-5.1-rpl
2008-03-28 14:52:33 +01:00
mats@mats-laptop.(none)
c8c4500a98 BUG#29020 (Event results not correctly replicated to slave in RBR):
The bug allow multiple executing transactions working with non-transactional
to interfere with each others by interleaving the events of different trans-
actions.

Bug is fixed by writing non-transactional events to the transaction cache and
flushing the cache to the binary log at statement commit. To mimic the behavior
of normal statement-based replication, we flush the transaction cache in row-
based mode when there is no committed statements in the transaction cache,
which means we are committing the first one. This means that it will be written
to the binary log as a "mini-transaction" with just the rows for the statement.

Note that the changes here does not take effect when building the server with
HAVE_TRANSACTIONS set to false, but it is not clear if this was possible before
this patch either.

For row-based logging, we also have that when AUTOCOMMIT=1, the code now always
generates a BEGIN/COMMIT pair for single statements, or BEGIN/ROLLBACK pair in the
case of non-transactional changes in a statement that was rolled back. Note that
for the case where changes to a non-transactional table causes a rollback due
to error, the statement will now be logged with a BEGIN/ROLLBACK pair, even
though some changes has been committed to the non-transactional table.
2008-03-28 13:16:41 +01:00
hezx@mail.hezx.com
35c158ec85 post fix after push of bug#33029 2008-03-27 13:48:04 +08:00
hezx@mail.hezx.com
905659a2a0 Merge mail.hezx.com:/media/sda3/work/mysql/bkroot/mysql-5.1-new-rpl
into  mail.hezx.com:/media/sda3/work/mysql/bkwork/b33029_5.0_to_5.1_fails_on_dup_key/5.1
2008-03-26 21:40:44 +08:00
istruewing@stella.local
c882b87110 Merge stella.local:/home2/mydev/mysql-5.1-ateam
into  stella.local:/home2/mydev/mysql-5.1-axmrg
2008-03-26 10:56:03 +01:00
istruewing@stella.local
44fbe74e1e Merge stella.local:/home2/mydev/mysql-5.1-amain
into  stella.local:/home2/mydev/mysql-5.1-axmrg
2008-03-26 10:27:00 +01:00
svoj@mysql.com/june.mysql.com
b799ea244c BUG#34768 - nondeterministic INSERT using LIMIT logged in stmt mode
if binlog_format=mixed

Addition to fix for BUG#34768: fixed test case failures discovered
by pushbuild.
2008-03-25 17:28:12 +04:00
svoj@mysql.com/june.mysql.com
6dfb184f09 BUG#34768 - nondeterministic INSERT using LIMIT logged in stmt mode if
binlog_format=mixed

Statement-based replication of DELETE ... LIMIT, UPDATE ... LIMIT,
INSERT ... SELECT ... LIMIT is not safe as order of rows is not
defined.

With this fix, we issue a warning that this statement is not safe to
replicate in statement mode, or go to row-based mode in mixed mode.

Note that we may consider a statement as safe if ORDER BY primary_key
is present. However it may confuse users to see very similiar statements
replicated differently.

Note 2: regular UPDATE statement (w/o LIMIT) is unsafe as well, but
this patch doesn't address this issue. See comment from Kristian
posted 18 Mar 10:55.
2008-03-18 20:25:34 +04:00
hezx@mail.hezx.com
a3d02647e6 BUG#33029 5.0 to 5.1 replication fails on dup key when inserting
using a trig in SP

For all 5.0 and up to 5.1.12 exclusive, when a stored routine or
trigger caused an INSERT into an AUTO_INCREMENT column, the
generated AUTO_INCREMENT value should not be written into the
binary log, which means if a statement does not generate
AUTO_INCREMENT value itself, there will be no Intvar event (SET
INSERT_ID) associated with it even if one of the stored routine
or trigger caused generation of such a value. And meanwhile, when
executing a stored routine or trigger, it would ignore the
INSERT_ID value even if there is a INSERT_ID value available set
by a SET INSERT_ID statement.

Starting from MySQL 5.1.12, the generated AUTO_INCREMENT value is
written into the binary log, and the value will be used if
available when executing the stored routine or trigger.

Prior fix of this bug in MySQL 5.0 and prior MySQL 5.1.12
(referenced as the buggy versions in the text below), when a
statement that generates AUTO_INCREMENT value by the top
statement was executed in the body of a SP, all statements in the
SP after this statement would be treated as if they had generated
AUTO_INCREMENT by the top statement.  When a statement that did
not generate AUTO_INCREMENT value by the top statement but by a
function/trigger called by it, an erroneous Intvar event would be
associated with the statement, this erroneous INSERT_ID value
wouldn't cause problem when replicating between masters and
slaves of 5.0.x or prior 5.1.12, because the erroneous INSERT_ID
value was not used when executing functions/triggers. But when
replicating from buggy versions to 5.1.12 or newer, which will
use the INSERT_ID value in functions/triggers, the erroneous
value will be used, which would cause duplicate entry error and
cause the slave to stop.

The patch for 5.1 fixed it to ignore the SET INSERT_ID value when
executing functions/triggers if it is replicating from a master
of buggy versions, another patch for 5.0 fixed it not to generate
the erroneous Intvar event.
2008-03-14 11:35:41 +08:00
sven@riska.(none)
afde9893b1 Problem: Pushbuild errors because sql_mode is unsafe but test thinks it is
safe.
Fix: Move sql_mode: from the section of the test where safe variables are
tested, to the section where unsafe variables are tested.
2008-03-10 15:26:21 +01:00
antony@pcg5ppc.xiphis.org
bdc74bbda7 Merge acurtis@bk-internal.mysql.com:/home/bk/mysql-5.1-engines
into  pcg5ppc.xiphis.org:/Network/Servers/anubis.xiphis.org/home/antony/work/merge.20080307/mysql-5.1
2008-03-07 14:07:01 -08:00
antony@pcg5ppc.xiphis.org
820068f1b7 Merge pcg5ppc.xiphis.org:/Network/Servers/anubis.xiphis.org/home/antony/work/mysql-5.1-engines
into  pcg5ppc.xiphis.org:/Network/Servers/anubis.xiphis.org/home/antony/work/merge.20080307/mysql-5.1
2008-03-07 13:46:29 -08:00
bar@mysql.com/bar.myoffice.izhnet.ru
84e6d960e0 After merge fix 2008-03-08 01:14:56 +04:00
sven@riska.(none)
81b1d712bf BUG#31168: @@hostname does not replicate
Problem: in mixed and statement mode, a query that refers to a
system variable will use the slave's value when replayed on
slave. So if the value of a system variable is inserted into a
table, the slave will differ from the master.
Fix: mark statements that refer to a system variable as "unsafe",
meaning they will be replicated by row in mixed mode and produce a warning
in statement mode. There are some exceptions: some variables are actually
replicated. Those should *not* be marked as unsafe.
BUG#34732: mysqlbinlog does not print default values for auto_increment variables
Problem: mysqlbinlog does not print default values for some variables,
including auto_increment_increment and others. So if a client executing
the output of mysqlbinlog has different default values, replication will
be wrong.
Fix: Always print default values for all variables that are replicated.
I need to fix the two bugs at the same time, because the test cases would
fail if I only fixed one of them.
2008-03-07 13:59:36 +01:00
bar@bar.myoffice.izhnet.ru
c49eccfe71 Merge mysql.com:/home/bar/mysql-work/mysql-5.0.b27580v2
into  mysql.com:/home/bar/mysql-work/mysql-5.1.b27580
Additonal after merge fix
2008-03-07 15:28:51 +04:00
mkindahl@dl145h.mysql.com
51ad2901d4 Adding missing drop of view last in test. 2008-03-05 14:45:40 +01:00
mkindahl@dl145h.mysql.com
9b54edd28e Updating result file. 2008-03-05 13:59:32 +01:00
mkindahl@dl145h.mysql.com
15e7050499 Merge dl145h.mysql.com:/data0/mkindahl/mysql-5.1
into  dl145h.mysql.com:/data0/mkindahl/mysql-5.1-rpl
2008-03-05 10:16:20 +01:00
skozlov/ksm@mysql.com/virtop.(none)
0771579b82 Bug#32663, Bug#33045, Bug#23533, WL#4091 2008-02-29 00:50:15 +03:00
sven@riska.(none)
4aab65ad5c Fix pushbuild errors. 2008-02-27 15:18:27 +01:00
kostja@dipika.(none)
52f5069703 Update new test results after merge (Bug#12713) 2008-02-22 21:49:16 +03:00
kostja@dipika.(none)
1e6dbd949f Update new tests after merge. 2008-02-22 17:51:57 +03:00
mkindahl@dl145h.mysql.com
802158bda5 Fixing result after merge. 2008-02-21 06:29:35 +01:00
mkindahl@dl145h.mysql.com
759d2f6658 Merge dl145h.mysql.com:/data0/mkindahl/mysql-5.0-rpl
into  dl145h.mysql.com:/data0/mkindahl/mysql-5.1-rpl
2008-02-20 19:49:26 +01:00