mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-20 11:45:50 +00:00
Merge pull request #353 from jhaaaa/reorg-rippled-server-tut
Reorg rippled tut cat
This commit is contained in:
Rome Reginelli
@@ -1,117 +1 @@
|
||||
# Capacity Planning
|
||||
|
||||
This section describes some of the challenges related to scaling `rippled` servers for testing and production deployments. Additionally, it describes how hardware and configuration settings relate to those challenges. Finally, this section offers recommendations to assist you in properly setting up `rippled` to meet the goals for the use case of your deployment.
|
||||
|
||||
Even the most minimally functional `rippled` server must contain the most recently validated ledger versions to submit transactions to the network and verify the integrity of the XRP Ledger. Beyond these requirements, consider the following possible business needs:
|
||||
|
||||
- Handling ever-increasing transaction volume
|
||||
- Servicing transaction reporting information to clients
|
||||
- Maintaining varying amounts of historical data
|
||||
|
||||
To meet your `rippled` capacity requirements, you must address these technical factors:
|
||||
|
||||
- The [configuration settings](#configuration-settings) that affect resource utilization
|
||||
- The [network and hardware](#network-and-hardware) requirements to achieve consistent, good performance across the XRP Ledger network
|
||||
|
||||
## Configuration Settings
|
||||
|
||||
Ripple recommends the following guidelines to improve performance. You can set the following parameters in the `rippled.cfg` file to improve performance for your `rippled` server.
|
||||
|
||||
### Node Size
|
||||
|
||||
The `node_size` parameter determines the size of database caches. Larger database caches decrease disk I/O requirements at a cost of higher memory requirements. Ripple recommends you always use the largest database cache your available memory can support. See the following table for recommended settings.
|
||||
|
||||
#### Recommendation
|
||||
|
||||
| Available RAM for `rippled` | `node_size` value | Notes |
|
||||
|:----------------------------|:------------------|:-----------------------------------|
|
||||
| < 8GB | `tiny` | Not recommended |
|
||||
| 8GB | `low` | |
|
||||
| 16GB | `medium` | |
|
||||
| 32GB | `huge` | Recommended for production servers |
|
||||
|
||||
### Node DB Type
|
||||
|
||||
The `type` field in the `node_db` section of the `rippled.cfg` file sets the type of key-value store that `rippled` uses to persist the XRP Ledger in the ledger store. You can set the value to either `rocksdb` or `nudb`.
|
||||
|
||||
`rippled` offers a history sharding feature that allows you to store a randomized range of ledgers in a separate shard store. You may want to configure the shard store to use a different type of key-value store than the ledger store. For more information about how to use this feature, see [History Sharding](https://ripple.com/build/history-sharding/#shard-store-configuration).
|
||||
|
||||
|
||||
#### RocksDB vs NuDB
|
||||
RocksDB requires approximately one-third less disk storage than NuDB and provides a corresponding improvement in I/O latency. However, this comes at a cost of increased memory utilization as storage size grows. NuDB, on the other hand, has nearly constant performance and memory footprint regardless of [storage](#storage).
|
||||
|
||||
`rippled` servers that operate as validators should keep only a few days' worth of data or less. Ripple recommends using RocksDB for validators. For all other uses, Ripple recommends using NuDB for the ledger store.
|
||||
|
||||
RocksDB has performance-related configuration options you can modify to achieve maximum transaction processing throughput. (NuDB does not have performance-related configuration options.) Here is an example of the recommended configuration for a `rippled` server using RocksDB:
|
||||
|
||||
```
|
||||
[node_db]
|
||||
type=rocksdb
|
||||
open_files=512
|
||||
file_size_mb=64
|
||||
file_size_mult=2
|
||||
filter_bits=12
|
||||
cache_mb=512
|
||||
path={path_to_ledger_store}
|
||||
```
|
||||
|
||||
### Historical Data
|
||||
|
||||
The amount of historical data that a `rippled` server keeps online is a major contributor to required storage space. At the time of writing (2018-03-01), a `rippled` server stores about 12GB of data per day. You can expect this amount to grow as transaction volume increases across the XRP Ledger network. You can control how much data you keep with the `online_delete` and `advisory_delete` fields.
|
||||
|
||||
Online deletion enables pruning of `rippled` ledgers from databases without any disruption of service. It only removes records that are not part of the current ledgers. Without online deletion, those databases grow without bounds. Freeing disk space requires stopping the process and manually removing database files.
|
||||
|
||||
<!-- {# ***TODO***: Add link to online_delete section, when complete, per https://ripplelabs.atlassian.net/browse/DOC-1313 #} -->
|
||||
|
||||
### Log Level
|
||||
|
||||
The default `rippled.cfg` file sets the logging verbosity to `warning`. 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.
|
||||
|
||||
## Network and Hardware
|
||||
|
||||
Each `rippled` server in the XRP Ledger network performs all of the transaction processing work of the network. It is unknown when volumes will approach maximum network capacity. Therefore, the baseline hardware for production `rippled` servers should be similar to that used in Ripple's [performance testing](https://ripple.com/dev-blog/demonstrably-scalable-blockchain/).
|
||||
|
||||
### 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: SSD
|
||||
- RAM:
|
||||
- For testing: 8GB+
|
||||
- For production: 32GB
|
||||
- Network: Enterprise data center network with a gigabit network interface on the host
|
||||
|
||||
#### SSD Storage
|
||||
|
||||
SSD storage should support several thousand of both read and write IOPS. The maximum reads and writes per second that Ripple engineers have observed are over 10,000 reads per second (in heavily-used public server clusters), and over 7,000 writes per second (in dedicated performance testing).
|
||||
|
||||
#### CPU Utilization and Virtualization
|
||||
Ripple performance engineering has determined that bare metal servers achieve maximum throughput. However, it is likely that hypervisors cause minimal degradation in performance.
|
||||
|
||||
#### Network
|
||||
|
||||
Any enterprise or carrier-class data center should have substantial network bandwidth to support running `rippled` servers. The minimum requirements are roughly 2Mbps transmit and 2Mbps receive for current transaction volumes. However, these can burst up to 100MBps transmissions when serving historical ledger and transaction reports. When a `rippled` server initially starts up, it can burst to over 20Mbps receive.
|
||||
|
||||
#### Storage
|
||||
|
||||
Ripple recommends estimating storage sizing at roughly 12GB per day of data kept online with NuDB. RocksDB requires around 8GB per day. However, the data per day changes with activity in the network. You should provision extra capacity to prepare for future growth. At the time of writing (2018-03-01), a server with all XRP Ledger history requires 6.8TB.
|
||||
|
||||
<!-- {# ***TODO: Update the dated storage consideration above, as needed. ***#} -->
|
||||
<!-- {# ***TODO: DOC-1331 tracks: Create historic metrics that a user can use to derive what will be required. For ex, a chart with 1TB in 2014, 3TB in 2015, 7TB in 2018 ***#} -->
|
||||
|
||||
#### Memory
|
||||
|
||||
Memory requirements are mainly a function of the `node_size` configuration setting and the amount of client traffic retrieving historical data. As mentioned, production servers should maximize performance and set this parameter to `huge`.
|
||||
You can set the `node_size` parameter lower to use less memory, but you should only do this for testing. With a `node_size` of `medium`, a `rippled` server can be reasonably stable in a test Linux system with as little as 8GB of RAM.
|
||||
|
||||
#### Amazon Web Services
|
||||
|
||||
Amazon Web Services (AWS) is a popular virtualized hosting environment. You can run rippled in AWS, but Ripple does not recommend using Elastic Block Storage (EBS). Elastic Block Storage's maximum number of IOPS (5,000) is insufficient for `rippled`'s heaviest loads, despite being very expensive.
|
||||
|
||||
AWS instance stores (`ephemeral` storage) do not have these constraints. Therefore, Ripple recommends deploying `rippled` servers with host types such as `M3` that have instance storage. The `database_path` and `node_db` path should each reside on instance storage.
|
||||
|
||||
**Caution:** AWS instance storage is not guaranteed to provide durability in the event of hard drive failure. Further, data that is lost when the instance stops and restarts (but not when just rebooted). This loss can be acceptable for a `rippled` server because an individual server can usually re-acquire that data from its peer servers.
|
||||
<!-- moved content to tutorials > manage the rippled server > capacity-planning.md -->
|
||||
|
||||
@@ -9,101 +9,4 @@ When you run `rippled` in stand-alone mode, you have to tell it what ledger vers
|
||||
|
||||
**Caution:** In stand-alone mode, you must [manually advance the ledger](#advancing-ledgers-in-stand-alone-mode).
|
||||
|
||||
|
||||
## New Genesis Ledger
|
||||
|
||||
In stand-alone mode, you can have `rippled` create a new genesis ledger. This provides a known state, with none of the ledger history from the production XRP Ledger. (This is very useful for unit tests, among other things.)
|
||||
|
||||
* To start `rippled` in stand-alone mode with a new genesis ledger, use the [`-a`](https://wiki.ripple.com/Rippled#--standalone.2C_-a) and [`--start`](https://wiki.ripple.com/Rippled#--start) options:
|
||||
|
||||
```
|
||||
rippled -a --start --conf=/path/to/rippled.cfg
|
||||
```
|
||||
|
||||
In a genesis ledger, the [genesis address](concept-accounts.html#special-addresses) holds all 100 billion XRP. The keys of the genesis address are [hardcoded](https://github.com/ripple/rippled/blob/94ed5b3a53077d815ad0dd65d490c8d37a147361/src/ripple/app/ledger/Ledger.cpp#L184) as follows:
|
||||
|
||||
**Address:** `rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh`
|
||||
|
||||
**Secret:** `snoPBrXtMeMyMHUVTgbuqAfg1SUTb` ("masterpassphrase")
|
||||
|
||||
### Settings in New Genesis Ledgers
|
||||
|
||||
In a new genesis ledger, the hard-coded default [Reserve](concept-reserves.html) is **200 XRP** minimum for funding a new address, with an increment of **50 XRP** per object in the ledger. These values are higher than the current reserve requirements of the production network. (See also: [Fee Voting](concept-fee-voting.html))
|
||||
|
||||
By default, a new genesis ledger has no [amendments](concept-amendments.html) enabled. If you start a new genesis ledger with `--start`, the genesis ledger contains an [EnableAmendment pseudo-transaction](reference-transaction-format.html#enableamendment) to turn on all amendments natively supported by the `rippled` server, except for amendments that you explicitly disable in the configuration file. The effects of those amendments are available starting from the very next ledger version. (Reminder: in stand-alone mode, you must [advance the ledger manually](#advancing-ledgers-in-stand-alone-mode).) [New in: rippled 0.50.0][]
|
||||
|
||||
|
||||
## Load Saved Ledger
|
||||
|
||||
You can start with a ledger version that was saved to disk if your `rippled` server was previously synced with the XRP Ledger peer-to-peer network (either the production network or the [Test Net](tutorial-rippled-setup.html#parallel-networks)).
|
||||
|
||||
### 1. Start `rippled` normally.
|
||||
|
||||
To load an existing ledger, you must first retrieve that ledger from the network. Start `rippled` in online mode as normal:
|
||||
|
||||
```
|
||||
rippled --conf=/path/to/rippled.cfg
|
||||
```
|
||||
|
||||
### 2. Wait until `rippled` is synced.
|
||||
|
||||
Use the [server_info method][] to check the state of your server relative to the network. Your server is synced when the `server_state` value shows any of the following values:
|
||||
|
||||
* `full`
|
||||
* `proposing`
|
||||
* `validating`
|
||||
|
||||
For more information, see [Possible Server States](reference-rippled.html#possible-server-states).
|
||||
|
||||
### 3. (Optional) Retrieve specific ledger versions.
|
||||
|
||||
If you only want the most recent ledger, you can skip this step.
|
||||
|
||||
If you want to load a specific historical ledger version, use the [ledger_request method][] to make `rippled` fetch it. If `rippled` does not already have the ledger version, you may have to run the `ledger_request` command multiple times until it has finished retrieving the ledger.
|
||||
|
||||
If you want to replay a specific historical ledger version, you must fetch both the ledger version to replay and the ledger version before it. (The previous ledger version sets up the initial state upon which you apply the changes described by the ledger version you replay.)
|
||||
|
||||
### 4. Shut down `rippled`.
|
||||
|
||||
Use the [stop method][]:
|
||||
|
||||
```
|
||||
rippled stop --conf=/path/to/rippled.cfg
|
||||
```
|
||||
|
||||
### 5. Start `rippled` in stand-alone mode.
|
||||
|
||||
To load the most recent ledger version, you can use the [`-a`](https://wiki.ripple.com/Rippled#--standalone.2C_-a) and [`--load`](https://wiki.ripple.com/Rippled#--load) options when starting the server:
|
||||
|
||||
```
|
||||
rippled -a --load --conf=/path/to/rippled.cfg
|
||||
```
|
||||
|
||||
To instead load a specific historical ledger, use the [`--load`](https://wiki.ripple.com/Rippled#--load) parameter along with the `--ledger` parameter, providing the ledger index or identifying hash of the ledger version to load:
|
||||
|
||||
```
|
||||
rippled -a --load --ledger 19860944 --conf=/path/to/rippled.cfg
|
||||
```
|
||||
|
||||
### 6. Manually advance the ledger.
|
||||
|
||||
When you load a ledger with `--ledger` in stand-alone mode, it goes to the current open ledger, so you must [manually advance the ledger](#advancing-ledgers-in-stand-alone-mode):
|
||||
|
||||
```
|
||||
rippled ledger_accept --conf=/path/to/rippled.cfg
|
||||
```
|
||||
|
||||
|
||||
## Advancing Ledgers in Stand-Alone Mode
|
||||
|
||||
In stand-alone mode, `rippled` does not communicate to other members of the peer-to-peer network or participate in a consensus process. Instead, you must manually advance the ledger index using the [ledger_accept method][]:
|
||||
|
||||
```
|
||||
rippled ledger_accept --conf=/path/to/rippled.cfg
|
||||
```
|
||||
|
||||
In stand-alone mode, `rippled` makes no distinction between a "closed" ledger version and a "validated" ledger version. (For more information about the difference, see [The XRP Ledger Consensus Process](concept-consensus.html).)
|
||||
|
||||
Whenever `rippled` closes a ledger, it reorders the transactions according to a deterministic but hard-to-game algorithm. (This is an important part of consensus, since transactions may arrive at different parts of the network in different order.) When using `rippled` in stand-alone mode, you should manually advance the ledger before submitting a transaction that depends on the result of a transaction from a different address. Otherwise, the two transactions might be executed in reverse order when the ledger is closed. **Note:** You can safely submit multiple transactions from a single address to a single ledger, because `rippled` sorts transactions from the same address in ascending order by [`Sequence` number](reference-transaction-format.html#common-fields).
|
||||
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
|
||||
@@ -0,0 +1,11 @@
|
||||
# Advance the Ledger in Stand-Alone Mode
|
||||
|
||||
In stand-alone mode, `rippled` does not communicate to other members of the peer-to-peer network or participate in a consensus process. Instead, you must manually advance the ledger index using the [ledger_accept method][]:
|
||||
|
||||
```
|
||||
rippled ledger_accept --conf=/path/to/rippled.cfg
|
||||
```
|
||||
|
||||
In stand-alone mode, `rippled` makes no distinction between a "closed" ledger version and a "validated" ledger version. (For more information about the difference, see [The XRP Ledger Consensus Process](concept-consensus.html).)
|
||||
|
||||
Whenever `rippled` closes a ledger, it reorders the transactions according to a deterministic but hard-to-game algorithm. (This is an important part of consensus, since transactions may arrive at different parts of the network in different order.) When using `rippled` in stand-alone mode, you should manually advance the ledger before submitting a transaction that depends on the result of a transaction from a different address. Otherwise, the two transactions might be executed in reverse order when the ledger is closed. **Note:** You can safely submit multiple transactions from a single address to a single ledger, because `rippled` sorts transactions from the same address in ascending order by [`Sequence` number](reference-transaction-format.html#common-fields).
|
||||
@@ -1,4 +1,4 @@
|
||||
# Build and Run `rippled` on Ubuntu
|
||||
# Build and Run rippled on Ubuntu
|
||||
|
||||
`rippled` is the core peer-to-peer server that manages the XRP Ledger. A `rippled` server can connect to a network of peers, relay cryptographically signed transactions, and maintain a local copy of the complete shared global ledger.
|
||||
|
||||
|
||||
117
content/tutorials/manage-the-rippled-server/capacity-planning.md
Normal file
117
content/tutorials/manage-the-rippled-server/capacity-planning.md
Normal file
@@ -0,0 +1,117 @@
|
||||
# Capacity Planning
|
||||
|
||||
This section describes some of the challenges related to scaling `rippled` servers for testing and production deployments. Additionally, it describes how hardware and configuration settings relate to those challenges. Finally, this section offers recommendations to assist you in properly setting up `rippled` to meet the goals for the use case of your deployment.
|
||||
|
||||
Even the most minimally functional `rippled` server must contain the most recently validated ledger versions to submit transactions to the network and verify the integrity of the XRP Ledger. Beyond these requirements, consider the following possible business needs:
|
||||
|
||||
- Handling ever-increasing transaction volume
|
||||
- Servicing transaction reporting information to clients
|
||||
- Maintaining varying amounts of historical data
|
||||
|
||||
To meet your `rippled` capacity requirements, you must address these technical factors:
|
||||
|
||||
- The [configuration settings](#configuration-settings) that affect resource utilization
|
||||
- The [network and hardware](#network-and-hardware) requirements to achieve consistent, good performance across the XRP Ledger network
|
||||
|
||||
## Configuration Settings
|
||||
|
||||
Ripple recommends the following guidelines to improve performance. You can set the following parameters in the `rippled.cfg` file to improve performance for your `rippled` server.
|
||||
|
||||
### Node Size
|
||||
|
||||
The `node_size` parameter determines the size of database caches. Larger database caches decrease disk I/O requirements at a cost of higher memory requirements. Ripple recommends you always use the largest database cache your available memory can support. See the following table for recommended settings.
|
||||
|
||||
#### Recommendation
|
||||
|
||||
| Available RAM for `rippled` | `node_size` value | Notes |
|
||||
|:----------------------------|:------------------|:-----------------------------------|
|
||||
| < 8GB | `tiny` | Not recommended |
|
||||
| 8GB | `low` | |
|
||||
| 16GB | `medium` | |
|
||||
| 32GB | `huge` | Recommended for production servers |
|
||||
|
||||
### Node DB Type
|
||||
|
||||
The `type` field in the `node_db` section of the `rippled.cfg` file sets the type of key-value store that `rippled` uses to persist the XRP Ledger in the ledger store. You can set the value to either `rocksdb` or `nudb`.
|
||||
|
||||
`rippled` offers a history sharding feature that allows you to store a randomized range of ledgers in a separate shard store. You may want to configure the shard store to use a different type of key-value store than the ledger store. For more information about how to use this feature, see [History Sharding](https://ripple.com/build/history-sharding/#shard-store-configuration).
|
||||
|
||||
|
||||
#### RocksDB vs NuDB
|
||||
RocksDB requires approximately one-third less disk storage than NuDB and provides a corresponding improvement in I/O latency. However, this comes at a cost of increased memory utilization as storage size grows. NuDB, on the other hand, has nearly constant performance and memory footprint regardless of [storage](#storage).
|
||||
|
||||
`rippled` servers that operate as validators should keep only a few days' worth of data or less. Ripple recommends using RocksDB for validators. For all other uses, Ripple recommends using NuDB for the ledger store.
|
||||
|
||||
RocksDB has performance-related configuration options you can modify to achieve maximum transaction processing throughput. (NuDB does not have performance-related configuration options.) Here is an example of the recommended configuration for a `rippled` server using RocksDB:
|
||||
|
||||
```
|
||||
[node_db]
|
||||
type=rocksdb
|
||||
open_files=512
|
||||
file_size_mb=64
|
||||
file_size_mult=2
|
||||
filter_bits=12
|
||||
cache_mb=512
|
||||
path={path_to_ledger_store}
|
||||
```
|
||||
|
||||
### Historical Data
|
||||
|
||||
The amount of historical data that a `rippled` server keeps online is a major contributor to required storage space. At the time of writing (2018-03-01), a `rippled` server stores about 12GB of data per day. You can expect this amount to grow as transaction volume increases across the XRP Ledger network. You can control how much data you keep with the `online_delete` and `advisory_delete` fields.
|
||||
|
||||
Online deletion enables pruning of `rippled` ledgers from databases without any disruption of service. It only removes records that are not part of the current ledgers. Without online deletion, those databases grow without bounds. Freeing disk space requires stopping the process and manually removing database files.
|
||||
|
||||
<!-- {# ***TODO***: Add link to online_delete section, when complete, per https://ripplelabs.atlassian.net/browse/DOC-1313 #} -->
|
||||
|
||||
### Log Level
|
||||
|
||||
The default `rippled.cfg` file sets the logging verbosity to `warning`. 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.
|
||||
|
||||
## Network and Hardware
|
||||
|
||||
Each `rippled` server in the XRP Ledger network performs all of the transaction processing work of the network. It is unknown when volumes will approach maximum network capacity. Therefore, the baseline hardware for production `rippled` servers should be similar to that used in Ripple's [performance testing](https://ripple.com/dev-blog/demonstrably-scalable-blockchain/).
|
||||
|
||||
### 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: SSD
|
||||
- RAM:
|
||||
- For testing: 8GB+
|
||||
- For production: 32GB
|
||||
- Network: Enterprise data center network with a gigabit network interface on the host
|
||||
|
||||
#### SSD Storage
|
||||
|
||||
SSD storage should support several thousand of both read and write IOPS. The maximum reads and writes per second that Ripple engineers have observed are over 10,000 reads per second (in heavily-used public server clusters), and over 7,000 writes per second (in dedicated performance testing).
|
||||
|
||||
#### CPU Utilization and Virtualization
|
||||
Ripple performance engineering has determined that bare metal servers achieve maximum throughput. However, it is likely that hypervisors cause minimal degradation in performance.
|
||||
|
||||
#### Network
|
||||
|
||||
Any enterprise or carrier-class data center should have substantial network bandwidth to support running `rippled` servers. The minimum requirements are roughly 2Mbps transmit and 2Mbps receive for current transaction volumes. However, these can burst up to 100MBps transmissions when serving historical ledger and transaction reports. When a `rippled` server initially starts up, it can burst to over 20Mbps receive.
|
||||
|
||||
#### Storage
|
||||
|
||||
Ripple recommends estimating storage sizing at roughly 12GB per day of data kept online with NuDB. RocksDB requires around 8GB per day. However, the data per day changes with activity in the network. You should provision extra capacity to prepare for future growth. At the time of writing (2018-03-01), a server with all XRP Ledger history requires 6.8TB.
|
||||
|
||||
<!-- {# ***TODO: Update the dated storage consideration above, as needed. ***#} -->
|
||||
<!-- {# ***TODO: DOC-1331 tracks: Create historic metrics that a user can use to derive what will be required. For ex, a chart with 1TB in 2014, 3TB in 2015, 7TB in 2018 ***#} -->
|
||||
|
||||
#### Memory
|
||||
|
||||
Memory requirements are mainly a function of the `node_size` configuration setting and the amount of client traffic retrieving historical data. As mentioned, production servers should maximize performance and set this parameter to `huge`.
|
||||
You can set the `node_size` parameter lower to use less memory, but you should only do this for testing. With a `node_size` of `medium`, a `rippled` server can be reasonably stable in a test Linux system with as little as 8GB of RAM.
|
||||
|
||||
#### Amazon Web Services
|
||||
|
||||
Amazon Web Services (AWS) is a popular virtualized hosting environment. You can run rippled in AWS, but Ripple does not recommend using Elastic Block Storage (EBS). Elastic Block Storage's maximum number of IOPS (5,000) is insufficient for `rippled`'s heaviest loads, despite being very expensive.
|
||||
|
||||
AWS instance stores (`ephemeral` storage) do not have these constraints. Therefore, Ripple recommends deploying `rippled` servers with host types such as `M3` that have instance storage. The `database_path` and `node_db` path should each reside on instance storage.
|
||||
|
||||
**Caution:** AWS instance storage is not guaranteed to provide durability in the event of hard drive failure. Further, data that is lost when the instance stops and restarts (but not when just rebooted). This loss can be acceptable for a `rippled` server because an individual server can usually re-acquire that data from its peer servers.
|
||||
@@ -0,0 +1,19 @@
|
||||
# Cluster rippled Servers
|
||||
|
||||
If you are running multiple `rippled` servers in a single datacenter, you can configure those servers into a cluster to maximize efficiency. Running your `rippled` servers in a cluster provides the following benefits:
|
||||
|
||||
* Clustered `rippled` servers share the work of cryptography. If one server has verified the authenticity of a message, the other servers in the cluster trust it and do not re-verify.
|
||||
* Clustered servers share information about peers and API clients that are misbehaving or abusing the network. This makes it harder to attack all servers of the cluster at once.
|
||||
* Clustered servers always propagate transactions throughout the cluster, even if the transaction does not meet the current load-based transaction fee on some of them.
|
||||
|
||||
To enable clustering, change the following sections of your [config file](https://github.com/ripple/rippled/blob/d7def5509d8338b1e46c0adf309b5912e5168af0/doc/rippled-example.cfg#L297-L346) for each server:
|
||||
|
||||
* List the IP address and port of each other server under the `[ips_fixed]` section. The port should be the one from the other servers' `protocol = peer` setting in their `rippled.cfg`. Example:
|
||||
|
||||
[ips_fixed]
|
||||
192.168.0.1 51235
|
||||
192.168.0.2 51235
|
||||
|
||||
* Generate a unique seed (using the [validation_create method][]) for each of your servers, and configure it under the `[node_seed]` section. The `rippled` server uses this key to sign its messages to other servers in the peer-to-peer network.
|
||||
|
||||
* Add the public keys (for peer communication) of each of your other servers under the `[cluster_nodes]` section.
|
||||
@@ -0,0 +1,83 @@
|
||||
# Install rippled
|
||||
|
||||
For development, you can [compile `rippled` from source](https://wiki.ripple.com/Rippled_build_instructions).
|
||||
|
||||
Production `rippled` instances can [use Ripple's binary executable](#installation-on-centosred-hat-with-yum), available from the Ripple [yum](https://en.wikipedia.org/wiki/Yellowdog_Updater,_Modified) repository.
|
||||
|
||||
## Minimum System Requirements
|
||||
|
||||
A `rippled` server should run comfortably on commodity hardware, to make it inexpensive to participate in the network. At present, we recommend the following mimimum requirements:
|
||||
|
||||
- Operating System:
|
||||
- Production: CentOS or RedHat Enterprise Linux (latest release) or Ubuntu (16.04+) supported
|
||||
- Development: Mac OS X, Windows (64-bit), or most Linux distributions
|
||||
- CPU: 64-bit x86_64, 2+ cores
|
||||
- Disk: Minimum 50GB SSD recommended (1000 IOPS, more is better) for the database partition
|
||||
- RAM:
|
||||
- Testing: 8GB+
|
||||
- Production: 32 GB
|
||||
|
||||
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.
|
||||
|
||||
**Tip:** For recommendations beyond the minimum requirements, see [Capacity Planning](#capacity-planning).
|
||||
|
||||
## Installation on CentOS/Red Hat with yum
|
||||
|
||||
This section assumes that you are using CentOS 7 or Red Hat Enterprise Linux 7.
|
||||
|
||||
1. Install the Ripple RPM repository:
|
||||
|
||||
$ sudo rpm -Uvh https://mirrors.ripple.com/ripple-repo-el7.rpm
|
||||
|
||||
2. Install the `rippled` software package:
|
||||
|
||||
$ sudo yum install --enablerepo=ripple-stable rippled
|
||||
|
||||
3. Configure the `rippled` service to start on system boot:
|
||||
|
||||
$ sudo systemctl enable rippled.service
|
||||
|
||||
4. Start the `rippled` service
|
||||
|
||||
$ sudo systemctl start rippled.service
|
||||
|
||||
## Installation on Ubuntu with alien
|
||||
|
||||
This section assumes that you are using Ubuntu 15.04 or later.
|
||||
|
||||
1. Install yum-utils and alien:
|
||||
|
||||
$ sudo apt-get update
|
||||
$ sudo apt-get install yum-utils alien
|
||||
|
||||
2. Install the Ripple RPM repository:
|
||||
|
||||
$ sudo rpm -Uvh https://mirrors.ripple.com/ripple-repo-el7.rpm
|
||||
|
||||
3. Download the `rippled` software package:
|
||||
|
||||
$ yumdownloader --enablerepo=ripple-stable --releasever=el7 rippled
|
||||
|
||||
4. Verify the signature on the `rippled` software package:
|
||||
|
||||
$ sudo rpm --import https://mirrors.ripple.com/rpm/RPM-GPG-KEY-ripple-release && rpm -K rippled*.rpm
|
||||
|
||||
5. Install the `rippled` software package:
|
||||
|
||||
$ sudo alien -i --scripts rippled*.rpm && rm rippled*.rpm
|
||||
|
||||
6. Configure the `rippled` service to start on system boot:
|
||||
|
||||
$ sudo systemctl enable rippled.service
|
||||
|
||||
7. Start the `rippled` service
|
||||
|
||||
$ sudo systemctl start rippled.service
|
||||
|
||||
## Postinstall
|
||||
|
||||
It can take several minutes for `rippled` to sync with the rest of the network, during which time it outputs warnings about missing ledgers. After that, you have a fully functional stock `rippled` server that you can use for local signing and API access to the XRP Ledger.
|
||||
|
||||
[rippled commands](reference-rippled.html#list-of-public-commands) can be run with:
|
||||
|
||||
$ /opt/ripple/bin/rippled <command>
|
||||
@@ -0,0 +1,59 @@
|
||||
# Load a Saved Ledger in Stand-Alone Mode
|
||||
|
||||
You can start with a ledger version that was saved to disk if your `rippled` server was previously synced with the XRP Ledger peer-to-peer network (either the production network or the [Test Net](tutorial-rippled-setup.html#parallel-networks)).
|
||||
|
||||
## 1. Start `rippled` normally.
|
||||
|
||||
To load an existing ledger, you must first retrieve that ledger from the network. Start `rippled` in online mode as normal:
|
||||
|
||||
```
|
||||
rippled --conf=/path/to/rippled.cfg
|
||||
```
|
||||
|
||||
## 2. Wait until `rippled` is synced.
|
||||
|
||||
Use the [server_info method][] to check the state of your server relative to the network. Your server is synced when the `server_state` value shows any of the following values:
|
||||
|
||||
* `full`
|
||||
* `proposing`
|
||||
* `validating`
|
||||
|
||||
For more information, see [Possible Server States](reference-rippled.html#possible-server-states).
|
||||
|
||||
## 3. (Optional) Retrieve specific ledger versions.
|
||||
|
||||
If you only want the most recent ledger, you can skip this step.
|
||||
|
||||
If you want to load a specific historical ledger version, use the [ledger_request method][] to make `rippled` fetch it. If `rippled` does not already have the ledger version, you may have to run the `ledger_request` command multiple times until it has finished retrieving the ledger.
|
||||
|
||||
If you want to replay a specific historical ledger version, you must fetch both the ledger version to replay and the ledger version before it. (The previous ledger version sets up the initial state upon which you apply the changes described by the ledger version you replay.)
|
||||
|
||||
## 4. Shut down `rippled`.
|
||||
|
||||
Use the [stop method][]:
|
||||
|
||||
```
|
||||
rippled stop --conf=/path/to/rippled.cfg
|
||||
```
|
||||
|
||||
## 5. Start `rippled` in stand-alone mode.
|
||||
|
||||
To load the most recent ledger version, you can use the [`-a`](https://wiki.ripple.com/Rippled#--standalone.2C_-a) and [`--load`](https://wiki.ripple.com/Rippled#--load) options when starting the server:
|
||||
|
||||
```
|
||||
rippled -a --load --conf=/path/to/rippled.cfg
|
||||
```
|
||||
|
||||
To instead load a specific historical ledger, use the [`--load`](https://wiki.ripple.com/Rippled#--load) parameter along with the `--ledger` parameter, providing the ledger index or identifying hash of the ledger version to load:
|
||||
|
||||
```
|
||||
rippled -a --load --ledger 19860944 --conf=/path/to/rippled.cfg
|
||||
```
|
||||
|
||||
## 6. Manually advance the ledger.
|
||||
|
||||
When you load a ledger with `--ledger` in stand-alone mode, it goes to the current open ledger, so you must [manually advance the ledger](#advancing-ledgers-in-stand-alone-mode):
|
||||
|
||||
```
|
||||
rippled ledger_accept --conf=/path/to/rippled.cfg
|
||||
```
|
||||
@@ -9,217 +9,6 @@ This page contains instructions for:
|
||||
* [Participating in the Consensus Process](#running-a-validator)
|
||||
|
||||
|
||||
|
||||
{% include '_snippets/capacity-planning.md' %}
|
||||
|
||||
# Installing rippled
|
||||
|
||||
For development, you can [compile `rippled` from source](https://wiki.ripple.com/Rippled_build_instructions).
|
||||
|
||||
Production `rippled` instances can [use Ripple's binary executable](#installation-on-centosred-hat-with-yum), available from the Ripple [yum](https://en.wikipedia.org/wiki/Yellowdog_Updater,_Modified) repository.
|
||||
|
||||
## Minimum System Requirements
|
||||
|
||||
A `rippled` server should run comfortably on commodity hardware, to make it inexpensive to participate in the network. At present, we recommend the following mimimum requirements:
|
||||
|
||||
- Operating System:
|
||||
- Production: CentOS or RedHat Enterprise Linux (latest release) or Ubuntu (16.04+) supported
|
||||
- Development: Mac OS X, Windows (64-bit), or most Linux distributions
|
||||
- CPU: 64-bit x86_64, 2+ cores
|
||||
- Disk: Minimum 50GB SSD recommended (1000 IOPS, more is better) for the database partition
|
||||
- RAM:
|
||||
- Testing: 8GB+
|
||||
- Production: 32 GB
|
||||
|
||||
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.
|
||||
|
||||
**Tip:** For recommendations beyond the minimum requirements, see [Capacity Planning](#capacity-planning).
|
||||
|
||||
## Installation on CentOS/Red Hat with yum
|
||||
|
||||
This section assumes that you are using CentOS 7 or Red Hat Enterprise Linux 7.
|
||||
|
||||
1. Install the Ripple RPM repository:
|
||||
|
||||
$ sudo rpm -Uvh https://mirrors.ripple.com/ripple-repo-el7.rpm
|
||||
|
||||
2. Install the `rippled` software package:
|
||||
|
||||
$ sudo yum install --enablerepo=ripple-stable rippled
|
||||
|
||||
3. Configure the `rippled` service to start on system boot:
|
||||
|
||||
$ sudo systemctl enable rippled.service
|
||||
|
||||
4. Start the `rippled` service
|
||||
|
||||
$ sudo systemctl start rippled.service
|
||||
|
||||
## Installation on Ubuntu with alien
|
||||
|
||||
This section assumes that you are using Ubuntu 15.04 or later.
|
||||
|
||||
1. Install yum-utils and alien:
|
||||
|
||||
$ sudo apt-get update
|
||||
$ sudo apt-get install yum-utils alien
|
||||
|
||||
2. Install the Ripple RPM repository:
|
||||
|
||||
$ sudo rpm -Uvh https://mirrors.ripple.com/ripple-repo-el7.rpm
|
||||
|
||||
3. Download the `rippled` software package:
|
||||
|
||||
$ yumdownloader --enablerepo=ripple-stable --releasever=el7 rippled
|
||||
|
||||
4. Verify the signature on the `rippled` software package:
|
||||
|
||||
$ sudo rpm --import https://mirrors.ripple.com/rpm/RPM-GPG-KEY-ripple-release && rpm -K rippled*.rpm
|
||||
|
||||
5. Install the `rippled` software package:
|
||||
|
||||
$ sudo alien -i --scripts rippled*.rpm && rm rippled*.rpm
|
||||
|
||||
6. Configure the `rippled` service to start on system boot:
|
||||
|
||||
$ sudo systemctl enable rippled.service
|
||||
|
||||
7. Start the `rippled` service
|
||||
|
||||
$ sudo systemctl start rippled.service
|
||||
|
||||
## Postinstall
|
||||
|
||||
It can take several minutes for `rippled` to sync with the rest of the network, during which time it outputs warnings about missing ledgers. After that, you have a fully functional stock `rippled` server that you can use for local signing and API access to the XRP Ledger.
|
||||
|
||||
[rippled commands](reference-rippled.html#list-of-public-commands) can be run with:
|
||||
|
||||
$ /opt/ripple/bin/rippled <command>
|
||||
|
||||
|
||||
## Updating rippled
|
||||
|
||||
You can subscribe to the [rippled Google Group](https://groups.google.com/forum/#!forum/ripple-server) to receive notifications of new `rippled` releases.
|
||||
|
||||
### Automatic Update on CentOS/Red Hat
|
||||
|
||||
Automatic rippled updates can be enabled with a one-time Cron configuration:
|
||||
|
||||
1. Check that `/opt/ripple/bin/update-rippled.sh` exists. If it does not, [update manually](#manual-update-on-centosred-hat).
|
||||
|
||||
2. Install `crond`:
|
||||
|
||||
$ sudo yum install cronie
|
||||
|
||||
3. Open the crontab file for editing
|
||||
|
||||
$ sudo crontab -e
|
||||
|
||||
4. Add the following to the crontab file. Be sure to add a blank line at the end of the file.
|
||||
|
||||
RANDOM_DELAY=59
|
||||
0 * * * * /opt/ripple/bin/update-rippled.sh
|
||||
|
||||
|
||||
The script updates the installed `rippled` package within an hour of each new release.
|
||||
|
||||
### Manual Update on CentOS/Red Hat
|
||||
|
||||
Run the following commands to update to the latest release of `rippled`:
|
||||
|
||||
$ sudo rpm -Uvh --replacepkgs https://mirrors.ripple.com/ripple-repo-el7.rpm
|
||||
$ sudo yum update --enablerepo=ripple-stable rippled
|
||||
$ sudo systemctl daemon-reload
|
||||
$ sudo service rippled restart
|
||||
|
||||
### Manual Update on Ubuntu
|
||||
|
||||
Run the following commands to update to the latest release of `rippled`:
|
||||
|
||||
$ sudo rpm -Uvh --replacepkgs https://mirrors.ripple.com/ripple-repo-el7.rpm
|
||||
$ yumdownloader --enablerepo=ripple-stable --releasever=el7 rippled
|
||||
$ rpm -K rippled*.rpm
|
||||
$ sudo alien -i --scripts rippled*.rpm
|
||||
$ sudo systemctl daemon-reload
|
||||
$ sudo service rippled restart
|
||||
|
||||
|
||||
# Running a Validator
|
||||
|
||||
Running a `rippled` validator that participates in the Consensus process is simple:
|
||||
|
||||
1. [Enable validation](#validator-setup) on your `rippled` server.
|
||||
* At first, your server is an _untrusted validator_. Others can see the validations your server issues, but they disregard them in the consensus process.
|
||||
2. Share the public key with the public, especially other `rippled` operators.
|
||||
3. When other `rippled` operators add your public key to their list of trusted servers, you have become a _trusted validator_.
|
||||
* Also see [Properties of a Good Validator](#properties-of-a-good-validator) for best practices.
|
||||
|
||||
|
||||
## Validator Setup
|
||||
|
||||
The `validator-keys` tool (included in the `rippled` RPM) is the recommended means to securely generate and manage your validator keys.
|
||||
|
||||
1. [Install a `rippled` server.](#installing-rippled)
|
||||
|
||||
2. Generate a validator key pair:
|
||||
|
||||
$ /opt/ripple/bin/validator-keys create_keys
|
||||
|
||||
**Warning:** Store the generated `validator-keys.json` key file in a secure but recoverable location, such as an encrypted USB flash drive. Do not modify its contents.
|
||||
|
||||
3. Generate a validator token and edit your `rippled.cfg` file to add the `[validator_token]` value.
|
||||
|
||||
$ /opt/ripple/bin/validator-keys create_token --keyfile /path/to/your/validator-keys.json
|
||||
|
||||
If you had previously configured your validator without using the `validator-keys` tool, you must also delete the `[validation_seed]` from your `rippled.cfg` file. This changes your validator public key.
|
||||
|
||||
4. Start `rippled`:
|
||||
|
||||
$ sudo service rippled restart
|
||||
|
||||
See [the `validator-keys-tool` GitHub repository](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md) for more information about managing validator keys.
|
||||
|
||||
|
||||
## Public-Facing Server
|
||||
|
||||
To protect a production validator from [DDoS](https://en.wikipedia.org/wiki/Denial-of-service_attack) attacks, you can use a stock `rippled` server as a proxy between the validator and the outside network.
|
||||
|
||||
1. [Set up the `rippled` validator.](#validator-setup)
|
||||
|
||||
2. [Set up one or more stock `rippled` servers.](#installing-rippled)
|
||||
|
||||
3. Configure the validator and stock `rippled` servers to be [clustered](#clustering) with each other.
|
||||
|
||||
4. Make the following configuration changes to your validator:
|
||||
* Copy the `[ips_fixed]` list and paste it under `[ips]`. These fields should contain only the IP addresses and ports of the public-facing rippled(s). The validator connects to only these peers.
|
||||
* Change `[peer_private]` to `1` to prevent its IP address from being forwarded.
|
||||
|
||||
5. Configure the validator host machine's firewall to only accept inbound connections from its public-facing rippled(s).
|
||||
|
||||
Remember to restart `rippled` for config changes to take effect.
|
||||
|
||||
Take care not to publish the IP address of your validator.
|
||||
|
||||
|
||||
## Domain Verification
|
||||
|
||||
Network participants are unlikely to trust validators without knowing who is operating them. To address this concern, validator operators can associate their validator with a web domain that they control.
|
||||
|
||||
1. Find your validator public key by running the following on the validator server:
|
||||
|
||||
$ /opt/ripple/bin/rippled server_info -q | grep pubkey_validator
|
||||
|
||||
2. Sign the validator public key (from step 1) using the SSL private key used for your domain. The SSL private key file does not need to be stored on the validator server.
|
||||
|
||||
$ openssl dgst -sha256 -hex -sign /path/to/your/ssl.key <(echo <your-validator-public-key>)
|
||||
|
||||
3. Using `validator-keys` tool (included in the `rippled` RPM), sign the domain name:
|
||||
|
||||
$ /opt/ripple/bin/validator-keys --keyfile /path/to/your/validator-keys.json sign <your-domain-name>
|
||||
|
||||
4. To have the verified validator domain included on [XRP Charts](https://xrpcharts.ripple.com/#/validators), submit this [Google Form](https://docs.google.com/forms/d/e/1FAIpQLScszfq7rRLAfArSZtvitCyl-VFA9cNcdnXLFjURsdCQ3gHW7w/viewform) with your validator's information.
|
||||
|
||||
|
||||
# Additional Configuration
|
||||
|
||||
`rippled` should connect to the XRP Ledger with the default configuration. However, you can change your settings by editing the `rippled.cfg` file (located at `/opt/ripple/etc/rippled.cfg` when installing `rippled` with yum). For recommendations about configuration settings, see [Capacity Planning](#capacity-planning).
|
||||
|
||||
@@ -0,0 +1,74 @@
|
||||
# Run rippled as a Validator
|
||||
|
||||
Running a `rippled` validator that participates in the Consensus process is simple:
|
||||
|
||||
1. [Enable validation](#validator-setup) on your `rippled` server.
|
||||
* At first, your server is an _untrusted validator_. Others can see the validations your server issues, but they disregard them in the consensus process.
|
||||
2. Share the public key with the public, especially other `rippled` operators.
|
||||
3. When other `rippled` operators add your public key to their list of trusted servers, you have become a _trusted validator_.
|
||||
* Also see [Properties of a Good Validator](#properties-of-a-good-validator) for best practices.
|
||||
|
||||
|
||||
## Validator Setup
|
||||
|
||||
The `validator-keys` tool (included in the `rippled` RPM) is the recommended means to securely generate and manage your validator keys.
|
||||
|
||||
1. [Install a `rippled` server.](#installing-rippled)
|
||||
|
||||
2. Generate a validator key pair:
|
||||
|
||||
$ /opt/ripple/bin/validator-keys create_keys
|
||||
|
||||
**Warning:** Store the generated `validator-keys.json` key file in a secure but recoverable location, such as an encrypted USB flash drive. Do not modify its contents.
|
||||
|
||||
3. Generate a validator token and edit your `rippled.cfg` file to add the `[validator_token]` value.
|
||||
|
||||
$ /opt/ripple/bin/validator-keys create_token --keyfile /path/to/your/validator-keys.json
|
||||
|
||||
If you had previously configured your validator without using the `validator-keys` tool, you must also delete the `[validation_seed]` from your `rippled.cfg` file. This changes your validator public key.
|
||||
|
||||
4. Start `rippled`:
|
||||
|
||||
$ sudo service rippled restart
|
||||
|
||||
See [the `validator-keys-tool` GitHub repository](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md) for more information about managing validator keys.
|
||||
|
||||
|
||||
## Public-Facing Server
|
||||
|
||||
To protect a production validator from [DDoS](https://en.wikipedia.org/wiki/Denial-of-service_attack) attacks, you can use a stock `rippled` server as a proxy between the validator and the outside network.
|
||||
|
||||
1. [Set up the `rippled` validator.](#validator-setup)
|
||||
|
||||
2. [Set up one or more stock `rippled` servers.](#installing-rippled)
|
||||
|
||||
3. Configure the validator and stock `rippled` servers to be [clustered](#clustering) with each other.
|
||||
|
||||
4. Make the following configuration changes to your validator:
|
||||
* Copy the `[ips_fixed]` list and paste it under `[ips]`. These fields should contain only the IP addresses and ports of the public-facing rippled(s). The validator connects to only these peers.
|
||||
* Change `[peer_private]` to `1` to prevent its IP address from being forwarded.
|
||||
|
||||
5. Configure the validator host machine's firewall to only accept inbound connections from its public-facing rippled(s).
|
||||
|
||||
Remember to restart `rippled` for config changes to take effect.
|
||||
|
||||
Take care not to publish the IP address of your validator.
|
||||
|
||||
|
||||
## Domain Verification
|
||||
|
||||
Network participants are unlikely to trust validators without knowing who is operating them. To address this concern, validator operators can associate their validator with a web domain that they control.
|
||||
|
||||
1. Find your validator public key by running the following on the validator server:
|
||||
|
||||
$ /opt/ripple/bin/rippled server_info -q | grep pubkey_validator
|
||||
|
||||
2. Sign the validator public key (from step 1) using the SSL private key used for your domain. The SSL private key file does not need to be stored on the validator server.
|
||||
|
||||
$ openssl dgst -sha256 -hex -sign /path/to/your/ssl.key <(echo <your-validator-public-key>)
|
||||
|
||||
3. Using `validator-keys` tool (included in the `rippled` RPM), sign the domain name:
|
||||
|
||||
$ /opt/ripple/bin/validator-keys --keyfile /path/to/your/validator-keys.json sign <your-domain-name>
|
||||
|
||||
4. To have the verified validator domain included on [XRP Charts](https://xrpcharts.ripple.com/#/validators), submit this [Google Form](https://docs.google.com/forms/d/e/1FAIpQLScszfq7rRLAfArSZtvitCyl-VFA9cNcdnXLFjURsdCQ3gHW7w/viewform) with your validator's information.
|
||||
@@ -0,0 +1,21 @@
|
||||
# Start a New Genesis Ledger in Stand-Alone Mode
|
||||
|
||||
In stand-alone mode, you can have `rippled` create a new genesis ledger. This provides a known state, with none of the ledger history from the production XRP Ledger. (This is very useful for unit tests, among other things.)
|
||||
|
||||
* To start `rippled` in stand-alone mode with a new genesis ledger, use the [`-a`](https://wiki.ripple.com/Rippled#--standalone.2C_-a) and [`--start`](https://wiki.ripple.com/Rippled#--start) options:
|
||||
|
||||
```
|
||||
rippled -a --start --conf=/path/to/rippled.cfg
|
||||
```
|
||||
|
||||
In a genesis ledger, the [genesis address](concept-accounts.html#special-addresses) holds all 100 billion XRP. The keys of the genesis address are [hardcoded](https://github.com/ripple/rippled/blob/94ed5b3a53077d815ad0dd65d490c8d37a147361/src/ripple/app/ledger/Ledger.cpp#L184) as follows:
|
||||
|
||||
**Address:** `rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh`
|
||||
|
||||
**Secret:** `snoPBrXtMeMyMHUVTgbuqAfg1SUTb` ("masterpassphrase")
|
||||
|
||||
## Settings in New Genesis Ledgers
|
||||
|
||||
In a new genesis ledger, the hard-coded default [Reserve](concept-reserves.html) is **200 XRP** minimum for funding a new address, with an increment of **50 XRP** per object in the ledger. These values are higher than the current reserve requirements of the production network. (See also: [Fee Voting](concept-fee-voting.html))
|
||||
|
||||
By default, a new genesis ledger has no [amendments](concept-amendments.html) enabled. If you start a new genesis ledger with `--start`, the genesis ledger contains an [EnableAmendment pseudo-transaction](reference-transaction-format.html#enableamendment) to turn on all amendments natively supported by the `rippled` server, except for amendments that you explicitly disable in the configuration file. The effects of those amendments are available starting from the very next ledger version. (Reminder: in stand-alone mode, you must [advance the ledger manually](#advancing-ledgers-in-stand-alone-mode).) [New in: rippled 0.50.0][]
|
||||
@@ -0,0 +1,45 @@
|
||||
# Update rippled
|
||||
|
||||
You can subscribe to the [rippled Google Group](https://groups.google.com/forum/#!forum/ripple-server) to receive notifications of new `rippled` releases.
|
||||
|
||||
## Automatic Update on CentOS/Red Hat
|
||||
|
||||
Automatic rippled updates can be enabled with a one-time Cron configuration:
|
||||
|
||||
1. Check that `/opt/ripple/bin/update-rippled.sh` exists. If it does not, [update manually](#manual-update-on-centosred-hat).
|
||||
|
||||
2. Install `crond`:
|
||||
|
||||
$ sudo yum install cronie
|
||||
|
||||
3. Open the crontab file for editing
|
||||
|
||||
$ sudo crontab -e
|
||||
|
||||
4. Add the following to the crontab file. Be sure to add a blank line at the end of the file.
|
||||
|
||||
RANDOM_DELAY=59
|
||||
0 * * * * /opt/ripple/bin/update-rippled.sh
|
||||
|
||||
|
||||
The script updates the installed `rippled` package within an hour of each new release.
|
||||
|
||||
## Manual Update on CentOS/Red Hat
|
||||
|
||||
Run the following commands to update to the latest release of `rippled`:
|
||||
|
||||
$ sudo rpm -Uvh --replacepkgs https://mirrors.ripple.com/ripple-repo-el7.rpm
|
||||
$ sudo yum update --enablerepo=ripple-stable rippled
|
||||
$ sudo systemctl daemon-reload
|
||||
$ sudo service rippled restart
|
||||
|
||||
## Manual Update on Ubuntu
|
||||
|
||||
Run the following commands to update to the latest release of `rippled`:
|
||||
|
||||
$ sudo rpm -Uvh --replacepkgs https://mirrors.ripple.com/ripple-repo-el7.rpm
|
||||
$ yumdownloader --enablerepo=ripple-stable --releasever=el7 rippled
|
||||
$ rpm -K rippled*.rpm
|
||||
$ sudo alien -i --scripts rippled*.rpm
|
||||
$ sudo systemctl daemon-reload
|
||||
$ sudo service rippled restart
|
||||
@@ -566,9 +566,81 @@ pages:
|
||||
targets:
|
||||
- local
|
||||
|
||||
# TODO: install rippled, troubleshoot rippled, build & run on ubuntu,
|
||||
- md: tutorials/manage-the-rippled-server/capacity-planning.md
|
||||
html: capacity-planning.html
|
||||
funnel: Docs
|
||||
doc_type: Tutorials
|
||||
category: Manage the rippled Server
|
||||
targets:
|
||||
- local
|
||||
|
||||
- md: tutorials/manage-the-rippled-server/install-rippled.md
|
||||
html: install-rippled.html
|
||||
funnel: Docs
|
||||
doc_type: Tutorials
|
||||
category: Manage the rippled Server
|
||||
targets:
|
||||
- local
|
||||
|
||||
- md: tutorials/manage-the-rippled-server/update-rippled.md
|
||||
html: update-rippled.html
|
||||
funnel: Docs
|
||||
doc_type: Tutorials
|
||||
category: Manage the rippled Server
|
||||
targets:
|
||||
- local
|
||||
|
||||
- md: tutorials/manage-the-rippled-server/cluster-rippled-servers.md
|
||||
html: cluster-rippled-servers.html
|
||||
funnel: Docs
|
||||
doc_type: Tutorials
|
||||
category: Manage the rippled Server
|
||||
targets:
|
||||
- local
|
||||
|
||||
- md: tutorials/manage-the-rippled-server/run-rippled-as-a-validator.md
|
||||
html: run-rippled-as-a-validator.html
|
||||
funnel: Docs
|
||||
doc_type: Tutorials
|
||||
category: Manage the rippled Server
|
||||
targets:
|
||||
- local
|
||||
|
||||
- md: tutorials/manage-the-rippled-server/start-a-new-genesis-ledger-in-stand-alone-mode.md
|
||||
html: start-a-new-genesis-ledger-in-stand-alone-mode.html
|
||||
funnel: Docs
|
||||
doc_type: Tutorials
|
||||
category: Manage the rippled Server
|
||||
targets:
|
||||
- local
|
||||
|
||||
- md: tutorials/manage-the-rippled-server/load-a-saved-ledger-in-stand-alone-mode.md
|
||||
html: load-a-saved-ledger-in-stand-alone-mode.html
|
||||
funnel: Docs
|
||||
doc_type: Tutorials
|
||||
category: Manage the rippled Server
|
||||
targets:
|
||||
- local
|
||||
|
||||
- md: tutorials/manage-the-rippled-server/advance-the-ledger-in-stand-alone-mode.md
|
||||
html: advance-the-ledger-in-stand-alone-mode.html
|
||||
funnel: Docs
|
||||
doc_type: Tutorials
|
||||
category: Manage the rippled Server
|
||||
targets:
|
||||
- local
|
||||
|
||||
- md: tutorials/manage-the-rippled-server/build-run-rippled-ubuntu.md
|
||||
html: build-run-rippled-ubuntu.html
|
||||
funnel: Docs
|
||||
doc_type: Tutorials
|
||||
category: Manage the rippled Server
|
||||
targets:
|
||||
- local
|
||||
|
||||
# TODO: troubleshoot rippled,
|
||||
# run a validator, run in stand-alone mode, set up private peers, run in
|
||||
# a cluster, capacity planning
|
||||
# a cluster
|
||||
|
||||
# References -------------------------------------------------------------------
|
||||
|
||||
|
||||
Reference in New Issue
Block a user