IMHO, this should be a priority Major: a database without the D of ACID is not a "real" database.
https://jfg-mysql.blogspot.com/2018/10/consequences-sync-binlog-neq-1-part-1.html
https://fosdem.org/2019/schedule/event/sync_binlog_use_default/
https://twitter.com/jfg956/status/1081697022267351040

I think that we should run benchmarks to determine the performance impact of sync_binlog=1. Maybe it is insignificant enough on SSD and with group commit, so that we can enable this setting by default?

to the benchmarking.

It is not a question of benchmark / speed, it is a question of trust in the database. IMHO, a database should ship "safe" by default, and now it is not the case with MariaDB with sync_binlog = 0 in the default configuration.

There will always be situations where running safe configuration will be slower. With HDD, the latency of a sync is ~10ms, which is slow, but this is not a reason for unsafe configuration. With a RAID cache, sync latency is less than 1ms, ans it is the same with SSD, but Cloud / Network storage is bringing back this latency to 1ms. If a DBA wants better performance, he can change the sync_binlog and trx_commit parameters, but this has consequence that I detailed in [1], [2] and [3].

[1]: https://jfg-mysql.blogspot.com/2018/10/consequences-sync-binlog-neq-1-part-1.html

[2]: https://archive.fosdem.org/2020/schedule/event/sync_binlog/

[3]: https://www.slideshare.net/JeanFranoisGagn/the-consequences-of-syncbinlog-1

Please ship MariaDB with a safe default configuration, which means sync_binlog = 1.

jeanfrancois.gagne, thanks for your comments and compilation of valuable analysis! At my endorsement I actually meant MDEV-18959
(that aims at overcoming `sync_binlog=1 && innodb_flush_log_at_trx_commit=1` as the only safe configuration).
I'd personally agree to change to `sync_binlog=1`, but since there's some legacy involved it should
be widely discussed in engineering and support.

So we've actually started in that...

I insist that we should either ship with sync_binlog=1, or clearly state that we are not ACID compliant unless the setting is changed...

let's change it in 10.6, unless there're convincing reasons not to

Nice graphs sujatha.sivakumar. So 8-16 threads the throughput is higher. Still suffering on latency, particularly insert.

https://mariadb.org/fest2020/ssd/ at 10:48 offset - talking about fsync (redo, but same applies to binlog), that each fsync can be on the same data sector. Aligning every binlog unit to a beginning of a new 4k (discoverable fstat - blksize) block on disk after a fsync acceptable/show gains? And/or piggy back on the io_uring (MDEV-24883) implementation to have the kernel processing both binlog and other fsyncs for a transaction at the same tiem.

On a benchmark which aims to isolate the transaction commits alone, and varying different group commit parameters (i.e., binlog_commit_wait_count, binlog_commit_wait_usec, innodb_flush_log_at_trx_commit, sync_binlog, and concurrent connection count), we have the following results:

Added a new benchmark result prototyping the use of an innodb table to serve as the binlog (with the normal binary log disabled). Tested against various modes of flushing the binary log. In the legend, b stands for sync_binlog, and i stands for innodb_flush_log_at_trx_commit.

Running the innodb table prototype benchmark on an SSD (rather than ramdisk and WITH_PMEM) shows that with low concurrency, the innodb binary log implementation is able to have higher performance than the current file implementation; however, with more concurrency, the methods switch. Will do further analysis into the time spent, along with more benchmarks comparing differing binlog group commit parameters.

As far as I understand, implementing MDEV-34705 would significantly reduce the impact of setting sync_binlog. It should also make sync_binlog=0 (which would effectively be an alias of innodb_flush_log_at_trx_commit=0) crash-safe in a non-DDL workload. Yes, you might lose some latest committed transactions, but the binlog would be in sync with the storage engine.

For any crash safety, DDL operations seem to require fdatasync() or fsync(), as long as a separate ddl_recovery.log file is being maintained.