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

5.0 KiB
Raw Permalink Blame History

Проверка и эксплуатация 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

Нормальная последовательность логов/статусов:

SNAPSHOT_CREATED
FILE_BUILT
ARWEAVE_UPLOADED
ARWEAVE_CONFIRMED
SOLANA_SUBMITTED
SOLANA_FINALIZED
CURSORS_COMMITTED

После FILE_BUILT существует .tmp.SHiNE-archive. После полного Arweave upload имя уже содержит настоящий TX ID.

После успешного первого job

Проверить:

find data/archive -maxdepth 1 -type f -name '*.SHiNE-archive' -ls
SELECT big_block_number, status, local_archive_path, arweave_confirmations
FROM archive_publish_job ORDER BY id DESC LIMIT 1;
SELECT count(*) AS archived_blockchains FROM archive_chain_cursor;
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.

Обычный сервер без публикации

Проверить отдельно:

archive.publish.enabled=false

Сервер должен запускаться без Arweave/root/client archive key files и не создавать archive_publish_job.

Проверка trusted importer

  1. На принимающем сервере указать только тестовый publisher:
archive.import.allowedPublishers=<publisher-login>
  1. Перезапустить сервер.
  2. Дождаться Solana PDA sync и цикла importer-а.
  3. Проверить, что у publisher в solana_user_pda_current после успешного цикла archive_imported=true, а archive_last_imported_tx_id=archive_head_tx_id.
  4. Проверить archive_blockchain_location.
  5. Для blockchain, которой локально не хватало блоков, убедиться, что blockchain_state.last_block_number вырос.
  6. Для уже существующих блоков importer должен пропускать совпадающий hash, а не создавать дубликат.
  7. Временно удалить publisher из whitelist и убедиться, что новые archive heads больше не скачиваются.

Проверка Viewer

Открыть Настройки → Архив блокчейна, получить ссылку и проверить:

  • tx, offset, size, blockchain присутствуют;
  • Viewer собирает несколько chunks по backlink;
  • неправильный blockchain в URL приводит к ошибке проверки;
  • channel открывает нужный канал;
  • message прокручивает к нужному block number.