Согласованность эволюции схемы данных в среде асинхронной репликации #8

New Issue

2026-08-17T21:26:15Z

gvsafronov commented

2026-08-17 21:26:15 +00:00

Проблема

В текущей реализации миграции схемы данных используется ленивая стратегия миграции документов (StrategyLazy) при обновлении версии СУБД.
Однако при работе в кластерной среде с асинхронной репликацией возникает ситуация, когда узлы кластера могут иметь разные версии схемы в переходный период обновления.

Симптомы. Документ, мигрированный на основном узле (Node A), реплицируется на вторичный узел (Node B) с более старой версией схемы. Движок MigrateDocument выполняет преобразование «на лету», но это преобразование недетерминировано и зависит от текущей версии схемы на вторичном узле. Отсутствует механизм каскадного обновления или версионирования для репликации, что может приводить к несогласованности данных.

Архитектурная проблема

Как обеспечить согласованные обновления схемы данных в распределённой системе с асинхронной репликацией при сохранении высокой доступности?

Предлагаемые направления исследований

Версионированные документы — хранение версии схемы в метаданных документа, позволяющее узлам определять, какой версии схемы соответствует каждый документ, и применять соответствующие преобразования при чтении или репликации.
Двухфазная миграция — сначала подготовка (изменения схемы применяются, но не применяются принудительно), затем атомарное переключение (все узлы одновременно переключаются на новую схему через протокол координации).
Протокол координации версий — аналог Raft для схем данных, предоставляющий механизм на основе консенсуса для координации переходов между версиями схем в масштабах кластера.
Подход CRDT для схем — конфликт-свободные операции над определением схемы, при которых одновременные изменения схемы от разных узлов могут автоматически объединяться без конфликтов.
Матрица совместимости версий схемы — ведение матрицы совместимости, определяющей, какие версии схем могут взаимодействовать, что обеспечивает постепенные развёртывания и откаты.
Сервис реестра схем (Schema Registry) — выделенный сервис, поддерживающий каноническую версию схемы и координирующий обновления в масштабах кластера.

Соответствующие файлы с исходным кодом

internal/migration/schema_migrator.go
internal/cluster/node.go (движок репликации)
internal/cluster/raft_coordinator.go (координация кластера)

**Проблема** В текущей реализации миграции схемы данных используется ленивая стратегия миграции документов (StrategyLazy) при обновлении версии СУБД. Однако при работе в кластерной среде с асинхронной репликацией возникает ситуация, когда узлы кластера могут иметь разные версии схемы в переходный период обновления. **Симптомы.** Документ, мигрированный на основном узле (Node A), реплицируется на вторичный узел (Node B) с более старой версией схемы. Движок MigrateDocument выполняет преобразование «на лету», но это преобразование недетерминировано и зависит от текущей версии схемы на вторичном узле. Отсутствует механизм каскадного обновления или версионирования для репликации, что может приводить к несогласованности данных. **Архитектурная проблема** Как обеспечить согласованные обновления схемы данных в распределённой системе с асинхронной репликацией при сохранении высокой доступности? **Предлагаемые направления исследований** 1. **Версионированные документы** — хранение версии схемы в метаданных документа, позволяющее узлам определять, какой версии схемы соответствует каждый документ, и применять соответствующие преобразования при чтении или репликации. 2. **Двухфазная миграция** — сначала подготовка (изменения схемы применяются, но не применяются принудительно), затем атомарное переключение (все узлы одновременно переключаются на новую схему через протокол координации). 3. **Протокол координации версий** — аналог Raft для схем данных, предоставляющий механизм на основе консенсуса для координации переходов между версиями схем в масштабах кластера. 4. **Подход CRDT для схем** — конфликт-свободные операции над определением схемы, при которых одновременные изменения схемы от разных узлов могут автоматически объединяться без конфликтов. 5. **Матрица совместимости версий схемы** — ведение матрицы совместимости, определяющей, какие версии схем могут взаимодействовать, что обеспечивает постепенные развёртывания и откаты. 6. **Сервис реестра схем (Schema Registry)** — выделенный сервис, поддерживающий каноническую версию схемы и координирующий обновления в масштабах кластера. **Соответствующие файлы с исходным кодом** - `internal/migration/schema_migrator.go` - `internal/cluster/node.go` (движок репликации) - `internal/cluster/raft_coordinator.go` (координация кластера)

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: gvsafronov/futriix#8