I see you’re using innodb_log_buffer_size=128M is it indeed required value or you just set it so high to make sure is not the bottleneck ?

It is my assumption there is no need for log buffer more than twice of peak amount of log records which can be generated a second.

Change the table to MyISAM. Many people are using MySQL to keep logs, or other information that’s mostly INSERT. I think it’s important to mention that option as well, especially since this solution doesn’t seem to be good for lots of UPDATE statements either.

(ps the challenge question is somewhat broken, because 4+8 does in fact equal 12

Great. Looking forward to your next post on binlog.

Would love to see how innodb_support_xa=1 affects performance too!

great analyze of bottlenecks and very constructive approach in proposed solutions! – I’m impatient to test the new XtraDB! )

few questions so far:

- do you mean that database/datafile should be recreated to be able to use several rollback segments? (setting the option is not enough?)

- from your TPS graph is not seen when XtraDB outperforms the “Normal 1.0.4″, anyway to see the “whole” picture?

Thanks a lot for sharing it!

Rgds,
-Dimitri

This benchmark is for discussing about the pure performance problem in InnoDB engine. The setting is preferred as simple not safer. The binlog may have the another bound. But for real systems, binlog is important of course. Discussing about performance with binlog is the next step, I think. I will test it as you say in the next post and discuss performance disadvantages (or fix it).

Whether innodb_support_xa is needed or not is depend on the each user. If innodb_support_xa=1 and using binlog, 2 times fsync() is done for the each transaction. It is “prepare” fsync() and “commit” fsync(), the writing binlog for the transaction is done between the fsyncs. So, it affects to performance clearly. But MySQL seems to adjust consistency between InnoDB and binlog when crash recovery. “prepared but not committed transaction” seems to be rollbacked if the transaction is not committed in the binlog yet, and be committed if the transaction is committed in the binlog. So innodb_support_xa=1 seems to be safer than innodb_support_xa=0, but it is not perfect.
There are possibility still that the transaction which is committed in InnoDB but not written in binlog exists, when power trouble for example.

Thank you

Is it safe to not use binlog in production? I thought binlog is needed for recovery purpose.

If binlog is needed, then innodb_support_xa is also needed, right?

How much of a performance penalty does enabling binlog & innodb_support_xa incur then?

The disadvantages of “innodb_stats_update_need_lock = 0″ is only that “DATA_FREE” column of “SHOW TABLE STATUS” is not updated. The value is only used for the “SHOW TABLE STATUS” for now. So, there are no influence to the other operations.

And I intend “innodb_support_xa = false” as a little optimization. The undo entry may be different a little from “true”. And this test doesn’t use binlogs.

Thank you