Files
SHiNE-server/docs/Archive/04_TEST_AND_OPERATIONS.md
T

114 lines
5.0 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Проверка и эксплуатация Archive Publisher
## Перед ночным тестом
- [ ] Новый `shine_users` уже развёрнут на том Solana-кластере, который использует сервер.
- [ ] Серверный JAR собран из этого пакета.
- [ ] БД забэкаплена.
- [ ] `archive.publish.enabled=true`.
- [ ] `archive.publish.time=00:00`.
- [ ] `archive.publish.zoneId` соответствует желаемой локальной полуночи.
- [ ] `server.SHiNE.login` соответствует root/client keys.
- [ ] Arweave JWK читается пользователем процесса.
- [ ] На Arweave wallet достаточно AR.
- [ ] `data/archive` доступна на запись.
- [ ] В логе есть `Archive publisher включён` и точное время следующего запуска.
## Во время job
Нормальная последовательность логов/статусов:
```text
SNAPSHOT_CREATED
FILE_BUILT
ARWEAVE_UPLOADED
ARWEAVE_CONFIRMED
SOLANA_SUBMITTED
SOLANA_FINALIZED
CURSORS_COMMITTED
```
После `FILE_BUILT` существует `.tmp.SHiNE-archive`.
После полного Arweave upload имя уже содержит настоящий TX ID.
## После успешного первого job
Проверить:
```bash
find data/archive -maxdepth 1 -type f -name '*.SHiNE-archive' -ls
```
```sql
SELECT big_block_number, status, local_archive_path, arweave_confirmations
FROM archive_publish_job ORDER BY id DESC LIMIT 1;
```
```sql
SELECT count(*) AS archived_blockchains FROM archive_chain_cursor;
```
```sql
SELECT login, archive_head_tx_id, archive_head_hash
FROM solana_user_pda_current
WHERE login='<SERVER_LOGIN>';
```
## Проверка второй публикации
До следующей полуночи добавить несколько новых SHiNE records только в часть blockchain. После следующего job:
- в новый big block должны попасть только изменившиеся blockchain;
- одна blockchain в новом big block должна иметь один chunk независимо от числа новых records;
- cursor blockchain, которая не изменилась, должен остаться на старом big block/chunk;
- backlink изменившегося chunk должен указывать на предыдущий chunk этой же blockchain;
- FULL reference table нового big block должна содержать все предыдущие finalized big blocks.
## Crash/restart сценарии
### Restart после FILE_BUILT
Должен использоваться тот же frozen job и тот же локальный файл.
### Restart после ARWEAVE_UPLOADED
Не должно быть повторной оплаты/upload. Если TX сохранён, но rename не успел произойти, recovery переименует `.tmp` в имя с TX ID.
### Restart после SOLANA_FINALIZED
При совпадении PDA head с job сервер должен только commit cursors.
## Обычный сервер без публикации
Проверить отдельно:
```properties
archive.publish.enabled=false
```
Сервер должен запускаться без Arweave/root/client archive key files и не создавать `archive_publish_job`.
## Проверка trusted importer
1. На принимающем сервере указать только тестовый publisher:
```properties
archive.import.allowedPublishers=<publisher-login>
```
2. Перезапустить сервер.
3. Дождаться Solana PDA sync и цикла importer-а.
4. Проверить, что у publisher в `solana_user_pda_current` после успешного цикла `archive_imported=true`, а `archive_last_imported_tx_id=archive_head_tx_id`.
5. Проверить `archive_blockchain_location`.
6. Для blockchain, которой локально не хватало блоков, убедиться, что `blockchain_state.last_block_number` вырос.
7. Для уже существующих блоков importer должен пропускать совпадающий hash, а не создавать дубликат.
8. Временно удалить publisher из whitelist и убедиться, что новые archive heads больше не скачиваются.
### Проверка Viewer
Открыть `Настройки → Архив блокчейна`, получить ссылку и проверить:
- `tx`, `offset`, `size`, `blockchain` присутствуют;
- Viewer собирает несколько chunks по backlink;
- неправильный `blockchain` в URL приводит к ошибке проверки;
- `channel` открывает нужный канал;
- `message` прокручивает к нужному block number.