アーカイブノードのセットアップとリカバリ

Injectiveアーカイブノードのセットアップ、設定、およびリカバリのガイドです。ゲートウェイプロキシの背後にセグメント化されたアーカイブノード群をデプロイする方法に加え、協調アップグレードや予定外のチェーン停止後にアーカイブノードを復旧する方法を説明します。

プルーニングされたスナップショットやバリデーターの復旧をお探しですか？ プルーニングされたスナップショットのリソースおよび協調セキュリティアップグレードの復旧手順については、バリデーターのトラブルシューティングガイドを参照してください。

アップグレードまたは停止後の復旧が必要ですか？ 復旧手順についてはアップグレードまたは停止後のアーカイブノードの復旧に進んでください。

アーカイブノードのセットアップ

アーカイブデータの提供をより扱いやすくするため、データを小さなセグメントに分割しています。これらのセグメントは s3://injective-snapshots/mainnet/subnode に保存されています。このバケットは一般公開されています。AWSの認証情報は不要です：

# List all available segments using AWS CLI
aws s3 ls --no-sign-request s3://injective-snapshots/mainnet/subnode/

# Or without AWS CLI, using curl
curl -s "https://injective-snapshots.s3.amazonaws.com/?prefix=mainnet/subnode/&delimiter=/" \
  | tr '<' '\n' | sed -n 's/^Prefix>mainnet\/subnode\/\([^/]*\)\/.*/\1/p' | sort -n

命名規則

ディレクトリ名は、ブロック高の範囲を百万（M）単位でエンコードしています。たとえば、138150 には138Mから150Mまでのブロックが含まれます。セグメントが重複している場合（例：8896 と 8898、あるいは 119127、119141、119143）、より新しい、または範囲の広いセグメントには通常、修正が含まれているか、カバー範囲が拡張されています。不要な重複を避けつつ、目的の範囲を最もよくカバーするセグメントを選択してください。

利用可能なセグメント

この表には最新のセグメントが含まれていない場合があります。新しく公開されたセグメントを確認するには、上記の aws s3 ls コマンドを実行してください。

スナップショットディレクトリ	ブロック高の範囲	Injectiveバージョン	推奨ディスクサイズ
`0073`	0 – 73M	v1.12.1	42 TiB
`6068`	60M – 68M	v1.12.1	7 TiB
`7380`	73M – 80M	v1.12.1	7 TiB
`8088`	80M – 88M	v1.13.3	7 TiB
`8896`	88M – 96M	v1.13.3	7 TiB
`8898`	88M – 98M	v1.13.3	7 TiB
`98106`	98M – 106M	v1.13.3	7 TiB
`98107`	98M – 107M	v1.14.0	7.5 TiB
`66101`	66M – 101M	v1.14.0	27 TiB
`105116`	105M – 116M	v1.15.0	7.5 TiB
`113127`	113M – 127M	v1.15.0	11 TiB
`119127`	119M – 127M	未定	未定
`119141`	119M – 141M	未定	未定
`119143`	119M – 143M	v1.17.0	16 TiB
`138150`	138M – 150M	v1.17.2	5.8 TiB
`150181`	150M – 181M	近日公開	近日公開

未定または近日公開と記載されている行は、S3上には存在するものの、バージョンとディスクサイズがまだ検証されていないセグメントです。これらを使用する前に、インフラチームに問い合わせるか、セグメントのメタデータを確認してください。

全範囲をカバーするためのセグメントの選択

いくつかのセグメントはブロック高の範囲が重複しています。すべてのセグメントが必要なわけではありません。ジェネシスから現在のチェーン先端までの完全なアーカイブカバレッジを実現するための推奨最小セットは以下のとおりです：

ノード	セグメント	ブロック高の範囲	備考
1	`0073`	0 – 73M	ジェネシスから初期のチェーン履歴まで
2	`7380`	73M – 80M
3	`8088`	80M – 88M
4	`8898`	88M – 98M	より広い範囲をカバーするため `8896` ではなく `8898` を使用
5	`98107`	98M – 107M	より広い範囲とより新しいバイナリのため `98106` ではなく `98107` を使用
6	`105116`	105M – 116M	前のセグメントと重複し、冗長性を提供
7	`119143`	119M – 143M	ノード数を最小化するため最も広いセグメントを使用
8	`138150`	138M – 150M
9	`150181`	150M – 181M	最新のセグメント、直近のチェーン高までカバー
先端	プルーニングされたノード	最新ブロック	プルーニングされたノードが、最新のセグメントとライブチェーンの先端との間のギャップをカバーします

