# オンライン削除 [[ソース]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/misc/SHAMapStoreImp.cpp) オンライン削除機能により、`rippled`サーバはレジャーの古いバージョンのローカルコピーを削除できます。これにより、時間とともにディスク使用量が急増しないようにできます。デフォルトの構成ファイルにはオンライン削除の自動実行が設定されていますが、指示があった場合にのみオンライン削除を実行するようにも設定できます。新規: rippled 0.27.0 サーバは、レジャーおよびそのすべての残高と設定を、常に完全かつ *最新* の状態に維持します。削除されるデータには、保存されている履歴よりも古いレジャー状態の古いトランザクションやバージョンがあります。 デフォルトの構成ファイルは、`rippled`サーバが2000の最新レジャーバージョンを保持し、古いデータを自動的に削除するように設定されています。 オンライン削除を使用しても、同一期間のレジャーデータを保管するのに必要なディスク容量は時間の経過とともに増加します。これは、個々のレジャーバージョンのサイズが時間とともに増加する傾向にあるためです。蓄積データが増加するペースは、古いレジャーを削除しない場合に比べると、非常にゆっくりとしています。必要なディスク容量に関する詳細は、[容量の計画](/ja/docs/infrastructure/installation/capacity-planning)をご覧ください。 ## 背景 `rippled`サーバでは[レジャー履歴](/ja/docs/concepts/networks-and-servers/ledger-history)がその *レジャーストアー* に保管されます。このデータは時間とともに蓄積されます。 レジャーストアー内ではレジャーデータの「重複排除」が行われます。つまり、バージョン間で変更されていないデータは1回だけ保存されます。レジャーストアーのレコード自体には、レコードが記録されているレジャーバージョンの記載はありません。オンライン削除処理において、古いレジャーバージョンでのみ使用されるレコードが特定されます。この処理には時間がかかり、またディスクI/Oとアプリケーションキャッシュに影響するため、レジャーを閉鎖するたびに古いデータを削除することは現実的ではありません。 ## オンライン削除の動作 オンライン削除の設定では、`rippled`サーバがレジャーストアーで使用可能な状態で維持するレジャーバージョンの数が設定されます。ただし、指定される数は目安であり、厳格に適用されるものではありません。 - サーバでは、設定された数のレジャーバージョンよりも新しいデータが削除されることはありませんが、長期にわたってサーバが稼働していない場合や、ネットワークとの同期が失われた場合には、サーバに含まれるレジャーバージョンの数が使用可能な数よりも少ないことがあります。（サーバは一部の履歴の埋め戻しを試みます。詳細は、[履歴の取得](/ja/docs/concepts/networks-and-servers/ledger-history#%E5%B1%A5%E6%AD%B4%E3%81%AE%E5%8F%96%E5%BE%97)をご覧ください。） - オンライン削除の自動実行が設定されている場合、設定されているレジャーバージョンの数の2倍を超える数まで保存できる可能性があります。（オンライン削除を実行するたびに、保管されるレジャーバージョンの数が削減され、設定数に近くなります。） ＰＣサーバがビジーのためオンライン削除が遅延すると、レジャーバージョンが蓄積し続けることがあります。正常に動作している場合には、サーバ内のレジャーバージョン数が設定された数の2倍に達した時点でオンライン削除が開始されますが、さらにいくつかのレジャーバージョンが蓄積するまではオンライン削除が完了しないことがあります。 - 指示による削除が有効な場合、管理者が[can_deleteメソッド](/ja/docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/can_delete)を呼び出すまで、サーバが取得および作成したすべてのレジャーバージョンがサーバに保存されます。 サーバに保存されるデータ量は、[can_delete](/ja/docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/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`は引き続きレジャーを閉鎖します。この場合、サーバには未検証の閉鎖済みレジャーが多数蓄積されます。このような未検証レジャーは、オンライン削除の実行までにサーバに保持される *検証済み* レジャーの数には影響しません。 ### オンライン削除の中断 [サーバの状態](/ja/docs/references/http-websocket-apis/api-conventions/rippled-server-states)が`full`より優先順位の低い状態になると、オンライン削除は自動的に停止します。この場合、サーバはプレフィクス`SHAMapStore::WRN`が付いたログメッセージを書き込みます。サーバは完全に同期された後、次の検証済みレジャーバージョン以降からオンライン削除の再開を試みます。 サーバを停止した場合や、オンライン削除の実行中にサーバがクラッシュした場合には、サーバが再起動し、完全に同期されれば、オンライン削除が再開されます。 オンライン削除を一時的に無効にするには、引数`never`を指定した[can_deleteメソッド](/ja/docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/can_delete)を使用できます。この変更は、[can_delete](/ja/docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/can_delete) をもう一度呼び出してオンライン削除を再度有効にするまで保持されます。オンライン削除の実行時点の制御についての詳細は、[指示による削除](#%E6%8C%87%E7%A4%BA%E3%81%AB%E3%82%88%E3%82%8B%E5%89%8A%E9%99%A4)をご覧ください。 ## 設定 オンライン削除に関連する設定は以下のとおりです。 - **`online_delete`** - 維持する検証済みレジャーバージョンの数を指定します。サーバは、この数よりも古いレジャーバージョンをすべて定期的に削除します。数を指定しなければ、レジャーは削除されません。 デフォルトの構成ファイルでは、この値は2000に設定されています。この値に256未満の数は設定はできません。これは、[手数料投票](/ja/docs/concepts/consensus-protocol/fee-voting)や[Amendmentプロセス](/ja/docs/concepts/networks-and-servers/amendments#amendment%E3%83%97%E3%83%AD%E3%82%BB%E3%82%B9)などのイベントで一度に更新されるレジャーの数が256であるためです。 **注意:**`online_delete`を無効にして`rippled`を実行し、その後`online_delete`を有効にしてサーバを再起動すると、`online_delete`が無効の間にサーバがダウンロードした既存のレジャー履歴は無視されますが、削除されません。ディスク容量を節約するには、`online_delete`設定の変更後にサーバを再起動する前に、既存の履歴を削除します。 - **`[ledger_history]`** - 検証済みレジャーの数（`online_delete`の値以下）を指定します。サーバの検証済みレジャーバージョンの数がこの数よりも少ない場合、ピアからデータを取得してバージョンを埋め戻す操作が試行されます。 この設定のデフォルト値はレジャー256個です。 次の図は、`online_delete`設定と`ledger_history`設定の関係を示します。 [](/assets/online_delete-vs-ledger_history.d5628e5adad52c37547a79ccc6fa136505840f5ffe7a6df14b6ddd8f4dd1f0ba.ac57e6ef.svg) - **`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の仕組みを示します。 [](/assets/fetch_depth.ja.c8a2c0108807f6799910e67440215e305620d8ba9e4f96e9b4bfe2f6fdc47b58.ac57e6ef.svg) さまざまな量の履歴の保管に必要なディスク容量の見積もりについては、[容量の計画](/ja/docs/infrastructure/installation/capacity-planning#%E3%83%87%E3%82%A3%E3%82%B9%E3%82%AF%E5%AE%B9%E9%87%8F)をご覧ください。 ### 指示による削除 デフォルトの構成ファイルでは、オンライン削除が定期的に自動で実行されるように設定されています。構成ファイルに`online_delete`間隔が指定されていない場合、オンライン削除は実行されません。構成ファイルで`advisory_delete`設定が有効になっている場合、オンライン削除は、管理者が[can_deleteメソッド](/ja/docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/can_delete)を使用してオンライン削除をトリガーしたときにのみ実行されます。 指示による削除とスケジュール済みジョブを使用すれば、閉鎖済みレジャーバージョン数の代わりに、時刻に基づいて自動削除をトリガーできます。サーバの使用率が高い場合、オンライン削除によって負荷が追加されるとサーバの処理が遅延し、コンセンサスネットワークと一時的に非同期になることがあります。この場合は、指示による削除を使用して、オンライン削除をオフピーク期間にのみ実行するようにスケジュールできます。 指示による削除はその他の目的でも使用できます。たとえば、トランザクションデータを削除する前に、そのデータが別のサーバにバックアップされていることを手動で確認できます。あるいは、トランザクションデータを削除する前に、別のタスクによるそのデータの処理が完了していることを手動で確認できます。 `can_delete` API メソッドは、構成ファイルで `advisory_delete` が有効になっている場合は、一般的な自動削除または特定のレジャーバージョンまでの自動削除を有効または無効にできます。`rippled`サーバの再起動前に構成ファイルで`advisory_delete`を無効にしている場合を除き、これらの設定はサーバを再起動しても維持されます。 ## 仕組み オンライン削除では2つのデータベースが作成されます。このため、「古い」読み取り専用データベースと、書き込み可能な「現行」データベースが常に存在します。`rippled`サーバはいずれかのデータベースからオブジェクトを読み取ることができます。このため、現行レジャーバージョンにはいずれかのデータベースのオブジェクトが含まれます。レジャーバージョン間でレジャー内のオブジェクトに変更がない場合、そのオブジェクトのコピーが1つだけデータベースに残ります。これにより、オブジェクトのコピーが重複してサーバに保存されることはありません。レジャーバージョンの更新によりオブジェクトが変更されると、サーバは変更されたオブジェクトを「新しい」データベースに保存し、古いバージョンのオブジェクト（古いレジャーバージョンで使用されているオブジェクト）は「古い」データベースに残ります。 オンライン削除を実行する場合、サーバはまず、最も古いレジャーバージョンの中から保持するものを確認し、そのレジャーバージョンのすべてのオブジェクトを読み取り専用の「古い」データベースから「現行」データベースにコピーします。これにより、「現行」データベースには、選択したレジャーバージョンとそれ以降のすべての新しいバージョンで使用されるオブジェクトがすべて含まれることになります。次に、サーバは「古い」データベースを削除し、既存の「現行」データベースを「古い」読み取り専用データベースにします。これ以降、サーバは新しい「現行」データベースを始動し、新たな変更をすべてこのデータベースに保存します。 [](/assets/online-deletion-process.ja.2ae0df084ebf1a57a807116ad5276e8df3d527cc4add68290fbad74800a00ed0.ac57e6ef.svg) ## 関連項目 - [容量の計画](/ja/docs/infrastructure/installation/capacity-planning) - [can_deleteメソッド](/ja/docs/references/http-websocket-apis/admin-api-methods/logging-and-data-management-methods/can_delete) - APIリファレンス資料 - [オンライン削除の設定](/ja/docs/infrastructure/configuration/data-retention/configure-online-deletion) - [指示による削除の設定](/ja/docs/infrastructure/configuration/data-retention/configure-advisory-deletion) - [完全な履歴の設定](/ja/docs/infrastructure/configuration/data-retention/configure-full-history)