Добавить resync блокчейна при рассинхроне

2026-06-26 15:25:11 +04:00
parent 23edad416c
commit be4f76834a
11 changed files with 783 additions and 17 deletions
@@ -0,0 +1,45 @@
+# Вернуть настоящую tmp_bch-схему для обычного AddBlock
+
+## Зачем нужна эта доработка
+
+Сейчас обычный `AddBlock` пишет данные так:
+
+1. в SQL-транзакции добавляет блок в БД и обновляет `blockchain_state`;
+2. делает `commit`;
+3. только после этого дописывает основной файл `<blockchainName>.bch`.
+
+Это рабочая схема, но она не идеально crash-safe. Если сервер резко упадёт между `commit` БД и записью файла, можно получить состояние:
+
+- в БД новый блок уже есть;
+- в `.bch` файла этого блока ещё нет.
+
+При этом в проекте уже есть логика startup-recovery через `*.tmp_bch`, но текущий `BlockchainWriter` её полноценно не использует. Из-за этого writer и recovery сейчас живут в разных моделях.
+
+## Что планируем сделать
+
+Нужно вернуть единую и понятную схему:
+
+1. обычный `AddBlock` работает через временный файл `<blockchainName>.tmp_bch`;
+2. после успешной подготовки нового содержимого выполняется атомарная подмена `tmp -> main`;
+3. `BlockchainTmpRecoveryOnStartup` и `BlockchainWriter` используют одну и ту же модель;
+4. при резкой перезагрузке сервер на старте может корректно добрать или откатить незавершённый файловый шаг.
+
+## Что уже есть в коде
+
+- recovery-класс: `SHiNE-server/src/main/java/server/ws/BlockchainTmpRecoveryOnStartup.java`
+- файловые helper-методы под `tmp_bch`: `SHiNE-server/shine-server-blockchain/src/main/java/utils/files/FileStoreUtil.java`
+- текущий writer: `SHiNE-server/shine-server-net-protocol/src/main/java/server/logic/ws_protocol/JSON/handlers/blockchain/Net_AddBlock_Handler_utils/BlockchainWriter.java`
+
+## Что надо будет изменить
+
+1. Переписать `BlockchainWriter`, чтобы он больше не писал сразу в основной `.bch`.
+2. Привести порядок записи и замены файла в соответствие с `BlockchainTmpRecoveryOnStartup`.
+3. Проверить сценарии:
+   - обычный `AddBlock`;
+   - резкий restart до commit БД;
+   - резкий restart после commit БД, но до замены файла;
+   - recovery на старте при наличии `*.tmp_bch`.
+
+## Почему это отложено отдельно
+
+Это отдельная задача от server-to-server resync. Для divergence-resync сейчас важнее сначала закончить безопасный SQL cleanup одной цепочки, а усиление crash-safety обычного `AddBlock` делать следующим самостоятельным шагом.