プルーニングされた先端（tip）ノードは不可欠です。アーカイブセグメントは静的なスナップショットであり、ライブチェーンとは同期しません。ゲートウェイは直近のブロックに対するクエリをプルーニングされたノードにルーティングし、このノードはp2p経由で同期を維持します。先端ノードを blocks: [1000] で設定する方法については、以下のゲートウェイ設定を参照してください。これらのセグメントは、ブロック範囲に基づいてクエリを適切なノードにルーティングするアグリゲータープロキシであるゲートウェイによって結合されます。

システム要件

アーカイブデータのスライスをホストする各ノードは、以下の最小要件を満たす必要があります。

コンポーネント	最小仕様	備考
CPU	AMD EPYC™ 9454P	48コア / 96スレッド
メモリ	128 GB DDR5 ECC	DDR5-5200 MHz以上、データ整合性のためECC
ストレージ	7 – 40 TB NVMe Gen 4	PCIe 4.0ドライブ、単体ドライブまたはRAID-0アレイのいずれも可

セットアップ手順

アーカイブセグメントをホストする各ノードで実行：

1. セットアップに必要な履歴を含むアーカイブセグメントをダウンロードします

# SNAPSHOT_DIR matches the "Snapshot Dir" column in the table above (0073, 138150)
aws s3 cp --no-sign-request --recursive s3://injective-snapshots/mainnet/subnode/$SNAPSHOT_DIR $INJ_HOME

2. 上記の表に基づいて、適切なinjectiveバイナリまたはイメージタグをダウンロードまたは設定します

3. 設定フォルダを生成します

injectived init $MONIKER --chain-id injective-1 --home $INJ_HOME --overwrite

4. app.tomlファイルでプルーニングを無効化し、config.tomlファイルでp2pをブロックし、ログレベルをerrorに設定します。

これにより、データがプルーニングされず、ノードが停止状態を維持することが保証されます。ログレベルをerrorに設定するとディスク操作が減り、パフォーマンスが向上します。

# Disable pruning in app.toml
sed -i 's/^pruning *= *.*/pruning = "nothing"/' $INJ_HOME/config/app.toml

