Цитата об одной из настроек InnoDB: innodb_flush_log_at_trx_commit — имеет три допустимых значения: 0, 1, 2. При значении равном 0, лог сбрасывается на диск один раз в секунду, вне зависимости от происходящих транзакций. При значении равном 1, лог сбрасывается на диск при каждой транзакции. При значении равном 2, лог пишется при каждой транзакции, но не сбрасывается на диск никогда, оставляя это на совести ОС. По умолчанию используется 1, что является самой надежной настройкой, но не самой быстрой. В общем случае вы можете смело использовать 2, данные могут быть утеряны лишь в случае краха ОС и лишь за несколько секунд (зависит от настроек ОС). 0 — самый быстрый режим, но данные могут быть утеряны как при крахе ОС, так и при крахе самого сервера MySQL (впрочем данные лишь за 1-2 секунды).
Вопрос: Значит ли это что при значениях 0 и 2 в случае краха я потеряю транзакцию, или даже при таких настройках при крахе она откатится назад? И т.е. если я хочу гарантированные true транзакции то мне надо ставить только 1?
если я хочу гарантированные true транзакции то мне надо ставить только 1?
Да.
И надо бы учитывать что это только то, на что может повлиять СУБД - т.е. вызвать fsync. Нижележащие ОС и железо могут не осуществлять реальную запись данных при ответе на fsync. Обычно fsync честный, но это стоит проверять или в документации (к рейд-контроллеру, например) или у гугла или синтетикой (результаты бенчмарков на разных innodb_flush_log_at_trx_commit должны различаться существенно)
Значения 0 и 2 - данные о коммите транзакции в WAL могут не успеть записаться на диск и при восстановлении базы эти транзакции будут отменены. Ведь если в WAL нет данных о коммите - как СУБД понять, была транзакция закоммичена или авария случилась ещё до коммита и транзакция была прервана?
Простой
