mariadb/mysql-test/main/xa_binlog.result

86 lines
3 KiB
Text
Raw Normal View History

2011-03-31 14:29:23 +02:00
CREATE TABLE t1 (a INT PRIMARY KEY) ENGINE=InnoDB;
SET binlog_format= mixed;
RESET MASTER;
XA START 'xatest';
INSERT INTO t1 VALUES (1);
XA END 'xatest';
XA PREPARE 'xatest';
XA COMMIT 'xatest';
XA START 'xatest';
INSERT INTO t1 VALUES (2);
XA END 'xatest';
XA COMMIT 'xatest' ONE PHASE;
BEGIN;
INSERT INTO t1 VALUES (3);
COMMIT;
SELECT * FROM t1 ORDER BY a;
a
1
2
3
Aria will now register it's transactions MDEV-22531 Remove maria::implicit_commit() MDEV-22607 Assertion `ha_info->ht() != binlog_hton' failed in MYSQL_BIN_LOG::unlog_xa_prepare From the handler point of view, Aria now looks like a transactional engine. One effect of this is that we don't need to call maria::implicit_commit() anymore. This change also forces the server to call trans_commit_stmt() after doing any read or writes to system tables. This work will also make it easier to later allow users to have system tables in other engines than Aria. To handle the case that Aria doesn't support rollback, a new handlerton flag, HTON_NO_ROLLBACK, was added to engines that has transactions without rollback (for the moment only binlog and Aria). Other things - Moved freeing of MARIA_SHARE to a separate function as the MARIA_SHARE can be still part of a transaction even if the table has closed. - Changed Aria checkpoint to use the new MARIA_SHARE free function. This fixes a possible memory leak when using S3 tables - Changed testing of binlog_hton to instead test for HTON_NO_ROLLBACK - Removed checking of has_transaction_manager() in handler.cc as we can assume that as the transaction was started by the engine, it does support transactions. - Added new class 'start_new_trans' that can be used to start indepdendent sub transactions, for example while reading mysql.proc, using help or status tables etc. - open_system_tables...() and open_proc_table_for_Read() doesn't anymore take a Open_tables_backup list. This is now handled by 'start_new_trans'. - Split thd::has_transactions() to thd::has_transactions() and thd::has_transactions_and_rollback() - Added handlerton code to free cached transactions objects. Needed by InnoDB. squash! 2ed35999f2a2d84f1c786a21ade5db716b6f1bbc
2020-05-02 13:19:53 +03:00
DROP TABLE t1;
CREATE TABLE t1 (a INT) ENGINE=Aria;
INSERT INTO t1 VALUES (1),(2);
XA BEGIN 'x';
DELETE FROM t1;
XA END 'x';
XA PREPARE 'x';
Warnings:
Warning 1030 Got error 131 "Command not supported by the engine" from storage engine Aria
XA COMMIT 'x';
SELECT * from t1;
a
XA BEGIN 'x';
INSERT INTO t1 VALUES (3),(4);
XA END 'x';
XA PREPARE 'x';
Warnings:
Warning 1030 Got error 131 "Command not supported by the engine" from storage engine Aria
XA ROLLBACK 'x';
Warnings:
Warning 1196 Some non-transactional changed tables couldn't be rolled back
SELECT * from t1;
a
3
4
DROP TABLE t1;
SHOW BINLOG EVENTS LIMIT 3,100;
2011-03-31 14:29:23 +02:00
Log_name Pos Event_type Server_id End_log_pos Info
MDEV-742 XA PREPAREd transaction survive disconnect/server restart Lifted long standing limitation to the XA of rolling it back at the transaction's connection close even if the XA is prepared. Prepared XA-transaction is made to sustain connection close or server restart. The patch consists of - binary logging extension to write prepared XA part of transaction signified with its XID in a new XA_prepare_log_event. The concusion part - with Commit or Rollback decision - is logged separately as Query_log_event. That is in the binlog the XA consists of two separate group of events. That makes the whole XA possibly interweaving in binlog with other XA:s or regular transaction but with no harm to replication and data consistency. Gtid_log_event receives two more flags to identify which of the two XA phases of the transaction it represents. With either flag set also XID info is added to the event. When binlog is ON on the server XID::formatID is constrained to 4 bytes. - engines are made aware of the server policy to keep up user prepared XA:s so they (Innodb, rocksdb) don't roll them back anymore at their disconnect methods. - slave applier is refined to cope with two phase logged XA:s including parallel modes of execution. This patch does not address crash-safe logging of the new events which is being addressed by MDEV-21469. CORNER CASES: read-only, pure myisam, binlog-*, @@skip_log_bin, etc Are addressed along the following policies. 1. The read-only at reconnect marks XID to fail for future completion with ER_XA_RBROLLBACK. 2. binlog-* filtered XA when it changes engine data is regarded as loggable even when nothing got cached for binlog. An empty XA-prepare group is recorded. Consequent Commit-or-Rollback succeeds in the Engine(s) as well as recorded into binlog. 3. The same applies to the non-transactional engine XA. 4. @@skip_log_bin=OFF does not record anything at XA-prepare (obviously), but the completion event is recorded into binlog to admit inconsistency with slave. The following actions are taken by the patch. At XA-prepare: when empty binlog cache - don't do anything to binlog if RO, otherwise write empty XA_prepare (assert(binlog-filter case)). At Disconnect: when Prepared && RO (=> no binlogging was done) set Xid_cache_element::error := ER_XA_RBROLLBACK *keep* XID in the cache, and rollback the transaction. At XA-"complete": Discover the error, if any don't binlog the "complete", return the error to the user. Kudos ----- Alexey Botchkov took to drive this work initially. Sergei Golubchik, Sergei Petrunja, Marko Mäkelä provided a number of good recommendations. Sergei Voitovich made a magnificent review and improvements to the code. They all deserve a bunch of thanks for making this work done!
2019-03-31 01:47:28 +04:00
master-bin.000001 # Gtid 1 # XA START X'786174657374',X'',1 GTID #-#-#
2011-03-31 14:29:23 +02:00
master-bin.000001 # Query 1 # use `test`; INSERT INTO t1 VALUES (1)
MDEV-742 XA PREPAREd transaction survive disconnect/server restart Lifted long standing limitation to the XA of rolling it back at the transaction's connection close even if the XA is prepared. Prepared XA-transaction is made to sustain connection close or server restart. The patch consists of - binary logging extension to write prepared XA part of transaction signified with its XID in a new XA_prepare_log_event. The concusion part - with Commit or Rollback decision - is logged separately as Query_log_event. That is in the binlog the XA consists of two separate group of events. That makes the whole XA possibly interweaving in binlog with other XA:s or regular transaction but with no harm to replication and data consistency. Gtid_log_event receives two more flags to identify which of the two XA phases of the transaction it represents. With either flag set also XID info is added to the event. When binlog is ON on the server XID::formatID is constrained to 4 bytes. - engines are made aware of the server policy to keep up user prepared XA:s so they (Innodb, rocksdb) don't roll them back anymore at their disconnect methods. - slave applier is refined to cope with two phase logged XA:s including parallel modes of execution. This patch does not address crash-safe logging of the new events which is being addressed by MDEV-21469. CORNER CASES: read-only, pure myisam, binlog-*, @@skip_log_bin, etc Are addressed along the following policies. 1. The read-only at reconnect marks XID to fail for future completion with ER_XA_RBROLLBACK. 2. binlog-* filtered XA when it changes engine data is regarded as loggable even when nothing got cached for binlog. An empty XA-prepare group is recorded. Consequent Commit-or-Rollback succeeds in the Engine(s) as well as recorded into binlog. 3. The same applies to the non-transactional engine XA. 4. @@skip_log_bin=OFF does not record anything at XA-prepare (obviously), but the completion event is recorded into binlog to admit inconsistency with slave. The following actions are taken by the patch. At XA-prepare: when empty binlog cache - don't do anything to binlog if RO, otherwise write empty XA_prepare (assert(binlog-filter case)). At Disconnect: when Prepared && RO (=> no binlogging was done) set Xid_cache_element::error := ER_XA_RBROLLBACK *keep* XID in the cache, and rollback the transaction. At XA-"complete": Discover the error, if any don't binlog the "complete", return the error to the user. Kudos ----- Alexey Botchkov took to drive this work initially. Sergei Golubchik, Sergei Petrunja, Marko Mäkelä provided a number of good recommendations. Sergei Voitovich made a magnificent review and improvements to the code. They all deserve a bunch of thanks for making this work done!
2019-03-31 01:47:28 +04:00
master-bin.000001 # Query 1 # XA END X'786174657374',X'',1
master-bin.000001 # XA_prepare 1 # XA PREPARE X'786174657374',X'',1
master-bin.000001 # Gtid 1 # GTID #-#-#
master-bin.000001 # Query 1 # XA COMMIT X'786174657374',X'',1
master-bin.000001 # Gtid 1 # BEGIN GTID #-#-#
2011-03-31 14:29:23 +02:00
master-bin.000001 # Query 1 # use `test`; INSERT INTO t1 VALUES (2)
MDEV-742 XA PREPAREd transaction survive disconnect/server restart Lifted long standing limitation to the XA of rolling it back at the transaction's connection close even if the XA is prepared. Prepared XA-transaction is made to sustain connection close or server restart. The patch consists of - binary logging extension to write prepared XA part of transaction signified with its XID in a new XA_prepare_log_event. The concusion part - with Commit or Rollback decision - is logged separately as Query_log_event. That is in the binlog the XA consists of two separate group of events. That makes the whole XA possibly interweaving in binlog with other XA:s or regular transaction but with no harm to replication and data consistency. Gtid_log_event receives two more flags to identify which of the two XA phases of the transaction it represents. With either flag set also XID info is added to the event. When binlog is ON on the server XID::formatID is constrained to 4 bytes. - engines are made aware of the server policy to keep up user prepared XA:s so they (Innodb, rocksdb) don't roll them back anymore at their disconnect methods. - slave applier is refined to cope with two phase logged XA:s including parallel modes of execution. This patch does not address crash-safe logging of the new events which is being addressed by MDEV-21469. CORNER CASES: read-only, pure myisam, binlog-*, @@skip_log_bin, etc Are addressed along the following policies. 1. The read-only at reconnect marks XID to fail for future completion with ER_XA_RBROLLBACK. 2. binlog-* filtered XA when it changes engine data is regarded as loggable even when nothing got cached for binlog. An empty XA-prepare group is recorded. Consequent Commit-or-Rollback succeeds in the Engine(s) as well as recorded into binlog. 3. The same applies to the non-transactional engine XA. 4. @@skip_log_bin=OFF does not record anything at XA-prepare (obviously), but the completion event is recorded into binlog to admit inconsistency with slave. The following actions are taken by the patch. At XA-prepare: when empty binlog cache - don't do anything to binlog if RO, otherwise write empty XA_prepare (assert(binlog-filter case)). At Disconnect: when Prepared && RO (=> no binlogging was done) set Xid_cache_element::error := ER_XA_RBROLLBACK *keep* XID in the cache, and rollback the transaction. At XA-"complete": Discover the error, if any don't binlog the "complete", return the error to the user. Kudos ----- Alexey Botchkov took to drive this work initially. Sergei Golubchik, Sergei Petrunja, Marko Mäkelä provided a number of good recommendations. Sergei Voitovich made a magnificent review and improvements to the code. They all deserve a bunch of thanks for making this work done!
2019-03-31 01:47:28 +04:00
master-bin.000001 # Xid 1 # COMMIT /* xid=XX */
master-bin.000001 # Gtid 1 # BEGIN GTID #-#-#
2011-03-31 14:29:23 +02:00
master-bin.000001 # Query 1 # use `test`; INSERT INTO t1 VALUES (3)
master-bin.000001 # Xid 1 # COMMIT /* xid=XX */
Aria will now register it's transactions MDEV-22531 Remove maria::implicit_commit() MDEV-22607 Assertion `ha_info->ht() != binlog_hton' failed in MYSQL_BIN_LOG::unlog_xa_prepare From the handler point of view, Aria now looks like a transactional engine. One effect of this is that we don't need to call maria::implicit_commit() anymore. This change also forces the server to call trans_commit_stmt() after doing any read or writes to system tables. This work will also make it easier to later allow users to have system tables in other engines than Aria. To handle the case that Aria doesn't support rollback, a new handlerton flag, HTON_NO_ROLLBACK, was added to engines that has transactions without rollback (for the moment only binlog and Aria). Other things - Moved freeing of MARIA_SHARE to a separate function as the MARIA_SHARE can be still part of a transaction even if the table has closed. - Changed Aria checkpoint to use the new MARIA_SHARE free function. This fixes a possible memory leak when using S3 tables - Changed testing of binlog_hton to instead test for HTON_NO_ROLLBACK - Removed checking of has_transaction_manager() in handler.cc as we can assume that as the transaction was started by the engine, it does support transactions. - Added new class 'start_new_trans' that can be used to start indepdendent sub transactions, for example while reading mysql.proc, using help or status tables etc. - open_system_tables...() and open_proc_table_for_Read() doesn't anymore take a Open_tables_backup list. This is now handled by 'start_new_trans'. - Split thd::has_transactions() to thd::has_transactions() and thd::has_transactions_and_rollback() - Added handlerton code to free cached transactions objects. Needed by InnoDB. squash! 2ed35999f2a2d84f1c786a21ade5db716b6f1bbc
2020-05-02 13:19:53 +03:00
master-bin.000001 # Gtid 1 # GTID #-#-#
master-bin.000001 # Query 1 # use `test`; DROP TABLE `t1` /* generated by server */
master-bin.000001 # Gtid 1 # GTID #-#-#
master-bin.000001 # Query 1 # use `test`; CREATE TABLE t1 (a INT) ENGINE=Aria
master-bin.000001 # Gtid 1 # BEGIN GTID #-#-#
master-bin.000001 # Query 1 # use `test`; INSERT INTO t1 VALUES (1),(2)
master-bin.000001 # Query 1 # COMMIT
master-bin.000001 # Gtid 1 # BEGIN GTID #-#-#
master-bin.000001 # Query 1 # use `test`; DELETE FROM t1
master-bin.000001 # Query 1 # COMMIT
master-bin.000001 # Gtid 1 # XA START X'78',X'',1 GTID #-#-#
master-bin.000001 # Query 1 # XA END X'78',X'',1
master-bin.000001 # XA_prepare 1 # XA PREPARE X'78',X'',1
master-bin.000001 # Gtid 1 # GTID #-#-#
master-bin.000001 # Query 1 # XA COMMIT X'78',X'',1
master-bin.000001 # Gtid 1 # BEGIN GTID #-#-#
master-bin.000001 # Query 1 # use `test`; INSERT INTO t1 VALUES (3),(4)
master-bin.000001 # Query 1 # COMMIT
master-bin.000001 # Gtid 1 # XA START X'78',X'',1 GTID #-#-#
master-bin.000001 # Query 1 # XA END X'78',X'',1
master-bin.000001 # XA_prepare 1 # XA PREPARE X'78',X'',1
master-bin.000001 # Gtid 1 # GTID #-#-#
master-bin.000001 # Query 1 # XA ROLLBACK X'78',X'',1
master-bin.000001 # Gtid 1 # GTID #-#-#
master-bin.000001 # Query 1 # use `test`; DROP TABLE `t1` /* generated by server */