Hi Steve, Brandon Nesterenko told me you would be interested in benchmarking the MDEV-34705 binlog-in-engine feature. The issue https://jira.mariadb.org/browse/MDEV-34705 has a design writeup. The feature is a new implementation of the binlog that is integrated with the InnoDB storage engine, and can therefore be more efficient. The code is in the branch: knielsen_binlog_in_engine Performance-wise, this feature has two major goals: 1. Reduce the number of fsync() required in durable configuration (--innodb-flush-log-at-trx-commit=1 --sync-binlog=1) from two to one per (group) commit, giving a large speedup. 2. Make the non-durable configuration (--innodb-flush-log-at-trx-commit=0|2) crash-safe for the binlog also, by avoiding the need for two-phase commit between InnoDB and binlog. Thus the primary goal of benchmarking is to verify the speedup in (1), and to verify that crash-safety in (2) is obtained without performance regression. Also interesting is to see how much faster new (2) is than old (1), since this comparison applies when crash-safety is required but durability is not. The speedup is expected to be higher at lower concurrency (as fsync cost is amortised over fewer commits); it is also interesting to test for scalabitily regressions at higher concurrency. Read-only workloads should be mostly unaffected. To enable the new binlog in the branch, use the following configuration: binlog_storage_engine=innodb log_bin # Optional binlog location, defaults to datadir. binlog_directory=/data/m/my/binlogs/ I'd be very interested in any results of testing the new feature, and happy to hear any comments/suggestions/questions. If you start testing the code, I will advise that this is work-in-progress; so a good idea to communicate any findings early. There are still pieces missing (and surely bugs), and I'm happy to quickly fix anything that blocks testing. In my own preliminary benchmarks, I have successfully run sysbench (using Mark Callaghan's scripts), where I see typically 50%-150% speedup in (1), and 10%-20% in (2). Results depend heavily on transaction load, concurrency, and benchmark machine disk performance. - Kristian.