Frequency of Commits-opracowanie

Frequency of Commits
One tradeoff between durability and raw performance is how frequently 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 raw throughput 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=1 [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=1 [1737] to avoid high I/O overhead during busy times,
commits could become very infrequent when the workload decreases. As a safety measure, a
background thread automatically commits changes made 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.
... zobacz całą notatkę