Насколько безопасен SQLite WAL при сбоях питания?

Чтобы ответить полностью, нам нужно знать, что у вас установлено для PRAGMA synchronous, поскольку это влияет на то, когда вызывается fdatasync() и, следовательно, когда буферы очищаются на физическом диске.

Когда вы цитируете «до тех пор, пока приложение готово пожертвовать долговечностью из-за потери мощности», имеется в виду наличие synchronous=NORMAL. Здесь WAL синхронизируется с диском только при установлении контрольных точек (один fdatasync() для WAL и один для основной БД после его слияния). Вы должны быть хорошо защищены от коррупции, но могут быть некоторые записи, которые никогда не попадают на пластину и, таким образом, теряются: отсюда и потеря прочности. Однако положительным моментом является гораздо меньше медленной fdatasync () для фактической синхронизации данных.

Чтобы обеспечить максимальную защиту от потери данных, вам может потребоваться synchronous=FULL. Это увеличивает надежность, но стоимость одной транзакции записи составляет один fdatasync(). Однако это все же лучше, чем режим без WAL, где было бы два вызова fdatasync() - один для журнала транзакций и один для основной БД.

Пока вызовы синхронизации к вашей ОС работают безупречно, у вас нулевой риск повреждения базы данных. Однако это может быть так, а может и не быть - см. Документацию sqlite для более подробного объяснения этого.

Чтобы исправить Дуга Карри (см. Сообщение MattR): вы рискуете потерять транзакции, только если @ synchronous = NORMAL @. Если @ synchronous = FULL @ (по умолчанию), вы не жертвуете долговечностью. Подробнее см. http://www.sqlite.org/draft/wal.html. на этом.

Я считаю, что ведение журнала WAL на самом деле безопаснее, чем «классическое» ведение журнала (в случае несовершенной системной синхронизации), потому что вероятность того, что база данных сделает что-то критическое в данный момент, ниже, насколько я понимаю ведение журнала WAL. Однако в настоящее время у меня нет достоверных данных, подтверждающих это.