Remove Reporting Mode & History Shards docs

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

@@ -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][]

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

@@ -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:

@l10n/ja/docs/_snippets/common-links.md

@@ -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

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

@@ -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メソッド][]

@l10n/ja/docs/infrastructure/commandline-usage.md

@@ -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 %}。
 
 ## スタンドアロンモードのオプション
 

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

@@ -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)すれば、レジャー履歴のグループをランダムに選択して保管できます。
 
 ## 構成手順