Bug #75394 | Improve documentation of binlog_order_commits. | ||
---|---|---|---|
Submitted: | 2 Jan 2015 14:45 | Modified: | 24 Jan 2019 10:53 |
Reporter: | Jean-François Gagné | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: Documentation | Severity: | S4 (Feature request) |
Version: | 5.6 and 5.7 | OS: | Any |
Assigned to: | CPU Architecture: | Any |
[2 Jan 2015 14:45]
Jean-François Gagné
[24 Jan 2019 10:53]
Margaret Fisher
Posted by developer: Thanks for raising this issue - sorry you didn't get a response before. I have consulted with development and changed the description for this system variable to the following: binlog_order_commits When this variable is enabled on a replication master (which is the default), transaction commit instructions issued to storage engines are serialized on a single thread, so that transactions are always committed in the same order as they are written to the binary log. Disabling this variable permits transaction commit instructions to be issued using multiple threads. Used in combination with binary log group commit, this prevents the commit rate of a single transaction being a bottleneck to throughput, and might therefore produce a performance improvement. Transactions are written to the binary log at the point when all the storage engines involved have confirmed that the transaction is prepared to commit. The binary log group commit logic then commits a group of transactions after their binary log write has taken place. When binlog_order_commits is disabled, because multiple threads are used for this process, transactions in a commit group might be committed in a different order from their order in the binary log. (Transactions from a single client always commit in chronological order.) In many cases this does not matter, as operations carried out in separate transactions should produce consistent results, and if that is not the case, a single transaction ought to be used instead. If you want to ensure that the transaction history on the master and on a multithreaded replication slave remains identical, set slave_preserve_commit_order =1 on the replication slave. - Thanks again for helping us to improve the documentation!