ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-06 12:55:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Remove Reporting Mode & History Shards docs

Browse Source
This commit is contained in:
mDuo13
2025-09-12 17:03:56 -07:00
parent 7cb5f9a893
commit b1c1ae685a
64 changed files with 88 additions and 1710 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
@l10n/es-ES/docs/concepts/networks-and-servers/ledger-history.md
View File

@@ -58,14 +58,6 @@ Los proveedores de servidores Full History se reservan el derecho de bloquear ac
Para instrucciones de cómo configurar un servidor full history, consultar [Configurar Full History](../../infrastructure/configuration/data-retention/configure-full-history.md).
## Fragmentación del historial
Una alternativa para almacenar todo el histórico completo del XRP Ledger en una única máquina cara es configurar muchos servidores para que cada uno almacene una parte del histórico completo del ledger. La función [Fragmentación del histórico](../../infrastructure/configuration/data-retention/history-sharding.md) hace esto posible, almacenando rangos del histórico del ledger en áreas de almacenamiento separadas llamadas almacenes de fragmentación o _shard store_. Cuando un servidor par solicita datos específicos (como se describe en [fetching history](#recuperar-el-histórico) arriba), un servidor puede responder usando datos de su ledger store o shard store.
Online deletion **no** borra desde un shard store. Sin embargo, si configuras online deletion para mantener al menos 32768 versiones de ledger en el ledger store de tu servidor, tu servidor puede copiar shards completos desde el ledger store al shard store antes de borrarlos automáticamente del ledger store.
Para más información, ver [Configurar History Sharding](../../infrastructure/configuration/data-retention/configure-history-sharding.md).
## Ver también
@@ -76,7 +68,6 @@ Para más información, ver [Configurar History Sharding](../../infrastructure/c
- [Configurar `rippled`](../../infrastructure/configuration/index.md)
- [Configurar Online Deletion](../../infrastructure/configuration/data-retention/configure-online-deletion.md)
- [Configurar Advisory Deletion](../../infrastructure/configuration/data-retention/configure-advisory-deletion.md)
- [Configurar History Sharding](../../infrastructure/configuration/data-retention/configure-history-sharding.md)
- [Configurar Full History](../../infrastructure/configuration/data-retention/configure-full-history.md)
- **Referencias:**
- [método ledger][]

13
@l10n/es-ES/docs/concepts/networks-and-servers/rippled-server-modes.md
View File

@@ -14,7 +14,6 @@ El software del servidor `rippled` puede ejecutarse en varios modos dependiendo
- [**Validador**](#validadores) - Ayuda a asegurar la red participando en el consenso.
- [**Servidor API**](#servidores-api) - Proporciona [acceso API](../../tutorials/http-websocket-apis/build-apps/get-started.md) para leer datos del ledger compartido, enviar transacciones, y mirar la actividad en el ledger. Opcionalmente, puede ser un [**servidor full history**](#servidores-full-history), el cual guarda un registro completo de transacciones y el histórico del ledger.
- [**Servidor hub**](#hubs-públicos) - Transmite mensajes entre muchos otros miembros de la red peer-to-peer.
- [**Modo Reporting**](#modo-reporting) - Un modo especializado para servir consultas API desde una base de datos relacional. No participa en la red peer-to-peer, por lo que necesitas ejecutar un servidor en modo P2P y conectarle el servidor modo reporting usando una conexión gRPC de confianza.
- [**Modo solitario**](#modo-solitario) - Un modo offline para pruebas. No se conecta a la red peer-to-peer ni usa consenso.
Tambien puedes ejecutar el ejecutable `rippled` como una aplicación cliente para acceder [APIs `rippled`](../../references/http-websocket-apis/index.md) localmente. (Dos instancias del mismo binario pueden ejecutarse uno al lado del otro en este caso; uno como un servidor, y el otro ejecutándose brevemente como cliente y luego apagarlo.)
@@ -67,18 +66,6 @@ Puedes habilitar de forma segura la validación en un servidor que también se u
Para más información sobre como ejecutar un validador, ver [Ejecutar `rippled` como un validador](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md).
## Modo reporting
El modo reporting es un modo especializado para servir solicitudes API de manera más eficiente. En este modo, el servidor obtiene los datos del ledger validados más recientes a través de [gRPC](../../infrastructure/configuration/configure-grpc.md) desde un servidor `rippled` separado en Modo P2P, luego carga esos datos en una base de datos relacional ([PostgreSQL](https://www.postgresql.org/)). El servidor en modo reporting no participa directamente en la red peer-to-peer, aunque puede reenviar solicitudes como el envío de transacciones al servidor en Modo P2P que utiliza.
Varios servidores en modo reporting pueden compartir acceso a una base de datos PostgreSQL y a un clúster [Apache Cassandra](https://cassandra.apache.org/) para servir una gran cantidad de historial sin que cada servidor necesite una copia redundante de todos los datos. Los servidores en modo reporting proporcionan estos datos a través de las mismas [`rippled` APIs](../../references/http-websocket-apis/index.md) con algunos cambios leves para adaptarse a las diferencias en cómo almacenan los datos subyacentes.
Especialmente, los servidores en modo reporting no informan sobre datos pendientes de validación del ledger o transacciones no validadas. Esta limitación es relevante para ciertos casos de uso que dependen de un acceso rápido a datos en flujo, como realizar arbitraje en el [exchange descentralizado](../tokens/decentralized-exchange/index.md).
<!-- TODO: link setup steps for Reporting Mode when those are ready -->
## Modo solitario
En el modo solitario, el servidor opera sin conectarse a la red y sin participar en el proceso de consenso. Sin el proceso de consenso, debes avanzar manualmente el ledger y no se hace ninguna distinción entre "cerrado" y "validado" ledgers. Sin embargo, el servidor sigue proporcionando acceso a la API y procesa transacciones de la misma manera. Esto te permite:

2
@l10n/ja/docs/_snippets/common-links.md
View File

@@ -218,11 +218,9 @@
[共通フィールド]: /@l10n/ja/docs/references/protocol/transactions/common-fields.md
[connectメソッド]: /@l10n/ja/docs/references/http-websocket-apis/admin-api-methods/peer-management-methods/connect.md
[consensus_infoメソッド]: /@l10n/ja/docs/references/http-websocket-apis/admin-api-methods/status-and-debugging-methods/consensus_info.md
[crawl_shardsメソッド]: /@l10n/ja/docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/crawl_shards.md
[crypto-condition]: https://tools.ietf.org/html/draft-thomas-crypto-conditions-04
[crypto-conditions]: https://tools.ietf.org/html/draft-thomas-crypto-conditions-04
[deposit_authorizedメソッド]: /@l10n/ja/docs/references/http-websocket-apis/public-api-methods/path-and-order-book-methods/deposit_authorized.md
[download_shardメソッド]: /@l10n/ja/docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/download_shard.md
[featureメソッド]: /@l10n/ja/docs/references/http-websocket-apis/admin-api-methods/status-and-debugging-methods/feature.md
[手数料レベル]: /@l10n/ja/docs/concepts/transactions/transaction-cost.md#手数料レベル
[feeメソッド]: /@l10n/ja/docs/references/http-websocket-apis/public-api-methods/server-info-methods/fee.md

8
@l10n/ja/docs/concepts/networks-and-servers/ledger-history.md
View File

@@ -54,13 +54,6 @@ XRP Ledger財団は、コミュニティメンバーが運営する一連の全
すべての履歴の設定については、[完全な履歴の設定](../../infrastructure/configuration/data-retention/configure-full-history.md)をご覧ください。
## 履歴シャーディング
XRP Ledgerのすべての履歴を1台の高価なマシンに保管する代わりに、複数のサーバがレジャー履歴の一部分を保管するように構成できます。これは[履歴シャーディング](../../infrastructure/configuration/data-retention/history-sharding.md)機能によって実現します。一定範囲のレジャー履歴が _シャードストアー_ という個別の保管領域に保管されます。ピアサーバから（上記の[履歴の取得](#履歴の取得)で説明したとおり）特定のデータがリクエストされると、サーバはレジャーストアーまたはシャードストアーのデータを使用してレスポンスできます。
オンライン削除ではシャードストアーのデータは削除**されません**。ただし、32768個以上のレジャーバージョンをサーバのレジャーストアーに保持するようにオンライン削除が設定されていれば、レジャーストアーからデータが自動的に削除される前に、サーバはレジャーストアーからシャードストアーにすべてのシャードをコピーできます。
詳細は、[履歴シャーディングの設定](../../infrastructure/configuration/data-retention/configure-history-sharding.md)をご覧ください。
## 関連項目
@@ -71,7 +64,6 @@ XRP Ledgerのすべての履歴を1台の高価なマシンに保管する代わ
- [`rippled`の設定](../../infrastructure/configuration/index.md)
- [オンライン削除の設定](../../infrastructure/configuration/data-retention/configure-online-deletion.md)
- [指示による削除の設定](../../infrastructure/configuration/data-retention/configure-advisory-deletion.md)
- [履歴シャーディングの設定](../../infrastructure/configuration/data-retention/configure-history-sharding.md)
- [全履歴の設定](../../infrastructure/configuration/data-retention/configure-full-history.md)
- **リファレンス:**
- [ledgerメソッド][]

5
@l10n/ja/docs/infrastructure/commandline-usage.md
View File

@@ -65,10 +65,9 @@ rippled [OPTIONS]
| `--fg` | デーモンをフォアグラウンドでシングルプロセスとして実行します。このオプションを指定しない場合、`rippled`は1番目のプロセスがモニターとして実行されている間に、デーモンの2番目のプロセスをフォークします。 |
| `--import` | 完全に起動する前に、別の`rippled`サーバのレジャーストアーからレジャーデータをインポートしてください。構成ファイルに有効な`[import_db]`スタンザが指定されている必要があります。 |
| `--net` | **廃止予定** デバッグのためのオプションです。ネットワークからレジャーを取得できるようになるまで、ローカルレジャーを作成しません。 |
| `--nodetoshard` | 完全に起動する前に、すべての完全な[履歴シャード](configuration/data-retention/history-sharding.md)をレジャーストアーからシャードストアーにコピーしてください（シャードストアーに設定されている最大ディスク容量まで）。CPUとI/Oを大量に使用します。注意: このコマンドは、データを（移動するのではなく）コピーするため、シャードストアーとレジャーストアーの両方にデータを保存するのに十分なディスク容量が必要です。 <!--{# Task for writing a tutorial to use this: DOC-1639 #}--> |
| `--quorum {QUORUM}` | これは[テストネットワーク](../concepts/networks-and-servers/parallel-networks.md)のブートストラップ用のオプションです。検証のための最小定数をオーバーライドするには、`{QUORUM}`の信頼できるバリデータの同意を必要とします。デフォルトでは、検証のための定数は、信頼できるバリデータの実際の数に基づき、安全な数に自動的に設定されます。一部のバリデータがオンラインではない場合、このオプションにより、標準定数よりも少ない数のバリデータで続行できるようになります。**警告:** 定数を手動で設定すると、設定した値が小さすぎるためにサーバがネットワークの他の部分から分岐することを防ぐことができない可能性があります。このオプションは、コンセンサスを十分に理解し、標準以外の設定を使用する必要がある場合にのみ使用してください。 |
| `--quorum {QUORUM}` | これは[テストネットワーク](../concepts/networks-and-servers/parallel-networks.md)のブートストラップ用のオプションです。検証のための最小定数をオーバーライドするには、`{QUORUM}`の信頼できるバリデータの同意を必要とします。デフォルトでは、検証のための定数は、信頼できるバリデータの実際の数に基づき、安全な数に自動的に設定されます。一部のバリデータがオンラインではない場合、このオプションにより、標準定数よりも少ない数のバリデータで続行できるようになります。{% admonition type="danger" name="警告" %}定数を手動で設定すると、設定した値が小さすぎるためにサーバがネットワークの他の部分から分岐することを防ぐことができない可能性があります。このオプションは、コンセンサスを十分に理解し、標準以外の設定を使用する必要がある場合にのみ使用してください。{% /admonition %} |
次のフィールドは廃止されました： `--validateShards`。 {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.7.0" %}削除: rippled 1.7.0{% /badge %}
次のフィールドは廃止されました： `--validateShards` {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.7.0" %}削除: rippled 1.7.0{% /badge %}, `--nodetoshard` {% badge href="https://github.com/XRPLF/rippled/releases/tag/2.3.0" %}削除: rippled 2.3.0{% /badge %}。
## スタンドアロンモードのオプション

3
@l10n/ja/docs/infrastructure/configuration/data-retention/configure-full-history.md
View File

@@ -1,6 +1,4 @@
---
html: configure-full-history.html
parent: data-retention.html
seo:
description: 完全履歴サーバは、運用のコストは高いものの、XRP Ledgerでこれまでに発生したすべてのトランザクションの記録を提供します。
labels:
@@ -19,7 +17,6 @@ labels:
ネットワークへの参加、トランザクションの検証、またはネットワークの現在の状態の確認には、全履歴を記録するサーバは必要ありません。全履歴が有用となるのは、過去に発生したトランザクションの結果や、過去の特定の時点におけるレジャーの状態を確認する場合だけです。このような情報を取得するには、必要とする履歴を保持している他のサーバを利用する必要があります。
全履歴は保管せずにXRP Ledgerネットワークの履歴の保管に参加したい場合には、[履歴シャーディングを構成](configure-history-sharding.md)すれば、レジャー履歴のグループをランダムに選択して保管できます。
## 構成手順

82
@l10n/ja/docs/infrastructure/configuration/data-retention/configure-history-sharding.md
View File

@@ -1,82 +0,0 @@
---
html: configure-history-sharding.html
parent: data-retention.html
seo:
description: XRP Ledgerの履歴データのシャードを保存するようにサーバを設定します。
labels:
- データ保持
- コアサーバ
---
# 履歴シャーディングの設定
[履歴シャーディング](history-sharding.md)では、各サーバで完全な履歴を保管することなく、履歴XRP Ledgerデータを保存できます。デフォルトでは`rippled`サーバは履歴シャードを保管しません。
{% admonition type="success" name="ヒント" %}バリデータおよび`rippled`追跡（またはストック）サーバの両方で履歴シャードを保管するように設定できます。ただし`rippled`バリデータサーバの経費を抑えるために、バリデータサーバでシャードを保管するように設定 _しない_ ことが推奨されます。バリデータを実行していて、XRP Ledger履歴を保管したい場合は、履歴シャーディングを有効にして別の`rippled`サーバを実行することが推奨されます。{% /admonition %}
レジャー履歴のシャードを保管できるよう`rippled`を設定するには、以下の手順を実行します。
## 1. シャードストアーに割り当てる容量を決めます。
履歴シャードを保管できるように`rippled`サーバを設定する前に、履歴シャードストアーに割り当てるディスク容量を決定する必要があります。これはまた、デフォルトのレジャーストアーに保持する履歴の量にも影響します。シャードストアーのサイズを設定する際には、以下の点を考慮してください。
- レジャーストアー（`[node_db]`スタンザにより定義される）は、履歴シャードストアーとは別のストアーです。レジャーストアーはすべてのサーバに必要であり、そこには一定範囲の最近の履歴が保管されている必要があります。保管する範囲は、`online_delete`パラメーターに使用可能な状態で維持するレジャーの数によって定義されます。（デフォルトの設定では、最新のレジャー2000個が保管されます。）
- レジャーストアーに2<sup>15</sup>個以上のレジャー（32768）が保持されている場合は、レジャーストアーからシャードストアーへ最近の履歴のグループを効率的にインポートできます。
- 履歴シャードストアー（`[shard_db]`スタンザにより定義される）は、履歴シャードを保管する場合にのみ必要です。履歴シャードを保管しないサーバではこの構成スタンザを省略する必要があります。履歴シャードストアーのサイズは`max_size_gb`パラメーターでギガバイト単位で定義されます。サーバは完全なシャードを保管するため、この容量を最大限利用します。履歴シャードストアーは、 _必ず_ ソリッドステートディスクまたは同様の高速なメディアに保管します。従来の回転式ハードディスクでは不十分です。
- シャードには2<sup>14</sup>個のレジャー（16384）が含まれており、シャードの経過期間に応じて約200MB～4GBを専有します。古いシャードほどXRP Ledgerでのアクティビティが少ないため、サイズが小さくなります。
- 履歴シャードストアーとレジャーストアーはファイルパスを分けて保管する _必要があります_ 。必要に応じて、レジャーストアーと履歴ストアーをそれぞれ別のディスクやパーティションに配置するように設定できます。
- 完全なレジャー履歴をレジャーストアーと履歴シャードストアーの両方に保持できますが、冗長な処理となります。
- シャードの取得にかかる時間、`rippled`サーバに必要なファイルハンドル数、およびメモリーキャッシュ使用率は、シャードのサイズの影響を直接受けます。
## 2. rippled.cfgの編集
`rippled.cfg`ファイルを編集し、`[shard_db]`スタンザを追加します。
{% partial file="/@l10n/ja/docs/_snippets/conf-file-location.md" /%}
以下のスニペットに、`[shard_db]`スタンザの例を示します。
```
[shard_db]
type=NuDB
path=/var/lib/rippled/db/shards/nudb
max_size_gb=50
```
`type`フィールドは省略できます。省略しない場合は、`NuDB`である _必要があります_ 。{% badge href="https://github.com/XRPLF/rippled/releases/tag/1.3.1" %}新規: rippled 1.3.1{% /badge %}
{% admonition type="warning" name="注意" %}`rippled`がシャードストアーパスで不適切なデータを検出すると、[起動できない](../../troubleshooting/server-wont-start.md)可能性があります。シャードストアーには新しいフォルダーを使用する必要があります。以前にRocksDBシャードストアー（`rippled` 1.2.x以前）を使用していた場合は、別のパスを使用するか、RocksDBシャードデータを削除します。{% /admonition %}
詳細は、[rippled.cfgの設定例](https://github.com/XRPLF/rippled/blob/master/cfg/rippled-example.cfg)の`[shard_db]`の例をご覧ください。
## 3. サーバの再起動
```
systemctl restart rippled
```
## 4. シャードのダウンロードの待機
サーバはネットワークと同期すると、履歴シャードのダウンロードを自動的に開始し、シャードストアーの空き容量を埋めます。ダウンロード対象のシャードを確認するには、シャードストアーを設定したフォルダー内に作成されるフォルダーを確認します。（これは`rippled.cfg`ファイルの`[shard_db]`スタンザの`path`フィールドによって定義されます。）
このフォルダーには、サーバに保管されている各シャードのフォルダーが番号付きで保存されています。常に、最大で1つのフォルダーに、未完了であることを示す`control.txt`ファイルが保存されています。
[download_shardメソッド][]を使用して、サーバにアーカイブファイルからシャードをダウンロードしてインポートするように指示できます。
サーバとそのピアが使用できるシャードのリストを表示するには、[crawl_shardsメソッド][]か[ピアクローラー](../../../references/http-websocket-apis/peer-port-methods/peer-crawler.md)を使用します。
## 関連項目
- **コンセプト:**
- [レジャー履歴](../../../concepts/networks-and-servers/ledger-history.md)
- [オンライン削除](online-deletion.md)
- **チュートリアル:**
- [オンライン削除の設定](configure-online-deletion.md)
- [ピアクローラーの設定](../peering/configure-the-peer-crawler.md)
- [容量の計画](../../installation/capacity-planning.md)
- **リファレンス:**
- [download_shardメソッド][]
- [crawl_shardsメソッド][]
- [レジャーデータフォーマット](../../../references/protocol/ledger-data/index.md)
{% raw-partial file="/@l10n/ja/docs/_snippets/common-links.md" /%}

1
@l10n/ja/docs/infrastructure/configuration/data-retention/configure-online-deletion.md
View File

@@ -78,7 +78,6 @@ labels:
- [オンライン削除](online-deletion.md)
- [指示による削除の設定](configure-advisory-deletion.md)
- [履歴シャーディングの設定](configure-history-sharding.md)
- [完全な履歴の設定](configure-full-history.md)
{% raw-partial file="/@l10n/ja/docs/_snippets/common-links.md" /%}

42
@l10n/ja/docs/infrastructure/configuration/data-retention/history-sharding.md
View File

@@ -1,42 +0,0 @@
---
html: history-sharding.html
parent: data-retention.html
seo:
description: 履歴シャーディングは、履歴レジャーデータを保持する任務をrippledサーバ間で分担するようにします。
labels:
- データ保持
- コアサーバ
---
# 履歴シャーディング
{% badge href="https://github.com/XRPLF/rippled/releases/tag/0.90.0" %}導入: rippled 0.90.0{% /badge %}
稼働中のサーバは、ネットワーク実行時に検知または取得したレジャーに関するデータを格納したデータベースを作成します。各`rippled`サーバは、そのレジャーのデータをレジャーストアーに保存しますが、保存されたレジャー数が設定された容量制限を超えると、オンライン削除ロジックによりこれらのデータベースがローテーションされます。
履歴シャーディングは、XRP Ledgerのトランザクション履歴をシャードと呼ばれるセグメントに分割し、XRP Ledgerネットワークのサーバ全体に分散します。シャードは、一連のレジャーです。`rippled`サーバは、レジャーストアーとシャードストアーの両方にレジャーを同じ方法で保存します。
履歴シャーディング機能を使用すると、個々の`rippled`サーバが履歴データの保存する役割を担い、すべての履歴（数テラバイト）を保存する必要がなくなります。シャードストアーはレジャーストアーに代わるものではありませんが、XRP Ledgerネットワーク上の分散レジャー履歴への信頼性の高いパスを実現します。
[![XRP Ledgerネットワーク: レジャーストアーとシャードストアーの図](/docs/img/xrp-ledger-network-ledger-store-and-shard-store.ja.png)](/docs/img/xrp-ledger-network-ledger-store-and-shard-store.ja.png)
<!-- Diagram source: https://docs.google.com/presentation/d/1mg2jZQwgfLCIhOU8Mr5aOiYpIgbIgk3ymBoDb2hh7_s/edit#slide=id.g417450e8da_0_316 -->
## 履歴シャードの取得と共有
`rippled` サーバは履歴シャードを取得して保存します（この動作には設定が必要です）。このようなサーバでは、ネットワークとの同期を実行し、設定された数の最新レジャーへのレジャー履歴の埋め戻しが完了した後で、シャードの取得が開始されます。ネットワークアクティビティがあまり発生しないこの期間に、`shard_db`を維持するように設定されている`rippled`サーバ が、シャードストアーに追加するシャードをランダムに選択します。ネットワークレジャー履歴が均等に分散される確率を高めるため、取得対象のシャードはランダムに選択され、現行シャードが特に優先されることはありません。
シャードが選択されたら、レジャー取得プロセスが開始されます。最初にシャードの最後のレジャーのシーケンスが取得され、最初のシャードに向けて逆方向に処理が進められます。取得プロセスでは最初に、サーバがローカルでデータを確認します。取得できないデータについては、サーバはピア`rippled`サーバにデータをリクエストします。リクエストされた期間のデータを供給できるサーバは、履歴でレスポンスします。リクエスト側サーバはこれらのレスポンスを結合し、シャードを作成します。シャードに特定範囲のレジャーがすべて含まれた状態になれば、シャードが完成します。
`rippled`サーバが1つのシャードを完全に取得する前に容量不足になった場合、空き容量ができて処理を続行できるようになるまで取得プロセスを停止します。この後、古いシャードは完成された最新のシャードに置き換えられます。ディスク容量が十分にある場合は、`rippled`サーバはシャードに割り当てられている最大ディスク容量（`max_size_gb`）に達するまで、ランダムに選択された追加のシャードを取得し、シャードストアーに追加します。
## XRP Ledgerネットワークデータの整合性
すべてのレジャーの履歴は、特定範囲の履歴レジャーを維持することに同意したサーバ間で共有されます。これにより、各サーバは維持することに同意したデータがすべてあることを確認し、プルーフツリーまたはレジャーデルタを作成できるようになります。履歴シャーディングが設定されている`rippled`サーバは、保存するシャードをランダムに選択するため、すべての閉鎖済みレジャーの履歴全体が正規分布曲線で保存され、XRP Ledgerネットワークで履歴が均一に維持される確率が高くなります。
## 関連項目
- [履歴シャーディングの設定](configure-history-sharding.md)
- [download_shardメソッド][]
- [crawl_shardsメソッド][]
{% raw-partial file="/@l10n/ja/docs/_snippets/common-links.md" /%}

369
@l10n/ja/docs/infrastructure/installation/build-run-rippled-in-reporting-mode.md
View File

@@ -1,369 +0,0 @@
---
html: build-run-rippled-in-reporting-mode.html
parent: install-rippled.html
seo:
description: 検証済みデータのリモートプロシージャコール(RPC)を処理するrippledの特別なモードをビルドし、実行します。
labels:
- コアサーバ
- ブロックチェーン
top_nav_grouping: 人気ページ
---
# レポートモードでの`rippled`のビルドと実行
[レポートモード](../../concepts/networks-and-servers/rippled-server-modes.md)は、[HTTPとWebSocket API](../../references/http-websocket-apis/index.md)の提供に特化したXRP Ledgerのコアサーバのモードです。
レポートモードでは、サーバはピアツーピアネットワークに接続しません。その代わりに、gRPCを使用して、P2Pネットワークに接続されている1つまたは複数の信頼できるサーバから有効なデータを取得します。
そしてAPIコールを効率的に処理し、P2Pモードで動作している`rippled`サーバの負荷を軽減することができます。
`rippled`のレポートモードでは2種類のデータストアを使用します。
* トランザクションのメタデータ、アカウントの状態、レジャーのヘッダーを含む`rippled`のプライマリ永続データストア。プライマリ永続データストアとしてNuDB(ソースに付属)または[Cassandra](https://cassandra.apache.org/)を使用できます。Cassandraを使用する場合、複数のレポートモードサーバが単一のCassandraインスタンスまたはクラスター内のデータへのアクセスを共有できます。
* リレーショナルデータを保持する[PostgreSQL](https://www.postgresql.org/)データベース。主に[txメソッド][]と[account_txメソッド][]で使用されます。
レポートモードサーバはAPIリクエストを受信すると、可能であればこれらのデータストアからデータをロードします。P2Pネットワークからのデータが必要なリクエストの場合、レポートモードはリクエストをP2Pサーバに転送し、レスポンスをクライアントに返します。
複数のレポートモードサーバが同じネットワークのアクセス可能なデータベース(PostgreSQLとCassandra)へのアクセスを共有することができます。
## レポートモードの実行方法
### 前提条件
1. お使いのシステムが[システム要件](system-requirements.md)を満たしていることを確認してください。
{% admonition type="info" name="注記" %}データベースとしてCassandraを選択した場合、データがローカルディスクに保存されないため、`rippled`のディスク要件は低くなります。{% /admonition %}
2. 少なくとも1台の`rippled`サーバをP2Pモードで動作させる必要があります。
3. 互換性のあるバージョンのCMakeがインストールされている必要があります。
4. レポートモードで`rippled`を実行するために必要なデータストアをインストールして設定します。
1. PostgreSQLをインストールします。
2. プライマリ永続データストアとして使用するデータベースをインストールして構成します。CassandraまたはNuDBを選択できます。
3. macOSでは、Cassandraのcppライバを手動でインストールする必要があります。その他のプラットフォームでは、Cassandraドライバは`rippled`ビルドの一部としてビルドされます。
```
brew install cassandra-cpp-driver
```
#### PostgreSQLのインストール
**LinuxにPostgreSQLをインストール**
1. LinuxにPostgreSQLをダウンロードし[インストール](https://www.postgresqltutorial.com/install-postgresql-linux/)してください。
2. `psql`を使用してPostgreSQLデータベースサーバに接続し、ユーザ`newuser`とデータベース`reporting`を作成します。
```
psql postgres
CREATE ROLE newuser WITH LOGIN PASSWORD ‘password’;
ALTER ROLE newuser CREATEDB;
\q
psql postgres -U newuser
postgres=# create database reporting;
```
**macOSにPostgreSQLをインストール**
1. macOSにPostgreSQLをダウンロードしてインストールします。
```
brew install postgres
brew services start postgres
```
2. `psql` を使用してPostgreSQLデータベースサーバに接続し、ユーザ`newuser`とデータベース`reporting`を作成します。
```
psql postgres
CREATE ROLE newuser WITH LOGIN PASSWORD ‘password’;
ALTER ROLE newuser CREATEDB;
\q
psql postgres -U newuser
postgres=# create database reporting;
```
#### プライマリ永続データストアのインストールと設定
**Cassandra**
Cassandraをインストールし、レプリケーションを使用して`rippled`用のキースペースを作成します。
レプリケーション係数は3が推奨されますが、ローカルで実行する場合はレプリケーションは不要なので、`replication_factor`を1に設定することができます。
```
$ cqlsh [host] [port]
> CREATE KEYSPACE `rippled` WITH REPLICATION =
{'class' : 'SimpleStrategy', 'replication_factor' : 1 };
```
**NuDB**
ローカルネットワークのレポートモードで`rippled`を実行している場合、バックエンドデータベースとしてCassandraの代わりにNuDBを選択できます。
NuDBは`rippled`ビルドセットアップの一部としてインストールされ、追加のインストール手順は必要ありません。
### 手順
1. [UbuntuまたはmacOS](https://github.com/XRPLF/rippled/blob/release/BUILD.md)のレポートモード用に`rippled`をビルド。
{% tabs %}
```{% label="Linux" %}
wget https://github.com/Kitware/CMake/releases/download/v3.16.3/cmake-3.16.3-Linux-x86_64.sh
sudo sh cmake-3.16.3-Linux-x86_64.sh --prefix=/usr/local --exclude-subdir
cmake -B build -Dreporting=ON -DCMAKE_BUILD_TYPE=Debug
cmake --build build --parallel $(nproc)
```
```{% label="macOS" %}
cmake -B build -G "Unix Makefiles" -Dreporting=ON -DCMAKE_BUILD_TYPE=Debug
cmake --build build --parallel $(nproc)
```
{% /tabs %}
2. レポートモードで`rippled`を実行するための設定ファイルを作成します。
設定ファイル例`rippled-example.cfg`をコピーして、非rootユーザで`rippled`を実行できる場所に`rippled-reporting-mode.cfg`として保存してください。例えば
```
mkdir -p $HOME/.config/ripple
cp <RIPPLED_SOURCE>/cfg/rippled-example.cfg $HOME/.config/ripple/rippled-reporting-mode.cfg
```
3. rippled-reporting-mode.cfgを編集して必要なファイルパスを設定してください。あなたが`rippled`を実行する予定のユーザは、ここで指定したすべてのパスに書き込み権限を持っている必要があります。
1. `[node_db]`のパスには、レジャーデータベースを保存する場所を設定します。
2. `[database_path]`には他のデータベースデータを格納する場所を設定してください。(これには設定データを格納したSQLiteデータベースも含まれ、通常は`[node_db]`パスフィールドの一つ上の階層になります)。
3. `[debug_logfile]`に`rippled`がロギング情報を書き込めるパスを設定します。
これらは`rippled`が正常に起動するために必須の設定だけであることに注意してください。他の設定はすべてオプションであり、サーバが動作するようになってから調整することができます。
4. `rippled-reporting-mode.cfg`ファイルを編集してレポートモードを有効にします：
1. `[reporting]`スタンザのコメントを外すか、新しいスタンザを追加してください：
```
[reporting]
etl_source
read_only=0
```
2. データを抽出する`rippled`ソース(ETLソース)をリストアップします。これらの`rippled`サーバはgRPCが有効になっている必要があります。
注記: レポートモードはP2Pネットワークに接続しないため、データがネットワークのコンセンサスレジャーと実際に一致しているかどうかを検証できないため、信頼できるサーバだけを含めるようにしてください。
```
[etl_source]
source_grpc_port=50051
source_ws_port=6006
source_ip=127.0.0.1
```
5. データベースの設定
1. `[ledger_tx_tables]`にPostgres DBを指定します。
```
[ledger_tx_tables]
conninfo = postgres://newuser:password@127.0.0.1/reporting
use_tx_tables=1
```
2. `[node_db]` にデータベースを指定します。
{% tabs %}
```{% label="NuDB" %}
[node_db]
type=NuDB
path=/home/ubuntu/ripple/
[ledger_history]
1000000
```
```{% label="Cassandra" %}
[node_db]
type=Cassandra
[ledger_history]
1000000
```
{% /tabs %}
6. `rippled`の設定を変更してポートを開放してください。
1. パブリックWebSocketのポートを開きます。
```
[port_ws_admin_local]
port = 6006
ip = 127.0.0.1
admin = 127.0.0.1
protocol = ws
```
2. ポートを開きます。
```
[port_grpc]
port = 60051
ip = 0.0.0.0
```
3. レポートシステムのIPに安全なゲートウェイを追加します。
```
secure_gateway = 127.0.0.1
```
7. レポートモードで`rippled`を実行します。
```
./rippled --conf /home/ubuntu/.config/ripple/rippled-reporting-example.cfg
```
### 予想される結果
ターミナルに表示される内容の抜粋です。
```text
Loading: "/home/ubuntu/.config/ripple/rippled-reporting-example.cfg"
2021-Dec-09 21:31:52.245577 UTC JobQueue:NFO Using 10 threads
2021-Dec-09 21:31:52.255422 UTC LedgerConsensus:NFO Consensus engine started (cookie: 17859050541656985684)
2021-Dec-09 21:31:52.256542 UTC ReportingETL::ETLSource:NFO Using IP to connect to ETL source: 127.0.0.1:50051
2021-Dec-09 21:31:52.257784 UTC ReportingETL::ETLSource:NFO Made stub for remote = { validated_ledger : , ip : 127.0.0.1 , web socket port : 6006, grpc port : 50051 }
2021-Dec-09 21:31:52.258032 UTC ReportingETL::LoadBalancer:NFO add : added etl source - { validated_ledger : , ip : 127.0.0.1 , web socket port : 6006, grpc port : 50051 }
2021-Dec-09 21:31:52.258327 UTC Application:NFO process starting: rippled-1.8.1+DEBUG
2021-Dec-09 21:31:52.719186 UTC PgPool:DBG max_connections: 18446744073709551615, timeout: 600, connection params: port: 5432, hostaddr: 127.0.0.1, user: newuser, password: *, channel_binding: prefer, dbname: reporting_test_core, host: 127.0.0.1, options: , sslmode: prefer, sslcompression: 0, sslsni: 1, ssl_min_protocol_version: TLSv1.2, gssencmode: prefer, krbsrvname: postgres, target_session_attrs: any
2021-Dec-09 21:31:52.788851 UTC PgPool:NFO server message: NOTICE: relation "version" already exists, skipping
2021-Dec-09 21:31:53.282807 UTC TaggedCache:DBG LedgerCache target size set to 384
2021-Dec-09 21:31:53.282892 UTC TaggedCache:DBG LedgerCache target age set to 240000000000
2021-Dec-09 21:31:53.283741 UTC Amendments:DBG Amendment 98DECF327BF79997AEC178323AD51A830E457BFC6D454DAF3E46E5EC42DC619F (CheckCashMakesTrustLine) is supported and will be down voted if not enabled on the ledger.
2021-Dec-09 21:31:53.283836 UTC Amendments:DBG Amendment 157D2D480E006395B76F948E3E07A45A05FE10230D88A7993C71F97AE4B1F2D1 (Checks) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.283917 UTC Amendments:DBG Amendment 1562511F573A19AE9BD103B5D6B9E01B3B46805AEC5D3C4805C902B514399146 (CryptoConditions) is supported and will be down voted if not enabled on the ledger.
2021-Dec-09 21:31:53.283975 UTC Amendments:DBG Amendment 86E83A7D2ECE3AD5FA87AB2195AE015C950469ABF0B72EAACED318F74886AE90 (CryptoConditionsSuite) is supported and will be down voted if not enabled on the ledger.
2021-Dec-09 21:31:53.284016 UTC Amendments:DBG Amendment 30CD365592B8EE40489BA01AE2F7555CAC9C983145871DC82A42A31CF5BAE7D9 (DeletableAccounts) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.284062 UTC Amendments:DBG Amendment F64E1EABBE79D55B3BB82020516CEC2C582A98A6BFE20FBE9BB6A0D233418064 (DepositAuth) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.284099 UTC Amendments:DBG Amendment 3CBC5C4E630A1B82380295CDA84B32B49DD066602E74E39B85EF64137FA65194 (DepositPreauth) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.284126 UTC Amendments:DBG Amendment DC9CA96AEA1DCF83E527D1AFC916EFAF5D27388ECA4060A88817C1238CAEE0BF (EnforceInvariants) is supported and will be down voted if not enabled on the ledger.
2021-Dec-09 21:31:53.284153 UTC Amendments:DBG Amendment 07D43DCE529B15A10827E5E04943B496762F9A88E3268269D69C44BE49E21104 (Escrow) is supported and will be down voted if not enabled on the ledger.
2021-Dec-09 21:31:53.284189 UTC Amendments:DBG Amendment 42426C4D4F1009EE67080A9B7965B44656D7714D104A72F9B4369F97ABF044EE (FeeEscalation) is supported and will be down voted if not enabled on the ledger.
2021-Dec-09 21:31:53.284216 UTC Amendments:DBG Amendment 740352F2412A9909880C23A559FCECEDA3BE2126FED62FC7660D628A06927F11 (Flow) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.284241 UTC Amendments:DBG Amendment 3012E8230864E95A58C60FD61430D7E1B4D3353195F2981DC12B0C7C0950FFAC (FlowCross) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.284284 UTC Amendments:DBG Amendment AF8DF7465C338AE64B1E937D6C8DA138C0D63AD5134A68792BBBE1F63356C422 (FlowSortStrands) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.284337 UTC Amendments:DBG Amendment 1F4AFA8FA1BC8827AD4C0F682C03A8B671DCDF6B5C4DE36D44243A684103EF88 (HardenedValidations) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.284412 UTC Amendments:DBG Amendment 4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373 (MultiSign) is supported and will be down voted if not enabled on the ledger.
2021-Dec-09 21:31:53.284455 UTC Amendments:DBG Amendment 586480873651E106F1D6339B0C4A8945BA705A777F3F4524626FF1FC07EFE41D (MultiSignReserve) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.284491 UTC Amendments:DBG Amendment B4E4F5D2D6FB84DF7399960A732309C9FD530EAE5941838160042833625A6076 (NegativeUNL) is supported and will be down voted if not enabled on the ledger.
2021-Dec-09 21:31:53.284528 UTC Amendments:DBG Amendment 08DE7D96082187F6E6578530258C77FAABABE4C20474BDB82F04B021F1A68647 (PayChan) is supported and will be down voted if not enabled on the ledger.
2021-Dec-09 21:31:53.284592 UTC Amendments:DBG Amendment 00C1FC4A53E60AB02C864641002B3172F38677E29C26C5406685179B37E1EDAC (RequireFullyCanonicalSig) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.284649 UTC Amendments:DBG Amendment CC5ABAE4F3EC92E94A59B1908C2BE82D2228B6485C00AFF8F22DF930D89C194E (SortedDirectories) is supported and will be down voted if not enabled on the ledger.
2021-Dec-09 21:31:53.284703 UTC Amendments:DBG Amendment 532651B4FD58DF8922A49BA101AB3E996E5BFBF95A913B3E392504863E63B164 (TickSize) is supported and will be down voted if not enabled on the ledger.
2021-Dec-09 21:31:53.284787 UTC Amendments:DBG Amendment 955DF3FA5891195A9DAEFA1DDC6BB244B545DDE1BAA84CBB25D5F12A8DA68A0C (TicketBatch) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.284950 UTC Amendments:DBG Amendment 6781F8368C4771B83E8B821D88F580202BCB4228075297B19E4FDC5233F1EFDC (TrustSetAuth) is supported and will be down voted if not enabled on the ledger.
2021-Dec-09 21:31:53.284997 UTC Amendments:DBG Amendment B4D44CC3111ADD964E846FC57760C8B50FFCD5A82C86A72756F6B058DDDF96AD (fix1201) is supported and will be down voted if not enabled on the ledger.
2021-Dec-09 21:31:53.285025 UTC Amendments:DBG Amendment E2E6F2866106419B88C50045ACE96368558C345566AC8F2BDF5A5B5587F0E6FA (fix1368) is supported and will be down voted if not enabled on the ledger.
2021-Dec-09 21:31:53.285067 UTC Amendments:DBG Amendment 42EEA5E28A97824821D4EF97081FE36A54E9593C6E4F20CBAE098C69D2E072DC (fix1373) is supported and will be down voted if not enabled on the ledger.
2021-Dec-09 21:31:53.285103 UTC Amendments:DBG Amendment 6C92211186613F9647A89DFFBAB8F94C99D4C7E956D495270789128569177DA1 (fix1512) is supported and will be down voted if not enabled on the ledger.
2021-Dec-09 21:31:53.285129 UTC Amendments:DBG Amendment 67A34F2CF55BFC0F93AACD5B281413176FEE195269FA6D95219A2DF738671172 (fix1513) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.285153 UTC Amendments:DBG Amendment 5D08145F0A4983F23AFFFF514E83FAD355C5ABFBB6CAB76FB5BC8519FF5F33BE (fix1515) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.285176 UTC Amendments:DBG Amendment B9E739B8296B4A1BB29BE990B17D66E21B62A300A909F25AC55C22D6C72E1F9D (fix1523) is supported and will be down voted if not enabled on the ledger.
2021-Dec-09 21:31:53.285202 UTC Amendments:DBG Amendment 1D3463A5891F9E589C5AE839FFAC4A917CE96197098A1EF22304E1BC5B98A454 (fix1528) is supported and will be down voted if not enabled on the ledger.
2021-Dec-09 21:31:53.285256 UTC Amendments:DBG Amendment CA7C02118BA27599528543DFE77BA6838D1B0F43B447D4D7F53523CE6A0E9AC2 (fix1543) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.285290 UTC Amendments:DBG Amendment 7117E2EC2DBF119CA55181D69819F1999ECEE1A0225A7FD2B9ED47940968479C (fix1571) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.285343 UTC Amendments:DBG Amendment FBD513F1B893AC765B78F250E6FFA6A11B573209D1842ADC787C850696741288 (fix1578) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.285381 UTC Amendments:DBG Amendment 58BE9B5968C4DA7C59BA900961828B113E5490699B21877DEF9A31E9D0FE5D5F (fix1623) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.285424 UTC Amendments:DBG Amendment 25BA44241B3BD880770BFA4DA21C7180576831855368CBEC6A3154FDE4A7676E (fix1781) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.285464 UTC Amendments:DBG Amendment 4F46DF03559967AC60F2EB272FEFE3928A7594A45FF774B87A7E540DB0F8F068 (fixAmendmentMajorityCalc) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.285500 UTC Amendments:DBG Amendment 8F81B066ED20DAECA20DF57187767685EEF3980B228E0667A650BAF24426D3B4 (fixCheckThreading) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.285527 UTC Amendments:DBG Amendment C4483A1896170C66C098DEA5B0E024309C60DC960DE5F01CD7AF986AA3D9AD37 (fixMasterKeyAsRegularKey) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.285550 UTC Amendments:DBG Amendment 621A0B264970359869E3C0363A899909AAB7A887C8B73519E4ECF952D33258A8 (fixPayChanRecipientOwnerDir) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.285575 UTC Amendments:DBG Amendment 89308AF3B8B10B7192C4E613E1D2E4D9BA64B2EE2D5232402AE82A6A7220D953 (fixQualityUpperBound) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.285614 UTC Amendments:DBG Amendment B6B3EEDC0267AB50491FDC450A398AF30DBCD977CECED8BEF2499CAB5DAC19E2 (fixRmSmallIncreasedQOffers) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.285651 UTC Amendments:DBG Amendment 452F5906C46D46F407883344BFDD90E672B672C5E9943DB4891E3A34FEEEB9DB (fixSTAmountCanonicalize) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.285725 UTC Amendments:DBG Amendment 2CD5286D8D687E98B41102BDD797198E81EA41DF7BD104E6561FEB104EFF2561 (fixTakerDryOfferRemoval) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.290446 UTC Server:NFO Opened 'port_rpc_admin_local' (ip=127.0.0.1:7005, admin IPs:127.0.0.1, http)
2021-Dec-09 21:31:53.290834 UTC Server:NFO Opened 'port_ws_admin_local' (ip=127.0.0.1:7006, admin IPs:127.0.0.1, ws)
2021-Dec-09 21:31:53.290984 UTC Application:WRN Running in standalone mode
2021-Dec-09 21:31:53.291048 UTC NetworkOPs:NFO STATE->full
2021-Dec-09 21:31:53.291192 UTC Application:FTL Startup RPC:
{
"command" : "log_level",
"severity" : "debug"
}
2021-Dec-09 21:31:53.291347 UTC RPCHandler:DBG RPC call log_level completed in 2.2e-08seconds
2021-Dec-09 21:31:53.291440 UTC Application:FTL Result:
{
"warnings" :
[
{
"id" : 1004,
"message" : "This is a reporting server. The default behavior of a reporting server is to only return validated data. If you are looking for not yet validated data, include \"ledger_index : current\" in your request, which will cause this server to forward the request to a p2p node. If the forward is successful the response will include \"forwarded\" : \"true\""
}
]
}
2021-Dec-09 21:31:53.291502 UTC ReportingETL:NFO Starting reporting etl
2021-Dec-09 21:31:53.291605 UTC Application:NFO Application starting. Version is 1.8.1+DEBUG
2021-Dec-09 21:31:53.291747 UTC LoadManager:DBG Starting
2021-Dec-09 21:31:53.291846 UTC gRPC Server:NFO Starting gRPC server at 0.0.0.0:60051
2021-Dec-09 21:31:53.293246 UTC LedgerCleaner:DBG Started
2021-Dec-09 21:31:53.295543 UTC ReportingETL::ETLSource:DBG handleMessage : Received a message on ledger subscription stream. Message : {
"result" : {},
"status" : "success",
"type" : "response"
}
- { validated_ledger : , ip : 127.0.0.1 , web socket port : 6006, grpc port : 50051 }
2021-Dec-09 21:31:53.368075 UTC ReportingETL:NFO monitor : Database is empty. Will download a ledger from the network.
2021-Dec-09 21:31:53.368183 UTC ReportingETL:NFO monitor : Waiting for next ledger to be validated by network...
```
## よくある質問
**レポートモードを使用するには、`rippled`インスタンスを実行する必要がありますか？**
はい。レポートモードで動作している`rippled`サーバはピアツーピアネットワークに接続せず、ネットワークに接続されている一つ以上の`rippled`サーバから有効なデータを抽出します。そのため、少なくとも一つのP2Pモードサーバを動作させる必要があります。
**すでに`rippled`をインストールしています。設定ファイルを更新して`rippled`を再起動しレポートモードを有効にすることはできますか？**
現在のところ、レポートモードではソースをダウンロードして`rippled`をビルドする必要があります。レポートモード用のパッケージを提供するための作業が進められています。
**レポートモードで`rippled`を実行するには、P2Pモードで動作している`rippled`サーバが少なくとも1つ必要です。これはディスク容量が2倍必要ということですか？**
答えは、プライマリデータストアの場所に依存します。プライマリデータストアにCassandraを使用する場合、レポートモードサーバがローカル・ディスクに保存するデータはかなり少なくなります。PostgreSQLサーバはリモートでもかまいません。複数のレポートモードサーバで同じデータを共有できます。
最後に、P2Pモードサーバはごく最近の履歴しか保持する必要がありませんが、レポートモードサーバは長期間の履歴を保持します。
`rippled`を実行するためのシステム要件については、[`rippled`のシステム要件](system-requirements.md)をご覧ください。
**PostgreSQLまたはCassandraデータベースから送られてくるデータの信頼性を確認するにはどうすればよいですか。**
レポートモードで`rippled`を実行すると、設定ファイルで指定されたETLソースからの有効なデータのみを提供します。P2Pモードで他人の`rippled`サーバをETLソースとして使用している場合、そのサーバを暗黙的に信頼することになります。そうでない場合は、自分の`rippled`ノードをP2Pモードで実行する必要があります。
**APIを使用するのではなく、リレーショナルデータベースに対して従来のSQLクエリを実行することは可能ですか？**
技術的には、データベースに直接アクセスすることも*可能*です。しかし、データはバイナリーBlobとして保存されており、その中のデータにアクセスするにはBlobをデコードしなければなりません。このため、従来のSQLクエリは、データの個々のフィールドを検索したりフィルタリングしたりすることができず、あまり役に立ちません。
{% raw-partial file="/@l10n/ja/docs/_snippets/common-links.md" /%}

2
@l10n/ja/docs/infrastructure/installation/capacity-planning.md
View File

@@ -165,8 +165,6 @@ XRP Ledgerネットワークの各サーバは、ネットワークのすべて
一般的なルールとして、実行されていない`rippled`サーバのデータベースファイル（レジャーストアとデータベースの両方）を安全に削除することができます。これにより、サーバに保存されているレジャーの履歴はすべて消去されますが、そのデータをネットワークから再取得することができます。ただし、`[database_path]`にある`wallet.db`ファイルを削除すると、[Amendment 投票](../configuration/configure-amendment-voting.md)や[ピアリザベーション](../configuration/peering/use-a-peer-reservation.md)などのランタイムの設定変更を手動で再適用しなければなりません。
レジャー履歴を格納したくても、全履歴を格納するための十分な容量がない場合には、[履歴シャーディング](../configuration/data-retention/history-sharding.md)機能を使用して個別の共有ストアにランダムな範囲のレジャーを格納できます。履歴シャーディングは、`[shard_db]`節で構成されます。
##### Amazon Web Services

2
@l10n/ja/docs/infrastructure/troubleshooting/fix-sqlite-tx-db-page-size-issue.md
View File

@@ -16,7 +16,7 @@ seo:
SQLiteデータベースの容量は、データベースの _ページサイズ_ パラメーターによって決まります。この容量は、データベース作成後は容易に変更できません。（SQLiteの内部についての詳細は、[SQLite公式ドキュメント](https://www.sqlite.org/fileformat.html)をご覧ください。）データベースが保管されているディスクとファイルシステムに空き容量がある場合でも、データベースが容量いっぱいになることがあります。以下の「[解決策](#解決策)」で説明するように、この問題を回避するためにページサイズを再構成するには、時間のかかる移行プロセスが必要です。
{% admonition type="success" name="ヒント" %}ほとんどの場合、`rippled`サーバの稼働に全履歴が必要となることはありません。サーバにトランザクションの全履歴が記録されていれば、長期分析やアーカイブ、または災害に対する事前対策に役立ちます。リソースを大量に消費せずにトランザクション履歴を保管する方法については、[履歴シャーディング](../configuration/data-retention/history-sharding.md)をご覧ください。{% /admonition %}
{% admonition type="success" name="ヒント" %}ほとんどの場合、`rippled`サーバの稼働に全履歴が必要となることはありません。サーバにトランザクションの全履歴が記録されていれば、長期分析やアーカイブ、または災害に対する事前対策に役立ちます。{% /admonition %}
## 検出

26
@l10n/ja/docs/infrastructure/troubleshooting/server-wont-start.md
View File

@@ -186,32 +186,6 @@ Terminating thread rippled: main: unhandled N5beast14BadLexicalCastE 'std::bad_c
`node_size`フィールドの有効なパラメーターは`tiny`、`small`、`medium`、`large`、`huge`です。詳細は、[ノードサイズ](../installation/capacity-planning.md#ノードサイズ)をご覧ください。
## シャードパスが欠落している
以下のようなエラーが出力される場合は、`rippled.cfg`の[履歴シャーディング](../configuration/data-retention/history-sharding.md)の設定が不完全です。
```text
Terminating thread rippled: main: unhandled St13runtime_error 'shard path missing'
```
設定に`[shard_db]`スタンザが含まれている場合、このスタンザには`path`フィールドが指定されている必要があります。このフィールドは、`rippled`がシャードストアーのデータを書き込むことができるディレクトリを指しています。このエラーが発生する場合は、`path`フィールドが欠落しているか、誤った位置に指定されています。構成ファイルで余分な空白やスペルミスがないかどうかを確認し、[シャード設定の例](../configuration/data-retention/configure-history-sharding.md#2-rippledcfgの編集)と比較してください。
## サポート対象外のシャードストアータイプ: RocksDB
RocksDBは、[履歴シャーディング](../configuration/data-retention/history-sharding.md)のバックエンドとしてサポートされなくなりました。RocksDBシャードストアーを定義している既存の構成がある場合は、サーバが起動に失敗します。{% badge href="https://github.com/XRPLF/rippled/releases/tag/1.3.1" %}新規: rippled 1.3.1{% /badge %}
この場合、log startupコマンドの直後にプロセスが終了し、出力ログの早い段階で次のようなメッセージが表示されます。
```text
ShardStore:ERR Unsupported shard store type: RocksDB
```
この問題を修正するには、以下のいずれかを行ってからサーバを再起動します。
- 代わりにNuDBを使用するようにシャードストアーを変更します。
- 履歴シャーディングを無効にします。
## 関連項目

43
@l10n/ja/docs/infrastructure/troubleshooting/understanding-log-messages.md
View File

@@ -72,7 +72,7 @@ Terminating thread rippled: main: unhandled St13runtime_error
InboundLedger:WRN 11 timeouts for ledger 8265938
```
これは、サーバがそのピアに対して特定のレジャーデータをリクエストする際に問題が発生していることを示しています。[レジャーインデックス](../../references/protocol/data-types/basic-data-types.md#レジャーインデックス)が、[server_infoメソッド][]により報告される最新の検証済みレジャーのインデックスよりもかなり小さい場合は、サーバが[履歴シャード](../configuration/data-retention/history-sharding.md)のダウンロード中である可能性があります。
これは、サーバがそのピアに対して特定のレジャーデータをリクエストする際に問題が発生していることを示しています。
これは厳密には問題ではありませんが、レジャー履歴を迅速に取得したい場合は、`[ips_fixed]`構成スタンザを追加または編集してからサーバを再起動することで、すべての履歴が記録されたピアに接続するように`rippled`を構成できます。たとえば、すべての履歴が記録されたRippleのサーバに常に接続するには、以下のようにします。
@@ -90,7 +90,7 @@ s2.ripple.com 51235
InboundLedger:WRN Want: 5AE53B5E39E6388DBACD0959E5F5A0FCAF0E0DCBA45D9AB15120E8CDD21E019B
```
これは、サーバの同期中、埋め戻し中、[履歴シャード](../configuration/data-retention/history-sharding.md)のダウンロード中は正常です。
これは、サーバの同期中、埋め戻し中は正常です。
## LoadMonitor:WRN Job
@@ -116,29 +116,15 @@ InboundLedger:WRN Want: 5AE53B5E39E6388DBACD0959E5F5A0FCAF0E0DCBA45D9AB15120E8CD
サーバの起動後5分以上にわたってこれらのメッセージが継続する場合、特に`run`時間が1000msを大きく上回る場合は、**サーバに十分なリソース（ディスクI/O、RAM、CPUなど）がない**可能性があります。この原因として、使用しているハードウェアの性能が不十分であること、または同じハードウェアで実行されている他のプロセスがリソースをめぐって`rippled`と競合していることが考えられます。（`rippled`とリソースをめぐって競合する可能性のある他のプロセスの例としては、スケジュール済みバックアップ、ウィルススキャナー、定期的なデータベースクリーナーなどがあります。）
考えられるもう1つの原因として、回転型ハードディスクでNuDBの使用を試みていることが挙げられます。NuDBはソリッドステートドライブ（SSD）でのみ使用してください。`rippled`のデータベースには常にSSDストレージの使用が推奨されますが、RocksDBを使用する回転型ディスクで`rippled`を正常に稼働できる _可能性があります_ 。回転型ディスクを使用している場合は、`[node_db]`と`[shard_db]`（使用している場合）の両方がRocksDBを使用するように設定されていることを確認してください。例:
考えられるもう1つの原因として、回転型ハードディスクでNuDBの使用を試みていることが挙げられます。NuDBはソリッドステートドライブ（SSD）でのみ使用してください。`rippled`のデータベースには常にSSDストレージの使用が推奨されますが、RocksDBを使用する回転型ディスクで`rippled`を正常に稼働できる _可能性があります_ 。回転型ディスクを使用している場合は、`[node_db]`がRocksDBを使用するように設定されていることを確認してください。例:
```
[node_db]
type=RocksDB
# ... more config omitted
[shard_db]
type=RocksDB
```
## No hash for fetch pack
以下のようなメッセージは、[履歴シャーディング](../configuration/data-retention/history-sharding.md)のために履歴レジャーをダウンロードする際に、`rippled` v1.1.0以前のバグが原因で発生します。
```text
2018-Aug-28 22:56:21.397076850 LedgerMaster:ERR No hash for fetch pack. Missing Index 7159808
```
これらは安全に無視できます。
## Potential Censorship
XRP Ledgerが取引検閲の可能性を検出すると、以下のようなログメッセージが出力されます。ログメッセージと取引検閲検出機能の詳細は、[取引検閲の検知](../../concepts/networks-and-servers/transaction-censorship-detection.md)をご覧ください。
@@ -156,29 +142,6 @@ LedgerConsensus:ERR Potential Censorship: Eligible tx E08D6E9754025BA2534A787076
```
## シャード: No such file or directory
`rippled` 1.3.1のバグが原因で、[履歴シャーディング](../configuration/data-retention/history-sharding.md)を有効にしたときに次のようなログメッセージが書き込まれることがあります。
```text
ShardStore:ERR shard 1804: No such file or directory
ShardStore:ERR shard 354: No such file or directory
ShardStore:ERR shard 408: No such file or directory
ShardStore:ERR shard 2927: No such file or directory
ShardStore:ERR shard 2731: No such file or directory
ShardStore:ERR shard 2236: No such file or directory
```
これは、サーバが新しい履歴シャードの取得を開始しようとしたものの、シャードを格納するための新しいディレクトリーを作成できなかったことを示します。このバグにより、rippled 1.3.1は新しいシャードを取得できません。[修正は近日リリース予定](https://github.com/XRPLF/rippled/pull/3014)です。
このエラーは、上記のバグのほかに、`rippled`が**起動後**に基となるファイルシステムに書き込めなくなった場合にも起こります。考えられる原因は次のとおりです。
- ストレージメディアのハードウェア障害
- ファイルシステムがアンマウントされた
- シャードフォルダーが削除された
{% admonition type="success" name="ヒント" %}一般的に、サービスが停止している場合は、`rippled`のデータベースファイルを削除しても安全ですが、サーバの稼働中には決してデータベースファイルを削除しないでください。{% /admonition %}
## Unable to determine hash of ancestor

1
@l10n/ja/docs/references/http-websocket-apis/admin-api-methods/index.md
View File

@@ -26,7 +26,6 @@ labels:
ログレベルとその他のデータ（レジャーなど）の管理には、以下のメソッドを使用します。
* **[`can_delete`](logging-and-data-management-methods/can_delete.md)** - 特定レジャーまでのレジャーのオンライン削除を許可します。
* **[`download_shard`](logging-and-data-management-methods/download_shard.md)** - レジャー履歴の特定のシャードをダウンロードします。
* **[`ledger_cleaner`](logging-and-data-management-methods/ledger_cleaner.md)** - レジャークリーナーサービスが破損データを確認するように設定します。
* **[`ledger_request`](logging-and-data-management-methods/ledger_request.md)** - ピアサーバに対し特定のレジャーバージョンを照会します。
* **[`log_level`](logging-and-data-management-methods/log_level.md)** - ログの詳細レベルを取得または変更します。

140
@l10n/ja/docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/crawl_shards.md
View File

@@ -1,140 +0,0 @@
---
html: crawl_shards.html
parent: logging-and-data-management-methods.html
seo:
description: ピアが持つ履歴シャードについての情報をリクエストします。
labels:
- データ保持
---
# crawl_shards
[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/ripple/rpc/handlers/CrawlShards.cpp "Source")
使用可能な[履歴レジャーデータのシャード](../../../../infrastructure/configuration/data-retention/history-sharding.md)に関するピアサーバからの情報をリクエストします。{% badge href="https://github.com/XRPLF/rippled/releases/tag/1.2.0" %}新規: rippled 1.2.0{% /badge %}
_`crawl_shards`メソッドは、権限のないユーザは実行できない[管理メソッド](../index.md)です。_
### リクエストのフォーマット
リクエストのフォーマットの例:
{% tabs %}
{% tab label="WebSocket" %}
```json
{
"command": "crawl_shards",
"pubkey": true,
"limit": 0
}
```
{% /tab %}
{% tab label="JSON-RPC" %}
```json
{
"method": "crawl_shards",
"params": [
{
"pubkey": true,
"limit": 0
}
]
}
```
{% /tab %}
{% /tabs %}
{% admonition type="info" name="注記" %}このメソッドのコマンドライン構文はありません。コマンドラインからアクセスするには[jsonメソッド][]を使用してください。{% /admonition %}
リクエストには以下のフィールドが含まれます。
| `Field` | 型 | 説明 |
|:---------|:--------|:--------------------------------------------------------|
| `pubkey` | ブール値 | _（省略可）_ `true`の場合、レスポンスには、クロールされたサーバのノード公開鍵（ピアツーピア通信用）が含まれます。デフォルトは`false`です。 |
| `limit` | 数値 | _（省略可）_ 検索の深さを示すホップ数。デフォルトは0で、ダイレクトピアのみを検索します。`1`を制限値にすると、ピアのピアも検索します。最大値は`3`です。 |
{% admonition type="warning" name="注意" %}`limit`が増加すると、検索される可能性のあるピアの数は、指数関数的に増加します。2または3を制限値にすると、サーバがAPIリクエストにレスポンスするのに数秒かかる場合があります。{% /admonition %}
### レスポンスのフォーマット
処理が成功したレスポンスの例:
{% tabs %}
{% tab label="WebSocket" %}
```json
{
"result": {
"complete_shards": "1-2,5,8-9,584,1973,2358",
"peers": [
{
"complete_shards": "1-2,8,47,371,464,554,653,857,1076,1402,1555,1708,1813,1867",
"public_key": "n9LxFZiySnfDSvfh23N94UxsFkCjWyrchTeKHcYE6tJJQL5iejb2"
},
{
"complete_shards": "8-9,584",
"ip": "192.168.1.132",
"public_key": "n9MN5xwYqbrj64rtfZAXQy7Y3sNxXZJeLt7Lj61a9DYEZ4SE2tQQ"
}
]
},
"status": "success",
"type": "response"
}
```
{% /tab %}
{% tab label="JSON-RPC" %}
```json
200 OK
{
"result": {
"complete_shards": "1-2,5,8-9,584,1973,2358",
"peers": [
{
"complete_shards": "1-2,8,47,371,464,554,653,857,1076,1402,1555,1708,1813,1867",
"public_key": "n9LxFZiySnfDSvfh23N94UxsFkCjWyrchTeKHcYE6tJJQL5iejb2"
},
{
"complete_shards": "8-9,584",
"ip": "192.168.1.132",
"public_key": "n9MN5xwYqbrj64rtfZAXQy7Y3sNxXZJeLt7Lj61a9DYEZ4SE2tQQ"
}
],
"status": "success"
}
}
```
{% /tab %}
{% /tabs %}
このレスポンスは[標準フォーマット][]に従っており、正常に完了した場合は結果に次のフィールドが含まれます。
| `Field` | 型 | 説明 |
|:------------------|:-------|:------------------------------------------------|
| `complete_shards` | 文字列 | _（省略可）_ ローカルサーバで利用可能な[履歴シャード](../../../../infrastructure/configuration/data-retention/history-sharding.md)の範囲。これは、空の文字列か、または連続していない範囲である場合があります。たとえば、`1-2,5,7-9`は、シャード1、2、5、7、8、9が利用可能であることを示します。このサーバで履歴シャーディングが有効になっていない場合は省略されます。 |
| `peers` | 配列 | 各ピアが使用可能な履歴シャードを表す**ピアシャードオブジェクト**のリスト（以下を参照）。 |
#### ピアシャードオブジェクト
レスポンスの`peers`配列のメンバーはそれぞれ、ピアツーピアネットワーク内の1つのサーバを表すオブジェクトです。リストには、少なくとも1つの完全な[履歴シャード](../../../../infrastructure/configuration/data-retention/history-sharding.md)が使用可能なピアのみが含まれます。配列の各オブジェクトには以下のフィールドが含まれます。
| `Field` | 型 | 説明 |
|:----------|:-------|:--------------------------------------------------------|
| `complete_shards` | 文字列 | このピアが使用可能な履歴シャードの範囲。連続していない場合があります。たとえば、`1-2,5,7-9`は、シャード1、2、5、7、8、9が利用可能であることを示します。 |
| `ip` | 文字列 | _（省略される場合があります）_ このオブジェクトが表すピアのIPアドレス。IPv4アドレスまたはIPv6アドレスを指定できます。[プライベートピア](../../../../concepts/networks-and-servers/peer-protocol.md#プライベートピア)の場合は省略されます。 |
| `public_key` | 文字列 | _(リクエストで`"pubkey": true`が指定されている場合を除き省略)_ XRP Ledgerの[base58フォーマット](../../../protocol/data-types/base58-encodings.md)で、このピアでピアツーピア通信に使用される公開鍵。 |
### 考えられるエラー
- いずれかの[汎用エラータイプ][]。
- `invalidParams` - リクエストで1つ以上の必須フィールドが省略されていたか、または指定されたフィールドのデータタイプが誤っています。
{% raw-partial file="/@l10n/ja/docs/_snippets/common-links.md" /%}

122
@l10n/ja/docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/download_shard.md
View File

@@ -1,122 +0,0 @@
---
html: download_shard.html
parent: logging-and-data-management-methods.html
seo:
description: レジャー履歴の特定のシャードをダウンロードします。
labels:
- データ保持
---
# download_shard
[[ソース]](https://github.com/XRPLF/rippled/blob/master/src/ripple/rpc/handlers/DownloadShard.cpp "Source")
サーバに対し、外部ソースから特定の[履歴レジャーデータのシャード](../../../../infrastructure/configuration/data-retention/history-sharding.md)をダウンロードするように指示します。`rippled`サーバで[履歴シャードが保管されるように設定する](../../../../infrastructure/configuration/data-retention/configure-history-sharding.md)必要があります。{% badge href="https://github.com/XRPLF/rippled/releases/tag/1.1.0" %}新規: rippled 1.1.0{% /badge %}
_`download_shard`メソッドは、権限のないユーザは実行できない[管理メソッド](../index.md)です。_
外部ソースからHTTPSを使用してシャードが[lz4圧縮](https://lz4.github.io/lz4/) [tarアーカイブ](https://en.wikipedia.org/wiki/Tar_(computing))として提供される必要があります。アーカイブには、NuDB形式のシャードディレクトリとデータファイルが含まれている必要があります。
通常、このメソッドを使用してシャードをダウンロードしてインポートすれば、ピアツーピアネットワークからシャードを個別に取得するよりも短い時間で取得できます。また、サーバから提供される特定範囲のシャードまたはシャードのセットを選択する場合にもこのメソッドを使用できます。
### リクエストのフォーマット
リクエストのフォーマットの例:
{% tabs %}
{% tab label="WebSocket" %}
```json
{
"command": "download_shard",
"shards": [
{"index": 1, "url": "https://example.com/1.tar.lz4"},
{"index": 2, "url": "https://example.com/2.tar.lz4"},
{"index": 5, "url": "https://example.com/5.tar.lz4"}
]
}
```
{% /tab %}
{% tab label="JSON-RPC" %}
```json
{
"method": "download_shard",
"params": [
{
"shards": [
{"index": 1, "url": "https://example.com/1.tar.lz4"},
{"index": 2, "url": "https://example.com/2.tar.lz4"},
{"index": 5, "url": "https://example.com/5.tar.lz4"}
]
}
]
}
```
{% /tab %}
{% /tabs %}
リクエストには以下のフィールドが含まれます。
| `Field` | 型 | 説明 |
|:-----------|:--------|:------------------------------------------------------|
| `shards` | 配列 | ダウンロードするシャードとダウンロード元を記述したShard Descriptorオブジェクト（以下の説明を参照）のリスト。 |
`validate`のフィールドは廃止予定であり、今後予告なしに削除される可能性があります。`rippled`は全てのシャードの検証を実行します。{% badge href="https://github.com/XRPLF/rippled/releases/tag/1.6.0" %}更新: rippled 1.6.0{% /badge %}
`shards`配列の各**Shard Descriptorオブジェクト**には以下のフィールドが含まれています。
| `Field` | 型 | 説明 |
|:--------|:-------|:----------------------------------------------------------|
| `index` | 数値 | 取得するシャードのインデックス。本番環境のXRP Ledgerでは、最も古いシャードのインデックスは1であり、このシャードにはレジャー32750～32768が含まれています。次のシャードのインデックスは2であり、このシャードにはレジャー32769～49152が含まれています。 |
| `url` | 文字列 | このシャードをダウンロードできるURL。このURLは`https://`か`http://`かで始まり`.tar.lz4`（大文字小文字の区別なし）で終わる必要があります。このダウンロードを提供するWebサーバは、信頼できる認証局（CA）によって署名された有効なTLS証明書を使用する必要があります。（`rippled`はオペレーティングシステムのCAストアーを使用します。） {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.7.0" %}更新: rippled 1.7.0{% /badge %} |
### レスポンスのフォーマット
処理が成功したレスポンスの例:
{% tabs %}
{% tab label="WebSocket" %}
```json
{
"result": {
"message": "downloading shards 1-2,5"
},
"status": "success",
"type": "response"
}
```
{% /tab %}
{% tab label="JSON-RPC" %}
```json
200 OK
{
"result": {
"message": "downloading shards 1-2,5",
"status": "success"
}
}
```
{% /tab %}
{% /tabs %}
このレスポンスは[標準フォーマット][]に従っており、正常に完了した場合は結果に次のフィールドが含まれます。
| `Field` | 型 | 説明 |
|:----------|:-------|:--------------------------------------------------------|
| `message` | 文字列 | このリクエストに対応して実行されたアクションを説明するメッセージ。 |
{% admonition type="success" name="ヒント" %}サーバで使用可能なシャードを確認するには、[crawl_shardsメソッド][]を使用します。または、シャードストアーとして設定されたロケーションのサブフォルダー（`rippled.cfg`の`[shard_db]`の`path`パラメーター）を調べます。フォルダーには、シャードの番号に対応する名前が付いています。これらのフォルダーの1つに、シャードが未完了であることを示す`control.txt`ファイルが含まれていることがあります。{% /admonition %}
### 考えられるエラー
- いずれかの[汎用エラータイプ][]。
- `notEnabled` - サーバでシャードストアーを使用するように設定されていません。
- `tooBusy` - サーバはすでに、ピアツーピアネットワークから、または以前の`download_shard`リクエストの結果として、シャードをダウンロード中です。
- `invalidParams` - リクエストで1つ以上の必須フィールドが省略されていたか、または指定されたフィールドのデータタイプが誤っています。
{% raw-partial file="/@l10n/ja/docs/_snippets/common-links.md" /%}

120
@l10n/ja/docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/node_to_shard.md
View File

@@ -1,120 +0,0 @@
---
html: node_to_shard.html
parent: logging-and-data-management-methods.html
seo:
description: レジャーストアからシャードストアにデータをコピーします。
labels:
- データ保持
---
# node_to_shard
[[ソース]](https://github.com/XRPLF/rippled/blob/develop/src/ripple/rpc/handlers/NodeToShard.cpp "Source")
{% code-page-name /%}メソッドは、レジャーストアから[シャードストア](../../../../infrastructure/configuration/data-retention/history-sharding.md)へのデータコピーを管理します。データコピーの開始、停止、状態チェックが可能です。
_{% code-page-name /%}メソッドは、権限のないユーザには実行できない[管理メソッド](../index.md)です。_
### リクエストのフォーマット
リクエストのフォーマット例:
{% tabs %}
{% tab label="WebSocket" %}
```json
{
"command": "{% $frontmatter.seo.title %}",
"action": "start"
}
```
{% /tab %}
{% tab label="JSON-RPC" %}
```json
{
"method": "{% $frontmatter.seo.title %}",
"params": [{
"action": "start"
}]
}
```
{% /tab %}
{% tab label="Commandline" %}
```sh
#Syntax: {% $frontmatter.seo.title %} start|stop|status
rippled {% $frontmatter.seo.title %} start
```
{% /tab %}
{% /tabs %}
リクエストは、以下のパラメータを含みます:
| `項目` | 型 | 説明
|:---------|:-------|:---------------------------------------------------------|
| `action` | String | どのような動作をさせるかによって、 `start`、`stop` または `status` のいずれかを指定します。 |
### レスポンスのフォーマット
正常レスポンス例:
{% tabs %}
{% tab label="WebSocket" %}
```json
{
"result": {
"message": "Database import initiated..."
},
"status": "success",
"type": "response"
}
```
{% /tab %}
{% tab label="JSON-RPC" %}
```json
{
"result" : {
"message" : "Database import initiated...",
"status" : "success"
}
}
```
{% /tab %}
{% tab label="Commandline" %}
```json
Loading: "/etc/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result" : {
"message" : "Database import initiated...",
"status" : "success"
}
}
```
{% /tab %}
{% /tabs %}
レスポンスは、[標準フォーマット][]に従っており、成功した場合は、以下の項目を含みます:
| `項目` | 型 | 説明 |
|:----------|:-------|:--------------------------------------------------------|
| `message` | 文字列 | コマンドにレスポンスして実行されたアクションを示す、可読性の高いメッセージ。 |
### 起こり得るエラー
- いずれかの[汎用エラータイプ][]。
- `internal` - コピーが実行されていない時にコピーの状態チェックをするといったような無効な操作の場合。
- `notEnabled` - サーバが[履歴シャード](../../../../infrastructure/configuration/data-retention/history-sharding.md)を保存するように環境設定されていない場合。
- `invalidParams` - 1つ以上の項目が誤って定義されている、もしくは、1つ以上の必須項目が抜けている。
{% raw-partial file="/@l10n/ja/docs/_snippets/common-links.md" /%}

1
@l10n/ja/docs/references/http-websocket-apis/admin-api-methods/status-and-debugging-methods/feature.md
View File

@@ -197,6 +197,5 @@ Connecting to 127.0.0.1:5005
* [汎用エラータイプ][]のすべて。
* `badFeature` - 指定されている`feature`のフォーマットが正しくないか、サーバがその名前のAmendmentを認識していません。
- `reportingUnsupported` - ([レポートモード][]サーバのみ) このメソッドはレポートモードでは使用できません。
{% raw-partial file="/@l10n/ja/docs/_snippets/common-links.md" /%}

1
@l10n/ja/docs/references/http-websocket-apis/peer-port-methods/peer-crawler.md
View File

@@ -44,7 +44,6 @@ JSONオブジェクトは次のフィールドを含んでいます。
| `Field` | 値 | 説明 |
|:-------------------|:-----------------------|:-----------------------------------|
| `complete_ledgers` | 文字列 | このピアで利用可能な[レジャーバージョン](../../../concepts/networks-and-servers/ledger-history.md)の範囲。 |
| `complete_shards` | 文字列 | _(省略可)_ このピアが利用可能な[レジャー履歴シャード](../../../infrastructure/configuration/data-retention/history-sharding.md)の範囲。 |
| `ip` | 文字列 (IPv4アドレス) | _(省略可)_この接続ピアの IPアドレス。ピアがバリデータまたは[プライベートピア](../../../concepts/networks-and-servers/peer-protocol.md#プライベートピア)として設定されている場合は省略されます。{% badge href="https://github.com/XRPLF/rippled/releases/tag/1.2.1" %}更新: rippled 1.2.1{% /badge %}. |
| `port` | 文字列 (数値) | _(省略可)_ RTXPを提供するピアサーバのポート番号。通常は`51235`。ピアがバリデータまたは[プライベートピア](../../../concepts/networks-and-servers/peer-protocol.md#プライベートピア)として設定されている場合は省略されます。{% badge href="https://github.com/XRPLF/rippled/releases/tag/1.2.1" %}更新: rippled 1.2.1{% /badge %}. |
| `public_key` | 文字列 (Base64エンコード) | このピアがRTXPメッセージに署名するために使用するECDSA鍵ペアの公開鍵。(これはピアサーバの[server_infoメソッド][]で報告される`pubkey_node`と同じデータです)。 |

1
@l10n/ja/docs/references/http-websocket-apis/public-api-methods/server-info-methods/manifest.md
View File

@@ -148,6 +148,5 @@ Connecting to 127.0.0.1:5005
* いずれかの[汎用エラータイプ][]。
- `invalidParams` - `public_key`フィールドが見つからないか、正しく指定されていません。
- `reportingUnsupported` - ([レポートモード][]サーバのみ) このメソッドはレポートモードでは使用できません。
{% raw-partial file="/@l10n/ja/docs/_snippets/common-links.md" /%}

2
@theme/markdoc/components.tsx
View File

@@ -102,6 +102,8 @@ export function Badge(props: {
"enabled": "green",
"有効": "green", // ja: enabled
"obsolete": "red",
"removed in": "red",
"削除": "red", // ja: removed in
"廃止": "red", // ja: obsolete
"撤回": "red", // ja: withdrawn/removed/vetoed
"new in": "blue",

5
docs/_snippets/common-links.md
View File

@@ -207,7 +207,6 @@
[MPTokenIssuanceSet transaction]: /docs/references/protocol/transactions/types/mptokenissuanceset.md
[MPTokensV1_1 amendment]: /resources/known-amendments.md#priceoracle
[RFC-1751]: https://tools.ietf.org/html/rfc1751
[Reporting Mode]: /docs/concepts/networks-and-servers/rippled-server-modes.md#reporting-mode
[RequireFullyCanonicalSig amendment]: /resources/known-amendments.md#requirefullycanonicalsig
[RippleState entry]: /docs/references/protocol/ledger-data/ledger-entry-types/ripplestate.md
[RippleState object]: /docs/references/protocol/ledger-data/ledger-entry-types/ripplestate.md
@@ -300,14 +299,10 @@
[connect method]: /docs/references/http-websocket-apis/admin-api-methods/peer-management-methods/connect.md
[consensus_info command]: /docs/references/http-websocket-apis/admin-api-methods/status-and-debugging-methods/consensus_info.md
[consensus_info method]: /docs/references/http-websocket-apis/admin-api-methods/status-and-debugging-methods/consensus_info.md
[crawl_shards command]: /docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/crawl_shards.md
[crawl_shards method]: /docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/crawl_shards.md
[crypto-condition]: https://tools.ietf.org/html/draft-thomas-crypto-conditions-04
[crypto-conditions]: https://tools.ietf.org/html/draft-thomas-crypto-conditions-04
[deposit_authorized command]: /docs/references/http-websocket-apis/public-api-methods/path-and-order-book-methods/deposit_authorized.md
[deposit_authorized method]: /docs/references/http-websocket-apis/public-api-methods/path-and-order-book-methods/deposit_authorized.md
[download_shard command]: /docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/download_shard.md
[download_shard method]: /docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/download_shard.md
[drops of XRP]: /docs/references/protocol/data-types/basic-data-types.md#specifying-currency-amounts
[feature command]: /docs/references/http-websocket-apis/admin-api-methods/status-and-debugging-methods/feature.md
[feature method]: /docs/references/http-websocket-apis/admin-api-methods/status-and-debugging-methods/feature.md

9
docs/concepts/networks-and-servers/ledger-history.md
View File

@@ -58,14 +58,6 @@ Providers of Full History servers reserve the right to block access that is foun
For instructions on setting up full history, see [Configure Full History](../../infrastructure/configuration/data-retention/configure-full-history.md).
## History Sharding
An alternative to storing the full history of the XRP Ledger on a single expensive machine is to configure many servers to each store a part of all ledger history. The [History Sharding](../../infrastructure/configuration/data-retention/history-sharding.md) feature makes this possible, storing ranges of ledger history in a separate storage area called the _shard store_. When a peer server asks for specific data (as described in [fetching history](#fetching-history) above), a server can answer using data from either its ledger store or shard store.
Online deletion **does not** delete from the shard store. However, if you configure online deletion to keep at least 32768 ledger versions in your server's ledger store, your server can copy full shards from the ledger store to the shard store before automatically deleting them from the ledger store.
For more information, see [Configure History Sharding](../../infrastructure/configuration/data-retention/configure-history-sharding.md).
## See Also
@@ -76,7 +68,6 @@ For more information, see [Configure History Sharding](../../infrastructure/conf
- [Configure `rippled`](../../infrastructure/configuration/index.md)
- [Configure Online Deletion](../../infrastructure/configuration/data-retention/configure-online-deletion.md)
- [Configure Advisory Deletion](../../infrastructure/configuration/data-retention/configure-advisory-deletion.md)
- [Configure History Sharding](../../infrastructure/configuration/data-retention/configure-history-sharding.md)
- [Configure Full History](../../infrastructure/configuration/data-retention/configure-full-history.md)
- **References:**
- [ledger method][]

15
docs/concepts/networks-and-servers/rippled-server-modes.md
View File

@@ -1,6 +1,4 @@
---
html: rippled-server-modes.html
parent: networks-and-servers.html
seo:
description: Learn about rippled server modes, including stock servers, validator servers, and rippled servers run in stand-alone mode.
labels:
@@ -14,7 +12,6 @@ The `rippled` server software can run in several modes depending on its configur
- [**Validator**](#validators) - Helps secure the network by participating in consensus.
- [**API Server**](#api-servers) - Provides [API access](../../tutorials/http-websocket-apis/build-apps/get-started.md) to read data from the shared ledger, submit transactions, and watch activity in the ledger. Optionally, this can be a [**Full History Server**](#full-history-servers), which keeps a complete record of transaction and ledger history.
- [**Hub Server**](#public-hubs) - Relays messages between many other members of the peer-to-peer network.
- [**Reporting mode**](#reporting-mode) - A specialized mode for serving API requests from a relational database. It does not participate in the peer-to-peer network, so you need to run a P2P Mode server and connect the reporting mode server using a trusted gRPC connection.
- [**Stand-alone mode**](#stand-alone-mode) - An offline mode for testing. Does not connect to the peer-to-peer network or use consensus.
You can also run the `rippled` executable as a client application for accessing [`rippled` APIs](../../references/http-websocket-apis/index.md) locally. (Two instances of the same binary can run side-by-side in this case; one as a server, and the other running briefly as a client and then terminating.)
@@ -68,18 +65,6 @@ You can safely enable validation on a server that is also used for other purpose
For more information about running a validator, see [Run `rippled` as a Validator](../../infrastructure/configuration/server-modes/run-rippled-as-a-validator.md).
## Reporting Mode
Reporting mode is specialized mode for serving API requests more efficiently. In this mode, the server gets the latest validated ledger data over [gRPC](../../infrastructure/configuration/configure-grpc.md) from a separate `rippled` server running in P2P Mode, then loads that data into a relational database ([PostgreSQL](https://www.postgresql.org/)). The reporting mode server does not directly participate in the peer-to-peer network, though it can forward requests such as transaction submission to the P2P Mode server it uses.
Multiple reporting mode servers can share access to a PostgreSQL database and [Apache Cassandra](https://cassandra.apache.org/) cluster to serve a large amount of history without each server needing a redundant copy of all the data. Reporting mode servers provide this data through the same [`rippled` APIs](../../references/http-websocket-apis/index.md) with some slight changes to accommodate for the differences in how they store the underlying data.
Most notably, reporting mode servers do not report pending, non-validated ledger data or transactions. This limitation is relevant to certain use cases that rely on rapid access to in-flux data, such as performing arbitrage in the [decentralized exchange](../tokens/decentralized-exchange/index.md).
<!-- TODO: link setup steps for Reporting Mode when those are ready -->
## Stand-Alone Mode
In stand-alone mode, the server operates without connecting to the network and participating in the consensus process. Without the consensus process, you have to manually advance the ledger and no distinction is made between "closed" and "validated" ledgers. However, the server still provides API access and processes transactions the same. This enables you to:

19
docs/infrastructure/commandline-usage.md
View File

@@ -1,20 +1,6 @@
---
html: commandline-usage.html
name: Commandline Usage
parent: infrastructure.html
seo:
description: Commandline usage options for the rippled server.
curated_anchors:
- name: Available Modes
anchor: "#available-modes"
- name: Daemon Mode Options
anchor: "#daemon-mode-options"
- name: Stand-Alone Mode Options
anchor: "#stand-alone-mode-options"
- name: Client Mode Options
anchor: "#client-mode-options"
- name: Unit Tests
anchor: "#unit-tests"
labels:
- Core Server
---
@@ -66,10 +52,9 @@ Daemon mode is the default mode of operation for `rippled`. In addition to the [
| `--import` | Before fully starting, import ledger data from another `rippled` server's ledger store. Requires a valid `[import_db]` stanza in the config file. |
| `--newnodeid` | Generate a random node identity for the server. |
| `--nodeid {VALUE}` | Specify a node identity. `{VALUE}` can also be a parameter associated with the container or hardware running the server, such as `$HOSTNAME`. |
| `--nodetoshard` | Before fully starting, copy any complete [history shards](configuration/data-retention/history-sharding.md) from the ledger store into the shard store, up to the shard store's configured maximum disk space. Uses large amounts of CPU and I/O. Caution: this command copies data (instead of moving it), so you must have enough disk space to store the data in both the shard store and the ledger store. <!--{# Task for writing a tutorial to use this: DOC-1639 #}--> |
| `--quorum {QUORUM}` | This option is intended for starting [test networks](../concepts/networks-and-servers/parallel-networks.md). Override the minimum quorum for validation by requiring an agreement of `{QUORUM}` trusted validators. By default, the quorum for validation is automatically set to a safe number of trusted validators based on how many there are. If some validators are not online, this option can allow progress with a lower than normal quorum. **Warning:** If you set the quorum manually, it may be too low to prevent your server from diverging from the rest of the network. Only use this option if you have a deep understanding of consensus and have a need to use a non-standard configuration. |
| `--quorum {QUORUM}` | This option is intended for starting [test networks](../concepts/networks-and-servers/parallel-networks.md). Override the minimum quorum for validation by requiring an agreement of `{QUORUM}` trusted validators. By default, the quorum for validation is automatically set to a safe number of trusted validators based on how many there are. If some validators are not online, this option can allow progress with a lower than normal quorum. {% admonition type="danger" name="Warning" %}If you set the quorum manually, it may be too low to prevent your server from diverging from the rest of the network. Only use this option if you have a deep understanding of consensus and have a need to use a non-standard configuration.{% /admonition %} |
The following option has been removed: `--validateShards`. {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.7.0" %}Removed in: rippled 1.7.0{% /badge %}
The following options have been removed: `--validateShards` {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.7.0" %}Removed in: rippled 1.7.0{% /badge %} and `--nodetoshard` {% badge href="https://github.com/XRPLF/rippled/releases/tag/2.3.0" %}Removed in: rippled 2.3.0{% /badge %}.
## Stand-Alone Mode Options

6
docs/infrastructure/configuration/configure-grpc.md
View File

@@ -1,6 +1,4 @@
---
html: configure-grpc.html
parent: configure-rippled.html
seo:
description: Enable and configure the gRPC API.
labels:
@@ -8,9 +6,9 @@ labels:
---
# Configure gRPC
The `rippled` server has a limited [gRPC API](https://grpc.io/) which [P2P mode servers](../../concepts/networks-and-servers/rippled-server-modes.md) can provide. Reporting mode servers use this API to retrieve data about the latest validated ledgers and transactions. You can enable the gRPC API on your server with a new configuration stanza.
The `rippled` server has a limited [gRPC API](https://grpc.io/) it can provide. Clio servers use this API to retrieve data about the latest validated ledgers and transactions. You can enable the gRPC API on your server with a new configuration stanza.
{% admonition type="warning" name="Caution" %}gRPC support is intended specifically for providing data to reporting mode servers from P2P mode servers. Breaking changes to the gRPC API may occur without warning or it may be removed entirely in future versions of the server.{% /admonition %}
{% admonition type="warning" name="Caution" %}gRPC support is intended specifically for providing data to Clio servers. Breaking changes to the gRPC API may occur without warning or it may be removed entirely in future versions of the server.{% /admonition %}
## Prerequisites

1
docs/infrastructure/configuration/data-retention/configure-full-history.md
View File

@@ -21,7 +21,6 @@ Acquiring full history from the peer-to-peer network takes a long time (several
You do not need a full history server to participate in the network, validate transactions, or know the current state of the network. Full history is only useful for knowing the outcome of transactions that occurred in the past, or the state of the ledger at a given time in the past. To get such information, you must rely on other servers having the history you need.
If you want to contribute to storing the history of the XRP Ledger network without storing the full history, you can [configure history sharding](configure-history-sharding.md) to store randomly-selected chunks of ledger history instead.
## Configuration Steps

89
docs/infrastructure/configuration/data-retention/configure-history-sharding.md
View File

@@ -1,89 +0,0 @@
---
html: configure-history-sharding.html
parent: data-retention.html
seo:
description: Set up a server to contribute to preserving shards of historical XRP Ledger data.
labels:
- Data Retention
- Core Server
---
# Configure History Sharding
[History Sharding](history-sharding.md) lets servers contribute to preserving historical XRP Ledger data without each server needing to store the full history. By default, `rippled` servers do not store history shards.
{% admonition type="success" name="Tip" %}While both validator and tracking (or stock) `rippled` servers can be configured to store history shards, Ripple recommends _not_ configuring validator `rippled` servers to store shards, to reduce overhead on those servers. If you run a validator and want to contribute to storing XRP Ledger history, Ripple recommends you run a separate `rippled` server with history sharding enabled.{% /admonition %}
To configure your `rippled` to store shards of ledger history, complete the following steps:
## 1. Determine how many shards to maintain
Before you configure your `rippled` server to store history shards, you must decide how many history shards you want to keep, which is mostly determined by how much disk space is available for the shard store. This also affects how much history you keep in the default ledger store. You should consider the following when deciding what size to configure your shard store:
- The ledger store (defined by the `[node_db]` stanza) is separate from the history shard store. The ledger store is required for all servers, and always contains a range of recent history, defined by how many ledgers to keep available in the `online_delete` parameter. (The default configuration stores the most recent 2000 ledgers.)
- If you keep at least 2<sup>15</sup> ledgers (32768) in the ledger store, you can efficiently import chunks of recent history from the ledger store into the shard store.
- The history shard store (defined by the `[shard_db]` stanza) is only required for storing history shards. The configuration stanza should be omitted from servers that do not store history shards. The total number of shards stored is defined by the `max_historical_shards` parameter; the server attempts to store no more than this many complete shards. The history shard store _MUST_ be stored on a solid-state disk or similar fast media. Traditional spinning hard disks are insufficient.
- A shard consists of 2<sup>14</sup> ledgers (16384) and occupies approximately 200 MB to 4 GB based on the age of the shard. Older shards are smaller because there was less activity in the XRP Ledger at the time.
- The history shard store and the ledger store _MUST_ be stored at different file paths. You can configure the ledger store and history store to be on different disks or partitions if desired.
- It is possible but redundant to hold full ledger history in both the ledger store and the history shard store.
- The time to acquire a shard, number of file handles needed by the `rippled` server, and memory cache usage is directly affected by the size of the shard.
- You can specify additional paths to store older history shards by providing a `[historical_shard_paths]` stanza. These paths may be on different, slower disks because they hold data that is used less often. The most recent two shards (the ones with the largest ledger indexes) are always stored in the path specified in the `[shard_db]` stanza.
## 2. Edit rippled.cfg
<!-- SPELLING_IGNORE: cfg -->
Edit your `rippled.cfg` file to add a `[shard_db]` stanza and optionally a `[historical_shard_paths]` stanza.
{% partial file="/docs/_snippets/conf-file-location.md" /%}
The following snippet shows an example of a `[shard_db]` stanza:
```
[shard_db]
path=/var/lib/rippled/db/shards/nudb
max_historical_shards=12
# Optional paths for shards other than the newest 2
[historical_shard_paths]
/mnt/disk1
/mnt/disk2
```
The `type` field of `[shard_db]` can be omitted. If present, it _MUST_ be `NuDB`.
{% admonition type="warning" name="Caution" %}If `rippled` detects the wrong type of data in the shard store path, it may [fail to start](../../troubleshooting/server-wont-start.md). You should use a new folder for the shard store. If you previously used a RocksDB shard store (`rippled` 1.2.x and lower), use a different path or delete the RocksDB shard data.{% /admonition %}
For more information, reference the `[shard_db]` example in the [rippled.cfg configuration example](https://github.com/XRPLF/rippled/blob/master/cfg/rippled-example.cfg).
## 3. Restart the server
```
systemctl restart rippled
```
## 4. Wait for shards to download
After your server syncs to the network, it automatically starts downloading history shards to fill the available space in the shard store. You can see which shards are being downloaded by looking at which folders are created in the folder where you configured your shard store. (This is defined by the `path` field of the `[shard_db]` stanza in the `rippled.cfg` file.)
This folder should contain a numbered folder for each shard your server has. At any given time, up to one folder may contain a `control.txt` file, indicating it is incomplete.
You can instruct your server to download and import a shard from an archive file using the [download_shard method][].
To list the shards your server and its peers have available, you can use the [crawl_shards method][] or the [Peer Crawler](../../../references/http-websocket-apis/peer-port-methods/peer-crawler.md).
## See Also
- **Concepts:**
- [Ledger History](../../../concepts/networks-and-servers/ledger-history.md)
- [Online Deletion](online-deletion.md)
- **Tutorials:**
- [Configure Online Deletion](configure-online-deletion.md)
- [Configure the Peer Crawler](../peering/configure-the-peer-crawler.md)
- [Capacity Planning](../../installation/capacity-planning.md)
- **References:**
- [download_shard method][]
- [crawl_shards method][]
- [Ledger Data Formats](../../../references/protocol/ledger-data/index.md)
{% raw-partial file="/docs/_snippets/common-links.md" /%}

1
docs/infrastructure/configuration/data-retention/configure-online-deletion.md
View File

@@ -81,7 +81,6 @@ To change the amount of history your server stores, perform the following steps:
- [Online Deletion](online-deletion.md)
- **Tutorials:**
- [Configure Advisory Deletion](configure-advisory-deletion.md)
- [Configure History Sharding](configure-history-sharding.md)
- [Capacity Planning](../../installation/capacity-planning.md)
- **References:**
- [server_info method][]

50
docs/infrastructure/configuration/data-retention/history-sharding.md
View File

@@ -1,50 +0,0 @@
---
html: history-sharding.html
parent: data-retention.html
seo:
description: History sharding divides the work of keeping historical ledger data among rippled servers.
labels:
- Data Retention
- Core Server
---
# History Sharding
{% admonition type="danger" name="Warning" %}History sharding was removed in [rippled 2.3.0](https://github.com/XRPLF/rippled/releases/tag/2.3.0). This page describes historical behavior of older versions of XRP Ledger software.{% /admonition %}
As XRP Ledger servers run, they naturally produce a database containing data about the ledgers they built or acquired during network runtime. Each server stores that ledger data in its _ledger store_, but [online deletion](online-deletion.md) removes old ledgers' data automatically over time. History sharding provides a separate storage system for older ledger history so that the network can divide up the work of recording the entire (multiple terabyte) history of the XRP Ledger.
Historical sharding distributes the transaction history of the XRP Ledger into segments, called shards, across servers in the XRP Ledger network. A shard is a range of ledgers. A server uses mostly the same format for ledgers in both the ledger store and the shard store, but the two stores are separate.
[![XRP Ledger Network: Ledger Store and Shard Store Diagram](/docs/img/xrp-ledger-network-ledger-store-and-shard-store.png)](/docs/img/xrp-ledger-network-ledger-store-and-shard-store.png)
<!-- Diagram source: https://docs.google.com/presentation/d/1mg2jZQwgfLCIhOU8Mr5aOiYpIgbIgk3ymBoDb2hh7_s/edit#slide=id.g417450e8da_0_316 -->
## Acquiring and Sharing History Shards
Servers acquire and store history shards only if configured to do so. Acquiring shards begins after synchronizing with the network and backfilling ledger history to the configured number of recent ledgers. During this time of lower network activity, a server set to maintain a shard database randomly chooses a shard to add to its shard store. To increase the probability for an even distribution of the network ledger history, shards are randomly selected for acquisition, and the most recent shard is given no special consideration.
Once a shard is selected, the ledger acquire process begins by fetching the sequence of the last ledger in the shard and working backwards toward the first. The retrieval process begins with the server checking for the data locally. For data that is not available, the server requests data from its peers. Those servers that have the data available for the requested period respond with their history. The requesting server combines those responses to create the shard. The shard is complete when it contains all the ledgers in a specific range.
The server selects and downloads additional shards until it reaches the maximum number of shards it is configured to store. If a server runs out of space before completely acquiring a shard, it stops its retrieval process until it has space available to continue.
## XRP Ledger Network Data Integrity
The history of all ledgers is shared by servers agreeing to keep particular ranges of historical ledgers. This makes it possible for servers to confirm that they have all the data they agreed to maintain, and produce "proof trees" or "ledger deltas" which shows how each ledger in the blockchain's history was the result of applying transactions to the previous state. Since servers that are configured with history sharding randomly select the shards that they store, the entire history of all closed ledgers is stored in a normal distribution curve, increasing the probability that the XRP Ledger Network evenly maintains the history.
History shards are recorded in a deterministic format, so that any two servers assembling the same shard produce the exact same binary data no matter what order they acquired the data and where they got it from. This makes it possible to compare checksums or cryptographic hashes of the shard data to verify the integrity of the data, and it is possible to share and import history shards through other formats. (For example, you could download shard data using Bittorrent or acquire physical media with the shard data pre-loaded on it, and verify that it matches the data that can be downloaded from the network.) {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.8.1" %}New in: rippled 1.8.1{% /badge %}
## See Also
- **Concepts:**
- [Ledgers](../../../concepts/ledgers/index.md)
- [Consensus](../../../concepts/consensus-protocol/index.md)
- **Tutorials:**
- [Capacity Planning](../../installation/capacity-planning.md)
- [Configure `rippled`](../index.md)
- [Configure History Sharding](configure-history-sharding.md)
- **References:**
- [crawl_shards method][]
- [download_shard method][]
- [Peer Crawler](../../../references/http-websocket-apis/peer-port-methods/peer-crawler.md)
{% raw-partial file="/docs/_snippets/common-links.md" /%}

1
docs/infrastructure/configuration/data-retention/online-deletion.md
View File

@@ -126,7 +126,6 @@ When it comes time for online deletion, the server first walks through the oldes
- [Configure `rippled`](../index.md)
- [Configure Online Deletion](configure-online-deletion.md)
- [Configure Advisory Deletion](configure-advisory-deletion.md)
- [Configure History Sharding](configure-history-sharding.md)
- [Configure Full History](configure-full-history.md)
- **References:**
- [ledger method][]

4
docs/infrastructure/installation/capacity-planning.md
View File

@@ -1,6 +1,4 @@
---
html: capacity-planning.html
parent: install-rippled.html
seo:
description: Plan system specs and tune configuration for rippled in production environments.
labels:
@@ -159,7 +157,7 @@ The `[database_path]` configures separate bookkeeping databases: these include t
As a general rule, you can safely delete the database files (both the ledger store and the bookkeeping databases) for a `rippled` server when it isn't running; this clears any stored ledger history the server has, but it can re-acquire that data from the network. However, if you delete the `wallet.db` file in the `[database_path]`, you must manually reapply runtime configuration changes such as [amendment votes](../configuration/configure-amendment-voting.md) and [peer reservations](../configuration/peering/use-a-peer-reservation.md).
If you want to contribute to storing ledger history but you do not have enough disk space to store full history, you can use the [History Sharding](../configuration/data-retention/history-sharding.md) feature to store a randomized range of ledgers in a separate shard store. History sharding is configured in the `[shard_db]` stanza.
If your server has a `[shard_db]` stanza, you can remove it. History Sharding was removed in `rippled` version 2.3.0, so this config stanza no longer does anything.
##### Amazon Web Services

2
docs/infrastructure/troubleshooting/fix-sqlite-tx-db-page-size-issue.md
View File

@@ -17,7 +17,7 @@ This document describes steps to detect and correct this problem if it occurs.
The capacity of the SQLite database is a result of the database's _page size_ parameter, which cannot be easily changed after the database is created. (For more information on SQLite's internals, see [the official SQLite documentation](https://www.sqlite.org/fileformat.html).) The database can reach its capacity even if there is still free space on the disk and filesystem where it is stored. As described in the [Fix](#fix) below, reconfiguring the page size to avoid this problem requires a somewhat time-consuming migration process. <!-- STYLE_OVERRIDE: easily -->
{% admonition type="success" name="Tip" %}Full history is not necessary for most use cases. Servers with full transaction history may be useful for long-term analysis and archive purposes or as a precaution against disasters. For a less resource-intense way to contribute to the storage of transaction history, see [History Sharding](../configuration/data-retention/history-sharding.md).{% /admonition %}
{% admonition type="success" name="Tip" %}Full history is not necessary for most use cases. Servers with full transaction history may be useful for long-term analysis and archive purposes or as a precaution against disasters.{% /admonition %}
## Detection

27
docs/infrastructure/troubleshooting/server-wont-start.md
View File

@@ -187,33 +187,6 @@ Terminating thread rippled: main: unhandled N5beast14BadLexicalCastE 'std::bad_c
Valid parameters for the `node_size` field are `tiny`, `small`, `medium`, `large`, or `huge`. For more information see [Node Size](../installation/capacity-planning.md#node-size).
## Shard path missing
An error such as the following indicates that the `rippled.cfg` has an incomplete [history sharding](../configuration/data-retention/history-sharding.md) configuration:
```text
Terminating thread rippled: main: unhandled St13runtime_error 'shard path missing'
```
If your config includes a `[shard_db]` stanza, it must contain a `path` field, which points to a directory where `rippled` can write the data for the shard store. This error means the `path` field is missing or located in the wrong place. Check for extra whitespace or typos in your config file, and compare against the [Shard Configuration Example](../configuration/data-retention/configure-history-sharding.md#2-edit-rippledcfg).
## Unsupported shard store type: RocksDB
RocksDB is no longer supported as a backend for [history sharding](../configuration/data-retention/history-sharding.md). If you have an existing configuration that defines a RocksDB shard store, the server fails to start.
In this case, the process dies shortly after the log startup command, with a message such as the following appearing earlier in the output log:
```text
ShardStore:ERR Unsupported shard store type: RocksDB
```
To fix this problem, do one of the following, then restart the server:
- Change your shard store to use NuDB instead.
- Disable history sharding.
## See Also
- **Concepts:**

38
docs/infrastructure/troubleshooting/understanding-log-messages.md
View File

@@ -137,7 +137,7 @@ To avoid being dropped by rate limiting on your own server, [connect as an admin
InboundLedger:WRN 11 timeouts for ledger 8265938
```
This indicates that your server is having trouble requesting specific ledger data from its peers. If the [ledger index](../../references/protocol/data-types/basic-data-types.md#ledger-index) is much lower than the most recent validated ledger's index as reported by the [server_info method][], this probably indicates that your server is downloading a [history shard](../configuration/data-retention/history-sharding.md).
This indicates that your server is having trouble requesting specific ledger data from its peers.
This is not strictly a problem, but if you want to acquire ledger history faster, you can configure `rippled` to connect to peers with full history by adding or editing the `[ips_fixed]` config stanza and restarting the server. For example, to always try to connect to one of Ripple's full-history servers:
@@ -155,7 +155,7 @@ Log messages such as the following indicate that the server is requesting ledger
InboundLedger:WRN Want: 5AE53B5E39E6388DBACD0959E5F5A0FCAF0E0DCBA45D9AB15120E8CDD21E019B
```
This is normal if your server is syncing, backfilling, or downloading [history shards](../configuration/data-retention/history-sharding.md).
This is normal if your server is syncing or backfilling.
## LoadMonitor Job
@@ -181,29 +181,14 @@ It is **normal** to display several messages of these types **during the first f
If the messages continue for more than 5 minutes after starting the server, especially if the `run` times are well over 1000 ms, that may indicate that **your server does not have enough disk I/O, RAM, or CPU**. This may be caused by not having powerful enough hardware or because other processes running on the same hardware are competing with `rippled` for resources. (Examples of other processes that may compete with `rippled` for resources include scheduled backups, virus scanners, and periodic database cleaners.)
Another possible cause is trying to use NuDB on rotational hard disks; NuDB should only be used with solid state drives (SSDs). Ripple recommends always using SSD storage for `rippled`'s databases, but you _may_ be able to run `rippled` successfully on rotational disks using RocksDB. If you are using rotational disks, make sure both the `[node_db]` and the `[shard_db]` (if you have one) are configured to use RocksDB. For example:
Another possible cause is trying to use NuDB on rotational hard disks; NuDB should only be used with solid state drives (SSDs). It's **not recommended** to use `rippled` with rotational disks, but you _may_ be able to do so using RocksDB. If you are using rotational disks, make sure both `[node_db]` is configured to use RocksDB. For example:
```
[node_db]
type=RocksDB
# ... more config omitted
[shard_db]
type=RocksDB
```
## No hash for fetch pack
Messages such as the following are caused by a bug in `rippled` v1.1.0 and earlier when downloading historical ledgers for [history sharding](../configuration/data-retention/history-sharding.md):
```text
2018-Aug-28 22:56:21.397076850 LedgerMaster:ERR No hash for fetch pack. Missing Index 7159808
```
These can be safely ignored.
## Not deleting
Messages such as the following occur when [online deletion is interrupted](../configuration/data-retention/online-deletion.md#interrupting-online-deletion):
@@ -264,23 +249,6 @@ The number at the end of the message is the [ledger index][] of the validated le
If the server falls out of sync while running online deletion, it interrupts online deletion and writes a ["Not deleting" log message](#not-deleting) instead of a "finished rotation" message.
## Shard: No such file or directory
Log messages such as the following can occur when you have [history sharding](../configuration/data-retention/history-sharding.md) enabled:
```text
ShardStore:ERR shard 1804: No such file or directory
```
This indicates that the server tried to start acquiring a new history shard, but it cannot write to the underlying file system. Possible causes include:
- Hardware failure of storage media
- The file system became unmounted
- The shard folder was deleted
{% admonition type="success" name="Tip" %}It is generally safe to delete `rippled`'s database files when the service is stopped, but you should never delete them while the server is running.{% /admonition %}
## Unable to determine hash of ancestor
Log messages such as the following occur when the server sees a validation message from a peer and it does not know the parent ledger version that server is building on. This can occur when the server is not in sync with the rest of the network:

2
docs/introduction/software-ecosystem.md
View File

@@ -30,7 +30,7 @@ The peer-to-peer network at the heart of the XRP Ledger requires a highly-reliab
Every core server syncs to the same network (unless it's configured to follow a [test network](../concepts/networks-and-servers/parallel-networks.md)) and has access to all communications across the network. Every server on the network keeps a complete copy of the latest state data for the entire XRP Ledger, along with recent transactions and a record of the changes those transactions made, and every server processes every transaction independently while verifying that its outcome matches the rest of the network. Servers can be configured to keep more [ledger history](../concepts/networks-and-servers/ledger-history.md) and to participate in the consensus process as a [validator](../concepts/networks-and-servers/rippled-server-modes.md#validators).
Core servers expose [HTTP / WebSocket APIs](../references/http-websocket-apis/index.md) for users to look up data, administer the server, and submit transactions. Some servers also serve HTTP / WebSocket APIs but don't connect directly to the peer-to-peer network and don't process transactions or participate in consensus. These servers, such as `rippled` servers running in Reporting Mode and Clio servers, rely on a core server in P2P mode to process transactions.
Core servers expose [HTTP / WebSocket APIs](../references/http-websocket-apis/index.md) for users to look up data, administer the server, and submit transactions. Clio servers also serve HTTP / WebSocket APIs but they don't connect directly to the peer-to-peer network and don't process transactions or participate in consensus. These servers rely on a core server in P2P mode to process transactions.
### Client Libraries

5
docs/references/http-websocket-apis/admin-api-methods/index.md
View File

@@ -1,6 +1,4 @@
---
html: admin-api-methods.html
parent: http-websocket-apis.html
seo:
description: Administer an XRP Ledger server with these API methods.
labels:
@@ -26,12 +24,10 @@ Use these methods to generate and manage keys.
Use these methods to manage log levels and other data, such as ledgers.
* **[`can_delete`](logging-and-data-management-methods/can_delete.md)** - Allow online deletion of ledgers up to a specific ledger.
* **[`download_shard`](logging-and-data-management-methods/download_shard.md)** - Download a specific shard of ledger history.
* **[`ledger_cleaner`](logging-and-data-management-methods/ledger_cleaner.md)** - Configure the ledger cleaner service to check for corrupted data.
* **[`ledger_request`](logging-and-data-management-methods/ledger_request.md)** - Query a peer server for a specific ledger version.
* **[`log_level`](logging-and-data-management-methods/log_level.md)** - Get or modify log verbosity.
* **[`logrotate`](logging-and-data-management-methods/logrotate.md)** - Reopen the log file.
* **[`node_to_shard`](logging-and-data-management-methods/node_to_shard.md)** - Copy data from the ledger store to the shard store.
## [Server Control Methods](server-control-methods/index.md)
@@ -47,6 +43,7 @@ Use these methods to sign transactions.
* **[`sign`](signing-methods/sign.md)** - Cryptographically sign a transaction.
* **[`sign_for`](signing-methods/sign_for.md)** - Contribute to a multi-signature.
* **[`channel_authorize`](../public-api-methods/payment-channel-methods/channel_authorize.md)** - Sign a claim for money from a payment channel.
By default, these methods are [admin-only](../../../tutorials/http-websocket-apis/build-apps/get-started.md#admin-access). They can be used as public methods if the server admin has [enabled public signing](../../../infrastructure/configuration/enable-public-signing.md).

1
docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/can_delete.md
View File

@@ -74,7 +74,6 @@ Use this command with no parameter to query the existing `can_delete` setting.
- `lgrNotFound` - The ledger specified by the `can_delete` field of the request does not exist, or it does exist but the server does not have it.
- `notEnabled` - If either online deletion or advisory deletion are not enabled in the server's configuration.
- `notReady` - The server is not ready to run online deletion at the moment. This usually means the server has recently started up and has not yet acquired a validated ledger.
- `reportingUnsupported` - ([Reporting Mode][] servers only) This method is not available in Reporting Mode.
## See Also

141
docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/crawl_shards.md
View File

@@ -1,141 +0,0 @@
---
html: crawl_shards.html
parent: logging-and-data-management-methods.html
seo:
description: Request information about which history shards peers have.
labels:
- Data Retention
---
# crawl_shards
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/rpc/handlers/CrawlShards.cpp "Source")
Requests information from peer servers about which [shards of historical ledger data](../../../../infrastructure/configuration/data-retention/history-sharding.md) they have available.
_The `crawl_shards` method is an [admin method](../index.md) that cannot be run by unprivileged users._
### Request Format
An example of the request format:
{% tabs %}
{% tab label="WebSocket" %}
```json
{
"command": "crawl_shards",
"public_key": true,
"limit": 0
}
```
{% /tab %}
{% tab label="JSON-RPC" %}
```json
{
"method": "crawl_shards",
"params": [
{
"public_key": true,
"limit": 0
}
]
}
```
{% /tab %}
{% /tabs %}
{% admonition type="info" name="Note" %}There is no command-line syntax for this method. Use the [json method][] to access this from the command line.{% /admonition %}
The request includes the following fields:
| `Field` | Type | Description |
|:---------|:--------|:--------------------------------------------------------|
| `public_key` | Boolean | _(Optional)_ If `true`, the response includes the node public keys (for peer-to-peer communications) of servers that were crawled. The default is `false`. |
| `limit` | Number | _(Optional)_ How many hops deep to search. The default is 0, which searches direct peers only. With a limit of `1`, searches peers' peers also. The maximum value is `3`. |
{% admonition type="warning" name="Caution" %}The number of peers potentially searched grows exponentially as `limit` increases. With a limit of 2 or 3, it can take several seconds for the server to respond to the API request.{% /admonition %}
### Response Format
An example of a successful response:
{% tabs %}
{% tab label="WebSocket" %}
```json
{
"result": {
"complete_shards": "1-2,5,8-9,584,1973,2358",
"peers": [
{
"complete_shards": "1-2,8,47,371,464,554,653,857,1076,1402,1555,1708,1813,1867",
"public_key": "n9LxFZiySnfDSvfh23N94UxsFkCjWyrchTeKHcYE6tJJQL5iejb2"
},
{
"complete_shards": "8-9,584",
"ip": "192.168.1.132",
"public_key": "n9MN5xwYqbrj64rtfZAXQy7Y3sNxXZJeLt7Lj61a9DYEZ4SE2tQQ"
}
]
},
"status": "success",
"type": "response"
}
```
{% /tab %}
{% tab label="JSON-RPC" %}
```json
200 OK
{
"result": {
"complete_shards": "1-2,5,8-9,584,1973,2358",
"peers": [
{
"complete_shards": "1-2,8,47,371,464,554,653,857,1076,1402,1555,1708,1813,1867",
"public_key": "n9LxFZiySnfDSvfh23N94UxsFkCjWyrchTeKHcYE6tJJQL5iejb2"
},
{
"complete_shards": "8-9,584",
"ip": "192.168.1.132",
"public_key": "n9MN5xwYqbrj64rtfZAXQy7Y3sNxXZJeLt7Lj61a9DYEZ4SE2tQQ"
}
],
"status": "success"
}
}
```
{% /tab %}
{% /tabs %}
The response follows the [standard format][], with a successful result containing the following fields:
| `Field` | Type | Description |
|:------------------|:-------|:------------------------------------------------|
| `complete_shards` | String | _(May be omitted)_ The range of [history shards](../../../../infrastructure/configuration/data-retention/history-sharding.md) that are available on the local server. This may be an empty string, or a disjointed range. For example, `1-2,5,7-9` indicates that shards 1, 2, 5, 7, 8, and 9 are available. Omitted if this server does not have history sharding enabled. |
| `peers` | Array | _(May be omitted)_ List of **Peer Shard Objects** (see below) describing which history shards each peer has available. The response omits this field if no peers within the number of hops specified by `limit` have any shards. |
#### Peer Shard Objects
Each member of the `peers` array of the response is an object that describes one server in the peer-to-peer network. The list only includes peers that have at least one complete [history shard](../../../../infrastructure/configuration/data-retention/history-sharding.md) available. Each object in the array has the following fields:
| `Field` | Type | Description |
|:----------|:-------|:--------------------------------------------------------|
| `complete_shards` | String | The range of complete history shards this peer has available. This may be disjointed. For example, `1-2,5,7-9` indicates that shards 1, 2, 5, 7, 8, and 9 are available. |
| `incomplete_shards` | String | _(May be omitted)_ A comma-separated list of history shards this peer has partially downloaded, and percent completion for each. For example, `1:50,2:25` indicates that shard 1 is 50% downloaded and shard 2 is 25% downloaded. {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.8.1" %}New in: rippled 1.8.1{% /badge %} |
| `public_key` | String | _(Omitted unless the request specified `"public_key": true`)_ The public key this peer uses for peer-to-peer communications, in the XRP Ledger's [base58 format](../../../protocol/data-types/base58-encodings.md). |
The `ip` field is no longer provided. {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.8.1" %}Removed in: rippled 1.8.1{% /badge %}
### Possible Errors
- Any of the [universal error types][].
- `invalidParams` - One or more required fields were omitted from the request, or a provided field was specified as the wrong data type.
- `reportingUnsupported` - ([Reporting Mode][] servers only) This method is not available in Reporting Mode.
{% raw-partial file="/docs/_snippets/common-links.md" /%}

144
docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/download_shard.md
View File

@@ -1,144 +0,0 @@
---
html: download_shard.html
parent: logging-and-data-management-methods.html
seo:
description: Download a specific shard of ledger history.
labels:
- Data Retention
---
# download_shard
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/rpc/handlers/DownloadShard.cpp "Source")
Instructs the server to download a specific [shard of historical ledger data](../../../../infrastructure/configuration/data-retention/history-sharding.md) from an external source. Your `rippled` server must be [configured to store history shards](../../../../infrastructure/configuration/data-retention/configure-history-sharding.md). {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.6.0" %}Updated in: rippled 1.6.0{% /badge %}
_The `download_shard` method is an [admin method](../index.md) that cannot be run by unprivileged users._
The external source must provide the shard as an [lz4-compressed](https://lz4.github.io/lz4/) [tar archive](https://en.wikipedia.org/wiki/Tar_(computing)) served via HTTPS. The archive must contain the shard directory and data files in NuDB format.
Downloading and importing shards using this method is usually faster than acquiring the shards individually from the peer-to-peer network. You can also use this method to choose a specific range or set of shards to provide from your server.
### Request Format
An example of the request format:
{% tabs %}
{% tab label="WebSocket" %}
```json
{
"command": "download_shard",
"shards": [
{"index": 1, "url": "https://example.com/1.tar.lz4"},
{"index": 2, "url": "https://example.com/2.tar.lz4"},
{"index": 5, "url": "https://example.com/5.tar.lz4"}
]
}
```
{% /tab %}
{% tab label="JSON-RPC" %}
```json
{
"method": "download_shard",
"params": [
{
"shards": [
{"index": 1, "url": "https://example.com/1.tar.lz4"},
{"index": 2, "url": "https://example.com/2.tar.lz4"},
{"index": 5, "url": "https://example.com/5.tar.lz4"}
]
}
]
}
```
{% /tab %}
{% tab label="Commandline" %}
```sh
# Syntax: download_shard [[<index> <url>]]
rippled download_shard 1 https://example.com/1.tar.lz4 2 https://example.com/2.tar.lz4 5 https://example.com/5.tar.lz4
```
{% /tab %}
{% /tabs %}
The request includes the following field:
| `Field` | Type | Description |
|:-----------|:--------|:------------------------------------------------------|
| `shards` | Array | List of Shard Descriptor objects (see below) describing shards to download and where to download them from. |
The `validate` field is deprecated and may be removed in a future version. (The server always checks the integrity of shards when it imports them.) {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.6.0" %}Updated in: rippled 1.6.0{% /badge %}
Each **Shard Descriptor object** in the `shards` array has the following fields:
| `Field` | Type | Description |
|:--------|:-------|:----------------------------------------------------------|
| `index` | Number | The index of the shard to retrieve. In the production XRP Ledger, the oldest shard has index 1 and contains ledgers 32750-32768. The next shard has index 2 and contains ledgers 32769-49152, and so on. |
| `url` | String | The URL where this shard can be downloaded. The URL must start with `http://` or `https://` and must end with `.tar.lz4` (not case-sensitive). The web server providing this download must use a valid TLS certificate signed by a trusted Certificate Authority (CA). (`rippled` uses the operating system's CA store.) {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.7.0" %}Updated in: rippled 1.7.0{% /badge %} |
### Response Format
An example of a successful response:
{% tabs %}
{% tab label="WebSocket" %}
```json
{
"result": {
"message": "downloading shards 1-2,5"
},
"status": "success",
"type": "response"
}
```
{% /tab %}
{% tab label="JSON-RPC" %}
```json
200 OK
{
"result": {
"message": "downloading shards 1-2,5",
"status": "success"
}
}
```
{% /tab %}
{% tab label="Commandline" %}
```json
Loading: "/etc/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result": {
"message": "downloading shards 1-2,5",
"status": "success"
}
}
```
{% /tab %}
{% /tabs %}
The response follows the [standard format][], with a successful result containing the following fields:
| `Field` | Type | Description |
|:----------|:-------|:--------------------------------------------------------|
| `message` | String | A message describing the actions taken in response to this request. |
{% admonition type="success" name="Tip" %}To see which shards your server has available, use the [crawl_shards method][]. Alternatively, you can look at the subfolders in your configured location for the shard store (the `path` parameter of `[shard_db]` in your `rippled.cfg`). The folders are named to match the numbers of the shards; up to one of those folders may contain a `control.txt` file indicating that the shard is incomplete.{% /admonition %}
### Possible Errors
- Any of the [universal error types][].
- `notEnabled` - The server is not configured with a shard store.
- `tooBusy` - The server is already downloading the shard, either from the peer-to-peer network or as the result of a previous `download_shard` request.
- `invalidParams` - One or more required fields were omitted from the request, or a provided field was specified as the wrong data type.
- `reportingUnsupported` - ([Reporting Mode][] servers only) This method is not available in Reporting Mode.
{% raw-partial file="/docs/_snippets/common-links.md" /%}

1
docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/ledger_request.md
View File

@@ -187,6 +187,5 @@ When the server is in the progress of fetching a ledger, but has not yet finishe
- Any of the [universal error types][].
- `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing. This error can also occur if you specify a ledger index equal or higher than the current in-progress ledger.
- `lgrNotFound` - If the ledger is not yet available. This indicates that the server has started fetching the ledger, although it may fail if none of its connected peers have the requested ledger. (Previously, this error used the code `ledgerNotFound` instead.) {% badge href="https://github.com/XRPLF/rippled/releases/tag/0.30.1" %}Updated in: rippled 0.30.1{% /badge %}
- `reportingUnsupported` - ([Reporting Mode][] servers only) This method is not available in Reporting Mode.
{% raw-partial file="/docs/_snippets/common-links.md" /%}

120
docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/node_to_shard.md
View File

@@ -1,120 +0,0 @@
---
html: node_to_shard.html
parent: logging-and-data-management-methods.html
seo:
description: Copy data from the ledger store into the shard store.
labels:
- Data Retention
---
# node_to_shard
[[Source]](https://github.com/XRPLF/rippled/blob/develop/src/ripple/rpc/handlers/NodeToShard.cpp "Source")
The {% code-page-name /%} method manages copying data from the ledger store to the [shard store](../../../../infrastructure/configuration/data-retention/history-sharding.md). It can start, stop, or check the status of copying the data.
_The {% code-page-name /%} method is an [admin method](../index.md) that cannot be run by unprivileged users._
### Request Format
An example of the request format:
{% tabs %}
{% tab label="WebSocket" %}
```json
{
"command": "{% $frontmatter.seo.title %}",
"action": "start"
}
```
{% /tab %}
{% tab label="JSON-RPC" %}
```json
{
"method": "{% $frontmatter.seo.title %}",
"params": [{
"action": "start"
}]
}
```
{% /tab %}
{% tab label="Commandline" %}
```sh
#Syntax: {% $frontmatter.seo.title %} start|stop|status
rippled {% $frontmatter.seo.title %} start
```
{% /tab %}
{% /tabs %}
The request includes the following parameters:
| `Field` | Type | Description |
|:---------|:-------|:---------------------------------------------------------|
| `action` | String | Either `start`, `stop` or `status` depending on what action to take. |
### Response Format
An example of a successful response:
{% tabs %}
{% tab label="WebSocket" %}
```json
{
"result": {
"message": "Database import initiated..."
},
"status": "success",
"type": "response"
}
```
{% /tab %}
{% tab label="JSON-RPC" %}
```json
{
"result" : {
"message" : "Database import initiated...",
"status" : "success"
}
}
```
{% /tab %}
{% tab label="Commandline" %}
```json
Loading: "/etc/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result" : {
"message" : "Database import initiated...",
"status" : "success"
}
}
```
{% /tab %}
{% /tabs %}
The response follows the [standard format][], with a successful result containing the following fields:
| `Field` | Type | Description |
|:----------|:-------|:--------------------------------------------------------|
| `message` | String | A human-readable message indicating the action taken in response to the command. |
### Possible Errors
- Any of the [universal error types][].
- `internal` - If you attempt an invalid operation like checking the status of a copy when one isn't running.
- `notEnabled` - If the server is not configured to store [history shards](../../../../infrastructure/configuration/data-retention/history-sharding.md).
- `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing.
{% raw-partial file="/docs/_snippets/common-links.md" /%}

1
docs/references/http-websocket-apis/admin-api-methods/peer-management-methods/connect.md
View File

@@ -102,6 +102,5 @@ The response follows the [standard format][], with a successful result containin
- Any of the [universal error types][].
- `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing.
- Cannot connect in stand-alone mode - Network-related commands are disabled in stand-alone mode.
- `reportingUnsupported` - ([Reporting Mode][] servers only) This method is not available in Reporting Mode.
{% raw-partial file="/docs/_snippets/common-links.md" /%}

1
docs/references/http-websocket-apis/admin-api-methods/peer-management-methods/peer_reservations_add.md
View File

@@ -137,6 +137,5 @@ If the `previous` field is provided, it shows the previous status of this peer r
- Any of the [universal error types][].
- `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing.
- `publicMalformed` - The `public_key` field of the request is not valid. It must be a valid node public key in [base58][] format.
- `reportingUnsupported` - ([Reporting Mode][] servers only) This method is not available in Reporting Mode.
{% raw-partial file="/docs/_snippets/common-links.md" /%}

1
docs/references/http-websocket-apis/admin-api-methods/peer-management-methods/peer_reservations_del.md
View File

@@ -133,6 +133,5 @@ If the `previous` field is provided, it shows the previous status of this peer r
- Any of the [universal error types][].
- `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing.
- `publicMalformed` - The `public_key` field of the request is not valid. It must be a valid node public key in [base58][] format.
- `reportingUnsupported` - ([Reporting Mode][] servers only) This method is not available in Reporting Mode.
{% raw-partial file="/docs/_snippets/common-links.md" /%}

1
docs/references/http-websocket-apis/admin-api-methods/peer-management-methods/peer_reservations_list.md
View File

@@ -135,6 +135,5 @@ Each member of the `reservations` array is a JSON object describing one [peer re
### Possible Errors
- Any of the [universal error types][].
- `reportingUnsupported` - ([Reporting Mode][] servers only) This method is not available in Reporting Mode.
{% raw-partial file="/docs/_snippets/common-links.md" /%}

1
docs/references/http-websocket-apis/admin-api-methods/peer-management-methods/peers.md
View File

@@ -417,6 +417,5 @@ The `metrics` object contains the following fields:
### Possible Errors
- Any of the [universal error types][].
- `reportingUnsupported` - ([Reporting Mode][] servers only) This method is not available in Reporting Mode.
{% raw-partial file="/docs/_snippets/common-links.md" /%}

1
docs/references/http-websocket-apis/admin-api-methods/status-and-debugging-methods/consensus_info.md
View File

@@ -236,6 +236,5 @@ The results of the `consensus_info` command can vary dramatically if you run it
### Possible Errors
- Any of the [universal error types][].
- `reportingUnsupported` - ([Reporting Mode][] servers only) This method is not available in Reporting Mode.
{% raw-partial file="/docs/_snippets/common-links.md" /%}

1
docs/references/http-websocket-apis/admin-api-methods/status-and-debugging-methods/feature.md
View File

@@ -197,6 +197,5 @@ The response follows the [standard format][], with a successful result containin
- Any of the [universal error types][].
- `badFeature` - The `feature` specified was invalidly formatted, or the server does not know an amendment with that name.
- `reportingUnsupported` - ([Reporting Mode][] servers only) This method is not available in Reporting Mode.
{% raw-partial file="/docs/_snippets/common-links.md" /%}

1
docs/references/http-websocket-apis/admin-api-methods/status-and-debugging-methods/fetch_info.md
View File

@@ -163,6 +163,5 @@ The fields describing a fetch in progress are subject to change without notice.
### Possible Errors
- Any of the [universal error types][].
- `reportingUnsupported` - ([Reporting Mode][] servers only) This method is not available in Reporting Mode.
{% raw-partial file="/docs/_snippets/common-links.md" /%}

1
docs/references/http-websocket-apis/admin-api-methods/status-and-debugging-methods/validator_list_sites.md
View File

@@ -151,6 +151,5 @@ The `last_refresh_status` field can have the following values:
### Possible Errors
- Any of the [universal error types][].
- `reportingUnsupported` - ([Reporting Mode][] servers only) This method is not available in Reporting Mode.
{% raw-partial file="/docs/_snippets/common-links.md" /%}

1
docs/references/http-websocket-apis/admin-api-methods/status-and-debugging-methods/validators.md
View File

@@ -505,6 +505,5 @@ Each member of the `publisher_lists` array is a **Publisher List** object with t
### Possible Errors
- Any of the [universal error types][].
- `reportingUnsupported` - ([Reporting Mode][] servers only) This method is not available in Reporting Mode.
{% raw-partial file="/docs/_snippets/common-links.md" /%}

2
docs/references/http-websocket-apis/api-conventions/error-formatting.md
View File

@@ -110,7 +110,7 @@ For other errors that returned with HTTP status code 200 OK, the responses are f
All methods can potentially return any of the following values for the `error` code:
- `amendmentBlocked` - The server is [amendment blocked](../../../concepts/networks-and-servers/amendments.md#amendment-blocked-servers) and needs to be updated to the latest version to stay synced with the XRP Ledger network.
- `failedToForward` - ([Reporting Mode][] servers only) The server tried to forward this request to a P2P Mode server, but the connection failed.
- `failedToForward` - (Clio servers only) The server tried to forward this request to a `rippled` server, but the connection failed.
- `invalid_API_version` - The server does not support the [API version number](request-formatting.md#api-versioning) from the request.
- `jsonInvalid` - (WebSocket only) The request is not a proper JSON object.
- JSON-RPC returns a 400 Bad Request HTTP error in this case instead.

44
docs/references/http-websocket-apis/api-conventions/response-formatting.md
View File

@@ -1,6 +1,4 @@
---
html: response-formatting.html
parent: api-conventions.html
seo:
description: Standard response format, with examples, for the WebSocket, JSON-RPC, and Commandline interfaces.
---
@@ -10,16 +8,28 @@ Responses are formatted slightly differently based on whether the method is call
The fields of a successful response include:
| `Field` | Type | Description |
|:----------------|:---------|:------------------------------------------------|
| `id` | (Varies) | (WebSocket only) ID provided in the request that prompted this response |
| `status` | String | (WebSocket only) The value `success` indicates the request was successfully received and understood by the server. Some [client libraries](../../client-libraries.md) omit this field on success. |
| `result.status` | String | (JSON-RPC and Commandline) The value `success` indicates the request was successfully received and understood by the server. Some [client libraries](../../client-libraries.md) omit this field on success. |
| `type` | String | (WebSocket only) The value `response` indicates a direct response to an API request. [Asynchronous notifications](../public-api-methods/subscription-methods/subscribe.md) use a different value such as `ledgerClosed` or `transaction`. |
| `result` | Object | The result of the query; contents vary depending on the command. |
| `warning` | String | _(May be omitted)_ If this field is provided, the value is the string `load`. This means the client is approaching the [rate limiting](rate-limiting.md) threshold where the server will disconnect this client. <!-- STYLE_OVERRIDE: will --> |
| `warnings` | Array | _(May be omitted)_ If this field is provided, it contains one or more **Warnings Objects** with important warnings. For details, see [API Warnings](#api-warnings). |
| `forwarded` | Boolean | _(May be omitted)_ If `true`, this request and response have been forwarded from a [Reporting Mode][] server to a P2P Mode server (and back) because the request requires data that is not available in Reporting Mode. The default is `false`. |
{% tabs %}
{% tab label="WebSocket" %}
| Field | Type | Required? | Description |
|:----------------|:---------|:----------|-------------|
| `status` | String | Yes | The value `success` indicates the request was successfully received and understood by the server. Some [client libraries](../../client-libraries.md) omit this field on success. |
| `type` | String | Yes | The value `response` indicates a direct response to an API request. [Asynchronous notifications](../public-api-methods/subscription-methods/subscribe.md) use a different value such as `ledgerClosed` or `transaction`. |
| `result` | Object | Yes | The result of the query; contents vary depending on the API method. |
| `id` | (Varies) | No | Arbitrary ID provided by the request that prompted this response. Omitted if the request didn't specify an ID. |
| `warning` | String | No | If this field is provided, the value is the string `load`. This means the client is approaching the [rate limiting](rate-limiting.md) threshold where the server will disconnect this client. <!-- STYLE_OVERRIDE: will --> |
| `warnings` | Array | No | If this field is provided, it contains one or more **Warnings Objects** with important warnings. For details, see [API Warnings](#api-warnings). |
| `forwarded` | Boolean | No | If `true`, this request and response have been forwarded from a Clio server to a P2P Mode server (and back) because the request requires data that is not available from Clio. The default is `false`. |
{% /tab %}
{% tab label="JSON-RPC" %}
| Field | Type | Required? | Description |
|:----------------|:---------|:----------|-------------|
| `result` | Object | Yes | The result of the query; contents vary depending on the command. |
| `result.status` | String | Yes | The value `success` indicates the request was successfully received and understood by the server. Some [client libraries](../../client-libraries.md) omit this field on success. |
| `warning` | String | No | If this field is provided, the value is the string `load`. This means the client is approaching the [rate limiting](rate-limiting.md) threshold where the server will disconnect this client. <!-- STYLE_OVERRIDE: will --> |
| `warnings` | Array | No | If this field is provided, it contains one or more **Warnings Objects** with important warnings. For details, see [API Warnings](#api-warnings). |
| `forwarded` | Boolean | No | If `true`, this request and response have been forwarded from a Clio server to a P2P Mode server (and back) because the request requires data that is not available from Clio. The default is `false`. |
{% /tab %}
{% /tabs %}
## Example Successful Response
@@ -159,24 +169,24 @@ This warning indicates that the server is [amendment blocked](../../../concepts/
The server administrator must [upgrade `rippled`](../../../infrastructure/installation/index.md) to a version that supports the activated amendments.
### 1003. This is a reporting server
### 2001. This is a clio server
Example warning:
```json
"warnings": [
{
"id" : 1003,
"message" : "This is a reporting server. The default behavior of a reporting server is to only return validated data. If you are looking for not yet validated data, include \"ledger_index : current\" in your request, which will cause this server to forward the request to a p2p node. If the forward is successful the response will include \"forwarded\" : \"true\""
"id": 2001,
"message": "This is a clio server. clio only serves validated data. If you want to talk to rippled, include 'ledger_index':'current' in your request"
}
]
```
This warning indicates that the server answering the request is running [Reporting Mode][]. Certain API methods are not available or behave differently because Reporting Mode does not connect to the peer-to-peer network and does not track ledger data that has not yet been validated.
This warning indicates that the server answering the request a Clio server, which does not have direct access to the peer-to-peer network. Certain API methods behave differently or may have additional information, and requests that require non-validated data are forwarded to a peer-to-peer server.
It is generally safe to ignore this warning.
{% admonition type="warning" name="Caution" %}If you request ledger data without explicitly [specifying a ledger version][Specifying Ledgers], Reporting Mode uses the latest validated ledger by default instead of the current in-progress ledger.{% /admonition %}
{% admonition type="warning" name="Caution" %}If you request ledger data without explicitly [specifying a ledger version][Specifying Ledgers], Clio uses the latest validated ledger by default instead of the current in-progress ledger.{% /admonition %}
## See Also

3
docs/references/http-websocket-apis/peer-port-methods/peer-crawler.md
View File

@@ -1,6 +1,4 @@
---
html: peer-crawler.html
parent: peer-port-methods.html
seo:
description: Special API method for sharing network topology and status metrics.
labels:
@@ -44,7 +42,6 @@ Each member of the `overlay.active` array is an object with the following fields
| `Field` | Value | Description |
|:-------------|:-------------------------|:-----------------------------------|
| `complete_ledgers` | String | The range of [ledger versions](../../../concepts/networks-and-servers/ledger-history.md) this peer has available. |
| `complete_shards` | String | _(May be omitted)_ The range of [ledger history shards](../../../infrastructure/configuration/data-retention/history-sharding.md) this peer has available. |
| `ip` | String (IPv4 Address) | _(May be omitted)_ The IP address of this connected peer. Omitted if the peer is configured as a validator or a [private peer](../../../concepts/networks-and-servers/peer-protocol.md#private-peers). {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.2.1" %}Updated in: rippled 1.2.1{% /badge %} |
| `port` | String or Number | _(May be omitted)_ The port number on the peer server that serves RTXP. This will be a string if outbound and a number otherwise. Typically `51235`. Omitted if the peer is configured as a validator or a [private peer](../../../concepts/networks-and-servers/peer-protocol.md#private-peers). {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.2.1" %}Updated in: rippled 1.2.1{% /badge %} |
| `public_key` | String (Base-64 Encoded) | The public key of the ECDSA key pair used by this peer to sign RTXP messages. (This is the same data as the `pubkey_node` reported by the peer server's [server_info method][].) |

4
docs/references/http-websocket-apis/public-api-methods/account-methods/account_info.md
View File

@@ -1,6 +1,4 @@
---
html: account_info.html
parent: account-methods.html
seo:
description: Get basic data about an account.
labels:
@@ -63,7 +61,7 @@ The request contains the following parameters:
| `account` | String - [Address][] | Yes | The account to look up. {% badge href="https://github.com/XRPLF/rippled/releases/tag/1.11.0" %}Updated in: rippled 1.11.0{% /badge %} |
| `ledger_hash` | String | No | The unique hash of the ledger version to use. (See [Specifying Ledgers][]) |
| `ledger_index` | Number or String | No | The [ledger index][] of the ledger to use, or a shortcut string to choose a ledger automatically. (See [Specifying Ledgers][]) |
| `queue` | Boolean | No | If `true`, return stats about [queued transactions](../../../../concepts/transactions/transaction-queue.md) sent by this account. Can only be used when querying for the data from the current open ledger. Not available from servers in [Reporting Mode][]. |
| `queue` | Boolean | No | If `true`, return stats about [queued transactions](../../../../concepts/transactions/transaction-queue.md) sent by this account. Can only be used when querying for the data from the current open ledger. |
| `signer_lists` | Boolean | No | If `true`, return any [SignerList objects](../../../protocol/ledger-data/ledger-entry-types/signerlist.md) associated with this account. |
The following fields are deprecated and should not be provided: `ident`, `ledger`, `strict`.

4
docs/references/http-websocket-apis/public-api-methods/index.md
View File

@@ -72,9 +72,11 @@ Paths define a way for payments to flow through intermediary steps on their way
Payment channels are a tool for facilitating repeated, unidirectional payments, or temporary credit between two parties. Use these methods to work with payment channels.
* **[`channel_authorize`](payment-channel-methods/channel_authorize.md)** - Sign a claim for money from a payment channel.
* **[`channel_verify`](payment-channel-methods/channel_verify.md)** - Check a payment channel claim's signature.
By default, the following method is [admin-only](../admin-api-methods/index.md). It can be used as a public method if the server admin has [enabled public signing](../../../infrastructure/configuration/enable-public-signing.md).
* **[`channel_authorize`](payment-channel-methods/channel_authorize.md)** - Sign a claim for money from a payment channel.
## [Subscription Methods](subscription-methods/index.md)

3
docs/references/http-websocket-apis/public-api-methods/server-info-methods/feature.md
View File

@@ -1,6 +1,4 @@
---
html: feature.html
parent: server-info-methods.html
seo:
description: Get information about protocol amendments.
labels:
@@ -137,6 +135,5 @@ The response follows the [standard format][], with a successful result containin
- Any of the [universal error types][].
- `badFeature` - The `feature` specified was invalidly formatted, or the server does not know an amendment with that name.
- `noPermission` - The server does not have permission to run the specified command. For example, this can occur if the request includes admin-only fields that are not allowed, such as the `vetoed` request parameter.
- `reportingUnsupported` - ([Reporting Mode][] servers only) This method is not available in Reporting Mode.
{% raw-partial file="/docs/_snippets/common-links.md" /%}

3
docs/references/http-websocket-apis/public-api-methods/server-info-methods/manifest.md
View File

@@ -1,6 +1,4 @@
---
html: manifest.html
parent: server-info-methods.html
seo:
description: Look up the public information about a known validator.
labels:
@@ -150,6 +148,5 @@ If provided, the `details` object contains the following fields:
- Any of the [universal error types][].
- `invalidParams` - The `public_key` field was missing or specified incorrectly.
- `reportingUnsupported` - ([Reporting Mode][] servers only) This method is not available in Reporting Mode.
{% raw-partial file="/docs/_snippets/common-links.md" /%}

4
docs/references/protocol/data-types/basic-data-types.md
View File

@@ -99,11 +99,11 @@ Many API methods require you to specify an instance of the ledger, with the data
There is also a deprecated `ledger` parameter which accepts any of the above three formats. *Do not* use this parameter; it may be removed without further notice.
If you do not specify a ledger, the server decides which ledger to use to serve the request. By default, the server chooses the `current` (in-progress) ledger. In [Reporting Mode](../../../concepts/networks-and-servers/rippled-server-modes.md#reporting-mode), the server uses the most recent validated ledger instead. Do not provide more than one field specifying ledgers.
If you do not specify a ledger, the server decides which ledger to use to serve the request. By default, peer-to-peer servers chooses the `current` (in-progress) ledger. Clio servers use the most recent validated ledger instead. Do not provide more than one field specifying ledgers.
{% admonition type="info" name="Note" %}Do not rely on the default behavior for specifying a ledger; it is subject to change. Always specify a ledger version in the request if you can.{% /admonition %}
Reporting Mode does not record ledger data until it has been validated. If you make a request to a Reporting Mode server for the `current` or `closed` ledger, the server forwards the request to a P2P Mode server. If you request a ledger index or hash that is not validated, a Reporting Mode server responds with a `lgrNotFound` error.
Clio servers only record validated ledger data. If you make a request to a Clio server for the `current` or `closed` ledger, the server forwards the request to a P2P Mode server. If you request a ledger index or hash that is not validated, Clio responds with a `lgrNotFound` error.
## Specifying Currency Amounts

2
docs/tutorials/public-servers.md
View File

@@ -42,7 +42,7 @@ If you don't [run your own `rippled` server](../infrastructure/installation/inde
[¹]: #footnote-1
[²]: #footnote-2
<a id="footnote-1"></a>¹ Ripple's public servers are not for sustained or business use, and they may become unavailable at any time. For regular use, you should [run your own `rippled` server](../concepts/networks-and-servers/index.md) or contract someone you trust to do so. Ripple includes [Clio servers](../concepts/networks-and-servers/the-clio-server.md) (the successor to [Reporting Mode][]) in its public clusters.
<a id="footnote-1"></a>¹ Ripple's public servers are not for sustained or business use, and they may become unavailable at any time. For regular use, you should [run your own `rippled` server](../concepts/networks-and-servers/index.md) or contract someone you trust to do so. Ripple includes [Clio servers](../concepts/networks-and-servers/the-clio-server.md) in its public clusters.
<a id="footnote-2"></a>² `xrpl.ws` is an alias for `xrplcluster.com`. However, the `.ws` top-level domain's reliability may be unsuitable for production uses.

36
redirects.yaml
View File

@@ -1,3 +1,18 @@
/docs/infrastructure/configuration/data-retention/configure-history-sharding/:
to: /docs/infrastructure/configuration/data-retention/
type: 301
/docs/infrastructure/configuration/data-retention/history-sharding/:
to: /docs/infrastructure/configuration/data-retention/
type: 301
/docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/node_to_shard/:
to: /docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/
type: 301
/docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/crawl_shards/:
to: /docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/
type: 301
/docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/download_shard/:
to: /docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/
type: 301
/docs/infrastructure/installation/rippled-1-3-migration-instructions/:
to: /docs/infrastructure/installation/
type: 301
@@ -1325,10 +1340,10 @@ can_delete.html:
to: /docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/can_delete
type: 301
crawl_shards.html:
to: /docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/crawl_shards
to: /docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/
type: 301
download_shard.html:
to: /docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/download_shard
to: /docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/
type: 301
ledger_cleaner.html:
to: /docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/ledger_cleaner
@@ -1343,7 +1358,7 @@ logrotate.html:
to: /docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/logrotate
type: 301
node_to_shard.html:
to: /docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/node_to_shard
to: /docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/
type: 301
server-control-methods.html:
to: /docs/references/http-websocket-apis/admin-api-methods/server-control-methods/
@@ -2335,6 +2350,21 @@ code_of_conduct.ja:
type: 301
# Japanese
/ja/docs/infrastructure/configuration/data-retention/configure-history-sharding/:
to: /ja/docs/infrastructure/configuration/data-retention/
type: 301
/ja/docs/infrastructure/configuration/data-retention/history-sharding/:
to: /ja/docs/infrastructure/configuration/data-retention/
type: 301
/ja/docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/node_to_shard/:
to: /ja/docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/
type: 301
/ja/docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/crawl_shards/:
to: /ja/docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/
type: 301
/ja/docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/download_shard/:
to: /ja/docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/
type: 301
/ja/docs/infrastructure/installation/rippled-1-3-migration-instructions/:
to: /ja/docs/infrastructure/installation/
type: 301

5
sidebars.yaml
View File

@@ -593,13 +593,10 @@
expanded: false
items:
- page: docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/can_delete.md
- page: docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/crawl_shards.md
- page: docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/download_shard.md
- page: docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/ledger_cleaner.md
- page: docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/ledger_request.md
- page: docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/log_level.md
- page: docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/logrotate.md
- page: docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/node_to_shard.md
- page: docs/references/http-websocket-apis/admin-api-methods/server-control-methods/index.md
expanded: false
items:
@@ -667,8 +664,6 @@
- page: docs/infrastructure/configuration/data-retention/online-deletion.md
- page: docs/infrastructure/configuration/data-retention/configure-online-deletion.md
- page: docs/infrastructure/configuration/data-retention/configure-advisory-deletion.md
- page: docs/infrastructure/configuration/data-retention/history-sharding.md
- page: docs/infrastructure/configuration/data-retention/configure-history-sharding.md
- page: docs/infrastructure/configuration/peering/index.md
expanded: false
items: