Japanese translation: add all concepts

content/concepts/the-rippled-server/ledger-history/history-sharding.ja.md

@@ -0,0 +1,36 @@
+# 履歴シャーディング
+
+[導入: rippled 0.90.0][新規: rippled 0.90.0]
+
+稼働中のサーバーは、ネットワーク実行時に検知または取得したレジャーに関するデータを格納したデータベースを作成します。各`rippled`サーバーは、そのレジャーのデータをレジャーストアーに保存しますが、保存されたレジャー数が設定された容量制限を超えると、オンライン削除ロジックによりこれらのデータベースがローテーションされます。
+
+履歴シャーディングは、XRP Ledgerのトランザクション履歴をシャードと呼ばれるセグメントに分割し、XRP Ledgerネットワークのサーバー全体に分散します。シャードは、一連のレジャーです。`rippled`サーバーは、レジャーストアーとシャードストアーの両方にレジャーを同じ方法で保存します。
+
+履歴シャーディング機能を使用すると、個々の`rippled`サーバーが履歴データの保存する役割を担い、すべての履歴（数テラバイト）を保存する必要がなくなります。シャードストアーはレジャーストアーに代わるものではありませんが、XRP Ledgerネットワーク上の分散レジャー履歴への信頼性の高いパスを実現します。
+
+[![XRP Ledgerネットワーク: レジャーストアーとシャードストアーの図](img/xrp-ledger-network-ledger-store-and-shard-store.ja.png)](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.html)
+- [download_shardメソッド][]
+- [crawl_shardsメソッド][]
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}			
+{% include '_snippets/tx-type-links.md' %}			
+{% include '_snippets/rippled_versions.md' %}

content/concepts/the-rippled-server/ledger-history/ledger-history.ja.md

