WL#10493: Add transaction length to gtid_log_event
Affects: Server-8.0 — Status: Complete
Add transaction length to the Gtid_log_event in the binary log. This is a stepping stone for: 1. Optimizing the applier. Currently, the coordinator thread dispatches one event at a time to the workers. This context switch is expensive, and becomes more of a bottleneck the more we optimize other things. If we have the transaction length, we can dispatch the whole transaction in just one context switch. Since RBR transactions use at least 5 events (gtid+begin+table_map+row+commit) this is a big improvement. 2. Optimizing the protocol. Currently, we send each event in one packet. If we have the length easily available, it becomes easier to send each transaction as one packet (and split into multiple packets if that is needed in order to keep within max_allowed_packet). 3. Optimizing the binlog by removing BEGIN/COMMIT events. When we have the length field, we can use that to detect transaction boundaries. Then the BEGIN/COMMIT become less important. 4. Expose transaction size to the user through performance_schema tables.
Functional requirements ----------------------- F-1: A server with support for this feature must always log the transaction length of transactions applied (and binary logged) into Gtid_log_event. F-2: Non-applied (injected) transactions may let the transaction length field set to 0. Those are transactions generated and injected into relay logs to be applied. Once applied, the correspondent Gtid on binary log must have the correct transaction length. F-3: A server without support for this feature shall be able to apply events generated from a server that supports the feature, but without the ability to take benefit of the transaction length information. F-4: A transaction replicated from a server without support for this feature, when replicated to a server with support for this feature, shall have no transaction length information on the relay log, but must generate it once applying the transaction and logging it to the binary log. F-5: The transaction length information is not designed to be preserved across distinct server's binary logs, but it shall be preserved between a master binary log and its slaves relays log. F-6: The dump of mysqlbinlog client program with support for this feature must display the transaction length information when available, and display 0 as the transaction length when the Gtid_log_event was generated in a server without support for this feature. Non-Functional requirements --------------------------- NF-1: The impact on server performance introduced by logging the transaction length into the binary log shall be negligible.
Interface Specification ----------------------- I-1: Introduce a new field at Gtid_log_event: NAME: transaction length TYPE: unsigned long long int using net_store_length (1 to 9 bytes) DESCRIPTION: Stores the transaction length in bytes (this also includes the Gtid_log_event length). I-2: No new options I-3: No new files I-4: No changes in existing syntax I-5: No new commands I-6: No new tools High Level Specification ------------------------ The specification can be divided into two steps: (S-1) make the master to log the transaction length on its binary log; (S-2) make mysqlbinlog to output the transaction length information. S-1: In order to support F-1, the Gtid_log_event should be extended to log a new field (defined at I-1) containing the transaction length. The idea is to calculate the transaction size when writing the Gtid_log_event into the binary log. The binary_log_cache size is the transaction size but missing the Gtid_log_event size and the CRC32 information for all events in the cache (when checksum is enabled). In order to compute the CRC32 payload on the transaction, we need to count the amount of events written to the binary log cache. This counter must take into account the possibility of SAVEPOINT and ROLLBACK TO SAVEPOINT be applied on the binary log cache. S-2: In order to support F-6, a mysqbinlog client tool dumping a Gtid_log_event should display 0 as transaction length for the events without the information and will display the transaction length for those containing it.
Copyright (c) 2000, 2022, Oracle Corporation and/or its affiliates. All rights reserved.