Reboxetine (ripple) Historical fragment

when the server runs, they naturally generate a database that contains data about the ledger that was witnessed or obtained during the network run time. Each rippled server stores the ledger data in its ledger store, but the online delete logic rotates those databases when the number of ledger accounts stored exceeds the configured space limit.

Historical fragmentation The transaction history of the XRP ledger is dispersed into segments called fragments between the servers in the XRP ledger network. Fragmentation is a series of ledger accounts. A rippled server stores the ledger in the same way in ledger storage and fragmented storage.

With the historical fragmentation feature, a single rippled server can help store historical data without having to store the entire (terabytes) history. Fragmented storage does not replace the ledger storage, but the reliable path of distributed ledger history through XRP Ledger network.

get and share history slices

Rippled servers can only be configured to acquire and store historical fragmentation
。 For these servers, start acquiring the branch after synchronizing with the network and backfilling the ledger history to the configured number of recent ledger transactions. During a lower network activity, rippled is set to maintain a server's server shard_db randomly select a fragment to add to its fragmented storage. In order to increase the probability of the uniform distribution of the network ledger history records, random selection of fragmentation is carried out, and the current fragmentation is not specially considered.

When you select a fragment, the ledger acquisition process first obtains the sequence of the last ledger in the fragment and then categorizes it backwards. The retrieval process begins with the server checking data locally. For data that is not available, the server requests data from the peer rippled server. Servers that have data available during the requested time period respond to their history. The requesting server combines these responses to create a fragment. When it contains all the ledger in a specific range, the fragment is completed.

If the rippled server does not have enough space before it is fully fetched, it stops its retrieval process until there is enough room to continue. After that, the recently completed fragment may replace the older fragment. If there is sufficient disk space, the rippled server acquires other randomly selected slices to add to the fragmented storage until the maximum allocated disk space for fragmentation (MAX_SIZE_GB) is reached. XRP Ledger network data integrity

The history of all ledger transactions is shared by the server, and they agree to retain a specific range of historical ledger. This allows the server to confirm that they have all the data they agree to maintain and generate a proof tree or ledger increment. Because rippled configured with historical fragmentation servers randomly select the slices they store, all the history of closed ledgers is stored in the normal distribution curve, increasing the likelihood that the XRP ledger network will maintain the average maintenance history. Fragmented Storage Configuration

To configure the fragmentation of your rippled store ledger history, shard_db Add a section to the Rippled.cfg file. Fragment Configuration Example

The following fragment in the sample Rippled.cfg file shows the configuration fields that add fragmentation to the rippled server:

[shard_db]
Type=nudb
path=/var/lib/rippled/db/shards/nudb
max_size_gb=50

Tip: Ripple recommends using NUDB as a fragment storage (TYPE=NUDB). NUDB uses fewer file handles than Rocksdb. ROCKSDB uses memory that varies with the size of the storage data, which may require excessive memory overhead.

Tip: Although validator and trace (or inventory) rippled servers can be configured to use historical fragmented storage, Ripple recommends adding historical fragmentation only for non-validator rippled servers to reduce the cost of the validator. If you run the validator and you want to use the partition Management ledger history, run rippled a separate server that enables fragmentation.

For more information, refer to [shard_db] in the sample RIPPLED.CFG configuration sample. Adjust Fragmented storage

The

Determine the appropriate size of the fragmented storage requires careful consideration. When determining the size of a fragmented storage, consider the following points: Although redundant, you can save all ledger history in the ledger store and the history slice store. A valid configuration may limit the ledger storage to the most recent history. Because the current fragmentation may be selected for storage, the ledger storage history should be at least twice times the size of the ledger for each fragment, and it would be wasteful to retrieve the data again. The time it takes, the number of file handles, and memory cache usage are directly affected by size. Each fragment contains 2 ^ 14 Ledger (16384). Based on the age of fragmentation, fragmentation occupies about 200MB to 4GB. Older slices were smaller because there were fewer activities in the XRP ledger at that time.