オンライン削除
オンライン削除機能により、rippled
サーバはレジャーの古いバージョンのローカルコピーを削除できます。これにより、時間とともにディスク使用量が急増しないようにできます。デフォルトの構成ファイルにはオンライン削除の自動実行が設定されていますが、指示があった場合にのみオンライン削除を実行するようにも設定できます。
サーバは、レジャーおよびそのすべての残高と設定を、常に完全かつ 最新 の状態に維持します。削除されるデータには、保存されている履歴よりも古いレジャー状態の古いトランザクションやバージョンがあります。
デフォルトの構成ファイルは、rippled
サーバが2000の最新レジャーバージョンを保持し、古いデータを自動的に削除するように設定されています。
ヒント: オンライン削除を使用しても、同一期間のレジャーデータを保管するのに必要なディスク容量は時間の経過とともに増加します。これは、個々のレジャーバージョンのサイズが時間とともに増加する傾向にあるためです。蓄積データが増加するペースは、古いレジャーを削除しない場合に比べると、非常にゆっくりとしています。必要なディスク容量に関する詳細は、容量の計画をご覧ください。
背景
rippled
サーバではレジャー履歴がその レジャーストアー に保管されます。このデータは時間とともに蓄積されます。
レジャーストアー内ではレジャーデータの「重複排除」が行われます。つまり、バージョン間で変更されていないデータは1回だけ保存されます。レジャーストアーのレコード自体には、レコードが記録されているレジャーバージョンの記載はありません。オンライン削除処理において、古いレジャーバージョンでのみ使用されるレコードが特定されます。この処理には時間がかかり、またディスクI/Oとアプリケーションキャッシュに影響するため、レジャーを閉鎖するたびに古いデータを削除することは現実的ではありません。
オンライン削除の動作
オンライン削除の設定では、rippled
サーバがレジャーストアーで使用可能な状態で維持するレジャーバージョンの数が設定されます。ただし、指定される数は目安であり、厳格に適用されるものではありません。
サーバでは、設定された数のレジャーバージョンよりも新しいデータが削除されることはありませんが、長期にわたってサーバが稼働していない場合や、ネットワークとの同期が失われた場合には、サーバに含まれるレジャーバージョンの数が使用可能な数よりも少ないことがあります。(サーバは一部の履歴の埋め戻しを試みます。詳細は、履歴の取得をご覧ください。)
オンライン削除の自動実行が設定されている場合、設定されているレジャーバージョンの数の2倍を超える数まで保存できる可能性があります。(オンライン削除を実行するたびに、保管されるレジャーバージョンの数が削減され、設定数に近くなります。)
PCサーバがビジーのためオンライン削除が遅延すると、レジャーバージョンが蓄積し続けることがあります。正常に動作している場合には、サーバ内のレジャーバージョン数が設定された数の2倍に達した時点でオンライン削除が開始されますが、さらにいくつかのレジャーバージョンが蓄積するまではオンライン削除が完了しないことがあります。
指示による削除が有効な場合、管理者が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
は引き続きレジャーを閉鎖します。この場合、サーバには未検証の閉鎖済みレジャーが多数蓄積されます。このような未検証レジャーは、オンライン削除の実行までにサーバに保持される 検証済み レジャーの数には影響しません。
オンライン削除の中断
サーバの状態がfull
より優先順位の低い状態になると、オンライン削除は自動的に停止します。この場合、サーバはプレフィクスSHAMapStore::WRN
が付いたログメッセージを書き込みます。サーバは完全に同期された後、次の検証済みレジャーバージョン以降からオンライン削除の再開を試みます。
サーバを停止した場合や、オンライン削除の実行中にサーバがクラッシュした場合には、サーバが再起動し、完全に同期されれば、オンライン削除が再開されます。
オンライン削除を一時的に無効にするには、引数never
を指定したcan_deleteメソッドを使用できます。この変更は、can_delete をもう一度呼び出してオンライン削除を再度有効にするまで保持されます。オンライン削除の実行時点の制御についての詳細は、指示による削除をご覧ください。
設定
オンライン削除に関連する設定は以下のとおりです。
online_delete
- 維持する検証済みレジャーバージョンの数を指定します。サーバは、この数よりも古いレジャーバージョンをすべて定期的に削除します。数を指定しなければ、レジャーは削除されません。デフォルトの構成ファイルでは、この値は2000に設定されています。この値に256未満の数は設定はできません。これは、手数料投票やAmendmentプロセスなどのイベントで一度に更新されるレジャーの数が256であるためです。
注意:
online_delete
を無効にしてrippled
を実行し、その後online_delete
を有効にしてサーバを再起動すると、online_delete
が無効の間にサーバがダウンロードした既存のレジャー履歴は無視されますが、削除されません。ディスク容量を節約するには、online_delete
設定の変更後にサーバを再起動する前に、既存の履歴を削除します。[ledger_history]
- 検証済みレジャーの数(online_delete
の値以下)を指定します。サーバの検証済みレジャーバージョンの数がこの数よりも少ない場合、ピアからデータを取得してバージョンを埋め戻す操作が試行されます。この設定のデフォルト値はレジャー256個です。
次の図は、
online_delete
設定とledger_history
設定の関係を示します。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の仕組みを示します。
さまざまな量の履歴の保管に必要なディスク容量の見積もりについては、容量の計画をご覧ください。
指示による削除
デフォルトの構成ファイルでは、オンライン削除が定期的に自動で実行されるように設定されています。構成ファイルにonline_delete
間隔が指定されていない場合、オンライン削除は実行されません。構成ファイルでadvisory_delete
設定が有効になっている場合、オンライン削除は、管理者がcan_deleteメソッドを使用してオンライン削除をトリガーしたときにのみ実行されます。
指示による削除とスケジュール済みジョブを使用すれば、閉鎖済みレジャーバージョン数の代わりに、時刻に基づいて自動削除をトリガーできます。サーバの使用率が高い場合、オンライン削除によって負荷が追加されるとサーバの処理が遅延し、コンセンサスネットワークと一時的に非同期になることがあります。この場合は、指示による削除を使用して、オンライン削除をオフピーク期間にのみ実行するようにスケジュールできます。
指示による削除はその他の目的でも使用できます。たとえば、トランザクションデータを削除する前に、そのデータが別のサーバにバックアップされていることを手動で確認できます。あるいは、トランザクションデータを削除する前に、別のタスクによるそのデータの処理が完了していることを手動で確認できます。
can_delete
API メソッドは、構成ファイルで advisory_delete
が有効になっている場合は、一般的な自動削除または特定のレジャーバージョンまでの自動削除を有効または無効にできます。rippled
サーバの再起動前に構成ファイルでadvisory_delete
を無効にしている場合を除き、これらの設定はサーバを再起動しても維持されます。
仕組み
オンライン削除では2つのデータベースが作成されます。このため、「古い」読み取り専用データベースと、書き込み可能な「現行」データベースが常に存在します。rippled
サーバはいずれかのデータベースからオブジェクトを読み取ることができます。このため、現行レジャーバージョンにはいずれかのデータベースのオブジェクトが含まれます。レジャーバージョン間でレジャー内のオブジェクトに変更がない場合、そのオブジェクトのコピーが1つだけデータベースに残ります。これにより、オブジェクトのコピーが重複してサーバに保存されることはありません。レジャーバージョンの更新によりオブジェクトが変更されると、サーバは変更されたオブジェクトを「新しい」データベースに保存し、古いバージョンのオブジェクト(古いレジャーバージョンで使用されているオブジェクト)は「古い」データベースに残ります。
オンライン削除を実行する場合、サーバはまず、最も古いレジャーバージョンの中から保持するものを確認し、そのレジャーバージョンのすべてのオブジェクトを読み取り専用の「古い」データベースから「現行」データベースにコピーします。これにより、「現行」データベースには、選択したレジャーバージョンとそれ以降のすべての新しいバージョンで使用されるオブジェクトがすべて含まれることになります。次に、サーバは「古い」データベースを削除し、既存の「現行」データベースを「古い」読み取り専用データベースにします。これ以降、サーバは新しい「現行」データベースを始動し、新たな変更をすべてこのデータベースに保存します。
関連項目
- 容量の計画
- can_deleteメソッド - APIリファレンス資料
- オンライン削除の設定
- 指示による削除の設定
- 完全な履歴の設定