mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-20 03:35:51 +00:00
Merge pull request #876 from ripple/spelling
Spell Checking / Updated Style Checking
This commit is contained in:
Rome Reginelli
@@ -88,7 +88,7 @@ To configure advisory deletion with a daily schedule, perform the following step
|
||||
If online deletion does not seem to be running after configuring it, try the following:
|
||||
|
||||
- Check that the user who configured the `cron` job has permissions to run the `rippled` server as a commandline client.
|
||||
- Check the syntax of your cron job and the time when it is supposed to run.
|
||||
- Check the syntax of your `cron` job and the time when it is supposed to run.
|
||||
- Check that the `rippled` executable is available at the path specified in your `cron` configuration. If necessary, specify the absolute path to the executable, such as `/opt/ripple/bin/rippled`.
|
||||
- Check your `rippled` logs for messages that begin with `SHAMapStore::WRN`. This can indicate that [online deletion is being interrupted](online-deletion.html#interrupting-online-deletion) because your server fell out of sync with the network.
|
||||
|
||||
|
||||
@@ -25,7 +25,7 @@ To enable gRPC on your server, complete the following steps:
|
||||
The configurable fields are as follows:
|
||||
|
||||
- `port` field defines the port the server listens on for gRPC connections from client applications. The recommended port is `50051`.
|
||||
- `ip` defines which interfaces the server listens on. The value `0.0.0.0` listens on all available network interfaces. To limit connections to just the local loopback network (same machine), use `127.0.0.1` instead.
|
||||
- `ip` defines which interfaces the server listens on. The value `0.0.0.0` listens on all available network interfaces. To limit connections to the local loopback network (same machine), use `127.0.0.1` instead.
|
||||
|
||||
{% include '_snippets/conf-file-location.md' %}<!--_ -->
|
||||
|
||||
|
||||
@@ -20,6 +20,8 @@ Before you configure your `rippled` server to store history shards, you must dec
|
||||
|
||||
## 2. Edit rippled.cfg
|
||||
|
||||
<!-- SPELLING_IGNORE: cfg -->
|
||||
|
||||
Edit your `rippled.cfg` file to add a `[shard_db]` stanza.
|
||||
|
||||
{% include '_snippets/conf-file-location.md' %}<!--_ -->
|
||||
|
||||
@@ -1,77 +1,77 @@
|
||||
# Connect Your rippled to an XRPL Altnet
|
||||
# Connect Your rippled to an XRP Ledger Altnet
|
||||
|
||||
Ripple has created [alternative test and development networks](parallel-networks.html) for developers to test their apps on the latest non-production version of the XRP Ledger (Testnet) or to test and experiment with features on the latest beta version (Devnet). **The funds used on these networks are not real funds and are intended for testing only.** You can connect your [`rippled` server](the-rippled-server.html) to either the Testnet or Devnet.
|
||||
Ripple hosts [alternative test and development networks](parallel-networks.html) for developers to test their apps on the latest non-production version of the XRP Ledger (Testnet) or to test and experiment with features on the latest beta version (Devnet). **The funds used on these networks are not real funds and are intended for testing only.** You can connect your [`rippled` server](the-rippled-server.html) to either the Testnet or Devnet.
|
||||
|
||||
**Note:** The XRP Testnet and Devnet ledger and balances are reset on a regular basis.
|
||||
|
||||
To connect your `rippled` server to the XRP Testnet or Devnet, set the following configurations:
|
||||
|
||||
1. In your `rippled.cfg` file:
|
||||
1. Edit your `rippled.cfg` file to connect to a hub server in the network you want to connect to.
|
||||
|
||||
a. To connect to the [Testnet](xrp-testnet-faucet.html), uncomment the following section and add:
|
||||
1. To connect to the [Testnet](xrp-testnet-faucet.html), uncomment or add the following section:
|
||||
|
||||
[ips]
|
||||
s.altnet.rippletest.net 51235
|
||||
[ips]
|
||||
s.altnet.rippletest.net 51235
|
||||
|
||||
b. To connect to the [Devnet](xrp-testnet-faucet.html), uncomment the following section and add:
|
||||
2. To connect to the [Devnet](xrp-testnet-faucet.html), uncomment or add the following section:
|
||||
|
||||
[ips]
|
||||
s.devnet.rippletest.net 51235
|
||||
[ips]
|
||||
s.devnet.rippletest.net 51235
|
||||
|
||||
c. Comment out the following section, as follows:
|
||||
3. Comment out the existing `[ips]` stanza:
|
||||
|
||||
# [ips]
|
||||
# r.ripple.com 51235
|
||||
# [ips]
|
||||
# r.ripple.com 51235
|
||||
|
||||
|
||||
|
||||
2. In your `validators.txt` file:
|
||||
2. Edit your `validators.txt` file.
|
||||
|
||||
2a. Changes to connect to the Testnet
|
||||
- To connect to the Testnet:
|
||||
|
||||
a. Uncomment the following sections, as follows to connect to the altnet:
|
||||
1. Uncomment the following sections:
|
||||
|
||||
[validator_list_sites]
|
||||
https://vl.altnet.rippletest.net
|
||||
[validator_list_sites]
|
||||
https://vl.altnet.rippletest.net
|
||||
|
||||
[validator_list_keys]
|
||||
ED264807102805220DA0F312E71FC2C69E1552C9C5790F6C25E3729DEB573D5860
|
||||
[validator_list_keys]
|
||||
ED264807102805220DA0F312E71FC2C69E1552C9C5790F6C25E3729DEB573D5860
|
||||
|
||||
b. Comment out the following sections, as follows:
|
||||
1. Comment out the following sections, as follows:
|
||||
|
||||
# [validator_list_sites]
|
||||
# https://vl.ripple.com
|
||||
#
|
||||
# [validator_list_keys]
|
||||
# ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
|
||||
# [validator_list_sites]
|
||||
# https://vl.ripple.com
|
||||
#
|
||||
# [validator_list_keys]
|
||||
# ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
|
||||
|
||||
2b. Changes to connect to the Devnet
|
||||
- To connect to the Devnet:
|
||||
|
||||
a. Comment out the following sections as follows:
|
||||
1. Comment out the following sections:
|
||||
|
||||
# [validator_list_sites]
|
||||
# https://vl.altnet.rippletest.net
|
||||
# [validator_list_sites]
|
||||
# https://vl.altnet.rippletest.net
|
||||
|
||||
# [validator_list_keys]
|
||||
# ED264807102805220DA0F312E71FC2C69E1552C9C5790F6C25E3729DEB573D5860
|
||||
# [validator_list_keys]
|
||||
# ED264807102805220DA0F312E71FC2C69E1552C9C5790F6C25E3729DEB573D5860
|
||||
|
||||
# [validator_list_sites]
|
||||
# https://vl.ripple.com
|
||||
#
|
||||
# [validator_list_keys]
|
||||
# ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
|
||||
# [validator_list_sites]
|
||||
# https://vl.ripple.com
|
||||
#
|
||||
# [validator_list_keys]
|
||||
# ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
|
||||
|
||||
b. Add the following trusted validators to the validator.txt file:
|
||||
2. Add the following trusted validators to the `validator.txt` file:
|
||||
|
||||
# Hard-coded List of Devnet Validators
|
||||
[validators]
|
||||
n9Mo4QVGnMrRN9jhAxdUFxwvyM4aeE1RvCuEGvMYt31hPspb1E2c
|
||||
n9MEwP4LSSikUnhZJNQVQxoMCgoRrGm6GGbG46AumH2KrRrdmr6B
|
||||
n9M1pogKUmueZ2r3E3JnZyM3g6AxkxWPr8Vr3zWtuRLqB7bHETFD
|
||||
n9MX7LbfHvPkFYgGrJmCyLh8Reu38wsnnxA4TKhxGTZBuxRz3w1U
|
||||
n94aw2fof4xxd8g3swN2qJCmooHdGv1ajY8Ae42T77nAQhZeYGdd
|
||||
n9LiE1gpUGws1kFGKCM9rVFNYPVS4QziwkQn281EFXX7TViCp2RC
|
||||
n9Jq9w1R8UrvV1u2SQqGhSXLroeWNmPNc3AVszRXhpUr1fmbLyhS
|
||||
# Hard-coded List of Devnet Validators
|
||||
[validators]
|
||||
n9Mo4QVGnMrRN9jhAxdUFxwvyM4aeE1RvCuEGvMYt31hPspb1E2c
|
||||
n9MEwP4LSSikUnhZJNQVQxoMCgoRrGm6GGbG46AumH2KrRrdmr6B
|
||||
n9M1pogKUmueZ2r3E3JnZyM3g6AxkxWPr8Vr3zWtuRLqB7bHETFD
|
||||
n9MX7LbfHvPkFYgGrJmCyLh8Reu38wsnnxA4TKhxGTZBuxRz3w1U
|
||||
n94aw2fof4xxd8g3swN2qJCmooHdGv1ajY8Ae42T77nAQhZeYGdd
|
||||
n9LiE1gpUGws1kFGKCM9rVFNYPVS4QziwkQn281EFXX7TViCp2RC
|
||||
n9Jq9w1R8UrvV1u2SQqGhSXLroeWNmPNc3AVszRXhpUr1fmbLyhS
|
||||
|
||||
|
||||
3. Restart `rippled`.
|
||||
|
||||
@@ -34,7 +34,7 @@ Strive to have your validator always embody the following properties. Being a go
|
||||
|
||||
- **Identified**
|
||||
|
||||
A good validator has a clearly identified owner. Providing [domain verification](#6-provide-domain-verification) is a good start. Ideally, XRP Ledger network UNLs include validators operated by different owners in multiple legal jurisdictions and geographic areas. This reduces the chance that any localized events could interfere with the impartial operations of trusted validators.
|
||||
A good validator has a clearly identified owner. Providing [domain verification](#6-provide-domain-verification) is a good start. Ideally, XRP Ledger network UNLs include validators run by different owners in multiple legal jurisdictions and geographic areas. This reduces the chance that any localized events could interfere with the impartial operations of trusted validators.
|
||||
|
||||
Ripple (the company) publishes a [validator list](https://github.com/ripple/rippled/blob/develop/cfg/validators-example.txt) with a set of recommended validators. Ripple strongly recommends using exactly this list for production servers.
|
||||
|
||||
@@ -48,7 +48,7 @@ For more information, see [Install `rippled`](install-rippled.html).
|
||||
|
||||
## 3. Enable validation on your `rippled` server
|
||||
|
||||
Enabling validation on your `rippled` server means providing a validator token in your server's `rippled.cfg` file. Ripple recommends using the `validator-keys` tool (included in `rippled` RPMs) to securely generate and manage your validator keys and tokens.
|
||||
Enabling validation on your `rippled` server means providing a validator token in your server's `rippled.cfg` file. Ripple recommends using the `validator-keys` tool (included in `rippled` packages) to securely generate and manage your validator keys and tokens.
|
||||
|
||||
In a location **not** on your validator:
|
||||
|
||||
@@ -80,7 +80,7 @@ In a location **not** on your validator:
|
||||
|
||||
$ validator-keys create_token --keyfile /PATH/TO/YOUR/validator-keys.json
|
||||
|
||||
Sample output:
|
||||
Sample output:
|
||||
|
||||
Update rippled.cfg file with these values:
|
||||
|
||||
@@ -133,7 +133,7 @@ For a comparison of these approaches, see [Pros and Cons of Peering Configuratio
|
||||
|
||||
This configuration connects your validator to the XRP Ledger network using [discovered peers](peer-protocol.html#peer-discovery). This is the default behavior for `rippled` servers.
|
||||
|
||||
_**To connect your validator to the XRP Ledger network using discovered peers,**_ omit the `[peer_private]` stanza or set it to `0` in your validator's `rippled.cfg` file. The [example rippled.cfg file](https://github.com/ripple/rippled/blob/develop/cfg/rippled-example.cfg) is delivered with this configuration.
|
||||
_**To connect your validator to the XRP Ledger network using discovered peers,**_ omit the `[peer_private]` stanza or set it to `0` in your validator's `rippled.cfg` file. The [example `rippled.cfg` file](https://github.com/ripple/rippled/blob/develop/cfg/rippled-example.cfg) is delivered with this configuration.
|
||||
|
||||
|
||||
### Connect using proxies
|
||||
@@ -225,13 +225,13 @@ Here are some methods you can use to verify that your validator has a healthy co
|
||||
|
||||
## 6. Provide domain verification
|
||||
|
||||
To help validation list publishers and other participants in the XRP Ledger network understand who operates your validator, provide domain verification for your validator. At a high level, domain verification is a two-way link:
|
||||
To help validation list publishers and other participants in the XRP Ledger network understand who runs your validator, provide domain verification for your validator. At a high level, domain verification is a two-way link:
|
||||
|
||||
- Use your domain to claim ownership of a validator key.
|
||||
|
||||
- Use your validator key to claim ownership of a domain.
|
||||
|
||||
Creating this link establishes strong evidence that you own both the validator key and the domain. Providing this evidence is just one aspect of [being a good validator](#1-understand-the-traits-of-a-good-validator).
|
||||
Creating this link establishes strong evidence that you own both the validator key and the domain. Providing this evidence is one aspect of [being a good validator](#1-understand-the-traits-of-a-good-validator).
|
||||
|
||||
To provide domain verification:
|
||||
|
||||
@@ -259,7 +259,7 @@ To provide domain verification:
|
||||
|
||||
Provide the value returned in the **SSL Signature** field of the Google Form.
|
||||
|
||||
3. Using the [`validator-keys` tool](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md) (included in `rippled` RPMs), sign the domain name.
|
||||
3. Using the [`validator-keys` tool](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md) (included in `rippled` packages), sign the domain name.
|
||||
|
||||
$ validator-keys --keyfile /PATH/TO/YOUR/validator-keys.json sign YOUR_DOMAIN_NAME
|
||||
|
||||
|
||||
@@ -18,14 +18,12 @@ A wallet server does all of the following:
|
||||
|
||||
For more information, see [Install `rippled`](install-rippled.html).
|
||||
|
||||
<!--{TODO: Include instructions on how to enable GRPC once rippled v 1.5.0 is released}-->
|
||||
|
||||
## 2. Enable validation on your wallet server
|
||||
|
||||
For more information, see [Enable validation on your `rippled` server](run-rippled-as-a-validator.html#3-enable-validation-on-your-rippled-server).
|
||||
|
||||
**Warning:** Validators should not be accessible to the public. Do not allow public websockets access to your wallet server or any other form of public access.
|
||||
|
||||
**Warning:** Validators should not be accessible to the public. Do not allow public WebSocket access to your wallet server or any other form of public access.
|
||||
|
||||
## 3. Provide domain verification
|
||||
|
||||
For more information, see [Provide domain verification](run-rippled-as-a-validator.html#6-provide-domain-verification).
|
||||
|
||||
@@ -9,7 +9,7 @@ Use these steps to manually connect your server to a specific [peer](peer-protoc
|
||||
|
||||
- You must know the IP address of the peer you want to connect to.
|
||||
- You must know what port the peer you want to connect to uses for the XRP Ledger [peer protocol](peer-protocol.html). By default, this is port 51235.
|
||||
- You must have a network connection from your server to the peer. For example, the peer server must [forward the apppropriate port through its firewall](forward-ports-for-peering.html).
|
||||
- You must have a network connection from your server to the peer. For example, the peer server must [forward the appropriate port through its firewall](forward-ports-for-peering.html).
|
||||
- The peer server must have available peer slots. If the peer is already at its maximum number of peers, you can ask the peer server's operator to add a [peer reservation](use-a-peer-reservation.html) for your server.
|
||||
|
||||
## Steps
|
||||
|
||||
@@ -150,7 +150,7 @@ As a server administrator, you can manage the reservations your server has for o
|
||||
- Remove one of your reservations using the [peer_reservations_del method][].
|
||||
- Check which peers are currently connected and how much bandwidth they have used, using the [peers method][].
|
||||
|
||||
**Tip:** Although there is no API method to immediately disconnect from an unwanted peer, you can use a software firewall such as `firewalld` to block an unwanted peer from connecting to your server. For examples, see the community-contributed [rbh script](https://github.com/gnanderson/rbh).
|
||||
**Tip:** Although there is no API method to immediately disconnect from an unwanted peer, you can use a software firewall such as `firewalld` to block an unwanted peer from connecting to your server. For examples, see the community-contributed [rbh script](https://github.com/gnanderson/rbh). <!-- SPELLING_IGNORE: rbh -->
|
||||
|
||||
|
||||
## See Also
|
||||
|
||||
@@ -6,7 +6,7 @@ That said, macOS is suitable for many development and testing tasks. `rippled` h
|
||||
|
||||
For development purposes, run `rippled` as a non-admin user, not using `sudo`.
|
||||
|
||||
1. Install [Xcode](https://developer.apple.com/download/).
|
||||
1. Install [Xcode](https://developer.apple.com/download/). <!-- SPELLING_IGNORE: xcode -->
|
||||
|
||||
0. Install Xcode command line tools.
|
||||
|
||||
@@ -42,7 +42,7 @@ For development purposes, run `rippled` as a non-admin user, not using `sudo`.
|
||||
|
||||
2. Edit below code with your Boost directory location and run to add Boost environment variable to your `.bash_profile` file so it's automatically set when you log in.
|
||||
|
||||
$ echo $"export BOOST_ROOT=/Users/my_user/boost_1_71_0" >> ~/.bash_profile
|
||||
$ echo "export BOOST_ROOT=/Users/my_user/boost_1_71_0" >> ~/.bash_profile
|
||||
|
||||
0. If you updated your `.bash_profile` file in the previous step, be sure to source it in a new Terminal window. For example:
|
||||
|
||||
@@ -65,7 +65,7 @@ For development purposes, run `rippled` as a non-admin user, not using `sudo`.
|
||||
|
||||
Or, you can checkout one of the tagged releases listed on [GitHub](https://github.com/ripple/rippled/releases).
|
||||
|
||||
0. In the `rippled` directory you just cloned, create your build directory and access it. For example:
|
||||
0. In the `rippled` directory you cloned, create your build directory and access it. For example:
|
||||
|
||||
$ mkdir my_build
|
||||
$ cd my_build
|
||||
|
||||
@@ -97,7 +97,7 @@ These instructions use Ubuntu's APT (Advanced Packaging Tool) to install the sof
|
||||
|
||||
|
||||
|
||||
8. If you previously built, or (more importantly) tried and failed to build `rippled`, you should delete the `my_build/` directory (or whatever you named it) to start clean before moving on to the next step. Otherwise, you may get unexpected behavior, like a `rippled` executable that crashes due to a segmentation fault (segfault).
|
||||
8. If you previously built, or (more importantly) tried and failed to build `rippled`, you should delete the `my_build/` directory (or whatever you named it) to start clean before moving on to the next step. Otherwise, you may get unexpected behavior, like a `rippled` executable that crashes due to a segmentation fault (segfault). <!-- SPELLING_IGNORE: segfault -->
|
||||
|
||||
If this is your first time building `rippled` 1.0.0 or higher, you won't have a `my_build/` directory and can move on to the next step.
|
||||
|
||||
|
||||
@@ -19,16 +19,16 @@ Ripple recommends you always use the largest node size your available RAM can su
|
||||
|
||||
#### 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 32GB 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 |
|
||||
|:----------------------------|:------------------|:---------------------------|
|
||||
| < 8GB | `tiny` | Not recommended for testing or production servers. This is the default value if you don't specify a value in `rippled.cfg`. |
|
||||
| 8GB | `small` | Recommended for test servers. |
|
||||
| 16GB | `medium` | The `rippled-example.cfg` file uses this value. |
|
||||
| 32GB | `huge` | Recommended for production servers. |
|
||||
| < 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. |
|
||||
| 16 GB | `medium` | The `rippled-example.cfg` file uses this value. |
|
||||
| 32 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`.
|
||||
|
||||
@@ -47,13 +47,13 @@ You can set the value to either `RocksDB` or `NuDB`.
|
||||
|
||||
- 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 even just a 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`. [Learn more](#more-about-using-rocksdb)
|
||||
|
||||
The example `rippled-example.cfg` file has the `type` field in the `[node_db]` stanza set to `RocksDB`.
|
||||
|
||||
#### More About Using RocksDB
|
||||
|
||||
[RocksDB](https://rocksdb.org/docs/getting-started.html) is an embeddable persistent key-value store.
|
||||
[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.
|
||||
|
||||
@@ -121,7 +121,7 @@ For best performance in enterprise production environments, Ripple recommends ru
|
||||
- CPU: Intel Xeon 3+ GHz processor with 4 cores and hyperthreading enabled
|
||||
- Disk speed: SSD (7000+ writes/second, 10,000+ reads/second)
|
||||
- Disk space: Varies. At least 50 GB recommended.
|
||||
- RAM: 32GB
|
||||
- RAM: 32 GB
|
||||
- Network: Enterprise data center network with a gigabit network interface on the host
|
||||
|
||||
#### CPU Utilization and Virtualization
|
||||
@@ -165,7 +165,7 @@ If you want to contribute to storing ledger history but you do not have enough d
|
||||
|
||||
##### 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.
|
||||
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. <!-- SPELLING_IGNORE: iops, ebs, aws -->
|
||||
|
||||
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.
|
||||
|
||||
@@ -183,9 +183,9 @@ Here are examples of observed network bandwidth use for common `rippled` tasks:
|
||||
|
||||
| Task | Transmit/Receive |
|
||||
|:------------------------------------------------|:---------------------------|
|
||||
| Process current transaction volumes | 2Mbps transmit, 2 Mbps receive |
|
||||
| Serve historical ledger and transaction reports | 100Mbps transmit |
|
||||
| Start up `rippled` | 20Mbps receive |
|
||||
| Process current transaction volumes | 2 Mbps transmit, 2 Mbps receive |
|
||||
| Serve historical ledger and transaction reports | 100 Mbps transmit |
|
||||
| Start up `rippled` | 20 Mbps receive |
|
||||
|
||||
|
||||
## See Also
|
||||
|
||||
@@ -45,7 +45,7 @@ Before you install `rippled`, you must meet the [System Requirements](system-req
|
||||
|
||||
The above example is appropriate for **Ubuntu 18.04 Bionic Beaver**. For other operating systems, replace the word `bionic` with one of the following:
|
||||
|
||||
- `xenial` for **Ubuntu 16.04 Xenial Xerus**
|
||||
- `xenial` for **Ubuntu 16.04 Xenial Xerus** <!-- SPELLING_IGNORE: xenial, xerus -->
|
||||
- `stretch` for **Debian 9 Stretch**
|
||||
|
||||
If you want access to development or pre-release versions of `rippled`, use one of the following instead of `stable`:
|
||||
|
||||
@@ -8,8 +8,10 @@ A `rippled` server should run comfortably on commodity hardware, to make it inex
|
||||
- Production: CentOS or RedHat Enterprise Linux (latest release), Ubuntu (16.04+), or Debian (9.x) supported
|
||||
- Development: Mac OS X, Windows (64-bit), or most Linux distributions
|
||||
- CPU: 64-bit x86_64, 2+ cores
|
||||
- Disk: Minimum 50GB for the database partition. SSD strongly recommended (minimum 1000 IOPS, more is better)
|
||||
- RAM: 8GB+
|
||||
- Disk: Minimum 50 GB for the database partition. SSD strongly recommended (minimum 1000 IOPS, more is better)
|
||||
- RAM: 8 GB+
|
||||
|
||||
<!-- SPELLING_IGNORE: iops, ntp, x86_64 -->
|
||||
|
||||
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.
|
||||
|
||||
@@ -22,8 +24,8 @@ For best performance in enterprise production environments, Ripple recommends ru
|
||||
- CPU: Intel Xeon 3+ GHz processor with 4 cores and hyperthreading enabled
|
||||
- Disk: SSD (7000+ writes/second, 10,000+ reads/second)
|
||||
- RAM:
|
||||
- For testing: 8GB+
|
||||
- For production: 32GB
|
||||
- For testing: 8 GB+
|
||||
- For production: 32 GB
|
||||
- Network: Enterprise data center network with a gigabit network interface on the host
|
||||
|
||||
## System Time
|
||||
|
||||
@@ -12,7 +12,7 @@ To set up automatic updates, complete the following steps:
|
||||
|
||||
$ sudo ln -s /opt/ripple/etc/update-rippled-cron /etc/cron.d/
|
||||
|
||||
This cron 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 reduce the chance of outages from all servers updating simultaneously, the script delays the update for a random number of minutes, up to 59.
|
||||
|
||||
**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.
|
||||
|
||||
|
||||
@@ -14,7 +14,7 @@ In a genesis ledger, the [genesis address](accounts.html#special-addresses) hold
|
||||
|
||||
**Address:** `rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh`
|
||||
|
||||
**Secret:** `snoPBrXtMeMyMHUVTgbuqAfg1SUTb` ("masterpassphrase")
|
||||
**Secret:** `snoPBrXtMeMyMHUVTgbuqAfg1SUTb` ("`masterpassphrase`")
|
||||
|
||||
## Settings in New Genesis Ledgers
|
||||
|
||||
|
||||
@@ -99,7 +99,7 @@ The `rippled` executable returns the following message if it wasn't able to conn
|
||||
|
||||
This generally indicates one of several problems:
|
||||
|
||||
- The `rippled` server is just starting up, or is not running at all. Check the status of the service; if it is running, wait a few seconds and try again.
|
||||
- The `rippled` server is starting up, or is not running at all. Check the status of the service; if it is running, wait a few seconds and try again.
|
||||
- You may need to pass different [parameters to the `rippled` commandline client](commandline-usage.html#client-mode-options) to connect to your server.
|
||||
- The `rippled` server may be configured not to accept JSON-RPC connections.
|
||||
|
||||
@@ -138,7 +138,7 @@ To use the script:
|
||||
should verify before posting.
|
||||
####################################################
|
||||
|
||||
The script collects the output of numerous commands and writes them to a temporary file. The filename is randomized with a string of letters and numbers (case-sensitive), for example: `/tmp/ripple_info.Xo8Xr/rippled_info.md`
|
||||
The script collects the output of many commands and writes them to a temporary file. The filename is randomized with a string of letters and numbers (case-sensitive), for example: `/tmp/ripple_info.Xo8Xr/rippled_info.md`
|
||||
|
||||
|
||||
2. Look over the output file for sensitive information.
|
||||
@@ -149,7 +149,7 @@ To use the script:
|
||||
|
||||
3. Upload the output file where others can see it.
|
||||
|
||||
You can upload the file directly to [GitHub Gist](https://gist.github.com/), [Pastebin](https://pastebin.com/), or a similar service. If you are running `rippled` on a remote server, you may find it easier to first transfer the file to a machine with a web browser, using `scp` or a similar tool.
|
||||
You can upload the file directly to [GitHub Gist](https://gist.github.com/), [Pastebin](https://pastebin.com/), or a similar service. If you are running `rippled` on a remote server, you may find it easier to first transfer the file to a machine with a web browser, using `scp` or a similar tool. <!-- SPELLING_IGNORE: pastebin -->
|
||||
|
||||
|
||||
## See Also
|
||||
|
||||
@@ -6,11 +6,11 @@ This document describes steps to detect and correct this problem if it occurs.
|
||||
|
||||
## Background
|
||||
|
||||
`rippled` servers store a copy of their transaction history in a SQLite database. Before version 0.40.0, `rippled` configured this database to have a capacity of roughly 2TB. For most uses, this is plenty. However, full transaction history back to ledger 32570 (the oldest ledger version available in the production XRP Ledger history) is likely to exceed this exceed the SQLite database capacity. `rippled` servers version 0.40.0 and later create their SQLite database files with a larger capacity, so they are unlikely to encounter this problem.
|
||||
`rippled` servers store a copy of their transaction history in a SQLite database. Before version 0.40.0, `rippled` configured this database to have a capacity of roughly 2 TB. For most uses, this is plenty. However, full transaction history back to ledger 32570 (the oldest ledger version available in the production XRP Ledger history) is likely to exceed this exceed the SQLite database capacity. `rippled` servers version 0.40.0 and later create their SQLite database files with a larger capacity, so they are unlikely to encounter this problem.
|
||||
|
||||
The capacity of the SQLite database is a result of the database's _page size_ parameter, which cannot be easily changed after the database is created. (For more information on SQLite's internals, see [the official SQLite documentation](https://www.sqlite.org/fileformat.html).) The database can reach its capacity even if there is still free space on the disk and filesystem where it is stored. As described in the [Fix](#fix) below, reconfiguring the page size to avoid this problem requires a somewhat time-consuming migration process.
|
||||
|
||||
**Tip:** Full history is not necessary to operate a `rippled` server for most use cases. Servers with full transaction history may be useful for long-term analysis and archive purposes or as a precaution against disasters. For a less resource-intense way to contribute to the storage of transaction history, see [History Sharding](history-sharding.html).
|
||||
**Tip:** Full history is not necessary for most use cases. Servers with full transaction history may be useful for long-term analysis and archive purposes or as a precaution against disasters. For a less resource-intense way to contribute to the storage of transaction history, see [History Sharding](history-sharding.html).
|
||||
|
||||
|
||||
## Detection
|
||||
@@ -36,7 +36,7 @@ Transaction DB pathname: /opt/rippled/transaction.db; SQLite page size: 1024
|
||||
|
||||
The value `SQLite page size: 1024 bytes` indicates that your transaction database is configured with a smaller page size and does not have capacity for full transaction history. If the value is already 4096 bytes or higher, then your SQLite database should already have adequate capacity to store full transaction history and you do not need to perform the migration described in this document.
|
||||
|
||||
The `rippled` server halts if the `Free space` described in this log message becomes less than 524288000 bytes (500MB). If your free space is approaching that threshold, [fix the problem](#fix) to avoid an unexpected outage.
|
||||
The `rippled` server halts if the `Free space` described in this log message becomes less than 524288000 bytes (500 MB). If your free space is approaching that threshold, [fix the problem](#fix) to avoid an unexpected outage.
|
||||
|
||||
### Reactive Detection
|
||||
|
||||
|
||||
@@ -32,7 +32,7 @@ If the problem persists, check the other possibilities listed on this page. If n
|
||||
The most common cause of syncing issues is not meeting the [system requirements](system-requirements.html). The three most common shortfalls are:
|
||||
|
||||
- **Slow disks.** You need a consistently fast solid state disk (SSD). Cloud providers like AWS usually don't guarantee disk performance, which may be impacted by other users of shared hardware.
|
||||
- **Insufficient RAM.** The memory requirements vary depending on several factors including ones that are hard to predict like network load and how people use the XRP Ledger, so it's good to have more than the minimum system requirements just in case.
|
||||
- **Insufficient RAM.** The memory requirements vary depending on several factors including ones that are hard to predict like network load and how people use the XRP Ledger, so it's good to have more than the minimum system requirements.
|
||||
- **Poor network connection.** Network requirements vary the most based on how people use the XRP Ledger, but a slow or unstable connection can make it impossible to keep up with new transactions and data added to the XRP Ledger.
|
||||
|
||||
If you are having trouble remaining synced, double-check that your server meets the system requirements. Depending on how you use your server, you may need to meet the higher "Recommended" requirements instead of just the "Minimum" requirements. If you meet the "Recommended" requirements and still cannot sync, try the other possibilities on this page.
|
||||
@@ -106,6 +106,7 @@ As a test, you can temporarily change the paths to your server's databases as lo
|
||||
- [server_info method][]
|
||||
- [validator_list_sites method][]
|
||||
|
||||
<!-- SPELLING_IGNORE: aws -->
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
|
||||
@@ -209,6 +209,7 @@ To fix this problem, do one of the following, then restart the server:
|
||||
- [`rippled` Commandline Usage](commandline-usage.html)
|
||||
- [server_info method][]
|
||||
|
||||
<!-- SPELLING_IGNORE: cfg, node_size -->
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
|
||||
@@ -35,7 +35,7 @@ Log messages such as the following indicate that a server received validations f
|
||||
2018-Aug-28 22:55:58.316094260 Validations:WRN Val for 2137ACEFC0D137EFA1D84C2524A39032802E4B74F93C130A289CD87C9C565011 trusted/full from nHUeUNSn3zce2xQZWNghQvd9WRH6FWEnCBKYVJu2vAizMxnXegfJ signing key n9KcRZYHLU9rhGVwB9e4wEMYsxXvUfgFxtmX25pc1QPNgweqzQf5 already validated sequence at or past 12133663 src=1
|
||||
```
|
||||
|
||||
Occasional messages of this type do not usually indicate a problem. If this type of message occurs frequently with the same sending validator, it could indicate a problem, including any of the following (roughly in order of most to least likely):
|
||||
Occasional messages of this type do not usually indicate a problem. If this type of message occurs often with the same sending validator, it could indicate a problem, including any of the following (roughly in order of most to least likely):
|
||||
|
||||
- The server writing the message is having network issues.
|
||||
- The validator described in the message is having network issues.
|
||||
@@ -57,7 +57,7 @@ This could mean:
|
||||
|
||||
Check the `[insight]` stanza in your `rippled`'s config file and confirm that you have network connectivity from your `rippled` server to your StatsD server.
|
||||
|
||||
This error has no other impact on the `rippled` server, which should continue to operate as normal except for the sending of StatsD metrics.
|
||||
This error has no other impact on the `rippled` server, which should continue to work as normal except for the sending of StatsD metrics.
|
||||
|
||||
|
||||
## Connection reset by peer
|
||||
@@ -138,7 +138,7 @@ These two types of messages often occur together, when a long-running job causes
|
||||
|
||||
It is **normal** to display several messages of these types **during the first few minutes** after starting the server.
|
||||
|
||||
If the messages continue for more than 5 minutes after starting the server, especially if the `run` times are well over 1000ms, that may indicate that **your server does not have sufficient resources, such as disk I/O, RAM, or CPU**. This may be caused by not having sufficiently-powerful hardware or because other processes running on the same hardware are competing with `rippled` for resources. (Examples of other processes that may compete with `rippled` for resources include scheduled backups, virus scanners, and periodic database cleaners.)
|
||||
If the messages continue for more than 5 minutes after starting the server, especially if the `run` times are well over 1000 ms, that may indicate that **your server does not have sufficient resources, such as disk I/O, RAM, or CPU**. This may be caused by not having sufficiently-powerful hardware or because other processes running on the same hardware are competing with `rippled` for resources. (Examples of other processes that may compete with `rippled` for resources include scheduled backups, virus scanners, and periodic database cleaners.)
|
||||
|
||||
Another possible cause is trying to use NuDB on rotational hard disks; NuDB should only be used with solid state drives (SSDs). Ripple recommends always using SSD storage for `rippled`'s databases, but you _may_ be able to run `rippled` successfully on rotational disks using RocksDB. If you are using rotational disks, make sure both the `[node_db]` and the `[shard_db]` (if you have one) are configured to use RocksDB. For example:
|
||||
|
||||
@@ -296,6 +296,8 @@ NetworkOPs:WRN We are not running on the consensus ledger
|
||||
- [`rippled` Commandline Usage](commandline-usage.html)
|
||||
- [server_info method][]
|
||||
|
||||
<!-- SPELLING_IGNORE: oom, async_send, statsd, inboundledger, loadmonitor, validatedseq -->
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
|
||||
Reference in New Issue
Block a user