> ## Documentation Index > Fetch the complete documentation index at: https://docs.injective.network/llms.txt > Use this file to discover all available pages before exploring further. # アーカイブノードのセットアップとリカバリ Injectiveアーカイブノードのセットアップ、設定、およびリカバリのガイドです。ゲートウェイプロキシの背後にセグメント化されたアーカイブノード群をデプロイする方法に加え、協調アップグレードや予定外のチェーン停止後にアーカイブノードを復旧する方法を説明します。 **プルーニングされたスナップショットやバリデーターの復旧をお探しですか？** プルーニングされたスナップショットのリソースおよび協調セキュリティアップグレードの復旧手順については、[バリデーターのトラブルシューティングガイド](/jp/infra/coordinated-upgrades)を参照してください。 **アップグレードまたは停止後の復旧が必要ですか？** 復旧手順については[アップグレードまたは停止後のアーカイブノードの復旧](#アップグレードまたは停止後のアーカイブノードの復旧)に進んでください。 ## アーカイブノードのセットアップ アーカイブデータの提供をより扱いやすくするため、データを小さなセグメントに分割しています。これらのセグメントは `s3://injective-snapshots/mainnet/subnode` に保存されています。 このバケットは一般公開されています。AWSの認証情報は不要です： ```bash theme={null} # 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]` で設定する方法については、以下の[ゲートウェイ設定](#gateway設定)を参照してください。 これらのセグメントは、ブロック範囲に基づいてクエリを適切なノードにルーティングするアグリゲータープロキシであるゲートウェイによって結合されます。 アーカイブアーキテクチャ ## システム要件 アーカイブデータのスライスをホストする各ノードは、以下の最小要件を満たす必要があります。 | コンポーネント | 最小仕様 | 備考 | | --------- | -------------------- | ------------------------------------- | | **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. セットアップに必要な履歴を含むアーカイブセグメントをダウンロードします ```bash theme={null} # 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. 設定フォルダを生成します ```bash theme={null} injectived init $MONIKER --chain-id injective-1 --home $INJ_HOME --overwrite ``` #### 4. app.tomlファイルでプルーニングを無効化し、config.tomlファイルでp2pをブロックし、ログレベルをerrorに設定します。 これにより、データがプルーニングされず、ノードが停止状態を維持することが保証されます。ログレベルをerrorに設定するとディスク操作が減り、パフォーマンスが向上します。 ```bash theme={null} # 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. ノードを起動します ```bash theme={null} injectived start --home $INJ_HOME ``` ### Gateway設定 Gatewayは、リクエストされたブロック高に基づいてRPC、gRPC、およびAPIクエリを正しいアーカイブノードにルーティングするリバースプロキシです。以下のリファレンス実装は、エコシステムコントリビューターである[Decentrio](https://github.com/decentrio/gateway)によるものです。 Gatewayは受信リクエストを検査し、ブロック高を判定して、その範囲を保持するアップストリームノードに転送します。ブロック高を認識できるリバースプロキシ（nginx、Caddy、カスタムルーティングを備えたHAProxy）であれば、同じ目的を果たすことができます。 #### 1. gatewayリポジトリをクローンします ```bash theme={null} git clone https://github.com/decentrio/gateway ``` #### 2. gatewayをビルドします ```bash theme={null} make build ``` #### 3. 設定ファイルを作成します ```yaml theme={null} 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] # # 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を起動します ```bash theme={null} gateway start --config $CONFIG_FILE ``` *** ## アップグレードまたは停止後のアーカイブノードの復旧 アーカイブセグメントノードは静的であるため、コンセンサスに参加せず、p2p経由の同期も行いません。ただし、協調アップグレードや予定外のチェーン停止の影響を受ける可能性はあります。特に**プルーニングされた先端（tip）ノード**と、直近のブロック高をカバーするセグメントノードが影響を受けます。 ### プルーニングされた先端ノード プルーニングされた先端ノードは、アーカイブノード群の中で唯一、ライブチェーンとアクティブに同期するノードです。協調アップグレードや予定外の停止時には、他のフルノードと同様に扱ってください： 1. ノードを停止する 2. 新しいバイナリに入れ替える 3. 確認する：`injectived version` 4. ノードを起動する 先端ノードは `priv_validator_state.json` を持たない（バリデーターではない）ため、二重署名のリスクはありません。先端ノードのstateが破損している場合（AppHashの不一致）は、プルーニングされたスナップショットから復旧してください。[バリデーターのトラブルシューティングとスナップショットリソース](/jp/infra/coordinated-upgrades#スナップショットリソース)を参照してください。 ### 直近のブロック高をカバーするセグメントノード アップグレードによって過去のブロックの処理方法や保存方法が変更される場合（クエリ結果に影響するstateマイグレーションなど）、アップグレード境界付近のブロック高をカバーするセグメントノードが不整合なデータを返す可能性があります。その場合： 1. 影響を受けたセグメントノードを停止する 2. S3から更新されたセグメントをダウンロードする（アップグレード後にインフラチームが修正済みセグメントを公開する場合があります）： ```bash theme={null} aws s3 cp --no-sign-request --recursive s3://injective-snapshots/mainnet/subnode/$SNAPSHOT_DIR $INJ_HOME ``` 3. そのセグメントに指定されたバージョンにバイナリを更新する 4. ノードを再起動する ### 古いセグメントノード 過去のブロック範囲をカバーするセグメントノード（`0073`、`8088`）は、通常、チェーンアップグレードの影響を受けません。これらは、そのデータを生成したバージョンのバイナリで既存データを提供します。アップグレードが過去のクエリの処理方法を明示的に変更しない限り、対応は不要です。 ### ゲートウェイ ゲートウェイ自体はステートレスであり、チェーンアップグレード時にアップグレードする必要はありません。ただし、セグメントノードを追加または置き換えた場合は、新しいアップストリームエンドポイントを反映するようにゲートウェイの設定を更新し、再起動してください。 復旧作業の後は必ず、各セグメント範囲からブロックをクエリしてレスポンスを確認し、ゲートウェイが正しくルーティングしていることを検証してください。設定を誤ったゲートウェイは、特定のブロック高範囲に対してエラーや古いデータを気づかれないまま返す可能性があります。