mirror/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-01-22 23:04:20 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
mariadb/mysql-test/suite/rpl/r/rpl_truncate_3innodb.result

47 lines
1.4 KiB
Text
Raw Normal View History

Bug#19066 (DELETE FROM inconsistency for NDB): Under row-based replication, DELETE FROM will now always be replicated as individual row deletions, while TRUNCATE TABLE will always be replicated as a statement.
2006-06-01 11:53:27 +02:00
stop slave;
drop table if exists t1,t2,t3,t4,t5,t6,t7,t8,t9;
reset master;
reset slave;
drop table if exists t1,t2,t3,t4,t5,t6,t7,t8,t9;
start slave;
Bug #36763 TRUNCATE TABLE fails to replicate when stmt-based binlogging is not supported. There were two separate problems with the code, both of which are fixed with this patch: 1. An error was printed by InnoDB for TRUNCATE TABLE in statement mode when the in isolation levels READ COMMITTED and READ UNCOMMITTED since InnoDB does permit statement-based replication for DML statements. However, the TRUNCATE TABLE is not transactional, but is a DDL, and should therefore be allowed to be replicated as a statement. 2. The statement was not logged in mixed mode because of the error above, but the error was not reported to the client. This patch fixes the problem by treating TRUNCATE TABLE a DDL, that is, it is always logged as a statement and not reporting an error from InnoDB for TRUNCATE TABLE.
2009-02-06 17:06:41 +01:00
**** Resetting master and slave ****
BUG#36763: TRUNCATE TABLE fails to replicate when stmt-based binlogging is not supported. Post-merge fixes. Changes to some result sets.
2009-02-10 15:44:58 +01:00
include/stop_slave.inc
Bug #31554 rpl.rpl_truncate_2myisam test failure: wrong master binlog file name Actually, the failure happened with 3innodb as well. Most probably the reason is in failing to delete a binlog file on __NT__ so that that master increments the index of the binlog file. The test results hide valueable warning that windows could generate about that. The scope of this fix is to make sure we have such warning and to lessen chances for binlog file being held at time of closing. The dump thread is getting a good chance to leave and release the file for its successful deletion. We shall watch over the two tests as regression is not excluded. In that case we would have an extra info possibly explaining why __NT__ env can not close/delete the file. However, regardless of that reason, there is alwasy workaround to mask out non-deterministic binlog index number.
2007-11-02 14:00:38 +02:00
RESET SLAVE;
RESET MASTER;
BUG#36763: TRUNCATE TABLE fails to replicate when stmt-based binlogging is not supported. Post-merge fixes. Changes to some result sets.
2009-02-10 15:44:58 +01:00
include/start_slave.inc
Bug#19066 (DELETE FROM inconsistency for NDB): Under row-based replication, DELETE FROM will now always be replicated as individual row deletions, while TRUNCATE TABLE will always be replicated as a statement.
2006-06-01 11:53:27 +02:00
**** On Master ****
CREATE TABLE t1 (a INT, b LONG) ENGINE=InnoDB;
INSERT INTO t1 VALUES (1,1), (2,2);
**** On Master ****
TRUNCATE TABLE t1;
Bug #36763 TRUNCATE TABLE fails to replicate when stmt-based binlogging is not supported. There were two separate problems with the code, both of which are fixed with this patch: 1. An error was printed by InnoDB for TRUNCATE TABLE in statement mode when the in isolation levels READ COMMITTED and READ UNCOMMITTED since InnoDB does permit statement-based replication for DML statements. However, the TRUNCATE TABLE is not transactional, but is a DDL, and should therefore be allowed to be replicated as a statement. 2. The statement was not logged in mixed mode because of the error above, but the error was not reported to the client. This patch fixes the problem by treating TRUNCATE TABLE a DDL, that is, it is always logged as a statement and not reporting an error from InnoDB for TRUNCATE TABLE.
2009-02-06 17:06:41 +01:00
Comparing tables master:test.t1 and slave:test.t1
==== Test using a table with delete triggers ====
Bug#19066 (DELETE FROM inconsistency for NDB): Under row-based replication, DELETE FROM will now always be replicated as individual row deletions, while TRUNCATE TABLE will always be replicated as a statement.
2006-06-01 11:53:27 +02:00
**** On Master ****
Bug #36763 TRUNCATE TABLE fails to replicate when stmt-based binlogging is not supported. There were two separate problems with the code, both of which are fixed with this patch: 1. An error was printed by InnoDB for TRUNCATE TABLE in statement mode when the in isolation levels READ COMMITTED and READ UNCOMMITTED since InnoDB does permit statement-based replication for DML statements. However, the TRUNCATE TABLE is not transactional, but is a DDL, and should therefore be allowed to be replicated as a statement. 2. The statement was not logged in mixed mode because of the error above, but the error was not reported to the client. This patch fixes the problem by treating TRUNCATE TABLE a DDL, that is, it is always logged as a statement and not reporting an error from InnoDB for TRUNCATE TABLE.
2009-02-06 17:06:41 +01:00
SET @count := 1;
CREATE TABLE t2 (a INT, b LONG) ENGINE=InnoDB;
CREATE TRIGGER trg1 BEFORE DELETE ON t1 FOR EACH ROW SET @count := @count + 1;
Bug#19066 (DELETE FROM inconsistency for NDB): Under row-based replication, DELETE FROM will now always be replicated as individual row deletions, while TRUNCATE TABLE will always be replicated as a statement.
2006-06-01 11:53:27 +02:00
**** On Master ****
TRUNCATE TABLE t1;
Bug #36763 TRUNCATE TABLE fails to replicate when stmt-based binlogging is not supported. There were two separate problems with the code, both of which are fixed with this patch: 1. An error was printed by InnoDB for TRUNCATE TABLE in statement mode when the in isolation levels READ COMMITTED and READ UNCOMMITTED since InnoDB does permit statement-based replication for DML statements. However, the TRUNCATE TABLE is not transactional, but is a DDL, and should therefore be allowed to be replicated as a statement. 2. The statement was not logged in mixed mode because of the error above, but the error was not reported to the client. This patch fixes the problem by treating TRUNCATE TABLE a DDL, that is, it is always logged as a statement and not reporting an error from InnoDB for TRUNCATE TABLE.
2009-02-06 17:06:41 +01:00
Comparing tables master:test.t2 and slave:test.t2
DROP TABLE t1,t2;
**** Resetting master and slave ****
BUG#36763: TRUNCATE TABLE fails to replicate when stmt-based binlogging is not supported. Post-merge fixes. Changes to some result sets.
2009-02-10 15:44:58 +01:00
include/stop_slave.inc
Bug #31554 rpl.rpl_truncate_2myisam test failure: wrong master binlog file name Actually, the failure happened with 3innodb as well. Most probably the reason is in failing to delete a binlog file on __NT__ so that that master increments the index of the binlog file. The test results hide valueable warning that windows could generate about that. The scope of this fix is to make sure we have such warning and to lessen chances for binlog file being held at time of closing. The dump thread is getting a good chance to leave and release the file for its successful deletion. We shall watch over the two tests as regression is not excluded. In that case we would have an extra info possibly explaining why __NT__ env can not close/delete the file. However, regardless of that reason, there is alwasy workaround to mask out non-deterministic binlog index number.
2007-11-02 14:00:38 +02:00
RESET SLAVE;
RESET MASTER;
BUG#36763: TRUNCATE TABLE fails to replicate when stmt-based binlogging is not supported. Post-merge fixes. Changes to some result sets.
2009-02-10 15:44:58 +01:00
include/start_slave.inc
Bug#19066 (DELETE FROM inconsistency for NDB): Under row-based replication, DELETE FROM will now always be replicated as individual row deletions, while TRUNCATE TABLE will always be replicated as a statement.
2006-06-01 11:53:27 +02:00
**** On Master ****
CREATE TABLE t1 (a INT, b LONG) ENGINE=InnoDB;
INSERT INTO t1 VALUES (1,1), (2,2);
**** On Master ****
DELETE FROM t1;
Bug #36763 TRUNCATE TABLE fails to replicate when stmt-based binlogging is not supported. There were two separate problems with the code, both of which are fixed with this patch: 1. An error was printed by InnoDB for TRUNCATE TABLE in statement mode when the in isolation levels READ COMMITTED and READ UNCOMMITTED since InnoDB does permit statement-based replication for DML statements. However, the TRUNCATE TABLE is not transactional, but is a DDL, and should therefore be allowed to be replicated as a statement. 2. The statement was not logged in mixed mode because of the error above, but the error was not reported to the client. This patch fixes the problem by treating TRUNCATE TABLE a DDL, that is, it is always logged as a statement and not reporting an error from InnoDB for TRUNCATE TABLE.
2009-02-06 17:06:41 +01:00
Comparing tables master:test.t1 and slave:test.t1
==== Test using a table with delete triggers ====
Bug#19066 (DELETE FROM inconsistency for NDB): Under row-based replication, DELETE FROM will now always be replicated as individual row deletions, while TRUNCATE TABLE will always be replicated as a statement.
2006-06-01 11:53:27 +02:00
**** On Master ****
Bug #36763 TRUNCATE TABLE fails to replicate when stmt-based binlogging is not supported. There were two separate problems with the code, both of which are fixed with this patch: 1. An error was printed by InnoDB for TRUNCATE TABLE in statement mode when the in isolation levels READ COMMITTED and READ UNCOMMITTED since InnoDB does permit statement-based replication for DML statements. However, the TRUNCATE TABLE is not transactional, but is a DDL, and should therefore be allowed to be replicated as a statement. 2. The statement was not logged in mixed mode because of the error above, but the error was not reported to the client. This patch fixes the problem by treating TRUNCATE TABLE a DDL, that is, it is always logged as a statement and not reporting an error from InnoDB for TRUNCATE TABLE.
2009-02-06 17:06:41 +01:00
SET @count := 1;
CREATE TABLE t2 (a INT, b LONG) ENGINE=InnoDB;
CREATE TRIGGER trg1 BEFORE DELETE ON t1 FOR EACH ROW SET @count := @count + 1;
Bug#19066 (DELETE FROM inconsistency for NDB): Under row-based replication, DELETE FROM will now always be replicated as individual row deletions, while TRUNCATE TABLE will always be replicated as a statement.
2006-06-01 11:53:27 +02:00
**** On Master ****
DELETE FROM t1;
Bug #36763 TRUNCATE TABLE fails to replicate when stmt-based binlogging is not supported. There were two separate problems with the code, both of which are fixed with this patch: 1. An error was printed by InnoDB for TRUNCATE TABLE in statement mode when the in isolation levels READ COMMITTED and READ UNCOMMITTED since InnoDB does permit statement-based replication for DML statements. However, the TRUNCATE TABLE is not transactional, but is a DDL, and should therefore be allowed to be replicated as a statement. 2. The statement was not logged in mixed mode because of the error above, but the error was not reported to the client. This patch fixes the problem by treating TRUNCATE TABLE a DDL, that is, it is always logged as a statement and not reporting an error from InnoDB for TRUNCATE TABLE.
2009-02-06 17:06:41 +01:00
Comparing tables master:test.t2 and slave:test.t2
DROP TABLE t1,t2;
Reference in a new issue Copy permalink