本文へスキップ
このページは英語からの機械翻訳を使用しており、誤りや不明瞭な表現が含まれている可能性があります。最も正確な情報については、オリジナルの英語版をご覧ください。頻繁な更新のため、一部のコンテンツはオリジナルの英語になっている可能性があります。Crowdinでの取り組みに参加して、このページの翻訳改善にご協力ください。 (Crowdin translation page, Contributing guide)

ノードデータの削除

このページでは、過去のブロック状態を削除してストレージの必要量を減らす方法を説明します。 カイアはブロック状態を刈り込むために2つのアプローチを提供している：

剪定の影響を理解する​

「ライブ・プルーニング "は、古い状態を継続的に削除し、ディスクサイズを最小限に保つ。 しかし、付随する簿記作業のため、ライブ・プルーニングはブロック同期速度をわずかに低下させる。 一方、"バッチ刈り込み "は移行完了後のパフォーマンスには影響しないが、移行セッションには数日かかり、状態をコピーするために一時的に大きな空きディスク容量が必要になる。

活剪定の方法​

ジェネシス・ブロックからライブ・プルーニングを有効にするには、ノードの起動時に --state.live-pruning フラグを使用する。 ライブ・プルーニングがすでに有効になっているデータベースから開始する場合、このフラグはオプションですが、わかりやすくするために推奨します。

備考

state.live-pruning-retentionのNNN`フラグ（デフォルト：172800秒、つまり48時間）を使って、ライブプルーニングの保持期間をコントロールすることができる。 このフラグは、過去のブロック状態が刈り込まれるまでの保存期間を決定する。

インフォメーション

ライブ・プルーニングのあるデータベースとないデータベースは互換性がない。 ノードをライブ・プルーニングで実行するには、--state.live-pruningフラグを付けたgenesisブロックから開始するか、すでにライブ・プルーニングが有効になっているchaindata snapshotから開始する必要がある。

非ライブ・プルーニング・データベースをライブ・プルーニング・データベースに変換することはできません。 以下は、表示される可能性のあるログメッセージの例です：


#
INFO[08/27,14:09:01 +09] [41] データベースへのライブプルーニングフラグの書き込み
# ライブプルーニングが有効
INFO[08/27,14:09:01 +09] [41] ライブプルーニングが有効 retention=172800
# ライブプルーニングが無効
INFO[08/27,14：09:46 +09] [41] データベースにフラグが保存されていないため、ライブプルーニングが無効
# チェーンが進んだ後にライブプルーニングを有効にできない (ヘッドブロック数 > 0)
Fatal: プロトコルスタックの起動エラー: チェーンが進んだ後にライブプルーニングを有効にできない

一括剪定の方法​

前提条件​

  • m6i.8xlarge（32コア、128GBメモリー）以上のスペックのマシンでの実行を推奨。
  • マシンに十分な空きディスク容量（500GB以上）があること。
  • 全プロセスの完了には約7日間かかる：
    • ステージ1：状態を新しいディレクトリにコピー（移行）する。 状態移行が完了しました」というメッセージが表示される。
    • ステージ2：新しいディレクトリでブロック同期を続ける。 この手順の後、古いディレクトリは削除される。

ステップ​

  1. コンソール経由でノードに接続する：

ken attach --datadir /var/kend/data

  1. admin名前空間RPCを使用して状態の移行を制御する：

// 開始
> admin.startStateMigration()
null
// 進捗確認
> admin.stateMigrationStatus
// 中止
> admin.stopStateMigration()

ページを改善してください。