![](https://secure.gravatar.com/avatar/4a81ad68d36ab4fdbf830ccb4db35769.jpg?s=120&d=mm&r=g)
Hi Serg, Kristian, all On 14/12/2010, at 4:08 PM, Sergei Golubchik wrote:
On Dec 14, Arjen Lentz wrote:
Can we adopt/implement http://forge.mysql.com/worklog/task.php?id=4925 in MariaDB? The benchmark info is in the item, and looks quite interesting. The author tested it using a separate tool to preallocate the binlog, but it should be straightforward implementing this inside the server, that'd also be much easier to manage without extra fuss for a DBA.
You mean - before it gets into 5.6 and we merge it the normal way? Or you mean - with a different implementation (w/o mysqlbinlogalloc) ?
Both ;-) sync_binlog=1 is a serious problem, note my earlier bugreport on the number of fsyncs a commit requires. While fixing that is not trivial, pre-allocating apparently makes a big difference. So I'd see that as high priority, even just looking in the realm of a number of Open Query clients. Secondly, I think the implementation with the external mysqlbinlogalloc tool is not nice. I appreciate that writing full a 1GB file takes a long time, but that's not how it needs to work. InnoDB can extend its tablespace with a configurable chunk at a time (8M by default, iirc). The binlog_preallocate variable should, similar to the InnoDB method, define the size of the next preallocation. I also don't see the point of the =0 ignoring a preallocated file. Since mysqld always starts a new binlog on startup, it does not have to scan an existing file at that stage. For replication, surely it can detect what's going on without having a setting. By having the pre-allocation size configurable, users can choose an amount that works best in their particular environment; with the right filesystem, it could be huge. Otherwise, more modest. Either way advantage can be gained. Cheers, Arjen. -- Arjen Lentz, Exec.Director @ Open Query (http://openquery.com) Remote expertise & maintenance for MySQL/MariaDB server environments. Follow us at http://openquery.com/blog/ & http://twitter.com/openquery