# Disable p2p and disable create empty blocks on config.toml
awk '
    BEGIN { section = "" }
    /^\[/ {
    section = $0
    }
    section == "[p2p]" {
    if ($1 ~ /^laddr/) $0 = "laddr = \"tcp://0.0.0.0:26656\""
    if ($1 ~ /^max_num_inbound_peers/) $0 = "max_num_inbound_peers = 0"
    if ($1 ~ /^min_num_inbound_peers/) $0 = "min_num_inbound_peers = 0"
    if ($1 ~ /^pex/) $0 = "pex = false"
    if ($1 ~ /^seed_mode/) $0 = "seed_mode = false"
    }
    section == "[consensus]" {
    if ($1 ~ /^create_empty_blocks/) $0 = "create_empty_blocks = false"
    }
    { print }
    ' $INJ_HOME/config/config.toml > $INJ_HOME/config/config.tmp && mv $INJ_HOME/config/config.tmp $INJ_HOME/config/config.toml

# Set log level to error (less disk writes = better performance)
sed -i 's/^log_level *= *.*/log_level = "error"/' $INJ_HOME/config/app.toml

5. ノードを起動します

injectived start --home $INJ_HOME

Gateway設定

Gatewayは、リクエストされたブロック高に基づいてRPC、gRPC、およびAPIクエリを正しいアーカイブノードにルーティングするリバースプロキシです。以下のリファレンス実装は、エコシステムコントリビューターであるDecentrioによるものです。

Gatewayは受信リクエストを検査し、ブロック高を判定して、その範囲を保持するアップストリームノードに転送します。ブロック高を認識できるリバースプロキシ（nginx、Caddy、カスタムルーティングを備えたHAProxy）であれば、同じ目的を果たすことができます。

1. gatewayリポジトリをクローンします

git clone https://github.com/decentrio/gateway

2. gatewayをビルドします

make build

3. 設定ファイルを作成します

upstream:
  # example node 1 holds blocks 0-80M while node 2 holds blocks 80-88M
  - rpc: "http://$NODE1:$RPC_PORT"
    grpc: "$NODE1:$GRPC_PORT"
    api: "http://$NODE1:$API_PORT"
    blocks: [0,80000000]  
  - rpc: "http://$NODE2:$RPC_PORT"
    grpc: "$NODE2:$GRPC_PORT"
    api: "http://$NODE2:$API_PORT"
    blocks: [80000000,88000000]

  # <OTHER NODES HERE>

  # Archival tip, this serves the latest x blocks, usually set as a pruned node
  - rpc: "http://$PRUNED_NODE:$RPC_PORT"
    grpc: "$PRUNED_NODE:$GRPC_PORT"
    api: "http://$PRUNED_NODE:$API_PORT"
    blocks: [1000]


ports:
  rpc: $RPC_PORT
  api: $API_PORT 
  grpc: $GRPC_PORT
  # Leave these as zero to disable for now
  jsonrpc: 0
  jsonrpc_ws: 0

4. Gatewayを起動します

gateway start --config $CONFIG_FILE

アップグレードまたは停止後のアーカイブノードの復旧

アーカイブセグメントノードは静的であるため、コンセンサスに参加せず、p2p経由の同期も行いません。ただし、協調アップグレードや予定外のチェーン停止の影響を受ける可能性はあります。特にプルーニングされた先端（tip）ノードと、直近のブロック高をカバーするセグメントノードが影響を受けます。

プルーニングされた先端ノード

プルーニングされた先端ノードは、アーカイブノード群の中で唯一、ライブチェーンとアクティブに同期するノードです。協調アップグレードや予定外の停止時には、他のフルノードと同様に扱ってください：

ノードを停止する
新しいバイナリに入れ替える
確認する：injectived version
ノードを起動する

先端ノードは priv_validator_state.json を持たない（バリデーターではない）ため、二重署名のリスクはありません。先端ノードのstateが破損している場合（AppHashの不一致）は、プルーニングされたスナップショットから復旧してください。バリデーターのトラブルシューティングとスナップショットリソースを参照してください。

直近のブロック高をカバーするセグメントノード

アップグレードによって過去のブロックの処理方法や保存方法が変更される場合（クエリ結果に影響するstateマイグレーションなど）、アップグレード境界付近のブロック高をカバーするセグメントノードが不整合なデータを返す可能性があります。その場合：

影響を受けたセグメントノードを停止する
S3から更新されたセグメントをダウンロードする（アップグレード後にインフラチームが修正済みセグメントを公開する場合があります）：
aws s3 cp --no-sign-request --recursive s3://injective-snapshots/mainnet/subnode/$SNAPSHOT_DIR $INJ_HOME
そのセグメントに指定されたバージョンにバイナリを更新する
ノードを再起動する

古いセグメントノード

過去のブロック範囲をカバーするセグメントノード（0073、8088）は、通常、チェーンアップグレードの影響を受けません。これらは、そのデータを生成したバージョンのバイナリで既存データを提供します。アップグレードが過去のクエリの処理方法を明示的に変更しない限り、対応は不要です。

ゲートウェイ

ゲートウェイ自体はステートレスであり、チェーンアップグレード時にアップグレードする必要はありません。ただし、セグメントノードを追加または置き換えた場合は、新しいアップストリームエンドポイントを反映するようにゲートウェイの設定を更新し、再起動してください。

復旧作業の後は必ず、各セグメント範囲からブロックをクエリしてレスポンスを確認し、ゲートウェイが正しくルーティングしていることを検証してください。設定を誤ったゲートウェイは、特定のブロック高範囲に対してエラーや古いデータを気づかれないまま返す可能性があります。

​アーカイブノードのセットアップ

​命名規則

​利用可能なセグメント

​全範囲をカバーするためのセグメントの選択

​システム要件

​セットアップ手順

​アーカイブセグメントをホストする各ノードで実行：

​1. セットアップに必要な履歴を含むアーカイブセグメントをダウンロードします

​2. 上記の表に基づいて、適切なinjectiveバイナリまたはイメージタグをダウンロードまたは設定します

​3. 設定フォルダを生成します

​4. app.tomlファイルでプルーニングを無効化し、config.tomlファイルでp2pをブロックし、ログレベルをerrorに設定します。

​5. ノードを起動します

​Gateway設定

​1. gatewayリポジトリをクローンします

​2. gatewayをビルドします

​3. 設定ファイルを作成します

​4. Gatewayを起動します

​アップグレードまたは停止後のアーカイブノードの復旧

​プルーニングされた先端ノード

​直近のブロック高をカバーするセグメントノード

​古いセグメントノード

​ゲートウェイ

アーカイブノードのセットアップ

命名規則

利用可能なセグメント

全範囲をカバーするためのセグメントの選択

システム要件

セットアップ手順

アーカイブセグメントをホストする各ノードで実行：

1. セットアップに必要な履歴を含むアーカイブセグメントをダウンロードします

2. 上記の表に基づいて、適切なinjectiveバイナリまたはイメージタグをダウンロードまたは設定します

3. 設定フォルダを生成します

4. app.tomlファイルでプルーニングを無効化し、config.tomlファイルでp2pをブロックし、ログレベルをerrorに設定します。

5. ノードを起動します

Gateway設定

1. gatewayリポジトリをクローンします

2. gatewayをビルドします

3. 設定ファイルを作成します

4. Gatewayを起動します

アップグレードまたは停止後のアーカイブノードの復旧

プルーニングされた先端ノード

直近のブロック高をカバーするセグメントノード

古いセグメントノード

ゲートウェイ