mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-12-03 10:05:49 +00:00
Merge pull request #1233 from XRPLF/rippled_180
XRPL server v1.8.0 docs
This commit is contained in:
Rome Reginelli
@@ -40,6 +40,7 @@
|
||||
"1.6.0",
|
||||
"1.7.0",
|
||||
"1.7.2",
|
||||
"1.8.1",
|
||||
] %}
|
||||
|
||||
{% for v in rippled_versions %}
|
||||
|
||||
@@ -57,16 +57,18 @@ Theoretically, a `tfLostMajority` EnableAmendment pseudo-transaction could be in
|
||||
|
||||
## Amendment Voting
|
||||
|
||||
Each version of `rippled` is compiled with a list of known amendments and the code to implement those amendments. By default, `rippled` supports known amendments and opposes unknown amendments. Operators of `rippled` validators can [configure their servers](configure-amendment-voting.html) to explicitly support or oppose certain amendments, even if those amendments are not known to their `rippled` versions.
|
||||
Each version of `rippled` is compiled with a list of known amendments and the code to implement those amendments. Operators of `rippled` validators [configure their servers](configure-amendment-voting.html) to vote in favor or against each inactive amendment. Server operators can change their votes at any time. If the operator does not choose a setting for a particular amendment, the server uses a default vote which is defined in the source code. The default can change in new software releases. For example, version 2.0 of the server might understand a new amendment but vote against it by default; then version 2.1 of the server might vote in favor of the same amendment by default. [Updated in: rippled 1.8.1][]
|
||||
|
||||
To become enabled, an amendment must be supported by at least 80% of trusted validators continuously for two weeks. If support for an amendment goes below 80% of trusted validators, the amendment is temporarily rejected. The two week period starts over if the amendment regains support of at least 80% of trusted validators. (This can occur if validators vote differently, or if there is a change in which validators are trusted.) An amendment can gain and lose a majority any number of times before it becomes permanently enabled. An amendment cannot be permanently rejected, but it becomes very unlikely for an amendment to become enabled if new versions of `rippled` do not have the amendment in their known amendments list.
|
||||
To become enabled, an amendment must be supported by at least 80% of trusted validators continuously for two weeks. If support for an amendment goes below 80% of trusted validators, the amendment is temporarily rejected. The two week period starts over if the amendment regains support of at least 80% of trusted validators. (This can occur if validators vote differently, or if there is a change in which validators are trusted.) An amendment can gain and lose a majority any number of times before it becomes permanently enabled.
|
||||
|
||||
An amendment cannot be permanently rejected, but it becomes very unlikely for an amendment to become enabled if new versions of `rippled` do not have the amendment in their known amendments list. Amendments that have had their source code removed without becoming enabled are considered "Vetoed" by the network.
|
||||
|
||||
As with all aspects of the consensus process, amendment votes are only taken into account by servers that trust the validators sending those votes. <!-- TODO: link an explanation of validator list publishers when one's ready -->
|
||||
|
||||
For information on how to configure your server's amendment votes, see [Configure Amendment Voting](configure-amendment-voting.html). [Updated in: rippled 1.7.0][]
|
||||
|
||||
|
||||
### Amendment Blocked
|
||||
## Amendment Blocked
|
||||
|
||||
When an amendment gets enabled for the network after the voting process, servers running earlier versions of `rippled` that do not know about the amendment become "amendment blocked" because they no longer understand the rules of the network. Servers that are amendment blocked:
|
||||
|
||||
@@ -84,7 +86,7 @@ If your server is amendment blocked, you must [upgrade to a new version](install
|
||||
It is also possible to be amendment blocked because you connected your server to a [parallel network](parallel-networks.html) that has different amendments enabled. For example, the XRP Ledger Devnet typically has upcoming and experimental amendments enabled. If you are using the latest production release, your server is likely to be amendment blocked when connecting to Devnet. You could resolve this issue by upgrading to an unstable pre-release or nightly build, or you could [connect to a different network such as Testnet](connect-your-rippled-to-the-xrp-test-net.html) instead.
|
||||
|
||||
|
||||
#### How to Tell If Your `rippled` Server Is Amendment Blocked
|
||||
### How to Tell If Your `rippled` Server Is Amendment Blocked
|
||||
|
||||
One of the first signs that your `rippled` server is amendment blocked is an `amendmentBlocked` error that is returned [when you submit a transaction](submit.html). Here's an example `amendmentBlocked` error:
|
||||
|
||||
@@ -138,7 +140,7 @@ If your server is not amendment blocked, the `amendment_blocked` field is not re
|
||||
**Caution:** `rippled` versions older than 0.80.0 do not include the `amendment_blocked` field, even if your server is amendment blocked.
|
||||
|
||||
|
||||
#### How to Unblock an Amendment-Blocked `rippled` Server
|
||||
### How to Unblock an Amendment-Blocked `rippled` Server
|
||||
|
||||
Upgrade to the `rippled` version that supports the amendments that are causing your server to be amendment blocked. Ripple recommends that you [upgrade to the newest `rippled` version](install-rippled.html) to unblock your server and enable it to sync with the network again.
|
||||
|
||||
@@ -223,6 +225,15 @@ TrustSetAuth
|
||||
```
|
||||
|
||||
|
||||
## Retiring Legacy Code
|
||||
|
||||
After an amendment has become enabled, it can never be disabled. (To reverse protocol changes, it would be necessary to create a new amendment.) However, separate ledger chains, such as [test networks](parallel-networks.html) or [stand-alone mode](rippled-server-modes.html#stand-alone-mode) can have different sets of amendments applied. Therefore, the pre-amendment code may continue to run in those cases, and the software must work with an increasing number of combinations of amendments that may or may not be enabled on any given test network.
|
||||
|
||||
Rather than maintain the source code for all old behavior indefinitely, [XRP Ledger Standard 11d](https://github.com/XRPLF/XRPL-Standards/discussions/19) defines a process for retiring the pre-amendment code. In this process, amendments that have been enabled on the XRP Ledger Mainnet can have the pre-amendment code removed, making them apply unconditionally as part of the XRP Ledger protocol. For the XRP Ledger's [reference server implementation](the-rippled-server.html), the developers periodically chooses a cutoff date **at least 2 years** in the past, and retire pre-amendment source code for amendments that were enabled on the network before the cutoff date.
|
||||
|
||||
When pre-amendment code has been retired, the server follows the amended logic for all transactions at all times. As a result, the server is no longer guaranteed to produce historically-accurate results if you try to replay ledgers older than the cutoff date. The server prints a warning if you try to [load and replay a ledger](load-a-saved-ledger-in-stand-alone-mode.html) that is older than the cutoff date. To produce historically-accurate results, you must compile or download an old server binary that has the legacy code.
|
||||
|
||||
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
|
||||
@@ -10,11 +10,9 @@ labels:
|
||||
|
||||
[Introduced in: rippled 0.90.0][]
|
||||
|
||||
As servers run, they naturally produce a database containing data about the ledgers they witnessed or acquired during network runtime. Each `rippled` server stores that ledger data in its ledger store, but the online delete logic rotates these databases when the number of stored ledgers exceeds configured space limitations.
|
||||
As XRP Ledger servers run, they naturally produce a database containing data about the ledgers they witnessed or acquired during network runtime. Each server stores that ledger data in its _ledger store_, but [online deletion](online-deletion.html) removes old ledgers' data automatically over time. History sharding provides a separate storage system for older ledger history so that the network can divide up the work of recording the entire (multiple terabyte) history of the XRP Ledger.
|
||||
|
||||
Historical sharding distributes the transaction history of the XRP Ledger into segments, called shards, across servers in the XRP Ledger network. A shard is a range of ledgers. A `rippled` server stores ledgers in both the ledger store and the shard store in the same way.
|
||||
|
||||
Using the history sharding feature, individual `rippled` servers can contribute to storing historical data without needing to store the entire (multiple terabyte) history. A shard store does not replace a ledger store, but implements a reliable path towards distributed ledger history across the XRP Ledger Network.
|
||||
Historical sharding distributes the transaction history of the XRP Ledger into segments, called shards, across servers in the XRP Ledger network. A shard is a range of ledgers. A server uses mostly the same format for ledgers in both the ledger store and the shard store, but the two stores are separate.
|
||||
|
||||
[](img/xrp-ledger-network-ledger-store-and-shard-store.png)
|
||||
|
||||
@@ -22,15 +20,18 @@ Using the history sharding feature, individual `rippled` servers can contribute
|
||||
|
||||
## Acquiring and Sharing History Shards
|
||||
|
||||
`rippled` servers acquire and store history shards only if configured to do so. For those servers, acquiring shards begins after synchronizing with the network and backfilling ledger history to the configured number of recent ledgers. During this time of lower network activity, a `rippled` server set to maintain a `shard_db` randomly chooses a shard to add to its shard store. To increase the probability for an even distribution of the network ledger history, shards are randomly selected for acquisition, and the current shard is given no special consideration.
|
||||
Servers acquire and store history shards only if configured to do so. Acquiring shards begins after synchronizing with the network and backfilling ledger history to the configured number of recent ledgers. During this time of lower network activity, a server set to maintain a shard database randomly chooses a shard to add to its shard store. To increase the probability for an even distribution of the network ledger history, shards are randomly selected for acquisition, and the most recent shard is given no special consideration.
|
||||
|
||||
Once a shard is selected, the ledger acquire process begins by fetching the sequence of the last ledger in the shard and working backwards toward the first. The retrieval process begins with the server checking for the data locally. For data that is not available, the server requests data from its peer `rippled` servers. Those servers that have the data available for the requested period respond with their history. The requesting server combines those responses to create the shard. The shard is complete when it contains all the ledgers in a specific range.
|
||||
Once a shard is selected, the ledger acquire process begins by fetching the sequence of the last ledger in the shard and working backwards toward the first. The retrieval process begins with the server checking for the data locally. For data that is not available, the server requests data from its peers. Those servers that have the data available for the requested period respond with their history. The requesting server combines those responses to create the shard. The shard is complete when it contains all the ledgers in a specific range.
|
||||
|
||||
If a `rippled` server runs out of space before completely acquiring a shard, it stops its retrieval process until it has space available to continue. After that point, the most recently completed shard may replace an older shard. If there is sufficient disk space, the `rippled` server acquires additional randomly selected shards to add to the shard store until reaching the maximum allocated disk space for shards (`max_size_gb`).
|
||||
The server selects and downloads additional shards until it reaches the maximum number of shards it is configured to store. If a server runs out of space before completely acquiring a shard, it stops its retrieval process until it has space available to continue.
|
||||
|
||||
## XRP Ledger Network Data Integrity
|
||||
|
||||
The history of all ledgers is shared by servers agreeing to keep particular ranges of historical ledgers. This makes it possible for servers to confirm that they have all the data they agreed to maintain, and produce proof trees or ledger deltas. Since `rippled` servers that are configured with history sharding randomly select the shards that they store, the entire history of all closed ledgers is stored in a normal distribution curve, increasing the probability that the XRP Ledger Network evenly maintains the history.
|
||||
The history of all ledgers is shared by servers agreeing to keep particular ranges of historical ledgers. This makes it possible for servers to confirm that they have all the data they agreed to maintain, and produce "proof trees" or "ledger deltas" which shows how each ledger in the blockchain's history was the result of applying transactions to the previous state. Since servers that are configured with history sharding randomly select the shards that they store, the entire history of all closed ledgers is stored in a normal distribution curve, increasing the probability that the XRP Ledger Network evenly maintains the history.
|
||||
|
||||
History shards are recorded in a deterministic format, so that any two servers assembling the same shard produce binary-identical data regardless of what order they acquired the data and where they got it from. This makes it possible to compare checksums or cryptographic hashes of the shard data to verify the integrity of the data, and it is possible to share and import history shards through other formats. (For example, you could download shard data using Bittorrent or acquire physical media with the shard data pre-loaded on it, and verify that it matches the data that can be downloaded from the network.) [New in: rippled 1.8.1][]
|
||||
|
||||
|
||||
## See Also
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@ labels:
|
||||
---
|
||||
# Peer Protocol
|
||||
|
||||
Servers in the XRP Ledger communicate to each other using the XRP Ledger peer protocol, also known as RTXP.
|
||||
Servers in the XRP Ledger communicate to each other using the XRP Ledger peer protocol.
|
||||
|
||||
The peer protocol is the main mode of communication between servers in the XRP Ledger. All information about the behavior, progress, and connectivity of the XRP Ledger passes through the peer protocol. Examples of peer-to-peer communications include all of the following:
|
||||
|
||||
@@ -17,7 +17,7 @@ The peer protocol is the main mode of communication between servers in the XRP L
|
||||
- Requesting ledger data from historical ledgers, or providing that data.
|
||||
- Proposing a set of transactions for consensus, or sharing the calculated outcome of applying a consensus transaction set.
|
||||
|
||||
To establish a peer-to-peer connection, one server connects to another via HTTPS and requests an [HTTP upgrade](https://tools.ietf.org/html/rfc7230#section-6.7) to switch to RTXP. (For more information, see the [Overlay Network](https://github.com/ripple/rippled/blob/906ef761bab95f80b0a7e0cab3b4c594b226cf57/src/ripple/overlay/README.md#handshake) article in the [`rippled` repository](https://github.com/ripple/rippled).)
|
||||
To establish a peer-to-peer connection, one server connects to another via HTTPS and requests an [HTTP upgrade](https://tools.ietf.org/html/rfc7230#section-6.7) to switch to the `XRPL/2.0` protocol (formerly `RTXP/1.2`). (For more information, see the [Overlay Network](https://github.com/ripple/rippled/blob/96bbabbd2ece106779bb544aa0e4ce174e99fdf6/src/ripple/overlay/README.md#handshake) article in the [`rippled` repository](https://github.com/ripple/rippled).)
|
||||
|
||||
## Peer Discovery
|
||||
|
||||
|
||||
@@ -30,6 +30,7 @@ Use these methods to manage log levels and other data, such as ledgers.
|
||||
* **[`ledger_request`](ledger_request.html)** - Query a peer server for a specific ledger version.
|
||||
* **[`log_level`](log_level.html)** - Get or modify log verbosity.
|
||||
* **[`logrotate`](logrotate.html)** - Reopen the log file.
|
||||
* **[`node_to_shard`](node_to_shard.html)** - Copy data from the ledger store to the shard store.
|
||||
|
||||
|
||||
## [Server Control Methods](server-control-methods.html)
|
||||
|
||||
@@ -118,19 +118,20 @@ The response follows the [standard format][], with a successful result containin
|
||||
| `Field` | Type | Description |
|
||||
|:------------------|:-------|:------------------------------------------------|
|
||||
| `complete_shards` | String | _(May be omitted)_ The range of [history shards](history-sharding.html) that are available on the local server. This may be an empty string, or a disjointed range. For example, `1-2,5,7-9` indicates that shards 1, 2, 5, 7, 8, and 9 are available. Omitted if this server does not have history sharding enabled. |
|
||||
| `peers` | Array | List of **Peer Shard Objects** (see below) describing which history shards each peer has available. |
|
||||
| `peers` | Array | _(May be omitted)_ List of **Peer Shard Objects** (see below) describing which history shards each peer has available. The response omits this field if no peers within the number of hops specified by `limit` have any shards. |
|
||||
|
||||
#### Peer Shard Objects
|
||||
|
||||
Each member of the `peers` array of the response is an object that describes one server in the peer-to-peer network. The list only includes peers that have at least one complete [history shard](history-sharding.html) available. Each object in the array has the following fields:
|
||||
|
||||
|
||||
| `Field` | Type | Description |
|
||||
|:----------|:-------|:--------------------------------------------------------|
|
||||
| `complete_shards` | String | The range of history shards this peer has available. This may be disjointed. For example, `1-2,5,7-9` indicates that shards 1, 2, 5, 7, 8, and 9 are available. |
|
||||
| `ip` | String | _(May be omitted)_ The IP address of the peer this object describes. This may be an IPv4 or IPv6 address. Omitted if this is a [private peer](peer-protocol.html#private-peers). |
|
||||
| `complete_shards` | String | The range of complete history shards this peer has available. This may be disjointed. For example, `1-2,5,7-9` indicates that shards 1, 2, 5, 7, 8, and 9 are available. |
|
||||
| `incomplete_shards` | String | _(May be omitted)_ A comma-separated list of history shards this peer has partially downloaded, and percent completion for each. For example, `1:50,2:25` indicates that shard 1 is 50% downloaded and shard 2 is 25% downloaded. [New in: rippled 1.8.1][] |
|
||||
| `public_key` | String | _(Omitted unless the request specified `"public_key": true`)_ The public key this peer uses for peer-to-peer communications, in the XRP Ledger's [base58 format](base58-encodings.html). |
|
||||
|
||||
The `ip` field is no longer provided. [Removed in: rippled 1.8.1][]
|
||||
|
||||
|
||||
### Possible Errors
|
||||
|
||||
|
||||
@@ -0,0 +1,122 @@
|
||||
---
|
||||
html: node_to_shard.html
|
||||
parent: logging-and-data-management-methods.html
|
||||
blurb: Copy data from the ledger store into the shard store.
|
||||
labels:
|
||||
- Data Retention
|
||||
---
|
||||
# node_to_shard
|
||||
[[Source]](https://github.com/ripple/rippled/blob/develop/src/ripple/rpc/handlers/NodeToShard.cpp "Source")
|
||||
|
||||
The `{{currentpage.name}}` method manages copying data from the ledger store to the [shard store](history-sharding.html). It can start, stop, or check the status of copying the data.
|
||||
|
||||
_The `{{currentpage.name}}` method is an [admin method](admin-rippled-methods.html) that cannot be run by unprivileged users._
|
||||
|
||||
|
||||
### Request Format
|
||||
|
||||
An example of the request format:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```json
|
||||
{
|
||||
"command": "{{currentpage.name}}",
|
||||
"action": "start"
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```json
|
||||
{
|
||||
"method": "{{currentpage.name}}",
|
||||
"params": [{
|
||||
"action": "start"
|
||||
}]
|
||||
}
|
||||
```
|
||||
|
||||
*Commandline*
|
||||
|
||||
```sh
|
||||
#Syntax: {{currentpage.name}} start|stop|status
|
||||
rippled {{currentpage.name}} start
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
The request includes the following parameters:
|
||||
|
||||
| `Field` | Type | Description |
|
||||
|:---------|:-------|:---------------------------------------------------------|
|
||||
| `action` | String | Either `start`, `stop` or `status` depending on what action to take. |
|
||||
|
||||
|
||||
### Response Format
|
||||
|
||||
An example of a successful response:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```json
|
||||
{
|
||||
"result": {
|
||||
"message": "Database import initiated..."
|
||||
},
|
||||
"status": "success",
|
||||
"type": "response"
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```json
|
||||
{
|
||||
"result" : {
|
||||
"message" : "Database import initiated...",
|
||||
"status" : "success"
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
*Commandline*
|
||||
|
||||
```json
|
||||
Loading: "/etc/rippled.cfg"
|
||||
Connecting to 127.0.0.1:5005
|
||||
|
||||
{
|
||||
"result" : {
|
||||
"message" : "Database import initiated...",
|
||||
"status" : "success"
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
The response follows the [standard format][], with a successful result containing the following fields:
|
||||
|
||||
| `Field` | Type | Description |
|
||||
|:----------|:-------|:--------------------------------------------------------|
|
||||
| `message` | String | A human-readable message indicating the action taken in response to the command. |
|
||||
|
||||
|
||||
### Possible Errors
|
||||
|
||||
- Any of the [universal error types][].
|
||||
- `internal` - If you attempt an invalid operation like checking the status of a copy when one isn't running.
|
||||
- `notEnabled` - If the server is not configured to store [history shards](history-sharding.html).
|
||||
- `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing.
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -89,7 +89,7 @@ The `streams` parameter provides access to the following default streams of info
|
||||
- `server` - Sends a message whenever the status of the `rippled` server (for example, network connectivity) changes
|
||||
- `validations` - Sends a message whenever the server receives a validation message, regardless of if the server trusts the validator. (An individual `rippled` declares a ledger validated when the server receives validation messages from at least a quorum of trusted validators.)
|
||||
|
||||
**Note:** The following streams are not available from servers in [Reporting Mode][]: `server`, `manifests`, `validations`, `peer_status`, `consensus`. Reporting Mode servers return the error `reportingUnsupported` if you request one of these streams.
|
||||
**Note:** The following streams are not available from servers in [Reporting Mode][]: `server`, `peer_status`, `consensus`. Reporting Mode servers return the error `reportingUnsupported` if you request one of these streams. [Updated in: rippled 1.8.1][]
|
||||
|
||||
Each member of the `books` array, if provided, is an object with the following fields:
|
||||
|
||||
@@ -215,18 +215,21 @@ The fields from a validations stream message are as follows:
|
||||
| `Field` | Type | Description |
|
||||
|:------------------------|:-----------------|:--------------------------------|
|
||||
| `type` | String | The value `validationReceived` indicates this is from the validations stream. |
|
||||
| `amendments` | Array of Strings | (May be omitted) The [amendments](amendments.html) this server wants to be added to the protocol. [New in: rippled 0.32.0][] |
|
||||
| `base_fee` | Integer | (May be omitted) The unscaled transaction cost (`reference_fee` value) this server wants to set by [Fee Voting](fee-voting.html). [New in: rippled 0.32.0][] |
|
||||
| `amendments` | Array of Strings | _(May be omitted)_ The [amendments](amendments.html) this server wants to be added to the protocol. [New in: rippled 0.32.0][] |
|
||||
| `base_fee` | Integer | _(May be omitted)_ The unscaled transaction cost (`reference_fee` value) this server wants to set by [Fee Voting](fee-voting.html). [New in: rippled 0.32.0][] |
|
||||
| `cookie` | String - Number | _(May be omitted)_ An arbitrary value chosen by the server at startup. If the same validation key pair signs validations with different cookies concurrently, that usually indicates that multiple servers are incorrectly configured to use the same validation key pair. [New in: rippled 1.8.1][] |
|
||||
| `flags` | Number | Bit-mask of flags added to this validation message. The flag `0x80000000` indicates that the validation signature is fully-canonical. The flag `0x00000001` indicates that this is a full validation; otherwise it's a partial validation. Partial validations are not meant to vote for any particular ledger. A partial validation indicates that the validator is still online but not keeping up with consensus. [New in: rippled 0.32.0][] |
|
||||
| `full` | Boolean | If `true`, this is a full validation. Otherwise, this is a partial validation. Partial validations are not meant to vote for any particular ledger. A partial validation indicates that the validator is still online but not keeping up with consensus. [New in: rippled 0.32.0][] |
|
||||
| `ledger_hash` | String | The identifying hash of the proposed ledger is being validated. |
|
||||
| `ledger_index` | String - Integer | The [Ledger Index][] of the proposed ledger. [New in: rippled 0.31.0][] |
|
||||
| `load_fee` | Integer | (May be omitted) The local load-scaled transaction cost this validator is currently enforcing, in fee units. [New in: rippled 0.32.0][] |
|
||||
| `ledger_index` | String - Number | The [Ledger Index][] of the proposed ledger. [New in: rippled 0.31.0][] |
|
||||
| `load_fee` | Integer | _(May be omitted)_ The local load-scaled transaction cost this validator is currently enforcing, in fee units. [New in: rippled 0.32.0][] |
|
||||
| `master_key` | String | _(May be omitted)_ The validator's master public key, if the validator is using a validator token, in the XRP Ledger's [base58][] format. (See also: [Enable Validation on your `rippled` Server](run-rippled-as-a-validator.html#3-enable-validation-on-your-rippled-server).) [New in: rippled 1.4.0][] |
|
||||
| `reserve_base` | Integer | (May be omitted) The minimum reserve requirement (`account_reserve` value) this validator wants to set by [Fee Voting](fee-voting.html). [New in: rippled 0.32.0][] |
|
||||
| `reserve_inc` | Integer | (May be omitted) The increment in the reserve requirement (`owner_reserve` value) this validator wants to set by [Fee Voting](fee-voting.html). [New in: rippled 0.32.0][] |
|
||||
| `reserve_base` | Integer | _(May be omitted)_ The minimum reserve requirement (`account_reserve` value) this validator wants to set by [Fee Voting](fee-voting.html). [New in: rippled 0.32.0][] |
|
||||
| `reserve_inc` | Integer | _(May be omitted)_ The increment in the reserve requirement (`owner_reserve` value) this validator wants to set by [Fee Voting](fee-voting.html). [New in: rippled 0.32.0][] |
|
||||
| `server_version` | String - Number | _(May be omitted)_ An 64-bit integer that encodes the version number of the validating server. For example, `"1745990410175512576"`. Only provided once every 256 ledgers. [New in: rippled 1.8.1][] |
|
||||
| `signature` | String | The signature that the validator used to sign its vote for this ledger. |
|
||||
| `signing_time` | Number | When this validation vote was signed, in [seconds since the Ripple Epoch][]. [New in: rippled 0.32.0][] |
|
||||
| `validated_hash` | String | The unique hash of the proposed ledger this validation applies to. [New in: rippled 1.8.1][] |
|
||||
| `validation_public_key` | String | The public key from the key-pair that the validator used to sign the message, in the XRP Ledger's [base58][] format. This identifies the validator sending the message and can also be used to verify the `signature`. If the validator is using a token, this is an ephemeral public key. |
|
||||
|
||||
|
||||
|
||||
@@ -8,39 +8,42 @@ labels:
|
||||
---
|
||||
# Capacity Planning
|
||||
|
||||
This section describes configuration, network, and hardware recommendations that you can use to tune and optimize the performance of your `rippled` server. Being aware of these considerations can help you ensure that your `rippled` server is ready to handle XRP Ledger network capacity today and in the near future.
|
||||
This document describes configuration, network, and hardware recommendations that you can use to tune and optimize the performance of an XRP Ledger server.
|
||||
|
||||
The load on an XRP Ledger server varies based on multiple factors. One is the activity in the network. The total size of data in the shared ledger and the total volume of transactions being sent vary based on organic factors throughout the global XRP Ledger community. Another factor is API usage; different types of [API calls](rippled-api.html) put different load on the server. The performance characteristics can be very different between servers that provide a public API, provide a private API to specific integration software, or provide no API at all.
|
||||
|
||||
You should consider these factors to ensure that your server has the capacity to handle XRP Ledger network activity today and in the future.
|
||||
|
||||
|
||||
|
||||
## Configuration Settings
|
||||
|
||||
Ripple recommends using these configuration guidelines to optimize resource utilization and performance of your `rippled` server.
|
||||
The default configuration file contains settings for a broad range of common use cases. You can get better performance by customizing the settings for your specific hardware and intended usage pattern.
|
||||
|
||||
You can set the following parameters in the `rippled.cfg` file used for your `rippled` server. You can access an example config file, `rippled-example.cfg`, in the [`cfg` directory](https://github.com/ripple/rippled/blob/develop/cfg/rippled-example.cfg) in the `rippled` GitHub repo.
|
||||
The settings in this section are parameters in the `rippled.cfg` file. You can access an example config file, `rippled-example.cfg`, in the [`cfg` directory](https://github.com/ripple/rippled/blob/develop/cfg/rippled-example.cfg) in the `rippled` GitHub repo. The settings in the example config file match the default config installed alongside the server.
|
||||
|
||||
|
||||
### Node Size
|
||||
|
||||
Set the `node_size` based on your server's expected load and the amount of memory you can make available to `rippled`.
|
||||
The `[node_size]` parameter should reflect the overall hardware capacity of your server. You can omit this parameter to have the server automatically choose an appropriate setting based on the system's total RAM and number of CPU threads. You can set this value explicitly if the automatic setting is wrong for your system, for example if some of the system's RAM or threads need to be set aside for other software, or the amounts reported by the operating system are inaccurate. (This can occur in some containers.) [Updated in: rippled 1.8.1][]
|
||||
|
||||
Ripple recommends you always use the largest node size your available RAM can support. See the following table for recommended settings.
|
||||
As a general rule, you should always use the largest node size your available RAM can support. See the following table for recommended settings.
|
||||
|
||||
#### Recommendation
|
||||
|
||||
Each `node_size` has a corresponding requirement for available RAM. For example, if you set `node_size` to `huge`, you should have at least 32 GB of available RAM to help ensure that `rippled` can run smoothly.
|
||||
Each `[node_size]` has a corresponding requirement for available RAM. For example, if you set `[node_size]` to `huge`, you should have at least 32 GB of available RAM to help ensure that `rippled` can run smoothly.
|
||||
|
||||
To tune your server, it may be useful to start with `tiny` and increase the size to `small`, `medium`, and so on as you refine the requirements for your use case.
|
||||
|
||||
| RAM available for `rippled` | `node_size` value | Notes |
|
||||
|:----------------------------|:------------------|:---------------------------|
|
||||
| < 8 GB | `tiny` | Not recommended for testing or production servers. This is the default value if you don't specify a value in `rippled.cfg`. |
|
||||
| 8 GB | `small` | Recommended for test servers. |
|
||||
| RAM available | `node_size` value | Notes |
|
||||
|:--------------|:------------------|:-----------------------------------------|
|
||||
| < 8 GB | `tiny` | **Not recommended.** A server with this setting may not sync to a busy network. |
|
||||
| 8 GB | `small` | Recommended for test servers that only need to run occasionally. |
|
||||
| 16 GB | `medium` | The `rippled-example.cfg` file uses this value. |
|
||||
| 32 GB | `large` | **Not recommended.** In practice, this setting performs worse than `huge` in most circumstances. Always use `huge` if you want stability. |
|
||||
| 64 GB | `huge` | Recommended for production servers. |
|
||||
|
||||
Although `large` is also a legal value for `[node_size]`, in practice it performs worse than `huge` in most circumstances. Ripple recommends always using `huge` instead of `large`. Always use `huge` if you want stability.
|
||||
|
||||
If you set the `node_size` parameter to an invalid value, the [server fails to start](server-wont-start.html#bad-node_size-value).
|
||||
If you set the `[node_size]` parameter to an invalid value, the [server fails to start](server-wont-start.html#bad-node_size-value).
|
||||
|
||||
|
||||
### Node DB Type
|
||||
@@ -49,27 +52,21 @@ The `type` field in the `[node_db]` stanza of the `rippled.cfg` file sets the ty
|
||||
|
||||
This setting does not directly configure RAM settings, but the choice of key-value store has important implications for RAM usage because of the different ways these technologies cache and index data for fast lookup.
|
||||
|
||||
You can set the value to either `RocksDB` or `NuDB`.
|
||||
|
||||
- If your server is a validator, it only needs a small amount of history, so use `RocksDB` for best performance. [Learn more](#more-about-using-rocksdb)
|
||||
|
||||
- For most cases, use `NuDB` because its performance is constant even with large amounts of data on disk. A fast SSD is required. [Learn more](#more-about-using-nudb)
|
||||
|
||||
- If you are using rotational disks (not recommended) or an unusually slow SSD, use `RocksDB`. [Learn more](#more-about-using-rocksdb)
|
||||
- If you are using rotational disks (not recommended) or an unusually slow SSD, use `RocksDB`. You should avoid this setting for production servers. [Learn more](#more-about-using-rocksdb)
|
||||
|
||||
The example `rippled-example.cfg` file has the `type` field in the `[node_db]` stanza set to `RocksDB`.
|
||||
The example `rippled-example.cfg` file has the `type` field in the `[node_db]` stanza set to `NuDB`.
|
||||
|
||||
#### More About Using RocksDB
|
||||
|
||||
[RocksDB](https://rocksdb.org/docs/getting-started.html) is an persistent key-value store built into `rippled`.
|
||||
|
||||
RocksDB works well on solid-state disks. RocksDB performs better than NuDB when used with rotational disks, but you may still encounter performance problems unless you use solid-state disks.
|
||||
**Caution:** As of late 2021, the total size of the ledger has grown large enough that servers using RocksDB often struggle to maintain sync with the Mainnet. Large amounts of RAM can help, but you should generally use NuDB instead.
|
||||
|
||||
RocksDB requires approximately one-third less [disk storage](#disk-space) than NuDB and provides better I/O latency. However, the better I/O latency comes as result of the large amount of RAM RocksDB requires to store data indexes.
|
||||
RocksDB is intended to work on either solid-state disks or rotational disks. It requires approximately one-third less [disk storage](#disk-space) than NuDB and provides better I/O latency. However, the better I/O latency comes as result of the large amount of RAM RocksDB requires to store data indexes.
|
||||
|
||||
Validators should be configured to use RocksDB and to store no more than about 300,000 ledgers (approximately two weeks' worth of [historical data](#disk-space)) in the ledger store.
|
||||
|
||||
RocksDB has performance-related configuration options that you can set in `rippled.cfg` to achieve maximum transaction processing throughput. Here is the recommended configuration for a `rippled` server using RocksDB:
|
||||
RocksDB has performance-related configuration options that you can tweak for more transaction processing throughput. Here is a recommended `[node_db]` configuration for RocksDB:
|
||||
|
||||
```
|
||||
[node_db]
|
||||
@@ -92,9 +89,9 @@ advisory_delete=0
|
||||
|
||||
NuDB has nearly constant performance and memory footprints regardless of the [amount of data being stored](#disk-space). NuDB _requires_ a solid-state drive, but uses much less RAM than RocksDB to access a large database.
|
||||
|
||||
Non-validator production servers should be configured to use NuDB and to store the amount of historical data required for the use case.
|
||||
Production servers should be configured to use NuDB and to store the amount of historical data required for the use case.
|
||||
|
||||
NuDB does not have performance-related configuration options available in `rippled.cfg`. Here is the recommended configuration for a `rippled` server using NuDB:
|
||||
NuDB does not have performance-related configuration options available in `rippled.cfg`. Here is the recommended `[node_db]` configuration for a `rippled` server using NuDB:
|
||||
|
||||
```
|
||||
[node_db]
|
||||
@@ -111,26 +108,16 @@ advisory_delete=0
|
||||
|
||||
The example `rippled-example.cfg` file sets the logging verbosity to `warning` in the `[rpc_startup]` stanza. This setting greatly reduces disk space and I/O requirements over more verbose logging. However, more verbose logging provides increased visibility for troubleshooting.
|
||||
|
||||
**Caution:** If you omit the `log_level` command from the `[rpc_startup]` stanza, `rippled` writes logs to disk at the `debug` level and outputs `warning` level logs to the console. `debug` level logging requires several more GB of disk space per day than `warning` level, depending on transaction volumes and client activity.
|
||||
**Caution:** If you omit the `log_level` command from the `[rpc_startup]` stanza, the server writes logs to disk at the `debug` level and outputs `warning` level logs to the console. Logging at the `debug` level requires several more GB of disk space per day than `warning` level, depending on transaction volumes and client activity.
|
||||
|
||||
|
||||
## Network and Hardware
|
||||
|
||||
Each `rippled` server in the XRP Ledger network performs all of the transaction processing work of the network. Therefore, the baseline hardware for production `rippled` servers should be similar to that used in Ripple's [performance testing](https://xrpl.org/blog/2017/high-scalability-xrp-ledger.html).
|
||||
|
||||
Ensuring that your `rippled` server meets these network and hardware requirements helps achieve consistent, good performance across the XRP Ledger network.
|
||||
|
||||
Each server in the XRP Ledger network performs all of the transaction processing work of the network. Total activity on the network varies but has mostly increased over time, so you should choose hardware with greater capacity than you need for the current network activity.
|
||||
|
||||
### Recommendation
|
||||
|
||||
For best performance in enterprise production environments, Ripple recommends running `rippled` on bare metal with the following characteristics:
|
||||
|
||||
- Operating System: Ubuntu 16.04+
|
||||
- CPU: Intel Xeon 3+ GHz processor with 4 cores and hyperthreading enabled
|
||||
- Disk speed: SSD (10,000 IOPS)
|
||||
- Disk space: Varies. At least 50 GB recommended.
|
||||
- RAM: 64 GB
|
||||
- Network: Enterprise data center network with a gigabit network interface on the host
|
||||
See [System Requirements](system-requirements.html) for a summary of the recommended hardware specs.
|
||||
|
||||
#### CPU Utilization and Virtualization
|
||||
|
||||
@@ -138,14 +125,16 @@ You'll get the best performance on bare metal, but virtual machines can perform
|
||||
|
||||
#### Disk Speed
|
||||
|
||||
Ripple _strongly recommends_ using a high-grade solid state disk drive (SSD) with low-latency random reads and high throughput. Ripple engineers have observed the following maximum reads and writes per second:
|
||||
The speed of storage is one of the most important factors in a server's capacity. Use a high-grade solid state disk drive (SSD) with low-latency random reads and high throughput. Ripple engineers have observed the following maximum reads and writes per second:
|
||||
|
||||
- Over 10,000 reads per second (in heavily-used public server clusters)
|
||||
- Over 7,000 writes per second (in dedicated performance testing)
|
||||
|
||||
<!--{# TODO 2021-11: have bigger numbers been seen lately? These might need an update #}-->
|
||||
|
||||
#### Disk Space
|
||||
|
||||
The amount of disk space `rippled` requires depend on how much [ledger history](ledger-history.html) you plan to keep available locally. A `rippled` server does not need to store more than the most recent 256 ledger versions to follow the consensus process and report the complete state of the ledger, but you can only query your server for transactions that executed in ledger versions it has stored locally.
|
||||
The `[node_db]` stanza controls the server's _ledger store_, which holds [ledger history](ledger-history.html). The amount of disk space you need depends on how much history you plan to keep available locally. An XRP Ledger server does not need to store more than the most recent 256 ledger versions to follow the consensus process and report the complete state of the ledger, but you can only query your server for transactions that executed in ledger versions it has stored locally. Configure the `path` of the `[node_db]` to point to your chosen storage location for the ledger store.
|
||||
|
||||
You can control how much data you keep with [online deletion](online-deletion.html); the default config file has the server keep the latest 2000 ledger versions. Without online deletion, the server's disk requirements grow without bounds.
|
||||
|
||||
@@ -168,16 +157,20 @@ The `online_delete` setting tells the server how many ledger versions to keep af
|
||||
|
||||
For instructions on how to change the amount of history you keep, see [Configure Online Deletion](configure-online-deletion.html).
|
||||
|
||||
If you want to contribute to storing ledger history but you do not have enough disk space to store full history, you can use the [History Sharding](history-sharding.html) feature to store a randomized range of ledgers in a separate shard store. History sharding is configured in the `[shard_db]` stanza, and it can use a different type of key-value store than the one you defined for the ledger store using the `[node_db]` stanza.
|
||||
The `[database_path]` configures separate bookkeeping databases: these include transaction data as well as some runtime configurations.
|
||||
|
||||
As a general rule, you can safely delete the database files (both the ledger store and the bookkeeping databases) for a `rippled` server when it isn't running; this clears any stored ledger history the server has, but it can re-acquire that data from the network. However, if you delete the `wallet.db` file in the `[database_path]`, you must manually reapply runtime configuration changes such as [amendment votes](configure-amendment-voting.html) and [peer reservations](use-a-peer-reservation.html).
|
||||
|
||||
If you want to contribute to storing ledger history but you do not have enough disk space to store full history, you can use the [History Sharding](history-sharding.html) feature to store a randomized range of ledgers in a separate shard store. History sharding is configured in the `[shard_db]` stanza.
|
||||
|
||||
|
||||
##### Amazon Web Services
|
||||
|
||||
Amazon Web Services (AWS) is a popular virtualized hosting environment. You can run `rippled` in AWS, but if using Elastic Block Storage (EBS), only use either the `io1` or `io2` types, and configure them for at least 10,000 IOPS. <!-- SPELLING_IGNORE: iops, ebs, aws -->
|
||||
Alternately, AWS instance stores (`ephemeral` storage) also has suitable performance. However, that is not durable, so data loss is to be expected under some circumstances.
|
||||
The `database_path` and `node_db` path should each reside on either EBS io1 or io2, or on instance storage.
|
||||
|
||||
**Caution:** AWS instance storage is not guaranteed to provide durability in the event of hard drive failure. You also lose data when you stop/start or reboot the instance. The latter type of data loss can be acceptable for a `rippled` server because an individual server can usually re-acquire the lost data from its peer servers.
|
||||
Alternately, AWS instance stores (`ephemeral` storage) provide suitable performance, but you may lose data in some circumstances, including when you start/stop an instance. This may be acceptable, since an individual XRP Ledger server can usually re-acquire lost ledger history from its peers. Configuration settings should be stored on more reliable storage.
|
||||
|
||||
Make sure the `path` of your `[node_db]` stanza and your `[database_path]` both point to the appropriate storage.
|
||||
|
||||
#### RAM/Memory
|
||||
|
||||
@@ -185,11 +178,11 @@ Memory requirements are mainly a function of the `node_size` configuration setti
|
||||
|
||||
#### Network
|
||||
|
||||
Any enterprise or carrier-class data center should have substantial network bandwidth to support running `rippled` servers. The actual bandwidth necessary varies significantly based on the current transaction volume in the network. Server behavior (such as backfilling [ledger history](ledger-history.html)) also affects network use.
|
||||
Any enterprise or carrier-class data center should have substantial network bandwidth to support running XRP Ledger servers. The actual bandwidth necessary varies significantly based on the current transaction volume in the network. Server behavior (such as backfilling [ledger history](ledger-history.html)) also affects network use. Consumer-grade home internet is generally not sufficient to run a reliable server.
|
||||
|
||||
During exceptionally high periods of transaction volume, some operators have reported that their `rippled` servers have completely saturated a 100 megabit/s network link. Therefore, a gigabit network interface is required for reliable performance.
|
||||
During exceptionally high periods of transaction volume, some operators have reported that their servers have completely saturated a 100 megabit/s network link. Therefore, a gigabit network interface is required for reliable performance.
|
||||
|
||||
Here are examples of observed uncompressed network bandwidth use for common `rippled` tasks:
|
||||
Here are examples of observed uncompressed network bandwidth use for common tasks:
|
||||
|
||||
| Task | Transmit/Receive |
|
||||
|:------------------------------------------------|:---------------------------|
|
||||
|
||||
@@ -7,14 +7,23 @@ labels:
|
||||
---
|
||||
# System Requirements
|
||||
|
||||
## Recommended Specifications
|
||||
|
||||
For reliable performance in production environments, it is recommended to run an XRP Ledger (`rippled`) server on bare metal with the following characteristics:
|
||||
|
||||
- Operating System: Ubuntu (LTS) or CentOS or RedHat Enterprise Linux (latest release)
|
||||
- CPU: Intel Xeon 3+ GHz processor with 8+ cores and hyperthreading enabled
|
||||
- Disk: SSD / NVMe (10,000 IOPS or better)
|
||||
- RAM: 64 GB
|
||||
- Network: Enterprise data center network with a gigabit network interface on the host
|
||||
|
||||
|
||||
## Minimum Specifications
|
||||
|
||||
A `rippled` server should run comfortably on commodity hardware, to make it inexpensive to participate in the network. At present, Ripple recommends the following minimum requirements:
|
||||
For testing purposes or occasional use, you can run an XRP Ledger server should on commodity hardware. The following minimum requirements should work for most cases, but may not always [stay synced with the network](server-doesnt-sync.html):
|
||||
|
||||
- Operating System:
|
||||
- Production: CentOS or RedHat Enterprise Linux (latest release), Ubuntu (16.04+), or Debian (9.x, 10.x) supported
|
||||
- Development: Mac OS X, Windows (64-bit), or most Linux distributions
|
||||
- CPU: 64-bit x86_64, 2+ cores
|
||||
- Operating System: Mac OS X, Windows (64-bit), or most Linux distributions (Red Hat, Ubuntu, and Debian supported)
|
||||
- CPU: 64-bit x86_64, 4+ cores
|
||||
- Disk: Minimum 50 GB for the database partition. SSD strongly recommended (minimum 1000 IOPS, more is better)
|
||||
- RAM: 16 GB+
|
||||
|
||||
@@ -23,16 +32,6 @@ A `rippled` server should run comfortably on commodity hardware, to make it inex
|
||||
Amazon EC2's `m3.large` VM size may be appropriate depending on your workload. A fast network connection is preferable. Any increase in a server's client-handling load increases resources needs.
|
||||
|
||||
|
||||
## Recommended Specifications
|
||||
|
||||
For best performance in enterprise production environments, it is recommended to run `rippled` on bare metal with the following characteristics:
|
||||
|
||||
- Operating System: Ubuntu (LTS) or CentOS or RedHat Enterprise Linux (latest release)
|
||||
- CPU: Intel Xeon 3+ GHz processor with 8 cores and hyperthreading enabled
|
||||
- Disk: SSD / NVMe(10,000 IOPS or better)
|
||||
- RAM: 64 GB
|
||||
- Network: Enterprise data center network with a gigabit network interface on the host
|
||||
|
||||
## System Time
|
||||
|
||||
A `rippled` server relies on maintaining accurate time. It is recommended that the system synchronize time using the Network Time Protocol (NTP) with daemons such as `ntpd` or `chrony`.
|
||||
|
||||
@@ -20,7 +20,13 @@ Linuxでは、`rippled`が1回限りの`cron`構成を使用して最新バー
|
||||
|
||||
$ sudo ln -s /opt/ripple/etc/update-rippled-cron /etc/cron.d/
|
||||
|
||||
このcron構成は、インストール済みの`rippled`パッケージを新版のリリース後1時間以内に更新するためのスクリプトを実行します。同時に更新を実行しているすべてのサーバーが停止する可能性を抑えるため、このスクリプトはランダムな分数（最大で59）で更新を遅延して行います。
|
||||
このcron構成は、インストール済みの`rippled`パッケージを新版のリリース後1時間以内に更新するためのスクリプトを実行します。同時に更新を実行しているすべてのサーバーが停止する可能性を抑えるため、このスクリプトは`rippled`サービスを再起動しません。手動再起動しますまで、以前のバージョンを実行し続けます。[新規: rippled 1.8.1][]
|
||||
|
||||
3. 新しいリリースが公開された後、`rippled`サービスを手動再起動する。
|
||||
|
||||
sudo systemctl restart rippled.service
|
||||
|
||||
|
||||
|
||||
**注意:** 将来的には、Rippleのリポジトリが変更された場合に、更新を検索するスクリプトが実行されるURLの手動更新が必要となることがあります。必要な変更についての最新情報は、[XRP Ledgerブログ](/blog/)または[ripple-serverメーリングリスト](https://groups.google.com/forum/#!forum/ripple-server)でお知らせします。
|
||||
|
||||
|
||||
@@ -18,9 +18,13 @@ To set up automatic updates, complete the following steps:
|
||||
|
||||
2. Create a symlink in your `cron.d` folder to the `/opt/ripple/etc/update-rippled-cron` config file:
|
||||
|
||||
$ sudo ln -s /opt/ripple/etc/update-rippled-cron /etc/cron.d/
|
||||
sudo ln -s /opt/ripple/etc/update-rippled-cron /etc/cron.d/
|
||||
|
||||
This configuration runs a script to update the installed `rippled` package within an hour of each new release. To reduce the chance of outages from all servers updating simultaneously, the script delays the update for a random number of minutes, up to 59.
|
||||
This configuration runs a script to update the installed `rippled` package within an hour of each new release. To avoid network instability from too many servers updating at the same time, this script does not automatically restart the server, so it continues to run the old version until it restarts. [Updated in: rippled 1.8.1][]
|
||||
|
||||
3. **Whenever a new release comes out,** you must manually restart the `rippled` service to switch to the updated software.
|
||||
|
||||
sudo systemctl restart rippled.service
|
||||
|
||||
**Caution:** In the future, it is possible that changes to Ripple's repositories may require manual intervention to update the URLs where your script searches for updates. Stay tuned to the [XRP Ledger Blog](/blog/) or the [ripple-server mailing list](https://groups.google.com/forum/#!forum/ripple-server) for announcements on any required changes.
|
||||
|
||||
|
||||
@@ -18,7 +18,7 @@ labels:
|
||||
|
||||
1. `rippled` 1.7.0にその以前のバージョンから更新する場合は、リポジトリを再度追加して、Rippleの更新されたGPGキーを取得します。それ以外の場合は、この手順をスキップしてください。
|
||||
|
||||
$ cat << REPOFILE | sudo tee /etc/yum.repos.d/ripple.repo
|
||||
cat << REPOFILE | sudo tee /etc/yum.repos.d/ripple.repo
|
||||
[ripple-stable]
|
||||
name=XRP Ledger Packages
|
||||
enabled=1
|
||||
@@ -30,15 +30,15 @@ labels:
|
||||
|
||||
1. 最新の`rippled`パッケージをダウンロードしてインストールします。
|
||||
|
||||
$ sudo yum update rippled
|
||||
sudo yum update rippled
|
||||
|
||||
2. `systemd`ユニットファイルを再度読み込みます。
|
||||
|
||||
$ sudo systemctl daemon-reload
|
||||
sudo systemctl daemon-reload
|
||||
|
||||
3. `rippled`サービスを再起動します。
|
||||
|
||||
$ sudo service rippled restart
|
||||
sudo systemctl restart rippled.service
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
@@ -2980,6 +2980,11 @@ pages:
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: references/rippled-api/admin-rippled-methods/logging-and-data-management-methods/node_to_shard.md
|
||||
targets:
|
||||
- en
|
||||
- ja
|
||||
|
||||
#TODO: translate title and blurb
|
||||
- name: Server Control Methods
|
||||
html: server-control-methods.html
|
||||
|
||||
Reference in New Issue
Block a user