mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-19 11:15:49 +00:00
[JA] replaceサーバー to サーバ
This commit is contained in:
tequ
@@ -4,20 +4,20 @@ parent: data-retention.html
|
||||
seo:
|
||||
description: 指示による削除を使用して、新しい履歴ができたときではなく、スケジュールで古いレジャー履歴を削除します。
|
||||
labels:
|
||||
- コアサーバー
|
||||
- コアサーバ
|
||||
- データ保持
|
||||
---
|
||||
# 指示による削除の設定
|
||||
|
||||
デフォルトの構成ファイルは、新しいレジャーバージョンが利用可能になると`rippled`が古いXRP Ledgerの履歴を自動的に削除するように設定されています。サーバーがピーク時にハードウェアリソースの大部分を使用する場合は、オフピーク時に実行するようスケジュールされたコマンドからの指示があった場合にのみ、レジャーを削除するようにサーバーを設定できます。これにより、オンライン削除がサーバーのパフォーマンスに及ぼす影響はほとんどなくなります。
|
||||
デフォルトの構成ファイルは、新しいレジャーバージョンが利用可能になると`rippled`が古いXRP Ledgerの履歴を自動的に削除するように設定されています。サーバがピーク時にハードウェアリソースの大部分を使用する場合は、オフピーク時に実行するようスケジュールされたコマンドからの指示があった場合にのみ、レジャーを削除するようにサーバを設定できます。これにより、オンライン削除がサーバのパフォーマンスに及ぼす影響はほとんどなくなります。
|
||||
|
||||
## 前提条件
|
||||
|
||||
このチュートリアルでは、ご使用のサーバーが以下の条件を満たしていることを前提としています。
|
||||
このチュートリアルでは、ご使用のサーバが以下の条件を満たしていることを前提としています。
|
||||
|
||||
- サポートされているオペレーティングシステムを使用している。Ubuntu Linux、Red Hat Enterprise Linux（RHEL）、CentOS
|
||||
|
||||
- `rippled`サーバーがすでに[インストール](../../installation/index.md)されており、[オンライン削除](online-deletion.md)が有効になっている。
|
||||
- `rippled`サーバがすでに[インストール](../../installation/index.md)されており、[オンライン削除](online-deletion.md)が有効になっている。
|
||||
|
||||
デフォルトの構成ファイルは、レジャーバージョンが2000個を超えるとオンライン削除を実行するよう設定されています。
|
||||
|
||||
@@ -31,11 +31,11 @@ labels:
|
||||
$ sudo yum install cronie
|
||||
```
|
||||
|
||||
- 選択した量の履歴をレジャーストアーに保管するのに十分なディスク容量がサーバーにある。
|
||||
- 選択した量の履歴をレジャーストアーに保管するのに十分なディスク容量がサーバにある。
|
||||
|
||||
各種設定で必要なストレージの容量についての詳細は、[容量計画](../../installation/capacity-planning.md)を参照してください。指示による削除が有効な場合、削除が実行されるまでにサーバーに蓄積可能な履歴の最大数は、`online_delete`設定で設定したレジャーバージョン数と、オンライン削除の指示の間隔を**加算**したものに相当します。
|
||||
各種設定で必要なストレージの容量についての詳細は、[容量計画](../../installation/capacity-planning.md)を参照してください。指示による削除が有効な場合、削除が実行されるまでにサーバに蓄積可能な履歴の最大数は、`online_delete`設定で設定したレジャーバージョン数と、オンライン削除の指示の間隔を**加算**したものに相当します。
|
||||
|
||||
- サーバーの使用率が最も低い時間帯を把握している。
|
||||
- サーバの使用率が最も低い時間帯を把握している。
|
||||
|
||||
## 設定手順
|
||||
|
||||
@@ -55,7 +55,7 @@ labels:
|
||||
|
||||
{% partial file="/@i18n/ja/docs/_snippets/conf-file-location.md" /%}
|
||||
|
||||
2. サーバーに対してオンライン削除を指示する[can_deleteメソッド][]の実行をテストします。
|
||||
2. サーバに対してオンライン削除を指示する[can_deleteメソッド][]の実行をテストします。
|
||||
|
||||
このコマンドの実行には[`rippled`コマンドラインインターフェイス](../../../tutorials/http-websocket-apis/build-apps/get-started.md#コマンドライン)を使用できます。例:
|
||||
|
||||
@@ -63,7 +63,7 @@ labels:
|
||||
$ rippled --conf=/etc/opt/ripple/rippled.cfg can_delete now
|
||||
```
|
||||
|
||||
レスポンスは、サーバーがそのレジャーストアーから削除するレジャーインデックスの最大値を示します。たとえば、以下のメッセージはレジャーインデックス43633667以下のレジャーバージョンを削除できることを示します。
|
||||
レスポンスは、サーバがそのレジャーストアーから削除するレジャーインデックスの最大値を示します。たとえば、以下のメッセージはレジャーインデックス43633667以下のレジャーバージョンを削除できることを示します。
|
||||
|
||||
```
|
||||
{
|
||||
@@ -74,7 +74,7 @@ labels:
|
||||
}
|
||||
```
|
||||
|
||||
サーバー内の _新しい_ 検証済みレジャーバージョンの数が、`online_delete`の設定以上となった場合にのみ、レジャーバージョンが削除されます。
|
||||
サーバ内の _新しい_ 検証済みレジャーバージョンの数が、`online_delete`の設定以上となった場合にのみ、レジャーバージョンが削除されます。
|
||||
|
||||
3. 前のステップでテストした`can_delete`メソッドを、予定した時刻に実行するように`cron`デーモンを設定します。
|
||||
|
||||
@@ -84,15 +84,15 @@ labels:
|
||||
$ crontab -e
|
||||
```
|
||||
|
||||
以下の例では、サーバー時刻で毎日1:05 AMにサーバーが削除を実行するように設定されています。
|
||||
以下の例では、サーバ時刻で毎日1:05 AMにサーバが削除を実行するように設定されています。
|
||||
|
||||
```
|
||||
5 1 * * * rippled --conf /etc/opt/ripple/rippled.cfg can_delete now
|
||||
```
|
||||
|
||||
サーバーで設定されているタイムゾーンに基づいてコマンドが実行されるようにスケジュールしてください。
|
||||
サーバで設定されているタイムゾーンに基づいてコマンドが実行されるようにスケジュールしてください。
|
||||
|
||||
**ヒント:**`advisory_delete`を無効にしている場合は、`cron`ジョブをオンラインで実行するようにスケジュールする必要はありません。この場合、サーバーの最も古いレジャーバージョンと現行の検証済みレジャーバージョンの差が`online_delete`の値以上である場合に、`rippled`によりオンライン削除が実行されます。
|
||||
**ヒント:**`advisory_delete`を無効にしている場合は、`cron`ジョブをオンラインで実行するようにスケジュールする必要はありません。この場合、サーバの最も古いレジャーバージョンと現行の検証済みレジャーバージョンの差が`online_delete`の値以上である場合に、`rippled`によりオンライン削除が実行されます。
|
||||
|
||||
4. `rippled`サービスを起動（または再起動）します。
|
||||
|
||||
@@ -100,19 +100,19 @@ labels:
|
||||
$ sudo systemctl restart rippled
|
||||
```
|
||||
|
||||
5. [server_infoメソッド][]を使用してサーバーの`complete_ledgers`範囲を定期的に調べ、レジャーがスケジュール通りに削除されていることを確認します。
|
||||
5. [server_infoメソッド][]を使用してサーバの`complete_ledgers`範囲を定期的に調べ、レジャーがスケジュール通りに削除されていることを確認します。
|
||||
|
||||
オンライン削除の実行後には`complete_ledgers`の最小レジャーインデックスが増加します。
|
||||
|
||||
サーバーの使用率の状況と、一度に削除する履歴の量によっては、削除が完了するまでに数分間かかることがあります。
|
||||
サーバの使用率の状況と、一度に削除する履歴の量によっては、削除が完了するまでに数分間かかることがあります。
|
||||
|
||||
## トラブルシューティング
|
||||
|
||||
オンライン削除の設定後にオンライン削除が実行されていないようである場合は、以下を試してください。
|
||||
|
||||
- `cron`ジョブを設定したユーザーに、コマンドラインクライアントとして`rippled`サーバーを実行できる権限があることを確認します。
|
||||
- `cron`ジョブを設定したユーザーに、コマンドラインクライアントとして`rippled`サーバを実行できる権限があることを確認します。
|
||||
- cronジョブの構文とこのジョブの実行予定時刻を確認します。
|
||||
- `rippled`実行可能ファイルが`cron`設定で指定したパスで使用可能であることを確認します。必要に応じて実行可能ファイルの絶対パス（`/opt/ripple/bin/rippled`など）を指定します。
|
||||
- `rippled`ログで、`SHAMapStore::WRN`で始まるメッセージを調べます。このメッセージが出力されている場合、サーバーがネットワークと同期していない状態になったために[オンライン削除が中断されている](online-deletion.md#オンライン削除の中断)可能性があります。
|
||||
- `rippled`ログで、`SHAMapStore::WRN`で始まるメッセージを調べます。このメッセージが出力されている場合、サーバがネットワークと同期していない状態になったために[オンライン削除が中断されている](online-deletion.md#オンライン削除の中断)可能性があります。
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -2,36 +2,36 @@
|
||||
html: configure-full-history.html
|
||||
parent: data-retention.html
|
||||
seo:
|
||||
description: 完全履歴サーバーは、運用のコストは高いものの、XRP Ledgerでこれまでに発生したすべてのトランザクションの記録を提供します。
|
||||
description: 完全履歴サーバは、運用のコストは高いものの、XRP Ledgerでこれまでに発生したすべてのトランザクションの記録を提供します。
|
||||
labels:
|
||||
- コアサーバー
|
||||
- コアサーバ
|
||||
- データ保持
|
||||
---
|
||||
# 全履歴の設定
|
||||
|
||||
デフォルトの構成では、新しいレジャーバージョンが利用可能になると`rippled`サーバーが古いXRP Ledger状態とトランザクションの履歴を自動的に削除するように設定されています。ほとんどのサーバーでは現在の状態を把握してトランザクションを処理するのに古い履歴は不要なため、この設定で十分です。ただし、一部のサーバーが可能な限り多くのXRP Ledgerの履歴を提供する場合、これはネットワークにとって有用であることがあります。
|
||||
デフォルトの構成では、新しいレジャーバージョンが利用可能になると`rippled`サーバが古いXRP Ledger状態とトランザクションの履歴を自動的に削除するように設定されています。ほとんどのサーバでは現在の状態を把握してトランザクションを処理するのに古い履歴は不要なため、この設定で十分です。ただし、一部のサーバが可能な限り多くのXRP Ledgerの履歴を提供する場合、これはネットワークにとって有用であることがあります。
|
||||
|
||||
## 警告
|
||||
|
||||
全履歴の保存にはコストがかかります。2018年12月11日の時点では、XRP Ledgerの全履歴が専有するディスク容量は約**9テラバイト**にのぼります。適切なサーバーパフォーマンスのためには、全履歴を高速なソリッドステートディスクドライブに保存する必要があります。このような大量のソリッドステートストレージは安価ではなく、また保管する必要のある履歴の合計量は毎日約12 GBずつ増加します。
|
||||
全履歴の保存にはコストがかかります。2018年12月11日の時点では、XRP Ledgerの全履歴が専有するディスク容量は約**9テラバイト**にのぼります。適切なサーバパフォーマンスのためには、全履歴を高速なソリッドステートディスクドライブに保存する必要があります。このような大量のソリッドステートストレージは安価ではなく、また保管する必要のある履歴の合計量は毎日約12 GBずつ増加します。
|
||||
|
||||
ピアツーピアネットワークから全履歴を取得するには非常に長い時間がかかり（数か月）、また古い履歴を取得し、かつレジャーの新たな進展を常に把握するには、システムリソースとネットワークリソースを十分に備えたサーバーが必要となります。レジャー履歴の取得を迅速に開始するため、すでに大量の履歴をダウンロードしている別のサーバーオペレーターを探すこともできます。このようなオペレーターは、データベースダンプを提供できるか、または少なくとも、履歴の取得に十分な時間、あなたのサーバーをオペレーターのサーバーに明示的にピア接続することができます。サーバーはファイルからレジャー履歴を読み込み、インポートする履歴レジャーの整合性を検証できます。
|
||||
ピアツーピアネットワークから全履歴を取得するには非常に長い時間がかかり（数か月）、また古い履歴を取得し、かつレジャーの新たな進展を常に把握するには、システムリソースとネットワークリソースを十分に備えたサーバが必要となります。レジャー履歴の取得を迅速に開始するため、すでに大量の履歴をダウンロードしている別のサーバオペレーターを探すこともできます。このようなオペレーターは、データベースダンプを提供できるか、または少なくとも、履歴の取得に十分な時間、あなたのサーバをオペレーターのサーバに明示的にピア接続することができます。サーバはファイルからレジャー履歴を読み込み、インポートする履歴レジャーの整合性を検証できます。
|
||||
|
||||
ネットワークへの参加、トランザクションの検証、またはネットワークの現在の状態の確認には、全履歴を記録するサーバーは必要ありません。全履歴が有用となるのは、過去に発生したトランザクションの結果や、過去の特定の時点におけるレジャーの状態を確認する場合だけです。このような情報を取得するには、必要とする履歴を保持している他のサーバーを利用する必要があります。
|
||||
ネットワークへの参加、トランザクションの検証、またはネットワークの現在の状態の確認には、全履歴を記録するサーバは必要ありません。全履歴が有用となるのは、過去に発生したトランザクションの結果や、過去の特定の時点におけるレジャーの状態を確認する場合だけです。このような情報を取得するには、必要とする履歴を保持している他のサーバを利用する必要があります。
|
||||
|
||||
全履歴は保管せずにXRP Ledgerネットワークの履歴の保管に参加したい場合には、[履歴シャーディングを構成](configure-history-sharding.md)すれば、レジャー履歴のグループをランダムに選択して保管できます。
|
||||
|
||||
## 構成手順
|
||||
|
||||
サーバーが全履歴を取得して保管するように構成するには、以下の手順を実行します。
|
||||
サーバが全履歴を取得して保管するように構成するには、以下の手順を実行します。
|
||||
|
||||
1. `rippled`サーバーが稼働中の場合は停止します。
|
||||
1. `rippled`サーバが稼働中の場合は停止します。
|
||||
|
||||
```
|
||||
$ sudo systemctl stop rippled
|
||||
```
|
||||
|
||||
0. サーバーの構成ファイルで`[node_db]`スタンザの`online_delete`設定と`advisory_delete`設定を削除（またはコメントアウト）し、タイプをまだ`NuDB`に変更していない場合は変更します。
|
||||
0. サーバの構成ファイルで`[node_db]`スタンザの`online_delete`設定と`advisory_delete`設定を削除（またはコメントアウト）し、タイプをまだ`NuDB`に変更していない場合は変更します。
|
||||
|
||||
```
|
||||
[node_db]
|
||||
@@ -41,20 +41,20 @@ labels:
|
||||
#advisory_delete=0
|
||||
```
|
||||
|
||||
全履歴が記録されるサーバーでは、レジャーストアーにNuDBを使用します。これは、データベースがこれほど大きいと、RocksDBでは非常に大量のRAMが必要になるためです。詳細は、[容量の計画](../../installation/capacity-planning.md)を参照してください。パフォーマンス関連の構成オプション`open_files`、`filter_bits`、`cache_mb`、`file_size_mb`、および`file_size_mult`は、RocksDBのみに適用されるオプションであるため、デフォルトの`[node_db]`スタンザから削除できます。
|
||||
全履歴が記録されるサーバでは、レジャーストアーにNuDBを使用します。これは、データベースがこれほど大きいと、RocksDBでは非常に大量のRAMが必要になるためです。詳細は、[容量の計画](../../installation/capacity-planning.md)を参照してください。パフォーマンス関連の構成オプション`open_files`、`filter_bits`、`cache_mb`、`file_size_mb`、および`file_size_mult`は、RocksDBのみに適用されるオプションであるため、デフォルトの`[node_db]`スタンザから削除できます。
|
||||
|
||||
**注意:** RocksDBで履歴をすでにダウンロードしている場合は、NuDBへ切り替えるときに構成ファイルでデータベースのパスを変更するか、またはそのデータを削除する必要があります。`[node_db]`スタンザの`path`設定**および**`[database_path]`（SQLiteデータベース）設定の両方を変更する必要があります。このようにしないと、サーバーの[起動が失敗する](../../troubleshooting/server-wont-start.md#状態dbエラー)可能性があります。
|
||||
**注意:** RocksDBで履歴をすでにダウンロードしている場合は、NuDBへ切り替えるときに構成ファイルでデータベースのパスを変更するか、またはそのデータを削除する必要があります。`[node_db]`スタンザの`path`設定**および**`[database_path]`（SQLiteデータベース）設定の両方を変更する必要があります。このようにしないと、サーバの[起動が失敗する](../../troubleshooting/server-wont-start.md#状態dbエラー)可能性があります。
|
||||
|
||||
{% partial file="/@i18n/ja/docs/_snippets/conf-file-location.md" /%}
|
||||
|
||||
0. サーバーの構成ファイルで`[ledger_history]`スタンザを`full`に設定します。
|
||||
0. サーバの構成ファイルで`[ledger_history]`スタンザを`full`に設定します。
|
||||
|
||||
```
|
||||
[ledger_history]
|
||||
full
|
||||
```
|
||||
|
||||
0. 全履歴が保管されている1台以上のサーバーと明示的にピア接続するように、サーバーの構成ファイルで`[ips_fixed]`スタンザを設定します。
|
||||
0. 全履歴が保管されている1台以上のサーバと明示的にピア接続するように、サーバの構成ファイルで`[ips_fixed]`スタンザを設定します。
|
||||
|
||||
```
|
||||
[ips_fixed]
|
||||
@@ -62,11 +62,11 @@ labels:
|
||||
50.22.123.215
|
||||
```
|
||||
|
||||
サーバーのダイレクトピアの1つが使用可能な履歴データを保持している場合に限り、サーバーはピアツーピアネットワークから履歴データをダウンロードできます。全履歴をダウンロードする最も容易な方法は、すでに全履歴を保管しているサーバーとピア接続することです。
|
||||
サーバのダイレクトピアの1つが使用可能な履歴データを保持している場合に限り、サーバはピアツーピアネットワークから履歴データをダウンロードできます。全履歴をダウンロードする最も容易な方法は、すでに全履歴を保管しているサーバとピア接続することです。
|
||||
|
||||
**ヒント:** Rippleは、すべての履歴が記録されるサーバーのプールを公開しています。これらのサーバーのIPアドレスを取得するには、ドメイン`s2.ripple.com`を数回解決します。これらのサーバーは公開サービスとして提供されているため、他のサーバーとのピア接続での可用性は限られており、またこれらのサーバーを悪用するとブロックされる可能性があることに注意してください。
|
||||
**ヒント:** Rippleは、すべての履歴が記録されるサーバのプールを公開しています。これらのサーバのIPアドレスを取得するには、ドメイン`s2.ripple.com`を数回解決します。これらのサーバは公開サービスとして提供されているため、他のサーバとのピア接続での可用性は限られており、またこれらのサーバを悪用するとブロックされる可能性があることに注意してください。
|
||||
|
||||
0. 全履歴が記録されている別のサーバーからのデータベースダンプがあり、このダンプをベースとして利用できる場合は、サーバーの構成ファイルで`[import_db]`スタンザがインポート対象データを指し示すように設定します。（それ以外の場合はこのステップをスキップします。）
|
||||
0. 全履歴が記録されている別のサーバからのデータベースダンプがあり、このダンプをベースとして利用できる場合は、サーバの構成ファイルで`[import_db]`スタンザがインポート対象データを指し示すように設定します。（それ以外の場合はこのステップをスキップします。）
|
||||
|
||||
```
|
||||
[import_db]
|
||||
@@ -74,40 +74,40 @@ labels:
|
||||
path=/tmp/full_history_dump/
|
||||
```
|
||||
|
||||
0. 以前に稼働していた`rippled`からの既存のデータベースファイルがサーバーにある場合は、そのデータベースファイルを削除します。
|
||||
0. 以前に稼働していた`rippled`からの既存のデータベースファイルがサーバにある場合は、そのデータベースファイルを削除します。
|
||||
|
||||
オンライン削除を無効にすると、サーバーはオンライン削除が有効であった間にダウンロードしたデータをすべて無視するため、ディスク容量を空けることができます。次に例を示します。
|
||||
オンライン削除を無効にすると、サーバはオンライン削除が有効であった間にダウンロードしたデータをすべて無視するため、ディスク容量を空けることができます。次に例を示します。
|
||||
|
||||
```
|
||||
rm -r /var/lib/rippled/db/*
|
||||
```
|
||||
|
||||
**警告:** フォルダーを削除する前に、保持したいファイルがそのフォルダーに含まれていないことを確認してください。通常は安全に`rippled`サーバーのデータベースファイルをすべて削除できますが、この操作は、設定されているデータベースフォルダーが`rippled`のデータベース以外には使用されていない場合にのみ行ってください。
|
||||
**警告:** フォルダーを削除する前に、保持したいファイルがそのフォルダーに含まれていないことを確認してください。通常は安全に`rippled`サーバのデータベースファイルをすべて削除できますが、この操作は、設定されているデータベースフォルダーが`rippled`のデータベース以外には使用されていない場合にのみ行ってください。
|
||||
|
||||
0. `rippled`サーバーを起動し、インポート可能なデータベースダンプがある場合にはインポートします。
|
||||
0. `rippled`サーバを起動し、インポート可能なデータベースダンプがある場合にはインポートします。
|
||||
|
||||
`[Import_db]`で構成されている読み取り対象データベースダンプがある場合は、`--import` [コマンドラインオプション](../../commandline-usage.md#デーモンモードのオプション)を指定してサーバーを明示的に起動します。
|
||||
`[Import_db]`で構成されている読み取り対象データベースダンプがある場合は、`--import` [コマンドラインオプション](../../commandline-usage.md#デーモンモードのオプション)を指定してサーバを明示的に起動します。
|
||||
|
||||
```
|
||||
$ /opt/ripple/bin/rippled --conf /etc/opt/ripple/rippled.cfg --import
|
||||
```
|
||||
|
||||
大量のデータベースダンプのインポートには数分から数時間かかることがあります。インポート中はサーバーは完全には起動せず、ネットワークと同期しません。インポートの状況を確認するには、サーバーログを参照してください。
|
||||
大量のデータベースダンプのインポートには数分から数時間かかることがあります。インポート中はサーバは完全には起動せず、ネットワークと同期しません。インポートの状況を確認するには、サーバログを参照してください。
|
||||
|
||||
データベースダンプをインポートしない場合は、サーバーを通常の方法で起動します。
|
||||
データベースダンプをインポートしない場合は、サーバを通常の方法で起動します。
|
||||
|
||||
```
|
||||
$ sudo systemctl start rippled
|
||||
```
|
||||
|
||||
0. `[import_db]`スタンザをサーバーの構成ファイルに追加した場合は、インポートの完了後にそのスタンザを削除してください。
|
||||
0. `[import_db]`スタンザをサーバの構成ファイルに追加した場合は、インポートの完了後にそのスタンザを削除してください。
|
||||
|
||||
このようにしないと、次回の再起動時にサーバーが同じデータを再びインポートしようとします。
|
||||
このようにしないと、次回の再起動時にサーバが同じデータを再びインポートしようとします。
|
||||
|
||||
0. [server_infoメソッド][]を使用して、サーバーの利用可能な履歴を監視します。
|
||||
0. [server_infoメソッド][]を使用して、サーバの利用可能な履歴を監視します。
|
||||
|
||||
`complete_ledgers`フィールドに表示される利用可能なレジャーの範囲は、時間の経過とともに増加します。
|
||||
|
||||
本番環境のXRP Ledgerの履歴で最も古い利用可能なレジャーバージョンは、レジャーインデックス**32570**です。レジャー履歴の最初の約2週間分は、当時のサーバーのバグが原因で失われています。Test Netやその他のチェーンでは通常、履歴の最初のバージョンはレジャーインデックス**1**です。
|
||||
本番環境のXRP Ledgerの履歴で最も古い利用可能なレジャーバージョンは、レジャーインデックス**32570**です。レジャー履歴の最初の約2週間分は、当時のサーバのバグが原因で失われています。Test Netやその他のチェーンでは通常、履歴の最初のバージョンはレジャーインデックス**1**です。
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -5,27 +5,27 @@ seo:
|
||||
description: XRP Ledgerの履歴データのシャードを保存するようにサーバを設定します。
|
||||
labels:
|
||||
- データ保持
|
||||
- コアサーバー
|
||||
- コアサーバ
|
||||
---
|
||||
# 履歴シャーディングの設定
|
||||
|
||||
[履歴シャーディング](history-sharding.md)では、各サーバーで完全な履歴を保管することなく、履歴XRP Ledgerデータを保存できます。デフォルトでは`rippled`サーバーは履歴シャードを保管しません。
|
||||
[履歴シャーディング](history-sharding.md)では、各サーバで完全な履歴を保管することなく、履歴XRP Ledgerデータを保存できます。デフォルトでは`rippled`サーバは履歴シャードを保管しません。
|
||||
|
||||
**ヒント:** バリデータおよび`rippled`追跡（またはストック）サーバーの両方で履歴シャードを保管するように設定できます。ただし`rippled`バリデータサーバーの経費を抑えるために、バリデータサーバーでシャードを保管するように設定 _しない_ ことが推奨されます。バリデータを実行していて、XRP Ledger履歴を保管したい場合は、履歴シャーディングを有効にして別の`rippled`サーバーを実行することが推奨されます。
|
||||
**ヒント:** バリデータおよび`rippled`追跡（またはストック）サーバの両方で履歴シャードを保管するように設定できます。ただし`rippled`バリデータサーバの経費を抑えるために、バリデータサーバでシャードを保管するように設定 _しない_ ことが推奨されます。バリデータを実行していて、XRP Ledger履歴を保管したい場合は、履歴シャーディングを有効にして別の`rippled`サーバを実行することが推奨されます。
|
||||
|
||||
レジャー履歴のシャードを保管できるよう`rippled`を設定するには、以下の手順を実行します。
|
||||
|
||||
## 1. シャードストアーに割り当てる容量を決めます。
|
||||
|
||||
履歴シャードを保管できるように`rippled`サーバーを設定する前に、履歴シャードストアーに割り当てるディスク容量を決定する必要があります。これはまた、デフォルトのレジャーストアーに保持する履歴の量にも影響します。シャードストアーのサイズを設定する際には、以下の点を考慮してください。
|
||||
履歴シャードを保管できるように`rippled`サーバを設定する前に、履歴シャードストアーに割り当てるディスク容量を決定する必要があります。これはまた、デフォルトのレジャーストアーに保持する履歴の量にも影響します。シャードストアーのサイズを設定する際には、以下の点を考慮してください。
|
||||
|
||||
- レジャーストアー（`[node_db]`スタンザにより定義される）は、履歴シャードストアーとは別のストアーです。レジャーストアーはすべてのサーバーに必要であり、そこには一定範囲の最近の履歴が保管されている必要があります。保管する範囲は、`online_delete`パラメーターに使用可能な状態で維持するレジャーの数によって定義されます。（デフォルトの設定では、最新のレジャー2000個が保管されます。）
|
||||
- レジャーストアー（`[node_db]`スタンザにより定義される）は、履歴シャードストアーとは別のストアーです。レジャーストアーはすべてのサーバに必要であり、そこには一定範囲の最近の履歴が保管されている必要があります。保管する範囲は、`online_delete`パラメーターに使用可能な状態で維持するレジャーの数によって定義されます。（デフォルトの設定では、最新のレジャー2000個が保管されます。）
|
||||
- レジャーストアーに2<sup>15</sup>個以上のレジャー（32768）が保持されている場合は、レジャーストアーからシャードストアーへ最近の履歴のグループを効率的にインポートできます。
|
||||
- 履歴シャードストアー（`[shard_db]`スタンザにより定義される）は、履歴シャードを保管する場合にのみ必要です。履歴シャードを保管しないサーバーではこの構成スタンザを省略する必要があります。履歴シャードストアーのサイズは`max_size_gb`パラメーターでギガバイト単位で定義されます。サーバーは完全なシャードを保管するため、この容量を最大限利用します。履歴シャードストアーは、 _必ず_ ソリッドステートディスクまたは同様の高速なメディアに保管します。従来の回転式ハードディスクでは不十分です。
|
||||
- 履歴シャードストアー（`[shard_db]`スタンザにより定義される）は、履歴シャードを保管する場合にのみ必要です。履歴シャードを保管しないサーバではこの構成スタンザを省略する必要があります。履歴シャードストアーのサイズは`max_size_gb`パラメーターでギガバイト単位で定義されます。サーバは完全なシャードを保管するため、この容量を最大限利用します。履歴シャードストアーは、 _必ず_ ソリッドステートディスクまたは同様の高速なメディアに保管します。従来の回転式ハードディスクでは不十分です。
|
||||
- シャードには2<sup>14</sup>個のレジャー（16384）が含まれており、シャードの経過期間に応じて約200MB～4GBを専有します。古いシャードほどXRP Ledgerでのアクティビティが少ないため、サイズが小さくなります。
|
||||
- 履歴シャードストアーとレジャーストアーはファイルパスを分けて保管する _必要があります_ 。必要に応じて、レジャーストアーと履歴ストアーをそれぞれ別のディスクやパーティションに配置するように設定できます。
|
||||
- 完全なレジャー履歴をレジャーストアーと履歴シャードストアーの両方に保持できますが、冗長な処理となります。
|
||||
- シャードの取得にかかる時間、`rippled`サーバーに必要なファイルハンドル数、およびメモリーキャッシュ使用率は、シャードのサイズの影響を直接受けます。
|
||||
- シャードの取得にかかる時間、`rippled`サーバに必要なファイルハンドル数、およびメモリーキャッシュ使用率は、シャードのサイズの影響を直接受けます。
|
||||
|
||||
## 2. rippled.cfgの編集
|
||||
|
||||
@@ -48,7 +48,7 @@ max_size_gb=50
|
||||
|
||||
詳細は、[rippled.cfgの設定例](https://github.com/XRPLF/rippled/blob/master/cfg/rippled-example.cfg)の`[shard_db]`の例を参照してください。
|
||||
|
||||
## 3. サーバーの再起動
|
||||
## 3. サーバの再起動
|
||||
|
||||
```
|
||||
systemctl restart rippled
|
||||
@@ -56,13 +56,13 @@ systemctl restart rippled
|
||||
|
||||
## 4. シャードのダウンロードの待機
|
||||
|
||||
サーバーはネットワークと同期すると、履歴シャードのダウンロードを自動的に開始し、シャードストアーの空き容量を埋めます。ダウンロード対象のシャードを確認するには、シャードストアーを設定したフォルダー内に作成されるフォルダーを確認します。（これは`rippled.cfg`ファイルの`[shard_db]`スタンザの`path`フィールドによって定義されます。）
|
||||
サーバはネットワークと同期すると、履歴シャードのダウンロードを自動的に開始し、シャードストアーの空き容量を埋めます。ダウンロード対象のシャードを確認するには、シャードストアーを設定したフォルダー内に作成されるフォルダーを確認します。（これは`rippled.cfg`ファイルの`[shard_db]`スタンザの`path`フィールドによって定義されます。）
|
||||
|
||||
このフォルダーには、サーバーに保管されている各シャードのフォルダーが番号付きで保存されています。常に、最大で1つのフォルダーに、未完了であることを示す`control.txt`ファイルが保存されています。
|
||||
このフォルダーには、サーバに保管されている各シャードのフォルダーが番号付きで保存されています。常に、最大で1つのフォルダーに、未完了であることを示す`control.txt`ファイルが保存されています。
|
||||
|
||||
[download_shardメソッド][]を使用して、サーバーにアーカイブファイルからシャードをダウンロードしてインポートするように指示できます。
|
||||
[download_shardメソッド][]を使用して、サーバにアーカイブファイルからシャードをダウンロードしてインポートするように指示できます。
|
||||
|
||||
サーバーとそのピアが使用できるシャードのリストを表示するには、[crawl_shardsメソッド][]か[ピアクローラー](../../../references/http-websocket-apis/peer-port-methods/peer-crawler.md)を使用します。
|
||||
サーバとそのピアが使用できるシャードのリストを表示するには、[crawl_shardsメソッド][]か[ピアクローラー](../../../references/http-websocket-apis/peer-port-methods/peer-crawler.md)を使用します。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
@@ -2,31 +2,31 @@
|
||||
html: configure-online-deletion.html
|
||||
parent: data-retention.html
|
||||
seo:
|
||||
description: サーバーでどこまで古いトランザクション履歴を保持するかを設定します。
|
||||
description: サーバでどこまで古いトランザクション履歴を保持するかを設定します。
|
||||
labels:
|
||||
- データ保持
|
||||
- コアサーバー
|
||||
- コアサーバ
|
||||
---
|
||||
# オンライン削除の設定
|
||||
|
||||
`rippled`サーバーのデフォルトの構成では、最新2000個のレジャーバージョンよりも古い[履歴が削除され](online-deletion.md)、レジャー履歴は約15分間維持されます（現行のレジャー毎の間隔に基づく）。このページでは、削除までに`rippled`サーバーに保管される履歴の量を設定する方法を説明します。
|
||||
`rippled`サーバのデフォルトの構成では、最新2000個のレジャーバージョンよりも古い[履歴が削除され](online-deletion.md)、レジャー履歴は約15分間維持されます（現行のレジャー毎の間隔に基づく）。このページでは、削除までに`rippled`サーバに保管される履歴の量を設定する方法を説明します。
|
||||
|
||||
## 前提条件
|
||||
|
||||
このチュートリアルでは、ご使用のサーバーが以下の条件を満たしていることを前提としています。
|
||||
このチュートリアルでは、ご使用のサーバが以下の条件を満たしていることを前提としています。
|
||||
|
||||
- サポートされているオペレーティングシステムを使用している。Ubuntu Linux、Red Hat Enterprise Linux（RHEL）、CentOS
|
||||
|
||||
- `rippled`サーバーがすでに[インストール](../../installation/index.md)されており、[オンライン削除](online-deletion.md)が有効になっている。
|
||||
- `rippled`サーバがすでに[インストール](../../installation/index.md)されており、[オンライン削除](online-deletion.md)が有効になっている。
|
||||
|
||||
推奨されるプラットフォームのインストール手順に従えば、オンライン削除はデフォルトで有効となります。
|
||||
|
||||
- 選択した量の履歴をレジャーストアーに保管するのに[十分なディスク容量](../../installation/capacity-planning.md)がサーバーにある。
|
||||
- 選択した量の履歴をレジャーストアーに保管するのに[十分なディスク容量](../../installation/capacity-planning.md)がサーバにある。
|
||||
|
||||
|
||||
## 構成手順
|
||||
|
||||
サーバーに保管する履歴の量を変更するには、以下の手順を実行します。
|
||||
サーバに保管する履歴の量を変更するには、以下の手順を実行します。
|
||||
|
||||
1. 保管する履歴に相当するレジャーバージョンの数を決定します。
|
||||
|
||||
@@ -43,7 +43,7 @@ labels:
|
||||
advisory_delete=0
|
||||
```
|
||||
|
||||
`online_delete`を、オンライン削除の実行後に維持するレジャーバージョンの最小数に設定します。自動削除が設定されている場合（デフォルト）、サーバーは通常、この数の約2倍のレジャーバージョンが蓄積されると削除を実行します。
|
||||
`online_delete`を、オンライン削除の実行後に維持するレジャーバージョンの最小数に設定します。自動削除が設定されている場合（デフォルト）、サーバは通常、この数の約2倍のレジャーバージョンが蓄積されると削除を実行します。
|
||||
|
||||
{% partial file="/@i18n/ja/docs/_snippets/conf-file-location.md" /%}
|
||||
|
||||
@@ -53,23 +53,23 @@ labels:
|
||||
$ sudo systemctl restart rippled
|
||||
```
|
||||
|
||||
0. サーバーがネットワークと同期するまで待ちます。
|
||||
0. サーバがネットワークと同期するまで待ちます。
|
||||
|
||||
ネットワークとシステムの能力と、サーバーがオフラインになっていた期間に応じて、完全な同期が完了するまでには5～15分かかります。
|
||||
ネットワークとシステムの能力と、サーバがオフラインになっていた期間に応じて、完全な同期が完了するまでには5～15分かかります。
|
||||
|
||||
サーバーとネットワークの同期が完了すると、[server_infoメソッド][]が再び開き、`server_state`の値として`"full"`、`"proposing"`、`"validating"`のいずれかが報告されます。
|
||||
サーバとネットワークの同期が完了すると、[server_infoメソッド][]が再び開き、`server_state`の値として`"full"`、`"proposing"`、`"validating"`のいずれかが報告されます。
|
||||
|
||||
0. [server_infoメソッド][]を使用してサーバーの`complete_ledgers`範囲を定期的に調べ、レジャーが削除されていることを確認します。
|
||||
0. [server_infoメソッド][]を使用してサーバの`complete_ledgers`範囲を定期的に調べ、レジャーが削除されていることを確認します。
|
||||
|
||||
オンライン削除実行後の`complete_ledgers`範囲には、古いレジャーが使用できなくなったことが反映されます。サーバーに履歴が蓄積されるにつれ、使用可能なレジャーの総数が徐々に増加します。この数が設定した`online_delete`値の2倍に達し、オンライン削除が実行されるとレジャーの総数は減少します。
|
||||
オンライン削除実行後の`complete_ledgers`範囲には、古いレジャーが使用できなくなったことが反映されます。サーバに履歴が蓄積されるにつれ、使用可能なレジャーの総数が徐々に増加します。この数が設定した`online_delete`値の2倍に達し、オンライン削除が実行されるとレジャーの総数は減少します。
|
||||
|
||||
0. `rippled`ログで、`SHAMapStore::WRN`で始まるメッセージを確認します。このメッセージが出力されている場合、サーバーがネットワークと同期していない状態になったために[オンライン削除が中断されている](online-deletion.md#オンライン削除の中断)可能性があります。
|
||||
0. `rippled`ログで、`SHAMapStore::WRN`で始まるメッセージを確認します。このメッセージが出力されている場合、サーバがネットワークと同期していない状態になったために[オンライン削除が中断されている](online-deletion.md#オンライン削除の中断)可能性があります。
|
||||
|
||||
この状況が定期的に発生する場合は、サーバーのスペックが不十分で、オンライン削除の実行中にレジャーを最新状態に維持できていない可能性があります。同じハードウェア上の他のサービス（スケジュール済みバックアップやセキュリティスキャンなど）と`rippled`サーバーがリソースをめぐって競合していないことを確認してください。以下のいずれかの操作を実行できます。
|
||||
この状況が定期的に発生する場合は、サーバのスペックが不十分で、オンライン削除の実行中にレジャーを最新状態に維持できていない可能性があります。同じハードウェア上の他のサービス（スケジュール済みバックアップやセキュリティスキャンなど）と`rippled`サーバがリソースをめぐって競合していないことを確認してください。以下のいずれかの操作を実行できます。
|
||||
|
||||
- システムスペックを強化する。推奨事項については、[システム要件](../../installation/system-requirements.md)を参照してください。
|
||||
- 設定を変更し、保管する履歴の量を減らす。（このチュートリアルのステップ2）
|
||||
- サーバーの[`node_size`パラメーター](../../installation/capacity-planning.md)を変更する。
|
||||
- サーバの[`node_size`パラメーター](../../installation/capacity-planning.md)を変更する。
|
||||
- レジャーストアーに[RocksDBの代わりにNuDB](../../installation/capacity-planning.md)を使用する。
|
||||
- [指示による削除を使用してオンライン削除をスケジュールする](configure-advisory-deletion.md)。
|
||||
|
||||
|
||||
@@ -2,20 +2,20 @@
|
||||
html: history-sharding.html
|
||||
parent: data-retention.html
|
||||
seo:
|
||||
description: 履歴シャーディングは、履歴レジャーデータを保持する任務をrippledサーバー間で分担するようにします。
|
||||
description: 履歴シャーディングは、履歴レジャーデータを保持する任務をrippledサーバ間で分担するようにします。
|
||||
labels:
|
||||
- データ保持
|
||||
- コアサーバー
|
||||
- コアサーバ
|
||||
---
|
||||
# 履歴シャーディング
|
||||
|
||||
{% badge href="https://github.com/XRPLF/rippled/releases/tag/0.90.0" %}導入: rippled 0.90.0{% /badge %}
|
||||
|
||||
稼働中のサーバーは、ネットワーク実行時に検知または取得したレジャーに関するデータを格納したデータベースを作成します。各`rippled`サーバーは、そのレジャーのデータをレジャーストアーに保存しますが、保存されたレジャー数が設定された容量制限を超えると、オンライン削除ロジックによりこれらのデータベースがローテーションされます。
|
||||
稼働中のサーバは、ネットワーク実行時に検知または取得したレジャーに関するデータを格納したデータベースを作成します。各`rippled`サーバは、そのレジャーのデータをレジャーストアーに保存しますが、保存されたレジャー数が設定された容量制限を超えると、オンライン削除ロジックによりこれらのデータベースがローテーションされます。
|
||||
|
||||
履歴シャーディングは、XRP Ledgerのトランザクション履歴をシャードと呼ばれるセグメントに分割し、XRP Ledgerネットワークのサーバー全体に分散します。シャードは、一連のレジャーです。`rippled`サーバーは、レジャーストアーとシャードストアーの両方にレジャーを同じ方法で保存します。
|
||||
履歴シャーディングは、XRP Ledgerのトランザクション履歴をシャードと呼ばれるセグメントに分割し、XRP Ledgerネットワークのサーバ全体に分散します。シャードは、一連のレジャーです。`rippled`サーバは、レジャーストアーとシャードストアーの両方にレジャーを同じ方法で保存します。
|
||||
|
||||
履歴シャーディング機能を使用すると、個々の`rippled`サーバーが履歴データの保存する役割を担い、すべての履歴（数テラバイト）を保存する必要がなくなります。シャードストアーはレジャーストアーに代わるものではありませんが、XRP Ledgerネットワーク上の分散レジャー履歴への信頼性の高いパスを実現します。
|
||||
履歴シャーディング機能を使用すると、個々の`rippled`サーバが履歴データの保存する役割を担い、すべての履歴（数テラバイト）を保存する必要がなくなります。シャードストアーはレジャーストアーに代わるものではありませんが、XRP Ledgerネットワーク上の分散レジャー履歴への信頼性の高いパスを実現します。
|
||||
|
||||
[](/docs/img/xrp-ledger-network-ledger-store-and-shard-store.ja.png)
|
||||
|
||||
@@ -23,15 +23,15 @@ labels:
|
||||
|
||||
## 履歴シャードの取得と共有
|
||||
|
||||
`rippled` サーバーは履歴シャードを取得して保存します（この動作には設定が必要です）。このようなサーバーでは、ネットワークとの同期を実行し、設定された数の最新レジャーへのレジャー履歴の埋め戻しが完了した後で、シャードの取得が開始されます。ネットワークアクティビティがあまり発生しないこの期間に、`shard_db`を維持するように設定されている`rippled`サーバー が、シャードストアーに追加するシャードをランダムに選択します。ネットワークレジャー履歴が均等に分散される確率を高めるため、取得対象のシャードはランダムに選択され、現行シャードが特に優先されることはありません。
|
||||
`rippled` サーバは履歴シャードを取得して保存します（この動作には設定が必要です）。このようなサーバでは、ネットワークとの同期を実行し、設定された数の最新レジャーへのレジャー履歴の埋め戻しが完了した後で、シャードの取得が開始されます。ネットワークアクティビティがあまり発生しないこの期間に、`shard_db`を維持するように設定されている`rippled`サーバ が、シャードストアーに追加するシャードをランダムに選択します。ネットワークレジャー履歴が均等に分散される確率を高めるため、取得対象のシャードはランダムに選択され、現行シャードが特に優先されることはありません。
|
||||
|
||||
シャードが選択されたら、レジャー取得プロセスが開始されます。最初にシャードの最後のレジャーのシーケンスが取得され、最初のシャードに向けて逆方向に処理が進められます。取得プロセスでは最初に、サーバーがローカルでデータを確認します。取得できないデータについては、サーバーはピア`rippled`サーバーにデータをリクエストします。リクエストされた期間のデータを供給できるサーバーは、履歴でレスポンスします。リクエスト側サーバーはこれらのレスポンスを結合し、シャードを作成します。シャードに特定範囲のレジャーがすべて含まれた状態になれば、シャードが完成します。
|
||||
シャードが選択されたら、レジャー取得プロセスが開始されます。最初にシャードの最後のレジャーのシーケンスが取得され、最初のシャードに向けて逆方向に処理が進められます。取得プロセスでは最初に、サーバがローカルでデータを確認します。取得できないデータについては、サーバはピア`rippled`サーバにデータをリクエストします。リクエストされた期間のデータを供給できるサーバは、履歴でレスポンスします。リクエスト側サーバはこれらのレスポンスを結合し、シャードを作成します。シャードに特定範囲のレジャーがすべて含まれた状態になれば、シャードが完成します。
|
||||
|
||||
`rippled`サーバーが1つのシャードを完全に取得する前に容量不足になった場合、空き容量ができて処理を続行できるようになるまで取得プロセスを停止します。この後、古いシャードは完成された最新のシャードに置き換えられます。ディスク容量が十分にある場合は、`rippled`サーバーはシャードに割り当てられている最大ディスク容量（`max_size_gb`）に達するまで、ランダムに選択された追加のシャードを取得し、シャードストアーに追加します。
|
||||
`rippled`サーバが1つのシャードを完全に取得する前に容量不足になった場合、空き容量ができて処理を続行できるようになるまで取得プロセスを停止します。この後、古いシャードは完成された最新のシャードに置き換えられます。ディスク容量が十分にある場合は、`rippled`サーバはシャードに割り当てられている最大ディスク容量（`max_size_gb`）に達するまで、ランダムに選択された追加のシャードを取得し、シャードストアーに追加します。
|
||||
|
||||
## XRP Ledgerネットワークデータの整合性
|
||||
|
||||
すべてのレジャーの履歴は、特定範囲の履歴レジャーを維持することに同意したサーバー間で共有されます。これにより、各サーバーは維持することに同意したデータがすべてあることを確認し、プルーフツリーまたはレジャーデルタを作成できるようになります。履歴シャーディングが設定されている`rippled`サーバーは、保存するシャードをランダムに選択するため、すべての閉鎖済みレジャーの履歴全体が正規分布曲線で保存され、XRP Ledgerネットワークで履歴が均一に維持される確率が高くなります。
|
||||
すべてのレジャーの履歴は、特定範囲の履歴レジャーを維持することに同意したサーバ間で共有されます。これにより、各サーバは維持することに同意したデータがすべてあることを確認し、プルーフツリーまたはレジャーデルタを作成できるようになります。履歴シャーディングが設定されている`rippled`サーバは、保存するシャードをランダムに選択するため、すべての閉鎖済みレジャーの履歴全体が正規分布曲線で保存され、XRP Ledgerネットワークで履歴が均一に維持される確率が高くなります。
|
||||
|
||||
## 関連項目
|
||||
|
||||
|
||||
@@ -5,60 +5,60 @@ seo:
|
||||
description: オンライン削除は古いトランザクションと状態の履歴を消去します。
|
||||
labels:
|
||||
- データ保持
|
||||
- コアサーバー
|
||||
- コアサーバ
|
||||
---
|
||||
# オンライン削除
|
||||
[[ソース]<br/>](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/misc/SHAMapStoreImp.cpp "Source")
|
||||
|
||||
オンライン削除機能により、`rippled`サーバーはレジャーの古いバージョンのローカルコピーを削除できます。これにより、時間とともにディスク使用量が急増しないようにできます。デフォルトの構成ファイルにはオンライン削除の自動実行が設定されていますが、指示があった場合にのみオンライン削除を実行するようにも設定できます。{% badge href="https://github.com/XRPLF/rippled/releases/tag/0.27.0" %}新規: rippled 0.27.0{% /badge %}
|
||||
オンライン削除機能により、`rippled`サーバはレジャーの古いバージョンのローカルコピーを削除できます。これにより、時間とともにディスク使用量が急増しないようにできます。デフォルトの構成ファイルにはオンライン削除の自動実行が設定されていますが、指示があった場合にのみオンライン削除を実行するようにも設定できます。{% badge href="https://github.com/XRPLF/rippled/releases/tag/0.27.0" %}新規: rippled 0.27.0{% /badge %}
|
||||
|
||||
サーバーは、レジャーおよびそのすべての残高と設定を、常に完全かつ _最新_ の状態に維持します。削除されるデータには、保存されている履歴よりも古いレジャー状態の古いトランザクションやバージョンがあります。
|
||||
サーバは、レジャーおよびそのすべての残高と設定を、常に完全かつ _最新_ の状態に維持します。削除されるデータには、保存されている履歴よりも古いレジャー状態の古いトランザクションやバージョンがあります。
|
||||
|
||||
デフォルトの構成ファイルは、`rippled`サーバーが2000の最新レジャーバージョンを保持し、古いデータを自動的に削除するように設定されています。
|
||||
デフォルトの構成ファイルは、`rippled`サーバが2000の最新レジャーバージョンを保持し、古いデータを自動的に削除するように設定されています。
|
||||
|
||||
**ヒント:** オンライン削除を使用しても、同一期間のレジャーデータを保管するのに必要なディスク容量は時間の経過とともに増加します。これは、個々のレジャーバージョンのサイズが時間とともに増加する傾向にあるためです。蓄積データが増加するペースは、古いレジャーを削除しない場合に比べると、非常にゆっくりとしています。必要なディスク容量に関する詳細は、[容量の計画](../../installation/capacity-planning.md)を参照してください。
|
||||
|
||||
|
||||
## 背景
|
||||
|
||||
`rippled`サーバーでは[レジャー履歴](../../../concepts/networks-and-servers/ledger-history.md)がその _レジャーストアー_ に保管されます。このデータは時間とともに蓄積されます。
|
||||
`rippled`サーバでは[レジャー履歴](../../../concepts/networks-and-servers/ledger-history.md)がその _レジャーストアー_ に保管されます。このデータは時間とともに蓄積されます。
|
||||
|
||||
レジャーストアー内ではレジャーデータの「重複排除」が行われます。つまり、バージョン間で変更されていないデータは1回だけ保存されます。レジャーストアーのレコード自体には、レコードが記録されているレジャーバージョンの記載はありません。オンライン削除処理において、古いレジャーバージョンでのみ使用されるレコードが特定されます。この処理には時間がかかり、またディスクI/Oとアプリケーションキャッシュに影響するため、レジャーを閉鎖するたびに古いデータを削除することは現実的ではありません。
|
||||
|
||||
|
||||
## オンライン削除の動作
|
||||
|
||||
オンライン削除の設定では、`rippled`サーバーがレジャーストアーで使用可能な状態で維持するレジャーバージョンの数が設定されます。ただし、指定される数は目安であり、厳格に適用されるものではありません。
|
||||
オンライン削除の設定では、`rippled`サーバがレジャーストアーで使用可能な状態で維持するレジャーバージョンの数が設定されます。ただし、指定される数は目安であり、厳格に適用されるものではありません。
|
||||
|
||||
- サーバーでは、設定された数のレジャーバージョンよりも新しいデータが削除されることはありませんが、長期にわたってサーバーが稼働していない場合や、ネットワークとの同期が失われた場合には、サーバーに含まれるレジャーバージョンの数が使用可能な数よりも少ないことがあります。（サーバーは一部の履歴の埋め戻しを試みます。詳細は、[履歴の取得](../../../concepts/networks-and-servers/ledger-history.md#履歴の取得)を参照してください。）
|
||||
- サーバでは、設定された数のレジャーバージョンよりも新しいデータが削除されることはありませんが、長期にわたってサーバが稼働していない場合や、ネットワークとの同期が失われた場合には、サーバに含まれるレジャーバージョンの数が使用可能な数よりも少ないことがあります。（サーバは一部の履歴の埋め戻しを試みます。詳細は、[履歴の取得](../../../concepts/networks-and-servers/ledger-history.md#履歴の取得)を参照してください。）
|
||||
- オンライン削除の自動実行が設定されている場合、設定されているレジャーバージョンの数の2倍を超える数まで保存できる可能性があります。（オンライン削除を実行するたびに、保管されるレジャーバージョンの数が削減され、設定数に近くなります。）
|
||||
|
||||
ＰＣサーバーがビジーのためオンライン削除が遅延すると、レジャーバージョンが蓄積し続けることがあります。正常に動作している場合には、サーバー内のレジャーバージョン数が設定された数の2倍に達した時点でオンライン削除が開始されますが、さらにいくつかのレジャーバージョンが蓄積するまではオンライン削除が完了しないことがあります。
|
||||
ＰＣサーバがビジーのためオンライン削除が遅延すると、レジャーバージョンが蓄積し続けることがあります。正常に動作している場合には、サーバ内のレジャーバージョン数が設定された数の2倍に達した時点でオンライン削除が開始されますが、さらにいくつかのレジャーバージョンが蓄積するまではオンライン削除が完了しないことがあります。
|
||||
|
||||
- 指示による削除が有効な場合、管理者が[can_deleteメソッド][]を呼び出すまで、サーバーが取得および作成したすべてのレジャーバージョンがサーバーに保存されます。
|
||||
- 指示による削除が有効な場合、管理者が[can_deleteメソッド][]を呼び出すまで、サーバが取得および作成したすべてのレジャーバージョンがサーバに保存されます。
|
||||
|
||||
サーバーに保存されるデータ量は、[can_delete][can_deleteメソッド]を呼び出す頻度と、`online_delete`設定に指定されている期間の長さに応じて異なります。
|
||||
サーバに保存されるデータ量は、[can_delete][can_deleteメソッド]を呼び出す頻度と、`online_delete`設定に指定されている期間の長さに応じて異なります。
|
||||
|
||||
- `online_delete`の間隔よりも頻繁に`can_delete`を呼び出す場合、サーバーには最大で **`online_delete`の値の2倍** にほぼ相当するレジャーバージョンが保存されます。（削除後には、この数はほぼ`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`を呼び出しした場合、変更が生じません。これは、削除するのに十分な数のレジャーバージョンがサーバーにないためです。
|
||||
たとえば`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間隔分のデータまで減少します。）
|
||||
- `online_delete`の間隔 _よりも少ない頻度で_ `can_delete`を呼び出す場合、最大で **`can_delete`呼び出しの間隔のほぼ2倍** の期間にわたりレジャーバージョンがサーバに保管されます。（削除後には、この数は約1間隔分のデータまで減少します。）
|
||||
|
||||
たとえば`now`値を指定した`can_delete`を1日1回呼び出し、`online_delete`値に2000を指定している場合、サーバーでは通常、削除が実行されるまでに最大で2日間分のレジャーバージョンが保管されます。削除の実行後は、サーバーには約1日分のレジャーバージョン（約25,000）が保持されますが、このレジャーバージョンの数が2000を下回ることはありません。
|
||||
たとえば`now`値を指定した`can_delete`を1日1回呼び出し、`online_delete`値に2000を指定している場合、サーバでは通常、削除が実行されるまでに最大で2日間分のレジャーバージョンが保管されます。削除の実行後は、サーバには約1日分のレジャーバージョン（約25,000）が保持されますが、このレジャーバージョンの数が2000を下回ることはありません。
|
||||
|
||||
|
||||
オンライン削除が有効であり、自動的に実行される場合（つまり指示による削除が無効な場合）、保管されるレジャーデータの量は、最低でもサーバーに設定された保持レジャーバージョン数に相当し、最大でその約2倍です。
|
||||
オンライン削除が有効であり、自動的に実行される場合（つまり指示による削除が無効な場合）、保管されるレジャーデータの量は、最低でもサーバに設定された保持レジャーバージョン数に相当し、最大でその約2倍です。
|
||||
|
||||
オンライン削除が実行されても、ディスク上のSQLiteデータベースファイルのサイズは減少しません。これらのファイルの中に新しいデータを入れるのに再利用できるスペースが確保されるだけです。オンライン削除によって、レジャーストアーが含まれるRocksDB または NuDB データベースファイルのサイズは _減少します_ 。
|
||||
|
||||
サーバーでは、削除範囲を決定する際に検証済みレジャーバージョンの数だけがカウントされます。（ローカルネットワーク接続が停止していたか、グローバルXRP Ledgerネットワークがコンセンサスに達しなかったことが原因で）サーバーが新しいレジャーバージョンを検証できない例外的な状況にある場合、ネットワークが復旧した際に迅速に回復できるように、`rippled`は引き続きレジャーを閉鎖します。この場合、サーバーには未検証の閉鎖済みレジャーが多数蓄積されます。このような未検証レジャーは、オンライン削除の実行までにサーバーに保持される _検証済み_ レジャーの数には影響しません。
|
||||
サーバでは、削除範囲を決定する際に検証済みレジャーバージョンの数だけがカウントされます。（ローカルネットワーク接続が停止していたか、グローバルXRP Ledgerネットワークがコンセンサスに達しなかったことが原因で）サーバが新しいレジャーバージョンを検証できない例外的な状況にある場合、ネットワークが復旧した際に迅速に回復できるように、`rippled`は引き続きレジャーを閉鎖します。この場合、サーバには未検証の閉鎖済みレジャーが多数蓄積されます。このような未検証レジャーは、オンライン削除の実行までにサーバに保持される _検証済み_ レジャーの数には影響しません。
|
||||
|
||||
### オンライン削除の中断
|
||||
|
||||
[サーバーの状態](../../../references/http-websocket-apis/api-conventions/rippled-server-states.md)が`full`より優先順位の低い状態になると、オンライン削除は自動的に停止します。この場合、サーバーはプレフィクス`SHAMapStore::WRN`が付いたログメッセージを書き込みます。サーバーは完全に同期された後、次の検証済みレジャーバージョン以降からオンライン削除の再開を試みます。
|
||||
[サーバの状態](../../../references/http-websocket-apis/api-conventions/rippled-server-states.md)が`full`より優先順位の低い状態になると、オンライン削除は自動的に停止します。この場合、サーバはプレフィクス`SHAMapStore::WRN`が付いたログメッセージを書き込みます。サーバは完全に同期された後、次の検証済みレジャーバージョン以降からオンライン削除の再開を試みます。
|
||||
|
||||
サーバーを停止した場合や、オンライン削除の実行中にサーバーがクラッシュした場合には、サーバーが再起動し、完全に同期されれば、オンライン削除が再開されます。
|
||||
サーバを停止した場合や、オンライン削除の実行中にサーバがクラッシュした場合には、サーバが再起動し、完全に同期されれば、オンライン削除が再開されます。
|
||||
|
||||
オンライン削除を一時的に無効にするには、引数`never`を指定した[can_deleteメソッド][]を使用できます。この変更は、[can_delete][can_delete method] をもう一度呼び出してオンライン削除を再度有効にするまで保持されます。オンライン削除の実行時点の制御についての詳細は、[指示による削除](#指示による削除)を参照してください。
|
||||
|
||||
@@ -67,13 +67,13 @@ labels:
|
||||
|
||||
オンライン削除に関連する設定は以下のとおりです。
|
||||
|
||||
- **`online_delete`** - 維持する検証済みレジャーバージョンの数を指定します。サーバーは、この数よりも古いレジャーバージョンをすべて定期的に削除します。数を指定しなければ、レジャーは削除されません。
|
||||
- **`online_delete`** - 維持する検証済みレジャーバージョンの数を指定します。サーバは、この数よりも古いレジャーバージョンをすべて定期的に削除します。数を指定しなければ、レジャーは削除されません。
|
||||
|
||||
デフォルトの構成ファイルでは、この値は2000に設定されています。この値に256未満の数は設定はできません。これは、[手数料投票](../../../concepts/consensus-protocol/fee-voting.md)や[Amendmentプロセス](../../../concepts/networks-and-servers/amendments.md#amendmentプロセス)などのイベントで一度に更新されるレジャーの数が256であるためです。
|
||||
|
||||
**注意:**`online_delete`を無効にして`rippled`を実行し、その後`online_delete`を有効にしてサーバーを再起動すると、`online_delete`が無効の間にサーバーがダウンロードした既存のレジャー履歴は無視されますが、削除されません。ディスク容量を節約するには、`online_delete`設定の変更後にサーバーを再起動する前に、既存の履歴を削除します。
|
||||
**注意:**`online_delete`を無効にして`rippled`を実行し、その後`online_delete`を有効にしてサーバを再起動すると、`online_delete`が無効の間にサーバがダウンロードした既存のレジャー履歴は無視されますが、削除されません。ディスク容量を節約するには、`online_delete`設定の変更後にサーバを再起動する前に、既存の履歴を削除します。
|
||||
|
||||
- **`[ledger_history]`** - 検証済みレジャーの数（`online_delete`の値以下）を指定します。サーバーの検証済みレジャーバージョンの数がこの数よりも少ない場合、ピアからデータを取得してバージョンを埋め戻す操作が試行されます。
|
||||
- **`[ledger_history]`** - 検証済みレジャーの数（`online_delete`の値以下）を指定します。サーバの検証済みレジャーバージョンの数がこの数よりも少ない場合、ピアからデータを取得してバージョンを埋め戻す操作が試行されます。
|
||||
|
||||
この設定のデフォルト値はレジャー256個です。
|
||||
|
||||
@@ -85,11 +85,11 @@ labels:
|
||||
|
||||
この設定はデフォルトで無効になっています。
|
||||
|
||||
- **`[fetch_depth]`** - 検証済みレジャーバージョンの数を指定します。サーバーは、指定されている数のレジャーバージョンよりも古い履歴データに対するピアからの取得リクエストを受け入れません。使用可能なすべてのデータをピアに提供するには、値`full`を指定します。
|
||||
- **`[fetch_depth]`** - 検証済みレジャーバージョンの数を指定します。サーバは、指定されている数のレジャーバージョンよりも古い履歴データに対するピアからの取得リクエストを受け入れません。使用可能なすべてのデータをピアに提供するには、値`full`を指定します。
|
||||
|
||||
`fetch_depth`のデフォルトは`full`です（使用可能なすべてのデータを提供します）。
|
||||
|
||||
`fetch_depth`設定と`online_delete`設定の両方が指定されている場合、`fetch_depth`には`online_delete`よりも大きな値を設定できません。`fetch_depth`に大きな値が設定されている場合、サーバーは`fetch_depth`の値が`online_delete`と同等であるものとして扱います。
|
||||
`fetch_depth`設定と`online_delete`設定の両方が指定されている場合、`fetch_depth`には`online_delete`よりも大きな値を設定できません。`fetch_depth`に大きな値が設定されている場合、サーバは`fetch_depth`の値が`online_delete`と同等であるものとして扱います。
|
||||
|
||||
次の図は、fetch_depthの仕組みを示します。
|
||||
|
||||
@@ -101,18 +101,18 @@ labels:
|
||||
|
||||
デフォルトの構成ファイルでは、オンライン削除が定期的に自動で実行されるように設定されています。構成ファイルに`online_delete`間隔が指定されていない場合、オンライン削除は実行されません。構成ファイルで`advisory_delete`設定が有効になっている場合、オンライン削除は、管理者が[can_deleteメソッド][]を使用してオンライン削除をトリガーしたときにのみ実行されます。
|
||||
|
||||
指示による削除とスケジュール済みジョブを使用すれば、閉鎖済みレジャーバージョン数の代わりに、時刻に基づいて自動削除をトリガーできます。サーバーの使用率が高い場合、オンライン削除によって負荷が追加されるとサーバーの処理が遅延し、コンセンサスネットワークと一時的に非同期になることがあります。この場合は、指示による削除を使用して、オンライン削除をオフピーク期間にのみ実行するようにスケジュールできます。
|
||||
指示による削除とスケジュール済みジョブを使用すれば、閉鎖済みレジャーバージョン数の代わりに、時刻に基づいて自動削除をトリガーできます。サーバの使用率が高い場合、オンライン削除によって負荷が追加されるとサーバの処理が遅延し、コンセンサスネットワークと一時的に非同期になることがあります。この場合は、指示による削除を使用して、オンライン削除をオフピーク期間にのみ実行するようにスケジュールできます。
|
||||
|
||||
指示による削除はその他の目的でも使用できます。たとえば、トランザクションデータを削除する前に、そのデータが別のサーバーにバックアップされていることを手動で確認できます。あるいは、トランザクションデータを削除する前に、別のタスクによるそのデータの処理が完了していることを手動で確認できます。
|
||||
指示による削除はその他の目的でも使用できます。たとえば、トランザクションデータを削除する前に、そのデータが別のサーバにバックアップされていることを手動で確認できます。あるいは、トランザクションデータを削除する前に、別のタスクによるそのデータの処理が完了していることを手動で確認できます。
|
||||
|
||||
`can_delete` API メソッドは、構成ファイルで `advisory_delete` が有効になっている場合は、一般的な自動削除または特定のレジャーバージョンまでの自動削除を有効または無効にできます。`rippled`サーバーの再起動前に構成ファイルで`advisory_delete`を無効にしている場合を除き、これらの設定はサーバーを再起動しても維持されます。
|
||||
`can_delete` API メソッドは、構成ファイルで `advisory_delete` が有効になっている場合は、一般的な自動削除または特定のレジャーバージョンまでの自動削除を有効または無効にできます。`rippled`サーバの再起動前に構成ファイルで`advisory_delete`を無効にしている場合を除き、これらの設定はサーバを再起動しても維持されます。
|
||||
|
||||
|
||||
## 仕組み
|
||||
|
||||
オンライン削除では2つのデータベースが作成されます。このため、「古い」読み取り専用データベースと、書き込み可能な「現行」データベースが常に存在します。`rippled`サーバーはいずれかのデータベースからオブジェクトを読み取ることができます。このため、現行レジャーバージョンにはいずれかのデータベースのオブジェクトが含まれます。レジャーバージョン間でレジャー内のオブジェクトに変更がない場合、そのオブジェクトのコピーが1つだけデータベースに残ります。これにより、オブジェクトのコピーが重複してサーバーに保存されることはありません。レジャーバージョンの更新によりオブジェクトが変更されると、サーバーは変更されたオブジェクトを「新しい」データベースに保存し、古いバージョンのオブジェクト（古いレジャーバージョンで使用されているオブジェクト）は「古い」データベースに残ります。
|
||||
オンライン削除では2つのデータベースが作成されます。このため、「古い」読み取り専用データベースと、書き込み可能な「現行」データベースが常に存在します。`rippled`サーバはいずれかのデータベースからオブジェクトを読み取ることができます。このため、現行レジャーバージョンにはいずれかのデータベースのオブジェクトが含まれます。レジャーバージョン間でレジャー内のオブジェクトに変更がない場合、そのオブジェクトのコピーが1つだけデータベースに残ります。これにより、オブジェクトのコピーが重複してサーバに保存されることはありません。レジャーバージョンの更新によりオブジェクトが変更されると、サーバは変更されたオブジェクトを「新しい」データベースに保存し、古いバージョンのオブジェクト（古いレジャーバージョンで使用されているオブジェクト）は「古い」データベースに残ります。
|
||||
|
||||
オンライン削除を実行する場合、サーバーはまず、最も古いレジャーバージョンの中から保持するものを確認し、そのレジャーバージョンのすべてのオブジェクトを読み取り専用の「古い」データベースから「現行」データベースにコピーします。これにより、「現行」データベースには、選択したレジャーバージョンとそれ以降のすべての新しいバージョンで使用されるオブジェクトがすべて含まれることになります。次に、サーバーは「古い」データベースを削除し、既存の「現行」データベースを「古い」読み取り専用データベースにします。これ以降、サーバーは新しい「現行」データベースを始動し、新たな変更をすべてこのデータベースに保存します。
|
||||
オンライン削除を実行する場合、サーバはまず、最も古いレジャーバージョンの中から保持するものを確認し、そのレジャーバージョンのすべてのオブジェクトを読み取り専用の「古い」データベースから「現行」データベースにコピーします。これにより、「現行」データベースには、選択したレジャーバージョンとそれ以降のすべての新しいバージョンで使用されるオブジェクトがすべて含まれることになります。次に、サーバは「古い」データベースを削除し、既存の「現行」データベースを「古い」読み取り専用データベースにします。これ以降、サーバは新しい「現行」データベースを始動し、新たな変更をすべてこのデータベースに保存します。
|
||||
|
||||
[{% inline-svg file="/docs/img/online-deletion-process.ja.svg" /%}](/docs/img/online-deletion-process.ja.svg 'オンライン削除で2つのデータベースがどのように使用されるかを示す図')
|
||||
|
||||
|
||||
Reference in New Issue
Block a user