mariadb/mysql-test/extra/rpl_tests/rpl_mixing_engines.test

1780 lines
54 KiB
Text
Raw Normal View History

################################################################################
# - Introduction
# This checks if transactions that mixes transactional and non-transactional
# are correctly handled. There are several types of statements that require
# attention because of their special behavior in transactions:
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
#
# * Non-transactional updates that take place inside a transaction present
# problems for logging because (1) they are visible to other clients before
# the transaction is committed, and (2) they are not rolled back even if the
# transaction is rolled back. It is not always possible to log correctly in
# statement format when both transactional and non-transactional tables are
# used in the same transaction.
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
#
# * Statements that do an implicit commit (i.e., most but not all DDL, and
# some utility commands) are logged specially due to unspecified requirements by
# NDB.
#
# * Statements that update temporary tables need special treatment since they
# are not logged in row format.
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
#
# - Definitions
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
#
# To reason about logging different table types, we make some preliminary
# definitions.
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
#
# * A table that has a transactional engine is called a T-table.
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
#
# * A table that has a non-transactional engine is called an N-table.
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
#
# * A statement makes an N-write if it makes any type of change to the server
# state that will not be changed by a ROLLBACK.
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
#
# * Events are either appended to the Transaction Cache (TC) or to the
# Statement Cache (SC) or written directly to the binlog.
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
#
# - Preliminary Rules
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
#
# The following preliminary rules are actually consequences of the principle
# that statements shall be correctly logged when binlog_format=MIXED or ROW.
# They also apply when binlog_format=STATEMENT: this makes statement format
# work in many practical cases.
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
#
# * (Causality) If statement A is executed before statement B, and B is logged
# in statement format, and B reads tables that A may modifies, then B shall be
# logged after A.
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
#
# * (Durability) Events shall be written to the binary log at the moment they
# take effect. In particular, changes to N-tables shall be written to the
# binary log when they have been executed, and changes to T-tables shall be
# written to the binary log on commit. If --sync-binlog has been specified,
# then it suffices that events are be written to the binary log at the next
# synchronization point.
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
#
# * (causality-precedence) If causality and durability cannot both be
# fulfilled, then casuality is considered more important.
#
# - Rules for non-committing statements, except CREATE TEMPORARY TABLE...SELECT
#
# The preliminary rules above, together with the principles for logging format
# , have been used to construct the following rules.
#
# CALL statements are unrolled, so that each statement executed by the stored
# procedure is logged separately. (If a stored procedure A invokes a stored
# procedure B, then B is unrolled recursively). In the following, we assume
# that unrolling has already been done, and the word "statement" refers to a
# non-CALL top-level statement or a non-CALL sub-statement.
#
# Let S be a logged statement that does not have an implicit commit, except
# CREATE TEMPORARY TABLE...SELECT (This includes all "pure DML": INSERT,
# UPDATE, DELETE, REPLACE, TRUNCATE, SELECT, DO, CALL, EXECUTE, LOAD DATA
# INFILE, and BINLOG. It also includes CREATE TEMPORARY TABLE without SELECT,
# and DROP TEMPORARY TABLE. CREATE TEMPORARY TABLE...SELECT is handled in the
# next subsection).
#
# Before executing S, determine unsafeness:
#
# * If S either makes N-writes or reads from an N-table, and either S or a
# previous statement in the same transaction reads or writes to a T-table,
# then S is marked as unsafe.
#
# When logging S, determine where to log it by applying the following rules in
# order:
#
# * If S is to be logged in statement format (i.e., if one of the following
# holds: (1) STATEMENT; (2) MIXED and S is safe; (3) S is of DDL type, i.e.,
# CREATE TEMPORARY TABLE):
# 1. If S produces an error and does not do any N-write, do not log.
# 2. Otherwise, if either S or any previous statement in the same
# transaction reads or writes in any T-tables, log to TC.
# 3. Otherwise, log to SC.
#
# * If S is to be logged in row format (i.e., if S is DML and one of the
# following holds: (1) ROW; (2) MIXED and S is unsafe):
# 1. Do not log row events that write to temporary tables.
# 2. Log row events that write to non-temporary N-tables to SC.
# 3. Log row events that write to non-temporary T-tables to TC, except
# rows that are rolled back due to an error. (Note: if there is an error,
# rows written to a T-table are kept if there are subsequent rows written
# to an N-table.)
#
# * At the end of S, write BEGIN + SC + COMMIT to the binlog and clear the
# SC.
#
# At end of transaction:
#
# * At COMMIT or implicit commit, where all XA tables in the transaction
# succeed in the "prepare" phase:
# 1. If the TC is non-empty, write BEGIN + TC + COMMIT to the binlog.
# 2. If the TC is empty, do nothing.
#
# * At ROLLBACK; or at COMMIT or implicit commit where some XA table fails
# in the "prepare" phase:
# 1. If the TC contains any N-write, write BEGIN + TC + ROLLBACK to the
# binlog.
# 2. If the TC does not contain any N-write, do nothing.
#
# * At ROLLBACK TO SAVEPOINT:
# 1. If the TC contains any N-write after the savepoint, write ROLLBACK TO
# SAVEPOINT to the TC.
# 2. Otherwise, clear the part of the TC that starts at the savepoint and
# extends to the end of the TC. (Bug#47327 breaks this rule)
#
# * Clear the TC at the end of the transaction.
#
# - Rules for CREATE [TEMPORARY] TABLE...SELECT
#
# First, unsafeness is determined as above (R-unsafe-transaction). Then the
# logging format is decided. Then the following rules apply.
#
# * If logging in statement format (i.e., one of the following holds: (1)
# STATEMENT; (2) MIXED and statement is safe):
# 1. If there is an error, do not write anything.
# 2. If there is no error and the TEMPORARY keyword is used, write the
# entire CREATE...SELECT statement to the TC.
# 3. If there is no error and the TEMPORARY keyword is not used, write the
# entire CREATE...SELECT directly to the binlog.
#
# * If logging in row format (i.e., one of the following holds: (1) ROW; (2)
# MIXED and statement is unsafe):
# 1. If the TEMPORARY keyword is used, do not write anything.
# 2. If the TEMPORARY keyword is not used, write CREATE TABLE (without
# select) + BEGIN + row events + COMMIT to the TC. If there is an error,
# clear the TC; otherwise flush the TC to the binlog at the end of the
# statement and then clear the TC. (Note: currently Bug#47899 breaks this
# rule)
#
# - Rules for committing statements, except CREATE [TEMPORARY] TABLE...SELECT
#
# * All other statements that have a pre-commit are written directly to the
# binlog. (Note: this is semantically equivalent to writing it to the SC and
# flushing the SC. However, due to requirements by NDB (which have not been
# clarified), we write directly to the binlog.)
#
# We use the include file rpl_mixing_engines.inc to generate sql commands from a
# format string. The format string consists of a sequence of 'codes' separated
# by spaces. The following codes exist:
#
# - Define the scope of a transaction:
# B - Begin.
# C - Commit.
# R - Rollback.
# S1 - Savepoint.
# R1 - Rollback to S1.
#
# - Change only T-Tables:
# T - Updates a T-Table.
# T-trig - Updates T-Tables through a trigger.
# T-func - Updates T-Tables through a function.
# T-proc - Updates T-Tables through a procedure.
# eT - Fails while updating the first tuple in a T-Table.
# Te - Fails while updating an n-tuple (n > 1) in a T-Table.
# Te-trig - Fails while updating an n-tuple (n > 1) in a T-Table.
# Te-func - Fails while updating an n-tuple (n > 1) in a T-Table.
#
# - Change only N-Tables
# N - Updates a N-Table.
# N-trig - Updates N-Tables through a trigger.
# N-func - Updates N-Tables through a function.
# N-proc - Updates N-Tables through a procedure.
# eN - Fails while updating the first tuple in a N-Table.
# Ne - Fails while updating an n-tuple (n > 1) in a N-Table.
# Ne-trig - Fails while updating an n-tuple (n > 1) in a N-Table.
# Ne-func - Fails while updating an n-tuple (n > 1) in a N-Table.
#
# - Read T-table and write N-table:
# tN - Updates a N-Table
# tNe - Fails while updating an n-tuple (n > 1) in a N-Table.
#
# - Read N-table and write T-table:
# nT - Updates a T-Table.
# nTe - Fails while updating an n-tuple (n > 1) in a T-Table.
#
# - Update both types of tables. First a N-Table and the a T-Table:
# NT - Upates both types of tables through an update statement.
# NT-trig - Updates both types of tables through a trigger.
# NT-func - Updates both types of tables through a procedure.
# NeT-trig - Fails while updating an n-tuple (n > 1) in a T-Table.
# NeT-func - Fails while updating an n-tuple (n > 1) in a T-Table.
#
# - Update both types of tables. First a T-Table and the a N-Table:
# TN - Upates both types of tables through an update statement.
# TN-trig - Updates both types of tables through a trigger.
# TN-func - Updates both types of tables through a procedure.
# TeN-trig - Fails while updating an n-tuple (n > 1) in a N-Table.
# TeN-func - Fails while updating an n-tuple (n > 1) in a N-Table.
#
# - This is CREATE...SELECT:
# CS-T->T - Creates a T-table selecting from a T-table.
# CS-N->N - Creates a N-table selecting from a N-table.
# CS-T->N - Creates a T-table selecting form a N-table.
# CS-N->T - Creates a N-table selecting from a T-table.
# CSe-T->T - Fails while creating a T-table selecting from a T-table.
# CSe-N->N - Fails while creating a N-table selecting from a N-table.
# CSe-T->N - Fails while creating a T-table selecting from a a N-table.
# CSe-N->T - Fails while creating a N-table selecting from a T-table.
# drop-CS - Drops any of the tables previously created.
# trunc-CS-T - Truncates a T-table previously created.
# trunc-CS-N - Truncates a N-table previously created.
# CT - Creates a temporary T-table.
# drop-CT - Drops a temporary T-table.
#
# - This is INSERT...SELECT:
# IS-T<-T - Inserts data from a T-table into a T-table.
# IS-T<-N - Inserts data from a N-table into a T-table.
# IS-N<-T - Inserts data from a T-table into a N-table.
# IS-N<-N - Inserts data from a N-table into a N-table.
# ISe-T<-T - Fails while inserting data from a T-table into a T-table.
# ISe-T<-N - Fails while inserting data from a N-table into a T-table.
# ISe-N<-T - Fails while inserting data from a T-table into a N-table.
# ISe-N<-N - Fails while inserting data from a N-table into a N-table.
#
# For the CREATE...SELECT and INSERT...SELECT, the table names are defined based
# on the variable $tb_id which is automatically incremented after each drop.
# This indirectly means that two tables cannot co-exist unless we manually keep
# the variable $tb_id.
#
# The format of the entries in the binlog depends on the mode and on the type
# statements: S - statement and R - row. And when it is clear from the context
# which statement is referred to, we sometimes use "M" to denote a "Mixed"
# statement, i.e., one that accesses both a T-table and an N-table.
#
# For further details, please, read WL#2687 and WL#5072.
################################################################################
--echo #########################################################################
--echo # CONFIGURATION
--echo #########################################################################
BUG#50670: Slave stops with error code 1644 Clarified error messages related to unsafe statements: - avoid the internal technical term "row injection" - use 'binary log' instead of 'binlog' - avoid the word 'unsafeness' mysql-test/extra/binlog_tests/blackhole.test: updated suppression pattern mysql-test/extra/binlog_tests/mix_innodb_myisam_binlog.test: updated suppression pattern mysql-test/extra/rpl_tests/rpl_binlog_max_cache_size.test: updated suppression pattern mysql-test/extra/rpl_tests/rpl_insert_id.test: updated suppression pattern mysql-test/extra/rpl_tests/rpl_loaddata.test: updated suppression pattern mysql-test/extra/rpl_tests/rpl_mixing_engines.test: updated suppression pattern mysql-test/extra/rpl_tests/rpl_start_stop_slave.test: updated suppression pattern mysql-test/extra/rpl_tests/rpl_stm_000001.test: updated suppression pattern mysql-test/extra/rpl_tests/rpl_stop_middle_group.test: updated suppression pattern mysql-test/r/archive.result: updated result file mysql-test/r/commit_1innodb.result: updated result file mysql-test/r/ctype_cp932_binlog_stm.result: updated result file mysql-test/r/partition_innodb_stmt.result: updated result file mysql-test/suite/binlog/r/binlog_innodb.result: updated result file mysql-test/suite/binlog/r/binlog_killed.result: updated result file mysql-test/suite/binlog/r/binlog_multi_engine.result: updated result file mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: updated result file mysql-test/suite/binlog/r/binlog_statement_insert_delayed.result: updated result file mysql-test/suite/binlog/r/binlog_stm_blackhole.result: updated result file mysql-test/suite/binlog/r/binlog_stm_do_db.result: updated result file mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: updated result file mysql-test/suite/binlog/r/binlog_stm_ps.result: updated result file mysql-test/suite/binlog/r/binlog_stm_row.result: updated result file mysql-test/suite/binlog/r/binlog_stm_unsafe_warning.result: updated result file mysql-test/suite/binlog/r/binlog_unsafe.result: updated result file mysql-test/suite/binlog/t/binlog_killed.test: updated suppression pattern mysql-test/suite/binlog/t/binlog_multi_engine.test: updated suppression pattern mysql-test/suite/binlog/t/binlog_statement_insert_delayed.test: updated suppression pattern mysql-test/suite/binlog/t/binlog_stm_ps.test: updated suppression pattern mysql-test/suite/binlog/t/binlog_stm_row.test: updated suppression pattern mysql-test/suite/binlog/t/binlog_stm_unsafe_warning.test: updated suppression pattern mysql-test/suite/binlog/t/binlog_tmp_table.test: updated suppression pattern mysql-test/suite/binlog/t/binlog_unsafe.test: updated suppression pattern mysql-test/suite/ndb/r/ndb_binlog_format.result: updated result file mysql-test/suite/ndb/t/ndb_binlog_format.test: updated suppression pattern mysql-test/suite/perfschema/r/binlog_stmt.result: updated result file mysql-test/suite/perfschema/t/binlog_stmt.test: updated suppression pattern mysql-test/suite/rpl/r/rpl_begin_commit_rollback.result: updated result file mysql-test/suite/rpl/r/rpl_blackhole.result: updated result file mysql-test/suite/rpl/r/rpl_concurrency_error.result: updated result file mysql-test/suite/rpl/r/rpl_get_lock.result: updated result file mysql-test/suite/rpl/r/rpl_insert_id.result: updated result file mysql-test/suite/rpl/r/rpl_insert_ignore.result: updated result file mysql-test/suite/rpl/r/rpl_misc_functions.result: updated result file mysql-test/suite/rpl/r/rpl_mixed_binlog_max_cache_size.result: updated result file mysql-test/suite/rpl/r/rpl_mixed_mixing_engines.result: updated result file mysql-test/suite/rpl/r/rpl_mysql_upgrade.result: updated result file mysql-test/suite/rpl/r/rpl_non_direct_mixed_mixing_engines.result: updated result file mysql-test/suite/rpl/r/rpl_non_direct_row_mixing_engines.result: updated result file mysql-test/suite/rpl/r/rpl_non_direct_stm_mixing_engines.result: updated result file mysql-test/suite/rpl/r/rpl_nondeterministic_functions.result: updated result file mysql-test/suite/rpl/r/rpl_read_only.result: updated result file mysql-test/suite/rpl/r/rpl_row_binlog_max_cache_size.result: updated result file mysql-test/suite/rpl/r/rpl_row_inexist_tbl.result: updated result file mysql-test/suite/rpl/r/rpl_row_mixing_engines.result: updated result file mysql-test/suite/rpl/r/rpl_slow_query_log.result: updated result file mysql-test/suite/rpl/r/rpl_sp.result: updated result file mysql-test/suite/rpl/r/rpl_stm_000001.result: updated result file mysql-test/suite/rpl/r/rpl_stm_auto_increment_bug33029.result: updated result file mysql-test/suite/rpl/r/rpl_stm_binlog_max_cache_size.result: updated result file mysql-test/suite/rpl/r/rpl_stm_loadfile.result: updated result file mysql-test/suite/rpl/r/rpl_stm_mixing_engines.result: updated result file mysql-test/suite/rpl/r/rpl_stm_start_stop_slave.result: updated result file mysql-test/suite/rpl/r/rpl_stm_stop_middle_group.result: updated result file mysql-test/suite/rpl/r/rpl_temp_temporary.result: updated result file mysql-test/suite/rpl/r/rpl_variables_stm.result: updated result file mysql-test/suite/rpl/t/rpl000013.test: updated suppression pattern mysql-test/suite/rpl/t/rpl_begin_commit_rollback.test: updated suppression pattern mysql-test/suite/rpl/t/rpl_blackhole.test: updated suppression pattern mysql-test/suite/rpl/t/rpl_concurrency_error.test: updated suppression pattern mysql-test/suite/rpl/t/rpl_err_ignoredtable.test: updated suppression pattern mysql-test/suite/rpl/t/rpl_get_lock.test: updated suppression pattern mysql-test/suite/rpl/t/rpl_insert.test: updated suppression pattern mysql-test/suite/rpl/t/rpl_insert_id.test: updated suppression pattern mysql-test/suite/rpl/t/rpl_insert_ignore.test: updated suppression pattern mysql-test/suite/rpl/t/rpl_invoked_features.test: updated suppression pattern mysql-test/suite/rpl/t/rpl_misc_functions.test: updated suppression pattern mysql-test/suite/rpl/t/rpl_mixed_bit_pk.test: updated suppression pattern mysql-test/suite/rpl/t/rpl_mysql_upgrade.test: updated suppression pattern mysql-test/suite/rpl/t/rpl_nondeterministic_functions.test: updated suppression pattern mysql-test/suite/rpl/t/rpl_optimize.test: updated suppression pattern mysql-test/suite/rpl/t/rpl_read_only.test: updated suppression pattern mysql-test/suite/rpl/t/rpl_semi_sync.test: updated suppression pattern mysql-test/suite/rpl/t/rpl_semi_sync_event.test: updated suppression pattern mysql-test/suite/rpl/t/rpl_session_var.test: updated suppression pattern mysql-test/suite/rpl/t/rpl_slow_query_log.test: updated suppression pattern mysql-test/suite/rpl/t/rpl_sp.test: updated suppression pattern mysql-test/suite/rpl/t/rpl_stm_auto_increment_bug33029.test: updated suppression pattern mysql-test/suite/rpl/t/rpl_stm_found_rows.test: updated suppression pattern mysql-test/suite/rpl/t/rpl_stm_insert_delayed.test: updated suppression pattern mysql-test/suite/rpl/t/rpl_stm_loadfile.test: updated suppression pattern mysql-test/suite/rpl/t/rpl_temp_table.test: updated suppression pattern mysql-test/suite/rpl/t/rpl_temp_temporary.test: updated suppression pattern mysql-test/suite/rpl/t/rpl_temporary.test: updated suppression pattern mysql-test/suite/rpl/t/rpl_timezone.test: updated suppression pattern mysql-test/suite/rpl/t/rpl_trigger.test: updated suppression pattern mysql-test/suite/rpl/t/rpl_udf.test: updated suppression pattern mysql-test/suite/rpl/t/rpl_user_variables.test: updated suppression pattern mysql-test/suite/rpl/t/rpl_variables_stm.test: updated suppression pattern mysql-test/suite/rpl/t/rpl_view_multi.test: updated suppression pattern mysql-test/suite/rpl_ndb/r/rpl_ndb_binlog_format_errors.result: updated result file mysql-test/suite/rpl_ndb/t/rpl_ndb_binlog_format_errors.test: updated suppression pattern mysql-test/suite/rpl_ndb/t/rpl_ndb_stm_innodb.test: updated suppression pattern mysql-test/suite/sys_vars/t/rpl_init_slave_func.test: updated suppression pattern mysql-test/t/archive.test: updated suppression pattern mysql-test/t/commit_1innodb.test: updated suppression pattern mysql-test/t/create_select_tmp.test: updated suppression pattern mysql-test/t/ctype_cp932_binlog_stm.test: updated suppression pattern mysql-test/t/lock_sync.test: updated suppression pattern mysql-test/t/mysqlbinlog.test: updated suppression pattern mysql-test/t/mysqldump.test: updated suppression pattern mysql-test/t/sp_trans.test: updated suppression pattern sql/log_event.cc: Clarified error message. sql/share/errmsg-utf8.txt: Clarified error messages.
2010-04-28 14:47:49 +02:00
call mtr.add_suppression("Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT");
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'configure';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo #########################################################################
--echo # 1 - MIXING TRANSACTIONAL and NON-TRANSACTIONAL TABLES
--echo #########################################################################
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
connection master;
--echo
--echo
--echo
--echo
--echo #
--echo #1) Generates in the binlog what follows:
--echo # --> STMT "B T C" entries, format S.
--echo # --> ROW "B T C" entries, format R.
--echo # --> MIXED "B T C" entries, format S.
--echo #
SET @commands= 'T';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'T-trig';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'T-func';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'T-proc';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo
--echo
--echo
--echo
--echo #
--echo #1.e) Generates in the binlog what follows:
--echo # --> STMT empty.
--echo # --> ROW empty.
--echo # --> MIXED empty.
--echo #
SET @commands= 'eT';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'Te';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'Te-trig';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'Te-func';
--source extra/rpl_tests/rpl_mixing_engines.inc
--echo
--echo
--echo
--echo
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo #
--echo #2) Generates in the binlog what follows:
--echo # --> STMT "B N C" entry, format S.
--echo # --> ROW "B N C" entry, format R.
--echo # --> MIXED "B N C" entry, format S.
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo #
SET @commands= 'N';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'N-trig';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'N-func';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'N-proc';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo
--echo
--echo
--echo
--echo #
--echo #2.e) Generates in the binlog what follows if a N-table is changed:
--echo # --> STMT "B N C" entry, format S.
--echo # --> ROW "B N C" entry, format R.
--echo # --> MIXED "B N C" entry, format S.
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo #
SET @commands= 'eN';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'Ne';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'Ne-trig';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'Ne-func';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo
--echo
--echo
--echo
--echo #
--echo #3) Generates in the binlog what follows:
--echo # --> STMT "B M C" entry if only N-Table is changed, format S.
--echo # --> STMT "B M C" entries, format S.
--echo # --> ROW "B N T B T C" entries, format R.
--echo # --> MIXED "B N T B T C" entries, format R.
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo #
SET @commands= 'tN';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'nT';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'NT';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'NT-trig';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'NT-func';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'TN';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'TN-trig';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'TN-func';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo
--echo
--echo
--echo
--echo #
--echo #3.e) Generates in the binlog what follows:
--echo # --> STMT "B M C" entry if only N-Table is changed, format S.
--echo # --> STMT "B M R" entries, format S.
--echo # --> ROW "B N C" entry, format R.
--echo # --> MIXED "B N C" entry, format R.
SET @commands= 'tNe';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'nTe';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'NeT-trig';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'NeT-func';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'TeN-trig';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'TeN-func';
--source extra/rpl_tests/rpl_mixing_engines.inc
--echo
--echo
--echo
--echo
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo #
--echo #4) Generates in the binlog what follows:
--echo # --> STMT "B T T C" entries, format S.
--echo # --> ROW "B T T C" entries, format R.
--echo # --> MIXED "B T T C" entries, format S
--echo #
SET @commands= 'B T T C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T T-trig C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T T-func C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T T-proc C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T-trig T C';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B T-trig T-trig C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T-trig T-func C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T-trig T-proc C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T-func T C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T-func T-trig C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T-func T-func C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T-func T-proc C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T-proc T C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T-proc T-trig C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T-proc T-func C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T-proc T-proc C';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo
--echo
--echo
--echo
--echo #
--echo #4.e) Generates in the binlog what follows:
--echo # --> STMT "B T C" entries, format S.
--echo # --> ROW "B T C" entries, format R.
--echo # --> MIXED "B T C" entries, format S.
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo #
SET @commands= 'B T eT C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T Te C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T Te-trig C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T Te-func C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B eT T C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B Te T C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B Te-trig T C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B Te-func T C';
--source extra/rpl_tests/rpl_mixing_engines.inc
--echo
--echo
--echo
--echo
--echo #
--echo #5) Generates in the binlog what follows:
--echo # --> STMT empty.
--echo # --> ROW empty.
--echo # --> MIXED empty.
--echo #
SET @commands= 'B T T R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T T-trig R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T T-func R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T T-proc R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T-trig T R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T-trig T-trig R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T-trig T-func R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T-trig T-proc R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T-func T R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T-func T-trig R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T-func T-func R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T-func T-proc R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T-proc T R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T-proc T-trig R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T-proc T-func R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T-proc T-proc R';
--source extra/rpl_tests/rpl_mixing_engines.inc
--echo
--echo
--echo
--echo
--echo #
--echo #5.e) Generates in the binlog what follows:
--echo # --> STMT empty.
--echo # --> ROW empty.
--echo # --> MIXED empty.
--echo #
SET @commands= 'B T eT R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T Te R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T Te-trig R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T Te-func R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B eT T R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B Te T R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B Te-trig T R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B Te-func T R';
--source extra/rpl_tests/rpl_mixing_engines.inc
--echo
--echo
--echo
--echo
--echo #
--echo #6) Generates in the binlog what follows:
--echo # --> STMT "B N C B N C" entries, format S.
--echo # --> ROW "B N C B N C" entries, format R.
--echo # --> MIXED "B N C B N C" entries, format S.
--echo #
SET @commands= 'B N N C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N N-trig C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N N-func C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N N-proc C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N-trig N C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N-trig N-trig C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N-trig N-func C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N-trig N-proc C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N-func N C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N-func N-trig C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N-func N-func C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N-func N-proc C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N-proc N C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N-proc N-trig C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N-proc N-func C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N-proc N-proc C';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo
--echo
--echo
--echo
--echo #
--echo #6.e) Generates in the binlog what follows if a N-Table is changed:
--echo # --> STMT "B N C B N C" entries, format S.
--echo # --> ROW "B N C B N C" entries, format R.
--echo # --> MIXED "B N C B N C" entries, format S.
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo #
SET @commands= 'B N eN C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N Ne C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N Ne-trig C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N Ne-func C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B eN N C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B Ne N C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B Ne-trig N C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B Ne-func N C';
--source extra/rpl_tests/rpl_mixing_engines.inc
--echo
--echo
--echo
--echo
--echo #
--echo #7) Generates in the binlog what follows:
--echo # --> STMT "B N C B N C" entries, format S.
--echo # --> ROW "B N C B N C" entries, format R.
--echo # --> MIXED "B N C B N C" entries, format S.
--echo #
SET @commands= 'B N N R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N N-trig R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N N-func R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N N-proc R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N-trig N R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N-trig N-trig R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N-trig N-func R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N-trig N-proc R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N-func N R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B N-func N-trig R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N-func N-func R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N-func N-proc R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N-proc N R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N-proc N-trig R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N-proc N-func R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N-proc N-proc R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo
--echo
--echo
--echo
--echo #
--echo #7.e) Generates in the binlog what follows if a N-Table is changed:
--echo # --> STMT "B N C B N C" entries, format S.
--echo # --> ROW "B N C B N C" entries, format R.
--echo # --> MIXED "B N C B N C" entries, format S.
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo #
SET @commands= 'B N eN R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N Ne R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N Ne-trig R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N Ne-func R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B eN N R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B Ne N R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B Ne-trig N R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B Ne-func N R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo
--echo
--echo
--echo
--echo #
--echo #8) Generates in the binlog what follows:
--echo # --> STMT "B T N C" entries, format S.
--echo # --> ROW "B N C B T C" entries, format R.
--echo # --> MIXED "B N C B T C" entries, format R in N and S in T.
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo #
SET @commands= 'B T N C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T N-trig C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T N-func C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T N-proc C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T-trig N C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T-trig N-trig C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T-trig N-func C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T-trig N-proc C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T-func N C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T-func N-trig C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T-func N-func C';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B T-func N-proc C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T-proc N C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T-proc N-trig C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T-proc N-func C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T-proc N-proc C';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo
--echo
--echo
--echo
--echo #
--echo #8.e) Generates in the binlog what follows if T-* fails:
--echo # --> STMT "B N C" entry, format S.
--echo # --> ROW "B N C" entry, format R.
--echo # --> MIXED "B N C" entry, format R.
--echo # Otherwise, what follows if N-* fails and a N-Table is changed:
--echo # --> STMT "B T N C" entries, format S.
--echo # --> ROW "B N C B T C" entries, format R.
--echo # --> MIXED "B N C B T C" entries, format R in N and S in T.
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo #
SET @commands= 'B eT N C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B Te N C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T eN C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T Ne C';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo
--echo
--echo
--echo
--echo #
--echo #9) Generates in the binlog what follows:
--echo # --> STMT "B T N R" entries, format S.
--echo # --> ROW "B N C" entry, format R.
--echo # --> MIXED "B N C" entry, format R.
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo #
SET @commands= 'B T N R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T N-trig R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T N-func R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T N-proc R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T-trig N R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T-trig N-trig R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T-trig N-func R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T-trig N-proc R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T-func N R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T-func N-trig R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T-func N-func R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T-func N-proc R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T-proc N R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T-proc N-trig R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T-proc N-func R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T-proc N-proc R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo
--echo
--echo
--echo
--echo #
--echo #9.e) Generates in the binlog what follows if T* fails:
--echo # --> STMT "B N C" entry, format S.
--echo # --> ROW "B N C" entry, format R.
--echo # --> MIXED "B N C" entry, format R.
--echo # Otherwise, what follows if N* fails and a N-Table is changed:
--echo # --> STMT "B T N R" entries, format S.
--echo # --> ROW "B N C" entry, format R.
--echo # --> MIXED "B N C" entry, format R.
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo #
SET @commands= 'B eT N R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B Te N R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T eN R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T Ne R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo
--echo
--echo
--echo
--echo #
--echo #10) Generates in the binlog:
--echo # --> STMT "B N C B T C" entries, format S.
--echo # --> ROW "B N C B T C" entries, format R.
--echo # --> MIXED "B N C B T C" entries, format S.
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo #
SET @commands= 'B N T C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N T-trig C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N T-func C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N T-proc C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N-trig T C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N-trig T-trig C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N-trig T-func C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N-trig T-proc C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N-func T C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N-func T-trig C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N-func T-func C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N-func T-proc C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N-proc T C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N-proc T-trig C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N-proc T-func C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N-proc T-proc C';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo
--echo
--echo
--echo
--echo #
--echo #11) Generates in the binlog what follows:
--echo # --> STMT "B N C" entries, format S.
--echo # --> ROW "B N C" entries, format R.
--echo # --> MIXED "B N C" entries, format S.
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo #
SET @commands= 'B N T R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B N T-proc R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B N T-trig R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B N T-func R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B N-trig T R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B N-trig T-trig R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B N-trig T-func R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B N-trig T-proc R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B N-func T R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B N-func T-trig R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B N-func T-func R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B N-func T-proc R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B N-proc T R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B N-proc T-proc R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B N-proc T-trig R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B N-proc T-func R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo
--echo
--echo
--echo
--echo #
--echo #12) Generates in the binlog what follows:
--echo # --> STMT "B M C B T C" entries if in M only N-Table is changed, format S.
--echo # --> STMT "B M T C" entries, format S.
--echo # --> ROW "B N C B T T C" entries, format R.
--echo # --> MIXED "B N C B T T C" entries, format R in N/T and format S in T.
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo #
SET @commands= 'B tN T C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B nT T C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B NT T C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B NT-trig T C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B NT-func T C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B TN T C';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B TN-trig T C';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B TN-func T C';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo
--echo
--echo
--echo
--echo #
--echo #12.e) Generates in the binlog what follows if a N-Table is changed:
--echo # --> STMT "B M C B T C" entries if in M only N-Table is changed, format S.
--echo # --> STMT "B M T C" entries, format S.
--echo # --> ROW "B N C B T T C" entries, format R.
--echo # --> MIXED "B N C B T T C" entries, format R in N/T and format S in T.
--echo #
SET @commands= 'B tNe T C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B nTe T C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B NeT-trig T C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B NeT-func T C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B TeN-trig T C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B TeN-func T C';
--source extra/rpl_tests/rpl_mixing_engines.inc
--echo
--echo
--echo
--echo
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo #
--echo #13) "B M T R" generates in the binlog:
--echo # --> STMT "B M C B T R" entries if in M only N-Table is changed, format S.
--echo # --> STMT "B M T R" entries, format S.
--echo # --> ROW "B N C" entry, format R.
--echo # --> MIXED "B N C" entry, format R.
--echo #
SET @commands= 'B tN T R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B nT T R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B NT T R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B NT-trig T R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B NT-func T R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B TN T R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B TN-trig T R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B TN-func T R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo
--echo
--echo
--echo
--echo #
--echo #13.e) Generates in the binlog what follows if a N-Table is changed:
--echo # --> STMT "B M C B T R" entries if in M only N-Table is changed, format S.
--echo # --> STMT "B M T R" entries, format S.
--echo # --> ROW "B N C" entry, format R.
--echo # --> MIXED "B N C" entry, format R.
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo #
SET @commands= 'B tNe T R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B nTe T R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B NeT-trig T R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B NeT-func T R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B TeN-trig T R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B TeN-func T R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo
--echo
--echo
--echo
--echo #
--echo #14) Generates in the binlog what follows if a N-Table is changed:
--echo # --> STMT "B T M C" entries, format S.
--echo # --> ROW "B N C B T T C" entries, format R.
--echo # --> MIXED "B N C B T T C" entries, format R in N/T and format S in T.
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo #
SET @commands= 'B T tN C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T nT C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T NT C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T NT-trig C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T NT-func C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T TN C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T TN-trig C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T TN-func C';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo
--echo
--echo
--echo
--echo #
--echo #14.e) Generates in the binlog what follows if a N-Table is changed:
--echo # --> STMT "B T M C" entries, format S.
--echo # --> ROW "B N C B T C" entry, format R.
--echo # --> MIXED "B N C B T C" entry, format R.
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo #
SET @commands= 'B T tNe C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T nTe C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T NeT-trig C';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B T NeT-func C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T TeN-trig C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T TeN-func C';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo
--echo
--echo
--echo
--echo #
--echo #15) Generates in the binlog what follows if a N-Table is changed:
--echo # --> STMT "B T M R" entries, format S.
--echo # --> ROW "B N C" entry, format R.
--echo # --> MIXED "B N C" entry, format R.
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo #
SET @commands= 'B T tN R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T nT R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T NT R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T NT-trig R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T NT-func R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T TN R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T TN-trig R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T TN-func R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo
--echo
--echo
--echo
--echo #
--echo #15.e) Generates in the binlog what follows if a N-Table is changed:
--echo # --> STMT "B T M R" entries, format S.
--echo # --> ROW "B N C" entry, format R.
--echo # --> MIXED "B N C" entry, format R.
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo #
SET @commands= 'B T tNe R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T nTe R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T NeT-trig R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T NeT-func R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T TeN-trig R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T TeN-func R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo
--echo
--echo
--echo
--echo #
--echo #16) Generates in the binlog what follows if a N-Table is changed:
--echo # --> STMT "B M C B N C" entries if in M only N-Table is changed, format S.
--echo # --> STMT "B M N C" entries, format S.
--echo # --> ROW "B N C B N C B T C" entries, format R.
--echo # --> MIXED "B M C B N C" entries if in M only N-Table is changed, format S.
--echo # --> MIXED "B N C B N C B T C" entries, format R.
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo #
SET @commands= 'B tN N C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B nT N C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B NT N C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B NT-trig N C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B NT-func N C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B TN N C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B TN-trig N C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B TN-func N C';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo
--echo
--echo
--echo
--echo #
--echo #16.e) Generates in the binlog what follows if a N-Table is changed:
--echo # --> STMT "B M C B N C" entries if in M only N-Table is changed, format S.
--echo # --> STMT "B M N C" entries, format S.
--echo # --> ROW "B N C B N C B T C" entries, format R.
--echo # --> MIXED "B M C B N C" entries if in M only N-Table is changed, format S.
--echo # --> MIXED "B N C B N C B T C" entries, format R.
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo #
SET @commands= 'B tNe N C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B nTe N C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B NeT-trig N C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B NeT-func N C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B TeN-trig N C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B TeN-func N C';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo
--echo
--echo
--echo
--echo #
--echo #17) Generates in the binlog what follows if a N-Table is changed:
--echo # --> STMT "B M C B N C" entries if in M only N-Table is changed, format S.
--echo # --> STMT "B M N R" entries, format S.
--echo # --> ROW "B N C B N C" entries, format R.
--echo # --> MIXED "B M C B N C" entries if in M only N-Table is changed, format S.
--echo # --> MIXED "B N C B N C" entries, format R.
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo #
SET @commands= 'B tN N R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B nT N R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B NT N R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B NT-trig N R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B NT-func N R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B TN N R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B TN-trig N R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B TN-func N R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo
--echo
--echo
--echo
--echo #
--echo #17.e) Generates in the binlog what follows if a N-Table is changed:
--echo # --> STMT "B M C B N C" entries if in M only N-Table is changed, format S.
--echo # --> STMT "B M N R" entries, format S.
--echo # --> ROW "B N C B N C" entries, format R.
--echo # --> MIXED "B M C B N C" entries if in M only N-Table is changed, format S.
--echo # --> MIXED "B N C B N C" entries, format R.
--echo #
SET @commands= 'B tNe N R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B nTe N R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B NeT-trig N R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B NeT-func N R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B TeN-trig N R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B TeN-func N R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo
--echo
--echo
--echo
--echo #
--echo #18) Generates in the binlog what follows if a N-Table is changed:
--echo # --> STMT "B N C B M C" entries if in M only N-Table is changed, format S.
--echo # --> STMT "B N C B M C" entries, format S.
--echo # --> ROW "B N C B N C B T C" entries, format R.
--echo # --> MIXED "B N C B N C B T C" entries, format S in first N and format R in the other.
--echo #
SET @commands= 'B N tN C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N nT C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N NT C';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B N NT-trig C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N NT-func C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N TN C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N TN-trig C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N TN-func C';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo
--echo
--echo
--echo
--echo #
--echo #18.e) Generates in the binlog what follows if a N-Table is changed:
--echo # --> STMT "B N C B M C" entries if in M only N-Table is changed, format S.
--echo # --> STMT "B N C B M C" entries, format S.
--echo # --> ROW "B N C B N C" entries, format R.
--echo # --> MIXED "B N C B N C" entries, format S in first N and format R in the other.
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo #
SET @commands= 'B N tNe C';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B N nTe C';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B N NeT-trig C';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B N NeT-func C';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B N TeN-trig C';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B N TeN-func C';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo
--echo
--echo
--echo
--echo #
--echo #19) Generates in the binlog what follows if a N-Table is changed:
--echo # --> STMT "B N C B M C" entries if in M only N-Table is changed, format S.
--echo # --> STMT "B N C B M R" entries, format S.
--echo # --> ROW "B N C B N C" entries, format R.
--echo # --> MIXED "B N C B N C" entries, format S in first N and format R in the other.
--echo #
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B N tN R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B N nT R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B N NT R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B N NT-trig R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B N NT-func R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B N TN R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N TN-trig R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N TN-func R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo
--echo
--echo
--echo
--echo #
--echo #19.e) Generates in the binlog what follows if a N-Table is changed:
--echo # --> STMT "B N C B M C" entries if in M only N-Table is changed, format S.
--echo # --> STMT "B N C B M R" entries, format S.
--echo # --> ROW "B N C B N C" entries, format R.
--echo # --> MIXED "B N C B N C" entries, format S in first N and format R in the other.
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo #
SET @commands= 'B N tNe R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B N nTe R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B N NeT-trig R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B N NeT-func R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B N TeN-trig R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B N TeN-func R';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo ###################################################################################
--echo # 2 - SAVEPOINT
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo ###################################################################################
SET @commands= 'B T S1 T R1 C';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
SET @commands= 'B N T S1 T R1 C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T N S1 T R1 C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T S1 N T R1 C';
--source extra/rpl_tests/rpl_mixing_engines.inc
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
--echo ###################################################################################
--echo # 3 - CREATE TABLE...SELECT
--echo ###################################################################################
SET @commands= 'CSe-T->T CS-T->T drop-CS';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'CSe-N->N CS-N->N drop-CS';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'CSe-T->N CS-T->N drop-CS';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'CSe-N->T CS-N->T drop-CS';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'CSe-N->T CS-N->T drop-CS';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'CSe-N->T CS-N->T drop-CS';
--source extra/rpl_tests/rpl_mixing_engines.inc
--echo ###################################################################################
--echo # 4 - INSERT TABLE...SELECT
--echo ###################################################################################
SET @commands= 'CS-T->T';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'trunc-CS-T B T IS-T<-N T C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'trunc-CS-T B T ISe-T<-N T C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'trunc-CS-T B IS-T<-N T C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'trunc-CS-T B ISe-T<-N T C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'drop-CS';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'CS-T->T';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'trunc-CS-T B T IS-T<-T T C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'trunc-CS-T B T ISe-T<-T T C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'trunc-CS-T B IS-T<-T T C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'trunc-CS-T B ISe-T<-T T C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'drop-CS';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'CS-N->N';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'trunc-CS-N B T IS-N<-T T C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'trunc-CS-N B T ISe-N<-T T C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'trunc-CS-N B IS-N<-T T C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'trunc-CS-N B ISe-N<-T T C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'drop-CS';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'CS-N->N';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'trunc-CS-N B T IS-N<-N T C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'trunc-CS-N B T ISe-N<-N T C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'trunc-CS-N B IS-N<-N T C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'trunc-CS-N B ISe-N<-N T C';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'drop-CS';
--source extra/rpl_tests/rpl_mixing_engines.inc
--echo ###################################################################################
--echo # 5 - ROLLBACK TEMPORARY TABLE
--echo ###################################################################################
SET @commands= 'B T CT R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'drop-CT';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T S1 T CT R1 R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'drop-CT';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B T CT T R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'drop-CT';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B tN CT T R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'drop-CT';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B CT T R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'drop-CT';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'B N CT T R';
--source extra/rpl_tests/rpl_mixing_engines.inc
SET @commands= 'drop-CT';
--source extra/rpl_tests/rpl_mixing_engines.inc
--echo ###################################################################################
--echo # CHECK CONSISTENCY
--echo ###################################################################################
connection master;
BUG#28976 Mixing trans and non-trans tables in one transaction results in incorrect binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
2009-08-27 01:13:03 +02:00
sync_slave_with_master;
--exec $MYSQL_DUMP --compact --order-by-primary --skip-extended-insert --no-create-info test > $MYSQLTEST_VARDIR/tmp/test-nmt-master.sql
--exec $MYSQL_DUMP_SLAVE --compact --order-by-primary --skip-extended-insert --no-create-info test > $MYSQLTEST_VARDIR/tmp/test-nmt-slave.sql
BUG#51291 Unfortunate effect around variable binlog_direct_non_transactional_updates BUG#46364 introduced the flag binlog_direct_non_transactional_updates which would make N-changes to be written to the binary log upon committing the statement when "ON". On the other hand, when "OFF" the option was supposed to mimic the behavior in 5.1. However, the implementation was not mimicking the behavior correctly and the following bugs popped up: Case #1: N-changes executed within a transaction would go into the S-cache. When later in the same transaction a T-change occurs, N-changes following it were written to the T-cache instead of the S-cache. In some cases, this raises problems. For example, a Table_map_log_event being written initially into the S-cache, together with the initial N-changes, would be absent from the T-cache. This would log N-changes orphaned from a Table_map_log_event (thence discarded at the slave). (MIXED and ROW) Case #2: When rolling back a transaction, the N-changes that might be in the T-cache were disregarded and truncated along with the T-changes. (MIXED and ROW) Case #3: When a MIXED statement (TN) is ahead of any other T-changes in the transaction and it fails, it is kept in the T-cache until the transaction ends. This is not the case in 5.1 or Betony (5.5.2). In these, the failed TN statement would be written to the binlog at the same instant it had failed and not deferred until transaction end. (SBR) To fix these problems, we have decided to do what follows: For Case #1 and #2, we circumvent them: 1. by not letting binlog_direct_non_transactional_updates affect MIXED and RBR. These modes will keep the behavior provided by WL#2687. Although this will make Celosia to behave differently from 5.1, an execution will be always safe under such modes in the sense that slaves will never go out sync. In 5.1, using either MIXED or ROW while mixing N-statements and T-statements was not safe. For Case #3, we don't actually fix it. We: 1. keep it and make all MIXED statements whether they end up failing or not or whether they are up front in the transaction or after some transactional change to always be stored in the T-cache. This means that it is written to the binary log on transaction commit/rollback only. 2. We make the warning message even more specific about the MIXED statement and SBR. mysql-test/extra/rpl_tests/rpl_mixing_engines.test: Updated the test case to avoid checking inconsistencies between the master and slave when session.binlog_direct_non_transactional_updates is ON and the format is statement. In this scenario, they will diverge because a counter (within a triger) is incremented and associated to the issued statement. However, an n-statement is logged ahead of the transaction and thus is not executed by the same order in the slave and thus gets a different value from the counter. mysql-test/suite/binlog/r/binlog_multi_engine.result: Updated the test case with the new error ER_BINLOG_UNSAFE_MIXED_STATEMENT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Updated the test case with the new error ER_BINLOG_UNSAFE_MIXED_STATEMENT. mysql-test/suite/ndb/r/ndb_binlog_format.result: Updated the test case with the new error ER_BINLOG_UNSAFE_MIXED_STATEMENT. mysql-test/suite/rpl/r/rpl_concurrency_error.result: Updated the test case with the new error ER_BINLOG_UNSAFE_MIXED_STATEMENT. mysql-test/suite/rpl/r/rpl_stm_binlog_max_cache_size.result: Updated the test case with the new error ER_BINLOG_UNSAFE_MIXED_STATEMENT. mysql-test/suite/rpl/r/rpl_stm_mixing_engines.result: Updated the test case with the new error ER_BINLOG_UNSAFE_MIXED_STATEMENT. mysql-test/suite/rpl/r/rpl_stm_stop_middle_group.result: Updated the test case with the new error ER_BINLOG_UNSAFE_MIXED_STATEMENT. sql/log.cc: Checked if either a trx-cache or a non-trx-cache should be used. If bin_log_direct_non_trans_update is active or the format is either MIXED or ROW, the cache to be used depends on the flag is_transactional. When the format is STMT, the non-trx-cache should be used if the statement is non-transactional and the trx-cache is empty, i.e. if any transactional statement has not committed yet. Otherwise, the trx-cache should be used. sql/share/errmsg-utf8.txt: Added the new unsafe error ER_BINLOG_UNSAFE_MIXED_STATEMENT. sql/sql_class.cc: Started printing ER_BINLOG_UNSAFE_MIXED_STATEMENT, when there is a mixed-statement. Organized the names of the variables and added comments. sql/sql_lex.cc: Added the new unsafe error ER_BINLOG_UNSAFE_MIXED_STATEMENT. sql/sql_lex.h: Added the new unsafe error ER_BINLOG_UNSAFE_MIXED_STATEMENT.
2010-03-31 15:22:47 +02:00
if (`select @@session.binlog_direct_non_transactional_updates = 0 || @@session.binlog_format != 'STATEMENT'`)
Manual merge of patch for Bug#46364 from mysql-next-mr-bugfixing. Conflicts: - mysql-test/r/mysqld--help-win.result - sql/sys_vars.cc Original revsion (in next-mr-bugfixing): ------------------------------------------------------------ revno: 2971 [merge] revision-id: alfranio.correia@sun.com-20100121210527-rbuheu5rnsmcakh1 committer: Alfranio Correia <alfranio.correia@sun.com> branch nick: mysql-next-mr-bugfixing timestamp: Thu 2010-01-21 21:05:27 +0000 message: BUG#46364 MyISAM transbuffer problems (NTM problem) It is well-known that due to concurrency issues, a slave can become inconsistent when a transaction contains updates to both transaction and non-transactional tables. In a nutshell, the current code-base tries to preserve causality among the statements by writing non-transactional statements to the txn-cache which is flushed upon commit. However, modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections but may not immediately get into the binary log and therefore consistency may be broken. In general, it is impossible to automatically detect causality/dependency among statements by just analyzing the statements sent to the server. This happen because dependency may be hidden in the application code and it is necessary to know a priori all the statements processed in the context of a transaction such as in a procedure. Moreover, even for the few cases that we could automatically address in the server, the computation effort required could make the approach infeasible. So, in this patch we introduce the option - "--binlog-direct-non-transactional-updates" that can be used to bypass the current behavior in order to write directly to binary log statements that change non-transactional tables. Besides, it is used to enable the WL#2687 which is disabled by default. ------------------------------------------------------------ revno: 2970.1.1 revision-id: alfranio.correia@sun.com-20100121131034-183r4qdyld7an5a0 parent: alik@sun.com-20100121083914-r9rz2myto3tkdya0 committer: Alfranio Correia <alfranio.correia@sun.com> branch nick: mysql-next-mr-bugfixing timestamp: Thu 2010-01-21 13:10:34 +0000 message: BUG#46364 MyISAM transbuffer problems (NTM problem) It is well-known that due to concurrency issues, a slave can become inconsistent when a transaction contains updates to both transaction and non-transactional tables. In a nutshell, the current code-base tries to preserve causality among the statements by writing non-transactional statements to the txn-cache which is flushed upon commit. However, modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections but may not immediately get into the binary log and therefore consistency may be broken. In general, it is impossible to automatically detect causality/dependency among statements by just analyzing the statements sent to the server. This happen because dependency may be hidden in the application code and it is necessary to know a priori all the statements processed in the context of a transaction such as in a procedure. Moreover, even for the few cases that we could automatically address in the server, the computation effort required could make the approach infeasible. So, in this patch we introduce the option - "--binlog-direct-non-transactional-updates" that can be used to bypass the current behavior in order to write directly to binary log statements that change non-transactional tables. Besides, it is used to enable the WL#2687 which is disabled by default.
2010-02-02 08:56:42 +01:00
{
--diff_files $MYSQLTEST_VARDIR/tmp/test-nmt-master.sql $MYSQLTEST_VARDIR/tmp/test-nmt-slave.sql
}
--echo ###################################################################################
--echo # CLEAN
--echo ###################################################################################
SET @commands= 'clean';
--source extra/rpl_tests/rpl_mixing_engines.inc