# rippledサーバが同期しない

このページでは、[`rippled`サーバ](/ja/docs/concepts/networks-and-servers)が正常に起動したのに、ネットワークに完全に接続できずに[「connected」状態](/ja/docs/references/http-websocket-apis/api-conventions/rippled-server-states)のままになっている場合の原因について説明します。（サーバが起動中または起動直後にクラッシュした場合は、[サーバが起動しない](/ja/docs/infrastructure/troubleshooting/server-wont-start)をご覧ください。）

以下の手順では、サポートされているプラットフォームに[`rippled`がインストール](/ja/docs/infrastructure/installation)されていることを前提としています。

## 通常の同期動作

ネットワークとの同期は、通常はおよそ5分から15分で完了します。その間に、サーバは次のようなさまざまなことを行います。

- 推奨バリデータリストを読み込み（例: `vl.ripple.com`）、信頼できるバリデータを判断します。
- [ピアサーバを検出](/ja/docs/concepts/networks-and-servers/peer-protocol#%E3%83%94%E3%82%A2%E3%81%AE%E6%A4%9C%E5%87%BA)して接続します。
- 信頼できるバリデータをリッスンして、最近検証されたレジャーハッシュを見つけます。
- ピアから最新のレジャーを完全にダウンロードし、それを使ってレジャーデータの内部データベースを構築します。
- 新たにブロードキャストされたトランザクションを収集し、それを進行中のレジャーに適用します。


サーバがこれらのタスクを行うときにネットワークに同調して対応できなかった場合は、サーバはネットワークと同期しない状態になります。

## 最初のステップ: 再起動

多くの同期の問題は、サーバを再起動することで解決できます。最初に同期が失敗した原因がどのようなものであっても、2回目では成功する場合があります。

[server_infoメソッド](/ja/docs/references/http-websocket-apis/public-api-methods/server-info-methods/server_info)で[`server_state`](/ja/docs/references/http-websocket-apis/api-conventions/rippled-server-states)が`proposing`または`full`以外の状態であると示され、`server_state_duration_us`が`900000000`（15分のマイクロ秒表記）より大きい場合は、`rippled`サービスをシャットダウンしてから数秒間待ち、再起動してください。場合によっては、マシン全体を再起動します。

問題が解決しない場合は、このページに記載されている他の原因を確認してください。いずれも当てはまらないと思われる場合は、[`rippled`リポジトリに問題を登録](https://github.com/XRPLF/rippled/issues)し、「Syncing issue」ラベルを追加します。

## 同期の問題のよくある原因

同期の問題の原因として最もよくあるのは、[システム要件](/ja/docs/infrastructure/installation/system-requirements)を満たしていないことです。要件を満たせない主な原因は次の3つです。

- **低速なディスク。** 安定して高速な性能を発揮するソリッドステートディスク（SSD）が必要です。AWSなどのクラウドプロバイダーはディスク性能を保証しておらず、ハードウェアを共有する他のユーザの影響を受ける可能性があります。
- **不十分なRAM。** メモリー要件はさまざまな要因に大きく左右されます。例えば、ネットワークの負荷やXRP Ledgerがどのように使われるかなど、予測しづらい要因もあるため、念のため最小システム要件よりも大きいメモリーを用意することをお勧めします。
- **品質の悪いネットワーク接続。** ネットワーク要件は、主にXRP Ledgerをユーザがどのよう使うかによって左右されますが、接続が低速または不安定な場合、XRP Ledgerに追加された新しいトランザクションやデータとの同期がとれなくなる可能性があります。


同期の問題が解消されない場合は、サーバがシステム要件を満たしているかもう一度確認してください。サーバの使用方法によっては、「最小」要件よりも高い「推奨」要件を満たす必要があります。「推奨」要件を満たしていても、まだ同期ができない場合は、このページの他の原因を試してみてください。

## バリデータリストを読み込めない

デフォルトの構成では、`vl.ripple.com`から受信した推奨バリデータリストを使用します。このリストは、Rippleの暗号鍵ペアで署名されており、有効期限が組み込まれています。サーバが何らかの理由でリストを`vl.ripple.com`からダウンロードできない場合、サーバは信頼できるバリデータのセットを選択せず、有効として宣言できるレジャーを決定できません。（[Testnetや別の並列ネットワーク](/ja/docs/concepts/networks-and-servers/parallel-networks)に接続している場合、サーバは代わりにそのネットワークの信頼できるバリデータのリストを使用します。）

[server_infoメソッド](/ja/docs/references/http-websocket-apis/public-api-methods/server-info-methods/server_info)レスポンスの`validator_list`ブロックは、バリデータリストの有効期限などのステータスを示します。リストがあるが期限切れである場合、サーバは以前はそのバリデータリストのサイトに接続できていたものの、その後接続できなくなった可能性があります。その場合、現在のリストはサーバがそれより新しいリストをダウンロードできなかったために期限切れとなった可能性があります。

また、[validator_list_sitesメソッド](/ja/docs/references/http-websocket-apis/admin-api-methods/status-and-debugging-methods/validator_list_sites)を使用して、より詳細な情報を取得することもできます。レスポンス内のバリデータサイトオブジェクトに`last_refresh_status`および`last_refresh_time`フィールドがない場合、サーバからバリデータリストのサイトへの接続に問題があることを示しています。ファイアウォールの設定をチェックして、ポート80（HTTP）または443（HTTPS）の発信トラフィックをブロックしていないことを確認してください。また、DNSがバリデータリストのサイトのドメインを解決できることも確認してください。

## 十分な数のピアがない

サーバが十分な数の[ピアサーバ](/ja/docs/concepts/networks-and-servers/peer-protocol)に接続していない場合、サーバは十分なデータをダウンロードできず、ネットワークが新しいトランザクションを処理するときに同期がとれなくなる可能性があります。この問題は、ネットワーク接続の信頼性が低い場合や、十分な数の信頼できる固定ピアを追加せずにサーバを[プライベートサーバ](/ja/docs/concepts/networks-and-servers/peer-protocol#%E3%83%97%E3%83%A9%E3%82%A4%E3%83%99%E3%83%BC%E3%83%88%E3%83%94%E3%82%A2)として構成している場合に起こる可能性があります。

[peersメソッド](/ja/docs/references/http-websocket-apis/admin-api-methods/peer-management-methods/peers)を使用して、サーバの現在のピアについての情報を取得します。ピアの数が10または11の場合、ファイアウォールが着信ピア接続をブロックしていることを示しています。[ポートフォワーディングを設定](/ja/docs/infrastructure/configuration/peering/forward-ports-for-peering)して、より多くの着信接続を許可します。サーバがプライベートサーバとして構成されている場合は、構成ファイルの`[ips_fixed]`スタンザの内容と構文を再度確認し、可能であればプロキシと公開ハブをさらに追加します。

## データベースの破損

まれに、`rippled`サーバの内部データベースに保存されているデータが破損していることで同期の問題が発生する場合があります。サーバが稼動中でなければ、ほとんどの場合、サーバのデータベースを安全に削除できます。データの破損は、ディスクにコピーまたは書き込みするときに起こった一時的なハードウェア障害や、より深刻なディスク障害、別のプロセスがクラッシュしてディスクの誤った部分に書き込んだなど、さまざまな問題の結果として起こる可能性があります。

テストとして、十分な空き容量があれば、サーバのデータベースへのパスを一時的に変更することで、現行のレジャーをダウンロードし直して、別の設定を保存できます。

データベースのパスを変更した場合、サーバはサーバの現在の[ノードキーペア](/ja/docs/concepts/networks-and-servers/peer-protocol#%E3%83%8E%E3%83%BC%E3%83%89%E3%82%AD%E3%83%BC%E3%83%9A%E3%82%A2)や[ピアリザベーション](/ja/docs/concepts/networks-and-servers/peer-protocol#%E5%9B%BA%E5%AE%9A%E3%83%94%E3%82%A2%E3%81%A8%E3%83%94%E3%82%A2%E3%83%AA%E3%82%B6%E3%83%99%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3)など、保存されている一部の設定を読み込めません。データベースのパスを変更することでサーバの同期の問題が解決した場合は、これらの設定の一部を再作成することをお勧めします。

1. `rippled`サーバが稼働中の場合は停止します。

```
$ sudo systemctl stop rippled
```
2. 新しいデータベースを格納するための新しい空のフォルダーを作成します。

```
$ mkdir /var/lib/rippled/db_new/
$ mkdir /var/lib/rippled/db_new/nudb
```
3. 新しいパスを使用するように構成ファイルを編集します。`[node_db]`スタンザの`path`フィールド**と**`[database_path]`スタンザの値を変更します。

```
[node_db]
type=NuDB
path=/var/lib/rippled/db_new/nudb

[database_path]
 /var/lib/rippled/db_new
```

4. `rippled`サーバを再起動します。

```
$ sudo systemctl start rippled
```
新しいデータベースを使用してサーバが同期に成功したら、以前のデータベースを格納していたフォルダーを削除できます。また、ハードウェア障害、特にディスクとRAMの障害を確認することもお勧めします。


## 関連項目

- **コンセプト:**
  - [`rippled`サーバ](/ja/docs/concepts/networks-and-servers)
  - [ピアプロトコル](/ja/docs/concepts/networks-and-servers/peer-protocol)
  - [技術に関するよくある質問](/about/faq)
- **チュートリアル:**
  - [ログメッセージについて](/ja/docs/infrastructure/troubleshooting/understanding-log-messages)
  - [容量の計画](/ja/docs/infrastructure/installation/capacity-planning)
- **リファレンス:**
  - [rippled APIリファレンス](/ja/docs/references/http-websocket-apis)
    - [peersメソッド](/ja/docs/references/http-websocket-apis/admin-api-methods/peer-management-methods/peers)
    - [server_infoメソッド](/ja/docs/references/http-websocket-apis/public-api-methods/server-info-methods/server_info)
    - [validator_list_sitesメソッド](/ja/docs/references/http-websocket-apis/admin-api-methods/status-and-debugging-methods/validator_list_sites)