89338

Frequency of Commits

One tradeoff between durabillty and raw performance is howfrequently new and changed data is

committed. If the data is critical, you want it to be committed immediately so that it is safe in case of

any crash or outage. If the data is less critical, such as counters that would be reset after a crash, or

debugging or logging data where you could afford to lose a few seconds worth, you might prefer the

higher rawthroughput that comes with less frequent commits.

When a memcached operation causes an insert, update, or delete in the underlying InnoDB table, that change might be committed to the underlying table instantly (if

daemon_memcached_w_batch_size=l [1737]) or some time later (if that configuration option

value is greater than 1). In either case, the change cannot be rolled back. If you increase the value

of daemon_memcached_w_batch_size=l [1737] to avoid high l/O overhead during busy times,

commits could become very infrequent when the workload decreases. As a safety measure, a

background thread automatically commits changes madę through the memcached API at regular

intervals. The interval is controlled by the innodb_api_bk_commit_interval

[1739] configuration

option, and by default is 5 seconds.

When a memcached operation causes an insert or update in the underlying InnoDB table, the changed

data is immediately visible to other memcached requests because the new value remains in the

memory cache, even if it is not committed yet on the MySQL side.