1.概要
如果没有设置online deletion,那么Rippled Server的本地数据库大小将会无限增长。为了释放磁盘空间，那种情况应该被制止并且那些数据库文件应该被手动删除。online deletion可以在不引起Rippled Server正常运行的情况下帮助消减数据库的大小，这个特性主要在以下的源文件实现：
https://github.com/ripple/rippled/blob/develop/src/ripple/app/misc/SHAMapStoreImp.cpp
online deletion在rippled版本0.27.0发布之后就可以使用了。
online deletion是对创建账本和常规存储特性的回应？ ？每一个账本使用诸如RocksDB这样键值对存储形式存储在磁盘上，并作为一系列记录的集合。每一个新的账本都是在 之前所有的账本记录基础上产生的，包括前一个从最新共识中诞生的账本。所有未被改变的记录都会被保留下来。键值数据库里的记录是无法区分的，因为它们都和特定的账本相关联。当前Rippled Server账本里的所有记录必须存在于磁盘上。任何删除操作必须确保没有当前账本里的记录被影响。online deletion routine确保了没有记录被从当前的账本里移除。
由于磁盘上的记录不是根据账本来组织的，确保记录被安全删除的机制就是围绕着每个？？账本走，复制它里面的所有数据到一个新的键值数据库里。这是一个消耗时间的过程，在每一个账本被打包之前？？是不可能带着？？完成的。因此，账本记录的复制工作由一个独立的线程来做，并且每隔一段时间执行一次，这个间隔时间可配置。每一次的online deletion事件确保将来需要的所有记录都被复制到了一个新的键值数据库，保留了所需的所有数据，包括前一个间隔的，并且删除了数据优先级。为了细粒度的控制，有一个可选的机制，就是利用管理员的rpc调用来激活online deletion事件。
存储在内部SQLite表里的记录是根据账本索引来删除的，并且对应于从键值存储中删除的记录。
2. 部署
Online deletion在[node_db]配置节点有两个关键的配置项，其一，[online_delete]接受一个整数值用来设定Online deletion事件中的账本数。这个值必须大于256，以确保能够维持瑞波对等网络的稳定性。还有个关键的可选配置项[advisory_delete,它接受管理员命令来提交一个删除命令。但它并不是[online_delete]间隔的重载？？只要它的值设为大于0，就意味着该项已被打开。
Online deletion在任何时刻都是用两个不同的键值数据库(相同种类)在磁盘上存储数据，并且不引用任何已经存在的键值存储。因此，一个已经存在的键值存储应该在Online deletion实现前 被移除掉，包括账本和交易的SQLite数据库也应该被移除。其他的数据库可以被单独保留，但所有的账本和交易的数据都将从头开始。
Online deletion间隔必须大于或等于[ledger_history]的值，否则rippled server会启动失败。[fetch_depth]值必须小于或等于[online_delete]的值，如果两个值不同，rippled server将强制将[fetch_depth]值设为和Online deletion间隔值相同，然后正常启动。
-如果rippled server正在运行，停止它
-编辑服务配置文件rippled.cfg的[node_db]块，将想要设置的有关Online deletion的参数包含进去，例：
[ledger_history]
1024
[node_db]
type=rocksdb
path=/var/db/rippled/db/nodestore
online_delete=1024
advisory_delete=1
-移除已存在数据
sudo rm /var/db/rippled/db/ledger.db*
/var/db/rippled/db/transaction.db*
/var/db/rippled/db/nodestore/*
-重启再启动rippled
3.实施
在Online deletion事件执行的时候，日志信息都会被记录下来。你可以在[debug_logfile]的配置项里找到节点[SHAMapStore]配置或找到文件所在的路径。
Online deletion执行的时候可能会影响rippled的执行效率，因为需要占用IO资源和缓存清理。因此，需要在Online deletion执行期间经常去检查下rippled的健康状态。如果server_state是除了full以外的其他状态或者validated ledger age至少是60 秒，那么Online deletion事件将会停止。在这种情况下，Online deletion事件将会在下一个 被验证过的账本打包前 被触发。这样一来，Online deletion将会在后台以最小影响运行。如果一次Online deletion被中止了，那么debug日志里会记录一条日志。你可以通过关键词"SHAMapStore::WRN"来找到。同样的，如果rippled 在Online deletion执行期间被关闭了或者崩溃了
，那么Online deletion将会在rippled重启后的下一个验证过的账本打包前启动。
始终保留的数据量将基于已配置的online_delete间隔的最小值与三个在线删除事件之间获取的总数据之间的分类帐数量。如果没有设置advisory_delete，那么上限大约是online_delete间隔的两倍。另一方面，如果设置了advisory_delete并且每天触发一次online_deletion，那么在线数据量将介于一到两整天的数据之间。
----------------------------------以下google机翻------------------------------------
在该complete_ledgers领域server_infoRPC调用随时指示分类帐的精确范围。SQLite中的分类帐和事务数据库的数据大小将随着时间的推移稳步增长，但速度相对较慢。在线删除后，磁盘上的这些SQLite文件不会缩小，但文件中的空间将可用于新数据。这些文件只会随着分类帐规模的增长而增长。重启后，rippled将执行SQLite VACUUM操作以最小化这些文件的大小。
联机删除状态保留在state.db[database_path]目录中调用的SQLite数据库文件中。键值数据库位置，最后一个旋转的分类帐索引和advisory_delete分类帐（如果有）都存储在此数据库中。如果磁盘上的键值数据库与state.db中列出的值不匹配，则rippled将向控制台发出错误而不启动。在这种情况下，发生了某种类型的腐败。path在重新启动rippled之前，必须删除state.db文件和[node_db]中目录的内容。rippled将重新开始，没有键值存储数据。如果需要，请在执行此活动之前备份state.db和[node_db]路径。
【Rippled Server无法正常运行的可能原因 以及应对办法】
【Online delete state is retained in an SQLite database file called state.db in the [database_path] directory. Both key-value database locations, the last rotated ledger index, and the advisory_delete ledger, if any, are all stored in this database. If the key-value databases on disk do not match those listed in state.db, then rippled will emit an error to the console and not start. In this case, some type of corruption has occurred. It is necessary to remove the state.db file and the contents of the path directory in [node_db] before restarting rippled. rippled will start afresh with no key-value store data. If desired, make backups of state.db and the [node_db] path prior to performing this activity.】
例子[通常 只读数据库用来存放即将销毁的数据， 可写数据库 用来同步设定范围的区块]
使用advisory_delete
调用触发在线删除事件所需的管理RPC调用can_delete。使用上述配置，每天早上凌晨1点五分钟触发在线删除事件，将以下内容放入能够在本地运行波纹的用户的crontab中：
5 1 * * * --conf can_delete now
要告诉rippled它可能删除小于或等于11,500,000的任何分类帐，请使用以下命令行命令：
--conf can_delete 11500000
要禁用在线删除（手动更改此设置），请使用以下命令行命令：
--conf can_delete never
要求不再需要can_delete管理RPC调用进行在线删除：
--conf can_delete总是
提醒：无论advice_delete和can_delete设置如何，在线删除仅在自上次删除（或自初始波纹启动以来）的online_delete间隔之后发生。
在线删除流程 - 没有advisory_delete【自动的增量2倍，删除另一半，保持一半时刻是可用的】
假设当前分类帐为1000，并且rippled.cfg具有以下条件：
[ledger_history] 256 [node_db] 。 。 。 online_delete = 500 advisory_delete = 0
在线删除流程：
- 获取分类帐744 - 1000
- 满足[ledger_history]
- 分类帐存储在可写数据库中。
- 进度总额为1500
- 不要删除分类帐，而是将当前可写数据库转移到只读数据库。
- 只读数据库包含744-1500
- 新的当前可写数据库拥有1501+的所有内容
- 进展分类账到2000年
- 删除分类帐744-1500（只读数据库）。
- 创建一个新的可写数据库。
- 可写数据库（1501-2000）变为只读。
- 新的当前可写数据库拥有2001年以上的所有内容
- 进度总额为2500
在线删除流程 - 使用advisory_delete【保持增长，不自动删除，除非管理眼call 删除特定的参数】
假设当前分类帐为1000，并且rippled.cfg具有以下条件：
[ledger_history] 256 [node_db] 。 。 。 online_delete = 500 advisory_delete = 1
在线删除流程：
- 在分类账1000中第一次与网络同步
- 在分类帐1000中设置旋转标记
- 获取分类帐744 - 1000（满足[ledger_history]）
- 分类帐存储在可写数据库中。
- 进度总额为1500
- 不要删除分类帐。在使用最小值1000，“now”或“always”调用can_delete之前，不要旋转分类帐。
- 如果不是，则只读数据库保持为空。
- 当前可写数据库包含744-1500
- 进展分类账到2000年
- 不要删除分类帐。如前所述，在调用can_delete之前不要旋转分类帐。
- 如果不是，则只读数据库保持为空
- 当前可写数据库包含744-2000
- 【重点开始了】在分类帐2149处使用参数1200调用can_delete
--conf can_delete 1200
-
-
- 在线删除例程在下一个经过验证的分类帐2150处激活。
- 丢弃可读数据库（到目前为止已空）
- 带有分类帐744-2150的可写数据库变为只读。
- 创建一个新的可写数据库，并存储分类帐2151+。
- 最后一次轮换的标记现在是2151。
-
当另外500个分类帐经过时，将发生下一轮旋转，并且至少使用2150的值调用can_delete。
在线删除流程 - 每天安排建议删除
在cron中设置以下内容，在上午12:05执行：
5 0 * * * / usr / sbin / rippled --conf /etc/rippled/rippled.cfg can_delete now
假设当前分类帐为1000，并且rippled.cfg具有以下条件：
[ledger_history] 256 [node_db] 。 。 。 online_delete = 500 advisory_delete = 1
在cron中设置以下内容，在上午12:05执行：
5 0 * * * / usr / sbin / rippled --conf /etc/rippled/rippled.cfg can_delete now
在线删除流程：
- 在分类账1000中第一次与网络同步
- 在分类帐1000中设置旋转标记
- 获取分类帐744 - 1000（满足[ledger_history]）
- 分类帐存储在可写数据库中，直到至少处理了500个分类帐，直到适当地调用can_delete。
- 一整天大约有18,000个封闭式分类帐。
- 上午12:05，cron执行“can_delete now”RPC调用。假设下一个经过验证的分类帐为10000。
- 当前可写数据库包含分类帐744-10000。它变为只读，并创建新的可写数据库。
- 最后一次旋转的标记设置为10000。
- 当至少500个分类帐经过时，将发生下一个删除例程，并且至少调用can_delete值10000或“now”或“always”。
- 第二天早上12:05，cron执行“可以立即删除”。下一个经过验证的分类帐为28000，并且像以前一样创建，移动和删除数据库。
在线删除过程 - 使用advisory_delete文本命令
- never：删除例程根本不会执行，除非被另一个can_delete调用覆盖，或者在没有设置并重新启动advisory_delete的情况下重新配置了rippled。
- always：删除例程将在使用online_delete命令配置的每个时间间隔发生，并且不需要将来的can_delete调用。可以用与can_delete的“never”参数相同的方式覆盖。
- now：删除例程将在下一个已验证的时间间隔内发生，该时间间隔也等于或超过自上次执行例程以来的online_delete时间间隔。除非can_delete再次触发，否则不会再发生任何删除。