etcd 3.4.3 & Jepsen Test
https://jepsen.io/analyses/etcd-3.4.3
1.1 Consistency Documentation
- etcd’s documentation: “API exhibit sequential consistency
the strongest consistency guarantee available for distributed systems”
While the strongest is “linearizability”
- etcd has “serializable isolation, the strongest isolation level available”
While “strict serializability” is the strongest.
- Results
- Incorrect documentation (index of the first record 0 or 1)
- Locks aren’t real. Документация плохо объясняет, что такое Lock, как его
использовать, какие гарантии консистентности он имеет.
- Один из проведенных тестов смог добиться,
что два процесса взяли лок одновременно. Проблема часто
проявляется на маленьких TTL: 1, 2, 3 секунды.
- Была найдена проблема в исходниках, но даже её исправление не поможет,
потому что распределённый лок - это фундаментально-небезопасная концепция
в асинхронной распределённой системе.
- Вкратце. Если процесс А взял лок и послал запрос в БД. Потом он погиб,
и процесс B захватил лок. И послал сообщение в БД. При этом сообщение от
А может прийти после сообщения от В. Асинхронность.
- Результаты и обсуждения.
- Key-Value операции были на самом деле strict-serializable при записи, чтении
и даже в multi-key транзакциях (учитывая падения, сдвигания времени,
проблемы с сетью, изменениях в списке нод)
- Watch корректно работают с отдельными ключами
- etcd locks (как и все распределенные локи)
не предоставляют взаимного исключения (mutual exclusion). Даже в здоровом
кластере с идеально синхронизированными часами.
- etcd команда поправила проблемы в документации.