Период синхронизации журнала коммитов

Вы ничего не упускаете. Такие базы данных, как Cassandra и Scylla, не только обеспечивают согласованность в обмен на доступность при сбоях, но, подобно традиционным базам данных, таким как Postgres, также жертвуют надежностью в пользу производительности. Вы можете изменить параметр commitlog_sync на batch или уменьшить commitlog_sync_period_in_ms; обратите внимание, что если вы это сделаете, лучше всего хранить журнал фиксации на другом носителе, а не в каталоге данных.

Причина этого заключается в том, что устойчивость может быть достигнута за счет постоянства, а также за счет репликации. Типичный пользователь Cassandra/Scylla обычно имеет RF = 3 и пишет с уровнем согласованности QUORUM, так что для фактической потери данных вам потребуются скоординированные сбои нескольких машин.

(Отказ от ответственности: я сотрудник ScyllaDB)

Я думаю, что вам не хватает того, что данные записываются в журнал фиксации на диск и в memtable одновременно, и предполагая, что вы используете RF> 1 с CL> 1 (например, кворум), чем даже если конкретный узел вышел из строя, другие реплики все еще будут иметь данные, которые позже можно будет восстановить.

Если вы используете RF > 1 и CL = ONE, также есть вероятность, что если узел выйдет из строя до синхронизации реплики, данные будут потеряны.

Если весь кластер выходит из строя или в случае кластера с одним узлом, ваш клиент действительно может получить SUCCESS ACK обратно, но данные будут потеряны.

Вы можете ознакомиться с документацией по архитектуре Scylla для лучшего понимания:

• http://docs.scylladb.com/architecture/architecture-fault-tolerance/< /а>
• http://docs.scylladb.com/architecture/console_CL_full_demo/