You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

664 lines
16 KiB

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.
16 years ago
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.
16 years ago
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.
16 years ago
BUG#51894 Replication failure with SBR on DROP TEMPORARY TABLE inside a transaction BUG#52616 Temp table prevents switch binlog format from STATEMENT to ROW Before the WL#2687 and BUG#46364, every non-transactional change that happened after a transactional change was written to trx-cache and flushed upon committing the transaction. WL#2687 and BUG#46364 changed this behavior and non-transactional changes are now written to the binary log upon committing the statement. A binary log event is identified as transactional or non-transactional through a flag in the Log_event which is set taking into account the underlie storage engine on what it is stems from. In the current bug, this flag was not being set properly when the DROP TEMPORARY TABLE was executed. However, while fixing this bug we figured out that changes to temporary tables should be always written to the trx-cache if there is an on-going transaction. Otherwise, binlog events in the reversed order would be produced. Regarding concurrency, keeping changes to temporary tables in the trx-cache is also safe as temporary tables are only visible to the owner connection. In this patch, we classify the following statements as unsafe: 1 - INSERT INTO t_myisam SELECT * FROM t_myisam_temp 2 - INSERT INTO t_myisam_temp SELECT * FROM t_myisam 3 - CREATE TEMPORARY TABLE t_myisam_temp SELECT * FROM t_myisam On the other hand, the following statements are classified as safe: 1 - INSERT INTO t_innodb SELECT * FROM t_myisam_temp 2 - INSERT INTO t_myisam_temp SELECT * FROM t_innodb The patch also guarantees that transactions that have a DROP TEMPORARY are always written to the binary log regardless of the mode and the outcome: commit or rollback. In particular, the DROP TEMPORARY is extended with the IF EXISTS clause when the current statement logging format is set to row. Finally, the patch allows to switch from STATEMENT to MIXED/ROW when there are temporary tables but the contrary is not possible.
16 years ago
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.
16 years ago
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.
16 years ago
BUG#51894 Replication failure with SBR on DROP TEMPORARY TABLE inside a transaction BUG#52616 Temp table prevents switch binlog format from STATEMENT to ROW Before the WL#2687 and BUG#46364, every non-transactional change that happened after a transactional change was written to trx-cache and flushed upon committing the transaction. WL#2687 and BUG#46364 changed this behavior and non-transactional changes are now written to the binary log upon committing the statement. A binary log event is identified as transactional or non-transactional through a flag in the Log_event which is set taking into account the underlie storage engine on what it is stems from. In the current bug, this flag was not being set properly when the DROP TEMPORARY TABLE was executed. However, while fixing this bug we figured out that changes to temporary tables should be always written to the trx-cache if there is an on-going transaction. Otherwise, binlog events in the reversed order would be produced. Regarding concurrency, keeping changes to temporary tables in the trx-cache is also safe as temporary tables are only visible to the owner connection. In this patch, we classify the following statements as unsafe: 1 - INSERT INTO t_myisam SELECT * FROM t_myisam_temp 2 - INSERT INTO t_myisam_temp SELECT * FROM t_myisam 3 - CREATE TEMPORARY TABLE t_myisam_temp SELECT * FROM t_myisam On the other hand, the following statements are classified as safe: 1 - INSERT INTO t_innodb SELECT * FROM t_myisam_temp 2 - INSERT INTO t_myisam_temp SELECT * FROM t_innodb The patch also guarantees that transactions that have a DROP TEMPORARY are always written to the binary log regardless of the mode and the outcome: commit or rollback. In particular, the DROP TEMPORARY is extended with the IF EXISTS clause when the current statement logging format is set to row. Finally, the patch allows to switch from STATEMENT to MIXED/ROW when there are temporary tables but the contrary is not possible.
16 years ago
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.
16 years ago
BUG#51894 Replication failure with SBR on DROP TEMPORARY TABLE inside a transaction BUG#52616 Temp table prevents switch binlog format from STATEMENT to ROW Before the WL#2687 and BUG#46364, every non-transactional change that happened after a transactional change was written to trx-cache and flushed upon committing the transaction. WL#2687 and BUG#46364 changed this behavior and non-transactional changes are now written to the binary log upon committing the statement. A binary log event is identified as transactional or non-transactional through a flag in the Log_event which is set taking into account the underlie storage engine on what it is stems from. In the current bug, this flag was not being set properly when the DROP TEMPORARY TABLE was executed. However, while fixing this bug we figured out that changes to temporary tables should be always written to the trx-cache if there is an on-going transaction. Otherwise, binlog events in the reversed order would be produced. Regarding concurrency, keeping changes to temporary tables in the trx-cache is also safe as temporary tables are only visible to the owner connection. In this patch, we classify the following statements as unsafe: 1 - INSERT INTO t_myisam SELECT * FROM t_myisam_temp 2 - INSERT INTO t_myisam_temp SELECT * FROM t_myisam 3 - CREATE TEMPORARY TABLE t_myisam_temp SELECT * FROM t_myisam On the other hand, the following statements are classified as safe: 1 - INSERT INTO t_innodb SELECT * FROM t_myisam_temp 2 - INSERT INTO t_myisam_temp SELECT * FROM t_innodb The patch also guarantees that transactions that have a DROP TEMPORARY are always written to the binary log regardless of the mode and the outcome: commit or rollback. In particular, the DROP TEMPORARY is extended with the IF EXISTS clause when the current statement logging format is set to row. Finally, the patch allows to switch from STATEMENT to MIXED/ROW when there are temporary tables but the contrary is not possible.
16 years ago
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.
16 years ago
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.
16 years ago
BUG#51894 Replication failure with SBR on DROP TEMPORARY TABLE inside a transaction BUG#52616 Temp table prevents switch binlog format from STATEMENT to ROW Before the WL#2687 and BUG#46364, every non-transactional change that happened after a transactional change was written to trx-cache and flushed upon committing the transaction. WL#2687 and BUG#46364 changed this behavior and non-transactional changes are now written to the binary log upon committing the statement. A binary log event is identified as transactional or non-transactional through a flag in the Log_event which is set taking into account the underlie storage engine on what it is stems from. In the current bug, this flag was not being set properly when the DROP TEMPORARY TABLE was executed. However, while fixing this bug we figured out that changes to temporary tables should be always written to the trx-cache if there is an on-going transaction. Otherwise, binlog events in the reversed order would be produced. Regarding concurrency, keeping changes to temporary tables in the trx-cache is also safe as temporary tables are only visible to the owner connection. In this patch, we classify the following statements as unsafe: 1 - INSERT INTO t_myisam SELECT * FROM t_myisam_temp 2 - INSERT INTO t_myisam_temp SELECT * FROM t_myisam 3 - CREATE TEMPORARY TABLE t_myisam_temp SELECT * FROM t_myisam On the other hand, the following statements are classified as safe: 1 - INSERT INTO t_innodb SELECT * FROM t_myisam_temp 2 - INSERT INTO t_myisam_temp SELECT * FROM t_innodb The patch also guarantees that transactions that have a DROP TEMPORARY are always written to the binary log regardless of the mode and the outcome: commit or rollback. In particular, the DROP TEMPORARY is extended with the IF EXISTS clause when the current statement logging format is set to row. Finally, the patch allows to switch from STATEMENT to MIXED/ROW when there are temporary tables but the contrary is not possible.
16 years ago
BUG#51894 Replication failure with SBR on DROP TEMPORARY TABLE inside a transaction BUG#52616 Temp table prevents switch binlog format from STATEMENT to ROW Before the WL#2687 and BUG#46364, every non-transactional change that happened after a transactional change was written to trx-cache and flushed upon committing the transaction. WL#2687 and BUG#46364 changed this behavior and non-transactional changes are now written to the binary log upon committing the statement. A binary log event is identified as transactional or non-transactional through a flag in the Log_event which is set taking into account the underlie storage engine on what it is stems from. In the current bug, this flag was not being set properly when the DROP TEMPORARY TABLE was executed. However, while fixing this bug we figured out that changes to temporary tables should be always written to the trx-cache if there is an on-going transaction. Otherwise, binlog events in the reversed order would be produced. Regarding concurrency, keeping changes to temporary tables in the trx-cache is also safe as temporary tables are only visible to the owner connection. In this patch, we classify the following statements as unsafe: 1 - INSERT INTO t_myisam SELECT * FROM t_myisam_temp 2 - INSERT INTO t_myisam_temp SELECT * FROM t_myisam 3 - CREATE TEMPORARY TABLE t_myisam_temp SELECT * FROM t_myisam On the other hand, the following statements are classified as safe: 1 - INSERT INTO t_innodb SELECT * FROM t_myisam_temp 2 - INSERT INTO t_myisam_temp SELECT * FROM t_innodb The patch also guarantees that transactions that have a DROP TEMPORARY are always written to the binary log regardless of the mode and the outcome: commit or rollback. In particular, the DROP TEMPORARY is extended with the IF EXISTS clause when the current statement logging format is set to row. Finally, the patch allows to switch from STATEMENT to MIXED/ROW when there are temporary tables but the contrary is not possible.
16 years ago
BUG#51894 Replication failure with SBR on DROP TEMPORARY TABLE inside a transaction BUG#52616 Temp table prevents switch binlog format from STATEMENT to ROW Before the WL#2687 and BUG#46364, every non-transactional change that happened after a transactional change was written to trx-cache and flushed upon committing the transaction. WL#2687 and BUG#46364 changed this behavior and non-transactional changes are now written to the binary log upon committing the statement. A binary log event is identified as transactional or non-transactional through a flag in the Log_event which is set taking into account the underlie storage engine on what it is stems from. In the current bug, this flag was not being set properly when the DROP TEMPORARY TABLE was executed. However, while fixing this bug we figured out that changes to temporary tables should be always written to the trx-cache if there is an on-going transaction. Otherwise, binlog events in the reversed order would be produced. Regarding concurrency, keeping changes to temporary tables in the trx-cache is also safe as temporary tables are only visible to the owner connection. In this patch, we classify the following statements as unsafe: 1 - INSERT INTO t_myisam SELECT * FROM t_myisam_temp 2 - INSERT INTO t_myisam_temp SELECT * FROM t_myisam 3 - CREATE TEMPORARY TABLE t_myisam_temp SELECT * FROM t_myisam On the other hand, the following statements are classified as safe: 1 - INSERT INTO t_innodb SELECT * FROM t_myisam_temp 2 - INSERT INTO t_myisam_temp SELECT * FROM t_innodb The patch also guarantees that transactions that have a DROP TEMPORARY are always written to the binary log regardless of the mode and the outcome: commit or rollback. In particular, the DROP TEMPORARY is extended with the IF EXISTS clause when the current statement logging format is set to row. Finally, the patch allows to switch from STATEMENT to MIXED/ROW when there are temporary tables but the contrary is not possible.
16 years ago
  1. ################################################################################
  2. # In this test case, we verify if some DDL statements implicitly commit a
  3. # transaction and are written directly to the binary log without going
  4. # through either the Statement- or Transactional-Cache.
  5. #
  6. # As any statement that goes through a cache is written to the binary log
  7. # wrapped in a BEGIN...COMMIT, we proceed as follows:
  8. #
  9. # - create a transaction and insert some values into a transactional table.
  10. # - execute a DDL statement that is supposed to implicitly commit the previous
  11. # transaction.
  12. # - Check in the binary log for a COMMIT mark which is supposed to be written
  13. # before the DDL statement.
  14. # - Check in the binary log if the DDL is not wrapped by a BEGIN..COMMIT.
  15. #
  16. # For further details, please, read WL#2687 and WL#5072.
  17. ################################################################################
  18. --echo #########################################################################
  19. --echo # CONFIGURATION
  20. --echo #########################################################################
  21. connection master;
  22. eval CREATE TABLE tt_1 (ddl_case INT, PRIMARY KEY(ddl_case)) ENGINE = $engine;
  23. eval CREATE TABLE tt_2 (ddl_case INT, PRIMARY KEY(ddl_case)) ENGINE = $engine;
  24. eval CREATE TABLE nt_1 (ddl_case INT, PRIMARY KEY(ddl_case)) ENGINE = MyIsam;
  25. INSERT INTO tt_1(ddl_case) VALUES(0);
  26. INSERT INTO tt_2(ddl_case) VALUES(0);
  27. --echo #########################################################################
  28. --echo # CHECK IMPLICT COMMIT
  29. --echo #########################################################################
  30. SET AUTOCOMMIT= 0;
  31. let $ddl_cases= 41;
  32. while ($ddl_cases >= 1)
  33. {
  34. --echo -b-b-b-b-b-b-b-b-b-b-b- >> << -b-b-b-b-b-b-b-b-b-b-b-
  35. let $in_temporary= no;
  36. let $ok= yes;
  37. #
  38. # In SBR and MIXED modes, the commit event is usually the third event in the
  39. # binary log:
  40. #
  41. # 1: BEGIN
  42. # 2: INSERT
  43. # 3: COMMIT
  44. # 4: DDL EVENT which triggered the previous commmit.
  45. #
  46. if (`select @@binlog_format = 'STATEMENT' || @@binlog_format = 'MIXED'`)
  47. {
  48. let $commit_event_row_number= 3;
  49. }
  50. #
  51. # In RBR mode, the commit event is usually the fourth event in the binary log:
  52. #
  53. # 1: BEGIN
  54. # 2: TABLE MAP EVENT
  55. # 3: ROW EVENT
  56. # 4: COMMIT
  57. # 5: DDL EVENT which triggered the previous commmit.
  58. #
  59. if (`select @@binlog_format = 'ROW'`)
  60. {
  61. let $commit_event_row_number= 4;
  62. }
  63. #
  64. # In NDB (RBR and MIXED modes), the commit event is usually the seventh event
  65. # in the binary log:
  66. #
  67. # 1: COMMAND
  68. # 2: BEGIN
  69. # 3: TABLE MAP EVENT
  70. # 4: TABLE MAP EVENT (ndb_apply_status)
  71. # 5: ROW EVENT
  72. # 6: ROW EVENT
  73. # 7: COMMIT
  74. #
  75. if ($engine == NDB)
  76. {
  77. let $commit_event_row_number= 7;
  78. }
  79. let $first_binlog_position= query_get_value("SHOW MASTER STATUS", Position, 1);
  80. --enable_query_log
  81. eval INSERT INTO tt_1(ddl_case) VALUES ($ddl_cases);
  82. if ($ddl_cases == 41)
  83. {
  84. let $cmd= LOAD INDEX INTO CACHE nt_1 IGNORE LEAVES;
  85. if ($engine == NDB)
  86. {
  87. # This seems to be related to epochs.
  88. # We need to check this against an updated version or avoid it.
  89. let $ok= no;
  90. let $commit_event_row_number= 6;
  91. }
  92. }
  93. if ($ddl_cases == 40)
  94. {
  95. let $cmd= LOAD INDEX INTO CACHE tt_1, tt_2 IGNORE LEAVES;
  96. #
  97. # In NDB (RBR and MIXED modes), the commit event is the sixth event
  98. # in the binary log:
  99. #
  100. # 1: BEGIN
  101. # 2: TABLE MAP EVENT
  102. # 3: TABLE MAP EVENT (ndb_apply_status)
  103. # 4: ROW EVENT
  104. # 5: ROW EVENT
  105. # 6: COMMIT
  106. #
  107. if ($engine == NDB)
  108. {
  109. let $commit_event_row_number= 6;
  110. }
  111. }
  112. if ($ddl_cases == 39)
  113. {
  114. let $cmd= ANALYZE TABLE nt_1;
  115. }
  116. if ($ddl_cases == 38)
  117. {
  118. let $cmd= CHECK TABLE nt_1;
  119. #
  120. # In NDB (RBR and MIXED modes), the commit event is the sixth event
  121. # in the binary log:
  122. #
  123. # 1: BEGIN
  124. # 2: TABLE MAP EVENT
  125. # 3: TABLE MAP EVENT (ndb_apply_status)
  126. # 4: ROW EVENT
  127. # 5: ROW EVENT
  128. # 6: COMMIT
  129. #
  130. if ($engine == NDB)
  131. {
  132. let $commit_event_row_number= 6;
  133. }
  134. }
  135. if ($ddl_cases == 37)
  136. {
  137. let $cmd= OPTIMIZE TABLE nt_1;
  138. }
  139. if ($ddl_cases == 36)
  140. {
  141. let $cmd= REPAIR TABLE nt_1;
  142. }
  143. if ($ddl_cases == 35)
  144. {
  145. let $cmd= LOCK TABLES tt_1 WRITE;
  146. #
  147. # In NDB (RBR and MIXED modes), the commit event is the sixth event
  148. # in the binary log:
  149. #
  150. # 1: BEGIN
  151. # 2: TABLE MAP EVENT
  152. # 3: TABLE MAP EVENT (ndb_apply_status)
  153. # 4: ROW EVENT
  154. # 5: ROW EVENT
  155. # 6: COMMIT
  156. #
  157. if ($engine == NDB)
  158. {
  159. let $commit_event_row_number= 6;
  160. }
  161. }
  162. if ($ddl_cases == 34)
  163. {
  164. let $cmd= UNLOCK TABLES;
  165. #
  166. # In NDB (RBR and MIXED modes), the commit event is the sixth event
  167. # in the binary log:
  168. #
  169. # 1: BEGIN
  170. # 2: TABLE MAP EVENT
  171. # 3: TABLE MAP EVENT (ndb_apply_status)
  172. # 4: ROW EVENT
  173. # 5: ROW EVENT
  174. # 6: COMMIT
  175. #
  176. if ($engine == NDB)
  177. {
  178. let $commit_event_row_number= 6;
  179. }
  180. }
  181. if ($ddl_cases == 33)
  182. {
  183. let $cmd= CREATE USER 'user'@'localhost';
  184. }
  185. if ($ddl_cases == 32)
  186. {
  187. let $cmd= GRANT ALL ON *.* TO 'user'@'localhost';
  188. }
  189. if ($ddl_cases == 31)
  190. {
  191. let $cmd= SET PASSWORD FOR 'user'@'localhost' = PASSWORD('newpass');
  192. #
  193. # In NDB (RBR mode), the commit event is the eleventh event
  194. # in the binary log:
  195. #
  196. # 1: DDL EVENT which triggered the previous commmit.
  197. # 2: BEGIN
  198. # 3: TABLE MAP EVENT
  199. # 4: ROW EVENT
  200. # 5: COMMIT
  201. # 6: BEGIN
  202. # 7: TABLE MAP EVENT
  203. # 8: TABLE MAP EVENT (ndb_apply_status)
  204. # 9: ROW EVENT
  205. # 10: ROW EVENT
  206. # 11: COMMIT
  207. #
  208. if (`SELECT '$engine' = 'NDB' && @@binlog_format = 'ROW'`)
  209. {
  210. let $commit_event_row_number= 11;
  211. }
  212. #
  213. # In NDB (MIXED mode), the commit event is the eighth event
  214. # in the binary log:
  215. #
  216. # 1: DDL EVENT which triggered the previous commmit.
  217. # 2: BEGIN
  218. # 3: TABLE MAP EVENT
  219. # 4: TABLE MAP EVENT (ndb_apply_status)
  220. # 5: ROW EVENT
  221. # 6: ROW EVENT
  222. # 7: COMMIT
  223. #
  224. if (`SELECT '$engine' = 'NDB' && @@binlog_format != 'ROW'`)
  225. {
  226. let $commit_event_row_number= 7;
  227. }
  228. }
  229. if ($ddl_cases == 30)
  230. {
  231. let $cmd= REVOKE ALL PRIVILEGES, GRANT OPTION FROM 'user'@'localhost';
  232. }
  233. if ($ddl_cases == 29)
  234. {
  235. let $cmd= RENAME USER 'user'@'localhost' TO 'user_new'@'localhost';
  236. }
  237. if ($ddl_cases == 28)
  238. {
  239. let $cmd= DROP USER 'user_new'@'localhost';
  240. }
  241. if ($ddl_cases == 27)
  242. {
  243. let $cmd= CREATE EVENT evt ON SCHEDULE AT CURRENT_TIMESTAMP + INTERVAL 1 HOUR DO SELECT * FROM tt_1;
  244. }
  245. if ($ddl_cases == 26)
  246. {
  247. let $cmd= ALTER EVENT evt COMMENT 'evt';
  248. }
  249. if ($ddl_cases == 25)
  250. {
  251. let $cmd= DROP EVENT evt;
  252. }
  253. if ($ddl_cases == 24)
  254. {
  255. let $cmd= CREATE TRIGGER tr AFTER INSERT ON tt_1 FOR EACH ROW UPDATE tt_2 SET ddl_case = ddl_case WHERE ddl_case= NEW.ddl_case;
  256. }
  257. if ($ddl_cases == 23)
  258. {
  259. let $cmd= DROP TRIGGER tr;
  260. #
  261. # In RBR mode, due to the trigger the tt_2 is also updated:
  262. #
  263. # 1: BEGIN
  264. # 2: TABLE MAP EVENT
  265. # 3: TABLE MAP EVENT
  266. # 4: ROW EVENT
  267. # 5: COMMIT
  268. # 6: DDL EVENT which triggered the previous commmit.
  269. #
  270. if (`select @@binlog_format = 'ROW' && '$engine' != 'NDB'`)
  271. {
  272. let $commit_event_row_number= 5;
  273. }
  274. }
  275. if ($ddl_cases == 22)
  276. {
  277. let $cmd= CREATE FUNCTION fc () RETURNS VARCHAR(64) RETURN "fc";
  278. }
  279. if ($ddl_cases == 21)
  280. {
  281. let $cmd= ALTER FUNCTION fc COMMENT 'fc';
  282. }
  283. if ($ddl_cases == 20)
  284. {
  285. let $cmd= DROP FUNCTION fc;
  286. }
  287. if ($ddl_cases == 19)
  288. {
  289. let $cmd= CREATE PROCEDURE pc () UPDATE tt_2 SET ddl_case = ddl_case WHERE ddl_case= NEW.ddl_case;
  290. }
  291. if ($ddl_cases == 18)
  292. {
  293. let $cmd= ALTER PROCEDURE pc COMMENT 'pc';
  294. }
  295. if ($ddl_cases == 17)
  296. {
  297. let $cmd= DROP PROCEDURE pc;
  298. }
  299. if ($ddl_cases == 16)
  300. {
  301. let $cmd= CREATE VIEW v AS SELECT * FROM tt_1;
  302. }
  303. if ($ddl_cases == 15)
  304. {
  305. let $cmd= ALTER VIEW v AS SELECT * FROM tt_1;
  306. }
  307. if ($ddl_cases == 14)
  308. {
  309. let $cmd= DROP VIEW v;
  310. }
  311. if ($ddl_cases == 13)
  312. {
  313. let $cmd= CREATE INDEX ix ON tt_1(ddl_case);
  314. #
  315. # In NDB (RBR and MIXED modes), the commit event is the sixth event
  316. # in the binary log:
  317. #
  318. # 1: BEGIN
  319. # 2: TABLE MAP EVENT
  320. # 3: TABLE MAP EVENT (ndb_apply_status)
  321. # 4: ROW EVENT
  322. # 5: ROW EVENT
  323. # 6: COMMIT
  324. # 7: DDL EVENT which triggered the previous commmit.
  325. #
  326. if ($engine == NDB)
  327. {
  328. let $commit_event_row_number= 6;
  329. }
  330. }
  331. if ($ddl_cases == 12)
  332. {
  333. let $cmd= DROP INDEX ix ON tt_1;
  334. #
  335. # In NDB (RBR and MIXED modes), the commit event is the sixth event
  336. # in the binary log:
  337. #
  338. # 1: BEGIN
  339. # 2: TABLE MAP EVENT
  340. # 3: TABLE MAP EVENT (ndb_apply_status)
  341. # 4: ROW EVENT
  342. # 5: ROW EVENT
  343. # 6: COMMIT
  344. # 7: DDL EVENT which triggered the previous commmit.
  345. #
  346. if ($engine == NDB)
  347. {
  348. let $commit_event_row_number= 6;
  349. }
  350. }
  351. if ($ddl_cases == 11)
  352. {
  353. let $cmd= CREATE TEMPORARY TABLE tt_xx (a int);
  354. let $in_temporary= yes;
  355. # In SBR and MIXED modes, the DDL statement is written to the binary log but
  356. # does not commit the current transaction.
  357. #
  358. # 1: BEGIN
  359. # 2: CREATE TEMPORARY
  360. # 3: INSERT
  361. # 4: COMMIT
  362. #
  363. # In RBR the transaction is not committed either and the statement is not
  364. # written to the binary log:
  365. #
  366. # 1: BEGIN
  367. # 2: TABLE MAP EVENT
  368. # 3: ROW EVENT
  369. # 4: COMMIT
  370. #
  371. if (`select @@binlog_format = 'STATEMENT' || @@binlog_format = 'MIXED'` )
  372. {
  373. let $commit_event_row_number= 4;
  374. }
  375. #
  376. # In NDB (RBR mode), the commit event is the sixth event
  377. # in the binary log:
  378. #
  379. # 1: BEGIN
  380. # 2: TABLE MAP EVENT
  381. # 3: TABLE MAP EVENT (ndb_apply_status)
  382. # 4: ROW EVENT
  383. # 5: ROW EVENT
  384. # 6: COMMIT
  385. #
  386. if (`SELECT '$engine' = 'NDB' && @@binlog_format = 'ROW'` )
  387. {
  388. let $commit_event_row_number= 6;
  389. }
  390. #
  391. # In NDB (MIXED mode), the commit event is the nineth event
  392. # in the binary log:
  393. #
  394. # 1: BEGIN
  395. # 2: DDL EVENT which triggered the previous commmit.
  396. # 3: COMMIT
  397. # 4: BEGIN
  398. # 5: TABLE MAP EVENT
  399. # 6: TABLE MAP EVENT (ndb_apply_status)
  400. # 7: ROW EVENT
  401. # 8: ROW EVENT
  402. # 9: COMMIT
  403. #
  404. if (`SELECT '$engine' = 'NDB' && @@binlog_format != 'ROW'` )
  405. {
  406. let $commit_event_row_number= 9;
  407. }
  408. }
  409. if ($ddl_cases == 10)
  410. {
  411. let $cmd= ALTER TABLE tt_xx ADD COLUMN (b int);
  412. #
  413. # In MIXED mode, the changes are logged as rows and we have what follows:
  414. #
  415. # 1: BEGIN
  416. # 2: TABLE MAP EVENT
  417. # 3: ROW EVENT
  418. # 4: COMMIT
  419. # 5: DDL EVENT which triggered the previous commmit.
  420. #
  421. if (`select @@binlog_format = 'MIXED'`)
  422. {
  423. let $commit_event_row_number= 4;
  424. }
  425. #
  426. # In NDB (RBR and MIXED modes), the commit event is the sixth event
  427. # in the binary log:
  428. #
  429. # 1: BEGIN
  430. # 2: TABLE MAP EVENT
  431. # 3: TABLE MAP EVENT (ndb_apply_status)
  432. # 4: ROW EVENT
  433. # 5: ROW EVENT
  434. # 6: COMMIT
  435. #
  436. if ($engine == NDB)
  437. {
  438. let $commit_event_row_number= 6;
  439. }
  440. }
  441. if ($ddl_cases == 9)
  442. {
  443. let $cmd= ALTER TABLE tt_xx RENAME new_tt_xx;
  444. #
  445. # In MIXED mode, the changes are logged as rows and we have what follows:
  446. #
  447. # 1: BEGIN
  448. # 2: TABLE MAP EVENT
  449. # 3: ROW EVENT
  450. # 4: COMMIT
  451. # 5: DDL EVENT which triggered the previous commmit.
  452. #
  453. if (`select @@binlog_format = 'MIXED'`)
  454. {
  455. let $commit_event_row_number= 4;
  456. }
  457. #
  458. # In NDB (RBR and MIXED modes), the commit event is the sixth event
  459. # in the binary log:
  460. #
  461. # 1: BEGIN
  462. # 2: TABLE MAP EVENT
  463. # 3: TABLE MAP EVENT (ndb_apply_status)
  464. # 4: ROW EVENT
  465. # 5: ROW EVENT
  466. # 6: COMMIT
  467. #
  468. if ($engine == NDB)
  469. {
  470. let $commit_event_row_number= 6;
  471. }
  472. }
  473. if ($ddl_cases == 8)
  474. {
  475. let $cmd= DROP TEMPORARY TABLE IF EXISTS new_tt_xx;
  476. let $in_temporary= yes;
  477. #
  478. # In SBR and MIXED modes, the DDL statement is written to the binary log
  479. # but does not commit the current transaction:
  480. #
  481. # In SBR, we have what follows:
  482. #
  483. # 1: BEGIN
  484. # 2: INSERT
  485. # 3: DROP TEMPORARY
  486. # 4: COMMIT
  487. #
  488. # In RBR the transaction is not committed either and the statement is not
  489. # written to the binary log:
  490. #
  491. # 1: BEGIN
  492. # 2: TABLE MAP EVENT
  493. # 3: ROW EVENT
  494. # 4: COMMIT
  495. #
  496. if (`select @@binlog_format = 'STATEMENT'`)
  497. {
  498. let $commit_event_row_number= 4;
  499. }
  500. # In MIXED mode, the changes are logged as rows and we have what follows:
  501. #
  502. # 1: BEGIN
  503. # 2: TABLE MAP EVENT
  504. # 3: ROW EVENT
  505. # 4: DROP TEMPORARY table IF EXISTS
  506. # 5: COMMIT
  507. #
  508. if (`select @@binlog_format = 'MIXED' || @@binlog_format = 'ROW'`)
  509. {
  510. let $commit_event_row_number= 5;
  511. }
  512. #
  513. # In NDB (RBR and MIXED modes), the commit event is the sixth event
  514. # in the binary log:
  515. #
  516. # 1: BEGIN
  517. # 2: DROP TEMPORARY table IF EXISTS
  518. # 3: COMMIT
  519. # 4: BEGIN
  520. # 5: TABLE MAP EVENT
  521. # 6: TABLE MAP EVENT (ndb_apply_status)
  522. # 7: ROW EVENT
  523. # 8: ROW EVENT
  524. # 9: COMMIT
  525. #
  526. if ($engine == NDB)
  527. {
  528. let $commit_event_row_number= 9;
  529. }
  530. #
  531. # In NDB (MIXED mode), the commit event is the nineth event
  532. # in the binary log:
  533. #
  534. # 1: BEGIN
  535. # 2: DDL EVENT which triggered the previous commmit.
  536. # 3: COMMIT
  537. # 4: BEGIN
  538. # 5: TABLE MAP EVENT
  539. # 6: TABLE MAP EVENT (ndb_apply_status)
  540. # 7: ROW EVENT
  541. # 8: ROW EVENT
  542. # 9: COMMIT
  543. #
  544. if (`SELECT '$engine' = 'NDB' && @@binlog_format != 'ROW'` )
  545. {
  546. let $commit_event_row_number= 9;
  547. }
  548. }
  549. if ($ddl_cases == 7)
  550. {
  551. let $cmd= CREATE TABLE tt_xx (a int);
  552. }
  553. if ($ddl_cases == 6)
  554. {
  555. let $cmd= ALTER TABLE tt_xx ADD COLUMN (b int);
  556. }
  557. if ($ddl_cases == 5)
  558. {
  559. let $cmd= RENAME TABLE tt_xx TO new_tt_xx;
  560. }
  561. if ($ddl_cases == 4)
  562. {
  563. let $cmd= TRUNCATE TABLE new_tt_xx;
  564. }
  565. if ($ddl_cases == 3)
  566. {
  567. let $cmd= DROP TABLE IF EXISTS tt_xx, new_tt_xx;
  568. }
  569. if ($ddl_cases == 2)
  570. {
  571. let $cmd= CREATE DATABASE db;
  572. #
  573. # In NDB (RBR and MIXED modes), the commit event is the sixth event
  574. # in the binary log:
  575. #
  576. # 1: BEGIN
  577. # 2: TABLE MAP EVENT
  578. # 3: TABLE MAP EVENT (ndb_apply_status)
  579. # 4: ROW EVENT
  580. # 5: ROW EVENT
  581. # 6: COMMIT
  582. # 7: DDL EVENT which triggered the previous commmit.
  583. #
  584. if ($engine == NDB)
  585. {
  586. let $commit_event_row_number= 6;
  587. }
  588. }
  589. if ($ddl_cases == 1)
  590. {
  591. let $cmd= DROP DATABASE IF EXISTS db;
  592. #
  593. # In NDB (RBR and MIXED modes), the commit event is the sixth event
  594. # in the binary log:
  595. #
  596. # 1: BEGIN
  597. # 2: TABLE MAP EVENT
  598. # 3: TABLE MAP EVENT (ndb_apply_status)
  599. # 4: ROW EVENT
  600. # 5: ROW EVENT
  601. # 6: COMMIT
  602. # 7: DDL EVENT which triggered the previous commmit.
  603. #
  604. if ($engine == NDB)
  605. {
  606. let $commit_event_row_number= 6;
  607. }
  608. }
  609. --eval $cmd
  610. --disable_query_log
  611. #
  612. # When a temporary table is either created or dropped, there is no implicit
  613. # commit. The flag in_temporary is used to avoid aborting the test in such
  614. # cases. Thus we force the commit.
  615. #
  616. if ($in_temporary == yes)
  617. {
  618. --eval COMMIT
  619. }
  620. let $event_commit= query_get_value("SHOW BINLOG EVENTS FROM $first_binlog_position", Info, $commit_event_row_number);
  621. if (`SELECT SUBSTRING("$event_commit",1,6) != "COMMIT"`)
  622. {
  623. if ($ok == yes)
  624. {
  625. --echo it *does not* commit the current transaction.
  626. --echo $cmd
  627. --echo $event_commit
  628. SHOW BINLOG EVENTS;
  629. exit;
  630. }
  631. }
  632. --echo -e-e-e-e-e-e-e-e-e-e-e- >> << -e-e-e-e-e-e-e-e-e-e-e-
  633. let $binlog_start= $first_binlog_position;
  634. --echo -b-b-b-b-b-b-b-b-b-b-b- >> << -b-b-b-b-b-b-b-b-b-b-b-
  635. --source include/show_binlog_events.inc
  636. --echo -e-e-e-e-e-e-e-e-e-e-e- >> << -e-e-e-e-e-e-e-e-e-e-e-
  637. --echo
  638. dec $ddl_cases;
  639. }
  640. SET AUTOCOMMIT= 1;
  641. --echo ###################################################################################
  642. --echo # CHECK CONSISTENCY
  643. --echo ###################################################################################
  644. --sync_slave_with_master
  645. --let $diff_tables= master:tt_1,slave:tt_1
  646. --source include/diff_tables.inc
  647. --echo ###################################################################################
  648. --echo # CLEAN
  649. --echo ###################################################################################
  650. connection master;
  651. DROP TABLE tt_1;
  652. DROP TABLE tt_2;
  653. DROP TABLE nt_1;
  654. sync_slave_with_master;