Background
When a large transaction is executed in the database, execution of other transactions will slow down. The sign for successfully executing a transaction is its successful commit, but a transaction can be committed only after its binlogs are written to a file. Different transactions should queue up to write their binlogs to the binlog file, that is, only one transaction can write binlogs at a time. If a transaction has a larger binlog size, such as 100 GB, its binlog writing time is longer. In this case, other transactions in the queue are forced to wait for the large transaction to finish writing binlogs, so the execution of other transactions is very slow.
Overview
When a large transaction is committed, a large amount of binlogs are written, causing delays in the commit of other transactions. Through optimization of such scenarios by the Tencent Cloud kernel team, the binlogs generated by a large transaction are redirected to a new temporary file, to prevent other transactions from being blocked by the large transaction and avoid extra processing time. After the large transaction is committed, the temporary file will be updated as the official binlog file and the original data mapping relationship will also be updated.
Supported Versions
Kernel version 3.1.12 or later for TDSQL-C for MySQL 8.0.
Use Cases
In scenarios where a large transaction is executed together with other transactions in the database, this feature is used to shorten delays of other transactions caused by committing a large transaction.
Use Instructions
This feature is used with the txsql_non_blocking_binlog_threshold parameter. Set this parameter to a non-default value to use this feature. Detailed parameter descriptions are as follows:
|
txsql_non_blocking_binlog_threshold | Global | ulong | UINT64_MAX | 134217728-UINT64_MAX | When the binlog size of a transaction is greater than or equal to this value (unit: byte), the transaction will be committed by using the large transaction binlog optimization method. |
Was this page helpful?