# 指示による削除の設定

デフォルトの構成ファイルは、新しいレジャーバージョンが利用可能になると`rippled`が古いXRP Ledgerの履歴を自動的に削除するように設定されています。サーバがピーク時にハードウェアリソースの大部分を使用する場合は、オフピーク時に実行するようスケジュールされたコマンドからの指示があった場合にのみ、レジャーを削除するようにサーバを設定できます。これにより、オンライン削除がサーバのパフォーマンスに及ぼす影響はほとんどなくなります。

## 前提条件

このチュートリアルでは、ご使用のサーバが以下の条件を満たしていることを前提としています。

- サポートされているオペレーティングシステムを使用している。Ubuntu Linux、Red Hat Enterprise Linux（RHEL）、CentOS
- `rippled`サーバがすでに[インストール](/ja/docs/infrastructure/installation)されており、[オンライン削除](/ja/docs/infrastructure/configuration/data-retention/online-deletion)が有効になっている。
デフォルトの構成ファイルは、レジャーバージョンが2000個を超えるとオンライン削除を実行するよう設定されています。
- `cron`デーモンがインストールされており、実行されている。
Ubuntu Linuxではデフォルトで`cron`デーモンが実行されます。
RHELまたはCentOSでは、以下の`cronie`パッケージをインストールできます。

```
$ sudo yum install cronie
```
- 選択した量の履歴をレジャーストアーに保管するのに十分なディスク容量がサーバにある。
各種設定で必要なストレージの容量についての詳細は、[容量計画](/ja/docs/infrastructure/installation/capacity-planning)をご覧ください。指示による削除が有効な場合、削除が実行されるまでにサーバに蓄積可能な履歴の最大数は、`online_delete`設定で設定したレジャーバージョン数と、オンライン削除の指示の間隔を**加算**したものに相当します。
- サーバの使用率が最も低い時間帯を把握している。


## 設定手順

日次スケジュールで指示による削除は以下の手順で設定します。

1. `rippled`の構成ファイルの`[node_db]`スタンザで`advisory_delete`を有効にします。

```
[node_db]
# Other settings unchanged ...
  online_delete=300000
  advisory_delete=1
```
  - 指示された場合にのみオンライン削除を実行するには、`advisory_delete`を`1`に設定します。（`0`に設定すると、新しいレジャーバージョンが使用可能になると自動的にオンライン削除が実行されます。）
  - `online_delete`を、オンライン削除の実行後に維持するレジャーバージョンの最小数に設定します。オンライン削除が実行されるまでに蓄積される履歴は、この値よりも多くなります。

2. サーバに対してオンライン削除を指示する[can_deleteメソッド](/ja/docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/can_delete)の実行をテストします。
このコマンドの実行には[`rippled`コマンドラインインターフェイス](/ja/docs/tutorials/http-websocket-apis/build-apps/get-started#%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89%E3%83%A9%E3%82%A4%E3%83%B3)を使用できます。例:

```
$ rippled --conf=/etc/opt/ripple/rippled.cfg can_delete now
```
レスポンスは、サーバがそのレジャーストアーから削除するレジャーインデックスの最大値を示します。たとえば、以下のメッセージはレジャーインデックス43633667以下のレジャーバージョンを削除できることを示します。

```
{
  "result": {
    "can_delete": 43633667,
    "status": "success"
  }
}
```
サーバ内の *新しい* 検証済みレジャーバージョンの数が、`online_delete`の設定以上となった場合にのみ、レジャーバージョンが削除されます。
3. 前のステップでテストした`can_delete`メソッドを、予定した時刻に実行するように`cron`デーモンを設定します。
`cron` 設定を編集します。

```
$ crontab -e
```
以下の例では、サーバ時刻で毎日1:05 AMにサーバが削除を実行するように設定されています。

```
5 1 * * * rippled --conf /etc/opt/ripple/rippled.cfg can_delete now
```
サーバで設定されているタイムゾーンに基づいてコマンドが実行されるようにスケジュールしてください。
**ヒント:**`advisory_delete`を無効にしている場合は、`cron`ジョブをオンラインで実行するようにスケジュールする必要はありません。この場合、サーバの最も古いレジャーバージョンと現行の検証済みレジャーバージョンの差が`online_delete`の値以上である場合に、`rippled`によりオンライン削除が実行されます。
4. `rippled`サービスを起動（または再起動）します。

```
$ sudo systemctl restart rippled
```
5. [server_infoメソッド](/ja/docs/references/http-websocket-apis/public-api-methods/server-info-methods/server_info)を使用してサーバの`complete_ledgers`範囲を定期的に調べ、レジャーがスケジュール通りに削除されていることを確認します。
オンライン削除の実行後には`complete_ledgers`の最小レジャーインデックスが増加します。
サーバの使用率の状況と、一度に削除する履歴の量によっては、削除が完了するまでに数分間かかることがあります。


## トラブルシューティング

オンライン削除の設定後にオンライン削除が実行されていないようである場合は、以下を試してください。

- `cron`ジョブを設定したユーザに、コマンドラインクライアントとして`rippled`サーバを実行できる権限があることを確認します。
- cronジョブの構文とこのジョブの実行予定時刻を確認します。
- `rippled`実行可能ファイルが`cron`設定で指定したパスで使用可能であることを確認します。必要に応じて実行可能ファイルの絶対パス（`/opt/ripple/bin/rippled`など）を指定します。
- `rippled`ログで、`SHAMapStore::WRN`で始まるメッセージを調べます。このメッセージが出力されている場合、サーバがネットワークと同期していない状態になったために[オンライン削除が中断されている](/ja/docs/infrastructure/configuration/data-retention/online-deletion#%E3%82%AA%E3%83%B3%E3%83%A9%E3%82%A4%E3%83%B3%E5%89%8A%E9%99%A4%E3%81%AE%E4%B8%AD%E6%96%AD)可能性があります。