Valkey как платформенный сервис¶
Требования применяются к production Valkey, предоставляемому приложению как
cache или authoritative state. Общие требования к data services и backup
определены в смежных инфраструктурных документах. Уровни обязательности
определены в корневом README.md.
INF-DAT-003. Роль данных и исчерпание памяти¶
Уровень: MUST
Применяется к: production Valkey
Каждый экземпляр должен быть объявлен либо cache, либо authoritative state и иметь конечный memory limit. Для cache должны быть определены eviction policy, источник реконструкции, максимальное время полного восстановления и наблюдаемое поведение приложения при отсутствии ключа.
Для authoritative state автоматическое вытеснение данных запрещено: исчерпание
памяти должно возвращать наблюдаемую ошибку записи. Цель должна объявлять
capability persistent-data, а persistence, backup и восстановление должны
выполнять INF-BCK-001–INF-BCK-003 и
INF-BCK-006–INF-BCK-010.
Обоснование¶
Cache допускает потерю при проверенном восстановлении, тогда как незаметное вытеснение authoritative state является потерей данных.
Проверка¶
- запрос memory limit, eviction policy и роли экземпляра;
- исчерпание памяти с проверкой eviction или явной ошибки записи;
- полная очистка и измерение реконструкции cache;
- валидация capability и restore authoritative state.
Исключения¶
Разные роли MAY использовать общий кластер только как отдельные экземпляры с независимыми memory limits, credentials и политиками исчерпания.
INF-DAT-012. Failover и потеря записей Valkey¶
Уровень: MUST
Применяется к: production Valkey профиля high-availability
Платформа должна автоматизированно обнаруживать и публиковать новый primary. Прежний primary должен быть fenced от записи до допуска нового, а клиент не должен одновременно записывать в обе стороны network partition.
Режим репликации и критерий подтверждения записи должны задавать максимальную потерю подтверждённых записей и соответствовать RPO для authoritative state либо объявленной допустимой потере cache.
Обоснование¶
Обнаружение нового primary без fencing допускает расходящиеся записи, а асинхронная репликация может потерять уже подтверждённый результат.
Проверка¶
- failover и network partition под непрерывной записью;
- негативная запись в прежний primary после переключения;
- измерение подтверждённых, но потерянных записей;
- reconnect клиентов и восстановление репликации.
Исключения¶
Не допускаются для fencing. Профиль single-instance находится вне области
требования.