@@ -0,0 +1,56 @@
+# レジャー履歴
+
+[コンセンサスプロセス](intro-to-consensus.html)により、[検証済みレジャーバージョン](ledgers.html)のチェーンが作成されます。各バージョンは、以前のバージョンにトランザクションのセットを適用して生成されます。各`rippled`サーバーには、レジャーバージョンとトランザクション履歴がローカルに保管されます。サーバーに保管されるトランザクション履歴の量は、サーバーがオンラインであった期間と、サーバーが取得し、保持する履歴量の設定に応じて異なります。
+
+ピアツーピアのXRP Ledgerネットワーク内のサーバーは、コンセンサスプロセスの一環としてトランザクションやその他のデータを相互に共有します。各サーバーは個別に新しいレジャーバージョンを作成し、その結果を信頼できるバリデータと比較して、整合性を維持します。（信頼できるバリデータのコンセンサスがサーバーの結果と一致しない場合は、サーバーがピアから必要なデータを取得して整合性を維持します。）サーバーはピアから古いデータをダウンロードして、利用可能な履歴のギャップを埋めることができます。レジャーはデータの暗号[ハッシュ](basic-data-types.html#ハッシュ)を使用した構造となっているため、すべてのサーバーがデータの整合性の検証を行えます。
+
+## データベース
+
+サーバーはレジャーの状態データとトランザクションを _レジャーストアー_ と呼ばれるkey-valueストアで保持します。また、`rippled`にはいくつかのSQLiteデータベースファイルが維持されているので、トランザクション履歴などへより柔軟にアクセスし、特定の設定変更を追跡できます。
+
+一般に、`rippled`サーバーが稼働していないときにはそのサーバーのすべてのデータベースファイルを安全に削除できます。（たとえばサーバーのストレージ設定を変更する場合や、Test Netから本番環境ネットワークに切り替える場合に、このような削除が必要となることがあります。）
+
+## 利用可能な履歴
+
+設計上、XRP Ledgerのすべてのデータとトランザクションは公開されており、誰でもすべてのデータを検索または照会できます。ただし、サーバーが検索できるデータは、そのサーバーがローカルで使用できるデータに限られます。サーバーで利用できないレジャーバージョンやトランザクションを照会しようとすると、そのデータが見つからないという応答がサーバーから返されます。必要な履歴を保持している他のサーバーに対して同じ照会を実行すると、正常な応答が返されます。XRP Ledgerデータを使用する企業では、サーバーで利用可能な履歴の量に注意してください。
+
+[server_infoメソッド][]は、サーバーで利用可能なレジャーバージョンの数を`complete_ledgers`フィールドで報告します。
+
+## 履歴の取得
+
+`rippled`サーバーは起動されると、最優先で最新の検証済みレジャーの完全なコピーを取得します。その後、サーバーは常にレジャーの進行状況を把握します。レジャー履歴を埋め戻すように設定されているサーバーでは、レジャー履歴が設定量に達するまで埋め戻されます。この設定量は、オンライン削除による削除が開始されるカットオフ値以下でなければなりません。
+
+サーバーは同期される前から履歴の埋め戻しを行い、同期後にも収集した履歴のギャップを埋めることができます。（レジャー履歴のギャップは、サーバーの使用率が一時的に高くなりネットワークと同期をとることができない場合、ネットワークとの接続が失われた場合、またはその他の一時的な問題の影響を受けた場合に発生する可能性があります。）履歴を埋め戻すため、サーバーはピア`rippled`サーバーにデータを要求します。サーバーが埋め戻す量は、`[ledger_history]`設定で定義されます。
+
+XRP Ledgerは、コンテンツの一意のハッシュを使用して（さまざまなレベルの）データを識別します。XRP Ledgerの状態データには、レジャーの履歴の概要が[LedgerHashesオブジェクトタイプ](ledgerhashes.html)の形式で含まれています。サーバーはLedgerHashesオブジェクトを使用して取得するレジャーバージョンを認識し、受信するレジャーデータが正しく完全であることを確認します。
+
+履歴の埋め戻しは、サーバーでは最も優先度の低い処理の1つであるため、サーバーの使用率が高い場合やハードウェアとネットワークのスペックが十分ではない場合には、欠落している履歴を埋めるのに時間がかかることがあります。推奨されるハードウェアスペックについては、[容量の計画](capacity-planning.html)を参照してください。履歴の埋め戻しでは、サーバーのダイレクトピアの1つ以上に当該の履歴が保持されている必要もあります。 <!--{# TODO: link some info for managing your peer connections when that exists #}-->
+
+### 指示による削除の使用
+
+[オンライン削除](online-deletion.html)と指示による削除の両方が有効な場合、サーバーでは、まだ削除が許可されていない最も古いレジャーまでのデータが自動的に埋め戻されます。これにより、`[ledger_history]`設定と`online_delete`設定で構成されているレジャーバージョンの数よりも多いデータが取得されることがあります。[can_deleteメソッド][]を実行すると、削除可能なレジャーバージョンがサーバーに通知されます。
+
+
+## すべての履歴
+
+XRP Ledgerネットワーク内の一部のサーバーは、「すべての履歴が記録される」サーバーとして設定されています。これらのサーバーは、使用可能なすべてのXRP Ledgerの履歴を収集しますが、**オンライン削除は使用しません**。このため他の追跡サーバーよりもかなり多くのディスク容量が必要です。
+
+Rippleは、`s2.ripple.com`ですべての履歴が記録される一連の公開サーバーを公開サービスとして提供しています。このサービスは、より大きなXRPコミュニティーのために提供されています。Rippleは、サーバーを悪用するユーザーや、公平な量を超えるサーバーのリソースを使用するユーザーをブロックする権利を留保しています。
+
+**ヒント:** 一部の暗号資産ネットワークとは異なり、XRP Ledgerのサーバーは、現在の状態を認識して最新のトランザクションを把握するのにすべての履歴を必要としません。
+
+すべての履歴の設定については、[完全な履歴の設定](configure-full-history.html)を参照してください。
+
+## 履歴シャーディング
+
+XRP Ledgerのすべての履歴を1台の高価なマシンに保管する代わりに、複数のサーバーがレジャー履歴の一部分を保管するように構成できます。これは[履歴シャーディング](history-sharding.html)機能によって実現します。一定範囲のレジャー履歴が _シャードストアー_ という個別の保管領域に保管されます。ピアサーバーから（上記の[履歴の取得](#履歴の取得)で説明したとおり）特定のデータが要求されると、サーバーはレジャーストアーまたはシャードストアーのデータを使用して応答できます。
+
+オンライン削除ではシャードストアーのデータは削除**されません**。ただし、32768個以上のレジャーバージョンをサーバーのレジャーストアーに保持するようにオンライン削除が設定されていれば、レジャーストアーからデータが自動的に削除される前に、サーバーはレジャーストアーからシャードストアーにすべてのシャードをコピーできます。
+
+詳細は、[履歴シャーディングの設定](configure-history-sharding.html)を参照してください。
+
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}
+{% include '_snippets/tx-type-links.md' %}
+{% include '_snippets/rippled_versions.md' %}

content/concepts/the-rippled-server/ledger-history/online-deletion.ja.md

@@ -0,0 +1,122 @@
+# オンライン削除
+[[ソース]<br/>](https://github.com/ripple/rippled/blob/master/src/ripple/app/misc/SHAMapStoreImp.cpp "Source")
+
+オンライン削除機能により、`rippled`サーバーはレジャーの古いバージョンのローカルコピーを削除できます。これにより、時間とともにディスク使用量が急増しないようにできます。デフォルトの構成ファイルにはオンライン削除の自動実行が設定されていますが、指示があった場合にのみオンライン削除を実行するようにも設定できます。[新規: rippled 0.27.0][]
+
+サーバーは、レジャーおよびそのすべての残高と設定を、常に完全かつ _最新_ の状態に維持します。削除されるデータには、保存されている履歴よりも古いレジャー状態の古いトランザクションやバージョンがあります。
+
+デフォルトの構成ファイルは、`rippled`サーバーが2000の最新レジャーバージョンを保持し、古いデータを自動的に削除するように設定されています。
+
+**ヒント:** オンライン削除を使用しても、同一期間のレジャーデータを保管するのに必要なディスク容量は時間の経過とともに増加します。これは、個々のレジャーバージョンのサイズが時間とともに増加する傾向にあるためです。蓄積データが増加するペースは、古いレジャーを削除しない場合に比べると、非常にゆっくりとしています。必要なディスク容量に関する詳細は、[容量の計画](capacity-planning.html)を参照してください。
+
+
+## 背景
+
+`rippled`サーバーでは[レジャー履歴](ledger-history.html)がその _レジャーストアー_ に保管されます。このデータは時間とともに蓄積されます。
+
+レジャーストアー内ではレジャーデータの「重複排除」が行われます。つまり、バージョン間で変更されていないデータは1回だけ保存されます。レジャーストアーのレコード自体には、レコードが記録されているレジャーバージョンの記載はありません。オンライン削除処理において、古いレジャーバージョンでのみ使用されるレコードが特定されます。この処理には時間がかかり、またディスクI/Oとアプリケーションキャッシュに影響するため、レジャーを閉鎖するたびに古いデータを削除することは現実的ではありません。
+
+
+## オンライン削除の動作
+
+オンライン削除の設定では、`rippled`サーバーがレジャーストアーで使用可能な状態で維持するレジャーバージョンの数が設定されます。ただし、指定される数は目安であり、厳格に適用されるものではありません。
+
+- サーバーでは、設定された数のレジャーバージョンよりも新しいデータが削除されることはありませんが、長期にわたってサーバーが稼働していない場合や、ネットワークとの同期が失われた場合には、サーバーに含まれるレジャーバージョンの数が使用可能な数よりも少ないことがあります。（サーバーは一部の履歴の埋め戻しを試みます。詳細は、[履歴の取得](ledger-history.html#履歴の取得)を参照してください。）
+- オンライン削除の自動実行が設定されている場合、設定されているレジャーバージョンの数の2倍を超える数まで保存できる可能性があります。（オンライン削除を実行するたびに、保管されるレジャーバージョンの数が削減され、設定数に近くなります。）
+
+    ＰＣサーバーがビジーのためオンライン削除が遅延すると、レジャーバージョンが蓄積し続けることがあります。正常に動作している場合には、サーバー内のレジャーバージョン数が設定された数の2倍に達した時点でオンライン削除が開始されますが、さらにいくつかのレジャーバージョンが蓄積するまではオンライン削除が完了しないことがあります。
+
+- 指示による削除が有効な場合、管理者が[can_deleteメソッド][]を呼び出すまで、サーバーが取得および作成したすべてのレジャーバージョンがサーバーに保存されます。
+
+    サーバーに保存されるデータ量は、[can_delete][can_deleteメソッド]を呼び出す頻度と、`online_delete`設定に指定されている期間の長さに応じて異なります。
+
+    - `online_delete`の間隔よりも頻繁に`can_delete`を呼び出す場合、サーバーには最大で **`online_delete`の値の2倍** にほぼ相当するレジャーバージョンが保存されます。（削除後には、この数はほぼ`online_delete`の値まで減少します。）
+
+        たとえば`now`値を指定した`can_delete`を1日1回呼び出し、`online_delete`に値50,000を指定している場合、削除実行前のサーバーには通常、最大100,000のレジャーバージョンが蓄積されます。削除実行後は、少なくとも50,000のレジャーバージョン（約 2日分）がサーバーに保持されます。この設定では、約1回おきに`can_delete`を呼び出しした場合、変更が生じません。これは、削除するのに十分な数のレジャーバージョンがサーバーにないためです。
+
+    - `online_delete`の間隔 _よりも少ない頻度で_ `can_delete`を呼び出す場合、最大で **`can_delete`呼び出しの間隔のほぼ2倍** の期間にわたりレジャーバージョンがサーバーに保管されます。（削除後には、この数は約1間隔分のデータまで減少します。）
+
+        たとえば`now`値を指定した`can_delete`を1日1回呼び出し、`online_delete`値に2000を指定している場合、サーバーでは通常、削除が実行されるまでに最大で2日間分のレジャーバージョンが保管されます。削除の実行後は、サーバーには約1日分のレジャーバージョン（約25,000）が保持されますが、このレジャーバージョンの数が2000を下回ることはありません。
+
+
+オンライン削除が有効であり、自動的に実行される場合（つまり指示による削除が無効な場合）、保管されるレジャーデータの量は、最低でもサーバーに設定された保持レジャーバージョン数に相当し、最大でその約2倍です。
+
+オンライン削除が実行されても、ディスク上のSQLiteデータベースファイルのサイズは減少しません。これらのファイルの中に新しいデータを入れるのに再利用できるスペースが確保されるだけです。オンライン削除によって、レジャーストアーが含まれるRocksDB または NuDB データベースファイルのサイズは _減少します_ 。
+
+サーバーでは、削除範囲を決定する際に検証済みレジャーバージョンの数だけがカウントされます。（ローカルネットワーク接続が停止していたか、グローバルXRP Ledgerネットワークがコンセンサスに達しなかったことが原因で）サーバーが新しいレジャーバージョンを検証できない例外的な状況にある場合、ネットワークが復旧した際に迅速に回復できるように、`rippled`は引き続きレジャーを閉鎖します。この場合、サーバーには未検証の閉鎖済みレジャーが多数蓄積されます。このような未検証レジャーは、オンライン削除の実行までにサーバーに保持される _検証済み_ レジャーの数には影響しません。
+
+### オンライン削除の中断
+
+[サーバーの状態](rippled-server-states.html)が`full`より優先順位の低い状態になると、オンライン削除は自動的に停止します。この場合、サーバーはプレフィクス`SHAMapStore::WRN`が付いたログメッセージを書き込みます。サーバーは完全に同期された後、次の検証済みレジャーバージョン以降からオンライン削除の再開を試みます。
+
+サーバーを停止した場合や、オンライン削除の実行中にサーバーがクラッシュした場合には、サーバーが再起動し、完全に同期されれば、オンライン削除が再開されます。
+
+オンライン削除を一時的に無効にするには、引数`never`を指定した[can_deleteメソッド][]を使用できます。この変更は、[can_delete][can_delete method] をもう一度呼び出してオンライン削除を再度有効にするまで保持されます。オンライン削除の実行時点の制御についての詳細は、[指示による削除](#指示による削除)を参照してください。
+
+
+## 設定
+
+オンライン削除に関連する設定は以下のとおりです。
+
+- **`online_delete`** - 維持する検証済みレジャーバージョンの数を指定します。サーバーは、この数よりも古いレジャーバージョンをすべて定期的に削除します。数を指定しなければ、レジャーは削除されません。
+
+    デフォルトの構成ファイルでは、この値は2000に設定されています。この値に256未満の数は設定はできません。これは、[手数料投票](fee-voting.html)や[Amendmentプロセス](amendments.html#amendmentプロセス)などのイベントで一度に更新されるレジャーの数が256であるためです。
+
+    **注意:**`online_delete`を無効にして`rippled`を実行し、その後`online_delete`を有効にしてサーバーを再起動すると、`online_delete`が無効の間にサーバーがダウンロードした既存のレジャー履歴は無視されますが、削除されません。ディスク容量を節約するには、`online_delete`設定の変更後にサーバーを再起動する前に、既存の履歴を削除します。
+
+- **`[ledger_history]`** - 検証済みレジャーの数（`online_delete`の値以下）を指定します。サーバーの検証済みレジャーバージョンの数がこの数よりも少ない場合、ピアからデータを取得してバージョンを埋め戻す操作が試行されます。
+
+    この設定のデフォルト値はレジャー256個です。
+
+    次の図は、`online_delete`設定と`ledger_history`設定の関係を示します。
+
+    ![`online_delete`より古いレジャーは自動的に削除されます。`ledger_history`よりも新しいレジャーは埋め戻されます。その間に位置するレジャーは、使用可能な場合は保持されますが、埋め戻しは行われません](img/online_delete-vs-ledger_history.ja.png)
+
+- **`advisory_delete`** - 有効な場合、オンライン削除は自動的にスケジュールされません。代わりに管理者が手動でオンライン削除をトリガーする必要があります。無効にするには値`0`を使用し、有効にするには`1`を使用します。
+
+    この設定はデフォルトで無効になっています。
+
+- **`[fetch_depth]`** - 検証済みレジャーバージョンの数を指定します。サーバーは、指定されている数のレジャーバージョンよりも古い履歴データに対するピアからの取得要求を受け入れません。使用可能なすべてのデータをピアに提供するには、値`full`を指定します。
+
+    `fetch_depth`のデフォルトは`full`です（使用可能なすべてのデータを提供します）。
+
+    `fetch_depth`設定と`online_delete`設定の両方が指定されている場合、`fetch_depth`には`online_delete`よりも大きな値を設定できません。`fetch_depth`に大きな値が設定されている場合、サーバーは`fetch_depth`の値が`online_delete`と同等であるものとして扱います。
+
+    次の図は、fetch_depthの仕組みを示します。
+
+    ![fetch_depthよりも古いレジャーバージョンはピアに提供されません](img/fetch_depth.ja.png)
+
+さまざまな量の履歴の保管に必要なディスク容量の見積もりについては、[容量の計画](capacity-planning.html#ディスク容量)を参照してください。
+
+### 指示による削除
+
+デフォルトの構成ファイルでは、オンライン削除が定期的に自動で実行されるように設定されています。構成ファイルに`online_delete`間隔が指定されていない場合、オンライン削除は実行されません。構成ファイルで`advisory_delete`設定が有効になっている場合、オンライン削除は、管理者が[can_deleteメソッド][]を使用してオンライン削除をトリガーしたときにのみ実行されます。
+
+指示による削除とスケジュール済みジョブを使用すれば、閉鎖済みレジャーバージョン数の代わりに、時刻に基づいて自動削除をトリガーできます。サーバーの使用率が高い場合、オンライン削除によって負荷が追加されるとサーバーの処理が遅延し、コンセンサスネットワークと一時的に非同期になることがあります。この場合は、指示による削除を使用して、オンライン削除をオフピーク期間にのみ実行するようにスケジュールできます。
+
+指示による削除はその他の目的でも使用できます。たとえば、トランザクションデータを削除する前に、そのデータが別のサーバーにバックアップされていることを手動で確認できます。あるいは、トランザクションデータを削除する前に、別のタスクによるそのデータの処理が完了していることを手動で確認できます。
+
+`can_delete` API メソッドは、構成ファイルで `advisory_delete` が有効になっている場合は、一般的な自動削除または特定のレジャーバージョンまでの自動削除を有効または無効にできます。`rippled`サーバーの再起動前に構成ファイルで`advisory_delete`を無効にしている場合を除き、これらの設定はサーバーを再起動しても維持されます。
+
+
+## 仕組み
+
+オンライン削除では2つのデータベースが作成されます。このため、「古い」読み取り専用データベースと、書き込み可能な「現行」データベースが常に存在します。`rippled`サーバーはいずれかのデータベースからオブジェクトを読み取ることができます。このため、現行レジャーバージョンにはいずれかのデータベースのオブジェクトが含まれます。レジャーバージョン間でレジャー内のオブジェクトに変更がない場合、そのオブジェクトのコピーが1つだけデータベースに残ります。これにより、オブジェクトのコピーが重複してサーバーに保存されることはありません。レジャーバージョンの更新によりオブジェクトが変更されると、サーバーは変更されたオブジェクトを「新しい」データベースに保存し、古いバージョンのオブジェクト（古いレジャーバージョンで使用されているオブジェクト）は「古い」データベースに残ります。
+
+オンライン削除を実行する場合、サーバーはまず、最も古いレジャーバージョンの中から保持するものを確認し、そのレジャーバージョンのすべてのオブジェクトを読み取り専用の「古い」データベースから「現行」データベースにコピーします。これにより、「現行」データベースには、選択したレジャーバージョンとそれ以降のすべての新しいバージョンで使用されるオブジェクトがすべて含まれることになります。次に、サーバーは「古い」データベースを削除し、既存の「現行」データベースを「古い」読み取り専用データベースにします。これ以降、サーバーは新しい「現行」データベースを始動し、新たな変更をすべてこのデータベースに保存します。
+
+![オンライン削除で2つのデータベースがどのように使用されるかを示す図](img/online-deletion-process.ja.png)
+
+## 関連項目
+
+- [容量の計画](capacity-planning.html)
+- [can_deleteメソッド][] - APIリファレンス資料
+- [オンライン削除の設定](configure-online-deletion.html)
+- [指示による削除の設定](configure-advisory-deletion.html)
+- [完全な履歴の設定](configure-full-history.html)
+
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}
+{% include '_snippets/tx-type-links.md' %}
+{% include '_snippets/rippled_versions.md' %}