11 KiB
html, parent, seo, labels
| html | parent | seo | labels | |||
|---|---|---|---|---|---|---|
| server-doesnt-sync.html | troubleshoot-the-rippled-server.html |
|
|
rippledサーバが同期しない
このページでは、rippledサーバが正常に起動したのに、ネットワークに完全に接続できずに「connected」状態のままになっている場合の原因について説明します。（サーバが起動中または起動直後にクラッシュした場合は、サーバが起動しないをご覧ください。）
以下の手順では、サポートされているプラットフォームにrippledがインストールされていることを前提としています。
通常の同期動作
ネットワークとの同期は、通常はおよそ5分から15分で完了します。その間に、サーバは次のようなさまざまなことを行います。
- 推奨バリデータリストを読み込み（例:
vl.ripple.com）、信頼できるバリデータを判断します。 - ピアサーバを検出して接続します。
- 信頼できるバリデータをリッスンして、最近検証されたレジャーハッシュを見つけます。
- ピアから最新のレジャーを完全にダウンロードし、それを使ってレジャーデータの内部データベースを構築します。
- 新たにブロードキャストされたトランザクションを収集し、それを進行中のレジャーに適用します。
サーバがこれらのタスクを行うときにネットワークに同調して対応できなかった場合は、サーバはネットワークと同期しない状態になります。
最初のステップ: 再起動
多くの同期の問題は、サーバを再起動することで解決できます。最初に同期が失敗した原因がどのようなものであっても、2回目では成功する場合があります。
[server_infoメソッド][]でserver_stateがproposingまたはfull以外の状態であると示され、server_state_duration_usが900000000（15分のマイクロ秒表記）より大きい場合は、rippledサービスをシャットダウンしてから数秒間待ち、再起動してください。場合によっては、マシン全体を再起動します。
問題が解決しない場合は、このページに記載されている他の原因を確認してください。いずれも当てはまらないと思われる場合は、rippledリポジトリに問題を登録し、「Syncing issue」ラベルを追加します。
同期の問題のよくある原因
同期の問題の原因として最もよくあるのは、システム要件を満たしていないことです。要件を満たせない主な原因は次の3つです。
- 低速なディスク。 安定して高速な性能を発揮するソリッドステートディスク（SSD）が必要です。AWSなどのクラウドプロバイダーはディスク性能を保証しておらず、ハードウェアを共有する他のユーザの影響を受ける可能性があります。
- 不十分なRAM。 メモリー要件はさまざまな要因に大きく左右されます。例えば、ネットワークの負荷やXRP Ledgerがどのように使われるかなど、予測しづらい要因もあるため、念のため最小システム要件よりも大きいメモリーを用意することをお勧めします。
- 品質の悪いネットワーク接続。 ネットワーク要件は、主にXRP Ledgerをユーザがどのよう使うかによって左右されますが、接続が低速または不安定な場合、XRP Ledgerに追加された新しいトランザクションやデータとの同期がとれなくなる可能性があります。
同期の問題が解消されない場合は、サーバがシステム要件を満たしているかもう一度確認してください。サーバの使用方法によっては、「最小」要件よりも高い「推奨」要件を満たす必要があります。「推奨」要件を満たしていても、まだ同期ができない場合は、このページの他の原因を試してみてください。
バリデータリストを読み込めない
デフォルトの構成では、vl.ripple.comから受信した推奨バリデータリストを使用します。このリストは、Rippleの暗号鍵ペアで署名されており、有効期限が組み込まれています。サーバが何らかの理由でリストをvl.ripple.comからダウンロードできない場合、サーバは信頼できるバリデータのセットを選択せず、有効として宣言できるレジャーを決定できません。（Testnetや別の並列ネットワークに接続している場合、サーバは代わりにそのネットワークの信頼できるバリデータのリストを使用します。）
[server_infoメソッド][]レスポンスのvalidator_listブロックは、バリデータリストの有効期限などのステータスを示します。リストがあるが期限切れである場合、サーバは以前はそのバリデータリストのサイトに接続できていたものの、その後接続できなくなった可能性があります。その場合、現在のリストはサーバがそれより新しいリストをダウンロードできなかったために期限切れとなった可能性があります。
また、[validator_list_sitesメソッド][]を使用して、より詳細な情報を取得することもできます。レスポンス内のバリデータサイトオブジェクトにlast_refresh_statusおよびlast_refresh_timeフィールドがない場合、サーバからバリデータリストのサイトへの接続に問題があることを示しています。ファイアウォールの設定をチェックして、ポート80（HTTP）または443（HTTPS）の発信トラフィックをブロックしていないことを確認してください。また、DNSがバリデータリストのサイトのドメインを解決できることも確認してください。
十分な数のピアがない
サーバが十分な数のピアサーバに接続していない場合、サーバは十分なデータをダウンロードできず、ネットワークが新しいトランザクションを処理するときに同期がとれなくなる可能性があります。この問題は、ネットワーク接続の信頼性が低い場合や、十分な数の信頼できる固定ピアを追加せずにサーバをプライベートサーバとして構成している場合に起こる可能性があります。
[peersメソッド][]を使用して、サーバの現在のピアについての情報を取得します。ピアの数が10または11の場合、ファイアウォールが着信ピア接続をブロックしていることを示しています。ポートフォワーディングを設定して、より多くの着信接続を許可します。サーバがプライベートサーバとして構成されている場合は、構成ファイルの[ips_fixed]スタンザの内容と構文を再度確認し、可能であればプロキシと公開ハブをさらに追加します。
データベースの破損
まれに、rippledサーバの内部データベースに保存されているデータが破損していることで同期の問題が発生する場合があります。サーバが稼動中でなければ、ほとんどの場合、サーバのデータベースを安全に削除できます。データの破損は、ディスクにコピーまたは書き込みするときに起こった一時的なハードウェア障害や、より深刻なディスク障害、別のプロセスがクラッシュしてディスクの誤った部分に書き込んだなど、さまざまな問題の結果として起こる可能性があります。
テストとして、十分な空き容量があれば、サーバのデータベースへのパスを一時的に変更することで、現行のレジャーをダウンロードし直して、別の設定を保存できます。
{% admonition type="info" name="注記" %}データベースのパスを変更した場合、サーバはサーバの現在の[ノードキーペア][]やピアリザベーションなど、保存されている一部の設定を読み込めません。データベースのパスを変更することでサーバの同期の問題が解決した場合は、これらの設定の一部を再作成することをお勧めします。{% /admonition %}
-
rippledサーバが稼働中の場合は停止します。$ sudo systemctl stop rippled -
新しいデータベースを格納するための新しい空のフォルダーを作成します。
$ mkdir /var/lib/rippled/db_new/ $ mkdir /var/lib/rippled/db_new/nudb -
新しいパスを使用するように構成ファイルを編集します。
[node_db]スタンザのpathフィールドと[database_path]スタンザの値を変更します。[node_db] type=NuDB path=/var/lib/rippled/db_new/nudb [database_path] /var/lib/rippled/db_new{% partial file="/@l10n/ja/docs/_snippets/conf-file-location.md" /%}
-
rippledサーバを再起動します。$ sudo systemctl start rippled新しいデータベースを使用してサーバが同期に成功したら、以前のデータベースを格納していたフォルダーを削除できます。また、ハードウェア障害、特にディスクとRAMの障害を確認することもお勧めします。
関連項目
- コンセプト:
- チュートリアル:
- リファレンス:
- rippled APIリファレンス
- [peersメソッド][]
- [server_infoメソッド][]
- [validator_list_sitesメソッド][]
- rippled APIリファレンス
{% raw-partial file="/docs/_snippets/common-links.md" /%}