ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-20 19:55:54 +00:00
Code Issues Packages Projects Releases Wiki Activity

Information Architecture v3 (#1934)

Browse Source 
* Update look up escrows to remove redundant info about lookups via sender/destination. Modify cancel expired escrow for brevity.

* Cancel escrow: fix notes

* Add draft of updated cancel-escrow.js.

* Update intro to escrows.

* Add Escrow Tutorial

* Minor corrections

* Fix headings, add HTML

* Update escrow docs

This commit re-creates f205a92db2 with
some adjustments:

- Omit the accidentally-created dir full of junk
- Fix some typos and one mistake in the Escrow limitations section
- Add a table to the EscrowCreate ref to clarify valid combos of fields.

* Concept info from send-a-time-held-escrow added to escrow.md

* IA: Move "Consensus Network" files

This re-creates some work from the original commit 56fffe0b9f

* Rewrite escrows article (re-created)

This commit re-creates relevant work from the following commits:

9a4a588f2b Update escrow.md context info
e1b017dc83 Remove references to using escrow for interledger payments.

* IA: Move "XRPL servers" files

This re-creates some work from original commit 7611979abf

* IA: move "production readiness" files.

Re-creates work from the following commit:

692438693a  Move tutorials to concepts

* New intro articles

Original commit: 56fffe0b9f

* IA: Reorg account concepts

Re-creates some work from original commit 56fffe0b9f

* IA: reorg transaction concepts

Original commits:
9d4eff9940  WIP - reorg accounts
7611979abf  WIP dir. reorg

* IA: reorg consensus concepts

Original commit: 56fffe0b9f

* IA: Reorg ledger docs

Original commit: 56fffe0b9f

- Rephrased some details of the section

* IA: rename issuing/operational addresses page

Original commit: 56fffe0b9f

* Moving use cases

* Fleshing out Use Cases

Note, the dactyl-config.yml file has not been fully updated.

* Clean up checks conceptual info.

* Remove redundant checks use case section

Original commit: 3c29e9c05e

* IA: move Dex under tokens

Original commit: d08b3ba7d7

* Touch up stablecoin issuer use case (#1856)

* Consolidate stablecoin use case

* Stablecoin issuer: cleanup progress through sending

* Stablecoin issuer: reorg second half

(Note: the dactyl-config.yml is not fully reconciled yet)

* Move rippled and clio tutorials into infrastructure

* Remove link to checks amendement.

* Add note to account_objects.md about commandline interface type field.

* Merge expiration case with lifecycle section.

* Interoperability Use Cases

* Add graphics to intro

* Move escrow use cases to dedicated page.

* Update use case page intros and corresponding concept info.

* Clarify meaning of direct XRP payments.

* Intro link updates

* Payment use cases

* Remove some unnecessary links in transactions section

Original commit: e6fcf4a4dc

* Link cleanup in Tokens section

Original commit: 9588dd5e70

* Touch up 'Configure Peering' section

Original commit: fc8f0990b8

* Clean up links in accounts section

Original commit: 3da5fde7a8

* Add NFT mkt use case

* p2p payments: edits to Wallets

* Clean up payments use cases

* Refine history description

* IA: use case cleanup

* IA: reconcile servers, ledgers sections

* IA: reconcile payment types, tx, tokens

* IA: reconcile accounts section

* IA: reconcile infra

* IA: Fix most broken links

* Full Docs Index: omit from sidebar

* IA: fix up most broken links

* fix Absolute path link to internal content

* Quick updates to Software Ecosystem

* Remove some absolute links to internal resources

* Fix remaining broken links in JA target

* Contributing: tweak formatting

* Tutorials: fix some minor issues

* remove interop use cases

* remove intro image and personal references to dennis

* alphabetize-transaction-nav

* Remove unused files

* Add QS escrow tutorials

* IA: move ledgers, consensus protocol files around

* IA: update nav for new page hierarchy

* reordering of topics under new networks and servers top-nav

* Move "Naming" to "What is XRP?"

* Update dactyl-config.yml

Remove xrp.md from the TOC.

* Update list-xrp-as-an-exchange.md

Update link to what-is-xrp

* Update list-xrp-as-an-exchange.ja.md

Change link to what-is-xrp

* Update currency-formats.md

Change link to what-is-xrp

* Update currency-formats.ja.md

Change link to what-is-xrp

* Update cancel-an-expired-escrow.md

Change link to what-is-xrp

* Update paymentchannelfund.md

Change link to what-is-xml

* Update look-up-escrows.md

Change link to what-is-xrp

* Update tokens.md

change link to what-is-xrp

* Update use-payment-channels.md

* Update send-a-time-held-escrow.md

Update link to what-is-xml

* fix broken links

* Update parallel-networks.md

Change link to what-is-xml

* Update parallel-networks.ja.md

* Update invariant-checking.md

Remove link to xrp.html

* Update invariant-checking.ja.md

Remove link to xrp.html

* Update transaction-cost.md

Change link to what-is-xrp

* Update transaction-cost.ja.md

Change link to what-is-xrp

* Update send-a-conditionally-held-escrow.md

Change link to what-is-xrp

* Update stablecoin-issuer.md

Change link to what-is-xrp

* Update tokens.ja.md

Change link to what-is-xml

* Update autobridging.ja.md

Change link to what-is-xrp

* Update currency-formats.md

update text

* reorganize infrastructure nav section

* Update currency-formats.md

Try removing link altogether.

* Update currency-formats.ja.md

Remove link to what-is-xrp.html

* move commandline usage topic to infrastructure

* initial intro rewrite

* minor update to language

* IA.v3: rm Production Readiness

* Delete xrp.md

* Update xrp link in snippet

* Add redirect for old xrp.html URL

* Small edits to 'What is XRP?' article

* Add missing imgs

* XRP - copy edit per @DennisDawson

* restructure tutorials nav and pages

* fix broken links

* more broken link fixes

* Algo trading: 1st draft

* Algo trading: notes on taxes

* Algo trading: edits per review

* algo trading: fix broken link

* Ledger structure: rewrite for accuracy and clarity

* Update links to removed 'tree format' header

* Ledger Structure: Update diagrams

* Re-gen CSS for ledger structure changes

* Ledger structure: edits per review

* IA.v3: fix broken NFT links introduced by rebase

* Desktop Wallet (py): update little stuff

* Update some capacity/storage details

* contribute doc nav update

* fix image link in create diagram page

* IAv3: Fix 'Ledgers' blurb

* Update full history requirements with details from community members

* add reviewer suggestions

* Edits per @trippled review

* Apply suggestions from peer review

Co-authored-by: oeggert <117319296+oeggert@users.noreply.github.com>

* FH: reword file size limit note per review

* Update software ecosystem

* updates per review

* Minor tweaks to graphics

* fixTypos

* Update content/concepts/introduction/software-ecosystem.md

Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com>

* Update content/concepts/introduction/software-ecosystem.md

Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com>

* [JA] update AccountDelete cost

* custom transactors doc

* add doc to dactyl config

* [JA] fix NonFungibleTokensV1_1 amendment status

* [JA] update NFTokenOffer page

* Remove old, unused XRP article (#2039)

* add reviewer suggestions

* Add tooling to check for file/nav consistency

- From the repo top, run tool/check_file_consistency.py to look for
  Markdown files that exist in the "content/" directory but aren't used
  in the documentation.
- New "enforce_filenames" filter prints a warning to console when
  building, if a file's path and filename don't match expectations
  based on its place in the nav and top heading.

* File consistency checker: correctly handle filenames starting in _

* Remove unused old 'get started' and associated code

* Create Resources section & reorg some files

- Rename some files/folders based on their place in the nav
- Move a bunch of non-documentation stuff, and docs on contributing code
  and/or docs to the new "Resources" section.
- Known issue: nav spills into a second row on page widths between
  993px-1110px. To be fixed in a later CSS update, maybe along with
  making the Resources dropdown multi-column.

* Fix #2078 code tab bug

CSS not built yet, to reduce merge conflicts. Won't have any effect
until that happens.

* fix Transaction JSON

* [JA] translate contributing contents

* fix contributing-to-documentation parent

* fix contribute-code blurb

* Top nav: add cols for Resources, fix broken links

* CSS: fix top nav overflows

* Fix broken link from redirect not in JA target

* Top nav: add Infra to article types

* Update contrib info & rename intro file

* [ja] Update link to suggested first page to translate

* [ja] fix contribute docs organization

* Run private network with docker tutorial (#2065)

* [NO-ISSUE] Run private network with docker tutorial

Adds a tutorial page in the Infrastructure section on how to run a private XRPL network with Docker.

Please let me know if you think this is a useful page to include for developers, whether the steps are clear or not, and if you have suggestions on what can be added to it.

* Add minor link fixes and Japanese target

* Apply suggestions from code review

Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com>

* Add link to ripple-docker-testnet setup scripts in See Also section

* Update repo URL

---------

Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com>

* add intro gfx (#2036)

* add intro gfx

* Move graphic up

* Update some graphics with their revised versions

* Add updated version of the custodial vs non-custodial graphic

---------

Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com>
Co-authored-by: Amarantha Kulkarni <akulkarni@ripple.com>

* Update to reflect current UNL publishers

* [ja] update contributing

Co-authored-by: tequ <git@tequ.dev>

* Incorporate feedback on "What is XRP" page. (#2099)

* Add trademark info for XRP

* Revert section to previous state

* Fix broken link (#2101)

---------

Co-authored-by: Oliver Eggert <oeggert@ripple.com>
Co-authored-by: ddawson <dennis.s.dawson@gmail.com>
Co-authored-by: Maria Shodunke <mshodunke@ripple.com>
Co-authored-by: tequ <git@tequ.dev>
Co-authored-by: oeggert <117319296+oeggert@users.noreply.github.com>
Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com>
Co-authored-by: develoQ <develoQ.jp@gmail.com>
Co-authored-by: Maria Shodunke <maria-robobug@users.noreply.github.com>
Co-authored-by: Amarantha Kulkarni <akulkarni@ripple.com>
This commit is contained in:
Rome Reginelli
2023-09-01 12:40:18 -07:00
committed by GitHub
parent 31a068e6ae
commit b51bcb4ea3
445 changed files with 9020 additions and 4411 deletions
Download Patch File Download Diff File Expand all files Collapse all files

154
content/infrastructure/clio/install-clio-on-ubuntu.md Normal file
View File

@@ -0,0 +1,154 @@
---
html: install-clio-on-ubuntu.html
parent: infrastructure.html
blurb: Install a precompiled Clio binary on Ubuntu Linux.
labels:
- Clio Server
---
# Install Clio on Ubuntu Linux
This page describes the recommended instructions for installing the latest stable version of Clio on **Ubuntu Linux 20.04 or higher** using the [`apt`](https://ubuntu.com/server/docs) utility.
These instructions install a binary that has been compiled by Ripple. For instructions on how to build Clio from source, see the [Clio source code repository](https://github.com/XRPLF/clio).
## Prerequisites
Before you install Clio, you must meet the following requirements.
- Ensure that your system meets the [system requirements](system-requirements.html).
**Note:** Clio has the same system requirements as the `rippled` server, except Clio needs less disk space to store the same amount of ledger history.
- You need compatible versions of CMake and Boost. Clio requires C++20 and Boost 1.75.0 or higher.
- Access to a Cassandra cluster that is running locally or remote. You can choose to install and configure a Cassandra cluster manually by following the [Cassandra installation instructions](https://cassandra.apache.org/doc/latest/cassandra/getting_started/installing.html), or run Cassandra on a Docker container using one of the following commands.
- If you choose to persist Clio data, run Cassandra in a Docker container and specify an empty directory to store Clio data:
docker run --rm -it --network=host --name cassandra -v $PWD/cassandra_data:/var/lib/
cassandra cassandra:4.0.4
- If you do not wish to persist Clio data, run the following command:
docker run --rm -it --network=host --name cassandra cassandra:4.0.4
- You need gRPC access to one or more `rippled` servers in P2P mode. The `rippled` servers can either be local or remote, but you must trust them. The most reliable way to do this is to [install `rippled` yourself](install-rippled.html).
## Installation Steps
1. Update repositories:
sudo apt -y update
**Tip:** If you have already installed an up-to-date version of `rippled` on the same machine, you can skip the following steps for adding Ripple's package repository and signing key, which are the same as in the `rippled` install process. Resume from step 5, "Fetch the Ripple repository."
2. Install utilities:
sudo apt -y install apt-transport-https ca-certificates wget gnupg
3. Add Ripple's package-signing GPG key to your list of trusted keys:
sudo mkdir /usr/local/share/keyrings/
wget -q -O - "https://repos.ripple.com/repos/api/gpg/key/public" | gpg --dearmor > ripple-key.gpg
sudo mv ripple-key.gpg /usr/local/share/keyrings
4. Check the fingerprint of the newly-added key:
gpg /usr/local/share/keyrings/ripple-key.gpg
The output should include an entry for Ripple such as the following:
gpg: WARNING: no command supplied. Trying to guess what you mean ...
pub rsa3072 2019-02-14 [SC] [expires: 2026-02-17]
C0010EC205B35A3310DC90DE395F97FFCCAFD9A2
uid TechOps Team at Ripple <techops+rippled@ripple.com>
sub rsa3072 2019-02-14 [E] [expires: 2026-02-17]
In particular, make sure that the fingerprint matches. (In the above example, the fingerprint is on the third line, starting with `C001`.)
4. Add the appropriate Ripple repository for your operating system version:
echo "deb [signed-by=/usr/local/share/keyrings/ripple-key.gpg] https://repos.ripple.com/repos/rippled-deb focal stable" | \
sudo tee -a /etc/apt/sources.list.d/ripple.list
The above example is appropriate for **Ubuntu 20.04 Focal Fossa**.
5. Fetch the Ripple repository.
sudo apt -y update
6. Install the Clio software package. There are two options:
- To run `rippled` on the same machine, install the `clio` package, which sets up both servers:
sudo apt -y install clio
- To run Clio on a separate machine from `rippled`, install the `clio-server` package, which sets up Clio only:
sudo apt -y install clio-server
7. If you are running `rippled` on a separate machine, modify your Clio config file to point to it. You can skip this step if you used the `clio` package to install both on the same machine.
1. Edit the Clio server's config file to modify the connection information for the `rippled` server. The package installs this file at `/opt/clio/etc/config.json`.
"etl_sources":
[
{
"ip":"127.0.0.1",
"ws_port":"6006",
"grpc_port":"50051"
}
]
This includes:
- The IP of `rippled` server.
- The port where `rippled` accepts unencrypted WebSocket connections.
- The port where `rippled` accepts gRPC requests.
**Note** You can use multiple `rippled` servers as a data source by add more entries to the `etl_sources` section. If you do, Clio load balances requests across all the servers in the list, and can keep up with the network as long as at least one of the `rippled` servers is synced.
The [example config file](https://github.com/XRPLF/clio/blob/develop/example-config.json) accesses the `rippled` server running on the local loopback network (127.0.0.1), with the WebSocket (WS) on port 6006 and gRPC on port 50051.
2. Update the `rippled` server's config file to allow the Clio server to connect to it. The package installs this file at `/etc/opt/ripple/rippled.cfg`.
* Open a port to accept unencrypted WebSocket connections.
[port_ws_public]
port = 6005
ip = 0.0.0.0
protocol = ws
* Open a port to handle gRPC requests and specify the IP(s) of Clio server(s) in the `secure_gateway` entry.
[port_grpc]
port = 50051
ip = 0.0.0.0
secure_gateway = 127.0.0.1
**Tip:** If you are not running Clio on the same machine as `rippled`, change the `secure_gateway` in the example stanza to use the IP address of the Clio server.
8. Enable and start the Clio systemd service.
sudo systemctl enable clio
9. Start the `rippled` and Clio servers.
sudo systemctl start rippled
sudo systemctl start clio
If you are starting with a fresh database, Clio needs to download the full ledger. This can take some time. If you are starting both servers for the first time, it can take even longer because Clio waits for `rippled` to sync before extracting ledgers.
## See Also
- **Concepts:**
- [The Clio Server](the-clio-server.html)

188
content/infrastructure/rippled/commandline-usage.ja.md Normal file
View File

@@ -0,0 +1,188 @@
---
html: commandline-usage.html
name: Commandline Usage
parent: infrastructure.html
blurb: rippledサーバーのコマンドライン使用オプションです。
curated_anchors:
- name: 使用できるモード
anchor: "#使用できるモード"
- name: デーモンモードのオプション
anchor: "#デーモンモードのオプション"
- name: スタンドアロンモードのオプション
anchor: "#スタンドアロンモードのオプション"
- name: クライアントモードのオプション
anchor: "#クライアントモードのオプション"
- name: 単体テスト
anchor: "#単体テスト"
labels:
- コアサーバー
---
# rippledコマンドライン使用リファレンス
`rippled`実行可能ファイルは、通常はXRP Ledgerを処理するデーモンとして実行されますが、他のモードでも実行できます。このページでは、コマンドラインから実行する場合に`rippled`に渡すことができるすべてのオプションを説明します。
## 使用できるモード
- **デーモンモード** - デフォルトです。XRP Ledgerに接続して、トランザクションを処理し、レジャーデータベースを構築します。
- **スタンドアロンモード** - `-a`または`--standalone`オプションを使用します。他のサーバーには接続できない以外は、デーモンモードと同様です。このモードは、トランザクション処理やその他の機能のテストに使用できます。
- **クライアントモード** - APIメソッドの名前を指定して、別の`rippled`サーバーにJSON-RPCクライアントとして接続し、その後終了します。実行可能ファイルがすでに別のプロセスで実行中である場合に、このモードを使用してサーバーのステータスとレジャーデータを確認できます。
- **その他の使用法** - 以下の各コマンドを実行すると、`rippled`実行可能ファイルが何らかの情報を出力し、その後終了します。
- **ヘルプ** - 使用法の説明を出力するには、`-h`または`--help`を使用します。
- **単体テスト** - 単体テストを実行し、結果の概要を出力するには、`-u`または`--unittest`を使用します。rippledが正しくコンパイルされていることを確認する場合に便利です。
- **バージョンステートメント** - `rippled`のバージョン番号を出力し、その後終了するには、`--version`を使用します。
## 汎用オプション
ほとんどのモードに適用されるオプションは、以下の通りです。
| オプション | 説明 |
|:----------------|:-----------------------------------------------------------|
| `--conf {FILE}` | デフォルトのロケーションで構成ファイルを検索する代わりに、構成ファイルとして`{FILE}`を使用します。指定されていない場合、`rippled`は最初にローカル作業ディレクトリで`rippled.cfg`ファイルがあるかどうかを調べます。Linuxでは、このファイルが見つからない場合`rippled`は次に`$XDG_CONFIG_HOME/ripple/ripple.cfg`を確認します。（一般的に`$XDG_CONFIG_HOME`の場所は`$HOME/.config`です。） |
### 詳細レベルのオプション
次の汎用オプションは、標準出力とログファイルに書き込まれる情報の量を制御します。
| オプション | 短縮形 | 説明 |
|:------------|:--------------|:-----------------------------------------------|
| `--debug` | | **廃止予定** トレースレベルのデバッグを有効にします（`--verbose`のエイリアス）。代わりに[log_levelメソッド][]を使用してください。 |
| `--silent` | | 起動中にログを標準出力と標準エラー出力に書き込みません。冗長なログを削減するために`rippled`をsystemdユニットとして開始する場合に推奨されます。 |
| `--verbose` | `-v` | **廃止予定** トレースレベルデバッグを有効にします。代わりに[log_levelメソッド][]を使用してください。 |
## デーモンモードのオプション
```bash
rippled [OPTIONS]
```
デーモンモードは、`rippled`のデフォルトの運用モードです。[汎用オプション](#汎用オプション)の他に、以下のいずれかのオプションを指定できます。
| オプション | 説明 |
|:--------------------|:-------------------------------------------------------|
| `--fg` | デーモンをフォアグラウンドでシングルプロセスとして実行します。このオプションを指定しない場合、`rippled`は1番目のプロセスがモニターとして実行されている間に、デーモンの2番目のプロセスをフォークします。 |
| `--import` | 完全に起動する前に、別の`rippled`サーバーのレジャーストアーからレジャーデータをインポートしてください。構成ファイルに有効な`[import_db]`スタンザが指定されている必要があります。 |
| `--net` | **廃止予定** デバッグのためのオプションです。ネットワークからレジャーを取得できるようになるまで、ローカルレジャーを作成しません。 |
| `--nodetoshard` | 完全に起動する前に、すべての完全な[履歴シャード](history-sharding.html)をレジャーストアーからシャードストアーにコピーしてください（シャードストアーに設定されている最大ディスク容量まで）。CPUとI/Oを大量に使用します。注意: このコマンドは、データを（移動するのではなく）コピーするため、シャードストアーとレジャーストアーの両方にデータを保存するのに十分なディスク容量が必要です。 <!--{# Task for writing a tutorial to use this: DOC-1639 #}--> |
| `--quorum {QUORUM}` | これは[テストネットワーク](parallel-networks.html)のブートストラップ用のオプションです。検証のための最小定数をオーバーライドするには、`{QUORUM}`の信頼できるバリデータの同意を必要とします。デフォルトでは、検証のための定数は、信頼できるバリデータの実際の数に基づき、安全な数に自動的に設定されます。一部のバリデータがオンラインではない場合、このオプションにより、標準定数よりも少ない数のバリデータで続行できるようになります。**警告:** 定数を手動で設定すると、設定した値が小さすぎるためにサーバーがネットワークの他の部分から分岐することを防ぐことができない可能性があります。このオプションは、コンセンサスを十分に理解し、標準以外の設定を使用する必要がある場合にのみ使用してください。 |
次のフィールドは廃止されました： `--validateShards`。 [削除: rippled 1.7.0][]
## スタンドアロンモードのオプション
```bash
rippled --standalone [OPTIONS]
rippled -a [OPTIONS]
```
スタンドアロンモードで実行します。このモードでは、`rippled`はネットワークに接続しないか、またはコンセンサスを実行しません。（それ以外の場合、`rippled`はデーモンモードで実行されます。）
### 初期レジャーオプション
以下のオプションにより、起動時に最初に読み込むレジャーが判断されます。これらはのオプションは、履歴レジャーのリプレイまたはテストネットワークのブートストラップのためのものです。
| オプション | 説明 |
|:----------------------|:-----------------------------------------------------|
| `--ledger {LEDGER}` | `{LEDGER}`（レジャーハッシュまたはレジャーインデックス）により初期レジャーと識別されているレジャーバージョンを読み込みます。指定されたレジャーバージョンは、サーバーのレジャーストアーに格納される必要があります。 |
| `--ledgerfile {FILE}` | 指定された`{FILE}`からレジャーバージョンを読み込みます（このファイルには完全なレジャーがJSONフォーマットで格納されている必要があります）。このようなファイルの例については、付属の[`ledger-file.json`]({{target.github_forkurl}}/blob/{{target.github_branch}}/content/_api-examples/rippled-cli/ledger-file.json)を参照してください。 |
| `--load` | **廃止予定** デバッグのためのオプションです。ディスク上のレジャーストアーから初期レジャーを読み込むだけです。 |
| `--replay` | デバッグのためのオプションです。`--ledger`と組み合わせて使用し、レジャーの閉鎖をリプレイします。サーバーのレジャーストアーには、当該レジャーとその直前のバージョンのレジャーがすでに格納されている必要があります。サーバーでは、前のレジャーをベースとして使用して、指定されたレジャーのすべてのトランザクションが処理されます。その結果、指定されたレジャーが再作成されます。デバッガーを使用して、特定のトランザクションの処理ロジックを分析するためのブレークポイントを追加できます。 |
| `--start` | デバッグのためのオプションです。既知のすべてのAmendment（反対票を投じるようにサーバーに設定されているAmendmentを除く）が適用されている新しいジェネシスレジャーを使用して開始します。したがってこれらのAmendmentの機能は、2週間の[Amendmentプロセス](amendments.html)期間ではなく、2番目のレジャーの開始時から使用可能になります。 |
| `--valid` | **廃止予定** デバッグのためのオプションです。ネットワークとの完全同期の前であっても、初期レジャーを有効なネットワークレジャーと見なします。 |
## クライアントモードのオプション
```bash
rippled [OPTIONS] -- {COMMAND} {COMMAND_PARAMETERS}
```
クライアントモードでは、`rippled`実行可能ファイルが別の`rippled`サービスのクライアントとして動作します。（サービスは別のプロセスでローカルに実行されている同じ実行可能ファイルである場合や、別のサーバー上の`rippled`サーバーである場合があります。）
クライアントモードで実行するには、いずれかの[`rippled` API](http-websocket-apis.html)メソッドの[コマンドライン構文](request-formatting.html#コマンドライン形式)を指定します。
クライアントモードは、個別のコマンド構文の他に、[汎用オプション](#汎用オプション)と以下のオプションに対応します。
| オプション | 説明 |
|:------------------------|:---------------------------------------------------|
| `--rpc` | サーバーをクライアントモードで実行することを明示的に指定します。必須ではありません。 |
| `--rpc_ip {IP_ADDRESS}` | 指定されたIPアドレスの`rippled`サーバーに接続します。オプションでポート番号も指定します。 |
| `--rpc_port {PORT}` | **廃止予定** 指定されたポートで`rippled`サーバーに接続します。代わりに、`--rpc_ip`を使用してIPアドレスとともにポートを指定します。 |
**ヒント:** 一部の引数では、マイナスの値を指定できます。APIコマンドの引数がオプションとして解釈されないようにするには、コマンド名の前に`--`引数を渡します。
使用例（使用可能な最も古いレジャーバージョンから最新のレジャーバージョンまでのアカウントトランザクション履歴を取得）:
```bash
rippled -- account_tx r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59 -1 -1
```
## 単体テスト
```bash
rippled --unittest [OPTIONS]
rippled -u [OPTIONS]
```
単体テストでは、`rippled`ソースコードに組み込まれているテストを実行し、実行可能ファイルが予期されているとおりに動作することを確認します。単体テストの実行が完了すると、結果の概要が表示され、終了します。単体テストでは、組み込みのデータ型やトランザクション処理ルーチンなどの機能がカバーされます。
単体テストから失敗が報告される場合、一般的に次のいずれかの状況が発生しています。
- `rippled`のコンパイル時に問題が発生し、意図したとおりに機能していない
- `rippled`のソースコードにバグがある
- 単体テストにバグがあるか、単体テストが新しい動作に対応して更新されていない
単体テストの実行時には、[汎用オプション](#汎用オプション)と以下のいずれかのオプションを指定できます。
| オプション | 短縮形 | 説明 |
|:-----------------------------------|:--------------|:------------------------|
| `--unittest-ipv6` | | 単体テストの実行時に[IPv6](https://en.wikipedia.org/wiki/IPv6)を使用してローカルサーバーに接続します。このオプションが指定されていない場合、単体テストではIPv4が代わりに使用されます。[新規: rippled 1.1.0][] |
| `--unittest-jobs {NUMBER_OF_JOBS}` | | 指定された数のプロセスを使用して単体テストを実行します。これにより、マルチコアシステムの単体テストをより短時間で終了できます。`{NUMBER_OF_JOBS}`には、使用するプロセスの数を示すプラスの整数値を指定します。 |
| `--unittest-log` | | `--quiet`が指定されている場合でも、単体テストにてログへの書き込みができるようにします。（それ以外の影響はありません。） |
| `--quiet` | `-q` | 単体テストの実行時に出力される診断メッセージの数が減少します。 |
### 特定の単体テスト
```bash
rippled --unittest={TEST_OR_PACKAGE_NAME}
```
デフォルトでは、`rippled`は「手動」に分類されている単体テスト以外のすべての単体テストを実行します。テストの名前を指定してテストを個別に実行するか、またはパッケージ名を指定してテストのサブセットを実行することができます。
テストはパッケージの階層にまとめられます。パッケージは`.`文字で区切られ、テストケース名で終わります。
#### 単体テストの出力
```bash
rippled --unittest=print
```
`print`は、使用可能なテストとそのパッケージのリストを出力する特殊な単体テストです。
#### 手動単体テスト
完了に時間を要する一部の単体テストは、「手動」に分類されています。このようなテストについては、`print`単体テストの出力に`|M|`と表示されます。すべての単体テストまたは単体テストのパッケージを実行するときには、手動テストはデフォルトで実行されません。手動テストを個別に実行するには、テスト名を指定します。例:
```bash
$ ./rippled --unittest=ripple.tx.OversizeMeta
ripple.tx.OversizeMeta
Longest suite times:
60.9s ripple.tx.OversizeMeta
60.9s, 1 suite, 1 case, 9016 tests total, 0 failures
```
#### 単体テストの引数の指定
特定の手動単体テストでは引数を指定できます。以下のオプションを使用して引数を指定します。
| オプション | 説明 |
|:------------------------|:---------------------------------------------------|
| `--unittest-arg {ARG}` | 実行される単体テストに引数`{ARG}`を指定します。引数を受け入れる単体テストはそれぞれ、固有の引数形式を定義しています。 |
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

189
content/infrastructure/rippled/commandline-usage.md Normal file
View File

@@ -0,0 +1,189 @@
---
html: commandline-usage.html
name: Commandline Usage
parent: infrastructure.html
blurb: Commandline usage options for the rippled server.
curated_anchors:
- name: Available Modes
anchor: "#available-modes"
- name: Daemon Mode Options
anchor: "#daemon-mode-options"
- name: Stand-Alone Mode Options
anchor: "#stand-alone-mode-options"
- name: Client Mode Options
anchor: "#client-mode-options"
- name: Unit Tests
anchor: "#unit-tests"
labels:
- Core Server
---
# Commandline Usage
The `rippled` executable usually runs as a daemon that powers the XRP Ledger, although it can also run in other modes. This page describes all the options you can pass to `rippled` when running it from the command line.
## Available Modes
- **Daemon Mode** - The default. Connect to the XRP Ledger to process transactions and build a ledger database.
- **Stand-Alone Mode** - Use the `-a` or `--standalone` option. Like daemon mode, except it does not connect to other servers. You can use this mode to test transaction processing or other features.
- **Client Mode** - Specify an API method name to connect to another `rippled` server as a JSON-RPC client, then exit. You can use this to look up server status and ledger data if the executable is already running in another process.
- **Other Usage** - Each of the following commands causes the `rippled` executable to print some information, then exit:
- **Help** - Use `-h` or `--help` to print a usage statement.
- **Unit Tests** - Use `-u` or `--unittest` to run unit tests and print a summary of results. This can be helpful to confirm that you have compiled `rippled` successfully.
- **Version statement** - Use `--version` to have `rippled` print its version number, then exit.
## Generic Options
These options apply to most modes:
| Option | Description |
|:----------------|:-----------------------------------------------------------|
| `--conf {FILE}` | Use `{FILE}` as the config file instead of looking for config files in the default locations. If not specified, `rippled` first checks the local working directory for a `rippled.cfg` file. On Linux, if that file is not found, `rippled` next checks for `$XDG_CONFIG_HOME/ripple/ripple.cfg`. (Typically, `$XDG_CONFIG_HOME` maps to `$HOME/.config`.) |
### Verbosity Options
The following generic options affect the amount of information written to standard output and log files:
| Option | Short Version | Description |
|:------------|:--------------|:-----------------------------------------------|
| `--debug` | | **DEPRECATED** Enables trace-level debugging (alias for `--verbose`). Use the [log_level method][] instead. |
| `--silent` | | Don't write logs to standard out and standard error during startup. Recommended when starting `rippled` as a systemd unit to reduce redundant logging. |
| `--verbose` | `-v` | **DEPRECATED** Enables trace-level debugging. Use the [log_level method][] instead. |
## Daemon Mode Options
```bash
rippled [OPTIONS]
```
Daemon mode is the default mode of operation for `rippled`. In addition to the [Generic Options](#generic-options), you can provide any of the following:
| Option | Description |
|:--------------------|:-------------------------------------------------------|
| `--fg` | Run the daemon as a single process in the foreground. Otherwise, `rippled` forks a second process for the daemon while the first process runs as a monitor. |
| `--import` | Before fully starting, import ledger data from another `rippled` server's ledger store. Requires a valid `[import_db]` stanza in the config file. |
| `--newnodeid` | Generate a random node identity for the server. |
| `--nodeid {VALUE}` | Specify a node identity. `{VALUE}` can also be a parameter associated with the container or hardware running the server, such as `$HOSTNAME`. |
| `--nodetoshard` | Before fully starting, copy any complete [history shards](history-sharding.html) from the ledger store into the shard store, up to the shard store's configured maximum disk space. Uses large amounts of CPU and I/O. Caution: this command copies data (instead of moving it), so you must have enough disk space to store the data in both the shard store and the ledger store. <!--{# Task for writing a tutorial to use this: DOC-1639 #}--> |
| `--quorum {QUORUM}` | This option is intended for starting [test networks](parallel-networks.html). Override the minimum quorum for validation by requiring an agreement of `{QUORUM}` trusted validators. By default, the quorum for validation is automatically set to a safe number of trusted validators based on how many there are. If some validators are not online, this option can allow progress with a lower than normal quorum. **Warning:** If you set the quorum manually, it may be too low to prevent your server from diverging from the rest of the network. Only use this option if you have a deep understanding of consensus and have a need to use a non-standard configuration. |
The following option has been removed: `--validateShards`. [Removed in: rippled 1.7.0][]
## Stand-Alone Mode Options
```bash
rippled --standalone [OPTIONS]
rippled -a [OPTIONS]
```
Run in [stand-alone mode](rippled-server-modes.html). In this mode, `rippled` does not connect to the network or perform consensus. (Otherwise, `rippled` runs in daemon mode.)
## Initial Ledger Options
The following options determine which ledger to load first when starting up. These options are intended for debugging and for starting networks. These options work with both stand-alone mode and network mode. By default, the server loads its initial ledger using a combination of saved local data and data downloaded from the peer-to-peer network based on what ledger has been most recently validated by the network.
| Option | Description |
|:----------------------|:-----------------------------------------------------|
| `--ledger {LEDGER}` | Load the ledger version identified by `{LEDGER}` (either a ledger hash or a ledger index) as the initial ledger. The specified ledger version must be in the server's ledger store. |
| `--ledgerfile {FILE}` | Load the ledger version from the specified `{FILE}`, which must contain a complete ledger in JSON format. For an example of such a file, see the provided [`ledger-file.json`]({{target.github_forkurl}}/blob/{{target.github_branch}}/content/_api-examples/rippled-cli/ledger-file.json). |
| `--load` | Use only the ledger store on disk when loading the initial ledger. |
| `--net` | Use only data from the network when loading the initial ledger. |
| `--replay` | Use with `--ledger` to replay a specific ledger. Your server must have the ledger in question and its direct ancestor already in the ledger store. Using the previous ledger as a base, the server processes all the transactions in the specified ledger, resulting in a re-creation of the specified ledger. With a debugger, you can add breakpoints to analyze specific transaction processing logic. |
| `--start` | Start with a new genesis ledger that has known amendments enabled, based on their default votes. This makes the functionality of those amendments available right away, instead of needing to wait two weeks for the [Amendment Process](amendments.html). See also: [Start a New Genesis Ledger in Stand-Alone Mode](start-a-new-genesis-ledger-in-stand-alone-mode.html). |
| `--valid` | Consider the initial ledger a valid network ledger even before fully syncing with the network. This can be used for starting networks or rolling back an entire network to a known previous state, as long as 80% of that network's validators load the same ledger at around the same time. |
## Client Mode Options
```bash
rippled [OPTIONS] -- {COMMAND} {COMMAND_PARAMETERS}
```
In client mode, the `rippled` executable acts as a client to another `rippled` service. (The service may be the same executable running in a separate process locally, or it could be a `rippled` server on another server.)
To run in client mode, provide the [commandline syntax](request-formatting.html#commandline-format) for one of the [`rippled` API](http-websocket-apis.html) methods.
Besides the individual commands, client mode accepts the [Generic Options](#generic-options) and the following options:
| Option | Description |
|:------------------------|:---------------------------------------------------|
| `--rpc` | Explicitly specify that the server should run in client mode. Not required. |
| `--rpc_ip {IP_ADDRESS}` | Connect to the `rippled` server at the specified IP Address, optionally including a port number. |
| `--rpc_port {PORT}` | **DEPRECATED** Connect to the `rippled` server on the specified port. Specify the port alongside the IP address using `--rpc_ip` instead. |
**Tip:** Some arguments accept negative numbers as values. To ensure that arguments to API commands are not interpreted as options instead, pass the `--` argument before the command name.
Example usage (get account transaction history from the earliest available to latest available ledger versions):
```bash
rippled -- account_tx r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59 -1 -1
```
## Unit Tests
```bash
rippled --unittest [OPTIONS]
rippled -u [OPTIONS]
```
Unit testing runs tests built into the `rippled` source code to confirm that the executable performs as expected. After running unit tests, the process displays a summary of results and exits. Unit tests cover functionality such as built-in data types and transaction processing routines.
If unit testing reports a failure, that generally indicates one of the following:
- A problem occurred when compiling `rippled` and it is not functioning as intended
- The source code for `rippled` contains a bug
- A unit test has a bug or has not been updated to account for new behavior
While running unit tests, you can specify the [Generic Options](#generic-options) and any of the following options:
| Option | Short Version | Description |
|:-----------------------------------|:--------------|:------------------------|
| `--unittest-ipv6` | | Use [IPv6](https://en.wikipedia.org/wiki/IPv6) to connect to the local server when running unit tests. If not provided, unit tests use IPv4 instead. [New in: rippled 1.1.0][] |
| `--unittest-jobs {NUMBER_OF_JOBS}` | | Use the specified number of processes to run unit tests. This can finish running tests faster on multi-core systems. The `{NUMBER_OF_JOBS}` should be a positive integer indicating the number of processes to use. |
| `--unittest-log` | | Allow unit tests to write to logs even if `--quiet` is specified. (No effect otherwise.) |
| `--quiet` | `-q` | Print fewer diagnostic messages when running unit tests. |
### Specific Unit Tests
```bash
rippled --unittest={TEST_OR_PACKAGE_NAME}
```
By default, `rippled` runs all unit tests except ones that are classified as "manual". You can run an individual test by specifying its name, or run a subset of tests by specifying a package name.
Tests are grouped into a hierarchy of packages separated by `.` characters and ending in the test case name.
#### Printing Unit Tests
```bash
rippled --unittest=print
```
The `print` unit test is a special case that prints a list of available tests with their packages.
#### Manual Unit Tests
Certain unit tests are classified as "manual" because they take a long time to complete. These tests are marked with `|M|` in the output of the `print` unit test. Manual tests do not run by default when you run all unit tests or a package of unit tests. You can run manual tests individually by specifying the name of the test. For example:
```bash
$ ./rippled --unittest=ripple.tx.OversizeMeta
ripple.tx.OversizeMeta
Longest suite times:
60.9s ripple.tx.OversizeMeta
60.9s, 1 suite, 1 case, 9016 tests total, 0 failures
```
#### Providing Arguments to Unit Tests
Certain manual unit tests accept an argument. You can provide the argument with the following option:
| Option | Description |
|:------------------------|:---------------------------------------------------|
| `--unittest-arg {ARG}` | Provide the argument `{ARG}` to the unit test(s) currently being run. Each unit test that accepts arguments defines its own argument format. |
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

106
content/infrastructure/rippled/configuration/configure-advisory-deletion.ja.md Normal file
View File

@@ -0,0 +1,106 @@
---
html: configure-advisory-deletion.html
parent: data-retention.html
blurb: 指示による削除を使用して、新しい履歴ができたときではなく、スケジュールで古いレジャー履歴を削除します。
labels:
- コアサーバー
- データ保持
---
# 指示による削除の設定
デフォルトの構成ファイルは、新しいレジャーバージョンが利用可能になると`rippled`が古いXRP Ledgerの履歴を自動的に削除するように設定されています。サーバーがピーク時にハードウェアリソースの大部分を使用する場合は、オフピーク時に実行するようスケジュールされたコマンドからの指示があった場合にのみ、レジャーを削除するようにサーバーを設定できます。これにより、オンライン削除がサーバーのパフォーマンスに及ぼす影響はほとんどなくなります。
## 前提条件
このチュートリアルでは、ご使用のサーバーが以下の条件を満たしていることを前提としています。
- サポートされているオペレーティングシステムを使用している。Ubuntu Linux、Red Hat Enterprise Linux（RHEL）、CentOS
- `rippled`サーバーがすでに[インストール](install-rippled.html)されており、[オンライン削除](online-deletion.html)が有効になっている。
デフォルトの構成ファイルは、レジャーバージョンが2000個を超えるとオンライン削除を実行するよう設定されています。
- `cron`デーモンがインストールされており、実行されている。
Ubuntu Linuxではデフォルトで`cron`デーモンが実行されます。
RHELまたはCentOSでは、以下の`cronie`パッケージをインストールできます。
$ sudo yum install cronie
- 選択した量の履歴をレジャーストアーに保管するのに十分なディスク容量がサーバーにある。
各種設定で必要なストレージの容量についての詳細は、[容量計画](capacity-planning.html)を参照してください。指示による削除が有効な場合、削除が実行されるまでにサーバーに蓄積可能な履歴の最大数は、`online_delete`設定で設定したレジャーバージョン数と、オンライン削除の指示の間隔を**加算**したものに相当します。
- サーバーの使用率が最も低い時間帯を把握している。
## 設定手順
日次スケジュールで指示による削除は以下の手順で設定します。
1. `rippled`の構成ファイルの`[node_db]`スタンザで`advisory_delete`を有効にします。
[node_db]
# Other settings unchanged ...
online_delete=2000
advisory_delete=1
- 指示された場合にのみオンライン削除を実行するには、`advisory_delete`を`1`に設定します。（`0`に設定すると、新しいレジャーバージョンが使用可能になると自動的にオンライン削除が実行されます。）
- `online_delete`を、オンライン削除の実行後に維持するレジャーバージョンの最小数に設定します。オンライン削除が実行されるまでに蓄積される履歴は、この値よりも多くなります。
{% include '_snippets/conf-file-location.md' %}<!--_ -->
2. サーバーに対してオンライン削除を指示する[can_deleteメソッド][]の実行をテストします。
このコマンドの実行には[`rippled`コマンドラインインターフェイス](get-started-using-http-websocket-apis.html#コマンドライン)を使用できます。例:
$ rippled --conf=/etc/opt/ripple/rippled.cfg can_delete now
応答は、サーバーがそのレジャーストアーから削除するレジャーインデックスの最大値を示します。たとえば、以下のメッセージはレジャーインデックス43633667以下のレジャーバージョンを削除できることを示します。
{
"result": {
"can_delete": 43633667,
"status": "success"
}
}
サーバー内の _新しい_ 検証済みレジャーバージョンの数が、`online_delete`の設定以上となった場合にのみ、レジャーバージョンが削除されます。
3. 前のステップでテストした`can_delete`メソッドを、予定した時刻に実行するように`cron`デーモンを設定します。
`cron` 設定を編集します。
$ crontab -e
以下の例では、サーバー時刻で毎日1:05 AMにサーバーが削除を実行するように設定されています。
5 1 * * * rippled --conf /etc/opt/ripple/rippled.cfg can_delete now
サーバーで設定されているタイムゾーンに基づいてコマンドが実行されるようにスケジュールしてください。
**ヒント:**`advisory_delete`を無効にしている場合は、`cron`ジョブをオンラインで実行するようにスケジュールする必要はありません。この場合、サーバーの最も古いレジャーバージョンと現行の検証済みレジャーバージョンの差が`online_delete`の値以上である場合に、`rippled`によりオンライン削除が実行されます。
4. `rippled`サービスを起動（または再起動）します。
$ sudo systemctl restart rippled
5. [server_infoメソッド][]を使用してサーバーの`complete_ledgers`範囲を定期的に調べ、レジャーがスケジュール通りに削除されていることを確認します。
オンライン削除の実行後には`complete_ledgers`の最小レジャーインデックスが増加します。
サーバーの使用率の状況と、一度に削除する履歴の量によっては、削除が完了するまでに数分間かかることがあります。
## トラブルシューティング
オンライン削除の設定後にオンライン削除が実行されていないようである場合は、以下を試してください。
- `cron`ジョブを設定したユーザーに、コマンドラインクライアントとして`rippled`サーバーを実行できる権限があることを確認します。
- cronジョブの構文とこのジョブの実行予定時刻を確認します。
- `rippled`実行可能ファイルが`cron`設定で指定したパスで使用可能であることを確認します。必要に応じて実行可能ファイルの絶対パス（`/opt/ripple/bin/rippled`など）を指定します。
- `rippled`ログで、`SHAMapStore::WRN`で始まるメッセージを調べます。このメッセージが出力されている場合、サーバーがネットワークと同期していない状態になったために[オンライン削除が中断されている](online-deletion.html#オンライン削除の中断)可能性があります。
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

121
content/infrastructure/rippled/configuration/configure-advisory-deletion.md Normal file
View File

@@ -0,0 +1,121 @@
---
html: configure-advisory-deletion.html
parent: data-retention.html
blurb: Use advisory deletion to delete older ledger history on a schedule rather than as new history becomes available.
labels:
- Core Server
- Data Retention
---
# Configure Advisory Deletion
The default config file sets [`rippled`](xrpl-servers.html) to automatically delete outdated [history](ledger-history.html) of XRP Ledger state and transactions as new ledger versions become available. If your server uses most of its hardware resources during peak hours, you can configure the server to delete ledgers only when prompted by a command scheduled to run during off-peak hours, so that online deletion is less likely to impact [server performance](capacity-planning.html).
## Prerequisites
This tutorial assumes your server meets the following prerequisites:
- You are on a supported operating system: Ubuntu Linux, Red Hat Enterprise Linux (RHEL), or CentOS.
- The `rippled` server is already [installed](install-rippled.html) and [online deletion](online-deletion.html) is enabled.
The default config file enables online deletion after 2000 ledger versions.
- A `cron` daemon is installed and running.
Ubuntu Linux runs a `cron` daemon by default.
On RHEL or CentOS, you can install the `cronie` package:
$ sudo yum install cronie
- Your server has enough disk space to store your chosen amount of history in its ledger store.
See [Capacity Planning](capacity-planning.html) for details of how much storage is required for different configurations. With advisory deletion enabled, the maximum history a server may accumulate before deletion is equal to the number of ledger versions configured in the `online_delete` setting **plus** the amount of time between online deletion prompts.
- You know which hours are least busy for your server.
## Configuration Steps
To configure advisory deletion with a daily schedule, perform the following steps:
1. Enable `advisory_delete` in the `[node_db]` stanza of your `rippled`'s config file.
[node_db]
# Other settings unchanged ...
online_delete=2000
advisory_delete=1
- Set `advisory_delete` to `1` to run online deletion only when prompted. (Set it to `0` to run online deletion automatically as new ledger versions become available.)
- Set `online_delete` to the minimum number of ledger versions to keep after running online deletion. The server accumulates more history than this until online deletion runs.
{% include '_snippets/conf-file-location.md' %}<!--_ -->
2. Test running the [can_delete method][] to prompt the server to run online deletion.
You can use the [`rippled` commandline interface](get-started-using-http-websocket-apis.html#commandline) to run this command. For example:
$ rippled --conf=/etc/opt/ripple/rippled.cfg can_delete now
The response indicates the maximum ledger index that the server may delete from its ledger store. For example, the following message indicates that ledger versions up to and including ledger index 43633667 can be deleted:
{
"result": {
"can_delete": 43633667,
"status": "success"
}
}
The server only deletes those ledger versions if the number of _newer_ validated ledger versions it has is equal to or greater than the `online_delete` setting.
3. Configure your `cron` daemon to run the `can_delete` method you tested in the previous step at a scheduled time.
Edit your `cron` configuration:
$ crontab -e
The following example sets the server to run deletion at 1:05 AM server time daily:
5 1 * * * rippled --conf /etc/opt/ripple/rippled.cfg can_delete now
Be sure that you schedule the command to run based on your server's configured time zone.
**Tip:** You do not need to schedule a `cron` job to run online deletion if you have `advisory_delete` disabled. In that case, `rippled` runs online deletion automatically when the difference between the server's oldest and current validated ledger versions is at least the value of `online_delete`.
4. Start (or restart) the `rippled` service.
$ sudo systemctl restart rippled
5. Periodically check your server's `complete_ledgers` range using the [server_info method][] to confirm that ledgers are being deleted as scheduled.
The lowest ledger index in `complete_ledgers` should increase after online deletion.
Deletion may take several minutes to complete when it runs, depending on how busy your server is and how much history you delete at a time.
## Troubleshooting
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 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.
## See Also
- **Concepts:**
- [Ledger History](ledger-history.html)
- [Online Deletion](online-deletion.html)
- **Tutorials:**
- [Configure Online Deletion](configure-online-deletion.html)
- [Diagnosing Problems with rippled](diagnosing-problems.html)
- [Understanding Log Messages](understanding-log-messages.html)
- **References:**
- [server_info method][]
- [can_delete method][]
- [logrotate method][]
- [Ledger Data Formats](ledger-data-formats.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

74
content/infrastructure/rippled/configuration/configure-amendment-voting.ja.md Normal file
View File

@@ -0,0 +1,74 @@
---
html: configure-amendment-voting.html
parent: configure-rippled.html
blurb: プロトコル修正に伴うサーバーの投票を設定する。
labels:
- コアサーバー
- ブロックチェーン
---
# 修正投票機能の設定
バリデーターとして設定されたサーバーは、[feature method][]を使ってXRP Ledgerプロトコルの[修正案(amendments)](amendments.html)に投票することができます。(この方法には[管理者アクセス](get-started-using-http-websocket-apis.html#管理者アクセス権限)が必要です).
例えば、「SHAMapV2」Amendmentに反対票を投じるには、以下のコマンドを実行します。
<!-- MULTICODE_BLOCK_START -->
*WebSocket*
```json
{
"id": "any_id_here",
"command": "feature",
"feature": "SHAMapV2",
"vetoed": true
}
```
*JSON-RPC*
```json
{
"method": "feature",
"params": [
{
"feature": "SHAMapV2",
"vetoed": true
}
]
}
```
*コマンドライン*
```sh
rippled feature SHAMapV2 reject
```
<!-- MULTICODE_BLOCK_END -->
**注記:** Amendmentの省略名は大文字と小文字が区別されます。また、AmendmentのIDを16進数で指定することもできますが、この場合は大文字と小文字が区別されません。
## 設定ファイルを使用する
もし、修正票の設定に設定ファイルを使いたい場合は、`[rpc_startup]` 節に行を追加して、起動時に各明示票のために自動的にコマンドを実行させることができます。例えば
```
[rpc_startup]
{ "command": "feature", "feature": "SHAMapV2", "vetoed": true }
```
変更を有効にするには、必ずサーバーを再起動してください。
**注意事項:** `[rpc_startup]` 節にあるコマンドは、サーバが起動するたびに実行され、サーバが動作している間に構成された投票設定を上書きすることができます。
## 関連項目
- [Amendment](amendments.html)
- [既知のAmendment](known-amendments.html)
- [feature メソッド][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

74
content/infrastructure/rippled/configuration/configure-amendment-voting.md Normal file
View File

@@ -0,0 +1,74 @@
---
html: configure-amendment-voting.html
parent: configure-rippled.html
blurb: Set your server's votes on protocol amendments.
labels:
- Core Server
- Blockchain
---
# Configure Amendment Voting
Servers configured as validators can vote on [amendments](amendments.html) to the XRP Ledger protocol using the [feature method][]. (This method requires [admin access](get-started-using-http-websocket-apis.html#admin-access).)
For example, to vote against the "SHAMapV2" amendment, run the following command:
<!-- MULTICODE_BLOCK_START -->
*WebSocket*
```json
{
"id": "any_id_here",
"command": "feature",
"feature": "SHAMapV2",
"vetoed": true
}
```
*JSON-RPC*
```json
{
"method": "feature",
"params": [
{
"feature": "SHAMapV2",
"vetoed": true
}
]
}
```
*Commandline*
```sh
rippled feature SHAMapV2 reject
```
<!-- MULTICODE_BLOCK_END -->
**Note:** The short name of the amendment is case-sensitive. You can also use an amendment's ID as hexadecimal, which is not case sensitive.
## Using the Config File
If you prefer to use the config file to configure amendment voting, you can add a line to the `[rpc_startup]` stanza to run the command automatically on startup for each explicit vote. For example:
```
[rpc_startup]
{ "command": "feature", "feature": "SHAMapV2", "vetoed": true }
```
Be sure to restart your server for changes to take effect.
**Caution:** Any commands in the `[rpc_startup]` stanza run each time the server starts up, which can override voting settings you configured while the server was running.
## See Also
- [Amendments](amendments.html)
- [Known Amendments](known-amendments.html)
- [feature method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

100
content/infrastructure/rippled/configuration/configure-full-history.ja.md Normal file
View File

@@ -0,0 +1,100 @@
---
html: configure-full-history.html
parent: data-retention.html
blurb: 完全履歴サーバーは、運用のコストは高いものの、XRP Ledgerでこれまでに発生したすべてのトランザクションの記録を提供します。
labels:
- コアサーバー
- データ保持
---
# 全履歴の設定
デフォルトの構成では、新しいレジャーバージョンが利用可能になると`rippled`サーバーが古いXRP Ledger状態とトランザクションの履歴を自動的に削除するように設定されています。ほとんどのサーバーでは現在の状態を把握してトランザクションを処理するのに古い履歴は不要なため、この設定で十分です。ただし、一部のサーバーが可能な限り多くのXRP Ledgerの履歴を提供する場合、これはネットワークにとって有用であることがあります。
## 警告
全履歴の保存にはコストがかかります。2018年12月11日の時点では、XRP Ledgerの全履歴が専有するディスク容量は約**9テラバイト**にのぼります。適切なサーバーパフォーマンスのためには、全履歴を高速なソリッドステートディスクドライブに保存する必要があります。このような大量のソリッドステートストレージは安価ではなく、また保管する必要のある履歴の合計量は毎日約12 GBずつ増加します。
ピアツーピアネットワークから全履歴を取得するには非常に長い時間がかかり（数か月）、また古い履歴を取得し、かつレジャーの新たな進展を常に把握するには、システムリソースとネットワークリソースを十分に備えたサーバーが必要となります。レジャー履歴の取得を迅速に開始するため、すでに大量の履歴をダウンロードしている別のサーバーオペレーターを探すこともできます。このようなオペレーターは、データベースダンプを提供できるか、または少なくとも、履歴の取得に十分な時間、あなたのサーバーをオペレーターのサーバーに明示的にピア接続することができます。サーバーはファイルからレジャー履歴を読み込み、インポートする履歴レジャーの整合性を検証できます。
ネットワークへの参加、トランザクションの検証、またはネットワークの現在の状態の確認には、全履歴を記録するサーバーは必要ありません。全履歴が有用となるのは、過去に発生したトランザクションの結果や、過去の特定の時点におけるレジャーの状態を確認する場合だけです。このような情報を取得するには、必要とする履歴を保持している他のサーバーを利用する必要があります。
全履歴は保管せずにXRP Ledgerネットワークの履歴の保管に参加したい場合には、[履歴シャーディングを構成](configure-history-sharding.html)すれば、レジャー履歴のグループをランダムに選択して保管できます。
## 構成手順
サーバーが全履歴を取得して保管するように構成するには、以下の手順を実行します。
1. `rippled`サーバーが稼働中の場合は停止します。
$ sudo systemctl stop rippled
0. サーバーの構成ファイルで`[node_db]`スタンザの`online_delete`設定と`advisory_delete`設定を削除（またはコメントアウト）し、タイプをまだ`NuDB`に変更していない場合は変更します。
[node_db]
type=NuDB
path=/var/lib/rippled/db/nudb
#online_delete=2000
#advisory_delete=0
全履歴が記録されるサーバーでは、レジャーストアーにNuDBを使用します。これは、データベースがこれほど大きいと、RocksDBでは非常に大量のRAMが必要になるためです。詳細は、[容量の計画](capacity-planning.html)を参照してください。パフォーマンス関連の構成オプション`open_files`、`filter_bits`、`cache_mb`、`file_size_mb`、および`file_size_mult`は、RocksDBのみに適用されるオプションであるため、デフォルトの`[node_db]`スタンザから削除できます。
**注意:** RocksDBで履歴をすでにダウンロードしている場合は、NuDBへ切り替えるときに構成ファイルでデータベースのパスを変更するか、またはそのデータを削除する必要があります。`[node_db]`スタンザの`path`設定**および**`[database_path]`（SQLiteデータベース）設定の両方を変更する必要があります。このようにしないと、サーバーの[起動が失敗する](server-wont-start.html#状態dbエラー)可能性があります。
{% include '_snippets/conf-file-location.md' %}<!--_ -->
0. サーバーの構成ファイルで`[ledger_history]`スタンザを`full`に設定します。
[ledger_history]
full
0. 全履歴が保管されている1台以上のサーバーと明示的にピア接続するように、サーバーの構成ファイルで`[ips_fixed]`スタンザを設定します。
[ips_fixed]
169.55.164.20
50.22.123.215
サーバーのダイレクトピアの1つが使用可能な履歴データを保持している場合に限り、サーバーはピアツーピアネットワークから履歴データをダウンロードできます。全履歴をダウンロードする最も容易な方法は、すでに全履歴を保管しているサーバーとピア接続することです。
**ヒント:** Rippleは、すべての履歴が記録されるサーバーのプールを公開しています。これらのサーバーのIPアドレスを取得するには、ドメイン`s2.ripple.com`を数回解決します。これらのサーバーは公開サービスとして提供されているため、他のサーバーとのピア接続での可用性は限られており、またこれらのサーバーを悪用するとブロックされる可能性があることに注意してください。
0. 全履歴が記録されている別のサーバーからのデータベースダンプがあり、このダンプをベースとして利用できる場合は、サーバーの構成ファイルで`[import_db]`スタンザがインポート対象データを指し示すように設定します。（それ以外の場合はこのステップをスキップします。）
[import_db]
type=NuDB
path=/tmp/full_history_dump/
0. 以前に稼働していた`rippled`からの既存のデータベースファイルがサーバーにある場合は、そのデータベースファイルを削除します。
オンライン削除を無効にすると、サーバーはオンライン削除が有効であった間にダウンロードしたデータをすべて無視するため、ディスク容量を空けることができます。次に例を示します。
rm -r /var/lib/rippled/db/*
**警告:** フォルダーを削除する前に、保持したいファイルがそのフォルダーに含まれていないことを確認してください。通常は安全に`rippled`サーバーのデータベースファイルをすべて削除できますが、この操作は、設定されているデータベースフォルダーが`rippled`のデータベース以外には使用されていない場合にのみ行ってください。
0. `rippled`サーバーを起動し、インポート可能なデータベースダンプがある場合にはインポートします。
`[Import_db]`で構成されている読み取り対象データベースダンプがある場合は、`--import` [コマンドラインオプション](commandline-usage.html#デーモンモードのオプション)を指定してサーバーを明示的に起動します。
$ /opt/ripple/bin/rippled --conf /etc/opt/ripple/rippled.cfg --import
大量のデータベースダンプのインポートには数分から数時間かかることがあります。インポート中はサーバーは完全には起動せず、ネットワークと同期しません。インポートの状況を確認するには、サーバーログを参照してください。
データベースダンプをインポートしない場合は、サーバーを通常の方法で起動します。
$ sudo systemctl start rippled
0. `[import_db]`スタンザをサーバーの構成ファイルに追加した場合は、インポートの完了後にそのスタンザを削除してください。
このようにしないと、次回の再起動時にサーバーが同じデータを再びインポートしようとします。
0. [server_infoメソッド][]を使用して、サーバーの利用可能な履歴を監視します。
`complete_ledgers`フィールドに表示される利用可能なレジャーの範囲は、時間の経過とともに増加します。
本番環境のXRP Ledgerの履歴で最も古い利用可能なレジャーバージョンは、レジャーインデックス**32570**です。レジャー履歴の最初の約2週間分は、当時のサーバーのバグが原因で失われています。Test Netやその他のチェーンでは通常、履歴の最初のバージョンはレジャーインデックス**1**です。
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

117
content/infrastructure/rippled/configuration/configure-full-history.md Normal file
View File

@@ -0,0 +1,117 @@
---
html: configure-full-history.html
parent: data-retention.html
blurb: Full history servers provide a record of every transaction ever to occur in the XRP Ledger, although they are expensive to run.
labels:
- Core Server
- Data Retention
---
# Configure Full History
In its default configuration, the `rippled` server automatically deletes outdated history of XRP Ledger state and transactions as new ledger versions become available. This is enough for most servers, which do not need older history to know the current state and process transactions. However, it can be useful for the network if some servers provide as much history of the XRP Ledger as possible.
## Warnings
Storing full history is expensive. As of 2023-07-19, the full history of the XRP Ledger occupies approximately **26 terabytes** of disk space, which must be entirely stored on fast solid state disk drives for proper server performance. Such a large amount of solid state storage is not cheap, and the total amount of history you must store increases by approximately 12 GB per day.
Additionally, storing full history in NuDB requires single files that are larger than the 16 TB limit of ext4 filesystems, which is the default on many Linux distributions. You must use a filesystem with a larger single-file limit, such as XFS (recommended) or ZFS.
Acquiring full history from the peer-to-peer network takes a long time (several months) and requires that your server has enough system and network resources to acquire older history while keeping up with new ledger progress. To get a faster start on acquiring ledger history, you may want to find another server operator who has a large amount of history already downloaded, who can give you a database dump or at least allow your server to explicitly peer with theirs for a long time to acquire history. The server can load ledger history from a file and verify the integrity of the historical ledgers it imports.
You do not need a full history server to participate in the network, validate transactions, or know the current state of the network. Full history is only useful for knowing the outcome of transactions that occurred in the past, or the state of the ledger at a given time in the past. To get such information, you must rely on other servers having the history you need.
If you want to contribute to storing the history of the XRP Ledger network without storing the full history, you can [configure history sharding](configure-history-sharding.html) to store randomly-selected chunks of ledger history instead.
## Configuration Steps
To configure your server to acquire and store full history, complete the following steps:
1. Stop the `rippled` server if it is running.
$ sudo systemctl stop rippled
0. Remove (or comment out) the `online_delete` and `advisory_delete` settings from the `[node_db]` stanza of your server's config file, and change the type to `NuDB` if you haven't already:
[node_db]
type=NuDB
path=/var/lib/rippled/db/nudb
#online_delete=2000
#advisory_delete=0
On a full-history server, you should use NuDB for the ledger store, because RocksDB requires too much RAM when the database is that large. For more information, see [Capacity Planning](capacity-planning.html). You can remove the following performance-related configuration options from the default `[node_db]` stanza, because they only apply to RocksDB: `open_files`, `filter_bits`, `cache_mb`, `file_size_mb`, and `file_size_mult.`
**Caution:** If you have any history already downloaded with RocksDB, you must either delete that data or change the paths to the databases in the config file when you switch to NuDB. You must change both the `path` field of the `[node_db]` stanza **and** the `[database_path]` (SQLite database) setting. Otherwise, the server may [fail to start](server-wont-start.html#state-db-error).
{% include '_snippets/conf-file-location.md' %}<!--_ -->
0. Set the `[ledger_history]` stanza of your server's config file to `full`:
[ledger_history]
full
0. Set the `[ips_fixed]` stanza of your server's config file to explicitly peer with at least one server that has full history available.
[ips_fixed]
169.55.164.20 51235
50.22.123.215 51235
Your server can only download historical data from the peer-to-peer network if one its direct peers has the data available. The easiest way to ensure you can download full history is to peer with a server that already has full history.
**Tip:** Ripple makes a pool of full history servers publicly available. You can resolve the domain `s2.ripple.com` a few times to get the IP addresses of these servers. Ripple offers these servers as a public service, so be aware that their availability to peer with other servers is limited and you may be blocked if you abuse them.
0. If you have a database dump from another full-history server to use as a basis, set the `[import_db]` stanza of your server's config file to point to the data to be imported. (Otherwise, skip this step.)
[import_db]
type=NuDB
path=/tmp/full_history_dump/
0. Remove your server's existing database files, if you have any from previously running `rippled`.
After disabling online deletion, the server ignores any data that was downloaded while online deletion was enabled, so you may as well clear up the disk space. For example:
rm -r /var/lib/rippled/db/*
**Warning:** Be sure that you have not put any files you want to keep in the folder before you delete it. It is generally safe to delete all of a `rippled` server's database files, but you should only do this if the configured database folder is not used for anything other than `rippled`'s databases.
0. Start the `rippled` server, importing the database dump if you have one available:
If you have a database dump to load configured in `[import_db]`, start the server explicitly and include the `--import` [commandline option](commandline-usage.html#daemon-mode-options):
$ /opt/ripple/bin/rippled --conf /etc/opt/ripple/rippled.cfg --import
Importing a large database dump may take several minutes or even hours. During this time, the server is not fully started and synced with the network. Watch the server logs to see the status of the import.
If you are not importing a database dump, start the server normally:
$ sudo systemctl start rippled
0. If you added an `[import_db]` stanza to your server's config file, remove it after the import completes.
Otherwise, your server may try to import the same data again the next time it is restarted.
0. Monitor your server's available history with the [server_info method][].
The range of available ledgers reported in the `complete_ledgers` field should increase over time.
The earliest available ledger version in the production XRP Ledger's history is ledger index **32570**. The first two weeks or so of ledger history was lost due to a bug in the server at the time. [Test nets and other chains](parallel-networks.html) generally have history going back to ledger index **1**.
## See Also
- **Concepts:**
- [Ledger History](ledger-history.html)
- [rippled Server Modes](rippled-server-modes.html)
- **Tutorials:**
- [Capacity Planning](capacity-planning.html), particularly [Disk Space](capacity-planning.html#disk-space)
- [Configure Online Deletion](configure-online-deletion.html)
- [Diagnosing Problems with rippled](diagnosing-problems.html)
- [Understanding Log Messages](understanding-log-messages.html)
- **References:**
- [server_info method][]
- [can_delete method][]
- [Ledger Data Formats](ledger-data-formats.html)
- [rippled Commandline Usage Reference](commandline-usage.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

56
content/infrastructure/rippled/configuration/configure-grpc.md Normal file
View File

@@ -0,0 +1,56 @@
---
html: configure-grpc.html
parent: configure-rippled.html
blurb: Enable and configure the gRPC API.
labels:
- Core Server
---
# Configure gRPC
The `rippled` server has a limited [gRPC API](https://grpc.io/) which [P2P mode servers](rippled-server-modes.html) can provide. Reporting mode servers use this API to retrieve data about the latest validated ledgers and transactions. You can enable the gRPC API on your server with a new configuration stanza.
**Caution:** gRPC support is intended specifically for providing data to reporting mode servers from P2P mode servers. Breaking changes to the gRPC API may occur without warning or it may be removed entirely in future versions of the server.
## Prerequisites
To enable gRPC, you must meet the following prerequisites:
- You must have [installed rippled](install-rippled.html).
- Your server must be able to bind to the port you choose.
## Steps
To enable gRPC on your server, complete the following steps:
1. Ensure the `[port_grpc]` stanza is in your `rippled` config file.
[port_grpc]
port = 50051
ip = 127.0.0.1
- `port` 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. `127.0.0.1` limits connections to the local loopback network (same machine) and is enabled by default. Changing the value to `0.0.0.0` listens on all available network interfaces.
{% include '_snippets/conf-file-location.md' %}
2. Start (or restart) the `rippled` service.
sudo systemctl restart rippled
## See Also
- **Concepts:**
- [XRP Ledger Overview](xrp-ledger-overview.html)
- [`rippled` Server Modes](rippled-server-modes.html)
- **Tutorials:**
- [Get Started Using HTTP / WebSocket APIs](get-started-using-http-websocket-apis.html)
- [Reliable Transaction Submission](reliable-transaction-submission.html)
- [Manage the rippled Server](manage-the-rippled-server.html)
- **References:**
- [HTTP / WebSocket API Reference](http-websocket-apis.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

84
content/infrastructure/rippled/configuration/configure-history-sharding.ja.md Normal file
View File

@@ -0,0 +1,84 @@
---
html: configure-history-sharding.html
parent: data-retention.html
blurb: 履歴XRPレジャーデータのシャードを保存するようにサーバーを設定します。
labels:
- データ保持
- コアサーバー
---
# 履歴シャーディングの設定
[履歴シャーディング](history-sharding.html)では、各サーバーで完全な履歴を保管することなく、履歴XRP Ledgerデータを保存できます。デフォルトでは`rippled`サーバーは履歴シャードを保管しません。
**ヒント:** バリデータおよび`rippled`追跡（またはストック）サーバーの両方で履歴シャードを保管するように設定できます。ただし`rippled`バリデータサーバーの経費を抑えるために、バリデータサーバーでシャードを保管するように設定 _しない_ ことが推奨されます。バリデータを実行していて、XRP Ledger履歴を保管したい場合は、履歴シャーディングを有効にして別の`rippled`サーバーを実行することが推奨されます。
レジャー履歴のシャードを保管できるよう`rippled`を設定するには、以下の手順を実行します。
## 1. シャードストアーに割り当てる容量を決めます。
履歴シャードを保管できるように`rippled`サーバーを設定する前に、履歴シャードストアーに割り当てるディスク容量を決定する必要があります。これはまた、デフォルトのレジャーストアーに保持する履歴の量にも影響します。シャードストアーのサイズを設定する際には、以下の点を考慮してください。
- レジャーストアー（`[node_db]`スタンザにより定義される）は、履歴シャードストアーとは別のストアーです。レジャーストアーはすべてのサーバーに必要であり、そこには一定範囲の最近の履歴が保管されている必要があります。保管する範囲は、`online_delete`パラメーターに使用可能な状態で維持するレジャーの数によって定義されます。（デフォルトの設定では、最新のレジャー2000個が保管されます。）
- レジャーストアーに2<sup>15</sup>個以上のレジャー（32768）が保持されている場合は、レジャーストアーからシャードストアーへ最近の履歴のグループを効率的にインポートできます。
- 履歴シャードストアー（`[shard_db]`スタンザにより定義される）は、履歴シャードを保管する場合にのみ必要です。履歴シャードを保管しないサーバーではこの構成スタンザを省略する必要があります。履歴シャードストアーのサイズは`max_size_gb`パラメーターでギガバイト単位で定義されます。サーバーは完全なシャードを保管するため、この容量を最大限利用します。履歴シャードストアーは、 _必ず_ ソリッドステートディスクまたは同様の高速なメディアに保管します。従来の回転式ハードディスクでは不十分です。
- シャードには2<sup>14</sup>個のレジャー（16384）が含まれており、シャードの経過期間に応じて約200MB～4GBを専有します。古いシャードほどXRP Ledgerでのアクティビティが少ないため、サイズが小さくなります。
- 履歴シャードストアーとレジャーストアーはファイルパスを分けて保管する _必要があります_ 。必要に応じて、レジャーストアーと履歴ストアーをそれぞれ別のディスクやパーティションに配置するように設定できます。
- 完全なレジャー履歴をレジャーストアーと履歴シャードストアーの両方に保持できますが、冗長な処理となります。
- シャードの取得にかかる時間、`rippled`サーバーに必要なファイルハンドル数、およびメモリーキャッシュ使用率は、シャードのサイズの影響を直接受けます。
## 2. rippled.cfgの編集
`rippled.cfg`ファイルを編集し、`[shard_db]`スタンザを追加します。
{% include '_snippets/conf-file-location.md' %}<!--_ -->
以下のスニペットに、`[shard_db]`スタンザの例を示します。
```
[shard_db]
type=NuDB
path=/var/lib/rippled/db/shards/nudb
max_size_gb=50
```
`type`フィールドは省略できます。省略しない場合は、`NuDB`である _必要があります_ 。[新規: rippled 1.3.1][]
**注意:** `rippled`がシャードストアーパスで不適切なデータを検出すると、[起動できない](server-wont-start.html)可能性があります。シャードストアーには新しいフォルダーを使用する必要があります。以前にRocksDBシャードストアー（`rippled` 1.2.x以前）を使用していた場合は、別のパスを使用するか、RocksDBシャードデータを削除します。
詳細は、[rippled.cfgの設定例](https://github.com/ripple/rippled/blob/master/cfg/rippled-example.cfg)の`[shard_db]`の例を参照してください。
## 3. サーバーの再起動
```
systemctl restart rippled
```
## 4. シャードのダウンロードの待機
サーバーはネットワークと同期すると、履歴シャードのダウンロードを自動的に開始し、シャードストアーの空き容量を埋めます。ダウンロード対象のシャードを確認するには、シャードストアーを設定したフォルダー内に作成されるフォルダーを確認します。（これは`rippled.cfg`ファイルの`[shard_db]`スタンザの`path`フィールドによって定義されます。）
このフォルダーには、サーバーに保管されている各シャードのフォルダーが番号付きで保存されています。常に、最大で1つのフォルダーに、未完了であることを示す`control.txt`ファイルが保存されています。
[download_shardメソッド][]を使用して、サーバーにアーカイブファイルからシャードをダウンロードしてインポートするように指示できます。
サーバーとそのピアが使用できるシャードのリストを表示するには、[crawl_shardsメソッド][]か[ピアクローラー](peer-crawler.html)を使用します。
## 関連項目
- **コンセプト:**
- [レジャー履歴](ledger-history.html)
- [オンライン削除](online-deletion.html)
- **チュートリアル:**
- [オンライン削除の設定](configure-online-deletion.html)
- [ピアクローラーの設定](configure-the-peer-crawler.html)
- [容量の計画](capacity-planning.html)
- **リファレンス:**
- [download_shardメソッド][]
- [crawl_shardsメソッド][]
- [レジャーデータフォーマット](ledger-data-formats.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

91
content/infrastructure/rippled/configuration/configure-history-sharding.md Normal file
View File

@@ -0,0 +1,91 @@
---
html: configure-history-sharding.html
parent: data-retention.html
blurb: Set up a server to contribute to preserving shards of historical XRP Ledger data.
labels:
- Data Retention
- Core Server
---
# Configure History Sharding
[History Sharding](history-sharding.html) lets servers contribute to preserving historical XRP Ledger data without each server needing to store the full history. By default, `rippled` servers do not store history shards.
**Tip:** While both validator and tracking (or stock) `rippled` servers can be configured to store history shards, Ripple recommends _not_ configuring validator `rippled` servers to store shards, to reduce overhead on those servers. If you run a validator and want to contribute to storing XRP Ledger history, Ripple recommends you run a separate `rippled` server with history sharding enabled.
To configure your `rippled` to store shards of ledger history, complete the following steps:
## 1. Determine how many shards to maintain
Before you configure your `rippled` server to store history shards, you must decide how many history shards you want to keep, which is mostly determined by how much disk space is available for the shard store. This also affects how much history you keep in the default ledger store. You should consider the following when deciding what size to configure your shard store:
- The ledger store (defined by the `[node_db]` stanza) is separate from the history shard store. The ledger store is required for all servers, and always contains a range of recent history, defined by how many ledgers to keep available in the `online_delete` parameter. (The default configuration stores the most recent 2000 ledgers.)
- If you keep at least 2<sup>15</sup> ledgers (32768) in the ledger store, you can efficiently import chunks of recent history from the ledger store into the shard store.
- The history shard store (defined by the `[shard_db]` stanza) is only required for storing history shards. The configuration stanza should be omitted from servers that do not store history shards. The total number of shards stored is defined by the `max_historical_shards` parameter; the server attempts to store no more than this many complete shards. The history shard store _MUST_ be stored on a solid-state disk or similar fast media. Traditional spinning hard disks are insufficient.
- A shard consists of 2<sup>14</sup> ledgers (16384) and occupies approximately 200 MB to 4 GB based on the age of the shard. Older shards are smaller because there was less activity in the XRP Ledger at the time.
- The history shard store and the ledger store _MUST_ be stored at different file paths. You can configure the ledger store and history store to be on different disks or partitions if desired.
- It is possible but redundant to hold full ledger history in both the ledger store and the history shard store.
- The time to acquire a shard, number of file handles needed by the `rippled` server, and memory cache usage is directly affected by the size of the shard.
- You can specify additional paths to store older history shards by providing a `[historical_shard_paths]` stanza. These paths may be on different, slower disks because they hold data that is used less often. The most recent two shards (the ones with the largest ledger indexes) are always stored in the path specified in the `[shard_db]` stanza. [New in: rippled 1.7.0][]
## 2. Edit rippled.cfg
<!-- SPELLING_IGNORE: cfg -->
Edit your `rippled.cfg` file to add a `[shard_db]` stanza and optionally a `[historical_shard_paths]` stanza.
{% include '_snippets/conf-file-location.md' %}<!--_ -->
The following snippet shows an example of a `[shard_db]` stanza:
```
[shard_db]
path=/var/lib/rippled/db/shards/nudb
max_historical_shards=12
# Optional paths for shards other than the newest 2
[historical_shard_paths]
/mnt/disk1
/mnt/disk2
```
The `type` field of `[shard_db]` can be omitted. If present, it _MUST_ be `NuDB`. [New in: rippled 1.3.1][]
**Caution:** If `rippled` detects the wrong type of data in the shard store path, it may [fail to start](server-wont-start.html). You should use a new folder for the shard store. If you previously used a RocksDB shard store (`rippled` 1.2.x and lower), use a different path or delete the RocksDB shard data.
For more information, reference the `[shard_db]` example in the [rippled.cfg configuration example](https://github.com/ripple/rippled/blob/master/cfg/rippled-example.cfg).
## 3. Restart the server
```
systemctl restart rippled
```
## 4. Wait for shards to download
After your server syncs to the network, it automatically starts downloading history shards to fill the available space in the shard store. You can see which shards are being downloaded by looking at which folders are created in the folder where you configured your shard store. (This is defined by the `path` field of the `[shard_db]` stanza in the `rippled.cfg` file.)
This folder should contain a numbered folder for each shard your server has. At any given time, up to one folder may contain a `control.txt` file, indicating it is incomplete.
You can instruct your server to download and import a shard from an archive file using the [download_shard method][].
To list the shards your server and its peers have available, you can use the [crawl_shards method][] or the [Peer Crawler](peer-crawler.html).
## See Also
- **Concepts:**
- [Ledger History](ledger-history.html)
- [Online Deletion](online-deletion.html)
- **Tutorials:**
- [Configure Online Deletion](configure-online-deletion.html)
- [Configure the Peer Crawler](configure-the-peer-crawler.html)
- [Capacity Planning](capacity-planning.html)
- **References:**
- [download_shard method][]
- [crawl_shards method][]
- [Ledger Data Formats](ledger-data-formats.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

83
content/infrastructure/rippled/configuration/configure-online-deletion.ja.md Normal file
View File

@@ -0,0 +1,83 @@
---
html: configure-online-deletion.html
parent: data-retention.html
blurb: サーバーでどこまで古いトランザクション履歴を保持するかを設定します。
labels:
- データ保持
- コアサーバー
---
# オンライン削除の設定
`rippled`サーバーのデフォルトの構成では、最新2000個のレジャーバージョンよりも古い[履歴が削除され](online-deletion.html)、レジャー履歴は約15分間維持されます（現行のレジャー毎の間隔に基づく）。このページでは、削除までに`rippled`サーバーに保管される履歴の量を設定する方法を説明します。
## 前提条件
このチュートリアルでは、ご使用のサーバーが以下の条件を満たしていることを前提としています。
- サポートされているオペレーティングシステムを使用している。Ubuntu Linux、Red Hat Enterprise Linux（RHEL）、CentOS
- `rippled`サーバーがすでに[インストール](install-rippled.html)されており、[オンライン削除](online-deletion.html)が有効になっている。
推奨されるプラットフォームのインストール手順に従えば、オンライン削除はデフォルトで有効となります。
- 選択した量の履歴をレジャーストアーに保管するのに[十分なディスク容量](capacity-planning.html)がサーバーにある。
## 構成手順
サーバーに保管する履歴の量を変更するには、以下の手順を実行します。
1. 保管する履歴に相当するレジャーバージョンの数を決定します。
新しいレジャーバージョンは通常3～4秒間隔で検証されます。このため、レジャーバージョンの数は、保管する期間におおむね対応しています。各種構成で必要なストレージの容量についての詳細は、[容量計画](capacity-planning.html)を参照してください。
オンライン削除は、履歴の削除 _後_ に維持するレジャーバージョンの数に基づいておこなわれるので、設定した維持するレジャー数の2倍を保管するのに十分なディスク容量が必要です。
0. `rippled`の構成ファイルで`[node_db]` スタンザの`online_delete`フィールドを編集します。
[node_db]
# Other settings unchanged ...
online_delete=2000
advisory_delete=0
`online_delete`を、オンライン削除の実行後に維持するレジャーバージョンの最小数に設定します。自動削除が設定されている場合（デフォルト）、サーバーは通常、この数の約2倍のレジャーバージョンが蓄積されると削除を実行します。
{% include '_snippets/conf-file-location.md' %}<!--_ -->
0. `rippled`サービスを起動（または再起動）します。
$ sudo systemctl restart rippled
0. サーバーがネットワークと同期するまで待ちます。
ネットワークとシステムの能力と、サーバーがオフラインになっていた期間に応じて、完全な同期が完了するまでには5～15分かかります。
サーバーとネットワークの同期が完了すると、[server_infoメソッド][]が再び開き、`server_state`の値として`"full"`、`"proposing"`、`"validating"`のいずれかが報告されます。
0. [server_infoメソッド][]を使用してサーバーの`complete_ledgers`範囲を定期的に調べ、レジャーが削除されていることを確認します。
オンライン削除実行後の`complete_ledgers`範囲には、古いレジャーが使用できなくなったことが反映されます。サーバーに履歴が蓄積されるにつれ、使用可能なレジャーの総数が徐々に増加します。この数が設定した`online_delete`値の2倍に達し、オンライン削除が実行されるとレジャーの総数は減少します。
0. `rippled`ログで、`SHAMapStore::WRN`で始まるメッセージを確認します。このメッセージが出力されている場合、サーバーがネットワークと同期していない状態になったために[オンライン削除が中断されている](online-deletion.html#オンライン削除の中断)可能性があります。
この状況が定期的に発生する場合は、サーバーのスペックが不十分で、オンライン削除の実行中にレジャーを最新状態に維持できていない可能性があります。同じハードウェア上の他のサービス（スケジュール済みバックアップやセキュリティスキャンなど）と`rippled`サーバーがリソースをめぐって競合していないことを確認してください。以下のいずれかの操作を実行できます。
- システムスペックを強化する。推奨事項については、[システム要件](system-requirements.html)を参照してください。
- 設定を変更し、保管する履歴の量を減らす。（このチュートリアルのステップ2）
- サーバーの[`node_size`パラメーター](capacity-planning.html)を変更する。
- レジャーストアーに[RocksDBの代わりにNuDB](capacity-planning.html)を使用する。
- [指示による削除を使用してオンライン削除をスケジュールする](configure-advisory-deletion.html)。
## 関連項目
- [オンライン削除](online-deletion.html)
- [指示による削除の設定](configure-advisory-deletion.html)
- [履歴シャーディングの設定](configure-history-sharding.html)
- [完全な履歴の設定](configure-full-history.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

90
content/infrastructure/rippled/configuration/configure-online-deletion.md Normal file
View File

@@ -0,0 +1,90 @@
---
html: configure-online-deletion.html
parent: data-retention.html
blurb: Configure how far back your server should store transaction history.
labels:
- Core Server
- Data Retention
---
# Configure Online Deletion
In its default configuration, [the `rippled` server](xrpl-servers.html) [deletes history](online-deletion.html) older than the most recent 2000 [ledger versions](ledgers.html), keeping approximately 15 minutes of [ledger history](ledger-history.html) (based on the current rate between ledgers). This page describes how to configure the amount of history your `rippled` server stores before deleting.
## Prerequisites
This tutorial assumes your server meets the following prerequisites:
- You are on a supported operating system: Ubuntu Linux, Red Hat Enterprise Linux (RHEL), or CentOS.
- The `rippled` server is already [installed](install-rippled.html) and [online deletion](online-deletion.html) is enabled.
If you followed the installation instructions for a recommended platform, online deletion is enabled by default.
- Your server has [enough disk space](capacity-planning.html#disk-space) to store your chosen amount of history in its ledger store.
## Configuration Steps
To change the amount of history your server stores, perform the following steps:
1. Decide how many ledger versions' worth of history to store.
New ledger versions are usually validated 3 to 4 seconds apart, so the number of ledger versions corresponds roughly to the amount of time you want to store. See [Capacity Planning](capacity-planning.html) for details of how much storage is required for different configurations.
Online deletion is based on how many ledger versions to keep _after_ deleting history, so you should have enough disk space to store twice as many ledgers as you set it to keep.
0. In your `rippled`'s config file, edit the `online_delete` field of the `[node_db]` stanza.
[node_db]
# Other settings unchanged ...
online_delete=2000
advisory_delete=0
Set `online_delete` to the minimum number of ledger versions to keep after running online deletion. With automatic deletion (the default), the server typically runs deletion when it has accumulated about twice this many ledger versions.
{% include '_snippets/conf-file-location.md' %}<!--_ -->
0. Start (or restart) the `rippled` service.
$ sudo systemctl restart rippled
0. Wait for your server to sync to the network.
Depending on your network and system capabilities and how long your server was offline, it may take between 5 and 15 minutes to fully sync.
When your server is synced with the network, the [server_info method][] reports a `server_state` value of `"full"`, `"proposing"`, or `"validating"`.
0. Periodically check your server's `complete_ledgers` range using the [server_info method][] to confirm that ledgers are being deleted.
After online deletion runs, the `complete_ledgers` range reflects that older ledgers are no longer available. As your server accumulates history, the total number of ledgers available should slowly increase to twice the `online_delete` value you configured, then decrease when online deletion runs.
0. Monitor 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.
If this happens regularly, your server may not have sufficient specifications to keep up with the ledger while running online deletion. Check that other services on the same hardware (such as scheduled backups or security scans) aren't competing with the `rippled` server for resources. You may want to try any of the following:
- Increase your system specs. See [System Requirements](system-requirements.html) for recommendations.
- Change your configuration to store less history. (Step 2 of this tutorial)
- Change your server's [`node_size` parameter](capacity-planning.html).
- Use [NuDB instead of RocksDB](capacity-planning.html) for the ledger store.
- [Schedule online deletion using Advisory Deletion](configure-advisory-deletion.html).
## See Also
- **Concepts:**
- [Ledger History](ledger-history.html)
- [Online Deletion](online-deletion.html)
- **Tutorials:**
- [Configure Advisory Deletion](configure-advisory-deletion.html)
- [Configure History Sharding](configure-history-sharding.html)
- [Capacity Planning](capacity-planning.html)
- **References:**
- [server_info method][]
- [Ledger Data Formats](ledger-data-formats.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

66
content/infrastructure/rippled/configuration/configure-statsd.md Normal file
View File

@@ -0,0 +1,66 @@
---
html: configure-statsd.html
parent: configure-rippled.html
blurb: Monitor your rippled server with StatsD metrics.
labels:
- Core Server
---
# Configure StatsD
`rippled` can export health and behavioral information about itself in [StatsD](https://github.com/statsd/statsd) format. Those metrics can be consumed and visualized through [`rippledmon`](https://github.com/ripple/rippledmon) or any other collector that accepts StatsD formatted metrics.
## Configuration Steps
To enable StatsD on your `rippled` server, perform the following steps:
1. Set up a `rippledmon` instance on another machine to receive and aggregate stats.
$ git clone https://github.com/ripple/rippledmon.git
$ cd rippledmon
$ docker-compose up
Make sure [Docker](https://docs.docker.com/) and [Docker Compose](https://docs.docker.com/compose/install/) are installed on your machine when performing the steps above. For more information about configuring `rippledmon`, see the [`rippledmon` repository](https://github.com/ripple/rippledmon).
0. Add the `[insight]` stanza to your `rippled`'s config file.
[insight]
server=statsd
address=192.0.2.0:8125
prefix=my_rippled
- For the `address`, use the IP address and port where `rippledmon` is listening. By default, this port is 8125.
- For the `prefix`, choose a name that identifies the `rippled` server you are configuring. The prefix must not include whitespace, colons ":", or the vertical bar "|". The prefix appears on all of the StatsD metrics exported from this server.
{% include '_snippets/conf-file-location.md' %}<!--_ -->
0. Restart the `rippled` service.
$ sudo systemctl restart rippled
0. Check that the metrics are being exported:
$ tcpdump -i en0 | grep UDP
Replace `en0` with the appropriate network interface for your machine. For a complete list of the interfaces on your machine use `$ tcpdump -D`.
Sample Output:
00:41:53.066333 IP 192.0.2.2.63409 > 192.0.2.0.8125: UDP, length 196
You should periodically see messages indicating outbound traffic to the configured address and port of your `rippledmon` instance.
For descriptions of each StatsD metric, see the [`rippledmon` repository](https://github.com/ripple/rippledmon).
## See Also
- **Concepts:**
- [XRP Ledger Overview](xrp-ledger-overview.html)
- [The `rippled` Server](xrpl-servers.html)
- **Tutorials:**
- [Install `rippled`](install-rippled.html)
- [Capacity Planning](capacity-planning.html)
- **References:**
- [server_info method](server_info.html)
- [print method](print.html)

114
content/infrastructure/rippled/configuration/connect-your-rippled-to-the-xrp-test-net.ja.md Normal file
View File

@@ -0,0 +1,114 @@
---
html: connect-your-rippled-to-the-xrp-test-net.html
parent: configure-rippled.html
blurb: rippledサーバーをTest Netに接続して、模造の資金を使って新しい機能を試したり、機能をテストしたりします。
labels:
- コアサーバー
- ブロックチェーン
- 開発
---
# XRPL Altnetへのrippledの接続
Rippleは[代替となるテスト用および開発用ネットワーク](parallel-networks.html)を作成しており、開発者が最新のXRP Ledgerの非本番バージョン（Testnet）でアプリケーションをテストしたり、最新のベータバージョン（Devnet）で機能をテストして実験したりできるようにしています。 **これらのネットワークで使用する資金は実際の資金ではなく、テスト専用の資金です。** TestnetまたはDevnetの[`rippled`サーバー](xrpl-servers.html)に接続できます。
**注記:** XRP TestnetとDevnetのレジャーと残高は定期的にリセットされます。
`rippled`サーバーをXRP TestnetまたはDevnetに接続するには、以下の構成を設定します。
1. `rippled.cfg`ファイルで以下の手順に従います。
a. [Testnet](xrp-testnet-faucet.html)に接続するには、以下のセクションのコメントを解除し、次のように追加します。
[ips]
s.altnet.rippletest.net 51235
b. [Devnet](xrp-testnet-faucet.html)に接続するには、以下のセクションのコメントを解除し、次のように追加します。
[ips]
s.devnet.rippletest.net 51235
c. 以下のセクションを次のようにコメントアウトします。
# [ips]
# r.ripple.com 51235
2. `validators.txt`ファイルで以下の手順に従います。
2a. Altnetに接続するための変更
a. 以下のセクションのコメントを解除し、Altnetに接続するようにします。
[validator_list_sites]
https://vl.altnet.rippletest.net
[validator_list_keys]
ED264807102805220DA0F312E71FC2C69E1552C9C5790F6C25E3729DEB573D5860
b. 以下のセクションを次のようにコメントアウトします。
# [validator_list_sites]
# https://vl.ripple.com
#
# [validator_list_keys]
# ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
2b. Devnetに接続するための変更
a. 以下のセクションをコメントアウトします。
# [validator_list_sites]
# https://vl.altnet.rippletest.net
# [validator_list_keys]
# ED264807102805220DA0F312E71FC2C69E1552C9C5790F6C25E3729DEB573D5860
# [validator_list_sites]
# https://vl.ripple.com
#
# [validator_list_keys]
# ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
b. 次の信頼できるバリデータをvalidator.txtファイルに追加します。
[validator_list_sites]
https://vl.devnet.rippletest.net/index.json
[validator_list_keys]
EDDF2F53DFEC79358F7BE76BC884AC31048CFF6E2A00C628EAE06DB7750A247B12
3. `rippled`を再起動します。
4. `rippled`がXRP TestnetまたはDevnetに接続していることを確認するため、サーバーで[server_infoメソッド][]を使用して、その結果をTestnetまたはDevnetの公開サーバーの結果と比較します。両方のサーバーで`validated_ledger`オブジェクトの`seq`フィールドが同一である必要があります（確認中にこの数が変化した場合は、1～2の差が生じる可能性があります）。
以下のコマンドは、ローカルの`rippled`の最新検証済みレジャーインデックスをチェックします。
$ ./rippled server_info | grep seq
[WebSocket Toolのserver_info](websocket-api-tool.html#server_info)でネットワークのレジャーインデックスをチェックします。
## 関連項目
- **ツール:**
- [XRP Faucet](xrp-testnet-faucet.html)
- [WebSocket APIツール](websocket-api-tool.html) - 接続オプションで「Testnet公開サーバー」を選択します。
- **コンセプト:**
- [並列ネットワーク](parallel-networks.html)
- [コンセンサスについて](consensus.html)
- **チュートリアル:**
- [バリデータとしてのrippledの実行](run-rippled-as-a-validator.html)
- [スタンドアロンモードでの`rippled`のオフラインテスト](use-stand-alone-mode.html)
- `rippled`の[トラブルシューティング](troubleshoot-the-rippled-server.html)
- **リファレンス:**
- [server_infoメソッド][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

234
content/infrastructure/rippled/configuration/connect-your-rippled-to-the-xrp-test-net.md Normal file
View File

@@ -0,0 +1,234 @@
---
html: connect-your-rippled-to-the-xrp-test-net.html
parent: configure-rippled.html
blurb: Connect your rippled server to the test net to try out new features or test functionality with fake money.
labels:
- Core Server
- Blockchain
- Development
---
# Connect Your rippled to a Parallel Network
Various [alternative test and development networks](parallel-networks.html) exist for developers to test their apps or experiment with features without risking real money. **The funds used on these networks are not real funds and are intended for testing only.** You can connect your [`rippled` server](xrpl-servers.html) to any of these test networks.
**Caution:** On test networks with new and experimental features, you may need to run a pre-production release of the server to sync with the network. See the [Parallel Networks Page](parallel-networks.html) for information on what code version each network needs.
## Steps
To connect your `rippled` server to the XRP Testnet or Devnet, complete these steps. You can also use these steps to switch back to the production Mainnet after being on the Testnet or Devnet.
## 1. Configure your server to connect to the right hub.
Edit your `rippled.cfg` file.
{% include '_snippets/conf-file-location.md' %}
<!--{_ }-->
1. Set an `[ips]` stanza with the hub for the network you want to connect to:
<!-- MULTICODE_BLOCK_START -->
*Testnet*
[ips]
s.altnet.rippletest.net 51235
*Devnet*
[ips]
s.devnet.rippletest.net 51235
*Mainnet*
# No [ips] stanza. Use the default hubs to connect to Mainnet.
*AMM-Devnet*
[ips]
amm.devnet.rippletest.net 51235
<!-- MULTICODE_BLOCK_END -->
2. Comment out the previous `[ips]` stanza, if there is one:
# [ips]
# r.ripple.com 51235
# zaphod.alloy.ee 51235
# sahyadri.isrdc.in 51235
3. Add a `[network_id]` stanza with the appropriate value:
<!-- MULTICODE_BLOCK_START -->
*Testnet*
[network_id]
testnet
*Devnet*
[network_id]
devnet
*Mainnet*
[network_id]
main
*AMM-Devnet*
[network_id]
25
<!-- MULTICODE_BLOCK_END -->
For custom networks, everyone who connects to the network should use a value unique to that network. When creating a new network, choose a network ID at random from the integers 11 to 4,294,967,295.
**Note:** This setting helps your server find peers who are on the same network, but it is not a hard control on what network your server follows. The UNL / trusted validator settings (in the next step) are what actually define what network the server follows.
## 2. Set your trusted validator list.
Edit your `validators.txt` file. This file is located in the same folder as your `rippled.cfg` file and defines which validators your server trusts not to collude.
1. Uncomment or add the `[validator_list_sites]` and `[validator_list_keys]` stanzas for the network you want to connect to:
<!-- MULTICODE_BLOCK_START -->
*Testnet*
[validator_list_sites]
https://vl.altnet.rippletest.net
[validator_list_keys]
ED264807102805220DA0F312E71FC2C69E1552C9C5790F6C25E3729DEB573D5860
*Devnet*
[validator_list_sites]
https://vl.devnet.rippletest.net
[validator_list_keys]
EDDF2F53DFEC79358F7BE76BC884AC31048CFF6E2A00C628EAE06DB7750A247B12
*Mainnet*
[validator_list_sites]
https://vl.ripple.com
[validator_list_keys]
ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
*AMM-Devnet*
[validator_list_sites]
http://vlamm.devnet.rippletest.net/
[validator_list_keys]
03553F67DC5A6FE0EBFE1B3B4742833D14AF7C65E79E5760EC76EC56EAFD254CE9
<!-- MULTICODE_BLOCK_END -->
**Tip:** Preview packages might come with the necessary stanzas pre-configured, but check them just in case.
1. Comment out any previous `[validator_list_sites]`, `[validator_list_keys]`, or `[validators]` stanzas.
For example:
# [validator_list_sites]
# https://vl.ripple.com
#
# [validator_list_keys]
# ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
# Old hard-coded List of Devnet Validators
# [validators]
# n9Mo4QVGnMrRN9jhAxdUFxwvyM4aeE1RvCuEGvMYt31hPspb1E2c
# n9MEwP4LSSikUnhZJNQVQxoMCgoRrGm6GGbG46AumH2KrRrdmr6B
# n9M1pogKUmueZ2r3E3JnZyM3g6AxkxWPr8Vr3zWtuRLqB7bHETFD
# n9MX7LbfHvPkFYgGrJmCyLh8Reu38wsnnxA4TKhxGTZBuxRz3w1U
# n94aw2fof4xxd8g3swN2qJCmooHdGv1ajY8Ae42T77nAQhZeYGdd
# n9LiE1gpUGws1kFGKCM9rVFNYPVS4QziwkQn281EFXX7TViCp2RC
# n9Jq9w1R8UrvV1u2SQqGhSXLroeWNmPNc3AVszRXhpUr1fmbLyhS
## 3. Enable (or Disable) Features
For some test networks using experimental features, you must also forcefully enable the appropriate feature in the config file. For other networks, you should not use the `[features]` stanza. Add or modify the `[features]` stanza of your config file as follows:
<!-- MULTICODE_BLOCK_START -->
_Testnet_
```
# [features]
# Delete or comment out. Don't force-enable features on Testnet.
```
_Devnet_
```
# [features]
# Delete or comment out. Don't force-enable features on Devnet.
```
_Mainnet_
```
# [features]
# Delete or comment out. Don't force-enable features on Mainnet.
```
_AMM-Devnet_
```
[features]
AMM
```
<!-- MULTICODE_BLOCK_END -->
**Warning:** Do not use the `[features]` stanza when connecting to Mainnet or Testnet. Forcefully enabling different features than the rest of the network could cause your server to diverge from the network.
## 4. Restart the server.
```sh
$ sudo systemctl restart rippled
```
## 5. Verify that your server syncs.
It takes about 5 to 15 minutes to sync to the network after a restart. After your server is synced, the [server_info method][] shows a `validated_ledger` object based on the network you are connected to.
To confirm that your `rippled` is connected to the right network, compare the results from your server to [a public server][public servers] on the Testnet or Devnet. The `seq` field of the `validated_ledger` object should be the same on both servers (possibly off by one or two, if it changed as you were checking).
The following example shows how to check your server's latest validated ledger from the commandline:
```sh
rippled server_info | grep seq
```
You can use [server_info in the WebSocket Tool](websocket-api-tool.html#server_info) to look up the latest ledger index (`seq`) on the intended network.
## See Also
- **Tools:**
- [XRP Faucets](xrp-testnet-faucet.html)
- [WebSocket API Tool](websocket-api-tool.html) - Select 'Testnet Public Server' or 'Devnet Public Server' in the connection options.
- **Concepts:**
- [Parallel Networks](parallel-networks.html)
- [Consensus](consensus.html)
- **Tutorials:**
- [Run rippled as a Validator](run-rippled-as-a-validator.html)
- [Test `rippled` Offline in Stand-Alone Mode](use-stand-alone-mode.html)
- [Troubleshooting `rippled`](troubleshoot-the-rippled-server.html)
- **References:**
- [server_info method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

44
content/infrastructure/rippled/configuration/enable-public-signing.ja.md Normal file
View File

@@ -0,0 +1,44 @@
---
html: enable-public-signing.html
parent: configure-rippled.html
blurb: 他の人があなたのサーバーを使ってトランザクションに署名できるようにします。（非推奨）
labels:
- コアサーバー
- セキュリティ
---
# パブリック署名の有効化
[新規: rippled 1.1.0][]デフォルトでは、`rippled`の署名メソッドは管理者接続に限定されています。v1.1.0以前のバージョンの`rippled`のように、署名メソッドをパブリックAPIメソッドとして使用できるようにするには、構成を変更することで、これを使用できるようにします。
これにより、サーバーが「パブリック」[JSON-RPC接続およびWebSocket接続](get-started-using-http-websocket-apis.html)を受け入れる場合は、これらのパブリック接続で以下のメソッドが使用できるようになります。
- [sign][signメソッド]
- [sign_for][sign_forメソッド]
- [submit][submitメソッド](in "sign-and-submit" mode)
これらのメソッドを使用するにあたり、管理者接続からパブリック署名を有効にする必要は**ありません**。
**注意:** パブリック署名を有効にすることは推奨されません。[wallet_proposeメソッド][]と同様に、署名コマンドでは管理レベルの権限を必要とするアクションは実行されませんが、署名コマンドを管理者接続に制限することにより、ユーザーが安全ではない通信経由で、またはユーザーの管理下にないサーバーとの間でシークレットキーを無責任に送受信することを防止します。
パブリック署名を有効にするには、以下の手順を実行します。
1. `rippled`の構成ファイルを編集します。
vim /etc/opt/ripple/rippled.cfg
{% include '_snippets/conf-file-location.md' %}<!--_ -->
2. 以下のスタンザを構成ファイルに追加し、変更を保存します。
[signing_support]
true
3. `rippled`サーバーを再起動します。
systemctl restart rippled
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

58
content/infrastructure/rippled/configuration/enable-public-signing.md Normal file
View File

@@ -0,0 +1,58 @@
---
html: enable-public-signing.html
parent: configure-rippled.html
blurb: Allow others to use your server to sign transactions. (Not recommended)
labels:
- Core Server
- Security
---
# Enable Public Signing
By default, the signing methods for [`rippled`](xrpl-servers.html) are limited to [administrative connections](admin-api-methods.html). If you want to allow signing methods to be used as public API methods (like with versions of `rippled` before v1.1.0), you can enable it with a configuration change. [New in: rippled 1.1.0][]
This enables the following methods to be used on "public" [JSON-RPC and WebSocket connections](get-started-using-http-websocket-apis.html), if your server accepts them:
- [sign][sign method]
- [sign_for][sign_for method]
- [submit][submit method] (in "sign-and-submit" mode)
You **do not** need to enable public signing to use these methods from an admin connection.
**Caution:** Ripple does not recommend enabling public signing. Like the [wallet_propose method][], the signing commands do not perform any actions that would require administrative-level permissions, but restricting them to admin connections protects users from irresponsibly sending or receiving secret keys over unsecured communications, or to servers they do not control.
To enable public signing, perform the following steps:
1. Edit your `rippled`'s config file.
vim /etc/opt/ripple/rippled.cfg
{% include '_snippets/conf-file-location.md' %}<!--_ -->
2. Add the following stanza to your config file, and save the changes:
[signing_support]
true
3. Restart your `rippled` server:
systemctl restart rippled
## See Also
- **Concepts:**
- [Transactions](transactions.html)
- [Cryptographic Keys](cryptographic-keys.html)
- **Tutorials:**
- [Set Up Secure Signing](secure-signing.html)
- [Get Started Using HTTP / WebSocket APIs](get-started-using-http-websocket-apis.html)
- [Get Started Using JavaScript](get-started-using-javascript.html)
- **References:**
- [sign method][]
- [sign_for method][]
- [submit method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

55
content/infrastructure/rippled/configuration/run-rippled-as-a-stock-server.md Normal file
View File

@@ -0,0 +1,55 @@
---
html: run-rippled-as-a-stock-server.html
parent: server-modes.html
blurb: A multipurpose configuration for anyone integrating XRP.
labels:
- Core Server
---
# Run rippled as a Stock Server
A stock server is a multipurpose configuration for `rippled`. With a stock server, you can submit transactions to the XRP Ledger, access ledger history, and use the latest [tools](software-ecosystem.html) to integrate with XRP and the XRP Ledger. You can connect client applications to the XRP Ledger using this server.
A stock server does all of the following:
- Connects to a [network of peers](peer-protocol.html)
- Relays cryptographically signed [transactions](transactions.html)
- Maintains a local copy of the complete shared global [ledger](ledgers.html)
To participate in the [consensus process](consensus.html) as a validator, [run rippled as a validator](run-rippled-as-a-validator.html) instead.
## Install and run `rippled`
The default package installation installs a stock server with a small amount of transaction history. For installation steps, see [Install `rippled`](install-rippled.html).
After installation, you can adjust how much history your server stores at a time. For steps on how to do this, see [Configure Online Deletion](configure-online-deletion.html).
## Troubleshooting
For more information, see [Troubleshooting `rippled`](troubleshoot-the-rippled-server.html)
## See Also
- **Concepts:**
- [XRP Ledger Overview](xrp-ledger-overview.html)
- [The `rippled` Server](xrpl-servers.html)
- **Tutorials:**
- [Cluster rippled Servers](cluster-rippled-servers.html)
- [Install `rippled`](install-rippled.html)
- [Capacity Planning](capacity-planning.html)
- **References:**
- [Validator Keys Tool Guide](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md)
- [consensus_info method][]
- [validator_list_sites method][]
- [validators method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

311
content/infrastructure/rippled/configuration/run-rippled-as-a-validator.ja.md Normal file
View File

@@ -0,0 +1,311 @@
---
html: run-rippled-as-a-validator.html
parent: server-modes.html
blurb: サーバーがコンセンサスレジャーで投票できるようにします。
labels:
- コアサーバー
- ブロックチェーン
top_nav_grouping: 人気ページ
top_nav_name: UNLに参加しよう
---
# バリデータとしてのrippledの実行
[バリデータモード](rippled-server-modes.html)で実行されている[`rippled`サーバー](xrpl-servers.html)は、ストックサーバーが実行するあらゆる処理を実行します。
- [ピアのネットワーク](peer-protocol.html)への接続
- 暗号署名された[トランザクション](transactions.html)の中継
- 完全な共有グローバル[レジャー](ledgers.html)のローカルコピーの維持
バリデータが _特異である_ のは、検証メッセージも発行するという点です。これらのメッセージは、[コンセンサスプロセス](consensus-principles-and-rules.html#コンセンサスの仕組み)の進行中、XRP Ledgerネットワークによる評価の対象となる候補のトランザクションです。
ただし、単に検証メッセージを発行するだけで、バリデータにコンセンサスプロセスでの発言権が自動的に付与されるわけではありません。他のサーバーがバリデータ（モードのサーバー）を彼らのユニークノードリスト（UNL）に追加しない限り、彼らは（バリデータモードのサーバーからの）検証メッセージを無視します。バリデータがUNLに含まれている場合、 _信頼できる_ バリデータであり、その提案は、信頼する側のサーバーによってコンセンサスプロセスで検討されます。
バリデータが _信頼できる_ バリデータではない場合も、ネットワークの全体的な健全性に関して、重要な役割を果たすことに変わりはありません。これらのバリデータは、信頼できるバリデータを評価するための基準の確立を支援します。例えば、信頼できるバリデータが、UNLに含まれていない多数のバリデータに対して異議を唱えている場合、問題があることを示しているおそれがあります。
## 1. 優れたバリデータの特徴の理解
バリデータ（サーバー）が以下の特質を常に備えるよう努めます。優れたバリデータであることは、`rippled`サーバーの運用者や[https://vl.ripple.com](https://vl.ripple.com)などのバリデータリスト発行者が、バリデータを彼らのUNLに追加する際に、バリデータを信頼する上で後押しになります。
- **可用性**
優れたバリデータは、常に稼働し、提案されるあらゆるレジャーについて検証投票を送信します。100%のアップタイムを実現するよう努めてください。
- **合意**
優れたバリデータの投票は、可能な限り高い頻度で、コンセンサスプロセスの結果と合致します。これに該当しない場合は、バリデータのソフトウェアが最新のものではないか、不具合があるか、意図的な偏りがあることを示唆している可能性があります。常に[最新の`rippled`リリース](https://github.com/ripple/rippled/tree/master)を、修正を加えることなく実行します。新規リリースについて知るために、[`rippled`のリリースを確認](https://github.com/ripple/rippled/releases)してください。
- **適時の投票**
優れたバリデータの投票は、コンセンサスラウンドが終了する前に、素早く届きます。適時の投票を維持するには、バリデータが推奨される[システム要件](system-requirements.html)を満たしていることを確認してください。これには、高速のインターネット接続が含まれます。
- **身元の確さ**
優れたバリデータには、身元が明確な所有者が存在します。[ドメイン検証](#6-ドメイン検証の提供)を提供することは、その第一歩になります。XRP LedgerネットワークのUNLに、多くの法的な管轄域および地域のさまざまな所有者によって運営されているバリデータが含まれていると理想的です。結果として、信頼できるバリデータの公正な運用が地域特有の事象によって損なわれるおそれが低減されます。
Ripple社は、推奨される一連のバリデータを記載した[バリデータリスト](https://github.com/ripple/rippled/blob/develop/cfg/validators-example.txt)を公開しています。本番環境のサーバーでは、このリストを使用することを強くお勧めします。
## 2. `rippled`サーバーのインストール
詳細は、[`rippled`のインストール](install-rippled.html)を参照してください。
## 3. `rippled`サーバーで検証を有効化
`rippled`サーバーで検証を有効にすることは、サーバーの`rippled.cfg`ファイルにあるバリデータトークンを提供することを意味します。バリデータキーとトークンを安全に生成して管理するために、`validator-keys`ツール（`rippled` RPMに含まれる）を使用することをお勧めします。
バリデータ（サーバー）**以外の**場所で、以下の手順に従います。
1. `validator-keys`ツールを`rippled` RPMを通じてまだインストールしていない場合は、手動でビルドして実行します。
`validator-keys`ツールを手動でビルドして実行する方法については、[validator-keys-tool](https://github.com/ripple/validator-keys-tool)を参照してください。
2. `create_keys`コマンドを使用して、バリデータキーペアを生成します。
$ validator-keys create_keys
Ubuntuでの出力の例:
Validator keys stored in /home/my-user/.ripple/validator-keys.json
This file should be stored securely and not shared.
macOSでの出力の例:
Validator keys stored in /Users/my-user/.ripple/validator-keys.json
This file should be stored securely and not shared.
**警告:** 生成した`validator-keys.json`キーファイルは、暗号化されたUSBフラッシュドライブなど、安全かつ回復可能なオフラインの場所に保管してください。内容には修正を加えないでください。特に、キーの使用場所となるバリデータにキーファイルを保存しないようにします。バリデータの`secret_key`が悪用された場合は、ただちに[キーを破棄](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md#key-revocation)します。
`validator-keys`ツールおよびツールで生成されるキーペアの詳細は、[Validator Keys Tool Guide](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md)を参照してください。
3. `create_token`コマンドを使用して、バリデータトークンを生成します。
$ validator-keys create_token --keyfile /PATH/TO/YOUR/validator-keys.json
出力の例:
Update rippled.cfg file with these values:
# validator public key: nHUtNnLVx7odrz5dnfb2xpIgbEeJPbzJWfdicSkGyVw1eE5GpjQr
[validator_token]
eyJ2YWxpZGF0aW9uX3NlY3J|dF9rZXkiOiI5ZWQ0NWY4NjYyNDFjYzE4YTI3NDdiNT
QzODdjMDYyNTkwNzk3MmY0ZTcxOTAyMzFmYWE5Mzc0NTdmYT|kYWY2IiwibWFuaWZl
c3QiOiJKQUFBQUFGeEllMUZ0d21pbXZHdEgyaUNjTUpxQzlnVkZLaWxHZncxL3ZDeE
hYWExwbGMyR25NaEFrRTFhZ3FYeEJ3RHdEYklENk9NU1l1TTBGREFscEFnTms4U0tG
bjdNTzJmZGtjd1JRSWhBT25ndTlzQUtxWFlvdUorbDJWMFcrc0FPa1ZCK1pSUzZQU2
hsSkFmVXNYZkFpQnNWSkdlc2FhZE9KYy9hQVpva1MxdnltR21WcmxIUEtXWDNZeXd1
NmluOEhBU1FLUHVnQkQ2N2tNYVJGR3ZtcEFUSGxHS0pkdkRGbFdQWXk1QXFEZWRGdj
VUSmEydzBpMjFlcTNNWXl3TFZKWm5GT3I3QzBrdzJBaVR6U0NqSXpkaXRROD0ifQ==
バリデータ（サーバー）で、以下の手順に従います。
1. `[validator_token]`とその値を、バリデータの`rippled.cfg`ファイルに追加します。
以前に、`validator-keys`ツールを使用せずにバリデータを設定している場合は、`[validation_seed]`とその値を`rippled.cfg`ファイルから削除します。これにより、バリデータの公開鍵が変更されます。
2. `rippled`を再起動します。
$ sudo systemctl restart rippled.service
3. `server_info`コマンドを使用してバリデータの情報を取得し、バリデータとして実行されていることを確認します。
$ rippled server_info
- 応答に含まれている`pubkey_validator`の値は、バリデータで使用するために生成した`validator-keys.json`ファイルの`public_key`と一致している必要があります。
- `server_state`の値は、 _**proposing**_ にする必要があります。
**セキュリティのヒント:** `rippled.cfg`ファイルに対する権限をより制限的なものに変更します。Linuxでは、`0600`にすることを推奨します。`chmod 0600 rippled.cfg`を使用して変更できます。
## 4. ネットワークへの接続
このセクションでは、バリデータをXRP Ledgerネットワークに接続するために使用できる3種類の構成について説明します。ユースケースに最適な構成を使用してください。
- [検出されたピア](#検出されたピアを使用した接続): ピアツーピアネットワーク内の任意のサーバーに接続します。
- [プロキシ](#プロキシを使用した接続): ストック`rippled`サーバーを、バリデータとピアツーピアネットワークの他の部分との間のプロキシとして実行します。
- [公開ハブ](#公開ハブを使用した接続): 評価の高い特定の公開サーバーにのみ接続します。
これらのアプローチの違いについては、[ピア接続設定のメリットとデメリット](peer-protocol.html#ピア接続設定のメリットとデメリット)を参照してください。
### 検出されたピアを使用した接続
この構成では、[検出されたピア](peer-protocol.html#ピアの検出)を使用してバリデータをXRP Ledgerネットワークに接続します。これは`rippled`サーバーのデフォルトの動作です。
_**検出されたピアを使用してバリデータをXRP Ledgerネットワークに接続するには、**_ バリデータの`rippled.cfg`ファイルで`[peer_private]`スタンザを省略するか、それを`0`に設定します。この構成の[サンプルのrippled.cfgファイル](https://github.com/ripple/rippled/blob/develop/cfg/rippled-example.cfg)が提供されています。
### プロキシを使用した接続
この構成は、自社で運用するストック`rippled`サーバーを通じてバリデータをネットワークに接続します。これらのプロキシサーバーは、バリデータと発着信ネットワークトラフィックの間に設置します。
_**プロキシを使用してバリデータをXRP Ledgerネットワークに接続するには、次の手順を実行します。**_
1. ストック`rippled`サーバーを設置します。詳細は、[rippledのインストール](install-rippled.html)を参照してください。
2. バリデータとストック`rippled`サーバーを設定して、[クラスター](cluster-rippled-servers.html)内で実行します。
3. バリデータの`rippled.cfg`ファイルで、`[peer_private]`を`1`に設定します。そうすることで、バリデータのIPアドレスが転送されないようにします。詳細は、[プライベートピア](peer-protocol.html#プライベートピア)を参照してください。また、これによりクラスター内でバリデータを実行するよう`[ips_fixed]`スタンザで定義したサーバー以外のサーバーに、バリデータが接続しないようになります。
**警告:** バリデータのIPアドレスを、その他の方法で公開していないことを確認してください。
4. 以下のトラフィックのみを許可するように、バリデータのホストマシンのファイアウォールを構成します。
- 着信トラフィック: 構成したクラスター内にあるストック`rippled`サーバーのIPアドレスが発信元である場合のみ
- 発信トラフィック: 構成したクラスター内にあるストック`rippled`サーバーのIPアドレスおよびポート443経由の<https://vl.ripple.com>が送信先である場合のみ
5. `rippled`を再起動します。
$ sudo systemctl restart rippled.service
6. いずれかのストック`rippled`サーバーにある[ピアクローラー](peer-crawler.html)エンドポイントを使用します。応答には、バリデータが含まれていないはずです。これにより、バリデータの`[peer_private]`構成が機能していることが確認されます。バリデータの`[peer_private]`を有効にした場合の効果の1つは、バリデータのピアによって、ピアクローラーの結果にバリデータが含まれないことです。
$ curl --insecure https://STOCK_SERVER_IP_ADDRESS_HERE:51235/crawl | python3 -m json.tool
<!-- { TODO: Future: add a recommended network architecture diagram to represent the proxy, clustering, and firewall setup: https://ripplelabs.atlassian.net/browse/DOC-2046 }-->
### 公開ハブを使用した接続
この構成では、2つの[公開ハブ](rippled-server-modes.html#公開ハブ)を使用してバリデータをネットワークに接続します。この構成は、[自社で運用しているプロキシを使用した接続](#プロキシを使用した接続)と似ていますが、公開ハブを通じて接続します。
_**公開ハブを使用してバリデータをネットワークに接続するには、次の手順を実行します。**_
1. バリデータの`rippled.cfg`ファイルに、次の`[ips_fixed]`スタンザを含めます。2つの値`r.ripple.com 51235`と`zaphod.alloy.ee 51235`がデフォルトの公開ハブです。このスタンザは、これらの公開ハブとのピア接続を常に維持するよう`rippled`に指示します。
[ips_fixed]
r.ripple.com 51235
zaphod.alloy.ee 51235
**注意:** この構成では、デフォルトの公開ハブを使用してバリデータをネットワークに接続します。これらは _デフォルト_ の公開ハブであるため、ビジー状態になってバリデータにネットワークへの接続を提供できない場合があります。この問題を避けるために、接続する公開ハブの数を増やすか、デフォルトでない公開ハブに接続するようにします。
他の`rippled`サーバーのIPアドレスをここに記述することもできますが、それらのサーバーに対して以下の事項を期待できる場合に _**限ります**_ 。
- メッセージを検閲することなく中継する。
- オンライン状態を常に維持する。
- サーバーに対するDDoS攻撃を実行しない。
- サーバーをクラッシュさせようとしない。
- 未知の相手にバリデータのIPアドレスを公開しない。
2. また、バリデータの`rippled.cfg`ファイルに、次の`[peer_private]`スタンザを含めて、それを`1`に設定します。それにより、バリデータのピアに対して、バリデータのIPアドレスをブロードキャストしないよう指示することになります。また、バリデータに対して、`[ips_fixed]`スタンザで設定されているピアにのみ接続するよう指示することになります。これにより、既知の信頼できるピア`rippled`サーバーに対してのみ、バリデータが接続を確立し、IPアドレスを共有することが保証されます。
[peer_private]
1
**警告:** バリデータのIPアドレスを、その他の方法で公開していないことを確認してください。
`[peer_private]`が有効になっている場合、`rippled`は、`[ips]`スタンザで指定されている接続をすべて無視します。現在`[ips]`スタンザにあるIPアドレスに接続する必要がある場合は、代わりにそれを`[ips_fixed]`スタンザに記述します。ただし、それらのIPアドレスに対して、ステップ1で説明した確実な挙動を期待できる場合に _**限ります**_ 。
3. `rippled`を再起動します。
$ sudo systemctl restart rippled.service
## 5. ネットワーク接続の確認
ここでは、バリデータがXRP Ledgerネットワークへの健全な接続を保持していることを検証する方法をいくつか紹介します。
- [`peers`](peers.html)コマンドを使用して、バリデータに接続しているすべての`rippled`サーバーのリストを取得します。`peers`の配列が`null`である場合、ネットワークへの健全な接続が存在していません。このドキュメントの手順に従ってバリデータを設置した場合、`peers`の配列には、`[ips_fixed]`スタンザで定義されているピアの数と同数のオブジェクトが含まれています。
公開ハブを`[ips_fixed]`スタンザに記述した場合、そのハブがビジーになっているときは、バリデータの接続が拒否されることがあります。この場合、接続の数は、`[ips_fixed]`スタンザで設定した数よりも最終的に少なくなることがあります。初めて拒否された場合、バリデータは接続を再試行します。
ネットワークへの安全かつ信頼できる接続を維持することが困難であり、公開ハブまたはプロキシを使用して接続を設定していない場合、[4. ネットワークへの接続](#4-ネットワークへの接続)を参照してください。このセクションで説明されているいずれかの方法は、バリデータがネットワークへの健全な接続を維持する上で有用となる可能性があります。
- [`server_info`](server_info.html)コマンドを使用して、バリデータに関するいくつかの基本情報を取得します。`server_state`は、`proposing`に設定されているはずです。`full`または`validating`に設定されている場合もありますが、`proposing`に移行するまでの数分間に限られます。
`server_state`が`proposing`に設定されている時間が大部分を占めていない場合、XRP Ledgerネットワークにバリデータが完全に参加できていないことを示している可能性があります。サーバーの状態および`server_info`エンドポイントを使用してバリデータの問題を診断する方法の詳細は、[`rippled`サーバーの状態](rippled-server-states.html)および[`server_info`の取得](diagnosing-problems.html#server_infoの取得)を参照してください。
- [`validators`](validators.html)コマンドを使用して、バリデータによって使用される、公開済みかつ信頼できるバリデータの最新リストを取得します。`validator_list_expires`の値が、`never`（無期限）、期限が切れていない、または期限切れ間近のいずれかであることを確認してください。
## 6. ドメイン検証の提供
検証リスト発行者およびXRP Ledgerネットワーク内のその他の参加者がバリデータの運用元を把握しやすいようにするには、バリデータのドメイン検証を提供します。ドメイン検証とは、ハイレベルでは双方向リンクを指します。
- ドメインを使用して、バリデータキーの所有権を主張します。
- バリデータキーを使用して、ドメインの所有権を主張します。
このリンクを作成すると、バリデータキーとドメインの両方を所有しているという確固たる証拠が確立されます。この証拠を提供することは、[優れたバリデータであること](#1-優れたバリデータの特徴の理解)の側面の1つにすぎません。
ドメイン検証を提供するには、以下の手順に従います。
1. バリデータと公に関連付ける、所有しているドメインの名前を選択します。そのドメインのポート443で外部に公開されるHTTPSサーバーを実行中であり、そのサーバーのTLS証明書に関連付けられている秘密鍵ファイルへのアクセス権を持っている必要があります。（注記: [TLSの旧称はSSLです](https://en.wikipedia.org/wiki/Transport_Layer_Security)。）DDoS攻撃への対策として、ドメイン名によってバリデータのIPアドレスが解決されないようにする必要があります。
2. バリデータの公開鍵を公開し、特に他の`rippled`オペレーターに知らせます。例えば、Webサイト、ソーシャルメディア、[XRPChatコミュニティーフォーラム](https://www.xrpchat.com/)、またはプレスリリースでバリデータの公開鍵を公表できます。
3. この[Googleフォーム](https://docs.google.com/forms/d/e/1FAIpQLScszfq7rRLAfArSZtvitCyl-VFA9cNcdnXLFjURsdCQ3gHW7w/viewform)を使用して、自身のバリデータをXRP Chartsの[バリデータレジストリー](https://xrpcharts.ripple.com/#/validators)に登録するための要求を送信します。バリデータをこのレジストリーに登録することは、そのバリデータとドメインを所有していることを示す、別の形での公的な証拠になります。フォームに漏れなく記入するには、以下の情報が必要です。
1. バリデータのサーバーで以下のコマンドを実行して、バリデータの公開鍵を検出します。
$ /opt/ripple/bin/rippled server_info | grep pubkey_validator
返された値を、Googleフォームの**Validator Public Key**フィールドに入力します。
2. WebドメインのTLS秘密鍵を使用して、バリデータの公開鍵に署名します。TLS秘密鍵ファイルをバリデータのサーバーに保存する必要はありません。
$ openssl dgst -sha256 -hex -sign /PATH/TO/YOUR/TLS.key <(echo YOUR_VALIDATOR_PUBLIC_KEY_HERE)
出力の例:
4a8b84ac264d18d116856efd2761a76f3f4544a1fbd82b9835bcd0aa67db91c53342a1ab197ab1ec4ae763d8476dd92fb9c24e6d9de37e3594c0af05d0f14fd2a00a7a5369723c019f122956bf3fc6c6b176ed0469c70c864aa07b4bf73042b1c7cf0b2c656aaf20ece5745f54ab0f78fab50ebd599e62401f4b57a4cccdf8b76d26f4490a1c51367e4a36faf860d48dd2f98a6134ebec1a6d92fadf9f89aae67e854f33e1acdcde12cfaf5f5dbf1b6a33833e768edbb9ff374cf4ae2be21dbc73186a5b54cc518f63d6081919e6125f7daf9a1d8e96e3fdbf3b94b089438221f8cfd78fd4fc85c646b288eb6d22771a3ee47fb597d28091e7aff38a1e636b4f
返された値を、Googleフォームの**SSL Signature**フィールドに入力します。
3. [`validator-keys`ツール](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md)（`rippled`のRPMに収録）を使用して、ドメイン名に署名します。
$ validator-keys --keyfile /PATH/TO/YOUR/validator-keys.json sign YOUR_DOMAIN_NAME
出力の例:
E852C2FE725B64F353E19DB463C40B1ABB85959A63B8D09F72C6B6C27F80B6C72ED9D5ED6DC4B8690D1F195E28FF1B00FB7119C3F9831459F3C3DE263B73AC04
返された値を、Googleフォームの**Domain Signature**フィールドに入力します。
4. 記入したGoogleフォームを送信すると、ドメイン検証の成否を通知するメールがXRP Chartsから送信されます。ドメイン検証が成功した場合は、XRP Chartsの[バリデータレジストリー](https://xrpcharts.ripple.com/#/validators)にバリデータとドメインが表示されます。
<!--{ ***TODO: For the future - add a new section or separate document: "Operating a Trusted Validator" -- things that you need to be aware of once your validator has been added to a UNL and is participating in consensus. We should tell the user what to expect once they are listed in a UNL. How to tell if your validator is participating in the consensus process? How to tell if something isn't right with your validator - warning signs that they should look out for? How to tell if your validator has fallen out of agreement - what is the acceptable vs unacceptable threshold? Maybe provide a script that will alert them when something is going wrong.*** }-->
## バリデータキーの破棄
バリデータのマスター秘密鍵が漏えいした場合は、ただちに永続的に破棄する必要があります。
`validator-keys`ツールでバリデータ用に生成したマスターキーペアを破棄する方法については、[Key Revocation](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md#key-revocation)を参照してください。
## 関連項目
- **コンセプト:**
- [XRP Ledgerの概要](xrp-ledger-overview.html)
- [`rippled`サーバー](xrpl-servers.html)
- **チュートリアル:**
- [rippledサーバーのクラスター化](cluster-rippled-servers.html)
- [`rippled`のインストール](install-rippled.html)
- [容量の計画](capacity-planning.html)
- **リファレンス:**
- [Validator Keysツールガイド](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md)
- [consensus_infoメソッド][]
- [validator_list_sitesメソッド][]
- [validatorsメソッド][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

285
content/infrastructure/rippled/configuration/run-rippled-as-a-validator.md Normal file
View File

@@ -0,0 +1,285 @@
---
html: run-rippled-as-a-validator.html
parent: server-modes.html
blurb: Have your server vote on the consensus ledger.
labels:
- Core Server
- Blockchain
top_nav_grouping: Popular Pages
top_nav_name: Join UNL
---
# Run rippled as a Validator
A [`rippled` server](xrpl-servers.html) running in [validator mode](rippled-server-modes.html) does everything a stock server does:
- Connects to a [network of peers](peer-protocol.html)
- Relays cryptographically signed [transactions](transactions.html)
- Maintains a local copy of the complete shared global [ledger](ledgers.html)
What makes a validator _different_ is that it also issues validation messages, which are sets of candidate transactions for evaluation by the XRP Ledger network during the [consensus process](consensus-principles-and-rules.html#how-consensus-works).
Issuing validation messages does not automatically give your validator a say in the consensus process, so the system is not vulnerable to a [Sybil attack](https://en.wikipedia.org/wiki/Sybil_attack). Other servers ignore your validation messages unless they add your validator to their Unique Node List (UNL). If your validator is included in a UNL, it is a _trusted_ validator and its proposals are considered in the consensus process by the servers that trust it.
Even if your validator isn't a _trusted_ validator, it stills plays an important role in the overall health of the network. These validators help set the standard that trusted validators are measured against. For example, if a trusted validator is disagreeing with a lot of these validators that aren't listed in UNLs, that might indicate a problem.
**Warning:** Validators should not be accessible to the public. Do not allow public WebSocket access to your validator server or any other form of public access.
## 1. Understand the traits of a good validator
Strive to have your validator embody the following properties. Being a good validator helps `rippled` server operators and validator list publishers (such as https://vl.ripple.com and https://vl.xrplf.org) trust your validator before adding it to their UNLs.
- **Available**
A good validator is always running and submitting validation votes for every proposed ledger. Strive for 100% uptime.
- **In agreement**
A good validator's votes match the outcome of the consensus process as often as possible. To do otherwise could indicate that your validator's software is outdated, buggy, or intentionally biased. Always run the [latest `rippled` release](https://github.com/XRPLF/rippled/tree/release) without modifications. [Watch `rippled` releases](https://github.com/XRPLF/rippled/releases) and subscribe to the [Google Group](https://groups.google.com/g/ripple-server) to be notified of new releases.
- **Issuing prompt votes**
A good validator's votes arrive quickly and not after a consensus round has already finished. To keep your votes on time, make sure your validator meets the recommended [system requirements](system-requirements.html), which include a fast internet connection.
It is possible to submit new transactions and query data using a validator, but heavy loads of API queries may make the validator less reliable at keeping up with consensus. If your API needs are light enough, then you can use a server for both purposes. Ideally, a validator should be dedicated to participating in consensus.
- **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 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. <!-- STYLE_OVERRIDE: clearly -->
It is strongly recommended that operators use the list providers that are present in this [example file](https://github.com/XRPLF/rippled/blob/develop/cfg/validators-example.txt).
## 2. Install a `rippled` server
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. You can use the `validator-keys` tool (included in `rippled` packages) to securely generate and manage your validator keys and tokens.
In a secure location **not** on your validator:
1. Manually build and run the `validator-keys` tool, if you don't already have it installed via a `rippled` RPM.
For information about manually building and running the `validator-keys` tool, see [validator-keys-tool](https://github.com/ripple/validator-keys-tool).
2. Generate a validator key pair using the `create_keys` command.
$ validator-keys create_keys
Sample output on Ubuntu:
Validator keys stored in /home/my-user/.ripple/validator-keys.json
This file should be stored securely and not shared.
Sample output on macOS:
Validator keys stored in /Users/my-user/.ripple/validator-keys.json
This file should be stored securely and not shared.
**Warning:** Store the generated `validator-keys.json` key file in a secure, offline, and recoverable location, such as an encrypted USB flash drive. Do not store keys on the validator where you intend to use the keys. If your `secret_key` is compromised, [revoke the key](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md#key-revocation) immediately. Do not modify the contents of `validator-keys.json`, except to update the backup after generating a new token. If you generate more than one token from the same backup without updating, the network ignores the later tokens because they use the same `token_sequence` number.
For more information about the `validator-keys` tool and the key pairs it generates, see the [Validator Keys Tool Guide](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md).
3. Generate a validator token using the `create_token` command.
$ validator-keys create_token --keyfile /PATH/TO/YOUR/validator-keys.json
Sample output:
Update rippled.cfg file with these values:
# validator public key: nHUtNnLVx7odrz5dnfb2xpIgbEeJPbzJWfdicSkGyVw1eE5GpjQr
[validator_token]
eyJ2YWxpZGF0aW9uX3NlY3J|dF9rZXkiOiI5ZWQ0NWY4NjYyNDFjYzE4YTI3NDdiNT
QzODdjMDYyNTkwNzk3MmY0ZTcxOTAyMzFmYWE5Mzc0NTdmYT|kYWY2IiwibWFuaWZl
c3QiOiJKQUFBQUFGeEllMUZ0d21pbXZHdEgyaUNjTUpxQzlnVkZLaWxHZncxL3ZDeE
hYWExwbGMyR25NaEFrRTFhZ3FYeEJ3RHdEYklENk9NU1l1TTBGREFscEFnTms4U0tG
bjdNTzJmZGtjd1JRSWhBT25ndTlzQUtxWFlvdUorbDJWMFcrc0FPa1ZCK1pSUzZQU2
hsSkFmVXNYZkFpQnNWSkdlc2FhZE9KYy9hQVpva1MxdnltR21WcmxIUEtXWDNZeXd1
NmluOEhBU1FLUHVnQkQ2N2tNYVJGR3ZtcEFUSGxHS0pkdkRGbFdQWXk1QXFEZWRGdj
VUSmEydzBpMjFlcTNNWXl3TFZKWm5GT3I3QzBrdzJBaVR6U0NqSXpkaXRROD0ifQ==
On your validator:
1. Add `[validator_token]` and its value to your validator's `rippled.cfg` file.
If you previously configured your validator without the `validator-keys` tool, delete `[validation_seed]` and its value from your `rippled.cfg` file. This changes your validator public key.
2. Restart `rippled`.
$ sudo systemctl restart rippled.service
3. Use the `server_info` command to get information about your validator to verify that it is running as a validator.
$ rippled server_info
- The `pubkey_validator` value in the response should match the `public_key` in the `validator-keys.json` file that you generated for use with your validator.
- The `server_state` value should be _**proposing**_.
**Security Tip:** Change the permissions on your `rippled.cfg` file to be more restrictive. On Linux it is recommended to be `0600`. You can do this with `chmod 0600 rippled.cfg`
## 4. Connect to the network
This section describes three different configurations you can use to connect your validator to the XRP Ledger network. Use the configuration that best suits your use case.
- [Discovered peers](#connect-using-discovered-peers): Connect to any servers in the peer-to-peer network.
- [Proxies](#connect-using-proxies): Run stock `rippled` servers as proxies between your validator and the rest of the peer-to-peer network.
- [Public hubs](#connect-using-public-hubs): Connect only to specific public servers with a high reputation.
For a comparison of these approaches, see [Pros and Cons of Peering Configurations](peer-protocol.html#pros-and-cons-of-peering-configurations).
### Connect using discovered peers
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.
### Connect using proxies
This configuration connects your validator to the network through stock `rippled` servers that you run yourself. These proxy servers sit between your validator and inbound and outbound network traffic.
_**To connect your validator to the XRP Ledger network using proxies:**_
1. Set up stock `rippled` servers. For more information, see [Install rippled](install-rippled.html).
2. Configure your validator and stock `rippled` servers to run in a [cluster](cluster-rippled-servers.html).
3. In your validator's `rippled.cfg` file, set `[peer_private]` to `1`. This prevents your validator's IP address from being forwarded. For more information, see [Private Peers](peer-protocol.html#private-peers). It also prevents your validator from connecting to servers other than those defined in the `[ips_fixed]` stanza you defined to run your validator in a cluster.
**Warning:** Be sure that you don't publish your validator's IP address in other ways.
4. Configure your validator host machine's firewall to allow the following traffic only:
- Inbound traffic: Only from IP addresses of the stock `rippled` servers in the cluster you configured.
- Outbound traffic: Only to the IP addresses of the stock `rippled` servers in the cluster you configured and to your UNL list providers through port 443.
5. Restart `rippled`.
$ sudo systemctl restart rippled.service
6. Use the [Peer Crawler](peer-crawler.html) endpoint on one of your stock `rippled` servers. The response should not include your validator. This verifies that your validator's `[peer_private]` configuration is working. One of the effects of enabling `[peer_private]` on your validator is that your validator's peers do not include it in their Peer Crawler results.
$ curl --insecure https://STOCK_SERVER_IP_ADDRESS_HERE:51235/crawl | python3 -m json.tool
<!-- { TODO: Future: add a recommended network architecture diagram to represent the proxy, clustering, and firewall setup: https://ripplelabs.atlassian.net/browse/DOC-2046 }-->
### Connect using public hubs
This configuration connects your validator to the network using three [public hubs](rippled-server-modes.html#public-hubs). This configuration is similar to [connecting using proxies you run yourself](#connect-using-proxies), but instead you connect through public hubs.
_**To connect your validator to the network using public hubs:**_
1. In your validator's `rippled.cfg` file, include the following `[ips_fixed]` stanza. The three values, `r.ripple.com 51235`, `zaphod.alloy.ee 51235` and `sahyadri.isrdc.in 51235`, are default public hubs. This stanza tells `rippled` to always attempt to maintain peer connections with these public hubs.
[ips_fixed]
r.ripple.com 51235
zaphod.alloy.ee 51235
sahyadri.isrdc.in 51235
**Caution:** This configuration connects your validator to the network using default public hubs. Because these are the _default_ public hubs, they may sometimes be too busy to provide your validator with a connection to the network. To help avoid this issue, connect to more public hubs and, even better, connect to non-default public hubs.
You can include the IP addresses of other `rippled` servers here, but _**only**_ if you can expect them to:
- Relay messages without censoring.
- Stay online consistently.
- Not DDoS you.
- Not try to crash your server.
- Not publish your IP address to strangers.
2. Also in your validator's `rippled.cfg` file, include the following `[peer_private]` stanza and set it to `1`. This instructs your validator’s peers not to broadcast your validator’s IP address. This setting also instructs your validator to connect to only the peers configured in your `[ips_fixed]` stanza. This ensures that your validator connects to and shares its IP with only peer `rippled` servers you know and trust.
[peer_private]
1
**Warning:** Be sure that you don't publish your validator's IP address in other ways.
With `[peer_private]` enabled, `rippled` ignores any connections suggested by the `[ips]` stanza. If you need to connect to an IP currently in your `[ips]` stanza, put it in the `[ips_fixed]` stanza instead, but _**only**_ if you can expect them to behave responsibly as described in step 1.
3. Restart `rippled`.
$ sudo systemctl restart rippled.service
## 5. Verify your network connection
Here are some methods you can use to verify that your validator has a healthy connection to the XRP Ledger network:
- Use the [`peers`](peers.html) command to return a list of all `rippled` servers currently connected to your validator. If the `peers` array is `null`, you don’t have a healthy connection to the network. If you've set up your validator using the instructions in this document, the `peers` array should include the same number of objects as the number of peers defined in your `[ips_fixed]` stanza.
If you listed a public hub in your `[ips_fixed]` stanza and it is busy, it may reject your validator's connection. In this case, you may end up with fewer connections than configured in your `[ips_fixed]` stanza. Your validator retries the connection if it's initially rejected.
If you are having trouble maintaining a reliable and safe connection to the network and haven't set up connections using public hubs or proxies, see [4. Connect to the network](#4-connect-to-the-network). Using one of the methods described in the section may help your validator remain healthily connected to the network.
- Use the [`server_info`](server_info.html) command to return some basic information about your validator. The `server_state` should be set to `proposing`. It may also be set to `full` or `validating`, but only for a few minutes before moving into `proposing`.
If the `server_state` does not spend the majority of its time set to `proposing`, it may be a sign that your validator is unable to fully participate in the XRP Ledger network. For more information about server states and using the `server_info` endpoint to diagnose issues with your validator, see [`rippled` Server States](rippled-server-states.html) and [Get the `server_info`](diagnosing-problems.html#get-the-server_info).
- Use the [`validators`](validators.html) command to return the current list of published and trusted validators used by the validator. Ensure that the `validator_list_expires` value is either `never` or not expired or about to expire.
## 6. Provide domain verification
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 one aspect of [being a good validator](#1-understand-the-traits-of-a-good-validator).
To provide domain verification:
1. Choose a domain name you own that you want to be publicly associated with your validator. As a precaution against DDoS attempts, your domain name should not resolve to the ip address of your validator.
2. Serve an [`xrp-ledger.toml`](xrp-ledger-toml.html) file at your domain, and complete the [domain verification](xrp-ledger-toml.html#domain-verification) steps. Once you have completed these steps, your validator should be visible to the livenet [explorer](https://livenet.xrpl.org/network/validators) or any other site that monitors the validator network and supports decetralized domain verification.
3. Share your validator's public key with the public, especially other `rippled` operators. For example, you can share your validator's public key on your website, on social media, in the [XRPChat community forum](https://www.xrpchat.com/), or in a press release.
## Revoke validator keys
If your validator's master private key is compromised, you must revoke it immediately and permanently.
For information about how to revoke a master key pair you generated for your validator using the `validator-keys` tool, see [Key Revocation](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md#key-revocation).
## See Also
- **Concepts:**
- [XRP Ledger Overview](xrp-ledger-overview.html)
- [The `rippled` Server](xrpl-servers.html)
- **Tutorials:**
- [Cluster rippled Servers](cluster-rippled-servers.html)
- [Install `rippled`](install-rippled.html)
- [Capacity Planning](capacity-planning.html)
- **References:**
- [Validator Keys Tool Guide](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md)
- [consensus_info method][]
- [validator_list_sites method][]
- [validators method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

62
content/infrastructure/rippled/configuration/run-rippled-as-a-wallet-server.ja.md Normal file
View File

@@ -0,0 +1,62 @@
---
html: run-rippled-as-a-stock-server.html
parent: server-modes.html
blurb: XRPを統合する人のための汎用的な構成。
labels:
- コアサーバー
---
# ウォレットサーバーとしてrippledを実行する
ウォレットサーバーは `rippled` のための汎用的な構成です。ウォレットサーバーを利用することで、XRP Ledger へのトランザクションの送信、レジャーの履歴へのアクセス、XRP と統合するための最新の [ツール](software-ecosystem.html) を利用することができます。
ウォレットサーバーは、次のすべてのことを行います。
- [ピアネットワーク](peer-protocol.html)に接続
- 暗号署名された[トランザクション](transactions.html)を中継
- 完全な共有グローバル[レジャー](ledgers.html)のローカルコピーを維持
- [コンセンサスプロセス](consensus.html)にバリデーターとして参加
## 1. `rippled` のインストール
詳しくは、[`rippled` のインストール](install-rippled.html) を参照してください。
## 2. ウォレットサーバーでのバリデーションを有効にする
詳しくは、[rippledサーバーで検証を有効化](run-rippled-as-a-validator.html#3-enable-validation-on-your-rippled-server) を参照してください。
**注意:** バリデーターは、一般にアクセスできないようにする必要があります。ウォレットサーバーへのWebSocketアクセスなど、一般からのアクセスを許可しないでください。
## 3. ドメイン検証の提供
詳しくは、[ドメイン検証の提供](run-rippled-as-a-validator.html#6-provide-domain-verification)をご覧ください。
## トラブルシューティング
詳しくは、[`rippled`のトラブルシューティング](troubleshoot-the-rippled-server.html) を参照してください。
## 関連項目
- **コンセプト:**
- [XRP Ledgerの概要](xrp-ledger-overview.html)
- [`rippled`サーバー](xrpl-servers.html)
- **チュートリアル:**
- [rippledサーバーのクラスター化](cluster-rippled-servers.html)
- [`rippled`のインストール](install-rippled.html)
- [容量の計画](capacity-planning.html)
- **リファレンス:**
- [Validator Keysツールガイド](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md)
- [consensus_infoメソッド][]
- [validator_list_sitesメソッド][]
- [validatorsメソッド][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

26
content/infrastructure/rippled/configuration/test-amendments.md Normal file
View File

@@ -0,0 +1,26 @@
---
html: test-amendments.html
parent: configure-rippled.html
blurb: You can test proposed amendments before they're enabled on the network.
labels:
- Blockchain
---
# Test Amendments
You can test how `rippled` behaves before proposed amendments are fully enabled on the production network. Since other members of the consensus network won't have the feature enabled, run your server in stand-alone mode.
**Caution:** This is intended for development purposes only.
To forcibly enable a feature, add a `[features]` stanza with amendment short names to your `rippled.cfg` file. Each amendment needs its own line.
<!-- MULTICODE_BLOCK_START -->
_Example_
```
[features]
MultiSign
TrustSetAuth
```
<!-- MULTICODE_BLOCK_END -->

94
content/infrastructure/rippled/configure-peering/cluster-rippled-servers.ja.md Normal file
View File

@@ -0,0 +1,94 @@
---
html: cluster-rippled-servers.html
parent: configure-peering.html
blurb: サーバーのグループで処理を分担するように設定して効率化します。
labels:
- コアサーバー
---
# rippledサーバーのクラスター化
1つのデータセンターで複数の`rippled`サーバーを稼働している場合は、これらのサーバーを[クラスター](clustering.html)に構成して、効率を最大化できます。クラスター構成の設定は次のとおりです。
1. 各サーバーのIPアドレスをメモします。
2. [validation_createメソッド][]を使用して各サーバーの一意のシードを生成します。
コマンドラインインターフェイスを使用する場合の例を以下に示します。
$ rippled validation_create
Loading: "/etc/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result" : {
"status" : "success",
"validation_key" : "FAWN JAVA JADE HEAL VARY HER REEL SHAW GAIL ARCH BEN IRMA",
"validation_public_key" : "n9Mxf6qD4J55XeLSCEpqaePW4GjoCR5U1ZeGZGJUCNe3bQa4yQbG",
"validation_seed" : "ssZkdwURFMBXenJPbrpE14b6noJSu"
}
}
各応答の`validation_seed`パラメーターと`validation_public_key`パラメーターを安全な場所に保存します。
3. 各サーバーで[構成ファイル](https://github.com/ripple/rippled/blob/master/cfg/rippled-example.cfg)を編集し、以下のセクションを変更します。
1. `[ips_fixed]`セクションに、クラスターの _その他の_ 各メンバーのIPアドレスとポートを記入します。各サーバーのポート番号は、サーバーの `rippled.cfg`に指定されている`protocol = peer`ポート（通常は51235）と一致している必要があります。例:
[ips_fixed]
192.168.0.1 51235
192.168.0.2 51235
この例では、このサーバーがダイレクトピアツーピア接続の維持を常に試みる先のピアサーバーを特定しています。
2. `[node_seed]`セクションでは、サーバーのノードシードを、ステップ2で[validation_createメソッド][]を使用して生成した`validation_seed`の値の1つに設定します。各サーバーは一意のノードシードを使用する必要があります。例:
[node_seed]
ssZkdwURFMBXenJPbrpE14b6noJSu
この例では、ピアツーピア通信（検証メッセージを除く）の署名にサーバーが使用するキーペアを定義しています。
3. `[cluster_nodes]`セクションでは、サーバーのクラスターのメンバーを設定します。これらのメンバーは`validation_public_key`の値で識別されます。各サーバーのクラスターの _その他の_ すべてのメンバーをここに記入する必要があります。任意で、各サーバーのカスタム名を追加します。例:
[cluster_nodes]
n9McNsnzzXQPbg96PEUrrQ6z3wrvgtU4M7c97tncMpSoDzaQvPar keynes
n94UE1ukbq6pfZY9j54sv2A1UrEeHZXLbns3xK5CzU9NbNREytaa friedman
この例は、サーバーがクラスターのメンバーを認識するために使用するキーペアを定義しています。
4. 構成ファイルを保存した後、各サーバーで`rippled`を再起動します。
# systemctl restart rippled
5. 各サーバーがクラスターのメンバーになっていることを確認するには、[peersメソッド][]を使用します。`cluster`フィールドに、各サーバーの公開鍵とカスタム名（構成している場合）のリストが表示されます。
コマンドラインインターフェイスを使用する場合の例を以下に示します。
$ rippled peers
Loading: "/etc/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result" : {
"cluster" : {
"n9McNsnzzXQPbg96PEUrrQ6z3wrvgtU4M7c97tncMpSoDzaQvPar": {
"tag": "keynes",
"age": 1
},
"n94UE1ukbq6pfZY9j54sv2A1UrEeHZXLbns3xK5CzU9NbNREytaa": {
"tag": "friedman",
"age": 1
}
},
"peers" : [
...(omitted) ...
],
"status" : "success"
}
}
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

104
content/infrastructure/rippled/configure-peering/cluster-rippled-servers.md Normal file
View File

@@ -0,0 +1,104 @@
---
html: cluster-rippled-servers.html
parent: configure-peering.html
blurb: Set up a group of servers that share work for higher efficiency.
labels:
- Core Server
---
# Cluster rippled Servers
If you run multiple [`rippled` servers](xrpl-servers.html) in the same data center, you can configure them in a [cluster](clustering.html) to maximize efficiency. To configure clustering:
1. For each of your servers, note the IP address of the server.
2. For each of your servers, generate a unique seed using the [validation_create method][].
For example, using the commandline interface:
$ rippled validation_create
Loading: "/etc/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result" : {
"status" : "success",
"validation_key" : "FAWN JAVA JADE HEAL VARY HER REEL SHAW GAIL ARCH BEN IRMA",
"validation_public_key" : "n9Mxf6qD4J55XeLSCEpqaePW4GjoCR5U1ZeGZGJUCNe3bQa4yQbG",
"validation_seed" : "ssZkdwURFMBXenJPbrpE14b6noJSu"
}
}
Save the `validation_seed` and `validation_public_key` parameters from each response somewhere secure.
3. On each server, edit the [config file](https://github.com/ripple/rippled/blob/master/cfg/rippled-example.cfg), modifying the following sections:
1. In the `[ips_fixed]` section, list the IP address and port of each _other_ member of the cluster. For each of those servers, the port number should match the `protocol = peer` port (usually 51235) from that server's `rippled.cfg`. For example:
[ips_fixed]
192.168.0.1 51235
192.168.0.2 51235
This defines specific peer servers to which this server should always attempt to maintain a direct peer-to-peer connection.
**Note:** If you omit the port number, the server uses port 2459, the IANA-assigned port for the XRP Ledger protocol.
2. In the `[node_seed]` section, set the server's node seed to one of the `validation_seed` values you generated using the [validation_create method][] in step 2. Each server must use a unique node seed. For example:
[node_seed]
ssZkdwURFMBXenJPbrpE14b6noJSu
This defines the key pair the server uses to sign peer-to-peer communications, excluding validation messages.
3. In the `[cluster_nodes]` section, set the members of the server's cluster, identified by their `validation_public_key` values. Each server should list the public keys of all _other_ members of the cluster here. Optionally, add a custom name for each server. For example:
[cluster_nodes]
n9McNsnzzXQPbg96PEUrrQ6z3wrvgtU4M7c97tncMpSoDzaQvPar keynes
n94UE1ukbq6pfZY9j54sv2A1UrEeHZXLbns3xK5CzU9NbNREytaa friedman
This defines the key pairs the server uses to recognize members of its cluster.
4. After saving the config file, restart `rippled` on each server.
# systemctl restart rippled
5. To confirm that each server is now a member of the cluster, use the [peers method][]. The `cluster` field should list the public keys and (if configured) the custom names for each server.
For example, using the commandline interface:
$ rippled peers
Loading: "/etc/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result" : {
"cluster" : {
"n9McNsnzzXQPbg96PEUrrQ6z3wrvgtU4M7c97tncMpSoDzaQvPar": {
"tag": "keynes",
"age": 1
},
"n94UE1ukbq6pfZY9j54sv2A1UrEeHZXLbns3xK5CzU9NbNREytaa": {
"tag": "friedman",
"age": 1
}
},
"peers" : [
... (omitted) ...
],
"status" : "success"
}
}
## See Also
- **Concepts:**
- [Peer Protocol](peer-protocol.html)
- **Tutorials:**
- [Install rippled](install-rippled.html)
- **References:**
- [validation_create method][]
- [peers method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

98
content/infrastructure/rippled/configure-peering/configure-a-private-server.ja.md Normal file
View File

@@ -0,0 +1,98 @@
---
html: configure-a-private-server.html
parent: configure-peering.html
blurb: サーバーが特定の信頼できるピアのみに接続するように設定します。
labels:
- コアサーバー
- セキュリティ
---
# プライベートサーバーの設定
[プライベートサーバー](peer-protocol.html#プライベートピア)は、オープンなピアツーピアネットワーク内の検出されたピアに直接接続するのではなく、特定の信頼できるピアのみを通じてネットワークに接続する`rippled`サーバーです。この種の構成は、[バリデータ](run-rippled-as-a-validator.html)に一般的に推奨される任意の対策ですが、その他の特定の目的でも役立ちます。
## 前提条件
プライベートサーバーを使用するには、次の前提条件を満たしている必要があります。
- [`rippled`をインストール](install-rippled.html)して最新バージョンにアップデートし、まだ実行していない状態である必要があります。
- 自社で運用している**プロキシ**を通じて接続するか、**公開ハブ**を通じて接続するかを決める必要があります。これらの選択肢の違いについては、[ピアリング構成のメリットとデメリット](peer-protocol.html#ピア接続設定のメリットとデメリット)を参照してください。
- プロキシを使用している場合、`rippled`がインストールされていてプロキシとして使用し実行される別のマシンが必要です。これらのサーバーは、外部のネットワークとプライベートサーバーに接続できる必要があります。
- どちらの構成でも、接続先のピアのIPアドレスとポートを把握しておく必要があります。
## 手順
特定のサーバーをプライベートピアとして設定するには、次の手順を実行します。
1. `rippled`の構成ファイルを編集します。
vim /etc/opt/ripple/rippled.cfg
{% include '_snippets/conf-file-location.md' %}<!--_ -->
2. プライベートピアリングを有効にします。
構成ファイルに以下のスタンザを追加するか、コメントを解除します。
[peer_private]
1
3. 固定数のピアを追加します。
構成ファイルに`[ips_fixed]`スタンザを追加するか、コメントを解除します。このスタンザの各行は、接続先のピアのホスト名またはIPアドレス、1個の空白文字、このピアがピアプロトコル接続を受け付けるポートの順に記載されている必要があります。
例えば、**公開ハブ**を使用して接続する場合は、以下のスタンザを使用できます。
[ips_fixed]
r.ripple.com 51235
zaphod.alloy.ee 51235
サーバーが**プロキシ**を使用して接続している場合は、IPアドレスとポートが、プロキシとして使用している`rippled`サーバーの構成と一致している必要があります。これらの各サーバーについては、ポート番号が、サーバーの構成ファイルに記載されている`protocol = peer`ポート（通常は51235）と一致している必要があります。例えば、構成は次のようになります。
[ips_fixed]
192.168.0.1 51235
192.168.0.2 51235
4. プロキシを使用している場合、プロキシをプライベートピアと互いを含めてクラスター化します。
公開ハブを使用している場合は、このステップをスキップします。
プロキシを使用している場合、プライベートピアを含む[クラスターとしてプロキシを構成](cluster-rippled-servers.html)します。クラスターの各メンバーは、クラスターの_他の_各メンバーをリストにした`[ips_fixed]`スタンザを持っている必要があります。ただし、`[peer_private]`スタンザを持つのは**プライベートサーバーのみ**とします。
各プロキシで`rippled`を再起動します。各プロキシサーバーで、次のようにします。
sudo service systemctl restart rippled
5. プライベートサーバーで`rippled`を起動します。
sudo service systemctl start rippled
6. [peersメソッド][]を使用して、プライベートサーバーが自身のピアに _のみ_ 接続していることを確認します。
応答の`peers`配列に、構成済みのピアのいずれでもない`address`を持つオブジェクトが含まれていてはなりません。含まれている場合は、構成ファイルを再度確認して、プライベートサーバーを再起動します。
## 次のステップ
追加の予防対策として、自身のピアでないサーバーからプライベートサーバーへの着信接続をブロックするようにファイアウォールを設定する必要があります。プロキシサーバーを実行している場合は、ファイヤーウォールを通じてプロキシに[ピアポートを転送](forward-ports-for-peering.html)するようにします。ただし、プライベートピアで**ない**ものに転送します。この設定方法の具体的な手順は、使用するファイアウォールによって異なります。
ファイアウォールがポート80で発信HTTP接続を**ブロックしない**ことを確認します。デフォルトの設定では、このポートを使用して**vl.ripple.com**から最新の推奨バリデータリストをダウンロードします。バリデータリストがないと、サーバーはどのバリデータを信頼してよいかわからず、ネットワークが、いつコンセンサスに至ったかを認識できません。
## 関連項目
- **コンセプト:**
- [ピアプロトコル](peer-protocol.html)
- [コンセンサス](consensus.html)
- [並列ネットワーク](parallel-networks.html)
- **チュートリアル:**
- [ピアクローラーの設定](configure-the-peer-crawler.html)
- **リファレンス:**
- [peersメソッド][]
- [connectメソッド][]
- [fetch_infoメソッド][]
- [ピアクローラー](peer-crawler.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

100
content/infrastructure/rippled/configure-peering/configure-a-private-server.md Normal file
View File

@@ -0,0 +1,100 @@
---
html: configure-a-private-server.html
parent: configure-peering.html
blurb: Set up a server to connect only to specific, trusted peers.
labels:
- Core Server
- Security
---
# Configure a Private Server
A [private server](peer-protocol.html#private-peers) is a `rippled` server that connects to the network only through specific, trusted peers instead of connecting directly to discovered peers in the open peer-to-peer network. This kind of configuration is an optional precaution most commonly recommended for [validators](run-rippled-as-a-validator.html), but it can be useful for other specific purposes.
## Prerequisites
To use a private server, you must meet the following requirements:
- You must have [`rippled` installed](install-rippled.html) and updated to the latest version, but not running yet.
- You must decide whether to connect through **proxies** you run yourself, or through **public hubs**. For a comparison of these options, see [Pros and Cons of Peering Configurations](peer-protocol.html#pros-and-cons-of-peering-configurations).
- If you are using proxies, you must have additional machines with `rippled` installed and running to use as the proxies. These servers must be able to connect to the outside network and to your private server.
- For either configuration, you must know the IP addresses and ports of the peers you intend to connect to.
## Steps
To set up a specific server as a private peer, complete the following steps:
1. Edit your `rippled`'s config file.
vim /etc/opt/ripple/rippled.cfg
{% include '_snippets/conf-file-location.md' %}<!--_ -->
2. Enable private peering.
Add or uncomment the following stanza in your config file:
[peer_private]
1
3. Add fixed peers.
Add or uncomment an `[ips_fixed]` stanza in your config file. Each line in this stanza should be the hostname or IP address of a peer to connect to, followed by a space and the port where this peer accepts peer protocol connections.
For example, to connect using **public hubs**, you could use the following stanza:
[ips_fixed]
r.ripple.com 51235
zaphod.alloy.ee 51235
If your server connects using **proxies**, the IP addresses and ports should match the configurations of the `rippled` servers you are using as proxies. For each of those servers, the port number should match the `protocol = peer` port in that server's config file (usually 51235). For example, your configuration might look like this:
[ips_fixed]
192.168.0.1 51235
192.168.0.2 51235
**Note:** If you omit the port number, the server uses port 2459, the IANA-assigned port for the XRP Ledger protocol.
4. If using proxies, cluster them with your private peer and each other.
If you are using public hubs, skip this step.
If you are using proxies, [configure the proxies as a cluster](cluster-rippled-servers.html) that includes your private peer. Each member of the cluster should have an `[ips_fixed]` stanza that lists each _other_ member of the cluster. However, **only the private server** should have a `[peer_private]` stanza.
Restart `rippled` on the proxies one-by-one. On each proxy server:
sudo service systemctl restart rippled
5. Start `rippled` on the private server.
sudo service systemctl start rippled
6. Use the [peers method][] to confirm that your private server is connected _only_ to its peers.
The `peers` array in the response should not contain any objects whose `address` is not one of your configured peers. If this is not the case, double-check your config file and restart the private server.
## Next Steps
As an additional precaution, you should configure your firewall to block incoming connections to your private server from servers that are not your specific peers. If you are running proxy servers, [forward peer ports](forward-ports-for-peering.html) through your firewall to the proxies, but **not** to the private peer. The exact details of how to configure this depend on what firewall you use.
Be sure the firewall **does not block** outgoing HTTP connections on port 80. The default configuration uses this port to download the latest recommended validator list from **vl.ripple.com**. Without a validator list, the server does not know which validators to trust and cannot recognize when the network reaches a consensus.
## See Also
- **Concepts:**
- [Peer Protocol](peer-protocol.html)
- [Consensus](consensus.html)
- [Parallel Networks](parallel-networks.html)
- **Tutorials:**
- [Configure the Peer Crawler](configure-the-peer-crawler.html)
- **References:**
- [peers method][]
- [connect method][]
- [fetch_info method][]
- [Peer Crawler](peer-crawler.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

14
content/infrastructure/rippled/configure-peering/configure-peering.ja.md Normal file
View File

@@ -0,0 +1,14 @@
---
html: configure-peering.html
name: Peering
parent: infrastructure.html
template: pagetype-category.html.jinja
blurb: サーバーをピアツーピアネットワークに接続する方法を設定します。
labels:
- コアサーバー
---
# ピアリングの設定
XRP Ledgerのピアツーピアプロトコルは、ほとんどの場合、ピア接続を自動的に管理します。場合によっては、サーバーが接続するピアを手動で調整して、サーバーの可用性とネットワークの他の部分との接続性を最大限に高めたいというケースがあります。
同じデータセンター内で複数のサーバーを稼動させている場合は、[クラスター化](cluster-rippled-servers.html)して効率を向上させたいケースがあります。ピアツーピアネットワークのトポロジー内の重要なハブなど、稼動していないが接続を維持したいサーバー用の予約済みピアスロットを使うことができます。他のピアについては、サーバーはピアを自動検出し、その接続を管理しますが、望ましくない動作をするピアをブロックするように手動で介入することもできます。

14
content/infrastructure/rippled/configure-peering/configure-peering.md Normal file
View File

@@ -0,0 +1,14 @@
---
html: configure-peering.html
name: Peering
parent: infrastructure.html
template: pagetype-category.html.jinja
blurb: Configure how your server connects to the peer-to-peer network.
labels:
- Core Server
---
# Configure Peering
The XRP Ledger's peer-to-peer protocol automatically manages peer connections in most cases. In some cases, you may want to manually adjust which peers your server connects to, to maximize your server's availability and connectivity with the rest of the network.
If you run multiple servers in the same datacenter, you may want [to cluster them](cluster-rippled-servers.html) to improve efficiency. You can use reserved peer slots for servers you don't run but want to stay connected to, such as important hubs in the topology of the peer-to-peer network. For other peers, the server can automatically find peers and manage its connections, although you may occasionally want to intervene to block a peer that's behaving undesirably.

79
content/infrastructure/rippled/configure-peering/configure-the-peer-crawler.md Normal file
View File

@@ -0,0 +1,79 @@
---
html: configure-the-peer-crawler.html
parent: configure-peering.html
blurb: Configure how much information your rippled server reports publicly about its status and peers.
labels:
- Core Server
- Security
---
# Configure the Peer Crawler
By default, [`rippled` servers](xrpl-servers.html) provide statistics publicly to anyone who asks using the [peer crawler API](peer-crawler.html), to make it easier to track the health and topology of [the XRP Ledger's peer-to-peer network](peer-protocol.html). You can configure your server to provide more or less information, or to reject peer crawler requests entirely.
This document contains steps for two options:
- [Change the Information Reported by the Peer Crawler](#change-the-information-reported-by-the-peer-crawler)
- [Disable the Peer Crawler](#disable-the-peer-crawler)
## Change the Information Reported by the Peer Crawler
To configure how much information your server provides in response to peer crawler requests, complete the following steps:
1. Edit your `rippled`'s config file.
vim /etc/opt/ripple/rippled.cfg
{% include '_snippets/conf-file-location.md' %}<!--_ -->
2. Add or update the `[crawl]` stanza in your config file, and save the changes:
[crawl]
overlay = 1
server = 1
counts = 0
unl = 1
The fields in this stanza control which fields the server returns in the [peer crawler response](peer-crawler.html#response-format). The names of the config fields match the fields of the API response. A setting with a value of `1` means to include the field in the response. A value of `0` means to omit that field from the response. This example shows the default values for each setting.
3. After saving the changes to the config file, restart your `rippled` server to apply the updated configuration:
systemctl restart rippled
## Disable the Peer Crawler
To disable the peer crawler API on your server, so it does not respond to peer crawler requests at all, complete the following steps:
1. Edit your `rippled`'s config file.
vim /etc/opt/ripple/rippled.cfg
{% include '_snippets/conf-file-location.md' %}<!--_ -->
2. Add or update the `[crawl]` stanza in your config file, and save the changes:
[crawl]
0
Remove or comment out all other contents of the crawl stanza.
3. After saving the changes to the config file, restart your `rippled` server to apply the updated configuration:
systemctl restart rippled
## See Also
- **Concepts:**
- [Peer Protocol](peer-protocol.html)
- **Tutorials:**
- [Manage the rippled Server](manage-the-rippled-server.html)
- **References:**
- [server_info method][]
- [peers method][]
- [Peer Crawler](peer-crawler.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

51
content/infrastructure/rippled/configure-peering/enable-link-compression.md Normal file
View File

@@ -0,0 +1,51 @@
---
html: enable-link-compression.html
parent: configure-peering.html
blurb: Save bandwidth by compressing peer-to-peer communications.
labels:
- Core Server
---
# Enable Link Compression
The `rippled` server can save bandwidth by compressing its [peer-to-peer communications](peer-protocol.html), at a cost of greater CPU usage. If you enable link compression, the server automatically compresses communications with peer servers that also have link compression enabled.
## Steps
To enable link compression on your server, complete the following steps:
### 1. Edit your `rippled` server's config file.
```sh
$ vim /etc/opt/ripple/rippled.cfg
```
{% include '_snippets/conf-file-location.md' %}<!--_ -->
### 2. In the config file, add or uncomment the `[compression]` stanza.
To enable compression:
```text
[compression]
true
```
Use `false` to disable compression (the default).
### 3. Restart the `rippled` server
```sh
$ sudo systemctl restart rippled.service
```
After the restart, your server automatically uses link compression with other peers that also have link compression enabled.
## See Also
- [Capacity Planning](capacity-planning.html)
- [Peer Protocol](peer-protocol.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

66
content/infrastructure/rippled/configure-peering/forward-ports-for-peering.ja.md Normal file
View File

@@ -0,0 +1,66 @@
---
html: forward-ports-for-peering.html
parent: configure-peering.html
blurb: 受信ピアがrippledサーバーに接続できるようにファイアウォールを設定します。
labels:
- コアサーバー
---
# ピアリングのポート転送
XRP Ledgerのピアツーピアネットワーク内にあるサーバーは、[ピアプロトコル](peer-protocol.html)を介して通信します。セキュリティとネットワークの他の部分との接続を両立させるために、ファイアウォールを使用して、サーバーをほとんどのポートから保護し、ピアプロトコルポートだけを開放するか転送するようにする必要があります。
`rippled`サーバーの稼動中に、[server_infoメソッド][]を実行すると、いくつのピアがあるか確認することができます。`info`オブジェクトの`peers`フィールドは、サーバーに現在接続しているピアの数を示します。この数が10または11の場合、通常はファイアウォールが着信接続をブロックしていることを示します。
ファイアウォールが着信ピア接続をブロックしていると思われるためピアが10個しかないことを示している`server_info`の結果の例（一部省略）は次のとおりです。
```json
$ ./rippled server_info
Loading: "/etc/opt/ripple/rippled.cfg"
2019-Dec-23 22:15:09.343961928 HTTPClient:NFO Connecting to 127.0.0.1:5005
{
"result" : {
"info" : {
...（省略）...
"load_factor" : 1,
"peer_disconnects" : "0",
"peer_disconnects_resources" : "0",
"peers" : 10,
"pubkey_node" : "n9KUjqxCr5FKThSNXdzb7oqN8rYwScB2dUnNqxQxbEA17JkaWy5x",
"pubkey_validator" : "n9KM73uq5BM3Fc6cxG3k5TruvbLc8Ffq17JZBmWC4uP4csL4rFST",
"published_ledger" : "none",
"server_state" : "connected",
...（省略）...
},
"status" : "success"
}
}
```
着信接続を許可するために、ピアプロトコルポートを転送するようにファイアウォールを設定します。ピアプロトコルポートは、デフォルトの構成ファイルでは**ポート51235**で提供されます。ポートの転送の手順はファイアウォールによって異なります。例えば、Red Hat Enterprise Linuxで`firewalld`ソフトウェアファイアウォールを使用している場合は、[`firewall-cmd`ツールを使用](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-port_forwarding)して、TCPトラフィックを次のように転送します。
```sh
$ sudo firewall-cmd --add-forward-port=port=51235:proto=tcp:toport=51235
```
その他のソフトウェアファイアウォールとハードウェアファイアウォールについては、メーカー公式のドキュメントを参照してください。
## 関連項目
- **コンセプト:**
- [ピアプロトコル](peer-protocol.html)
- [`rippled`サーバー](xrpl-servers.html)
- **チュートリアル:**
- [容量の計画](capacity-planning.html)
- [`rippled`サーバーのトラブルシューティング](troubleshoot-the-rippled-server.html)
- **リファレンス:**
- [connectメソッド][]
- [peersメソッド][]
- [printメソッド][]
- [server_infoメソッド][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

84
content/infrastructure/rippled/configure-peering/forward-ports-for-peering.md Normal file
View File

@@ -0,0 +1,84 @@
---
html: forward-ports-for-peering.html
parent: configure-peering.html
blurb: Configure your firewall to allow incoming peers to your rippled server.
labels:
- Core Server
---
# Forward Ports for Peering
Servers in the XRP Ledger peer-to-peer network communicate over the [peer protocol](peer-protocol.html). For the best combination of security and connectivity to the rest of the network, you should use a firewall to protect your server from most ports, but open or forward the peer protocol port.
While your `rippled` server is running, you can check to see how many peers you have by running the [server_info method][]. The `peers` field of the `info` object shows how many peers are currently connected to your server. If this number is exactly 10 or 11, that usually means your firewall is blocking incoming connections.
Example of a `server_info` result (trimmed) showing only 10 peers, likely because a firewall is blocking incoming peer connections:
```json
$ ./rippled server_info
Loading: "/etc/opt/ripple/rippled.cfg"
2019-Dec-23 22:15:09.343961928 HTTPClient:NFO Connecting to 127.0.0.1:5005
{
"result" : {
"info" : {
... (trimmed) ...
"load_factor" : 1,
"peer_disconnects" : "0",
"peer_disconnects_resources" : "0",
"peers" : 10,
"pubkey_node" : "n9KUjqxCr5FKThSNXdzb7oqN8rYwScB2dUnNqxQxbEA17JkaWy5x",
"pubkey_validator" : "n9KM73uq5BM3Fc6cxG3k5TruvbLc8Ffq17JZBmWC4uP4csL4rFST",
"published_ledger" : "none",
"server_state" : "connected",
... (trimmed) ...
},
"status" : "success"
}
}
```
To allow incoming connections, configure your firewall to allow incoming traffic on the peer protocol port, which is served on **port 51235** in the default config file. The instructions to open a port depend on your firewall. If your server is behind a router that performs Network Address Translation (NAT), you must configure your router to forward the port to your server.
If you use the `firewalld` software firewall on Red Hat Enterprise Linux, you can [use the `firewall-cmd` tool](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-using_zones_to_manage_incoming_traffic_depending_on_source) to open **port 51235** to all incoming traffic.
_Assuming `--zone=public` is your public [zone](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-working_with_zones#sec-Listing_Zones)._
```sh
$ sudo firewall-cmd --zone=public --add-port=51235/tcp
```
Then, restart the `rippled` server:
```sh
$ sudo systemctl restart rippled.service
```
To make it permanent:
```sh
$ sudo firewall-cmd --zone=public --permanent --add-port=51235/tcp
```
For other software and hardware firewalls, see the manufacturer's official documentation.
If you are using a hosting service with a virtual firewall (for example, [AWS Security Groups](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)), you do not need to use `firewalld`, but you still need to allow inbound traffic from the open internet on the peer port. Make sure you apply the relevant rules to your host or virtual machine.
## See Also
- **Concepts:**
- [Peer Protocol](peer-protocol.html)
- [The `rippled` Server](xrpl-servers.html)
- **Tutorials:**
- [Capacity Planning](capacity-planning.html)
- [Troubleshoot the `rippled` Server](troubleshoot-the-rippled-server.html)
- **References:**
- [connect method][]
- [peers method][]
- [print method][]
- [server_info method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

79
content/infrastructure/rippled/configure-peering/manually-connect-to-a-specific-peer.ja.md Normal file
View File

@@ -0,0 +1,79 @@
---
html: manually-connect-to-a-specific-peer.html
parent: configure-peering.html
blurb: rippledサーバーを特定のピアに接続します。
labels:
- コアサーバー
---
# 特定のピアへの手動接続
サーバーをXRP Ledgerネットワーク内の特定の[ピア](peer-protocol.html)に手動で接続するには、次の手順を実行します。
**ヒント:** サーバーが起動時にこのサーバーに自動的に接続して、以降も接続を維持するようにするには、そのピアに対して[ピアリザベーション](use-a-peer-reservation.html)を設定することができます。
## 前提条件
- 接続先のピアのIPアドレスを把握しておく必要があります。
- 接続先のピアがXRP Ledger[ピアプロトコル](peer-protocol.html)に使用するポートを把握しておく必要があります。デフォルトでは、ポート51235です。
- サーバーからピアへのネットワーク接続を用意する必要があります。例えば、ピアサーバーは[ファイアウォールを通じて適切なポートを転送する](forward-ports-for-peering.html)必要があります。
- ピアサーバーに使用可能なピアスロットがある必要があります。ピアがすでにピアの最大数に達している場合、ピアサーバーのオペレーターに依頼して、サーバーの[ピアリザベーション](use-a-peer-reservation.html)を追加してもらいます。
## 手順
接続するには、[connectメソッド][]を使用します。例:
<!-- MULTICODE_BLOCK_START -->
*WebSocket*
```
{
"command": "connect",
"ip": "169.54.2.151",
"port": 51235
}
```
*JSON-RPC*
```
{
"method": "connect",
"params": [
{
"ip": "169.54.2.151",
"port": 51235
}
]
}
```
*コマンドライン*
```
rippled connect 169.54.2.151 51235
```
<!-- MULTICODE_BLOCK_END -->
## 関連項目
- **コンセプト:**
- [ピアプロトコル](peer-protocol.html)
- [`rippled`サーバー](xrpl-servers.html)
- **チュートリアル:**
- [容量の計画](capacity-planning.html)
- [`rippled`サーバーのトラブルシューティング](troubleshoot-the-rippled-server.html)
- **リファレンス:**
- [connectメソッド][]
- [peersメソッド][]
- [printメソッド][]
- [server_infoメソッド][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

79
content/infrastructure/rippled/configure-peering/manually-connect-to-a-specific-peer.md Normal file
View File

@@ -0,0 +1,79 @@
---
html: manually-connect-to-a-specific-peer.html
parent: configure-peering.html
blurb: Connect your rippled server to a specific peer.
labels:
- Core Server
---
# Manually Connect to a Specific Peer
Use these steps to manually connect your server to a specific [peer](peer-protocol.html) in the XRP Ledger network.
**Tip:** If you want to make sure your server automatically connects to this server on startup and remains connected later, you may want to configure a [peer reservation](use-a-peer-reservation.html) for that peer.
## Prerequisites
- 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). The default config file uses port 51235.
- 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
To connect, use the [connect method][]. For example:
<!-- MULTICODE_BLOCK_START -->
*WebSocket*
```
{
"command": "connect",
"ip": "169.54.2.151",
"port": 51235
}
```
*JSON-RPC*
```
{
"method": "connect",
"params": [
{
"ip": "169.54.2.151",
"port": 51235
}
]
}
```
*Commandline*
```
rippled connect 169.54.2.151 51235
```
<!-- MULTICODE_BLOCK_END -->
## See Also
- **Concepts:**
- [Peer Protocol](peer-protocol.html)
- [The `rippled` Server](xrpl-servers.html)
- **Tutorials:**
- [Capacity Planning](capacity-planning.html)
- [Troubleshoot the `rippled` Server](troubleshoot-the-rippled-server.html)
- **References:**
- [connect method][]
- [peers method][]
- [print method][]
- [server_info method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

55
content/infrastructure/rippled/configure-peering/set-max-number-of-peers.ja.md Normal file
View File

@@ -0,0 +1,55 @@
---
html: set-max-number-of-peers.html
parent: configure-peering.html
blurb: rippledサーバーが接続するピアの最大数を設定します。
labels:
- コアサーバー
---
# ピアの最大数の設定
`rippled`サーバーには、接続先の[ピア](peer-protocol.html)の数を定める設定可能なソフト最大数があります。ピアのデフォルトの最大数は**21**です。
**注記:** 内部的に、サーバーは受信ピアと送信ピアのおおよそのクォータを生成します。[固定ピアやピアリザベーション](peer-protocol.html#固定ピアとピアリザベーション)を使用している場合、あるいは[connectメソッド][]を使用して追加のピアに手動で接続している場合は、このソフト最大数を超える可能性があります。
サーバーが許可するピアの最大数を変更するには、以下の手順を実行します。
1. `rippled`の構成ファイルを編集します。
$ vim /etc/opt/ripple/rippled.cfg
{% include '_snippets/conf-file-location.md' %}<!--_ -->
2. 構成ファイルで、`[peers_max]`スタンザのコメントを解除して編集するか、まだない場合は追加します。
[peers_max]
30
スタンザの内容は、許可するピアの合計数を示す整数のみである必要があります。デフォルトでは、サーバーは受信ピアが約85%、送信ピアが約15%という比率を維持するように試みますが、送信ピアの最小数が10であるため、68未満の値にしても、サーバーが行う送信ピア接続の数は増えません。
`[peers_max]`値を10未満にした場合でも、サーバーはハードコーディングされた最小数である10台の送信ピアを許可するため、ネットワークとの接続を維持できます。すべての送信ピア接続をブロックするには、[サーバーをプライベートピアとして設定](run-rippled-as-a-validator.html#プロキシを使用した接続)します。
**注意:** 接続先のピアサーバーが増えると、`rippled`サーバーが使用するネットワーク帯域幅も増えます。`rippled`サーバーに良好なネットワーク接続があり、使用する帯域幅のコストを許容できる場合にのみ、ピアサーバーの数に大きな値を設定してください。
3. `rippled`サーバーを再起動します。
$ sudo systemctl restart rippled.service
## 関連項目
- **コンセプト:**
- [ピアプロトコル](peer-protocol.html)
- [`rippled`サーバー](xrpl-servers.html)
- **チュートリアル:**
- [容量の計画](capacity-planning.html)
- [`rippled`サーバーのトラブルシューティング](troubleshoot-the-rippled-server.html)
- **リファレンス:**
- [connectメソッド][]
- [peersメソッド][]
- [printメソッド][]
- [server_infoメソッド][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

55
content/infrastructure/rippled/configure-peering/set-max-number-of-peers.md Normal file
View File

@@ -0,0 +1,55 @@
---
html: set-max-number-of-peers.html
parent: configure-peering.html
blurb: Set the maximum number of peers your rippled server connects to.
labels:
- Core Server
---
# Set Maximum Number of Peers
The `rippled` server has a configurable soft maximum number of [peers](peer-protocol.html) to connect to. The default maximum number of peers is **21**.
**Note:** Internally, the server generates approximate quotas of incoming and outgoing peers. You can potentially go over the soft maximum if you are using [fixed peers, peer reservations](peer-protocol.html#fixed-peers-and-peer-reservations), or if you manually connect to additional peers using the [connect method][].
To change the maximum number of peers your server allows, complete the following steps:
1. Edit your `rippled`'s config file.
$ vim /etc/opt/ripple/rippled.cfg
{% include '_snippets/conf-file-location.md' %}<!--_ -->
2. In the config file, uncomment and edit the `[peers_max]` stanza, or add one if you don't have one already:
[peers_max]
30
The only content of the stanza should be an integer indicating the total number of peers to allow. By default, the server attempts to maintain a ratio of about 85% incoming and 15% outgoing peers, but with a minimum of 10 outgoing peers, so any value less than 68 won't increase the number of outgoing peer connections your server makes.
If the `[peers_max]` value is less than 10, the server still allows a hardcoded minimum of 10 outgoing peers so that it can maintain connectivity with the network. To block all outgoing peer connections, [configure the server as a private peer](run-rippled-as-a-validator.html#connect-using-proxies) instead.
**Caution:** The more peer servers you are connected to, the more network bandwidth your `rippled` server uses. You should only configure large numbers of peer servers if your `rippled` server has a good network connection and you can afford the costs you may incur for the bandwidth it uses.
3. Restart the `rippled` server.
$ sudo systemctl restart rippled.service
## See Also
- **Concepts:**
- [Peer Protocol](peer-protocol.html)
- [The `rippled` Server](xrpl-servers.html)
- **Tutorials:**
- [Capacity Planning](capacity-planning.html)
- [Troubleshoot the `rippled` Server](troubleshoot-the-rippled-server.html)
- **References:**
- [connect method][]
- [peers method][]
- [print method][]
- [server_info method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

185
content/infrastructure/rippled/configure-peering/use-a-peer-reservation.ja.md Normal file
View File

@@ -0,0 +1,185 @@
---
html: use-a-peer-reservation.html
parent: configure-peering.html
blurb: ピアリザベーションを使用して特定のピアへのより信頼できる接続を設定します。
lables:
- コアサーバー
---
# ピアリザベーションの使用
[ピアリザベーション][]を使用すると、`rippled`サーバーが予約とマッチしたピアからの通信を常に受け入れるように設定できます。このページでは、ピアリザベーションを使用して2台のサーバー間のピアツーピア通信を、各サーバーの管理者の協力のもと一貫して維持する方法について説明します。
ピアリザベーションは、2台のサーバーが異なる組織によって運用されていて、着信接続を受信するサーバーが、多くのピアを持つ[ハブサーバー](rippled-server-modes.html#公開ハブ)である場合に特に便利です。分かりやすいように、これらの手順では次の用語を使用します。
- **ストックサーバー**は発信接続を行うサーバーです。このサーバーは、ハブサーバー上のピアリザベーションを _使用_ します。
- **ハブサーバー**は着信接続を受信するサーバーです。管理者は、このサーバーにピアリザベーションを _追加_ します。
ただし、一方または両方のサーバーがハブ、バリデータ、ストックサーバーのいずれあっても、これらの手順を使用してピアリザベーションを設定できます。また、よりビジーな状態にあるサーバーから発信接続をする場合にもピアリザベーションを使用できますが、以下のプロセスではそのような構成については説明しません。
## 前提条件
これらの手順を実行するには、次の前提条件を満たしている必要があります。
- 両方のサーバーの管理者が`rippled`を[インストール](install-rippled.html)して実行している。
- 両方のサーバーの管理者が協力することに合意し、連絡が取り合える。秘密情報を共有する必要はないため、パブリックな通信チャネルを使用してもかまいません。
- ハブサーバーが着信ピア接続を受信できる。ファイアウォールをそのように設定する手順については、[ピアリングのポート転送](forward-ports-for-peering.html)を参照してください。
- 両方のサーバーが、同じ[XRP Ledgerネットワーク](parallel-networks.html)（本番XRP Ledger、Testnet、Devnetなど）と同期するように設定されている。
## 手順
ピアリザベーションを使用するには、以下の手順に従います。
### 1.（ストックサーバー）永続ノードキーペアを設定する
ストックサーバーの管理者が、以下の手順を実行します。
永続ノードキーペア値をすでにサーバーに設定している場合は、[ステップ2: ノード公開鍵をピアの管理者に連絡する](#2ストックサーバーのノード公開鍵を連絡する)に進んでください。（例えば、各サーバーの永続ノードキーペアは[サーバークラスターの設定](cluster-rippled-servers.html)の一環として設定します。）
**ヒント:** 永続ノードキーペアの設定は省略可能ですが、この設定をしておけば、サーバーのデータベースの消去や新規マシンへの移行が必要となった場合にピア接続の設定を容易に維持することができます。永続ノードキーペアを設定しない場合は、[server_infoメソッド][]の応答の`pubkey_node`フィールドに表示される、サーバーが自動生成したノード公開鍵を使用できます。
1. [validation_createメソッド][]を使用して新しいランダムキーペアを生成します。（`secret`値を省略します。）
例:
rippled validation_create
Loading: "/etc/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result" : {
"status" : "success",
"validation_key" : "FAWN JAVA JADE HEAL VARY HER REEL SHAW GAIL ARCH BEN IRMA",
"validation_public_key" : "n9Mxf6qD4J55XeLSCEpqaePW4GjoCR5U1ZeGZGJUCNe3bQa4yQbG",
"validation_seed" : "ssZkdwURFMBXenJPbrpE14b6noJSu"
}
}
`validation_seed`（ノードシード値）と`validation_public_key`値（ノード公開鍵）を保存します。
2. `rippled`の構成ファイルを編集します。
vim /etc/opt/ripple/rippled.cfg
{% include '_snippets/conf-file-location.md' %}<!--_ -->
3. 前のステップで生成した`validation_seed`値を使用して、`[node_seed]`スタンザを追加します。
例:
[node_seed]
ssZkdwURFMBXenJPbrpE14b6noJSu
**警告:** すべてのサーバーの`[node_seed]`値が一意である必要があります。構成ファイルを別のサーバーにコピーする場合は、`[node_seed]`値を削除するか、変更してください。`[node_seed]`は公開しないようにします。不正使用者がこの値にアクセスできた場合、それを使用してサーバーを偽装し、XRP Ledgerのピアツーピア通信を行う可能性があります。
4. `rippled`サーバーを再起動します。
systemctl restart rippled
### 2.ストックサーバーのノード公開鍵を連絡する
ストックサーバーの管理者が、ハブサーバーの管理者にストックサーバーのノード公開鍵を伝えます。（ステップ1の`validation_public_key`を使用します。）ハブサーバーの管理者はこの値を以降のステップで使用する必要があります。
### 3.（ハブサーバー）ピアリザベーションを追加する
ハブサーバーの管理者が、以下の手順を実行します。
[peer_reservations_addメソッド][]を使用し、前のステップで入手したノード公開鍵を使用して予約を追加します。例:
```sh
$ rippled peer_reservations_add n9Mxf6qD4J55XeLSCEpqaePW4GjoCR5U1ZeGZGJUCNe3bQa4yQbG "Description here"
Loading: "/etc/opt/ripple/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result": {
"status": "success"
}
}
```
**ヒント:** 説明はオプションのフィールドです。この予約は誰のためにしたものかを人間が読み取れる形式のメモを追加できます。
### 4.ハブサーバーの現在のIPアドレスとピアポートを連絡する
ハブサーバーの管理者は、サーバーの現在のIPアドレスとピアポートをストックサーバーの管理者に伝える必要があります。ハブサーバーが、ネットワークアドレス変換（NAT）を行なうファイアウォールの内側にある場合は、サーバーの _外部_ IPアドレスを使用します。デフォルトの構成ファイルは、ピアプロトコルにポート51235を使用します。
### 5.（ストックサーバー）ピアサーバーに接続する
ストックサーバーの管理者が、以下の手順を実行します。
[connectメソッド][]を使用して、サーバーをハブサーバーに接続します。例:
<!-- MULTICODE_BLOCK_START -->
*WebSocket*
```
{
"command": "connect",
"ip": "169.54.2.151",
"port": 51235
}
```
*JSON-RPC*
```
{
"method": "connect",
"params": [
{
"ip": "169.54.2.151",
"port": 51235
}
]
}
```
*コマンドライン*
```
rippled connect 169.54.2.151 51235
```
<!-- MULTICODE_BLOCK_END -->
ハブサーバーの管理者が上記の手順に従ってピアリザベーションを設定した場合、自動的に接続され、可能な限り接続が維持されます。
## 次のステップ
サーバーの管理者は、サーバーに設定された他のピアへの予約を管理できます。（他のサーバーからの予約は確認できません。）次のことを実行できます。
- [peer_reservations_addメソッド][]を使用して、ピアリザベーションの追加や説明の更新を行う。
- [peer_reservations_listメソッド][]を使用して、予約先のサーバーを確認する。
- [peer_reservations_delメソッド][]を使用して、予約を削除する。
- [peersメソッド][]を使用して、現在接続しているピアと使用している帯域幅の量を確認する。
**ヒント:** 不正なピアからの接続を即座に切断するAPIメソッドはありませんが、`firewalld`などのソフトウェアファイアウォールを使用すれば、不正なピアからのサーバーへの接続をブロックできます。例については、コミュニティーによって作成された[rbhスクリプト](https://github.com/gnanderson/rbh)を参照してください。
## 関連項目
- **コンセプト:**
- [ピアプロトコル](peer-protocol.html)
- [コンセンサス](consensus.html)
- [並列ネットワーク](parallel-networks.html)
- **チュートリアル:**
- [容量の計画](capacity-planning.html)
- [`rippled`のトラブルシューティング](troubleshoot-the-rippled-server.html)
- **リファレンス:**
- [peersメソッド][]
- [peer_reservations_addメソッド][]
- [peer_reservations_delメソッド][]
- [peer_reservations_listメソッド][]
- [connectメソッド][]
- [fetch_infoメソッド][]
- [ピアクローラー](peer-crawler.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

185
content/infrastructure/rippled/configure-peering/use-a-peer-reservation.md Normal file
View File

@@ -0,0 +1,185 @@
---
html: use-a-peer-reservation.html
parent: configure-peering.html
blurb: Set up a more reliable connection to a specific peer using a peer reservation.
labels:
- Core Server
---
# Use a Peer Reservation
A [peer reservation][] is a setting that makes a `rippled` server always accept connections from a peer matching the reservation. This page describes how to use peer reservations to keep a consistent peer-to-peer connection between two servers, with the cooperation of the administrators of both servers.
Peer reservations are most useful when the two servers are run by different parties, and the server that receives the incoming connection is a [hub server](rippled-server-modes.html#public-hubs) with many peers. For clarity, these instructions use the following terms:
- The server making the outgoing connection is the **stock server**. This server _uses_ the peer reservation on the hub server.
- The server receiving the incoming connection is the **hub server**. The administrator _adds_ the peer reservation to this server.
However, you can use these instructions to set up a peer reservation regardless of whether one server or both are hubs, validators, or stock servers. It is also possible to use a peer reservation when the busier server is the one making the outgoing connection, but this process does not describe that configuration.
## Prerequisites
To complete these steps, you must meet the following prerequisites:
- The administrators both servers must have `rippled` [installed](install-rippled.html) and running.
- The administrators of both servers must agree to cooperate and must be able to communicate. A public communications channel is fine because you don't need to share any secret information.
- The hub server must be able to receive incoming peer connections. For instructions on how to configure a firewall to allow this, see [Forward Ports for Peering](forward-ports-for-peering.html).
- Both servers must be configured to sync with the same [XRP Ledger network](parallel-networks.html), such as the production XRP Ledger, the Testnet, or the Devnet.
## Steps
To use a peer reservation, complete the following steps:
### 1. (Stock Server) Set up a permanent node key pair
The administrator of the stock server completes this step.
If you have already configured your server with a permanent node key pair value, you can skip ahead to [step 2: Communicate your node public key to the peer's admin](#2-communicate-the-stock-servers-node-public-key). (For example, setting up a permanent node key pair for each server is part of the process of [setting up a server cluster](cluster-rippled-servers.html).)
**Tip:** Setting up a permanent node key pair is optional, but makes it easier to keep the peer reservation set up if you need to erase your server's databases or move to a new machine. If you don't want to set up a permanent node key pair, you can use your server's automatically-generated node public key as reported in the `pubkey_node` field of the [server_info method][] response.
1. Generate a new, random key pair using the [validation_create method][]. (Omit the `secret` value.)
For example:
rippled validation_create
Loading: "/etc/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result" : {
"status" : "success",
"validation_key" : "FAWN JAVA JADE HEAL VARY HER REEL SHAW GAIL ARCH BEN IRMA",
"validation_public_key" : "n9Mxf6qD4J55XeLSCEpqaePW4GjoCR5U1ZeGZGJUCNe3bQa4yQbG",
"validation_seed" : "ssZkdwURFMBXenJPbrpE14b6noJSu"
}
}
Save the `validation_seed` (your node seed value) and the `validation_public_key` value (your node public key )
2. Edit your `rippled`'s config file.
vim /etc/opt/ripple/rippled.cfg
{% include '_snippets/conf-file-location.md' %}<!--_ -->
3. Add a `[node_seed]` stanza using the `validation_seed` value you generated earlier.
For example:
[node_seed]
ssZkdwURFMBXenJPbrpE14b6noJSu
**Warning:** All servers should have unique `[node_seed]` values. If you copy your config file to another server, be sure to remove or change the `[node_seed]` value. Keep your `[node_seed]` secret; if a malicious actor gains access to this value, they could use it to impersonate your server in XRP Ledger peer-to-peer communications.
4. Restart your `rippled` server:
systemctl restart rippled
### 2. Communicate the stock server's node public key
The administrator of the stock server tells the administrator of the hub server what the stock server's node public key is. (Use the `validation_public_key` from step 1.) The administrator of the hub server needs this value for the next steps.
### 3. (Hub Server) Add the peer reservation
The administrator of the hub server completes this step.
Use the [peer_reservations_add method][] to add a reservation using the node public key that you got in the previous step. For example:
```sh
$ rippled peer_reservations_add n9Mxf6qD4J55XeLSCEpqaePW4GjoCR5U1ZeGZGJUCNe3bQa4yQbG "Description here"
Loading: "/etc/opt/ripple/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result": {
"status": "success"
}
}
```
**Tip:** The description is an optional field that you can provide to add a human-readable note about who this reservation is for.
### 4. Communicate the hub server's current IP address and peer port
The administrator of the hub server must tell their server's current IP address and peer port to the administrator of the stock server. If the hub server is behind a firewall that does network address translation (NAT), use the server's _external_ IP address. The default config file uses port 51235 for the peer protocol.
### 5. (Stock Server) Connect to the peer server
The administrator of the stock server completes this step.
Use the [connect method][] to connect your server to the hub server. For example:
<!-- MULTICODE_BLOCK_START -->
*WebSocket*
```
{
"command": "connect",
"ip": "169.54.2.151",
"port": 51235
}
```
*JSON-RPC*
```
{
"method": "connect",
"params": [
{
"ip": "169.54.2.151",
"port": 51235
}
]
}
```
*Commandline*
```
rippled connect 169.54.2.151 51235
```
<!-- MULTICODE_BLOCK_END -->
If the hub server's administrator has set up the peer reservation as described in the previous steps, this should automatically connect and remain connected as long as possible.
## Next Steps
As a server administrator, you can manage the reservations your server has for other peers. (It is not possible to check which other servers have reservations for yours.) You can:
- Add more peer reservations or update their descriptions, using the [peer_reservations_add method][].
- Check which servers you have configured reservations for, using the [peer_reservations_list method][].
- 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). <!-- SPELLING_IGNORE: rbh -->
## See Also
- **Concepts:**
- [Peer Protocol](peer-protocol.html)
- [Consensus](consensus.html)
- [Parallel Networks](parallel-networks.html)
- **Tutorials:**
- [Capacity Planning](capacity-planning.html)
- [Troubleshooting `rippled`](troubleshoot-the-rippled-server.html)
- **References:**
- [peers method][]
- [peer_reservations_add method][]
- [peer_reservations_del method][]
- [peer_reservations_list method][]
- [connect method][]
- [fetch_info method][]
- [Peer Crawler](peer-crawler.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

348
content/infrastructure/rippled/installation/build-run-rippled-in-reporting-mode.md Normal file
View File

@@ -0,0 +1,348 @@
---
html: build-run-rippled-in-reporting-mode.html
parent: install-rippled.html
blurb: Build and run a special operating mode of rippled that handles remote procedure calls (RPC) for validated data.
labels:
- Core Server
- Blockchain
top_nav_grouping: Popular Pages
---
# Build and Run `rippled` in Reporting Mode
[Reporting mode](rippled-server-modes.html) is a mode of the XRP Ledger core server specialized for serving [HTTP and WebSocket APIs](http-websocket-apis.html).
In reporting mode, the server does not connect to the peer-to-peer network. Instead, it uses gRPC to get validated data from one or more trusted servers that are connected to the P2P network.
It can then efficiently handle API calls, reducing the load on `rippled` servers running in P2P mode.
{{ include_svg("img/reporting-mode-basic-architecture.svg", "Figure 1: Working of `rippled` in reporting mode") }}
The reporting mode of `rippled` uses two datastores:
* The primary persistent datastore for `rippled` that includes transaction metadata, account states, and ledger headers. You can use NuDB (included with the source) or [Cassandra](https://cassandra.apache.org/) as the primary persistent datastore. If you use Cassandra, multiple reporting mode servers can share access to data in a single Cassandra instance or cluster.
* [PostgreSQL](https://www.postgresql.org/) database to hold relational data, which is used mainly by [tx method][] and [account_tx method][].
When a reporting mode server receives an API request, it loads the data from these data stores if possible. For requests that require data from the P2P network, the reporting mode forwards the request to a P2P server, and then passes the response back to the client.
Multiple reporting mode servers can share access to the same network accessible databases (PostgreSQL and Cassandra); at any given time, only one reporting mode server writes to the databases, while all the others read from the databases.
## How to Run Reporting Mode
### Prerequisites
1. Ensure that your system meets the [system requirements](system-requirements.html).
**Note:** If you choose to use Cassandra as the database, the disk requirements for `rippled` will be lower as the data will not be stored on your local disk.
2. You also need to run at least one `rippled` server in P2P mode.
3. A compatible version of CMake must be installed.
4. Install and configure the datastores required to run `rippled` in reporting mode.
1. Install PostgreSQL.
2. Install and configure the database to be used as the primary persistent datastore. You can choose to use Cassandra or NuDB.
3. On macOS, you need to manually install the Cassandra cpp driver. On all other platforms, the Cassandra driver is built as part of the `rippled` build.
brew install cassandra-cpp-driver
#### Install PostgreSQL
**Install PostgreSQL on Linux**
1. Download and [install PostgreSQL on Linux](https://www.postgresqltutorial.com/install-postgresql-linux/).
2. Connect to the PostgreSQL Database Server using `psql`, and create a user `newuser` and a database `reporting`.
psql postgres
CREATE ROLE newuser WITH LOGIN PASSWORD ‘password’;
ALTER ROLE newuser CREATEDB;
\q
psql postgres -U newuser
postgres=# create database reporting;
**Install PostgreSQL on macOS**
1. Download and install PostgreSQL on macOS.
brew install postgres
brew services start postgres
2. Connect to the PostgreSQL Database Server using `psql` and create a user `newuser` and a database `reporting`.
psql postgres
CREATE ROLE newuser WITH LOGIN PASSWORD ‘password’;
ALTER ROLE newuser CREATEDB;
\q
psql postgres -U newuser
postgres=# create database reporting;
#### Install and Configure the Primary Persistent Datastore
**Cassandra**
Install Cassandra and then create a keyspace for `rippled`, with replication. <!-- SPELLING_IGNORE: keyspace -->
While a replication factor of 3 is recommended, when running locally, replication is not needed and you can set `replication_factor` to 1.
$ cqlsh [host] [port]
> CREATE KEYSPACE `rippled` WITH REPLICATION =
{'class' : 'SimpleStrategy', 'replication_factor' : 1 };
**NuDB**
If you’re running `rippled` in reporting mode for your local network, you can choose to use NuDB instead of Cassandra as your backend database.
NuDB is installed as part of your `rippled` build setup and does not require any additional installation steps.
### Steps
1. Build `rippled` for reporting mode on [Ubuntu or macOS](https://github.com/XRPLF/rippled/blob/release/BUILD.md).
<!-- MULTICODE_BLOCK_START -->
*Linux*
wget https://github.com/Kitware/CMake/releases/download/v3.16.3/cmake-3.16.3-Linux-x86_64.sh
sudo sh cmake-3.16.3-Linux-x86_64.sh --prefix=/usr/local --exclude-subdir
cmake -B build -Dreporting=ON -DCMAKE_BUILD_TYPE=Debug
cmake --build build --parallel $(nproc)
*macOS*
cmake -B build -G "Unix Makefiles" -Dreporting=ON -DCMAKE_BUILD_TYPE=Debug
cmake --build build --parallel $(nproc)
<!-- MULTICODE_BLOCK_END -->
2. Create a configuration file to run `rippled` in reporting mode.
Make a copy of the example config file, `rippled-example.cfg`, and save it as `rippled-reporting-mode.cfg` in a location that enables you to run `rippled` as a non-root user. For example:
mkdir -p $HOME/.config/ripple
cp <RIPPLED_SOURCE>/cfg/rippled-example.cfg $HOME/.config/ripple/rippled-reporting-mode.cfg
3. Edit rippled-reporting-mode.cfg to set necessary file paths. The user you plan to run `rippled` as must have write permissions to all of the paths you specify here.
1. Set the `[node_db]` path to the location where you want to store the ledger database.
2. Set the `[database_path]` to the location where you want to store other database data. (This includes an SQLite database with configuration data, and is typically one level above the `[node_db]` path field.)
3. Set the `[debug_logfile]` to a path where `rippled` can write logging information.
Note that these are the only configurations required for `rippled` to start up successfully. All other configurations are optional and can be tweaked after you have a working server.
4. Edit the `rippled-reporting-mode.cfg` file to enable reporting mode:
1. Uncomment the `[reporting]` stanza or add a new one:
[reporting]
etl_source
read_only=0
2. List the `rippled` sources (ETL sources) to extract data from. These `rippled` servers must have gRPC enabled.
NOTE: Only include servers that you trust as reporting mode does not connect to the P2P network and hence cannot verify that the data actually matches the network consensus ledger.
[etl_source]
source_grpc_port=50051
source_ws_port=6006
source_ip=127.0.0.1
5. Configure the databases
1. Specify the Postgres DB for `[ledger_tx_tables]`:
[ledger_tx_tables]
conninfo = postgres://newuser:password@127.0.0.1/reporting
use_tx_tables=1
2. Specify the database for `[node_db]`.
<!-- MULTICODE_BLOCK_START -->
*NuDB*
[node_db]
type=NuDB
path=/home/ubuntu/ripple/
[ledger_history]
1000000
*Cassandra*
[node_db]
type=Cassandra
[ledger_history]
1000000
<!-- MULTICODE_BLOCK_END -->
6. Modify the configuration for `rippled` to open up ports.
1. Open the public websocket port:
[port_ws_admin_local]
port = 6006
ip = 127.0.0.1
admin = 127.0.0.1
protocol = ws
2. Open the gRPC port:
[port_grpc]
port = 60051
ip = 0.0.0.0
3. Add a secured gateway to the IP of your reporting system:
secure_gateway = 127.0.0.1
7. Run `rippled` in reporting mode:
./rippled --conf /home/ubuntu/.config/ripple/rippled-reporting-example.cfg
### What to Expect
Here are the excerpts of what you can expect to see on your terminal.
```text
Loading: "/home/ubuntu/.config/ripple/rippled-reporting-example.cfg"
2021-Dec-09 21:31:52.245577 UTC JobQueue:NFO Using 10 threads
2021-Dec-09 21:31:52.255422 UTC LedgerConsensus:NFO Consensus engine started (cookie: 17859050541656985684)
2021-Dec-09 21:31:52.256542 UTC ReportingETL::ETLSource:NFO Using IP to connect to ETL source: 127.0.0.1:50051
2021-Dec-09 21:31:52.257784 UTC ReportingETL::ETLSource:NFO Made stub for remote = { validated_ledger : , ip : 127.0.0.1 , web socket port : 6006, grpc port : 50051 }
2021-Dec-09 21:31:52.258032 UTC ReportingETL::LoadBalancer:NFO add : added etl source - { validated_ledger : , ip : 127.0.0.1 , web socket port : 6006, grpc port : 50051 }
2021-Dec-09 21:31:52.258327 UTC Application:NFO process starting: rippled-1.8.1+DEBUG
2021-Dec-09 21:31:52.719186 UTC PgPool:DBG max_connections: 18446744073709551615, timeout: 600, connection params: port: 5432, hostaddr: 127.0.0.1, user: newuser, password: *, channel_binding: prefer, dbname: reporting_test_core, host: 127.0.0.1, options: , sslmode: prefer, sslcompression: 0, sslsni: 1, ssl_min_protocol_version: TLSv1.2, gssencmode: prefer, krbsrvname: postgres, target_session_attrs: any
2021-Dec-09 21:31:52.788851 UTC PgPool:NFO server message: NOTICE: relation "version" already exists, skipping
2021-Dec-09 21:31:53.282807 UTC TaggedCache:DBG LedgerCache target size set to 384
2021-Dec-09 21:31:53.282892 UTC TaggedCache:DBG LedgerCache target age set to 240000000000
2021-Dec-09 21:31:53.283741 UTC Amendments:DBG Amendment 98DECF327BF79997AEC178323AD51A830E457BFC6D454DAF3E46E5EC42DC619F (CheckCashMakesTrustLine) is supported and will be down voted if not enabled on the ledger.
2021-Dec-09 21:31:53.283836 UTC Amendments:DBG Amendment 157D2D480E006395B76F948E3E07A45A05FE10230D88A7993C71F97AE4B1F2D1 (Checks) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.283917 UTC Amendments:DBG Amendment 1562511F573A19AE9BD103B5D6B9E01B3B46805AEC5D3C4805C902B514399146 (CryptoConditions) is supported and will be down voted if not enabled on the ledger.
2021-Dec-09 21:31:53.283975 UTC Amendments:DBG Amendment 86E83A7D2ECE3AD5FA87AB2195AE015C950469ABF0B72EAACED318F74886AE90 (CryptoConditionsSuite) is supported and will be down voted if not enabled on the ledger.
2021-Dec-09 21:31:53.284016 UTC Amendments:DBG Amendment 30CD365592B8EE40489BA01AE2F7555CAC9C983145871DC82A42A31CF5BAE7D9 (DeletableAccounts) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.284062 UTC Amendments:DBG Amendment F64E1EABBE79D55B3BB82020516CEC2C582A98A6BFE20FBE9BB6A0D233418064 (DepositAuth) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.284099 UTC Amendments:DBG Amendment 3CBC5C4E630A1B82380295CDA84B32B49DD066602E74E39B85EF64137FA65194 (DepositPreauth) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.284126 UTC Amendments:DBG Amendment DC9CA96AEA1DCF83E527D1AFC916EFAF5D27388ECA4060A88817C1238CAEE0BF (EnforceInvariants) is supported and will be down voted if not enabled on the ledger.
2021-Dec-09 21:31:53.284153 UTC Amendments:DBG Amendment 07D43DCE529B15A10827E5E04943B496762F9A88E3268269D69C44BE49E21104 (Escrow) is supported and will be down voted if not enabled on the ledger.
2021-Dec-09 21:31:53.284189 UTC Amendments:DBG Amendment 42426C4D4F1009EE67080A9B7965B44656D7714D104A72F9B4369F97ABF044EE (FeeEscalation) is supported and will be down voted if not enabled on the ledger.
2021-Dec-09 21:31:53.284216 UTC Amendments:DBG Amendment 740352F2412A9909880C23A559FCECEDA3BE2126FED62FC7660D628A06927F11 (Flow) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.284241 UTC Amendments:DBG Amendment 3012E8230864E95A58C60FD61430D7E1B4D3353195F2981DC12B0C7C0950FFAC (FlowCross) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.284284 UTC Amendments:DBG Amendment AF8DF7465C338AE64B1E937D6C8DA138C0D63AD5134A68792BBBE1F63356C422 (FlowSortStrands) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.284337 UTC Amendments:DBG Amendment 1F4AFA8FA1BC8827AD4C0F682C03A8B671DCDF6B5C4DE36D44243A684103EF88 (HardenedValidations) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.284412 UTC Amendments:DBG Amendment 4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373 (MultiSign) is supported and will be down voted if not enabled on the ledger.
2021-Dec-09 21:31:53.284455 UTC Amendments:DBG Amendment 586480873651E106F1D6339B0C4A8945BA705A777F3F4524626FF1FC07EFE41D (MultiSignReserve) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.284491 UTC Amendments:DBG Amendment B4E4F5D2D6FB84DF7399960A732309C9FD530EAE5941838160042833625A6076 (NegativeUNL) is supported and will be down voted if not enabled on the ledger.
2021-Dec-09 21:31:53.284528 UTC Amendments:DBG Amendment 08DE7D96082187F6E6578530258C77FAABABE4C20474BDB82F04B021F1A68647 (PayChan) is supported and will be down voted if not enabled on the ledger.
2021-Dec-09 21:31:53.284592 UTC Amendments:DBG Amendment 00C1FC4A53E60AB02C864641002B3172F38677E29C26C5406685179B37E1EDAC (RequireFullyCanonicalSig) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.284649 UTC Amendments:DBG Amendment CC5ABAE4F3EC92E94A59B1908C2BE82D2228B6485C00AFF8F22DF930D89C194E (SortedDirectories) is supported and will be down voted if not enabled on the ledger.
2021-Dec-09 21:31:53.284703 UTC Amendments:DBG Amendment 532651B4FD58DF8922A49BA101AB3E996E5BFBF95A913B3E392504863E63B164 (TickSize) is supported and will be down voted if not enabled on the ledger.
2021-Dec-09 21:31:53.284787 UTC Amendments:DBG Amendment 955DF3FA5891195A9DAEFA1DDC6BB244B545DDE1BAA84CBB25D5F12A8DA68A0C (TicketBatch) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.284950 UTC Amendments:DBG Amendment 6781F8368C4771B83E8B821D88F580202BCB4228075297B19E4FDC5233F1EFDC (TrustSetAuth) is supported and will be down voted if not enabled on the ledger.
2021-Dec-09 21:31:53.284997 UTC Amendments:DBG Amendment B4D44CC3111ADD964E846FC57760C8B50FFCD5A82C86A72756F6B058DDDF96AD (fix1201) is supported and will be down voted if not enabled on the ledger.
2021-Dec-09 21:31:53.285025 UTC Amendments:DBG Amendment E2E6F2866106419B88C50045ACE96368558C345566AC8F2BDF5A5B5587F0E6FA (fix1368) is supported and will be down voted if not enabled on the ledger.
2021-Dec-09 21:31:53.285067 UTC Amendments:DBG Amendment 42EEA5E28A97824821D4EF97081FE36A54E9593C6E4F20CBAE098C69D2E072DC (fix1373) is supported and will be down voted if not enabled on the ledger.
2021-Dec-09 21:31:53.285103 UTC Amendments:DBG Amendment 6C92211186613F9647A89DFFBAB8F94C99D4C7E956D495270789128569177DA1 (fix1512) is supported and will be down voted if not enabled on the ledger.
2021-Dec-09 21:31:53.285129 UTC Amendments:DBG Amendment 67A34F2CF55BFC0F93AACD5B281413176FEE195269FA6D95219A2DF738671172 (fix1513) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.285153 UTC Amendments:DBG Amendment 5D08145F0A4983F23AFFFF514E83FAD355C5ABFBB6CAB76FB5BC8519FF5F33BE (fix1515) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.285176 UTC Amendments:DBG Amendment B9E739B8296B4A1BB29BE990B17D66E21B62A300A909F25AC55C22D6C72E1F9D (fix1523) is supported and will be down voted if not enabled on the ledger.
2021-Dec-09 21:31:53.285202 UTC Amendments:DBG Amendment 1D3463A5891F9E589C5AE839FFAC4A917CE96197098A1EF22304E1BC5B98A454 (fix1528) is supported and will be down voted if not enabled on the ledger.
2021-Dec-09 21:31:53.285256 UTC Amendments:DBG Amendment CA7C02118BA27599528543DFE77BA6838D1B0F43B447D4D7F53523CE6A0E9AC2 (fix1543) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.285290 UTC Amendments:DBG Amendment 7117E2EC2DBF119CA55181D69819F1999ECEE1A0225A7FD2B9ED47940968479C (fix1571) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.285343 UTC Amendments:DBG Amendment FBD513F1B893AC765B78F250E6FFA6A11B573209D1842ADC787C850696741288 (fix1578) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.285381 UTC Amendments:DBG Amendment 58BE9B5968C4DA7C59BA900961828B113E5490699B21877DEF9A31E9D0FE5D5F (fix1623) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.285424 UTC Amendments:DBG Amendment 25BA44241B3BD880770BFA4DA21C7180576831855368CBEC6A3154FDE4A7676E (fix1781) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.285464 UTC Amendments:DBG Amendment 4F46DF03559967AC60F2EB272FEFE3928A7594A45FF774B87A7E540DB0F8F068 (fixAmendmentMajorityCalc) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.285500 UTC Amendments:DBG Amendment 8F81B066ED20DAECA20DF57187767685EEF3980B228E0667A650BAF24426D3B4 (fixCheckThreading) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.285527 UTC Amendments:DBG Amendment C4483A1896170C66C098DEA5B0E024309C60DC960DE5F01CD7AF986AA3D9AD37 (fixMasterKeyAsRegularKey) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.285550 UTC Amendments:DBG Amendment 621A0B264970359869E3C0363A899909AAB7A887C8B73519E4ECF952D33258A8 (fixPayChanRecipientOwnerDir) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.285575 UTC Amendments:DBG Amendment 89308AF3B8B10B7192C4E613E1D2E4D9BA64B2EE2D5232402AE82A6A7220D953 (fixQualityUpperBound) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.285614 UTC Amendments:DBG Amendment B6B3EEDC0267AB50491FDC450A398AF30DBCD977CECED8BEF2499CAB5DAC19E2 (fixRmSmallIncreasedQOffers) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.285651 UTC Amendments:DBG Amendment 452F5906C46D46F407883344BFDD90E672B672C5E9943DB4891E3A34FEEEB9DB (fixSTAmountCanonicalize) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.285725 UTC Amendments:DBG Amendment 2CD5286D8D687E98B41102BDD797198E81EA41DF7BD104E6561FEB104EFF2561 (fixTakerDryOfferRemoval) is supported and will be up voted if not enabled on the ledger.
2021-Dec-09 21:31:53.290446 UTC Server:NFO Opened 'port_rpc_admin_local' (ip=127.0.0.1:7005, admin IPs:127.0.0.1, http)
2021-Dec-09 21:31:53.290834 UTC Server:NFO Opened 'port_ws_admin_local' (ip=127.0.0.1:7006, admin IPs:127.0.0.1, ws)
2021-Dec-09 21:31:53.290984 UTC Application:WRN Running in standalone mode
2021-Dec-09 21:31:53.291048 UTC NetworkOPs:NFO STATE->full
2021-Dec-09 21:31:53.291192 UTC Application:FTL Startup RPC:
{
"command" : "log_level",
"severity" : "debug"
}
2021-Dec-09 21:31:53.291347 UTC RPCHandler:DBG RPC call log_level completed in 2.2e-08seconds
2021-Dec-09 21:31:53.291440 UTC Application:FTL Result:
{
"warnings" :
[
{
"id" : 1004,
"message" : "This is a reporting server. The default behavior of a reporting server is to only return validated data. If you are looking for not yet validated data, include \"ledger_index : current\" in your request, which will cause this server to forward the request to a p2p node. If the forward is successful the response will include \"forwarded\" : \"true\""
}
]
}
2021-Dec-09 21:31:53.291502 UTC ReportingETL:NFO Starting reporting etl
2021-Dec-09 21:31:53.291605 UTC Application:NFO Application starting. Version is 1.8.1+DEBUG
2021-Dec-09 21:31:53.291747 UTC LoadManager:DBG Starting
2021-Dec-09 21:31:53.291846 UTC gRPC Server:NFO Starting gRPC server at 0.0.0.0:60051
2021-Dec-09 21:31:53.293246 UTC LedgerCleaner:DBG Started
2021-Dec-09 21:31:53.295543 UTC ReportingETL::ETLSource:DBG handleMessage : Received a message on ledger subscription stream. Message : {
"result" : {},
"status" : "success",
"type" : "response"
}
- { validated_ledger : , ip : 127.0.0.1 , web socket port : 6006, grpc port : 50051 }
2021-Dec-09 21:31:53.368075 UTC ReportingETL:NFO monitor : Database is empty. Will download a ledger from the network.
2021-Dec-09 21:31:53.368183 UTC ReportingETL:NFO monitor : Waiting for next ledger to be validated by network...
```
## Frequently Asked Questions
<!-- STYLE_OVERRIDE: frequently -->
**Do I need to run more than one instance of `rippled` to use reporting mode?**
Yes. A `rippled` server running in reporting mode does not connect to the peer-to-peer network, but instead extracts validated data from one or more `rippled` servers that are connected to the network, so you need to run at least one P2P mode server.
**I’ve already installed `rippled`. Can I update the configuration file to enable reporting mode and restart `rippled`?**
No. Currently, you need to download the source and build `rippled` for reporting mode. There are initiatives in progress to provide packages for reporting mode.
**To run `rippled` in reporting mode, I need at least one `rippled` server running in P2P mode too. Does this mean I need double the disk space?**
The answer depends on the location of your primary data store. If you use Cassandra as the primary data store, the reporting mode server stores much less data on its local disk. The PostgreSQL server can be remote as well. You can have multiple reporting mode servers share the same data this way.
Lastly, the P2P mode server only needs to keep very recent history, while the reporting mode server keeps long term history.
For more information on system requirements to run `rippled`, see the [`rippled` system requirements](system-requirements.html).
**How can I confirm the validity of the data that comes from the PostgreSQL or Cassandra database?**
When `rippled` runs in reporting mode, it only serves validated data from the ETL source specified in the config file. If you are using someone else's `rippled` server in P2P mode as the ETL source, you are implicitly trusting that server. If not, you need to run your own `rippled` node in P2P mode.
**Is it possible to make traditional SQL queries to the relational database rather than using the API?**
Technically, you *can* directly access the database if you want. However, the data is stored as binary blobs and you have to decode the blobs to access the data in them. This makes traditional SQL queries much less useful since they cannot find and filter the individual fields of the data.
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

218
content/infrastructure/rippled/installation/capacity-planning.ja.md Normal file
View File

@@ -0,0 +1,218 @@
---
html: capacity-planning.html
parent: install-rippled.html
blurb: 本番環境のシステムスペックを計画して、rippledの構成を調整します。
labels:
- コアサーバー
- データ保持
---
# 容量の計画
このドキュメントでは、XRP Ledgerサーバーのパフォーマンスを調整・最適化するために使用できる、構成、ネットワーク、ハードウェアに関する推奨事項を説明しています。
XRP Ledgerのサーバーの負荷は、複数の要因によって変化します。ひとつは、ネットワーク内の活動です。共有レジャーのデータサイズや送信されるトランザクションの総量は、グローバルなXRP Ledgerコミュニティ全体の有機的な要因に基づいて変化します。もうひとつの要因は、APIの使用状況です。異なる種類の[APIコール](http-websocket-apis.html)は、サーバーに異なる負荷をかけます。パブリックなAPIを提供しているサーバーと、特定の統合ソフトウェアにプライベートなAPIを提供しているサーバー、あるいはAPIを全く提供していないサーバーとでは、パフォーマンス特性が大きく異なります。
これらの要素を考慮して、構成するサーバーが現在および将来のXRP Ledgerネットワークの活動を処理する能力を持っていることを確認する必要があります。
## 構成設定
デフォルトの設定ファイルには、一般的なユースケースを幅広くカバーする設定が含まれています。お使いのハードウェアや使用目的に合わせて設定をカスタマイズすることで、より良いパフォーマンスを得ることができます。
本セクションでの設定は、`rippled.cfg`ファイルのパラメータです。設定ファイルの例である `rippled-example.cfg` は、`rippled` GitHubリポジトリ の [`cfg` ディレクトリ](https://github.com/ripple/rippled/blob/develop/cfg/rippled-example.cfg)からアクセスできます。サンプル設定ファイルの設定は、サーバーと一緒にインストールされたデフォルトの設定と一致しています。
### ノードサイズ
`[node_size]`パラメータは、サーバのハードウェア全体の容量を反映する必要があります。このパラメータを省略すると、システムの総RAMとCPUスレッド数に基づいて、サーバが自動的に適切な設定を選択します。システムのRAMやスレッドの一部を他のソフトウェア用に確保する必要がある場合や、オペレーティングシステムから報告される量が不正確な場合など、自動設定がシステムに合わない場合は、この値を明示的に設定できます。(これは一部のコンテナで発生する可能性があります。) [更新: rippled 1.8.1][].
一般的には、使用可能なRAMがサポートする最大のノードサイズを常に使用する必要があります。推奨される設定については、以下の表を参照してください。
#### 推奨事項
それぞれの`[node_size]`には、それに対応する利用可能なRAMの要件があります。例えば、`[node_size]`を`huge`に設定した場合、`rippled`がスムーズに動作するためには、最低でも32GBの利用可能なRAMが必要です。
サーバーを調整するために、まず`tiny`から初め、ユースケースの要件に合わせてサイズを徐々に`small`、`medium`と増やしていくと便利です。
| `rippled`で使用できるRAM | `node_size` 値 | 注記 |
|:----------------------------|:------------------|:---------------------------|
| 8GB未満 | `tiny` | **非推奨** この設定をしたサーバーは、ビジー状態のネットワークに同期しないことがあります。 |
| 8GB | `small` | テストサーバーに推奨。 |
| 16GB | `medium` | `rippled-example.cfg`ファイルではこの値が使用されます。 |
| 32GB | `large` | **非推奨** 実際には、この設定はほとんどの状況で `huge` よりもパフォーマンスが低下します。安定性を求めるのであれば、常に `huge` を使用してください。 |
| 64GB | `huge` | 実稼働サーバーに推奨。 |
`node_size`パラメーターを無効な値に設定すると、[サーバーは起動しません](server-wont-start.html#node_sizeの値が正しくない)。
### ノードDBタイプ
`rippled.cfg`ファイルの`[node_db]`節の`type`フィールドでは、レジャーストアを保持するために`rippled`で使用されるkey-valueストアのタイプを設定します。
この設定は、直接RAM設定を構成するわけではありませんが、key-valueストアの選択はRAMの使用に大きな影響をもたらします。これは、テクノロジーによって、高速検索のためにデータをキャッシュし、インデックス付けする方法が異なるためです。
- ほとんどのケースにおいて、ディスクのデータが膨大であってもパフォーマンスが一貫している`NuDB`を使用します。高速のSSDが必要です。[詳細はこちらをご覧ください。](#nudbの使用の詳細)
- HDD（非推奨）や、単に遅いSSDを使用している場合でも、`RocksDB`を使用してください。本番サーバーではこの設定は避けるべきです。[詳細はこちらをご覧ください。](#rocksdbの使用の詳細)
サンプルの`rippled-example.cfg`ファイルでは、`[node_db]`節の`type`フィールドが`NuDB`に設定されています。
#### RocksDBの使用の詳細
[RocksDB](https://rocksdb.org/docs/getting-started.html)は、組み込み可能で永続的なkey-valueストアです。
**注記：** 2021年後半、元帳の総サイズが大きくなったため、RocksDBを使用しているサーバーはメインネットとの同期を十分に維持できないことがありました。大容量のRAMがあれば問題ありませんが、通常はNuDBを使用してください。
RocksDBは、SSDまたはHHDでの動作を想定しています。RocksDBは、NuDBに比べて必要とする[ディスク容量](#ディスク容量)が約3分の1少なくてすみ、I/O待ち時間が削減されます。ただし、I/O待ち時間が短い半面、データインデックスを格納するために、RocksDBは大量のRAMを必要とします。
RocksDBには、トランザクション処理のスループットを向上させるために調整できるパフォーマンス関連の設定オプションがあります。以下は、RocksDBを使用する`rippled`の推奨構成です。
```
[node_db]
type=RocksDB
path=/var/lib/rippled/db/rocksdb
open_files=512
filter_bits=12
cache_mb=512
file_size_mb=64
file_size_mult=2
online_delete=2000
advisory_delete=0
```
（`path`を、ディスク上でレジャーを維持するディレクトリーに設定します。`online_delete`と`advisory_delete`をお使いの構成に合わせて調整します。）
#### NuDBの使用の詳細
[NuDB](https://github.com/vinniefalco/nudb#introduction)は、SSDドライブ用に最適化された追加専用のkey-valueストアです。
NuDBは、[格納されているデータ量に関係なく](#ディスク容量)、ほぼ一定したパフォーマンスとメモリーフットプリントを提供します。NuDBはSSDを _必要とします_ が、大容量のデータベースにアクセスするために使用するRAMがRocksDBよりも大幅に少なくなっています。
本番サーバーは、NuDBを使用してユースケースに必要な履歴データ量を格納するように構成する必要があります。
NuDBには、`rippled.cfg`にパフォーマンス関連の構成オプションがありません。以下は、NuDBを使用する`rippled`における`[node_db]`の推奨構成です。
```
[node_db]
type=NuDB
path=/var/lib/rippled/db/nudb
online_delete=2000
advisory_delete=0
```
（`path`を、ディスク上でレジャーを維持するディレクトリーに設定します。`online_delete`と`advisory_delete`をお使いの構成に合わせて調整します。）
### ログレベル
サンプルの`rippled-example.cfg`ファイルの`[rpc_startup]`節では、ロギング詳細レベルが`warning`に設定されています。この設定を使用すると、より詳細なログ比べ、ディスク容量とI/O要件が大幅に緩和されます。ただし、より詳細なログレベルを設定すると、トラブルシューティングの際により細かな情報が得られます。
**注意:** `[rpc_startup]`節で`log_level`コマンドを省略すると、サーバーは`debug`レべルでディスクにログを書き込み、`warning`レベルのログをコンソールに出力します。 `debug` レベルのログは、`warning`レベルに比べ、トランザクション量とクライアントアクティビティーに基づいて、一日当たりに必要なディスク容量が数GB多くなります。
## ネットワークとハードウェア
XRP Ledgerネットワークの各サーバーは、ネットワークのすべての取引処理作業を行います。ネットワーク上の総活動量は変動しますが、ほとんどが時間の経過とともに増加していますので、現在のネットワーク活動に必要な容量よりも大きな容量のハードウェアを選択する必要があります。
`rippled`サーバーが、これらのネットワーク要件とハードウェア要件を満たすようにすることは、XRP Ledgerネットワーク全体で一貫した優れたパフォーマンスを実現するために役立ちます。
### 推奨事項
推奨されるハードウェアのスペックをまとめたものは、[システム要件](system-requirements.html)をご覧ください
#### CPU使用率および仮想化
ベアメタルを使用するとパフォーマンスが最大になりますが、ホストのハードウェアの仕様が十分であれば、仮想マシンでもほぼ同様のパフォーマンスが得られます。
#### ディスク速度
ストレージの速度は、サーバーの容量を左右する重要な要素の1つです。待ち時間の少ないランダム読み取りと高いスループットを備えた、グレードの高いソリッドステートディスク（SSD）の使用を _強くお勧めします。_ Rippleのエンジニアにより、以下の最大読み取り速度（秒）と書き込み速度（秒）が測定されています。
- （使用率が高いパブリックサーバークラスターで）秒あたり10,000回の読み取り
- （専用のパフォーマンステストで）秒あたり7,000回の書き込み
<!--{# TODO 2021-11: 測定内容が新しくなっているのであれば、更新が必要 #}-->
#### ディスク容量
`[node_db]`節はサーバの_レジャーの保存容量_を制御し、[レジャーの履歴](ledger-history.html)を保持します。必要なディスク容量は、どの程度の履歴をローカルに保存するかによって決まります。XRP Ledgerサーバーは、コンセンサス・プロセスを追跡し、レジャーの完全な状態を報告するために、最新の256以上のレジャーバージョンを保存する必要はありません。ただし、サーバーで照会できる実行済みトランザクションは、ローカルで保存されたレジャーバージョンにあるものだけです。`[node_db]`の`path`を設定して、レジャーの保存場所を決めてください。
保持するデータ量は、[オンライン削除](online-deletion.html)で管理できます。デフォルトの構成ファイルの設定では、サーバーは最新の2000のレジャーバージョンを保持します。オンライン削除を使用しないと、サーバーのディスク要件が際限なく増え続けます。
以下のテーブルは、本書の執筆時点（2018年12月13日）における、様々な履歴量の要件をまとめたものです。
| 実際の時間 | レジャーバージョンの数 | 必要なディスク容量（RocksDB） | 必要なディスク容量（NuDB） |
|:-----------------|:--------------------------|:------------------------------|:--|
| 2時間 | 2,000 | 250MB | 450MB |
| 1日 | 25,000 | 8GB | 12GB |
| 14日 | 350,000 | 112GB | 168GB |
| 30日 | 750,000 | 240GB | 360GB |
| 90日 | 2,250,000 | 720GB | 1TB |
| 1年 | 10,000,000 | 3TB | 4.5TB |
| 2年 | 20,000,000 | 6TB | 9TB |
| 完全な履歴（2020-11-10まで） | 59,000,000+ | （非推奨） | ~14TB |
これらの数値は概算です。様々な要因によって変わりますが、最も重要なのはネットワーク内のトランザクション量です。トランザクション量が増えるにつれ、各レジャーバージョンはより多くの固有データを格納します。今後の拡大に備え、予備のストレージ容量を準備しておくことをお勧めします。
`online_delete`設定は、古い履歴の削除後に保持するレジャーバージョンの数を指定するものです。オンライン削除が実行される直前レジャーの最大数の2倍を格納できるほどの十分な容量を計画する必要があります。
保持する履歴量の変更方法については、[オンライン削除の設定](configure-online-deletion.html)を参照してください。
`[database_path]`では、個別のデータベースを設定します。これらには、トランザクションデータといくつかのランタイム設定が含まれます。
一般的なルールとして、実行されていない`rippled`サーバーのデータベースファイル（レジャーストアとデータベースの両方）を安全に削除することができます。これにより、サーバーに保存されているレジャーの履歴はすべて消去されますが、そのデータをネットワークから再取得することができます。ただし、`[database_path]`にある`wallet.db`ファイルを削除すると、[Amendment 投票](configure-amendment-voting.html)や[ピアリザベーション](use-a-peer-reservation.html)などのランタイムの設定変更を手動で再適用しなければなりません。
レジャー履歴を格納したくても、全履歴を格納するための十分な容量がない場合には、[履歴シャーディング](history-sharding.html)機能を使用して個別の共有ストアにランダムな範囲のレジャーを格納できます。履歴シャーディングは、`[shard_db]`節で構成されます。
##### Amazon Web Services
Amazon Web Services（AWS）は、人気のある仮想化ホスト環境です。AWSで`rippled`を実行することはできますが、RippleではElastic Block Storage（EBS）の使用はお勧めしません。Elastic Block Storageの最大IOPS数（5,000）は、非常に高額であるにもかかわらず、`rippled`の最大負荷には不十分です。
AWSインスタンスストア（`ephemeral`ストレージ）では適切なパフォーマンスが提供されます。しかし、インスタンスを開始/停止するときなど、いくつかの状況でデータが失われる可能性があります。しかし、個々のXRP Ledgerサーバーは、通常、失われたレジャーの履歴を他サーバーから再取得することができるので、これは許容範囲内でしょう。設定内容は、より信頼性の高いストレージに保存する必要があります。
`[node_db]`節の`path`と`[database_path]`の両方が、適切なストレージを指していることを確認してください。
#### RAM/メモリー
メモリー要件は、主に`node_size`構成設定の機能であり、履歴データを取得するクライアントトラフィック量です。メモリー要件についての詳細は、[ノードサイズ](#ノードサイズ)を参照してください。
#### ネットワーク
企業や企業レベルのデータセンターでは、XRP Ledgerサーバーの稼働をサポートするために、非常に大きなネットワーク帯域幅が必要です。実際に必要な帯域幅は、ネットワークにおける現在のトランザクション量に応じて大きく変わります。サーバーの動作（[レジャー履歴](ledger-history.html)の埋め戻しなど）もネットワークに影響します。一般的な家庭用インターネットでは、信頼性の高いサーバーを稼働させるには不十分です。
トランザクション量が非常に多い時期には、サーバーが100メガビット/秒のネットワークリンクを完全に飽和してしまうという報告を受けた事業者もあります。そのため、信頼性の高いパフォーマンスを実現するためには、ギガビット・ネットワーク・インターフェースが必要となります。
以下は、一般的なタスクで使用されるネットワーク帯域幅の例です。
| タスク | 転送量/受信量 |
|:------------------------------------------------|:---------------------------|
| 現在のトランザクション量を処理する | 2Mbpsの転送、2Mbpsの受信 |
| ピーク時のトランザクション量を処理 | 100Mbps以上の転送 |
| 履歴レジャーとトランザクションレポートを提供する | 100Mbps以上の転送 |
| `rippled`の起動 | 20Mbpsの受信 |
[P2P通信で圧縮を有効にする](enable-link-compression.html)ことで帯域幅を節約することができますが、その代償としてCPU使用率が高くなります。多くのハードウェア構成では、通常の使用時にはCPUの容量に余裕があるため、ネットワークの帯域幅が限られている場合には、この方法が経済的な選択肢となります。
## 関連項目
- **コンセプト:**
- [`rippled`サーバー](xrpl-servers.html)
- [コンセンサスについて](consensus.html)
- **チュートリアル:**
- [`rippled`の構成](configure-rippled.html)
- [オンライ削除の設定](configure-online-deletion.html) - サーバーが一度に保持するレジャー履歴のバージョン数を調整します。
- [`rippled`のトラブルシューティング](troubleshoot-the-rippled-server.html)
- **リファレンス:**
- [rippled APIリファレンス](http-websocket-apis.html)
- [`rippled`コマンドラインの使用](commandline-usage.html)
- [logrotate メソッド][] - サーバーのデバッグログを閉じたり再開したりして、標準的なツールでローテーション可能にします。
- [server_info メソッド][] - 同期の状態や、ディスク上で利用可能なレジャー履歴のバージョン数など、サーバーに関する一般的な情報を取得します。
- [get_counts メソッド][] - 追加のサーバの正常情報、特にRAM内に様々な種類のオブジェクトをいくつ保持しているかを取得します。
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

213
content/infrastructure/rippled/installation/capacity-planning.md Normal file
View File

@@ -0,0 +1,213 @@
---
html: capacity-planning.html
parent: install-rippled.html
blurb: Plan system specs and tune configuration for rippled in production environments.
labels:
- Core Server
- Data Retention
---
# Capacity Planning
This document describes configuration, network, and hardware recommendations that you can use to tune and optimize the performance of an XRP Ledger server.
The load on an XRP Ledger server varies based on multiple factors. One is the activity in the network. The total size of data in the shared ledger and the total volume of transactions being sent vary based on organic factors throughout the global XRP Ledger community. Another factor is API usage; different types of [API calls](http-websocket-apis.html) put different load on the server. The performance characteristics can be very different between servers that provide a public API, provide a private API to specific integration software, or provide no API at all.
You should consider these factors to ensure that your server has the capacity to handle XRP Ledger network activity today and in the future.
## Configuration Settings
The default configuration file contains settings for a broad range of common use cases. You can get better performance by customizing the settings for your specific hardware and intended usage pattern.
The settings in this section are parameters in the `rippled.cfg` file. You can access an example config file, `rippled-example.cfg`, in the [`cfg` directory](https://github.com/ripple/rippled/blob/develop/cfg/rippled-example.cfg) in the `rippled` GitHub repo. The settings in the example config file match the default config installed alongside the server.
### Node Size
The `[node_size]` parameter should match the overall hardware capacity of your server. You can omit this parameter to have the server automatically choose an appropriate setting based on the system's total RAM and number of CPU threads. You can set this value explicitly if the automatic setting is wrong for your system, for example if some of the system's RAM or threads need to be set aside for other software, or the amounts reported by the operating system are inaccurate. (This can occur in some containers.) [Updated in: rippled 1.8.1][]
As a general rule, you should always use the largest node size your available RAM can support. See the following table for recommended settings.
#### Recommendation
Each `[node_size]` has a corresponding requirement for available RAM. For example, if you set `[node_size]` to `huge`, you should have at least 32 GB of available RAM to help ensure that `rippled` can run smoothly.
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 | `node_size` value | Notes |
|:--------------|:------------------|:-----------------------------------------|
| < 8 GB | `tiny` | **Not recommended.** A server with this setting may not sync to a busy network. |
| 8 GB | `small` | Recommended for test servers that only need to run occasionally. |
| 16 GB | `medium` | The `rippled-example.cfg` file uses this value. |
| 32 GB | `large` | **Not recommended.** In practice, this setting performs worse than `huge` in most circumstances. Always use `huge` if you want stability. |
| 64 GB | `huge` | Recommended for production servers. |
If you set the `[node_size]` parameter to an invalid value, the [server fails to start](server-wont-start.html#bad-node_size-value).
### Node DB Type
The `type` field in the `[node_db]` stanza of the `rippled.cfg` file sets the type of key-value store that `rippled` uses to hold the ledger store.
For almost all purposes, use `NuDB`. A fast SSD is required. [Learn more](#more-about-using-nudb)
The `RocksDB` setting is available for legacy purposes, but is generally not recommended. [Learn more](#more-about-using-rocksdb)
The example `rippled-example.cfg` file has the `type` field in the `[node_db]` stanza set to `NuDB`.
#### More About Using RocksDB
[RocksDB](https://rocksdb.org/docs/getting-started.html) is a persistent key-value store built into `rippled`. **Support for RocksDB is considered legacy.** Servers using RocksDB usually struggle to maintain sync with the Mainnet due to the memory requirements of maintaining a large database. Generally, you should use NuDB instead.
Cases where you might use RocksDB include if you need to load historical data saved in RocksDB format, or if you are storing data on slow SSDs or rotational disks. While rotational disks won't be able to keep up with Mainnet, you can probably run offline tests or small private networks on them.
RocksDB has performance-related configuration options that you can tweak for more transaction processing throughput. Here is an example `[node_db]` configuration for RocksDB:
```
[node_db]
type=RocksDB
path=/var/lib/rippled/db/rocksdb
open_files=512
filter_bits=12
cache_mb=512
file_size_mb=64
file_size_mult=2
online_delete=2000
advisory_delete=0
```
(Adjust the `path` to the directory where you want to keep the ledger store on disk. Adjust the `online_delete` and `advisory_delete` settings as desired for your configuration.)
#### More About Using NuDB
[NuDB](https://github.com/vinniefalco/nudb#introduction) is an append-only key-value store that is optimized for SSD drives.
NuDB has nearly constant performance and memory footprints regardless of the [amount of data being stored](#disk-space). NuDB _requires_ a solid-state drive. Scalability testing has shown that NuDB has equivalent or better performance than RocksDB in production and comparable configurations.
Production servers should be configured to use NuDB and to store the amount of historical data required for your use case.
NuDB does not have performance-related configuration options available in `rippled.cfg`. Here is the recommended `[node_db]` configuration for a `rippled` server using NuDB:
```
[node_db]
type=NuDB
path=/var/lib/rippled/db/nudb
online_delete=2000
advisory_delete=0
```
Adjust the `path` to the directory where you want to keep the ledger store on disk. Adjust the `online_delete` and `advisory_delete` settings as desired for your configuration. For more details about these settings, see [Configure Online Deletion](configure-online-deletion.html) and [Configure Advisory Deletion](configure-advisory-deletion.html).
### Log Level
The example `rippled-example.cfg` file sets the logging verbosity to `warning` in the `[rpc_startup]` stanza. This setting greatly reduces disk space and I/O requirements over more verbose logging. However, more verbose logging provides increased visibility for troubleshooting.
**Caution:** If you omit the `log_level` command from the `[rpc_startup]` stanza, the server writes logs to disk at the `debug` level and outputs `warning` level logs to the console. Logging at the `debug` level requires several more GB of disk space per day than `warning` level, depending on transaction volumes and client activity.
## Network and Hardware
Each server in the XRP Ledger network performs all of the transaction processing work of the network. Total activity on the network varies but has mostly increased over time, so you should choose hardware with greater capacity than you need for the current network activity.
### Recommendation
See [System Requirements](system-requirements.html) for a summary of the recommended hardware specs.
#### CPU Utilization and Virtualization
<!-- STYLE_OVERRIDE: utilization -->
You'll get the best performance on bare metal, but virtual machines can perform nearly as well as long as the host hardware has high enough specs.
#### Disk Speed
The speed of storage is one of the most important factors in a server's capacity. Use a high-grade solid state disk drive (SSD) with low-latency random reads and high throughput. Ripple engineers have observed the following maximum reads and writes per second:
- Over 10,000 reads per second (in heavily-used public server clusters)
- Over 7,000 writes per second (in dedicated performance testing)
<!--{# TODO 2021-11: have bigger numbers been seen lately? These might need an update #}-->
#### Disk Space
The `[node_db]` stanza controls the server's _ledger store_, which holds [ledger history](ledger-history.html). The amount of disk space you need depends on how much history you plan to keep available locally. An XRP Ledger server does not need to store more than the most recent 256 ledger versions to follow the consensus process and report the complete state of the ledger, but you can only query your server for transactions that executed in ledger versions it has stored locally. Configure the `path` of the `[node_db]` to point to your chosen storage location for the ledger store.
You can control how much data you keep with [online deletion](online-deletion.html); the default config file has the server keep the latest 2000 ledger versions. Without online deletion, the server's disk requirements grow without bounds.
The following table approximates the requirements for different amounts of history, at the time of writing (2023-07-19):
| Real Time Amount | Number of Ledger Versions | Disk Space Required (NuDB) |
|:-----------------|:--------------------------|:---------------------------|
| 2 hours | 2,000 | 450 MB |
| 1 day | 25,000 | 12 GB |
| 14 days | 350,000 | 168 GB |
| 30 days | 750,000 | 360 GB |
| 90 days | 2,250,000 | 1 TB |
| 1 year | 10,000,000 | 4.5 TB |
| 2 years | 20,000,000 | 9 TB |
| Full history | 81,000,000+ | ~26 TB |
These numbers are estimates. They depend on several factors, most importantly the volume of transactions in the network. As transaction volume increases, each ledger version stores more unique data. You should provision extra storage capacity to prepare for future growth.
The `online_delete` setting tells the server how many ledger versions to keep after deleting old history. You should plan for enough disk space to store twice that many ledger versions at maximum (right before online deletion runs).
For instructions on how to change the amount of history you keep, see [Configure Online Deletion](configure-online-deletion.html).
The `[database_path]` configures separate bookkeeping databases: these include transaction data as well as some runtime configurations.
As a general rule, you can safely delete the database files (both the ledger store and the bookkeeping databases) for a `rippled` server when it isn't running; this clears any stored ledger history the server has, but it can re-acquire that data from the network. However, if you delete the `wallet.db` file in the `[database_path]`, you must manually reapply runtime configuration changes such as [amendment votes](configure-amendment-voting.html) and [peer reservations](use-a-peer-reservation.html).
If you want to contribute to storing ledger history but you do not have enough disk space to store full history, you can use the [History Sharding](history-sharding.html) feature to store a randomized range of ledgers in a separate shard store. History sharding is configured in the `[shard_db]` stanza.
##### Amazon Web Services
Amazon Web Services (AWS) is a popular virtualized hosting environment. You can run `rippled` in AWS, but do not use Elastic Block Storage (EBS). See [System Requirements](system-requirements.html). <!-- SPELLING_IGNORE: ebs, aws -->
AWS instance stores (`ephemeral` storage) provide suitable performance, but you may lose data in some circumstances, including when you start/stop an instance. This may be acceptable, since an individual XRP Ledger server can usually re-acquire lost ledger history from its peers. Configuration settings should be stored on more permanent storage.
Make sure the `path` of your `[node_db]` stanza and your `[database_path]` both point to the appropriate storage.
#### RAM/Memory
Memory requirements are mainly a function of the `node_size` configuration setting and the amount of client traffic retrieving historical data. For more information about memory requirements, see [Node Size](#node-size).
#### Network
Any enterprise or carrier-class data center should have enough network bandwidth to support running XRP Ledger servers. The actual bandwidth necessary varies significantly based on the current transaction volume in the network. Server behavior (such as backfilling [ledger history](ledger-history.html)) also affects network use. Consumer-grade home internet is generally not enough to run a reliable server.
During exceptionally high periods of transaction volume, some operators have reported that their servers have completely saturated a 100 megabit/s network link, so a gigabit network interface is required for reliable performance.
Here are examples of observed uncompressed network bandwidth use for common tasks:
| Task | Send/Receive |
|:------------------------------------------------|:-----------------------|
| Process average transaction volumes | 2 Mbps up, 2 Mbps down |
| Process peak transaction volumes | >100 Mbps up |
| Serve historical ledger and transaction reports | 100 Mbps up |
| Start up `rippled` | 20 Mbps down |
You can save bandwidth by [enabling compression on peer-to-peer communications](enable-link-compression.html), at a cost of higher CPU. Many hardware configurations have spare CPU capacity during normal use, so this can be an economical option if your network bandwidth is limited.
## See Also
- **Concepts:**
- [The `rippled` Server](xrpl-servers.html)
- [Consensus](consensus.html)
- **Tutorials:**
- [Configure rippled](configure-rippled.html)
- [Configure Online Deletion](configure-online-deletion.html) - Adjust how many historical ledger versions your server should keep at a time.
- [Troubleshoot rippled](troubleshoot-the-rippled-server.html)
- **References:**
- [rippled API Reference](http-websocket-apis.html)
- [`rippled` Commandline Usage](commandline-usage.html)
- [logrotate method][] - Closes and reopens the server's debug log so you can rotate it with standard tools.
- [server_info method][] - General information about the server including sync status and how many historical ledger versions it has available on disk.
- [get_counts method][] - Additional health information, especially how many objects of various types it holds in RAM.
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

80
content/infrastructure/rippled/installation/install-rippled-on-centos-rhel-with-yum.ja.md Normal file
View File

@@ -0,0 +1,80 @@
---
html: install-rippled-on-centos-rhel-with-yum.html
parent: install-rippled.html
blurb: プリコンパイル済みのrippledバイナリーをCentOSまたはRed Hat Enterprise Linuxにインストールします。
labels:
- コアサーバー
---
# yumを使用したCentOS/Red Hatへのインストール
このページでは、Rippleの[yum](https://en.wikipedia.org/wiki/Yellowdog_Updater,_Modified)リポジトリを使用して、**CentOS 7**または**Red Hat Enterprise Linux 7**に、`rippled`の安定した最新バージョンをインストールする場合の推奨手順を説明します。
以下の手順では、Rippleによってコンパイルされたバイナリーをインストールします。
## 前提条件
`rippled`をインストールする前に、[システム要件](system-requirements.html)を満たす必要があります。
## インストール手順
1. Ripple RPMリポジトリをインストールします。
$ cat << REPOFILE | sudo tee /etc/yum.repos.d/ripple.repo
[ripple-stable]
name=XRP Ledger Packages
baseurl=https://repos.ripple.com/repos/rippled-rpm/stable/
enabled=1
gpgcheck=0
gpgkey=https://repos.ripple.com/repos/rippled-rpm/stable/repodata/repomd.xml.key
repo_gpgcheck=1
REPOFILE
2. 最新のrepoのアップデートを取得します。
$ sudo yum -y update
3. 新しい`rippled`パッケージをインストールします。
$ sudo yum install rippled
バージョン1.3.1では、構成ファイル（`rippled.cfg`および`validators.txt`）を変更する必要はありません。このアップデート手順では、既存の構成ファイルが現在のまま残ります。
4. systemdユニットファイルを再度読み込みます。
$ sudo systemctl daemon-reload
5. 起動時に開始するように、`rippled`サービスを設定します。
$ sudo systemctl enable rippled.service
6. `rippled`サービスを開始します。
$ sudo systemctl start rippled.service
## 次のステップ
{% include '_snippets/post-rippled-install.ja.md' %}<!--_ -->
## 関連項目
- **コンセプト:**
- [`rippled`サーバー](xrpl-servers.html)
- [コンセンサスについて](consensus.html)
- **チュートリアル:**
- [rippledの構成](configure-rippled.html)
- [rippledのトラブルシューティング](troubleshoot-the-rippled-server.html)
- [rippled APIの使用開始](get-started-using-http-websocket-apis.html)
- **リファレンス:**
- [rippled APIリファレンス](http-websocket-apis.html)
- [`rippled`コマンドラインの使用](commandline-usage.html)
- [server_infoメソッド][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

114
content/infrastructure/rippled/installation/install-rippled-on-centos-rhel-with-yum.md Normal file
View File

@@ -0,0 +1,114 @@
---
html: install-rippled-on-centos-rhel-with-yum.html
parent: install-rippled.html
blurb: Install a precompiled rippled binary on CentOS or Red Hat Enterprise Linux.
labels:
- Core Server
---
# Install on CentOS/Red Hat with yum
This page describes the recommended instructions for installing the latest stable version of `rippled` on **CentOS 7** or **Red Hat Enterprise Linux 7**, using Ripple's [yum](https://en.wikipedia.org/wiki/Yellowdog_Updater,_Modified) repository.
These instructions install a binary that has been compiled by Ripple.
## Prerequisites
Before you install `rippled`, you must meet the [System Requirements](system-requirements.html).
## Installation Steps
1. Install the Ripple RPM repository:
Choose the appropriate RPM repository for the stability of releases you want:
- `stable` for the latest production release (`master` branch)
- `unstable` for pre-release builds (`release` branch)
- `nightly` for experimental/development builds (`develop` branch)
<!-- MULTICODE_BLOCK_START -->
*Stable*
cat << REPOFILE | sudo tee /etc/yum.repos.d/ripple.repo
[ripple-stable]
name=XRP Ledger Packages
enabled=1
gpgcheck=0
repo_gpgcheck=1
baseurl=https://repos.ripple.com/repos/rippled-rpm/stable/
gpgkey=https://repos.ripple.com/repos/rippled-rpm/stable/repodata/repomd.xml.key
REPOFILE
*Pre-release*
cat << REPOFILE | sudo tee /etc/yum.repos.d/ripple.repo
[ripple-unstable]
name=XRP Ledger Packages
enabled=1
gpgcheck=0
repo_gpgcheck=1
baseurl=https://repos.ripple.com/repos/rippled-rpm/unstable/
gpgkey=https://repos.ripple.com/repos/rippled-rpm/unstable/repodata/repomd.xml.key
REPOFILE
*Development*
cat << REPOFILE | sudo tee /etc/yum.repos.d/ripple.repo
[ripple-nightly]
name=XRP Ledger Packages
enabled=1
gpgcheck=0
repo_gpgcheck=1
baseurl=https://repos.ripple.com/repos/rippled-rpm/nightly/
gpgkey=https://repos.ripple.com/repos/rippled-rpm/nightly/repodata/repomd.xml.key
REPOFILE
<!-- MULTICODE_BLOCK_START -->
2. Fetch the latest repo updates:
sudo yum -y update
3. Install the new `rippled` package:
sudo yum install rippled
4. Reload systemd unit files:
sudo systemctl daemon-reload
5. Configure the `rippled` service to start on boot:
sudo systemctl enable rippled.service
6. Start the `rippled` service:
sudo systemctl start rippled.service
## Next Steps
{% include '_snippets/post-rippled-install.md' %}<!--_ -->
## See Also
- **Concepts:**
- [The `rippled` Server](xrpl-servers.html)
- [Consensus](consensus.html)
- **Tutorials:**
- [Configure rippled](configure-rippled.html)
- [Troubleshoot rippled](troubleshoot-the-rippled-server.html)
- [Get Started with the rippled API](get-started-using-http-websocket-apis.html)
- **References:**
- [rippled API Reference](http-websocket-apis.html)
- [`rippled` Commandline Usage](commandline-usage.html)
- [server_info method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

109
content/infrastructure/rippled/installation/install-rippled-on-ubuntu.ja.md Normal file
View File

@@ -0,0 +1,109 @@
---
html: install-rippled-on-ubuntu.html
parent: install-rippled.html
blurb: プリコンパイル済みのrippledバイナリーをUbuntu Linuxにインストールします。
labels:
- コアサーバー
---
# UbuntuまたはDebian Linuxへのインストール
このページでは、[`apt`](https://ubuntu.com/server/docs)ユーティリティを使用して、**Ubuntu Linux 18.04以降**または**Debian 10** に`rippled`の安定した最新バージョンをインストールする場合の推奨手順を説明します。
以下の手順では、Rippleによってコンパイルされたバイナリーをインストールします。
## 前提条件
`rippled`をインストールする前に、[システム要件](system-requirements.html)を満たす必要があります。
## インストール手順
1. リポジトリを更新します。
sudo apt -y update
2. ユーティリティをインストールします。
sudo apt -y install apt-transport-https ca-certificates wget gnupg
3. Rippleのパッケージ署名用のGPGキーを、信頼できるキーのリストに追加します。
sudo mkdir /usr/local/share/keyrings/
wget -q -O - "https://repos.ripple.com/repos/api/gpg/key/public" | gpg --dearmor > ripple-key.gpg
sudo mv ripple-key.gpg /usr/local/share/keyrings
4. 追加したキーのフィンガープリントを確認します。
gpg /usr/local/share/keyrings/ripple-key.gpg
出力に、次のようなRipple用のエントリーが含まれています。
gpg: WARNING: no command supplied. Trying to guess what you mean ...
pub rsa3072 2019-02-14 [SC] [expires: 2026-02-17]
C0010EC205B35A3310DC90DE395F97FFCCAFD9A2
uid TechOps Team at Ripple <techops+rippled@ripple.com>
sub rsa3072 2019-02-14 [E] [expires: 2026-02-17]
特に、フィンガープリントが一致することを確認してください。（上記の例では、フィンガープリントは三行目の`C001`で始まる部分です。）
5. 使用しているオペレーティングシステムのバージョンに対応する適切なRippleリポジトリを追加します。
echo "deb [signed-by=/usr/local/share/keyrings/ripple-key.gpg] https://repos.ripple.com/repos/rippled-deb focal stable" | \
sudo tee -a /etc/apt/sources.list.d/ripple.list
上記の例は、**Ubuntu 20.04 Focal Fossa**に適切です。その他のオペレーティングシステムについては、`focal`という単語を次のいずれかに置き換えます。
- `bionic` for **Ubuntu 18.04 Bionic Beaver**
- `buster` for **Debian 10 Buster**
- `bullseye` for **Debian 11 Bullseye**
- `jammy` for **Ubuntu 22.04 Jammy Jellyfish**
`rippled`の開発バージョンまたはプレリリースバージョンにアクセスするには、`stable`ではなく次のいずれかを使用します。
- `unstable` - プレインストールビルド（[`release`ブランチ](https://github.com/ripple/rippled/tree/release)）
- `nightly` - 実験/開発ビルド（[`develop`ブランチ](https://github.com/ripple/rippled/tree/develop)）
**警告:** 安定版ではないナイトリービルドはいつの時点でも壊れる可能性があります。これらのビルドを本番環境のサーバーに使用しないでください。
6. Rippleリポジトリを取得します。
sudo apt -y update
7. `rippled`ソフトウェアパッケージをインストールします。
sudo apt -y install rippled
8. `rippled`サービスのステータスをチェックします。
systemctl status rippled.service
`rippled`サービスが自動的に開始します。開始しない場合は、手動で開始できます。
sudo systemctl start rippled.service
## 次のステップ
{% include '_snippets/post-rippled-install.ja.md' %}
<!--_ -->
## 関連項目
- **コンセプト:**
- [`rippled`サーバー](xrpl-servers.html)
- [コンセンサスについて](consensus.html)
- **チュートリアル:**
- [rippledの構成](configure-rippled.html)
- [rippledのトラブルシューティング](troubleshoot-the-rippled-server.html)
- [rippled APIの使用開始](get-started-using-http-websocket-apis.html)
- **リファレンス:**
- [rippled APIリファレンス](http-websocket-apis.html)
- [`rippled`コマンドラインの使用](commandline-usage.html)
- [server_infoメソッド][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

118
content/infrastructure/rippled/installation/install-rippled-on-ubuntu.md Normal file
View File

@@ -0,0 +1,118 @@
---
html: install-rippled-on-ubuntu.html
parent: install-rippled.html
blurb: Install a precompiled rippled binary on Ubuntu Linux.
labels:
- Core Server
---
# Install on Ubuntu or Debian Linux
This page describes the recommended instructions for installing the latest stable version of `rippled` on **Ubuntu Linux 18.04 or higher** or **Debian 10 or higher**, using the [`apt`](https://ubuntu.com/server/docs) utility.
These instructions install a binary that has been compiled by Ripple.
## Prerequisites
Before you install `rippled`, you must meet the [System Requirements](system-requirements.html).
## Installation Steps
1. Update repositories:
sudo apt -y update
2. Install utilities:
sudo apt -y install apt-transport-https ca-certificates wget gnupg
3. Add Ripple's package-signing GPG key to your list of trusted keys:
sudo mkdir /usr/local/share/keyrings/
wget -q -O - "https://repos.ripple.com/repos/api/gpg/key/public" | gpg --dearmor > ripple-key.gpg
sudo mv ripple-key.gpg /usr/local/share/keyrings/
4. Check the fingerprint of the newly-added key:
gpg --import --import-options show-only /usr/local/share/keyrings/ripple-key.gpg
The output should include an entry for Ripple such as the following:
pub rsa3072 2019-02-14 [SC] [expires: 2026-02-17]
C0010EC205B35A3310DC90DE395F97FFCCAFD9A2
uid TechOps Team at Ripple <techops+rippled@ripple.com>
sub rsa3072 2019-02-14 [E] [expires: 2026-02-17]
In particular, make sure that the fingerprint matches. (In the above example, the fingerprint is on the second line, starting with `C001`.)
4. Add the appropriate Ripple repository for your operating system version:
echo "deb [signed-by=/usr/local/share/keyrings/ripple-key.gpg] https://repos.ripple.com/repos/rippled-deb focal stable" | \
sudo tee -a /etc/apt/sources.list.d/ripple.list
The above example is appropriate for **Ubuntu 20.04 Focal Fossa**. For other operating systems, replace the word `focal` with one of the following:
- `bionic` for **Ubuntu 18.04 Bionic Beaver**
- `buster` for **Debian 10 Buster**
- `bullseye` for **Debian 11 Bullseye**
- `jammy` for **Ubuntu 22.04 Jammy Jellyfish**
If you want access to development or pre-release versions of `rippled`, use one of the following instead of `stable`:
- `unstable` - Pre-release builds ([`release` branch](https://github.com/ripple/rippled/tree/release))
- `nightly` - Experimental/development builds ([`develop` branch](https://github.com/ripple/rippled/tree/develop))
**Warning:** Unstable and nightly builds may be broken at any time. Do not use these builds for production servers.
5. Fetch the Ripple repository.
sudo apt -y update
6. Install the `rippled` software package:
sudo apt -y install rippled
7. Check the status of the `rippled` service:
systemctl status rippled.service
The `rippled` service should start automatically. If not, you can start it manually:
sudo systemctl start rippled.service
8. Optional: allow `rippled` to bind to privileged ports.
This allows you to serve incoming API requests on port 80 or 443. (If you want to do so, you must also update the config file's port settings.)
sudo setcap 'cap_net_bind_service=+ep' /opt/ripple/bin/rippled
## Next Steps
{% include '_snippets/post-rippled-install.md' %}
<!--_ -->
## See Also
- **Concepts:**
- [The `rippled` Server](xrpl-servers.html)
- [Consensus](consensus.html)
- **Tutorials:**
- [Configure rippled](configure-rippled.html)
- [Troubleshoot rippled](troubleshoot-the-rippled-server.html)
- [Get Started with the rippled API](get-started-using-http-websocket-apis.html)
- **References:**
- [rippled API Reference](http-websocket-apis.html)
- [`rippled` Commandline Usage](commandline-usage.html)
- [server_info method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

111
content/infrastructure/rippled/installation/rippled-1-3-migration-instructions.ja.md Normal file
View File

@@ -0,0 +1,111 @@
---
html: rippled-1-3-migration-instructions.html
parent: install-rippled.html
blurb: rippled 1.2.4以前のバージョンからrippled v1.3以降に移行するプロセスについて説明します。
---
# rippled v1.3.xへの移行手順
このドキュメントでは、`rippled` 1.2.4以前のバージョンから`rippled` v1.3以降に移行するプロセスについて説明します。`rippled`のインストールプロセスがバージョン1.3では変更されたため、この移行プロセスは必須です。
このドキュメントでは、サポートされるプラットフォームでアップグレードするための移行手順について説明します。
- [CentOSまたはRed Hat Enterprise Linux（RHEL）](#centosまたはred-hat-enterprise-linuxrhelでの移行)
- [Ubuntu Linux](#ubuntu-linuxでの移行)
その他のプラットフォームについては、ソースからコンパイルするためのアップデート手順を参照してください。（[Ubuntu](build-run-rippled-ubuntu.html)、[macOS](build-run-rippled-macos.html)、または[Windows](https://github.com/ripple/rippled/tree/develop/Builds/VisualStudio2017)）
## CentOSまたはRed Hat Enterprise Linux（RHEL）での移行
Rippleの公式RPMリポジトリとそれを使用するための手順が変更されました。[自動更新](update-rippled-automatically-on-linux.html)を有効にしている場合は、システムで移行が自動的に実行されます。以前のリポジトリから新しいリポジトリに手動で移行するには、以下の手順を実行します。
1. `rippled`サーバーを停止します。
$ sudo systemctl stop rippled.service
2. 以前のRippleリポジトリパッケージを削除します。
$ sudo rpm -e ripple-repo
`rippled-repo`パッケージは、現在**廃止予定**です。このパッケージはバージョン1.3.1に対応するために、最後にもう一度だけ更新されました。今後は、リポジトリに変更があれば、`ripple.repo`ファイルに手動で変更を加える必要があります。
3. Rippleの新しいyumリポジトリを追加します。
$ cat << REPOFILE | sudo tee /etc/yum.repos.d/ripple.repo
[ripple-stable]
name=XRP Ledger Packages
baseurl=https://repos.ripple.com/repos/rippled-rpm/stable/
enabled=1
gpgcheck=0
gpgkey=https://repos.ripple.com/repos/rippled-rpm/stable/repodata/repomd.xml.key
repo_gpgcheck=1
REPOFILE
4. 新しい`rippled`パッケージをインストールします。
$ sudo yum install rippled
バージョン1.3.1では、構成ファイル（`rippled.cfg`および`validators.txt`）を変更する必要はありません。このアップデート手順では、既存の構成ファイルが現在のまま残ります。
5. systemdユニットファイルを再度読み込みます。
$ sudo systemctl daemon-reload
6. `rippled`サービスを開始します。
$ sudo systemctl start rippled.service
**警告:** [自動更新](update-rippled-automatically-on-linux.html)を使用している場合、この移行プロセスを実行した後も自動更新が続きます。ただし、**`ripple-repo`パッケージは、現在は廃止予定**です。そのため、今後は、Rippleのリポジトリへの変更があれば、各自がrepoファイルを手動で更新する必要があります。
## Ubuntu Linuxでの移行
バージョン1.3より前では、Ubuntu Linuxに`rippled`をインストールする方法として、Alienを使用してRPMパッケージをインストールする方法がサポートされていました。`rippled`v1.3.1から、RippleはUbuntuおよびDebian Linux向けのネイティブパッケージを提供しており、これが推奨のインストール方法となります。すでにRPMパッケージをインストールしている場合は、[インストール手順](install-rippled-on-ubuntu.html)を実行して、パッケージをアップグレードし、ネイティブAPT（`.deb`）パッケージに切り替えます。
構成ファイル（`/opt/ripple/etc/rippled.cfg`および`/opt/ripple/etc/validators.txt`）に変更を加えている場合は、インストール中に`apt`から、構成ファイルをパッケージからの最新バージョンで上書きするかどうかを尋ねられる場合があります。バージョン1.3では、構成ファイルに変更を加える必要はありません。そのため、既存の構成ファイルはそのまま維持できます。
1.3用のネイティブAPTパッケージをインストールした後で、サービスを再読み込み/再起動する必要があります。
1. systemdユニットファイルを再度読み込みます。
$ sudo systemctl daemon-reload
2. `rippled`サービスを再起動します。
$ sudo systemctl restart rippled.service
他のパッケージ用にAlienを使用する必要がなくなった場合は、必要に応じて、次の手順でAlienとその依存関係をアンインストールできます。
1. Alienをアンインストールします。
$ sudo apt -y remove alien
2. 使用していない依存関係をアンインストールします。
$ sudo apt -y autoremove
### 自動更新
`rippled` v1.3パッケージには、UbuntuおよびDebian Linuxで動作する最新のauto-updateスクリプトが含まれています。詳細は、[Linuxでの`rippled`の自動更新](update-rippled-automatically-on-linux.html)を参照してください。
## 関連項目
- **[`rippled` v1.3.1リリースノート](https://github.com/ripple/rippled/releases/1.3.1)**
- **コンセプト:**
- [`rippled`サーバー](xrpl-servers.html)
- [コンセンサスについて](consensus.html)
- **チュートリアル:**
- [Linuxでの自動更新](update-rippled-automatically-on-linux.html)
- [rippledのトラブルシューティング](troubleshoot-the-rippled-server.html)
- [rippled APIの使用開始](get-started-using-http-websocket-apis.html)
- **リファレンス:**
- [rippled APIリファレンス](http-websocket-apis.html)
- [`rippled`コマンドラインの使用](commandline-usage.html)
- [server_infoメソッド][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

112
content/infrastructure/rippled/installation/rippled-1-3-migration-instructions.md Normal file
View File

@@ -0,0 +1,112 @@
---
html: rippled-1-3-migration-instructions.html
parent: install-rippled.html
blurb: Use these instructions to upgrade rippled packages from 1.2.x or below to 1.3.x or higher.
status: removed
---
# rippled v1.3.x Migration Instructions
This document describes the migration process for upgrading from `rippled` 1.2.4 or earlier to `rippled` v1.3 or later. This migration process is necessary because the `rippled` install process has changed as of version 1.3.
This document provides migration steps for upgrading on supported platforms:
- [CentOS or Red Hat Enterprise Linux (RHEL)](#migration-on-centos-or-red-hat-enterprise-linux-rhel)
- [Ubuntu Linux](#migration-on-ubuntu-linux)
For other platforms, see the updated instructions for compiling from source. ([Ubuntu](build-run-rippled-ubuntu.html), [macOS](build-run-rippled-macos.html), or [Windows](https://github.com/ripple/rippled/tree/develop/Builds/VisualStudio2017))
## Migration on CentOS or Red Hat Enterprise Linux (RHEL)
Ripple's official RPM repository and instructions for using it have changed. If you have [automatic updates](update-rippled-automatically-on-linux.html) enabled, your system should perform the migration automatically. To migrate manually from the old repository to the new one, complete the following steps:
1. Stop the `rippled` server.
$ sudo systemctl stop rippled.service
2. Remove the old Ripple repository package.
$ sudo rpm -e ripple-repo
The `rippled-repo` package is now **DEPRECATED**. The package has been updated one last time for version 1.3.1. In the future, any changes to the repositories will require manual changes to the `ripple.repo` file. <!-- STYLE_OVERRIDE: will -->
3. Add Ripple's new yum repository:
$ cat << REPOFILE | sudo tee /etc/yum.repos.d/ripple.repo
[ripple-stable]
name=XRP Ledger Packages
baseurl=https://repos.ripple.com/repos/rippled-rpm/stable/
enabled=1
gpgcheck=0
gpgkey=https://repos.ripple.com/repos/rippled-rpm/stable/repodata/repomd.xml.key
repo_gpgcheck=1
REPOFILE
4. Install the new `rippled` package:
$ sudo yum install rippled
Version 1.3.1 does not require any changes to your config files (`rippled.cfg` and `validators.txt`). This update procedure leaves your existing config files in place.
5. Reload systemd unit files:
$ sudo systemctl daemon-reload
6. Start the `rippled` service:
$ sudo systemctl start rippled.service
**Warning:** If you use [automatic updates](update-rippled-automatically-on-linux.html), they should continue working after performing this migration process. However, **the `ripple-repo` package is now deprecated**. As a consequence, in the future, any changes to Ripple's repositories may require you to manually update your repos file.
## Migration on Ubuntu Linux
Prior to version 1.3, the supported way to install `rippled` on Ubuntu Linux was using Alien to install the RPM package. Starting with `rippled` v1.3.1, Ripple provides a native package for Ubuntu and Debian Linux, which is the recommended way of installing it. If you already have the RPM package installed, complete the [installation steps](install-rippled-on-ubuntu.html) to upgrade the package and switch over to the native APT (`.deb`) package.
If you have made any changes to your config files (`/opt/ripple/etc/rippled.cfg` and `/opt/ripple/etc/validators.txt`), `apt` may prompt you during installation asking if you want to overwrite your config files with the newest versions from the packages. Version 1.3 does not require any changes to the config file, so you can safely keep your existing config files unchanged.
After installing the native APT package for 1.3, you need to reload/restart the service:
1. Reload systemd unit files:
$ sudo systemctl daemon-reload
2. Restart the `rippled` service:
$ sudo systemctl restart rippled.service
If you no longer need Alien for any other packages, you may optionally uninstall it and its dependencies using the following steps:
1. Uninstall Alien:
$ sudo apt -y remove alien
2. Uninstall unused dependencies:
$ sudo apt -y autoremove
### Automatic Updates
The `rippled` v1.3 package includes an updated auto-update script that works on Ubuntu and Debian Linux. For more information, see [Update `rippled` Automatically on Linux](update-rippled-automatically-on-linux.html).
## See Also
- **[`rippled` v1.3.1 Release Notes](https://github.com/ripple/rippled/releases/1.3.1)**
- **Concepts:**
- [The `rippled` Server](xrpl-servers.html)
- [Consensus](consensus.html)
- **Tutorials:**
- [Update Automatically on Linux](update-rippled-automatically-on-linux.html)
- [Troubleshoot rippled](troubleshoot-the-rippled-server.html)
- [Get Started with the rippled API](get-started-using-http-websocket-apis.html)
- **References:**
- [rippled API Reference](http-websocket-apis.html)
- [`rippled` Commandline Usage](commandline-usage.html)
- [server_info method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

56
content/infrastructure/rippled/installation/system-requirements.ja.md Normal file
View File

@@ -0,0 +1,56 @@
---
html: system-requirements.html
parent: install-rippled.html
blurb: rippledのハードウェアやソフトウェアのシステム要件
labels:
- コアサーバー
---
# システム要件
## 推奨される仕様
企業の本番環境で最良のパフォーマンスを実現するため、以下の仕様のベアメタルで`rippled`を実行することが推奨されています。
- オペレーティングシステム: Ubuntu (LTF) 、CentOS または Red Hat Enterprise Linux (最新版)
- CPU: Intel Xeon 3GHz以上のプロセッサー、8コア以上、ハイパースレッディング有効
- ディスク: SSD / NVMe（10,000 IOPS以上）
- RAM: 64GB
- ネットワーク: ホスト上にギガビットネットワークインターフェイスを備える企業データセンターネットワーク
## 最小仕様
テスト目的やたまにしか使わない場合は、一般的なハードウェア上でXRP Ledgerサーバーを稼働させることができます。以下の最低要件を満たせば、ほとんどの場合は動作しますが、必ずしも[ネットワークと同期](server-doesnt-sync.html)しているとは限りません。
- オペレーティングシステム: macOS、Windows（64ビット）、またはほとんどのLinuxディストリビューション(Red Hat、 Ubuntu、 Debianをサポート)
- CPU: 64ビット x86_64、4コア以上
- ディスク: データベースパーティション用に最低50GB。SSDを強く推奨（最低でも1000IOPS、それよりも多いことが望ましい）
- RAM: 16GB以上
作業負荷によっては、Amazon EC2の`m3.large` VMサイズが適切な場合があります。高速のネットワーク接続が望ましいです。サーバーのクライアント処理負荷が増加すると、必要なリソースも増加します。
## システム時刻
`rippled`サーバーは、正確な時刻が維持されていることを前提としています。`ntpd`や`chrony`などのデーモンで、ネットワークタイムプロトコル（NTP）を使用してシステムの時刻を同期することを推奨します。
## 関連項目
- **コンセプト:**
- [`rippled`サーバー](xrpl-servers.html)
- [コンセンサスについて](consensus.html)
- **チュートリアル:**
- [容量の計画](capacity-planning.html) - 本番環境向けの推奨仕様および計画についての詳細情報
- [`rippled`のインストール](install-rippled.html)
- [rippledのトラブルシューティング](troubleshoot-the-rippled-server.html)
- **リファレンス:**
- [rippled APIリファレンス](http-websocket-apis.html)
- [`rippled`コマンドラインの使用](commandline-usage.html)
- [server_infoメソッド][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

60
content/infrastructure/rippled/installation/system-requirements.md Normal file
View File

@@ -0,0 +1,60 @@
---
html: system-requirements.html
parent: install-rippled.html
blurb: Hardware and software requirements for running rippled.
labels:
- Core Server
---
# System Requirements
## Recommended Specifications
For reliable performance in production environments, it is recommended to run an XRP Ledger (`rippled`) server on bare metal with the following characteristics or better:
- Operating System: Ubuntu (LTS), Red Hat Enterprise Linux (latest release), or a compatible Linux distribution.
- CPU: Intel Xeon 3+ GHz processor with 8+ cores and hyperthreading enabled.
- Disk: SSD / NVMe (10,000 IOPS sustained - not burst or peak - or better). Minimum 50 GB for the database partition. Do not use Amazon Elastic Block Store (AWS EBS) because its latency is too high to sync reliably.
- RAM: 64 GB.
- Network: Enterprise data center network with a gigabit network interface on the host.
## Minimum Specifications
For testing purposes or occasional use, you can run an XRP Ledger server on commodity hardware. The following minimum requirements should work for most cases, but may not always [stay synced with the network](server-doesnt-sync.html):
- Operating System: macOS, Windows (64-bit), or most Linux distributions (Red Hat, Ubuntu, and Debian supported).
- CPU: 64-bit x86_64, 4+ cores.
- Disk: SSD / NVMe (10,000 IOPS sustained - not burst or peak - or better). Minimum 50 GB for the database partition. Do not use Amazon Elastic Block Store (AWS EBS) because its latency is too high to sync reliably.
- RAM: 16 GB+.
<!-- SPELLING_IGNORE: iops, ntp, x86_64, ec2, nvme -->
Amazon EC2's `i3.2xlarge` 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.
For a validator, consider `z1d.2xlarge` with an extra 1 TB disk for logging and core dump storage.
## System Time
A `rippled` server relies on maintaining the correct time. It is recommended that the system synchronize time using the Network Time Protocol (NTP) with daemons such as `ntpd` or `chrony`.
## See Also
- **Concepts:**
- [The `rippled` Server](xrpl-servers.html)
- [Consensus](consensus.html)
- **Tutorials:**
- [Capacity Planning](capacity-planning.html) - More information on the recommended specifications and planning for production needs
- [Install `rippled`](install-rippled.html)
- [Troubleshoot rippled](troubleshoot-the-rippled-server.html)
- **References:**
- [rippled API Reference](http-websocket-apis.html)
- [`rippled` Commandline Usage](commandline-usage.html)
- [server_info method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

51
content/infrastructure/rippled/installation/update-rippled-automatically-on-linux.ja.md Normal file
View File

@@ -0,0 +1,51 @@
---
html: update-rippled-automatically-on-linux.html
parent: install-rippled.html
blurb: Linuxでrippledの自動更新を設定します。
labels:
- コアサーバー
- セキュリティ
---
# Linuxでの自動更新
Linuxでは、`rippled`が1回限りの`cron`構成を使用して最新バージョンに自動的にアップグレードされるように設定できます。可能であれば自動更新を有効にしておくことが推奨されます。
以下の手順では、`rippled`が[`yum`リポジトリから（CentOS/RedHat）](install-rippled-on-centos-rhel-with-yum.html)、または[`apt`（Ubuntu/Debian）を使用して](install-rippled-on-ubuntu.html)インストールされていることを前提としています。
自動更新を設定するには、以下の手順に従います。
1. `/opt/ripple/etc/update-rippled-cron`が存在することを確認します。存在しない場合は、（[CentOS/Red Hat](update-rippled-manually-on-centos-rhel.html)または[Ubuntu/Debian](update-rippled-manually-on-ubuntu.html)を）手動で更新します。
2. `cron.d`フォルダーに、`/opt/ripple/etc/update-rippled-cron`構成ファイルへのsymlinkを作成します。
$ sudo ln -s /opt/ripple/etc/update-rippled-cron /etc/cron.d/
このcron構成は、インストール済みの`rippled`パッケージを新版のリリース後1時間以内に更新するためのスクリプトを実行します。同時に更新を実行しているすべてのサーバーが停止する可能性を抑えるため、このスクリプトは`rippled`サービスを再起動しません。手動再起動しますまで、以前のバージョンを実行し続けます。[新規: rippled 1.8.1][]
3. 新しいリリースが公開された後、`rippled`サービスを手動再起動する。
sudo systemctl restart rippled.service
**注意:** 将来的には、Rippleのリポジトリが変更された場合に、更新を検索するスクリプトが実行されるURLの手動更新が必要となることがあります。必要な変更についての最新情報は、[XRP Ledgerブログ](/blog/)または[ripple-serverメーリングリスト](https://groups.google.com/forum/#!forum/ripple-server)でお知らせします。
## 関連項目
- **コンセプト:**
- [`rippled`サーバー](xrpl-servers.html)
- [コンセンサスについて](consensus.html)
- **チュートリアル:**
- [容量の計画](capacity-planning.html)
- [rippledのトラブルシューティング](troubleshoot-the-rippled-server.html)
- **リファレンス:**
- [rippled APIリファレンス](http-websocket-apis.html)
- [`rippled`コマンドラインの使用](commandline-usage.html)
- [server_infoメソッド][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

49
content/infrastructure/rippled/installation/update-rippled-automatically-on-linux.md Normal file
View File

@@ -0,0 +1,49 @@
---
html: update-rippled-automatically-on-linux.html
parent: install-rippled.html
blurb: Set up automatic updates for rippled on Linux.
labels:
- Core Server
- Security
---
# Update Automatically on Linux
On Linux, you can set up `rippled` to automatically upgrade to the latest version with a one-time `cron` configuration. Ripple recommends enabling automatic updates if possible.
These instructions assume you have already installed `rippled` [from the `yum` repository (CentOS/RedHat)](install-rippled-on-centos-rhel-with-yum.html) or [using `apt` (Ubuntu/Debian)](install-rippled-on-ubuntu.html).
To set up automatic updates, complete the following steps:
1. Check that `/opt/ripple/etc/update-rippled-cron` exists. If it does not, update manually ([CentOS/Red Hat](update-rippled-manually-on-centos-rhel.html) or [Ubuntu/Debian](update-rippled-manually-on-ubuntu.html)).
2. Create a symlink in your `cron.d` folder to the `/opt/ripple/etc/update-rippled-cron` config file:
sudo ln -s /opt/ripple/etc/update-rippled-cron /etc/cron.d/
This configuration runs a script to update the installed `rippled` package within an hour of each new release. To avoid network instability from too many servers updating at the same time, this script does not automatically restart the server, so it continues to run the old version until it restarts. [Updated in: rippled 1.8.1][]
3. **Whenever a new release comes out,** you must manually restart the `rippled` service to switch to the updated software.
sudo systemctl restart rippled.service
**Caution:** In the future, it is possible that changes to Ripple's repositories may require manual intervention to update the URLs where your script searches for updates. Stay tuned to the [XRP Ledger Blog](/blog/) or the [ripple-server mailing list](https://groups.google.com/forum/#!forum/ripple-server) for announcements on any required changes.
## See Also
- **Concepts:**
- [The `rippled` Server](xrpl-servers.html)
- [Consensus](consensus.html)
- **Tutorials:**
- [Capacity Planning](capacity-planning.html)
- [Troubleshoot rippled](troubleshoot-the-rippled-server.html)
- **References:**
- [rippled API Reference](http-websocket-apis.html)
- [`rippled` Commandline Usage](commandline-usage.html)
- [server_info method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

61
content/infrastructure/rippled/installation/update-rippled-manually-on-centos-rhel.ja.md Normal file
View File

@@ -0,0 +1,61 @@
---
html: update-rippled-manually-on-centos-rhel.html
parent: install-rippled.html
blurb: CentOSまたはRed Hat Enterprise Linuxでrippledを手動更新します。
labels:
- コアサーバー
- セキュリティ
---
# CentOS/Red Hatでの手動更新
このページでは、CentOSまたはRed Hat Enterprise Linuxで最新リリースの`rippled`に手動で更新する手順を説明します。可能であれば手動更新ではなく[自動更新](update-rippled-automatically-on-linux.html)を設定することが推奨されます。
以下の手順は、[`rippled`がすでに`yum`リポジトリからインストール](install-rippled-on-centos-rhel-with-yum.html)されていることを前提としています。
**ヒント:** これらの手順をすべて一度に実行するには、`rippled`パッケージに含まれている`/opt/ripple/bin/update-rippled.sh`スクリプトを実行します。このスクリプトは`sudo`ユーザーとして実行する必要があります。
手動で更新するには、以下の手順を実行します。
1. `rippled` 1.7.0にその以前のバージョンから更新する場合は、リポジトリを再度追加して、Rippleの更新されたGPGキーを取得します。それ以外の場合は、この手順をスキップしてください。
cat << REPOFILE | sudo tee /etc/yum.repos.d/ripple.repo
[ripple-stable]
name=XRP Ledger Packages
enabled=1
gpgcheck=0
repo_gpgcheck=1
baseurl=https://repos.ripple.com/repos/rippled-rpm/stable
gpgkey=https://repos.ripple.com/repos/rippled-rpm/stable/repodata/repomd.xml.key
REPOFILE
1. 最新の`rippled`パッケージをダウンロードしてインストールします。
sudo yum update rippled
2. `systemd`ユニットファイルを再度読み込みます。
sudo systemctl daemon-reload
3. `rippled`サービスを再起動します。
sudo systemctl restart rippled.service
## 関連項目
- **コンセプト:**
- [`rippled`サーバー](xrpl-servers.html)
- [コンセンサスについて](consensus.html)
- **チュートリアル:**
- [`rippled` v1.3.xへの移行手順](rippled-1-3-migration-instructions.html) <!-- Note: remove when versions older than v1.3 are basically extinct -->
- [rippledのトラブルシューティング](troubleshoot-the-rippled-server.html)
- **リファレンス:**
- [rippled APIリファレンス](http-websocket-apis.html)
- [`rippled`コマンドラインの使用](commandline-usage.html)
- [server_infoメソッド][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

63
content/infrastructure/rippled/installation/update-rippled-manually-on-centos-rhel.md Normal file
View File

@@ -0,0 +1,63 @@
---
html: update-rippled-manually-on-centos-rhel.html
parent: install-rippled.html
blurb: Manually update rippled on CentOS or Red Hat Enterprise Linux.
labels:
- Core Server
- Security
---
# Update Manually on CentOS/Red Hat
This page describes how to update manually to the latest release of `rippled` on CentOS or Red Hat Enterprise Linux. Ripple recommends setting up [automatic updates](update-rippled-automatically-on-linux.html) instead, where possible.
These instructions assume you have already [installed `rippled` from the `yum` repository](install-rippled-on-centos-rhel-with-yum.html).
**Tip:** To perform these steps all at once, you can run the `/opt/ripple/bin/update-rippled.sh` script, which is included with the `rippled` package. This script should be run as a `sudo` user.
To update manually, complete the following steps:
1. If you are upgrading to `rippled` 1.7.0 from an earlier version, re-add the repository to get Ripple's updated GPG key. Otherwise, skip this step:
$ cat << REPOFILE | sudo tee /etc/yum.repos.d/ripple.repo
[ripple-stable]
name=XRP Ledger Packages
enabled=1
gpgcheck=0
repo_gpgcheck=1
baseurl=https://repos.ripple.com/repos/rippled-rpm/stable
gpgkey=https://repos.ripple.com/repos/rippled-rpm/stable/repodata/repomd.xml.key
REPOFILE
1. Download and install the latest `rippled` package:
$ sudo yum update rippled
This update procedure leaves your existing config files in place.
2. Reload the `systemd` unit files:
$ sudo systemctl daemon-reload
3. Restart the `rippled` service:
$ sudo service rippled restart
## See Also
- **Concepts:**
- [The `rippled` Server](xrpl-servers.html)
- [Consensus](consensus.html)
- **Tutorials:**
- [`rippled` v1.3.x Migration Instructions](rippled-1-3-migration-instructions.html) <!-- Note: remove when versions older than v1.3 are basically extinct -->
- [Troubleshoot rippled](troubleshoot-the-rippled-server.html)
- **References:**
- [rippled API Reference](http-websocket-apis.html)
- [`rippled` Commandline Usage](commandline-usage.html)
- [server_info method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

53
content/infrastructure/rippled/installation/update-rippled-manually-on-ubuntu.ja.md Normal file
View File

@@ -0,0 +1,53 @@
---
html: update-rippled-manually-on-ubuntu.html
parent: install-rippled.html
blurb: Ubuntu Linuxでrippledを手動更新します。
labels:
- コアサーバー
- セキュリティ
---
# UbuntuまたはDebianでの手動更新
このページでは、Ubuntu Linuxで最新リリースの`rippled`に手動で更新する手順を説明します。以下の手順は、[`rippled`がすでにネイティブパッケージを使用してインストール](install-rippled-on-ubuntu.html)されていることを前提としています。可能であれば手動更新ではなく[自動更新](update-rippled-automatically-on-linux.html)を設定することが推奨されます。
**注意:** Ubuntu Linuxで`rippled` 1.2.xから1.3.1以降にアップグレードするには、[1.3.1への移行手順](rippled-1-3-migration-instructions.html)に従う必要があります。以下の手順は、バージョン1.3.1以降で提供されているネイティブAPTパッケージがインストール済みであることを前提としています。
**ヒント:** これらの手順をすべて一度に実行するには、`rippled`パッケージに含まれている`/opt/ripple/bin/update-rippled.sh`スクリプトを実行します。`rippled`バージョン1.3.1以降、このスクリプトはUbuntuおよびDebianと互換性があります。このスクリプトは`sudo`ユーザーとして実行する必要があります。
手動で更新するには、以下の手順を実行します。
1. リポジトリを更新します。
$ sudo apt -y update
2. `rippled`パッケージをアップグレードします。
$ sudo apt -y upgrade rippled
3. `systemd`ユニットファイルを再度読み込みます。
$ sudo systemctl daemon-reload
4. `rippled`サービスを再起動します。
$ sudo service rippled restart
## 関連項目
- **コンセプト:**
- [`rippled`サーバー](xrpl-servers.html)
- [コンセンサスについて](consensus.html)
- **チュートリアル:**
- [`rippled` v1.3.xへの移行手順](rippled-1-3-migration-instructions.html) <!-- Note: remove when versions older than v1.3 are basically extinct -->
- [rippledのトラブルシューティング](troubleshoot-the-rippled-server.html)
- **リファレンス:**
- [rippled APIリファレンス](http-websocket-apis.html)
- [`rippled`コマンドラインの使用](commandline-usage.html)
- [server_infoメソッド][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

58
content/infrastructure/rippled/installation/update-rippled-manually-on-ubuntu.md Normal file
View File

@@ -0,0 +1,58 @@
---
html: update-rippled-manually-on-ubuntu.html
parent: install-rippled.html
blurb: Manually update rippled on Ubuntu Linux.
labels:
- Core Server
- Security
---
# Update Manually on Ubuntu or Debian
This page describes how to update manually to the latest release of `rippled` on Ubuntu Linux. These instructions assume you have already [installed `rippled` using the native package](install-rippled-on-ubuntu.html). Ripple recommends setting up [automatic updates](update-rippled-automatically-on-linux.html) instead, where possible.
> **Caution:** Ripple renewed the GPG key used to sign binary packages shortly before the release of v1.7.0. If you are upgrading from a version earlier than 1.7.0, you must first download and manually trust the updated public key as follows:
>
> wget -q -O - "https://repos.ripple.com/repos/api/gpg/key/public" | \
> sudo apt-key add -
>
> For more information, see the [`rippled` 1.7.0 release notes](https://xrpl.org/blog/2021/rippled-1.7.0.html#upgrading-special-action-required).
**Tip:** To perform these steps all at once, you can run the `/opt/ripple/bin/update-rippled.sh` script, which is included with the `rippled` package and is compatible with Ubuntu and Debian. This script should be run as a `sudo` user.
To update manually, complete the following steps:
1. Update repositories:
$ sudo apt -y update
2. Upgrade the `rippled` package:
$ sudo apt -y upgrade rippled
3. Reload the `systemd` unit files:
$ sudo systemctl daemon-reload
4. Restart the `rippled` service:
$ sudo service rippled restart
## See Also
- **Concepts:**
- [The `rippled` Server](xrpl-servers.html)
- [Consensus](consensus.html)
- **Tutorials:**
- [`rippled` v1.3.x Migration Instructions](rippled-1-3-migration-instructions.html) <!-- Note: remove when versions older than v1.3 are basically extinct -->
- [Troubleshoot rippled](troubleshoot-the-rippled-server.html)
- **References:**
- [rippled API Reference](http-websocket-apis.html)
- [`rippled` Commandline Usage](commandline-usage.html)
- [server_info method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

443
content/infrastructure/rippled/run-private-network-with-docker.md Normal file
View File

@@ -0,0 +1,443 @@
---
html: private-network-with-docker.html
name: Run a Private Network with Docker
parent: infrastructure.html
blurb: Learn how to set up your own XRP private ledger network with Docker and Docker Compose.
labels:
- Core Server
---
# Run a Private Network with Docker
This tutorial describes how to run a private XRP Ledger network on your computer with [Docker](https://docs.docker.com/get-docker/) and the latest version of [rippled](https://hub.docker.com/r/xrpllabsofficial/xrpld).
While you can easily use the public XRP Testnet servers, running a private network can be useful when trying to understand how the XRP Ledger works, or when testing new features in isolation.
**Caution:** This tutorial is suited for development or testing purposes only, and does not involve using real money. You should **not** use this configuration for a production network.
## Learning Goals
In this tutorial, you will learn:
- How to set up and configure a _small_ network with three `rippled` validator nodes, including how to generate the keys for each node.
- How to run the network with [Docker Compose](https://docs.docker.com/compose/).
- How to verify the network is up and running.
The following diagram shows a high-level overview of the containerized private network that you will set up.
{{ include_svg("img/xrp-ledger-private-network-docker.svg", "Figure 1: Diagram of a three node containerized private ledger network") }}
## Prerequisites
To follow along with this tutorial, ensure that you have the latest version of **Docker** installed on your preferred platform.
## Generate the Validator Keys
Generate the keys for **each** of your validator nodes by using the `validator-keys` tool provided with `rippled`. The generated keys should be saved in a text file on your computer for later use.
1. In your terminal, run the following to execute commands within the `rippled` Docker container shell:
docker run -it --entrypoint /bin/bash xrpllabsofficial/xrpld:latest
**Note:** For Apple M1 or M2 chips, run `docker run -it --platform linux/amd64 --entrypoint /bin/bash xrpllabsofficial/xrpld:latest` instead.
Sample output:
root@7732bd585b14:/#
2. Generate a validator keypair using the `create_keys` command.
cd /opt/ripple/bin &&
./validator-keys create_keys --keyfile /PATH/TO/YOUR/validator-<NUMBER>-keys.json
Sample output:
Validator keys stored in /PATH/TO/YOUR/validator-<NUMBER>-keys.json
This file should be stored securely and not shared.
**Warning:** In a production or test environment you should follow best practices always and store the generated keys in a secure, offline, and recoverable location, such as an encrypted USB flash drive. However, as this tutorial is an example of a local development setup, storing the keys on your computer is sufficient.
3. Copy the **public_key** value from the JSON output, and store it in a text file on your computer.
cat /PATH/TO/YOUR/validator-<NUMBER>-keys.json
Sample output:
{
"key_type" : "ed25519",
"public_key" : "nHD9jtA9y1nWC2Fs1HeRkEisqV3iFpk12wHmHi3mQxQwUP1ywUKs",
"revoked" : false,
"secret_key" : "paLsUUm9bRrvNBPpvJQ4nF7vdRTZyDNofGMMYs9EDeEKeNJa99q",
"token_sequence" : 0
}
4. Create a validator token using the `create_token` command.
./validator-keys create_token --keyfile /PATH/TO/YOUR/validator-<NUMBER>-keys.json
Copy the token value from the output and save it in a text file on your computer. For example:
[validator_token]
eyJ2YWxpZGF0aW9uX3NlY3J|dF9rZXkiOiI5ZWQ0NWY4NjYyNDFjYzE4YTI3NDdiNT
QzODdjMDYyNTkwNzk3MmY0ZTcxOTAyMzFmYWE5Mzc0NTdmYT|kYWY2IiwibWFuaWZl
c3QiOiJKQUFBQUFGeEllMUZ0d21pbXZHdEgyaUNjTUpxQzlnVkZLaWxHZncxL3ZDeE
hYWExwbGMyR25NaEFrRTFhZ3FYeEJ3RHdEYklENk9NU1l1TTBGREFscEFnTms4U0tG
bjdNTzJmZGtjd1JRSWhBT25ndTlzQUtxWFlvdUorbDJWMFcrc0FPa1ZCK1pSUzZQU2
hsSkFmVXNYZkFpQnNWSkdlc2FhZE9KYy9hQVpva1MxdnltR21WcmxIUEtXWDNZeXd1
NmluOEhBU1FLUHVnQkQ2N2tNYVJGR3ZtcEFUSGxHS0pkdkRGbFdQWXk1QXFEZWRGdj
VUSmEydzBpMjFlcTNNWXl3TFZKWm5GT3I3QzBrdzJBaVR6U0NqSXpkaXRROD0ifQ==
5. Repeat steps **2-4** for the remaining validator nodes. Once you have generated the keys and tokens for _all_ validators, enter `exit` in your terminal to exit the Docker container.
## Configure the Network
This section describes how to configure the validator nodes in your network.
**Note:** The configuration in this tutorial enables the network to retain _some_ ledger history, but the amount of transaction history stored will depend on how long the network has been online.
### Create the node directories
On your computer, create the directories for all nodes in the private network, and their respective configuration folders.
xrpl-private-network/
├── validator_1/
│ └── config
├── validator_2/
│ └── config
└── validator_3/
└── config
In your terminal, run the following command to create the directories:
mkdir -p xrpl-private-network/{validator_1/config,validator_2/config,validator_3/config}
### Create the validator configuration files
For each validator node, follow these steps:
1. In the validator's `config` directory, create a `rippled.cfg` file.
2. Copy the information from the `rippled.cfg` template below into the file.
[server]
port_rpc_admin_local
port_rpc
port_ws_admin_local
port_ws_public
port_peer
# ssl_key = /etc/ssl/private/server.key
# ssl_cert = /etc/ssl/certs/server.crt
[port_rpc_admin_local]
port = 5005
ip = 127.0.0.1
admin = 127.0.0.1
protocol = http
[port_ws_admin_local]
port = 6006
ip = 127.0.0.1
admin = 127.0.0.1
protocol = ws
[port_ws_public]
port = 80
ip = 0.0.0.0
protocol = ws
[port_peer]
port = 51235
ip = 0.0.0.0
protocol = peer
[port_rpc]
port = 51234
ip = 0.0.0.0
admin = 127.0.0.1
protocol = https, http
[node_size]
small
# tiny
# small
# medium
# large
# huge
[node_db]
type=NuDB
path=/var/lib/rippled/db/nudb
advisory_delete=0
# How many ledgers do we want to keep (history)?
# Integer value that defines the number of ledgers
# between online deletion events
online_delete=256
[ledger_history]
# How many ledgers do we want to keep (history)?
# Integer value (ledger count)
# or (if you have lots of TB SSD storage): 'full'
256
[database_path]
/var/lib/rippled/db
[debug_logfile]
/var/log/rippled/debug.log
[sntp_servers]
time.windows.com
time.apple.com
time.nist.gov
pool.ntp.org
[ips_fixed]
validator_1 51235
validator_2 51235
validator_3 51235
[validators_file]
validators.txt
[rpc_startup]
{ "command": "log_level", "severity": "warning" }
# severity (order: lots of information .. only errors)
# debug
# info
# warn
# error
# fatal
[ssl_verify]
0
[validator_token]
<Add your validator token here>
3. Add the generated validator token that you created at the [beginning](#generate-the-validator-keys) of the tutorial. For example:
[validator_token]
eyJtYW5pZmVzdCI6IkpBQUFBQUZ4SWUwcVd3ZnpLZ2tacWJTL01QVGxHVXlOeTVJZ2kzYzlG
V1JvTDFIMGoydkNobk1oQTBOc2RHeFNXbWF6b0xkdU5NeDVmaVVZU2h3bjk2SnpSaUFReFJz
cENuR2dka1l3UkFJZ1dLazV4cklSN3FNRWd1UmJwOTRrN0E0QnBOZmwrT2VYUm92bTNIOGtS
YkVDSUZXYmVocHd5ZS9UWFpZRGYwUEgwTkxjN2I1cWNEOXUvbzVYUjA4YW1pUEJjQkpBYjEw
NE95bG5IS0JSZTJmRW1qSVVjT24vZ2ZacE44bXdhZ1dGbUxlemc2RFRLL0hpTVkyektNQ3l0
aksreHpHNWpjc3JlS3k5Q29sRGtpKzk3V0JHQ2c9PSIsInZhbGlkYXRpb25fc2VjcmV0X2tl
eSI6IjZFNTNFQjA1M0IwNEM1RTczNDc4M0VCMEU0RTBFOTg1NDVDNDQ0QzI3OTBFQjdBMzA2
NUQzMUVBOTU1QjQyMTIifQ==
Each validator node must have its own unique token.
### Create the validators.txt files
Now that you have created the configuration files for your validators, you need to add a `validator.txt` file. This file defines which validators are trusted by your network.
For each node, follow these steps:
1. Create a `validators.txt` file in the configuration directory.
2. Copy the public keys from the `validator-keys.json` files that you generated at the [beginning](#generate-the-validator-keys) of the tutorial.
3. Add the public keys of _all_ the validators. For example:
[validators]
nHBgaEDL8buUECuk4Rck4QBYtmUgbAoeYJLpWLzG9iXsznTRYrQu
nHBCHX7iLDTyap3LumqBNuKgG7JLA5tc6MSJxpLs3gjkwpu836mY
nHU5STUKTgWdreVqJDx6TopLUymzRUZshTSGcWNtjfByJkYdiiRc
## Start the Network
Docker Compose lets you manage multiple containers on your computer with a simple `yaml` file configuration. This section describes how to run the network with Docker Compose, and how to verify that the network is running successfully.
**Note:** Docker Compose ensures the containers are part of the same Docker virtual network by default, so you don't need to take any additional steps for the `rippled` containers to communicate with each other.
To start running your private network, follow these steps:
1. Create a `docker-compose.yml` file in the root of the private network directory, `xrpl-private-network`, and add the following content:
version: "3.9"
services:
validator_1:
platform: linux/amd64
container_name: validator_1
image: "xrpllabsofficial/xrpld"
ports:
- "8001:80"
- "5006:5005"
- "4001:6006"
- "9001:51235"
volumes:
- ./validator_1/config:/config/
validator_2:
platform: linux/amd64
container_name: validator_2
image: "xrpllabsofficial/xrpld"
ports:
- "8002:80"
- "5007:5005"
- "4002:6006"
- "9002:51235"
volumes:
- ./validator_2/config:/config/
validator_3:
platform: linux/amd64
container_name: validator_3
image: "xrpllabsofficial/xrpld"
ports:
- "8003:80"
- "5008:5005"
- "4003:6006"
- "9003:51235"
volumes:
- ./validator_3/config:/config/
The `volumes` key in each `service` represents the location where your config files are stored. For example, `./validator_1/config:/config/` maps the `/validator_1/config` directory on your host computer to `/config/` in the Docker container. Any changes made in the host directory will be reflected in the container automatically.
2. From your terminal, in the location where you created the `docker-compose.yml` file, run `docker-compose up -d`. You should see a similar output to the one below:
[+] Running 4/4
✔ Network xrpl-private-network_default Created 0.0s
✔ Container validator_3 Started 0.5s
✔ Container validator_1 Started 0.5s
✔ Container validator_2 Started 0.5s
## Verify the Network
Now that the private ledger network is up, you need to verify that **each** validator node is running as expected:
1. In your terminal, run `docker exec -it <validator_name> bin/bash` to execute commands in the validator Docker container. Replace `<validator_name>` with the name of the container (e.g., `validator_1`).
2. Run the `rippled server_info` command to check the state of the validator:
rippled server_info | grep server_state
Sample Output:
"server_state" : "proposing"
**Note:** If the state is not updated to **proposing**, repeat step **2** after a few minutes as the ledger can take some time to update.
3. Verify the number of peers connected to the validator.
rippled server_info | grep peers
Sample Output:
"peers" : 2
4. Run the following command to check the genesis account information:
rippled account_info rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh validated strict
Sample Output:
{
"result" : {
"account_data" : {
"Account" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
"Balance" : "100000000000000000",
"Flags" : 0,
"LedgerEntryType" : "AccountRoot",
"OwnerCount" : 0,
"PreviousTxnID" : "0000000000000000000000000000000000000000000000000000000000000000",
"PreviousTxnLgrSeq" : 0,
"Sequence" : 1,
"index" : "2B6AC232AA4C4BE41BF49D2459FA4A0347E1B543A4C92FCEE0821C0201E2E9A8"
},
"ledger_hash" : "CFCEFB049A71E26DE812529ABB212F330FAF583A98FE073F14713B0644D7CEE9",
"ledger_index" : 10181,
"status" : "success",
"validated" : true
}
}
5. To leave the Docker container shell, enter `exit` in the terminal.
### Perform a test transaction
Perform a **test** transaction to ensure you can send money to an account.
1. In your terminal, run the the following command to submit a transaction:
docker exec -it validator_1 \
rippled submit 'snoPBrXtMeMyMHUVTgbuqAfg1SUTb' '{ "Account": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", "Amount": "1000000000", "Destination": "r9wRwVgL2vWVnKhTPdtxva5vdH7FNw1zPs", "TransactionType": "Payment", "Fee": "10" }'
Sample Output:
{
"result" : {
"engine_result" : "tesSUCCESS",
"engine_result_code" : 0,
"engine_result_message" : "The transaction was applied. Only final in a validated ledger.",
"status" : "success",
"tx_blob" : "1200002280000000240000000161400000003B9ACA0068400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074463044022057CCEED351A4278F35C13FD104A55338DC8F48C1F9902D58045A4CD0CE89C92A0220184026BD3B1E2C21239017CAF1BBF683 35EDC57F6F98D952E263763DE449561B8114B5F762798A53D543A014CAF8B297CFF8F2F937E883145988EBB744055F4E8BDC7F67FD53EB9FCF961DC0",
"tx_json" : {
"Account" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
"Amount" : "1000000000",
"Destination" : "r9wRwVgL2vWVnKhTPdtxva5vdH7FNw1zPs",
"Fee" : "10",
"Flags" : 2147483648,
"Sequence" : 1,
"SigningPubKey" : "0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020",
"TransactionType" : "Payment",
"TxnSignature" : "3044022057CCEED351A4278F35C13FD104A55338DC8F48C1F9902D58045A4CD0CE89C92A0220184026BD3B1E2C21239017CAF1BBF68335EDC57F6F98D952E263763DE449561B",
"hash" : "EB516738841794B24819C68273E0F853A3D234350E6534F7F2841F620CE99437"
}
}
}
2. For each validator, verify that the destination account `r9wRwVgL2vWVnKhTPdtxva5vdH7FNw1zPs` has 1000000000 XRP. For example:
docker exec -it validator_1 \
rippled account_info r9wRwVgL2vWVnKhTPdtxva5vdH7FNw1zPs validated strict
Sample Output:
{
"result" : {
"account_data" : {
"Account" : "r9wRwVgL2vWVnKhTPdtxva5vdH7FNw1zPs",
"Balance" : "1000000000",
"Flags" : 0,
"LedgerEntryType" : "AccountRoot",
"OwnerCount" : 0,
"PreviousTxnID" : "EB516738841794B24819C68273E0F853A3D234350E6534F7F2841F620CE99437",
"PreviousTxnLgrSeq" : 36,
"Sequence" : 1,
"index" : "0F2E4615AE24EEF58EE82BD1E67D237234ED41BFC8B7885630B7AC05082E97AA"
},
"ledger_hash" : "6F9F54903CC4546F7A426CD78AFD68D907F5DC40B1780DF31A662CF65920E49C",
"ledger_index" : 51,
"status" : "success",
"validated" : true
}
}
All validator nodes should respond with the same balance of 1000000000 XRP for the `r9wRwVgL2vWVnKhTPdtxva5vdH7FNw1zPs` account.
## Stop the Network
If you wish to stop running the private network:
1. In your terminal, go to the `xrpl-private-network` directory.
2. Run the following command to shut down the network:
docker-compose down
Sample Output:
[+] Running 4/4
✔ Container validator_3 Removed 1.7s
✔ Container validator_1 Removed 1.6s
✔ Container validator_2 Removed 1.6s
✔ Network xrpl-private-network_default Removed 0.0s
## See Also
- **Networks and Servers:**
- [Peer Protocol](peer-protocol.html)
- **References:**
- [XRPL Testnet Setup Scripts for Docker](https://github.com/UNIC-IFF/xrpl-docker-testnet)

24
content/infrastructure/rippled/stand-alone-mode/advance-the-ledger-in-stand-alone-mode.ja.md Normal file
View File

@@ -0,0 +1,24 @@
---
html: advance-the-ledger-in-stand-alone-mode.html
parent: use-stand-alone-mode.html
blurb: レジャーを手動で閉鎖して、スタンドアロンモードでの処理を進めます。
labels:
- コアサーバー
---
# スタンドアロンモードでレジャーを進める
スタンドアロンモードでは`rippled`はピアツーピアネットワークの他のメンバーと通信せず、またコンセンサスプロセスに参加しません。このため、[ledger_acceptメソッド][]を使用してレジャーインデックスを手動で進める必要があります。
```
rippled ledger_accept --conf=/path/to/rippled.cfg
```
スタンドアロンモードでは`rippled`は「閉鎖済み」レジャーバージョンと「検証済み」レジャーバージョンは区別されません。（これらのバージョンの違いについての詳細は、[XRP Ledgerコンセンサスプロセス](consensus.html)を参照してください。）
`rippled`は、レジャーを閉鎖するたびに、確定的だが操作困難なアルゴリズムに基づいてトランザクションを並べ替えます。（トランザクションはネットワークの異なるパスに異なる順序で着信することがあるため、これはコンセンサスの重要な部分です。）スタンドアロンモードで`rippled`を使用するときには、別のアドレスからのトランザクションの結果に依存するトランザクションは、それを送信する前に、レジャーを手動で進める必要があります。このようにしないと、レジャーの閉鎖時に2つのトランザクションが逆の順序で実行される可能性があります。**注記:** 複数のトランザクションを1つのアドレスから1つのレジャーへ安全に送信できます。これは、同じアドレスからのトランザクションは`rippled`により[`Sequence`番号](transaction-common-fields.html)の昇順でソートされるためです。
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

33
content/infrastructure/rippled/stand-alone-mode/advance-the-ledger-in-stand-alone-mode.md Normal file
View File

@@ -0,0 +1,33 @@
---
html: advance-the-ledger-in-stand-alone-mode.html
parent: use-stand-alone-mode.html
blurb: Make progress in stand-alone mode by manually closing the ledger.
labels:
- Core Server
---
# 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. Since there is no consensus process in this mode, 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](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](transaction-common-fields.html).
## See Also
- **References:**
- [ledger_accept method][]
- [server_info method][]
- [`rippled` Commandline Usage](commandline-usage.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

89
content/infrastructure/rippled/stand-alone-mode/load-a-saved-ledger-in-stand-alone-mode.ja.md Normal file
View File

@@ -0,0 +1,89 @@
---
html: load-a-saved-ledger-in-stand-alone-mode.html
parent: use-stand-alone-mode.html
blurb: 特定の保存済みレジャーからスタンドアロンモードで開始して、トランザクションのテストやリプレイを行います。
labels:
- コアサーバー
---
# スタンドアロンモードでの保存済みレジャーの読み込み
以前にディスクに保存していた[履歴レジャーバージョン](ledgers.html)を使用して、`rippled`サーバーを[スタンドアロンモード](rippled-server-modes.html)で起動できます。例えば、以前に`rippled`サーバーをXRP Ledgerのピアツーピアネットワーク（[本番Mainnet、Testnet、Devnetなど](parallel-networks.html)）と同期していた場合は、過去にサーバーで使用できていた任意のレジャーバージョンを読み込むことができます。
履歴レジャーバージョンを読み込むことにより、レジャーを「リプレイ」して、トランザクションがネットワークのルールに従って処理されていたか検証したり、異なる[Amendment](amendments.html)を有効にした場合のトランザクションセットの処理の結果を比較したりすることができます。万が一、[XRP Ledgerのコンセンサスメカニズムに対する攻撃](consensus-protections.html)が発生して共有レジャーの状態に悪影響が及んでも、このプロセスを始めることで、バリデータのコンセンサスを以前の良好だったネットワークの状態に「ロールバック」できる可能性があります。
## 1. `rippled`を通常の方法で起動します。
既存のレジャーを読み込むには、最初にネットワークから当該のレジャーを取得する必要があります。`rippled`をオンラインモードで通常の方法で起動します。
```
rippled --conf=/path/to/rippled.cfg
```
## 2. `rippled`が同期されるまで待ちます。
[server_infoメソッド][]を使用して、ネットワークに対するサーバーの状態を確認します。`server_state`に以下のいずれかの値が示される場合は、サーバーは同期しています。
* `full`
* `proposing`
* `validating`
詳細は、[考えられるサーバーの状態](rippled-server-states.html)を参照してください。
## 3. （省略可）特定のレジャーバージョンを取得します。
最新レジャーのみを必要とする場合は、このステップをスキップできます。
特定の履歴レジャーバージョンを読み込むには、[ledger_requestメソッド][]を実行して`rippled`にそのレジャーバージョンを取得させます。`rippled`にまだレジャーバージョンがない場合は、レジャーの取得が完了するまで`ledger_request`コマンドを複数回実行する必要があります。
特定の履歴レジャーバージョンをリプレイする場合は、リプレイするレジャーバージョンとその直前のレジャーバージョンの両方を取得する必要があります。（前のレジャーバージョンにより、リプレイするレジャーバージョンに記述されている変更を適用する初期状態が設定されます。）
## 4. `rippled`をシャットダウンします。
[stopメソッド][]を使用します。
```
rippled stop --conf=/path/to/rippled.cfg
```
## 5. スタンドアロンモードで`rippled`を起動します。
最新のレジャーバージョンを読み込むには、`-a`オプションと`--load`オプションを指定してサーバーを起動します。
```
rippled -a --load --conf=/path/to/rippled.cfg
```
特定の履歴レジャーを読み込むには、`--load`パラメーターと`--ledger`パラメーターを使用し、読み込むレジャーバージョンのレジャーインデックスまたは識別用ハッシュを指定してサーバーを起動します。
```
rippled -a --load --ledger 19860944 --conf=/path/to/rippled.cfg
```
スタンドアロンモードで`rippled`を起動するときに使用可能なオプションについての詳細は、[コマンドラインの使用: スタンドアロンモードのオプション ](commandline-usage.html#スタンドアロンモードのオプション)を参照してください。
## 6. レジャーを手動で進めます。
スタンドアロンモードで`--ledger`を使用してレジャーを読み込むと、読み込まれたレジャーが現行のオープンレジャーになるので、[レジャーを手動で進める](advance-the-ledger-in-stand-alone-mode.html)必要があります。
```
rippled ledger_accept --conf=/path/to/rippled.cfg
```
## 関連項目
- **コンセプト:**
- [`rippled`サーバー](xrpl-servers.html)
- [`rippled`サーバーのモード](rippled-server-modes.html)
- [コンセンサスについて](consensus.html)
- [Amendment](amendments.html)
- **リファレンス:**
- [ledger_acceptメソッド][]
- [server_infoメソッド][]
- [`rippled`コマンドラインの使用](commandline-usage.html)
- **ユースケース:**
- [XRP Ledgerへのコードの提供](contribute-code.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

91
content/infrastructure/rippled/stand-alone-mode/load-a-saved-ledger-in-stand-alone-mode.md Normal file
View File

@@ -0,0 +1,91 @@
---
html: load-a-saved-ledger-in-stand-alone-mode.html
parent: use-stand-alone-mode.html
blurb: Start in stand-alone mode from a specific saved ledger to test or replay transactions.
labels:
- Core Server
---
# Load a Saved Ledger in Stand-Alone Mode
You can start a `rippled` server in [Stand-Alone Mode](rippled-server-modes.html) using a [historical ledger version](ledgers.html) that was previously saved to disk. For example, if your `rippled` server was previously synced with any XRP Ledger peer-to-peer network including [the production Mainnet, the Testnet, or the Devnet](parallel-networks.html), you can load any ledger version your server had available.
Loading a historical ledger version is useful for "replaying" a ledger to verify that transactions were processed according to the rules of the network, or to compare the results of processing transaction sets with different [amendments](amendments.html) enabled. In the unlikely event that [an attack against the XRP Ledger's consensus mechanism](consensus-protections.html) caused unwanted effects to the shared ledger state, a consensus of validators could "roll back" to a known-good network state starting with this process.
**Caution:** As `rippled` is updated to newer versions, amendments are retired and become core functions of the ledger, which can affect how transactions are processed. To produce historically accurate results, you need to replay ledgers using the version of `rippled` the transaction was processed in.
## 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](rippled-server-states.html).
## 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, start the server with the `-a` and `--load` options:
```
rippled -a --load --conf=/path/to/rippled.cfg
```
To load a specific historical ledger, start the server with the `--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
```
This makes the saved ledger version the "current" (open) ledger for the server when it starts.
For more information on the options you can use when starting `rippled` in stand-alone mode, see [Commandline Usage: Stand-Alone Mode Options](commandline-usage.html#stand-alone-mode-options).
## 6. Manually advance the ledger.
To process the saved ledger, manually advance it with the `ledger_accept` method:
```
rippled ledger_accept --conf=/path/to/rippled.cfg
```
This puts the transactions in canonical order and processes them to make a closed ledger.
## See Also
- **References:**
- [ledger_accept method][]
- [server_info method][]
- [`rippled` Commandline Usage](commandline-usage.html)
- **Use Cases:**
- [Contribute Code to the XRP Ledger](contribute-code.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

35
content/infrastructure/rippled/stand-alone-mode/start-a-new-genesis-ledger-in-stand-alone-mode.ja.md Normal file
View File

@@ -0,0 +1,35 @@
---
html: start-a-new-genesis-ledger-in-stand-alone-mode.html
parent: use-stand-alone-mode.html
blurb: スタンドアロンモードで新しいジェネシスレジャーを開始します。
labels:
- コアサーバー
---
# スタンドアロンモードでの新しいジェネシスレジャーの開始
スタンドアロンモードでは`rippled`に新しいジェネシスレジャーを作成させることができます。これにより既知の状態が実現され、本番環境のXRP Ledgerのレジャー履歴は使用されません。（これは単体テストなどに特に便利です。）
* スタンドアロンモードで新しいジェネシスレジャーを使用して`rippled`を起動するには、`-a`オプションと`--start`オプションを使用します。
```
rippled -a --start --conf=/path/to/rippled.cfg
```
スタンドアロンモードで`rippled`を起動時に使用できるオプションについての詳細は、[コマンドラインの使用リファレンスのスタンドアロンモードのオプション](commandline-usage.html#スタンドアロンモードのオプション)を参照してください。
ジェネシスレジャーの[ジェネシスアドレス](accounts.html#特別なアドレス)は1,000億XRPすべてを保有しています。ジェネシスアドレスのキーは以下のように[ハードコーディング](https://github.com/ripple/rippled/blob/94ed5b3a53077d815ad0dd65d490c8d37a147361/src/ripple/app/ledger/Ledger.cpp#L184)されています。
**アドレス:** `rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh`
**シークレット:** `snoPBrXtMeMyMHUVTgbuqAfg1SUTb`（"masterpassphrase"）
## 新しいジェネシスレジャーの設定
新しいジェネシスレジャーでは、デフォルトでハードコーディングされる[準備金](reserves.html)は**200 XRP**です。この額は、新規アドレスに支給される最低額で、レジャーの1オブジェクトにつき**50 XRP**ずつ増加します。これらは本番環境ネットワークの現在の必要準備金よりも大きな値です。（関連項目: [手数料投票](fee-voting.html)）
デフォルトでは、新しいジェネシスレジャーでは[Amendment](amendments.html)が有効になっていません。`--start`を使用して新しいジェネシスレジャーを開始する場合、ジェネシスレジャーには、構成ファイルで明示的に無効にされたAmendmentを除き、`rippled`サーバーでネイティブにサポートされているすべてのAmendmentを有効にする[EnableAmendment疑似トランザクション](enableamendment.html)が含まれています。これらのAmendmentの効果は、直後のレジャーバージョンから反映されます。（留意事項: スタンドアロンモードでは[レジャーを手動で進める](advance-the-ledger-in-stand-alone-mode.html)必要があります。）[新規: rippled 0.50.0][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

50
content/infrastructure/rippled/stand-alone-mode/start-a-new-genesis-ledger-in-stand-alone-mode.md Normal file
View File

@@ -0,0 +1,50 @@
---
html: start-a-new-genesis-ledger-in-stand-alone-mode.html
parent: use-stand-alone-mode.html
blurb: Start from a fresh genesis ledger in stand-alone mode.
labels:
- Core Server
---
# 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` and `--start` options:
```
rippled -a --start --conf=/path/to/rippled.cfg
```
For more information on the options you can use when starting `rippled` in stand-alone mode, see [Commandline Usage: Stand-Alone Mode Options](commandline-usage.html#stand-alone-mode-options).
In a genesis ledger, the [genesis address](addresses.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](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](fee-voting.html))
By default, a new genesis ledger has no [amendments](amendments.html) enabled. If you start a new genesis ledger with `--start`, the genesis ledger contains an [EnableAmendment pseudo-transaction](enableamendment.html) to turn on all amendments natively supported by the `rippled` server, except for amendments that you explicitly disable in the config 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](advance-the-ledger-in-stand-alone-mode.html).) [New in: rippled 0.50.0][]
## See Also
- **Concepts:**
- [The `rippled` Server](xrpl-servers.html)
- [`rippled` Server Modes](rippled-server-modes.html)
- [Parallel Networks](parallel-networks.html)
- [Amendments](amendments.html)
- [Fee Voting](fee-voting.html)
- **References:**
- [ledger_accept method][]
- [server_info method][]
- [`rippled` Commandline Usage](commandline-usage.html)
- **Use Cases:**
- [Contribute Code to the XRP Ledger](contribute-code-to-rippled.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

136
content/infrastructure/rippled/troubleshooting/diagnosing-problems.ja.md Normal file
View File

@@ -0,0 +1,136 @@
---
html: diagnosing-problems.html
parent: troubleshoot-the-rippled-server.html
blurb: 情報を収集して問題の原因を特定します。
labels:
- コアサーバー
---
# rippledの問題の診断
`rippled`で問題が発生した場合はまず、問題の特徴を正確に明らかにするため、詳細な情報を収集します。これにより、根本原因を洗い出して修正策を編み出すことが容易になります。
サーバーが起動しない場合（クラッシュが発生した場合や自動的にシャットダウンした場合など）は、[rippledサーバーが起動しない](server-wont-start.html)で考えられる原因と修正策のリストを確認してください。
このドキュメントでは、サーバーが稼働している場合（プロセスがアクティブだがネットワークと同期できない場合を含む）に発生する可能性がある問題の診断手順を説明します。
## server_infoの取得
コマンドラインを使用して、ローカル`rippled`インスタンスからサーバーステータス情報を取得できます。例:
```
rippled server_info
```
このコマンドに対する応答には大量の情報が含まれています。これについては、[server_infoメソッド][]で説明します。トラブルシューティングで最も重要なフィールドは以下のとおりです（最も一般的に使われるものから順に説明します）。
- **`server_state`** - ほとんどの場合、このフィールドには`proposing`（[バリデータとして設定されている](run-rippled-as-a-validator.html)サーバーの場合）または`full`（バリデータではないサーバーの場合）が表示されます。値が`connected`の場合は、サーバーはピアツーピアネットワークの他の部分と通信できますが、共有レジャーの状態を追跡するのに十分なデータがありません。通常、レジャーの残りの部分の状態を同期するには起動後約5～15分かかります。
- サーバーが数時間にわたり`connected`状態である場合、または`full`あるいは`proposing`状態になってから`connected`状態に戻る場合は通常、サーバーがネットワークの他の部分よりも遅れています。最も一般的なボトルネックはディスクI/O、ネットワーク帯域幅、RAMです。
- 例えば、以下のサーバー状態情報は、正常なサーバーで同期が3分以内に完了しており（`disconnected`、`connected`、`syncing`の状態に分かれている）、現在は完全に同期された`proposing`状態が約90分間続いていることを示しています。
$ ./rippled server_info
Loading: "/etc/opt/ripple/rippled.cfg"
2020-Jan-03 22:49:32.834134358 HTTPClient:NFO Connecting to 127.0.0.1:5005
{
"result" : {
"info" : {
...（省略）...
"server_state" : "proposing",
"server_state_duration_us" : "5183282365",
"state_accounting" : {
"connected" : {
"duration_us" : "126164786",
"transitions" : 1
},
"disconnected" : {
"duration_us" : "2111321",
"transitions" : 1
},
"full" : {
"duration_us" : "5183282365",
"transitions" : 1
},
"syncing" : {
"duration_us" : "5545604",
"transitions" : 1
},
"tracking" : {
"duration_us" : "0",
"transitions" : 1
}
},
...（省略）...
}
}
}
サーバーが同じ状態間で複数の`transitions`を示している場合、サーバーが同期状態を維持できなかったことを示します。`full`または`proposing`状態でない場合、サーバーはまだネットワークに同期されていません。長期の間には、インターネット接続が不安定になってサーバーの同期が時々失われる場合があります。そのためこれが問題になるのは、同期されていない時間がアップタイムのかなりの部分を占める場合のみです。アップタイムが約24時間経過した後に、`full`または`proposing`状態だった時間がサーバーの合計実行時間の99%に満たない場合、不安定になっている原因を調査することをお勧めします。
- 同期の問題をデバッグする際の参考として、[サーバーが同期しない](server-doesnt-sync.html)を参照してください。
- **`complete_ledgers`** - このフィールドは、サーバーに完全なレジャーデータが保管されている[レジャーインデックス](basic-data-types.html#レジャーインデックス)を示します。通常、正常なサーバーには連続した最新のレジャーのセット（`"12133424-12133858"`など）があります。
- 連続していない完全なレジャーのセット（`"11845721-12133420,12133424-12133858"`など）がある場合、サーバーで断続的な障害が発生したか、またはネットワークの他の部分との同期が一時的にできなかった可能性があります。このようなケースの最も一般的な原因は、ディスクI/Oまたはネットワーク帯域幅の不足です。
- 通常、`rippled`サーバーはピアから最新のレジャー履歴をダウンロードします。レジャー履歴のギャップが数時間以上続く場合は、欠落データを所有しているピアに接続されていない可能性があります。この状況が発生した場合は、構成ファイルに次のスタンザを追加して再起動すれば、完全な履歴が保管されているRippleのパブリックサーバーの1つにサーバーを強制的にピア接続できます。
[ips_fixed]
s2.ripple.com 51235
- **`amendment_blocked`** - このフィールドは通常`server_info`応答では省略されます。このフィールドの値が`true`の場合は、ネットワークにより承認された[Amendment](amendments.html)がサーバーに導入されていません。ほとんどの場合は、最新バージョンに[rippledを更新する](install-rippled.html)ことで修正できます。また[featureメソッド][]を使用して、現在有効なAmendment ID、サーバーでサポートされているAmendment ID、サーバーでサポートされていないAmendment IDを確認することもできます。
- **`peers`** - このフィールドは、サーバーが接続しているXRP Ledgerピアツーピアネットワーク内のその他のサーバーの数を示します。特定のピアのみに接続するように明示的に構成されているサーバーを除き、正常なサーバーでは通常5～50ピアと表示されます。
- ピアの数が0の場合、サーバーがネットワークに接続できないか、またはシステムクロックが正しくない可能性があります。（サーバーのクロックを同期するため、すべてのサーバーで[NTP](http://www.ntp.org/)デーモンを実行することが推奨されます。）
- ピアの数が10の場合、`rippled`が[NAT](https://en.wikipedia.org/wiki/Network_address_translation)を使用したルーター経由での着信接続を受信できていない可能性があります。接続を改善するには、ルーターのファイアウォールがピアツーピア接続に使用するポート（[デフォルトでは](https://github.com/ripple/rippled/blob/8429dd67e60ba360da591bfa905b58a35638fda1/cfg/rippled-example.cfg#L1065)ポート51235）を転送するように設定します。
### サーバーから応答がない場合
`rippled`実行可能ファイルがクライアントとして`rippled`サーバーに接続できなかった場合、以下のメッセージが返されます。
```json
{
"error" : "internal",
"error_code" : 71,
"error_message" : "Internal error.",
"error_what" : "no response from server"
}
```
通常これはさまざまな問題の1つを示します。
- `rippled`サーバーが起動したばかりであるか、または完全に稼働していません。サービスのステータスを確認してください。稼働している場合は数秒間待ってから再試行してください。
- サーバーに接続するために異なる[パラメーターを`rippled`コマンドラインクライアントに](commandline-usage.html#クライアントモードのオプション)渡す必要があります。
- `rippled`サーバーがJSON-RPC接続を受け入れるように構成されていない可能性があります。
## サーバーログの確認
[デフォルトでは](https://github.com/ripple/rippled/blob/master/cfg/rippled-example.cfg#L1139-L1142)`rippled`はサーバーのデバッグログを`/var/log/rippled/debug.log`ファイルに書き込みます。このデバッグログの位置は、サーバーの構成ファイルにより異なる可能性があります。`rippled`サービスを（`systemctl`または`service`を使用して開始するのではなく）直接開始した場合、デフォルトではログメッセージはコンソールにも出力されます。
デフォルトの構成ファイルでは、起動時に[log_levelメソッド][]を内部で使用して、すべてのログメッセージカテゴリーでログレベルの重大度は「警告」に設定されています。デバッグログの詳細レベルを制御するには、[起動時に`--silent`コマンドラインオプションを使用し](commandline-usage.html#詳細レベルのオプション)、サーバーの稼働中に[log_levelメソッド][]を使用します。（設定については構成ファイルの`[rpc_startup]`スタンザを参照してください。）
`rippled`サーバーが起動中に多数の警告レベルの（`WRN`）メッセージを出力し、その後はときどきいくつかの警告レベルメッセージを出力することは正常です。サーバー起動時の最初の5～15分間に出力されるほとんどの警告は、**安全に無視**できます。
さまざまな種類のログメッセージに関する詳しい説明については、[ログメッセージについて](understanding-log-messages.html)を参照してください。
## 関連項目
- **コンセプト:**
- [`rippled`サーバー](xrpl-servers.html)
- [Amendment](amendments.html)
- **チュートリアル:**
- [容量の計画](capacity-planning.html)
- [rippledの構成](configure-rippled.html)
- **リファレンス:**
- [rippled APIリファレンス](http-websocket-apis.html)
- [`rippled`コマンドラインの使用](commandline-usage.html)
- [log_levelメソッド][]
- [server_infoメソッド][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

180
content/infrastructure/rippled/troubleshooting/diagnosing-problems.md Normal file
View File

@@ -0,0 +1,180 @@
---
html: diagnosing-problems.html
parent: troubleshoot-the-rippled-server.html
blurb: Collect information to identify the cause of problems.
labels:
- Core Server
---
# Diagnosing Problems with rippled
If you are having problems with `rippled`, the first step is to collect more information to accurately characterize the problem. From there, it can be easier to figure out a root cause and a fix.
See the following pages for some common categories of problems, their causes, and fixes:
- If your server does not start (such as crashing or otherwise shutting down automatically), see **[rippled Server Won't Start](server-wont-start.html)**.
- If your server starts, but does not reliably sync or remain synced to the XRP Ledger network, see **[rippled Server Doesn't Sync](server-doesnt-sync.html)**.
The rest of this document suggests steps for diagnosing problems that happen while your server is up and running (including if the process is active but unable to sync with the network).
## Get the server_info
You can use the commandline to get server status information from the local `rippled` instance. For example:
```
rippled server_info
```
The response to this command has a lot of information, which is documented along with the [server_info method][].
For troubleshooting purposes, the most important fields are (from most commonly used to least):
- **`server_state`** - Most of the time, this field should show `proposing` for a server that is [configured as a validator](run-rippled-as-a-validator.html), or `full` for a non-validating server. The value `connected` means that the server can communicate with the rest of the peer-to-peer network, but it does not yet have enough data to track progress of the shared ledger state. Normally, syncing to the state of the rest of the ledger takes about 5-15 minutes after starting.
- If your server remains in the `connected` state for hours, or returns to the `connected` state after being in the `full` or `proposing` states, that usually indicates that your server cannot keep up with the rest of the network. The most common bottlenecks are disk I/O, network bandwidth, and RAM.
- For example, the following server state information shows a healthy server that took less than 3 minutes to sync (split between the `disconnected`, `connected`, and `syncing` states), and is currently in the fully-synced `proposing` state, where it has remained for approximately 90 minutes:
$ ./rippled server_info
Loading: "/etc/opt/ripple/rippled.cfg"
2020-Jan-03 22:49:32.834134358 HTTPClient:NFO Connecting to 127.0.0.1:5005
{
"result" : {
"info" : {
... (trimmed) ...
"server_state" : "proposing",
"server_state_duration_us" : "5183282365",
"state_accounting" : {
"connected" : {
"duration_us" : "126164786",
"transitions" : 1
},
"disconnected" : {
"duration_us" : "2111321",
"transitions" : 1
},
"full" : {
"duration_us" : "5183282365",
"transitions" : 1
},
"syncing" : {
"duration_us" : "5545604",
"transitions" : 1
},
"tracking" : {
"duration_us" : "0",
"transitions" : 1
}
},
... (trimmed) ...
}
}
}
If you do not have a `full` or `proposing` state, then your server has not yet synced to the network. If your server shows multiple transitions between the same states (`transitions` is 2 or more), that indicates that your server lost sync with the network. It's a problem if you have many transitions in a short period of time; it's OK if you have a few transitions over a long period of time, because some fluctuations in internet connectivity are unavoidable. The amount of time in individual states (`duration_us`) compared with total uptime (`server_state_duration_us`) can also tell you how well your server is staying synced. After about 24 hours of uptime, if less than 99% of your server's total runtime is spent in the `full` or `proposing` states, you may want to investigate possible sources of instability.
- For help debugging syncing issues, see [Server Doesn't Sync](server-doesnt-sync.html).
- **`complete_ledgers`** - This field shows which [ledger indexes](basic-data-types.html#ledger-index) your server has complete ledger data for. Healthy servers usually have a single range of recent ledgers, such as `"12133424-12133858"`.
- If you have a disjoint set of complete ledgers such as `"11845721-12133420,12133424-12133858"`, that could indicate that your server has had intermittent outages or has temporarily fallen out of sync with the rest of the network. The most common causes for this are insufficient disk I/O or network bandwidth.
- Normally, a `rippled` server downloads recent ledger history from its peers. If gaps in your ledger history persist for more than a few hours, you may not be connected to any peers who have the missing data. If this occurs, you can force your server to try and peer with one of Ripple's full-history public servers by adding the following stanza to your config file and restarting:
[ips_fixed]
s2.ripple.com 51235
- **`amendment_blocked`** - This field is normally omitted from the `server_info` response. If this field appears with the value `true`, then the network has approved an [amendment](amendments.html) for which your server doesn't have an implementation. Most likely, you can fix this by [updating rippled](install-rippled.html) to the latest version. You can also use the [feature method][] to see what amendment IDs are currently enabled and which one(s) your server does and does not support.
- **`peers`** - This field indicates how many other servers in the XRP Ledger peer-to-peer network your server is connected to. Healthy servers typically show between 5 and 50 peers, unless explicitly configured to connect only to certain peers.
- If you have 0 peers, your server may be unable to contact the network, or your system clock may be wrong. (Ripple recommends running an [NTP](http://www.ntp.org/) daemon on all servers to keep their clocks synced.)
- If you have exactly 10 peers, that may indicate that your `rippled` is unable to receive incoming connections through a router using [NAT](https://en.wikipedia.org/wiki/Network_address_translation). You can improve connectivity by configuring your router's firewall to forward the port used for peer-to-peer connections (port 51235 [by default](https://github.com/ripple/rippled/blob/8429dd67e60ba360da591bfa905b58a35638fda1/cfg/rippled-example.cfg#L1065)).
### No Response from Server
The `rippled` executable returns the following message if it wasn't able to connect as a client to the `rippled` server:
```json
{
"error" : "internal",
"error_code" : 71,
"error_message" : "Internal error.",
"error_what" : "no response from server"
}
```
This generally indicates one of several problems:
- 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.
## Check the server log
[By default,](https://github.com/ripple/rippled/blob/master/cfg/rippled-example.cfg#L1139-L1142) `rippled` writes the server's debug log to the file `/var/log/rippled/debug.log`. The location of the debug log can differ based on your server's config file. If you start the `rippled` service directly (instead of using `systemctl` or `service` to start it), it also prints log messages to the console by default.
The default config file sets the log level to severity "warning" for all categories of log messages by internally using the [log_level method][] during startup. You can control the verbosity of the debug log [using the `--silent` commandline option during startup](commandline-usage.html#verbosity-options) and with the [log_level method][] while the server is running. (See the `[rpc_startup]` stanza of the config file for settings.)
It is normal for a `rippled` the server to print many warning-level (`WRN`) messages during startup and a few warning-level messages from time to time later on. You can **safely ignore** most warnings in the first 5 to 15 minutes of server startup.
For a more thorough explanation of various types of log messages, see [Understanding Log Messages](understanding-log-messages.html).
## Info Collection Script
If you have problems diagnosing the problem, or you are unable to resolve the problem with any of the common fixes, you may want to ask for help in a support forum or the [GitHub issues](https://github.com/ripple/rippled/issues). When asking for help, you can use an info collection script to gather information about your system to help others diagnose the issue.
The official package installation (for [Ubuntu/Debian](install-rippled-on-ubuntu.html) or [CentOS/RedHat](install-rippled-on-centos-rhel-with-yum.html)) installs such a script by default, to `/opt/ripple/bin/getRippledInfo`. [New in: rippled 1.5.0][] If you compiled `rippled` yourself, you can find the same script [in the `rippled` source code repository](https://github.com/ripple/rippled/blob/develop/bin/getRippledInfo).
To use the script:
1. Run the script while `rippled` is running.
$ /opt/ripple/bin/getRippledInfo
####################################################
rippled info has been gathered. Please copy the
contents of /tmp/ripple_info.Xo8Xr/rippled_info.md
to a github gist at https://gist.github.com/
PLEASE REVIEW THIS FILE FOR ANY SENSITIVE DATA
BEFORE POSTING! We have tried our best to omit
any sensitive information from this file, but you
should verify before posting.
####################################################
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.
The script attempts to scrub sensitive information from the output, such as validator keys or tokens. However, you should still check the output before posting publicly, as a precaution. For example, the script outputs detailed information about your server hardware, and you may want to remove some sections for privacy reasons. Use a text editor to read the output file and to remove anything you don't want to post.
nano /tmp/ripple_info.Xo8Xr/rippled_info.md
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. <!-- SPELLING_IGNORE: pastebin -->
## See Also
- **Concepts:**
- [The `rippled` Server](xrpl-servers.html)
- [Amendments](amendments.html)
- **Tutorials:**
- [Capacity Planning](capacity-planning.html)
- [Configure rippled](configure-rippled.html)
- **References:**
- [rippled API Reference](http-websocket-apis.html)
- [`rippled` Commandline Usage](commandline-usage.html)
- [log_level method][]
- [server_info method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

178
content/infrastructure/rippled/troubleshooting/fix-sqlite-tx-db-page-size-issue.ja.md Normal file
View File

@@ -0,0 +1,178 @@
---
html: fix-sqlite-tx-db-page-size-issue.html
parent: troubleshoot-the-rippled-server.html
blurb: rippledバージョン0.40.0以前で起動された完全履歴サーバーでのSQLiteのページサイズに関する問題を解決します。
---
# SQLiteトランザクションデータベースのページサイズの問題の解決
全トランザクション履歴（または極めて大量のトランザクション履歴）が記録されている`rippled`サーバーと、0.40.0（2017年1月リリース）よりも古いバージョンの`rippled`で最初に作成されたデータベースでは、SQLiteデータベースのページサイズが原因でサーバーが適切に稼働しなくなる問題が発生する可能性があります。最近のトランザクション履歴のみが保管されているサーバー（デフォルト構成）と、バージョン0.40.0以降の`rippled`でデータベースファイルが作成されているサーバーでは、この問題が発生する可能性はそれほどありません。
このドキュメントでは、この問題の発生時に問題を検出し解決する手順を説明します。
## 背景
`rippled` サーバーではトランザクション履歴のコピーがSQLiteデータベースに保管されます。バージョン0.40.0より古い`rippled`では、このデータベースの容量は約2TBに設定されました。ほとんどの場合はこの容量で十分です。ただし、レジャー32570（本番環境XRP Ledgerの履歴で利用可能な最も古いレジャーバージョン）以降の全トランザクション履歴は、このSQLiteデータベースの容量を超える可能性があります。`rippled`サーバーバージョン0.40.0以降では、これよりも大きな容量でSQLiteデータベースファイルが作成されているため、この問題が発生する可能性は低くなります。
SQLiteデータベースの容量は、データベースの_ページサイズ_パラメーターによって決まります。この容量は、データベース作成後は容易に変更できません。（SQLiteの内部についての詳細は、[SQLite公式ドキュメント](https://www.sqlite.org/fileformat.html)を参照してください。）データベースが保管されているディスクとファイルシステムに空き容量がある場合でも、データベースが容量いっぱいになることがあります。以下の「[解決策](#解決策)」で説明するように、この問題を回避するためにページサイズを再構成するには、時間のかかる移行プロセスが必要です。
**ヒント:** ほとんどの場合、`rippled`サーバーの稼働に全履歴が必要となることはありません。サーバーにトランザクションの全履歴が記録されていれば、長期分析やアーカイブ、または災害に対する事前対策に役立ちます。リソースを大量に消費せずにトランザクション履歴を保管する方法については、[履歴シャーディング](history-sharding.html)を参照してください。
## 検出
サーバーがこの問題に対して脆弱である場合は、次の2種類の方法でこの問題を検出できます。
- ご使用の`rippled`サーバーが[バージョン1.1.0][新規: rippled 1.1.0]以降の場合、（問題が発生する前に）[事前に](#事前の検出)問題を検出できます。
- （サーバーがクラッシュした場合）どの`rippled`バージョンでも、問題を[事後に](#事後の検出)特定できます。
いずれの場合でも、問題を検出するには`rippled`のサーバーログへのアクセスが必要です。
**ヒント:** このデバッグログの位置は、`rippled`サーバーの構成ファイルの設定に応じて異なる可能性があります。[デフォルトの構成](https://github.com/ripple/rippled/blob/master/cfg/rippled-example.cfg#L1139-L1142)では、サーバーのデバッグログは`/var/log/rippled/debug.log`ファイルに書き込まれます。
### 事前の検出
SQLiteのページサイズの問題を事前に検出するには、 **[rippled 1.1.0][新規: rippled 1.1.0]以上**を実行している必要があります。`rippled`サーバーは、以下のようなメッセージをデバッグログに定期的に（少なくとも2分間隔で）書き込みます。（ログエントリーの正確な数値とトランザクションデータベースへのパスは、ご使用の環境に応じて異なります。）
```text
Transaction DB pathname:/opt/rippled/transaction.db; SQLite page size:1024
bytes; Free pages:247483646; Free space:253423253504 bytes; Note that this
does not take into account available disk space.
```
`SQLite page size: 1024 bytes`という値は、トランザクションデータベースが小さいページサイズで構成されており、全トランザクション履歴に対応できる容量がないことを示しています。この値がすでに4096バイト以上の場合、SQLiteデータベースにはすでに全トランザクション履歴を保管できる十分な容量があり、このドキュメントで説明する移行を行う必要はありません。
`rippled`サーバーは、このログメッセージに示されている`Free space`が524288000バイト（500MB）未満になると停止します。空き容量がこのしきい値に近づいている場合は、予期しない停止を回避するために[この問題を解決](#解決策)してください。
### 事後の検出
サーバーのSQLiteデータベース容量をすでに超えている場合には、`rippled`サービスがこの問題を示すログメッセージを書き込み、停止します。
#### rippled 1.1.0以降
`rippled`バージョン1.1.0以降では、サーバーは以下のようなメッセージをサーバーのデバッグログに書き込み、通常の方法でシャットダウンします。
```text
Free SQLite space for transaction db is less than 512MB.To fix this, rippled
must be executed with the vacuum <sqlitetmpdir> parameter before restarting.
Note that this activity can take multiple days, depending on database size.
```
#### rippled 1.1.0より前
バージョン1.1.0より前の`rippled`では、サーバーが繰り返しクラッシュし、以下のようなメッセージがサーバーのデバッグログに書き込まれます。
```text
Terminating thread doJob:AcquisitionDone: unhandled
N4soci18sqlite3_soci_errorE 'sqlite3_statement_backend::loadOne: database or
disk is full while executing "INSERT INTO [...]
```
## 解決策
この問題を解決するには、このドキュメントで説明する手順に従い、サポートされているLinuxシステムで`rippled`を使用します。[推奨されるハードウェア構成](capacity-planning.html#推奨事項-1)とおおよそ一致するシステムスペックで全履歴を記録するサーバーの場合、このプロセスにかかる日数は2日を超える可能性があります。
### 前提条件
- **[rippledバージョン1.1.0][新規: rippled 1.1.0]以上**を実行している必要があります。
- このプロセスを開始する前に、安定した最新バージョンに[rippledをアップグレード](install-rippled.html)します。
- 以下のコマンドを実行して、ローカルにインストールした`rippled`のバージョンを確認できます。
rippled --version
- `rippled`ユーザーが書き込めるディレクトリーに、トランザクションデータベースの2つめのコピーを一時的に保管するのに十分な空き容量が必要です。この空き容量は、既存のトランザクションデータベースと同じファイルシステムに設ける必要はありません。
トランザクションデータベースは、構成の`[database_path]`設定で指定されるフォルダーの`transaction.db`ファイルに保管されます。このファイルのサイズを調べ、必要な空き容量を確認できます。次に例を示します。
ls -l /var/lib/rippled/db/transaction.db
### 移行プロセス
トランザクションデータベースを大きなページサイズに移行するには、以下の手順を実行します。
1. すべての[前提条件](#前提条件)を満たしていることを確認します。
2. 移行プロセスの実行中に一時ファイルを保管するフォルダーを作成します。
mkdir /tmp/rippled_txdb_migration
3. `rippled`ユーザーに、一時フォルダーの所有権を付与します。これにより、ユーザーは一時フォルダー内のファイルに書き込みできるようになります。（`rippled`ユーザーがすでにアクセス権限を持つ場所に一時フォルダーがある場合は、この操作は不要です。）
chown rippled /tmp/rippled_txdb_migration
4. 一時フォルダーに、トランザクションデータベースのコピーを保管するのに十分な空き容量があることを確認します。
たとえば、`df`コマンドの`Avail`出力と、[`transaction.db`ファイルのサイズ](#前提条件)を比較します。
df -h /tmp/rippled_txdb_migration
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 5.4T 2.6T 2.6T 50% /tmp
5. `rippled`がまだ稼働している場合は停止します。
sudo systemctl stop rippled
6. `screen`セッション（または類似のツール）を開き、ログアウトしてもプロセスが停止しないようにします。
screen
7. `rippled`ユーザーになります。
sudo su - rippled
8. 一時ディレクトリへのパスを指定した`--vacuum`コマンドで、`rippled`実行可能ファイルを直接実行できます。
/opt/ripple/bin/rippled -q --vacuum /tmp/rippled_txdb_migration
`rippled`実行可能ファイルにより次のメッセージが即時に表示されます。
VACUUM beginning. page_size:1024
9. プロセスが完了するまで待ちます。これには丸2日以上かかることがあります。
プロセスが完了したら、`rippled`実行可能ファイルは以下のメッセージを表示して終了します。
VACUUM finished. page_size:4096
待機している間に`screen`セッションを切り離すには、**CTRL-A**を押してから**D**を押します。その後、以下のようなコマンドでスクリーンセッションを再接続します。
screen -x -r
プロセスが完了したら、スクリーンセッションを終了します。
exit
`screen`コマンドについての詳細は、[公式Screenユーザーマニュアル](https://www.gnu.org/software/screen/manual/screen.html)またはオンラインで使用可能なその他の多数のリソースを参照してください。
10. `rippled`サービスを再起動します。
sudo systemctl start rippled
11. `rippled`サービスが正常に起動したかどうかを確認します。
[コマンドラインインターフェイス](get-started-using-http-websocket-apis.html#コマンドライン)を使用してサーバーの状況を確認できます（サーバーがJSON-RPC要求を受け入れないように設定している場合を除く）。次に例を示します。
/opt/ripple/bin/rippled server_info
このコマンドの予期される応答の説明については、[server_infoメソッド][]ドキュメントを参照してください。
12. サーバーのデバッグログを参照し、`SQLite page size`が現在4096であることを確認します。
tail -F /var/log/rippled/debug.log
また[定期的なログメッセージ](#事前の検出)には、移行前に比べて非常に多くのフリーページとフリースペースが示されているはずです。
13. 必要に応じて、移行プロセスのために作成した一時フォルダーをこの時点で削除できます。
rm -r /tmp/rippled_txdb_migration
トランザクションデータベースの一時コピーを保持するために追加のストレージをマウントした場合は、この時点でそのストレージをアンマウントして取り外すことができます。
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

193
content/infrastructure/rippled/troubleshooting/fix-sqlite-tx-db-page-size-issue.md Normal file
View File

@@ -0,0 +1,193 @@
---
html: fix-sqlite-tx-db-page-size-issue.html
parent: troubleshoot-the-rippled-server.html
blurb: Fix a problem with the SQLite page size on full-history servers started on rippled version 0.40.0 or earlier.
status: removed
---
# Fix SQLite Transaction Database Page Size Issue
`rippled` servers with full [ledger history](ledger-history.html) (or a very large amount of transaction history) and a database that was initially created with a `rippled` version earlier than 0.40.0 (released January 2017) may encounter a problem with their SQLite database page size that stops the server from operating properly. Servers that store only recent transaction history (the default configuration) and servers whose database files were created with `rippled` version 0.40.0 and later are not likely to have this problem. <!-- STYLE_OVERRIDE: encounter -->
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 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. <!-- STYLE_OVERRIDE: easily -->
**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
If your server is vulnerable to this problem, you can detect it two ways:
- You can detect the problem [proactively](#proactive-detection) (before it causes problems) if your `rippled` server is [version 1.1.0][New in: rippled 1.1.0] or later.
- You can identify the problem [reactively](#reactive-detection) (when your server is crashing) on any `rippled` version.
In both cases, detection of the problem requires access to `rippled`'s server logs.
**Tip:** The location of the debug log depends on your `rippled` server's config file. The [default configuration](https://github.com/ripple/rippled/blob/master/cfg/rippled-example.cfg#L1139-L1142) writes the server's debug log to the file `/var/log/rippled/debug.log`.
### Proactive Detection
To detect the SQLite page size problem proactively, you must be running **[rippled 1.1.0][New in: rippled 1.1.0] or later**. The `rippled` server writes a message such as the following in its debug log periodically, at least once every 2 minutes. (The exact numeric values from the log entry and the path to your transaction database depend on your environment.)
```text
Transaction DB pathname: /opt/rippled/transaction.db; SQLite page size: 1024
bytes; Free pages: 247483646; Free space: 253423253504 bytes; Note that this
does not take into account available disk space.
```
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 (500 MB). If your free space is approaching that threshold, [fix the problem](#fix) to avoid an unexpected outage.
### Reactive Detection
If your server's SQLite database capacity has already been exceeded, the `rippled` service writes a log message indicating the problem and halts.
#### rippled 1.1.0 and Later
On `rippled` versions 1.1.0 and later, the server shuts down gracefully with a message such as the following in the server's debug log:
```text
Free SQLite space for transaction db is less than 512MB. To fix this, rippled
must be executed with the vacuum <sqlitetmpdir> parameter before restarting.
Note that this activity can take multiple days, depending on database size.
```
#### Earlier than rippled 1.1.0
On `rippled` versions before 1.1.0, the server crashes repeatedly with messages such as the following in the server's debug log:
```text
Terminating thread doJob: AcquisitionDone: unhandled
N4soci18sqlite3_soci_errorE 'sqlite3_statement_backend::loadOne: database or
disk is full while executing "INSERT INTO [...]
```
## Fix
You can fix this issue using `rippled` on supported Linux systems according to the steps described in this document. In the case of a full-history server with system specs approximately matching the [recommended hardware configuration](capacity-planning.html#recommendation-1), the process may take more than two full days.
### Prerequisites
- You must be running **[rippled version 1.1.0][New in: rippled 1.1.0] or later**.
- [Upgrade rippled](install-rippled.html) to the latest stable version before starting this process.
- You can check what version of `rippled` you have installed locally by running the following command:
rippled --version
- You must have enough free space to temporarily store a second copy of the transaction database, in a directory that is writable by the `rippled` user. This free space does not need to be in the same filesystem as the existing transaction database.
The transaction database is stored in the `transaction.db` file in the folder specified by your configuration's `[database_path]` setting. You can check the size of this file to see how much free space you need. For example:
ls -l /var/lib/rippled/db/transaction.db
### Migration Process
To migrate your transaction database to a larger page size, perform the following steps:
1. Check that you meet all the [prerequisites](#prerequisites).
2. Create a folder to store temporary files during the migration process.
mkdir /tmp/rippled_txdb_migration
3. Grant the `rippled` user ownership of the temporary folder so it can write files there. (This is not necessary if your temporary folder is somewhere the `rippled` user already has write access to.)
chown rippled /tmp/rippled_txdb_migration
4. Confirm that your temporary folder has enough free space to store a copy of the transaction database.
For example, compare the `Avail` output from the `df` command to the [size of your `transaction.db` file](#prerequisites).
df -h /tmp/rippled_txdb_migration
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 5.4T 2.6T 2.6T 50% /tmp
5. If `rippled` is still running, stop it:
sudo systemctl stop rippled
6. Open a `screen` session (or other similar tool) so that the process does not stop when you log out:
screen
7. Become the `rippled` user:
sudo su - rippled
8. Run `rippled` executable directly, providing the `--vacuum` command with the path to the temporary directory:
/opt/ripple/bin/rippled -q --vacuum /tmp/rippled_txdb_migration
The `rippled` executable immediately displays the following message:
VACUUM beginning. page_size: 1024
9. Wait for the process to complete. This can take more than two full days.
When the process is complete, the `rippled` executable displays the following message, then exits:
VACUUM finished. page_size: 4096
While you wait, you can detach your `screen` session by pressing **CTRL-A**, then **D**. Later, you can reattach your screen session with a command such as the following:
screen -x -r
When the process is over, exit the screen session:
exit
For more information on the `screen` command, see [the official Screen User's Manual](https://www.gnu.org/software/screen/manual/screen.html) or any of the other many resources available online.
10. Restart the `rippled` service.
sudo systemctl start rippled
11. Confirm that the `rippled` service started successfully.
You can use the [commandline interface](get-started-using-http-websocket-apis.html#commandline) to check the server status (unless you have configured your server not to accept JSON-RPC requests). For example:
/opt/ripple/bin/rippled server_info
For a description of the expected response from this command, see the [server_info method][] documentation.
12. Watch the server's debug log to confirm that the `SQLite page size` is now 4096:
tail -F /var/log/rippled/debug.log
The [periodic log message](#proactive-detection) should also show significantly more free pages and free pages than it did before the migration.
13. Optionally, you may now remove the temporary folder you created for the migration process.
rm -r /tmp/rippled_txdb_migration
If you mounted additional storage to hold the temporary copy of the transaction database, you can unmount and remove it now.
## See Also
- **Concepts:**
- [The `rippled` Server](xrpl-servers.html)
- [Ledger History](ledger-history.html)
- **Tutorials:**
- [Understanding Log Messages](understanding-log-messages.html)
- [Configure Full History](configure-full-history.html)
- **References:**
- [rippled API Reference](http-websocket-apis.html)
- [`rippled` Commandline Usage](commandline-usage.html)
- [server_info method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

117
content/infrastructure/rippled/troubleshooting/health-check-interventions.md Normal file
View File

@@ -0,0 +1,117 @@
---
html: health-check-interventions.html
parent: troubleshoot-the-rippled-server.html
blurb: Use the rippled server's health check as part of automated infrastructure monitoring.
labels:
- Core Server
---
# Health Check Interventions
The [Health Check method](health-check.html) can be used by automated monitoring to recognize when a `rippled` server is not healthy and prompt interventions such as restarting the server or alerting a human administrator.
Infrastructure monitoring, and reliability engineering more generally, is an advanced discipline that involves using multiple sources of data to make decisions in context. This document provides some suggestions for how to use the health check most effectively, but these recommendations are only meant as guidelines as part of a larger strategy.
## Momentary Failures
Some [metrics][] in the health check can rapidly fluctuate into unhealthy ranges and then recover automatically shortly afterward. It is unnecessary and undesirable to raise alerts every single time the health check reports an unhealthy status. An automated monitoring system should call the health check method often, but only escalate to a higher level of intervention if the problem is severe and consistent.
For example, if you check the health of the server once per second, you might raise an alert if the server reports "warning" status three times in a row, or four times in a five-second span. You might also raise an alert if the server reports "critical" status twice in a five-second span. It is usually excessive to raise an alert every single time the server reports "warning".
**Tip:** The server normally reports a "critical" status for the first few seconds after startup, switches to a "warning" status after it establishes a connection to the network, and finally reports a "healthy" status when it has fully synced to the network. After a restart, you should give a server 5–15 minutes to sync before taking additional interventions.
## Special Cases
Certain server configurations may always report a `warning` status even when operating normally. If your server qualifies as a special case, you must configure your automated monitoring to recognize the difference between the normal status and an actual problem. This probably involves parsing the JSON response body for the health check method and comparing the values there with expected normal ranges.
Some examples of special cases that may occur include:
- A [private peer](peer-protocol.html#private-peers) typically has a very small number of peer-to-peer connections to known servers only, but the health check reports a warning on the `peers` metric if the server is connected to 7 or fewer peers. You should know the exact number of peers your server is configured to have and check for that value.
- On a [parallel or test network](parallel-networks.html) where new transactions are not being sent continuously, the network waits up to 20 seconds for new transactions before attempting to validate a new ledger version, but the health check reports a warning on the `validated_ledger` metric if the latest validated ledger is 7 or more seconds old. If you are running `rippled` on a non-production network, you may want to ignore `warning` messages for this metric unless you know that there should be transactions being regularly sent. You may still want to alert on the `critical` level of 20 seconds, because the XRP Ledger protocol is designed to validate new ledger versions at least once every 20 seconds even if there are no new transactions to process.
## Suggested Interventions
When a health check fails, and it's not just a [momentary failure](#momentary-failures), the action to take to recover from the outage varies based on the cause. You may be able to configure your infrastructure to fix some types of failures automatically. Other failures require the intervention of a human administrator who can investigate and take the necessary steps to resolve more complex or critical failures; depending on the structure of your organization, you may have different levels of human administrator so that less skilled, lower level administrators can fix certain issues independently, but need to escalate to higher level administrators to fix larger or more complex issues. How and when you respond is likely to depend on your unique situation, but the metrics reported in the health check result can be a factor in these decisions. <!-- STYLE_OVERRIDE: just -->
The following sections suggest some common interventions you may want to attempt and the health check statuses most likely to prompt those interventions. Automated systems and human administrators may selectively escalate through these and other interventions:
- [Redirect traffic](#redirect-traffic) away from the affected server
- [Restart](#restart) the server software or hardware
- [Upgrade](#upgrade) the `rippled` software
- [Investigate network](#investigate-network) in case the problem originates elsewhere
- [Replace hardware](#replace-hardware)
### Redirect Traffic
A common reliability technique is to run a pool of redundant servers through one or more load-balancing proxies. You can do this with `rippled` servers, but should not do this with [validators](rippled-server-modes.html). In some cases, the load balancers can monitor the health of servers in their pools and direct traffic only to the servers that are currently reporting themselves as healthy. This allows servers to recover from being temporarily overloaded and automatically rejoin the pool of active servers.
Redirecting traffic away from a server that is unhealthy is an appropriate response, especially for servers that report a `health` status of `warning`. Servers in the `critical` range may need more significant interventions.
### Restart
The most straightforward intervention is to restart the server. This can resolve temporary issues with several types of failures, including any of the following [metrics][]:
- `load_factor`
- `peers`
- `server_state`
- `validated_ledger`
To restart only the `rippled` service, use `systemctl`:
```
$ sudo systemctl restart rippled.service
```
A stronger intervention is to restart the entire machine.
**Caution:** After a server starts, it typically needs up to 15 minutes to sync to the network. During this time, the health check is likely to report a critical or warning status. You should be sure your automated systems give servers enough time to sync before restarting them again.
### Upgrade
If the server reports `"amendment_blocked": true` in the health check, this indicates that the XRP Ledger has enabled a [protocol amendment](amendments.html) that your server does not understand. As a precaution against misinterpreting the revised rules of the network in a way that causes you to lose money, such servers become "amendment blocked" instead of operating normally.
To resolve being amendment blocked, [update your server](install-rippled.html) to a newer software version that understands the amendment.
Also, software bugs can cause a server to get [stuck not syncing](server-doesnt-sync.html). In this case, the `server_state` metric is likely to be in a warning or critical state. If you are not using the latest stable release, you should upgrade to get the latest fixes for any known issues that could cause this.
### Investigate Network
An unreliable or insufficient network connection can cause a server to report outages. Warning or critical values in the following [metrics][] can indicate network problems:
- `peers`
- `server_state`
- `validated_ledger`
In this case, the necessary interventions may involve changes to other systems, such as:
- Adjusting firewall rules to allow necessary traffic to reach a server, or to block harmful traffic from outside
- Restarting or replacing network interfaces, switches, routers, or cabling
- Contacting other network service providers to resolve an issue on their end
### Replace Hardware
If the outage is caused by a hardware failure or by higher load than the hardware is capable of handling, you may need to replace some components or even the entire server.
The amount of load on a server in the XRP Ledger depends in part on transaction volume in the network, which varies organically. Load also depends on your usage pattern. See [Capacity Planning](capacity-planning.html) for how to plan the appropriate hardware and settings for your situation.
Warning or critical values for the following [metrics][] may indicate insufficient hardware:
- `load_factor`
- `server_state`
- `validated_ledger`
<!--{# common link defs #}-->
[metrics]: health-check.html#response-format
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

115
content/infrastructure/rippled/troubleshooting/server-doesnt-sync.ja.md Normal file
View File

@@ -0,0 +1,115 @@
---
html: server-doesnt-sync.html
parent: troubleshoot-the-rippled-server.html
blurb: Troubleshoot problems that make a rippled server unable to sync with the rest of the XRP Ledger.
labels:
- コアサーバー
---
# rippledサーバーが同期しない
このページでは、[`rippled`サーバー](xrpl-servers.html)が正常に起動したのに、ネットワークに完全に接続できずに[「connected」状態](rippled-server-states.html)のままになっている場合の原因について説明します。（サーバーが起動中または起動直後にクラッシュした場合は、[サーバーが起動しない](server-wont-start.html)を参照してください。）
以下の手順では、サポートされているプラットフォームに[`rippled`がインストール](install-rippled.html)されていることを前提としています。
## 通常の同期動作
ネットワークとの同期は、通常はおよそ5分から15分で完了します。その間に、サーバーは次のようなさまざまなことを行います。
- 推奨バリデータリストを読み込み（通常は`vl.ripple.com`から）、信頼できるバリデータを判断します。
- [ピアサーバーを検出](peer-protocol.html#ピアの検出)して接続します。
- ピアから最新のレジャーの[ヘッダー](ledger-header.html)と完全な[状態情報](ledgers.html#ツリーの形式)をダウンロードし、それを使用してレジャーデータの内部データベースを構築します。
- 信頼できるバリデータをリッスンして、最近検証されたレジャーハッシュを見つけます。
- 新たにブロードキャストされたトランザクションを収集し、それを進行中のレジャーに適用します。
サーバーがこれらのタスクを行うときにネットワークに同調して対応できなかった場合は、サーバーはネットワークと同期しない状態になります。
## 最初のステップ: 再起動
多くの同期の問題は、サーバーを再起動することで解決できます。最初に同期が失敗した原因がどのようなものであっても、2回目では成功する場合があります。
[server_infoメソッド][]で[`server_state`](rippled-server-states.html)が`proposing`または`full`以外の状態であると示され、`server_state_duration_us`が`900000000`（15分のマイクロ秒表記）より大きい場合は、`rippled`サービスをシャットダウンしてから数秒間待ち、再起動してください。場合によっては、マシン全体を再起動します。
問題が解決しない場合は、このページに記載されている他の原因を確認してください。いずれも当てはまらないと思われる場合は、[`rippled`リポジトリに問題を登録](https://github.com/ripple/rippled/issues)し、「Syncing issue」ラベルを追加します。
## 同期の問題のよくある原因
同期の問題の原因として最もよくあるのは、[システム要件](system-requirements.html)を満たしていないことです。要件を満たせない主な原因は次の3つです。
- **低速なディスク。** 安定して高速な性能を発揮するソリッドステートディスク（SSD）が必要です。AWSなどのクラウドプロバイダーはディスク性能を保証しておらず、ハードウェアを共有する他のユーザーの影響を受ける可能性があります。
- **不十分なRAM。** メモリー要件はさまざまな要因に大きく左右されます。例えば、ネットワークの負荷やXRP Ledgerがどのように使われるかなど、予測しづらい要因もあるため、念のため最小システム要件よりも大きいメモリーを用意することをお勧めします。
- **品質の悪いネットワーク接続。** ネットワーク要件は、主にXRP Ledgerをユーザーがどのよう使うかによって左右されますが、接続が低速または不安定な場合、XRP Ledgerに追加された新しいトランザクションやデータとの同期がとれなくなる可能性があります。
同期の問題が解消されない場合は、サーバーがシステム要件を満たしているかもう一度確認してください。サーバーの使用方法によっては、「最小」要件よりも高い「推奨」要件を満たす必要があります。「推奨」要件を満たしていても、まだ同期ができない場合は、このページの他の原因を試してみてください。
## バリデータリストを読み込めない
デフォルトの構成では、`vl.ripple.com`から受信した推奨バリデータリストを使用します。このリストは、Rippleの暗号鍵ペアで署名されており、有効期限が組み込まれています。サーバーが何らかの理由でリストを`vl.ripple.com`からダウンロードできない場合、サーバーは信頼できるバリデータのセットを選択せず、有効として宣言できるレジャーを決定できません。（[Testnetや別の並列ネットワーク](parallel-networks.html)に接続している場合、サーバーは代わりにそのネットワークの信頼できるバリデータのリストを使用します。）
[server_infoメソッド][]応答の`validator_list`ブロックは、バリデータリストの有効期限などのステータスを示します。リストがあるが期限切れである場合、サーバーは以前はそのバリデータリストのサイトに接続できていたものの、その後接続できなくなった可能性があります。その場合、現在のリストはサーバーがそれより新しいリストをダウンロードできなかったために期限切れとなった可能性があります。
また、[validator_list_sitesメソッド][]を使用して、より詳細な情報を取得することもできます。応答内のバリデータサイトオブジェクトに`last_refresh_status`および`last_refresh_time`フィールドがない場合、サーバーからバリデータリストのサイトへの接続に問題があることを示しています。ファイアウォールの設定をチェックして、ポート80（HTTP）または443（HTTPS）の発信トラフィックをブロックしていないことを確認してください。また、DNSがバリデータリストのサイトのドメインを解決できることも確認してください。
<!-- TODO: create a tutorial for how to sideload a validator list from file and link it here -->
## 十分な数のピアがない
サーバーが十分な数の[ピアサーバー](peer-protocol.html)に接続していない場合、サーバーは十分なデータをダウンロードできず、ネットワークが新しいトランザクションを処理するときに同期がとれなくなる可能性があります。この問題は、ネットワーク接続の信頼性が低い場合や、十分な数の信頼できる固定ピアを追加せずにサーバーを[プライベートサーバー](peer-protocol.html#プライベートピア)として構成している場合に起こる可能性があります。
[peersメソッド][]を使用して、サーバーの現在のピアについての情報を取得します。ピアの数が10または11の場合、ファイアウォールが着信ピア接続をブロックしていることを示しています。[ポートフォワーディングを設定](forward-ports-for-peering.html)して、より多くの着信接続を許可します。サーバーがプライベートサーバーとして構成されている場合は、構成ファイルの`[ips_fixed]`スタンザの内容と構文を再度確認し、可能であればプロキシと公開ハブをさらに追加します。
## データベースの破損
まれに、`rippled`サーバーの内部データベースに保存されているデータが破損していることで同期の問題が発生する場合があります。サーバーが稼動中でなければ、ほとんどの場合、サーバーのデータベースを安全に削除できます。データの破損は、ディスクにコピーまたは書き込みするときに起こった一時的なハードウェア障害や、より深刻なディスク障害、別のプロセスがクラッシュしてディスクの誤った部分に書き込んだなど、さまざまな問題の結果として起こる可能性があります。
テストとして、十分な空き容量があれば、サーバーのデータベースへのパスを一時的に変更することで、現行のレジャーをダウンロードし直して、別の設定を保存できます。
**注記:** データベースのパスを変更した場合、サーバーはサーバーの現在の[ノードキーペア][]や[ピアリザベーション](peer-protocol.html#固定ピアとピアリザベーション)など、保存されている一部の設定を読み込めません。データベースのパスを変更することでサーバーの同期の問題が解決した場合は、これらの設定の一部を再作成することをお勧めします。
1. `rippled`サーバーが稼働中の場合は停止します。
$ sudo systemctl stop rippled
2. 新しいデータベースを格納するための新しい空のフォルダーを作成します。
$ mkdir /var/lib/rippled/db_new/
$ mkdir /var/lib/rippled/db_new/nudb
3. 新しいパスを使用するように構成ファイルを編集します。`[node_db]`スタンザの`path`フィールド**と**`[database_path]`スタンザの値を変更します。
[node_db]
type=NuDB
path=/var/lib/rippled/db_new/nudb
[database_path]
/var/lib/rippled/db_new
{% include '_snippets/conf-file-location.md' %}<!--_ -->
4. `rippled`サーバーを再起動します。
$ sudo systemctl start rippled
新しいデータベースを使用してサーバーが同期に成功したら、以前のデータベースを格納していたフォルダーを削除できます。また、ハードウェア障害、特にディスクとRAMの障害を確認することもお勧めします。
## 関連項目
- **コンセプト:**
- [`rippled`サーバー](xrpl-servers.html)
- [ピアプロトコル](peer-protocol.html)
- [技術に関するよくある質問](technical-faq.html)
- **チュートリアル:**
- [ログメッセージについて](understanding-log-messages.html)
- [容量の計画](capacity-planning.html)
- **リファレンス:**
- [rippled APIリファレンス](http-websocket-apis.html)
- [peersメソッド][]
- [server_infoメソッド][]
- [validator_list_sitesメソッド][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

120
content/infrastructure/rippled/troubleshooting/server-doesnt-sync.md Normal file
View File

@@ -0,0 +1,120 @@
---
html: server-doesnt-sync.html
parent: troubleshoot-the-rippled-server.html
blurb: Troubleshoot problems that make a rippled server unable to sync with the rest of the XRP Ledger.
labels:
- Core Server
---
# rippled Server Doesn't Sync
This page explains possible reasons [a `rippled` server](xrpl-servers.html) may start successfully, but get stuck in a ["connected" state](rippled-server-states.html) without ever fully connecting to the network. (If the server crashes during or shortly after startup, see [Server Won't Start](server-wont-start.html) instead.)
These instructions assume you have [installed `rippled`](install-rippled.html) on a supported platform.
## Normal Syncing Behavior
Syncing with the network normally takes about 5 to 15 minutes. During that time, the server does several things:
- Loads a recommended validator list (for example, from `vl.ripple.com`) to determine which validators it trusts.
- [Discovers peer servers](peer-protocol.html#peer-discovery) and connects to them.
- Listens to its trusted validators to find which ledger hashes have been recently validated.
- Downloads the full latest ledger from its peers, and uses that to build its internal database of ledger data.
- Collects newly-broadcast transactions and attempts to apply them to its in-progress ledger.
If the server is unable to keep up with the network while doing these tasks, the server does not sync to the network.
## First Step: Restart
Many syncing issues can be resolved by restarting the server. No matter why it didn't sync the first time, it may succeed on the second try.
If the [server_info method][] shows a [`server_state`](rippled-server-states.html) other than `proposing` or `full` and a `server_state_duration_us` of more than `900000000` (15 minutes in microseconds), then you should shut down the `rippled` service, wait a few seconds, and start it again. Optionally, restart the entire machine.
If the problem persists, check the other possibilities listed on this page. If none of them seem to apply, [open an issue in the `rippled` repository](https://github.com/ripple/rippled/issues) and add the "Syncing issue" label.
## Usual Causes of Syncing Issues
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, because it depends on hardware shared with other customers.
- **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. If you meet the "Recommended" requirements and still cannot sync, try the other possibilities on this page.
## Couldn't Load Validator List
The default configuration uses a recommended list of validators retrieved from `vl.ripple.com`. This list is signed by Ripple's cryptographic key pair and has a built-in expiration date. If your server cannot download the list from `vl.ripple.com` for some reason, your server does not choose a set of trusted validators and cannot determine which possible ledgers to declare as valid. (If you are connected to [the testnet or another parallel network](parallel-networks.html), your server uses a list of trusted validators for that network instead.)
The `validator_list` block in the [server_info method][] response shows the status of your validator list including its expiration date. If you have a list, but it's expired, it's possible that your server had connectivity to the validator list site before but hasn't been able to connect lately, so your current list expired while your server was unable to download a more updated list.
You can also use the [validator_list_sites method][] to get more detailed information. If the `last_refresh_status` and `last_refresh_time` fields are missing from the validator site objects in the response, that probably indicates that your server is having trouble connecting to the validator list site. Check your firewall configuration to make sure you're not blocking outgoing traffic on port 80 (HTTP) or 443 (HTTPS). Also check that your DNS is able to resolve the domain of your validator list site.
<!-- TODO: create a tutorial for how to sideload a validator list from file and link it here -->
## Not Enough Peers
If your server does not connect to enough [peer servers](peer-protocol.html), it may not be able to download enough data to remain synced with the network as the network continues processing new transactions. This can happen if your network connection is unreliable, or if you configure your server as a [private server](peer-protocol.html#private-peers) without adding enough reliable fixed peers.
Use the [peers method][] to get information about your server's current peers. If you have exactly 10 or 11 peers, that may indicate that your firewall is blocking incoming peer connections. [Set up port forwarding](forward-ports-for-peering.html) to allow more incoming connections. If your server is configured as a private server, double-check the contents and syntax of the `[ips_fixed]` stanza in your config file, and add more proxies or public hubs if possible.
## Corrupt Databases
In rare cases, corrupt data saved in your `rippled` server's internal databases could cause it to fail to sync. You can safely delete your server's databases in most circumstances as long as the server is not running. Corrupt data can be the result of a momentary hardware failure when copying or writing to disk, a more serious disk failure, a different process crashing and writing to the wrong part of the disk, or other issues.
As a test, you can temporarily change the paths to your server's databases as long as you have enough free space to re-download the current ledger and store other settings.
**Note:** When you change the database paths, the server does not load some saved settings, such as the server's current [node key pair][] and [peer reservations](peer-protocol.html#fixed-peers-and-peer-reservations). If changing the database paths fixes your server' syncing problems, you may want to re-create some of these settings.
1. Stop the `rippled` server if it is running.
$ sudo systemctl stop rippled
2. Create new empty folders to hold the fresh databases.
$ mkdir /var/lib/rippled/db_new/
$ mkdir /var/lib/rippled/db_new/nudb
3. Edit the config file to use the new paths. Be sure to change the `path` field of the `[node_db]` stanza **and** the value of the `[database_path]` stanza.
[node_db]
type=NuDB
path=/var/lib/rippled/db_new/nudb
[database_path]
/var/lib/rippled/db_new
{% include '_snippets/conf-file-location.md' %}<!--_ -->
4. Start the `rippled` server again.
$ sudo systemctl start rippled
If the server successfully syncs using the fresh databases, you can delete the folders that hold the old databases. You may also want to check for hardware failures, especially to your disk and RAM.
## See Also
- **Concepts:**
- [The `rippled` Server](xrpl-servers.html)
- [Peer Protocol](peer-protocol.html)
- [Technical FAQ](technical-faq.html)
- **Tutorials:**
- [Understanding Log Messages](understanding-log-messages.html)
- [Capacity Planning](capacity-planning.html)
- **References:**
- [rippled API Reference](http-websocket-apis.html)
- [peers method][]
- [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' %}
{% include '_snippets/rippled_versions.md' %}

132
content/infrastructure/rippled/troubleshooting/server-is-amendment-blocked.md Normal file
View File

@@ -0,0 +1,132 @@
---
html: server-is-amendment-blocked.html
parent: troubleshoot-the-rippled-server.html
blurb: Troubleshoot a server that can't implement amendment changes.
labels:
- Core Server
---
# rippled Server is Amendment Blocked
Servers which are amendment blocked can't determine the validity of a ledger, submit or process transactions, or participate in the consensus process.
One of the first signs that your `rippled` server is [amendment blocked](amendments.html#amendment-blocked-servers) is an `amendmentBlocked` error that is returned when you submit a transaction. Here's an example `amendmentBlocked` error:
```json
{
"result":{
"error":"amendmentBlocked",
"error_code":14,
"error_message":"Amendment blocked, need upgrade.",
"request":{
"command":"submit",
"tx_blob":"479H0KQ4LUUXIHL48WCVN0C9VD7HWSX0MG1UPYNXK6PI9HLGBU2U10K3HPFJSROFEG5VD749WDPHWSHXXO72BOSY2G8TWUDOJNLRTR9LTT8PSOB9NNZ485EY2RD9D80FLDFRBVMP1RKMELILD7I922D6TBCAZK30CSV6KDEDUMYABE0XB9EH8C4LE98LMU91I9ZV2APETJD4AYFEN0VNMIT1XQ122Y2OOXO45GJ737HHM5XX88RY7CXHVWJ5JJ7NYW6T1EEBW9UE0NLB2497YBP9V1XVAEK8JJYVRVW0L03ZDXFY8BBHP6UBU7ZNR0JU9GJQPNHG0DK86S4LLYDN0BTCF4KWV2J4DEB6DAX4BDLNPT87MM75G70DFE9W0R6HRNWCH0X075WHAXPSH7S3CSNXPPA6PDO6UA1RCCZOVZ99H7968Q37HACMD8EZ8SU81V4KNRXM46N520S4FVZNSJHA"
},
"status":"error"
}
}
```
The following `rippled` log message also indicates that your server is amendment blocked:
```
2018-Feb-12 19:38:30 LedgerMaster:ERR One or more unsupported amendments activated: server blocked.
```
You can verify that your `rippled` server is amendment blocked using the `server_info` command. In the response, look for `result.info.amendment_blocked`. If `amendment_blocked` is set to `true`, your server is amendment blocked.
**Example JSON-RPC Response:**
```json
{
"result": {
"info": {
"amendment_blocked": true,
"build_version": "0.80.1",
"complete_ledgers": "6658438-6658596",
"hostid": "ip-10-30-96-212.us-west-2.compute.internal",
"io_latency_ms": 1,
"last_close": {
"converge_time_s": 2,
"proposers": 10
},
...
},
"status": "success"
}
}
```
## Unblock Servers
The easiest solution is to update to the latest version of `rippled`, but depending on the scenario, you may want to update to an older version with the amendment blocking your server.
**Warning:** If the newest `rippled` version provides security or other urgent fixes, you should upgrade to the newest version as soon as possible.
To determine if you can unblock your `rippled` server by upgrading to a version older than the newest version, find out which features are blocking your server and then look up the `rippled` version that supports the blocking features.
To find out which features are blocking your `rippled` server, use the [`feature`](feature.html) admin command. Look for features that have:
```
"enabled" : true
"supported" : false
```
These values mean the amendment is required in the latest ledger, but your server doesn't support the implementation.
**Example JSON-RPC Response:**
```json
{
"result": {
"features": {
"07D43DCE529B15A10827E5E04943B496762F9A88E3268269D69C44BE49E21104": {
"enabled": true,
"name": "Escrow",
"supported": true,
"vetoed": false
},
"08DE7D96082187F6E6578530258C77FAABABE4C20474BDB82F04B021F1A68647": {
"enabled": true,
"name": "PayChan",
"supported": true,
"vetoed": false
},
"1562511F573A19AE9BD103B5D6B9E01B3B46805AEC5D3C4805C902B514399146": {
"enabled": false,
"name": "CryptoConditions",
"supported": true,
"vetoed": false
},
"157D2D480E006395B76F948E3E07A45A05FE10230D88A7993C71F97AE4B1F2D1": {
"enabled": true,
"supported": false,
"vetoed": false
},
...
"67A34F2CF55BFC0F93AACD5B281413176FEE195269FA6D95219A2DF738671172": {
"enabled": true,
"supported": false,
"vetoed": false
},
...
"F64E1EABBE79D55B3BB82020516CEC2C582A98A6BFE20FBE9BB6A0D233418064": {
"enabled": true,
"supported": false,
"vetoed": false
}
},
"status": "success"
}
}
```
In this example, conflicts with the following features are causing your `rippled` server to be amendment blocked:
* `157D2D480E006395B76F948E3E07A45A05FE10230D88A7993C71F97AE4B1F2D1`
* `67A34F2CF55BFC0F93AACD5B281413176FEE195269FA6D95219A2DF738671172`
* `F64E1EABBE79D55B3BB82020516CEC2C582A98A6BFE20FBE9BB6A0D233418064`
To look up which `rippled` version supports these features, see [Known Amendments](known-amendments.html).

221
content/infrastructure/rippled/troubleshooting/server-wont-start.ja.md Normal file
View File

@@ -0,0 +1,221 @@
---
html: server-wont-start.html
parent: troubleshoot-the-rippled-server.html
blurb: rippledサーバーが起動しない原因となると思われる問題とその解決方法です。
labels:
- コアサーバー
---
# rippledサーバーが起動しない
このページでは、[`rippled`サーバー](xrpl-servers.html)が起動しない際に考えられる原因とその修正方法を説明します。
以下の手順では、サポートされているプラットフォームに[`rippled`がインストール](install-rippled.html)されていることを前提としています。
## ファイル記述子の制限
一部のLinuxバリアントでは、`rippled`を実行しようとすると以下のようなエラーメッセージが出力されることがあります。
```text
WARNING: There are only 1024 file descriptors (soft limit) available, which
limit the number of simultaneous connections.
```
これは、セキュリティの点からシステムで1つのプロセスが開くことができるファイルの数に制限があるが、その制限が`rippled`にとっては少なすぎる場合に発生します。この問題を修正するには、**ルートアクセス権限が必要です**。以下の手順に従い、`rippled`が開くことができるファイルの数を増やします。
1. 次の行を`/etc/security/limits.conf`ファイルの終わりに追加します。
* soft nofile 65536
* hard nofile 65536
2. [開くことができるファイルの数のハード制限](https://ss64.com/bash/ulimit.html)が現在`65536`であることを確認します。
ulimit -Hn
このコマンドの出力は`65536`になるはずです。
3. `rippled`をもう一度起動します。
systemctl start rippled
4. それでも`rippled`が起動しない場合は、`/etc/sysctl.conf`を開き、以下のカーネルレベル設定を付加します。
fs.file-max = 65536
## /etc/opt/ripple/rippled.cfgを開くことができない
`rippled`が起動時にクラッシュし、以下のようなエラーが出力される場合は、`rippled`が構成ファイルを読み取ることができません。
```text
Loading: "/etc/opt/ripple/rippled.cfg"
Failed to open '"/etc/opt/ripple/rippled.cfg"'.
Terminating thread rippled: main: unhandled St13runtime_error 'Can not create "/var/opt/ripple"'
Aborted (core dumped)
```
考えられる解決策:
- 構成ファイル（デフォルトのロケーションは`/etc/opt/ripple/rippled.cfg`）が存在しており、`rippled`プロセスを実行するユーザー（通常は`rippled`）にこのファイルの読み取り権限があることを確認します。
- `rippled`ユーザーが読み取ることができる構成ファイルを`$HOME/.config/ripple/rippled.cfg`に作成します（`$HOME`は`rippled`ユーザーのホームディレクトリを指しています）。
**ヒント:** `rippled`リポジトリには、RPMのインストール時にデフォルトの構成として提供される[`rippled.cfg`サンプルファイル](https://github.com/ripple/rippled/blob/master/cfg/rippled-example.cfg)が含まれています。このファイルがない場合は、上記のリンク先からコピーできます。
- `--conf`[コマンドラインオプション](commandline-usage.html)を使用して、使用する構成ファイルのパスを指定します。
## バリデータファイルを開くことができない
`rippled`が起動時にクラッシュし、以下のようなエラーが出力される場合は、`rippled`はプライマリ構成ファイルを読み取ることはできても、この構成ファイルに指定されている別のバリデータ構成ファイル（通常は`validators.txt`）を読み取ることができません。
```text
Loading: "/home/rippled/.config/ripple/rippled.cfg"
Terminating thread rippled: main: unhandled St13runtime_error 'The file specified in [validators_file] does not exist: /home/rippled/.config/ripple/validators.txt'
Aborted (core dumped)
```
考えられる解決策:
- `[validators.txt]`ファイルが存在し、`rippled`ユーザーにこのファイルの読み取り権限があることを確認します。
**ヒント:** `rippled`リポジトリには、RPMのインストール時にデフォルトの構成として提供される[`validators.txt`サンプルファイル](https://github.com/ripple/rippled/blob/master/cfg/validators-example.txt)が含まれています。このファイルがない場合は、上記のリンク先からコピーできます。
- `rippled.cfg`ファイルを編集し、`[validators_file]`設定を変更して、`validators.txt`ファイル（またはこれに相当するファイル）の正しいパスを指定します。ファイル名の前後に余分な空白があるかどうかを確認します。
- `rippled.cfg`ファイルを編集し、`[validators_file]`設定を削除します。バリデータ設定を`rippled.cfg`ファイルに直接追加します。例:
[validator_list_sites]
https://vl.ripple.com
[validator_list_keys]
ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
## データベースパスを作成できない
`rippled`が起動時にクラッシュし、以下のようなエラーが出力される場合は、その構成ファイルの`[database_path]`への書き込み権限がサーバーにありません。
```text
Loading: "/home/rippled/.config/ripple/rippled.cfg"
Terminating thread rippled: main: unhandled St13runtime_error 'Can not create "/var/lib/rippled/db"'
Aborted (core dumped)
```
構成ファイルのパス（`/home/rippled/.config/ripple/rippled.cfg`）とデータベースのパス（`/var/lib/rippled/db`）は、システムによっては異なる可能性があります。
考えられる解決策:
- エラーメッセージに出力されているデータベースパスへの書き込み権限を持つ別のユーザーとして`rippled`を実行します。
- `rippled.cfg`ファイルを編集し、`[database_path]`設定を変更して、`rippled`ユーザーに書き込み権限があるパスを使用します。
- `rippled`ユーザーに対し、設定されているデータベースパスへの書き込み権限を付与します。
## 状態DBエラー
`rippled`サーバーの状態データベースが破損している場合に、以下のエラーが発生する可能性があります。これは、予期しないシャットダウンが行われた場合、またはデータベースのタイプをRocksDBからNuDBに変更したが構成ファイルの`path`設定と`[database_path]`設定を変更しなかった場合に発生する可能性があります。
```text
2018-Aug-21 23:06:38.675117810 SHAMapStore:ERR state db error:
writableDbExists false archiveDbExists false
writableDb '/var/lib/rippled/db/rocksdb/rippledb.11a9' archiveDb '/var/lib/rippled/db/rocksdb/rippledb.2d73'
To resume operation, make backups of and remove the files matching /var/lib/rippled/db/state* and contents of the directory /var/lib/rippled/db/rocksdb
Terminating thread rippled: main: unhandled St13runtime_error 'state db error'
```
この問題を修正する最も簡単な方法は、データベース全体を削除することです。あるいは、データベースを任意の場所にバックアップすることもできます。例:
```sh
mv /var/lib/rippled/db /var/lib/rippled/db-bak
```
あるいは、データベースが必要ではないことが判明している場合は以下のようにします。
```sh
rm -r /var/lib/rippled/db
```
**ヒント:** 一般に`rippled`データベースは安全に削除できます。これは、個々のサーバーはXRP Ledgerネットワーク内の他のサーバーからレジャー履歴を再ダウンロードできるためです。
あるいは、構成ファイルでデータベースのパスを変更できます。例:
```
[node_db]
type=NuDB
path=/var/lib/rippled/custom_nudb_path
[database_path]
/var/lib/rippled/custom_sqlite_db_path
```
## オンライン削除の値がレジャー履歴の値よりも少ない
以下のようなエラーメッセージが出力される場合、`rippled.cfg`ファイルの`[ledger_history]`と`online_delete`に矛盾する値が指定されています。
```text
Terminating thread rippled: main: unhandled St13runtime_error 'online_delete must not be less than ledger_history (currently 3000)
```
`[ledger_history]`設定は、サーバーが埋め戻す履歴のレジャー数を表します。`online_delete`フィールド（`[node_db]`スタンザ）は、古い履歴を削除するときに維持する履歴のレジャー数を示します。サーバーがダウンロードしようとしている履歴レジャーを削除しないようにするため、`online_delete`の値は`[ledger_history]`以上でなければなりません。
この問題を修正するには、`rippled.cfg`ファイルを編集し、`[ledger_history]`オプションまたは`online_delete`オプションのいずれかを変更または削除します。（`[ledger_history]`を省略すると、デフォルトの256レジャーバージョンに設定されるので、`online_delete`を残して指定する場合は256よりも大きな値にする必要があります。`online_delete`を省略すると、古いレジャーバージョンの自動削除が無効になります。）
## node_sizeの値が正しくない
以下のようなエラーが出力される場合は、`rippled.cfg`ファイルの`node_size`設定の値が誤っています。
```text
Terminating thread rippled: main: unhandled N5beast14BadLexicalCastE 'std::bad_cast'
```
`node_size`フィールドの有効なパラメーターは`tiny`、`small`、`medium`、`large`、`huge`です。詳細は、[ノードサイズ](capacity-planning.html#ノードサイズ)を参照してください。
## シャードパスが欠落している
以下のようなエラーが出力される場合は、`rippled.cfg`の[履歴シャーディング](history-sharding.html)の設定が不完全です。
```text
Terminating thread rippled: main: unhandled St13runtime_error 'shard path missing'
```
設定に`[shard_db]`スタンザが含まれている場合、このスタンザには`path`フィールドが指定されている必要があります。このフィールドは、`rippled`がシャードストアーのデータを書き込むことができるディレクトリを指しています。このエラーが発生する場合は、`path`フィールドが欠落しているか、誤った位置に指定されています。構成ファイルで余分な空白やスペルミスがないかどうかを確認し、[シャード設定の例](configure-history-sharding.html#2-rippledcfgの編集)と比較してください。
## サポート対象外のシャードストアータイプ: RocksDB
RocksDBは、[履歴シャーディング](history-sharding.html)のバックエンドとしてサポートされなくなりました。RocksDBシャードストアーを定義している既存の構成がある場合は、サーバーが起動に失敗します。[新規: rippled 1.3.1][]
この場合、log startupコマンドの直後にプロセスが終了し、出力ログの早い段階で次のようなメッセージが表示されます。
```text
ShardStore:ERR Unsupported shard store type: RocksDB
```
この問題を修正するには、以下のいずれかを行ってからサーバーを再起動します。
- 代わりにNuDBを使用するようにシャードストアーを変更します。
- 履歴シャーディングを無効にします。
## 関連項目
- **コンセプト:**
- [`rippled`サーバー](xrpl-servers.html)
- [技術に関するよくある質問](technical-faq.html)
- **チュートリアル:**
- [ログメッセージについて](understanding-log-messages.html)
- [容量の計画](capacity-planning.html)
- **リファレンス:**
- [rippled APIリファレンス](http-websocket-apis.html)
- [`rippled`コマンドラインの使用](commandline-usage.html)
- [server_infoメソッド][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

223
content/infrastructure/rippled/troubleshooting/server-wont-start.md Normal file
View File

@@ -0,0 +1,223 @@
---
html: server-wont-start.html
parent: troubleshoot-the-rippled-server.html
blurb: A collection of problems that would cause a rippled server not to start, and how to fix them.
labels:
- Core Server
---
# rippled Server Won't Start
This page explains possible reasons [the `rippled` server](xrpl-servers.html) does not start and how to fix them.
These instructions assume you have [installed `rippled`](install-rippled.html) on a supported platform.
## File Descriptors Limit
On some Linux variants, you may get an error message such as the following when trying to run `rippled`:
```text
WARNING: There are only 1024 file descriptors (soft limit) available, which
limit the number of simultaneous connections.
```
This occurs because the system has a security limit on the number of files a single process may open, but the limit is set too low for `rippled`. To fix the problem, **root access is required**. Increase the number of files `rippled` is allowed to open with the following steps:
1. Add the following lines to the end of your `/etc/security/limits.conf` file:
* soft nofile 65536
* hard nofile 65536
2. Check that the [hard limit on number of files that can be opened](https://ss64.com/bash/ulimit.html) is now `65536`:
ulimit -Hn
The command should output `65536`.
3. Try starting `rippled` again.
systemctl start rippled
4. If `rippled` still does not start, open `/etc/sysctl.conf` and append the following kernel-level setting:
fs.file-max = 65536
## Failed to open /etc/opt/ripple/rippled.cfg
If `rippled` crashes on startup with an error such as the following, it means that `rippled` cannot read its config file:
```text
Loading: "/etc/opt/ripple/rippled.cfg"
Failed to open '"/etc/opt/ripple/rippled.cfg"'.
Terminating thread rippled: main: unhandled St13runtime_error 'Can not create "/var/opt/ripple"'
Aborted (core dumped)
```
Possible solutions:
- Check that the config file exists (the default location is `/etc/opt/ripple/rippled.cfg`) and the user that runs your `rippled` process (usually `rippled`) has read permissions to the file.
- Create a config file that can be read by the `rippled` user at `$HOME/.config/ripple/rippled.cfg` (where `$HOME` points to the `rippled` user's home directory).
**Tip:** The `rippled` repository contains [an example `rippled.cfg` file](https://github.com/ripple/rippled/blob/master/cfg/rippled-example.cfg) which is provided as the default config when you do an RPM installation. If you do not have the file, you can copy it from there.
- Specify the path to your preferred config file using the `--conf` [commandline option](commandline-usage.html).
## Failed to open validators file
If `rippled` crashes on startup with an error such as the following, it means it can read its primary config file, but that config file specifies a separate validators config file (typically named `validators.txt`), which `rippled` cannot read.
```text
Loading: "/home/rippled/.config/ripple/rippled.cfg"
Terminating thread rippled: main: unhandled St13runtime_error 'The file specified in [validators_file] does not exist: /home/rippled/.config/ripple/validators.txt'
Aborted (core dumped)
```
Possible solutions:
- Check that the `[validators.txt]` file exists and the `rippled` user has permissions to read it.
**Tip:** The `rippled` repository contains [an example `validators.txt` file](https://github.com/ripple/rippled/blob/master/cfg/validators-example.txt) which is provided as the default config when you do an RPM installation. If you do not have the file, you can copy it from there.
- Edit your `rippled.cfg` file and modify the `[validators_file]` setting to have the correct path to your `validators.txt` (or equivalent) file. Check for extra whitespace before or after the filename.
- Edit your `rippled.cfg` file and remove the `[validators_file]` setting. Add validator settings directly to your `rippled.cfg` file. For example:
[validator_list_sites]
https://vl.ripple.com
[validator_list_keys]
ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
## Cannot create database path
If `rippled` crashes on startup with an error such as the following, it means the server does not have write permissions to the `[database_path]` from its config file.
```text
Loading: "/home/rippled/.config/ripple/rippled.cfg"
Terminating thread rippled: main: unhandled St13runtime_error 'Can not create "/var/lib/rippled/db"'
Aborted (core dumped)
```
The paths to the configuration file (`/home/rippled/.config/ripple/rippled.cfg`) and the database path (`/var/lib/rippled/db`) may vary depending on your system.
Possible solutions:
- Run `rippled` as a different user that has write permissions to the database path printed in the error message.
- Edit your `rippled.cfg` file and change the `[database_path]` setting to use a path that the `rippled` user has write permissions to.
- Grant the `rippled` user write permissions to the configured database path.
## State DB Error
The following error can occur if the `rippled` server's state database is corrupted. This can occur as the result of being shutdown unexpectedly, or if you change the type of database from RocksDB to NuDB without changing the `path` and `[database_path]` settings in the config file.
```text
2018-Aug-21 23:06:38.675117810 SHAMapStore:ERR state db error:
writableDbExists false archiveDbExists false
writableDb '/var/lib/rippled/db/rocksdb/rippledb.11a9' archiveDb '/var/lib/rippled/db/rocksdb/rippledb.2d73'
To resume operation, make backups of and remove the files matching /var/lib/rippled/db/state* and contents of the directory /var/lib/rippled/db/rocksdb
Terminating thread rippled: main: unhandled St13runtime_error 'state db error'
```
The easiest way to fix this problem is to delete the databases entirely. You may want to back them up elsewhere instead. For example:
```sh
mv /var/lib/rippled/db /var/lib/rippled/db-bak
```
Or, if you are sure you don't need the databases:
```sh
rm -r /var/lib/rippled/db
```
**Tip:** It is generally safe to delete the `rippled` databases, because any individual server can re-download ledger history from other servers in the XRP Ledger network.
Alternatively, you can change the paths to the databases in the config file. For example:
```
[node_db]
type=NuDB
path=/var/lib/rippled/custom_nudb_path
[database_path]
/var/lib/rippled/custom_sqlite_db_path
```
## Online Delete is Less Than Ledger History
An error message such as the following indicates that the `rippled.cfg` file has contradictory values for `[ledger_history]` and `online_delete`.
```text
Terminating thread rippled: main: unhandled St13runtime_error 'online_delete must not be less than ledger_history (currently 3000)
```
The `[ledger_history]` setting represents how many ledgers of history the server should seek to back-fill. The `online_delete` field (in the `[node_db]` stanza) indicates how many ledgers of history to keep when dropping older history. The `online_delete` value must be equal to or larger than `[ledger_history]` to prevent the server from deleting historical ledgers that it is also trying to download.
To fix the problem, edit the `rippled.cfg` file and change or remove either the `[ledger_history]` or `online_delete` options. (If you omit `[ledger_history]`, it uses a default of 256 ledger versions. If you specify the `online_delete` field, it must be larger than 256. If you omit `online_delete`, it disables automatic deletion of old ledger versions.)
## Bad node_size value
An error such as the following indicates that the `rippled.cfg` file has an improper value for the `node_size` setting:
```text
Terminating thread rippled: main: unhandled N5beast14BadLexicalCastE 'std::bad_cast'
```
Valid parameters for the `node_size` field are `tiny`, `small`, `medium`, `large`, or `huge`. For more information see [Node Size](capacity-planning.html#node-size).
## Shard path missing
An error such as the following indicates that the `rippled.cfg` has an incomplete [history sharding](history-sharding.html) configuration:
```text
Terminating thread rippled: main: unhandled St13runtime_error 'shard path missing'
```
If your config includes a `[shard_db]` stanza, it must contain a `path` field, which points to a directory where `rippled` can write the data for the shard store. This error means the `path` field is missing or located in the wrong place. Check for extra whitespace or typos in your config file, and compare against the [Shard Configuration Example](configure-history-sharding.html#2-edit-rippledcfg).
## Unsupported shard store type: RocksDB
RocksDB is no longer supported as a backend for [history sharding](history-sharding.html). If you have an existing configuration that defines a RocksDB shard store, the server fails to start. [New in: rippled 1.3.1][]
In this case, the process dies shortly after the log startup command, with a message such as the following appearing earlier in the output log:
```text
ShardStore:ERR Unsupported shard store type: RocksDB
```
To fix this problem, do one of the following, then restart the server:
- Change your shard store to use NuDB instead.
- Disable history sharding.
## See Also
- **Concepts:**
- [The `rippled` Server](xrpl-servers.html)
- [Technical FAQ](technical-faq.html)
- **Tutorials:**
- [Understanding Log Messages](understanding-log-messages.html)
- [Capacity Planning](capacity-planning.html)
- **References:**
- [rippled API Reference](http-websocket-apis.html)
- [`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' %}
{% include '_snippets/rippled_versions.md' %}

234
content/infrastructure/rippled/troubleshooting/understanding-log-messages.ja.md Normal file
View File

@@ -0,0 +1,234 @@
---
html: understanding-log-messages.html
parent: troubleshoot-the-rippled-server.html
blurb: デバッグログの警告メッセージとエラーメッセージを解釈して対応します。
labels:
- コアサーバー
---
# ログメッセージについて
以下のセクションでは、[`rippled`サーバー](xrpl-servers.html)のデバッグログに出力される最も一般的なログメッセージタイプとその解釈を説明します。
これは、`rippled`の[問題を診断する](diagnosing-problems.html)上で重要なステップです。
## クラッシュ
ログに記録されたランタイムエラーのメッセージは、サーバーがクラッシュしたことを示している可能性があります。このようなメッセージは通常、以下の例に示すいずれかのメッセージで始まります。
```
Throw<std::runtime_error>
```
```
Terminating thread rippled: main: unhandled St13runtime_error
```
サーバーが起動時に常にクラッシュする場合は、[サーバーが起動しない](server-wont-start.html)で考えられる原因を参照してください。
サーバーが稼働中にランダムにクラッシュする場合、または特定のコマンドを実行するとクラッシュする場合は、`rippled`が最新バージョンに[更新](install-rippled.html)されていることを確認してください。最新バージョンに更新済で、サーバーがクラッシュする場合は、以下の点を確認してください。
- サーバーのメモリーが不足していませんか。一部のシステムでは、OOM（Out Of Memory）Killerやその他の監視プロセスによって`rippled`が終了されることがあります。
- サーバーが共有環境で稼働している場合、他のユーザーや管理者によってマシンまたはサービスが再起動されますか。たとえば、一部のホステッドプロバイダーは、長期にわたって共有マシンのリソースを大量に消費するサービスを自動的に終了します。
- サーバーは`rippled`を実行するための[最小要件](system-requirements.html)を満たしていますか。[本番環境サーバーに関する推奨事項](system-requirements.html#推奨される仕様)を適用していますか。
上記のいずれにも該当しない場合は、その問題をセキュリティ上重要なバグとしてRippleに報告してください。Rippleでクラッシュを再現できる場合は、報奨を受領できる可能性があります。詳細は<https://ripple.com/bug-bounty/>を参照してください。
## Already validated sequence at or past
以下のようなログメッセージが出力される場合は、サーバーが異なるレジャーインデックスの検証を順不同で受信しています。
```text
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
```
この種類のメッセージが時折発生しても通常は問題ありません。この種類のメッセージが同じ送信バリデータで頻繁に発生する場合は、以下のような問題がある可能性があります（可能性の高いものから順に示しています）。
- メッセージを書き込むサーバーにネットワークの問題がある。
- メッセージに表示されているバリデータにネットワークの問題がある。
- メッセージに表示されているバリデータが悪意のある振る舞いをしている。
## Connection reset by peer
以下のメッセージは、ピア`rippled`サーバーによって接続が閉じられたことを示します。
```text
2018-Aug-28 22:55:41.738765510 Peer:WRN [012] onReadMessage: Connection reset by peer
```
ピアツーピアネットワークで接続が時折失われることは、特に異常な動作ではありません。**この種類のメッセージが時折発生しても問題ではありません。**
このようなメッセージが同時に大量に出力される場合は、以下のような問題がある可能性があります。
- 1つ以上の特定のピアへのインターネット接続が切断されている。
- サーバーからの要求でピアに過剰な負担がかかり、ピアがサーバーをドロップした。
## InboundLedger 11 timeouts for ledger
```text
InboundLedger:WRN 11 timeouts for ledger 8265938
```
これは、サーバーがそのピアに対して特定のレジャーデータを要求する際に問題が発生していることを示しています。[レジャーインデックス](basic-data-types.html#レジャーインデックス)が、[server_infoメソッド][]により報告される最新の検証済みレジャーのインデックスよりもかなり小さい場合は、サーバーが[履歴シャード](history-sharding.html)のダウンロード中である可能性があります。
これは厳密には問題ではありませんが、レジャー履歴を迅速に取得したい場合は、`[ips_fixed]`構成スタンザを追加または編集してからサーバーを再起動することで、すべての履歴が記録されたピアに接続するように`rippled`を構成できます。たとえば、すべての履歴が記録されたRippleのサーバーに常に接続するには、以下のようにします。
```
[ips_fixed]
s2.ripple.com 51235
```
## InboundLedger Want hash
以下のようなログメッセージは、サーバーが他のサーバーにレジャーデータを要求していることを示しています。
```text
InboundLedger:WRN Want: 5AE53B5E39E6388DBACD0959E5F5A0FCAF0E0DCBA45D9AB15120E8CDD21E019B
```
これは、サーバーの同期中、埋め戻し中、[履歴シャード](history-sharding.html)のダウンロード中は正常です。
## LoadMonitor:WRN Job
以下のようなメッセージは、機能の実行に時間がかかっている場合（この例では11秒以上）に出力されます。
```text
2018-Aug-28 22:56:36.180827973 LoadMonitor:WRN Job: gotFetchPack run: 11566ms wait: 0ms
```
以下のようなメッセージは、ジョブの実行待機に時間がかかっている場合（この例でも11秒以上）に出力されます。
```text
2018-Aug-28 22:56:36.180970431 LoadMonitor:WRN Job: processLedgerData run: 0ms wait: 11566ms
2018-Aug-28 22:56:36.181053831 LoadMonitor:WRN Job: AcquisitionDone run: 0ms wait: 11566ms
2018-Aug-28 22:56:36.181110594 LoadMonitor:WRN Job: processLedgerData run: 0ms wait: 11566ms
2018-Aug-28 22:56:36.181169931 LoadMonitor:WRN Job: AcquisitionDone run: 0ms wait: 11566ms
```
ジョブの実行に時間がかかり、そのジョブの完了を他のジョブが待っている場合に、この2種類のメッセージが同時に出力されることがよくあります。
サーバー起動後の**最初の数分間**にこの種類のメッセージがいくつか発生することは**特に異常な動作ではありません**。
サーバーの起動後5分以上にわたってこれらのメッセージが継続する場合、特に`run`時間が1000msを大きく上回る場合は、**サーバーに十分なリソース（ディスクI/O、RAM、CPUなど）がない**可能性があります。この原因として、使用しているハードウェアの性能が不十分であること、または同じハードウェアで実行されている他のプロセスがリソースをめぐって`rippled`と競合していることが考えられます。（`rippled`とリソースをめぐって競合する可能性のある他のプロセスの例としては、スケジュール済みバックアップ、ウィルススキャナー、定期的なデータベースクリーナーなどがあります。）
考えられるもう1つの原因として、回転型ハードディスクでNuDBの使用を試みていることが挙げられます。NuDBはソリッドステートドライブ（SSD）でのみ使用してください。`rippled`のデータベースには常にSSDストレージの使用が推奨されますが、RocksDBを使用する回転型ディスクで`rippled`を正常に稼働できる _可能性があります_ 。回転型ディスクを使用している場合は、`[node_db]`と`[shard_db]`（使用している場合）の両方がRocksDBを使用するように設定されていることを確認してください。例:
```
[node_db]
type=RocksDB
# ... more config omitted
[shard_db]
type=RocksDB
```
## No hash for fetch pack
以下のようなメッセージは、[履歴シャーディング](history-sharding.html)のために履歴レジャーをダウンロードする際に、`rippled` v1.1.0以前のバグが原因で発生します。
```text
2018-Aug-28 22:56:21.397076850 LedgerMaster:ERR No hash for fetch pack. Missing Index 7159808
```
これらは安全に無視できます。
## Potential Censorship
XRP Ledgerが取引検閲の可能性を検出すると、以下のようなログメッセージが出力されます。ログメッセージと取引検閲検出機能の詳細は、[取引検閲の検知](transaction-censorship-detection.html)を参照してください。
**警告メッセージ**
```text
LedgerConsensus:WRN Potential Censorship: Eligible tx E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7, which we are tracking since ledger 18851530 has not been included as of ledger 18851545.
```
**エラーメッセージ**
```text
LedgerConsensus:ERR Potential Censorship: Eligible tx E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7, which we are tracking since ledger 18851530 has not been included as of ledger 18851605. Additional warnings suppressed.
```
## シャード: No such file or directory
`rippled` 1.3.1のバグが原因で、[履歴シャーディング](history-sharding.html)を有効にしたときに次のようなログメッセージが書き込まれることがあります。
```text
ShardStore:ERR shard 1804: No such file or directory
ShardStore:ERR shard 354: No such file or directory
ShardStore:ERR shard 408: No such file or directory
ShardStore:ERR shard 2927: No such file or directory
ShardStore:ERR shard 2731: No such file or directory
ShardStore:ERR shard 2236: No such file or directory
```
これは、サーバーが新しい履歴シャードの取得を開始しようとしたものの、シャードを格納するための新しいディレクトリーを作成できなかったことを示します。このバグにより、rippled 1.3.1は新しいシャードを取得できません。[修正は近日リリース予定](https://github.com/ripple/rippled/pull/3014)です。
このエラーは、上記のバグのほかに、`rippled`が**起動後**に基となるファイルシステムに書き込めなくなった場合にも起こります。考えられる原因は次のとおりです。
- ストレージメディアのハードウェア障害
- ファイルシステムがアンマウントされた
- シャードフォルダーが削除された
**ヒント:** 一般的に、サービスが停止している場合は、`rippled`のデータベースファイルを削除しても安全ですが、サーバーの稼働中には決してデータベースファイルを削除しないでください。
## Unable to determine hash of ancestor
以下のようなログメッセージは、サーバーがピアからの検証メッセージを認識するけれども、サーバーが基盤としている親レジャーバージョンを認識しない場合に発生します。これは、サーバーがネットワークの他の部分と同期していない場合に発生することがあります。
```text
2018-Aug-28 22:56:22.256065549 Validations:WRN Unable to determine hash of ancestor seq=3 from ledger hash=00B1E512EF558F2FD9A0A6C263B3D922297F26A55AEB56A009341A22895B516E seq=12133675
```
{% include '_snippets/unsynced_warning_logs.ja.md' %}
<!--_ -->
## View of consensus changed during open
以下のようなログメッセージが出力される場合は、サーバーがネットワークの他の部分と同期していません。
```text
2018-Aug-28 22:56:22.368460130 LedgerConsensus:WRN View of consensus changed during open status=open, mode=proposing
2018-Aug-28 22:56:22.368468202 LedgerConsensus:WRN 96A8DF9ECF5E9D087BAE9DDDE38C197D3C1C6FB842C7BB770F8929E56CC71661 to 00B1E512EF558F2FD9A0A6C263B3D922297F26A55AEB56A009341A22895B516E
2018-Aug-28 22:56:22.368499966 LedgerConsensus:WRN {"accepted":true,"account_hash":"89A821400087101F1BF2D2B912C6A9F2788CC715590E8FA5710F2D10BF5E3C03","close_flags":0,"close_time":588812130,"close_time_human":"2018-Aug-28 22:55:30.000000000","close_time_resolution":30,"closed":true,"hash":"96A8DF9ECF5E9D087BAE9DDDE38C197D3C1C6FB842C7BB770F8929E56CC71661","ledger_hash":"96A8DF9ECF5E9D087BAE9DDDE38C197D3C1C6FB842C7BB770F8929E56CC71661","ledger_index":"3","parent_close_time":588812070,"parent_hash":"5F5CB224644F080BC8E1CC10E126D62E9D7F9BE1C64AD0565881E99E3F64688A","seqNum":"3","totalCoins":"100000000000000000","total_coins":"100000000000000000","transaction_hash":"0000000000000000000000000000000000000000000000000000000000000000"}
```
{% include '_snippets/unsynced_warning_logs.ja.md' %}
<!--_ -->
## We are not running on the consensus ledger
```text
NetworkOPs:WRN We are not running on the consensus ledger
```
{% include '_snippets/unsynced_warning_logs.ja.md' %}
<!--_ -->
## 関連項目
- **コンセプト:**
- [`rippled`サーバー](xrpl-servers.html)
- [技術に関するよくある質問](technical-faq.html)
- **チュートリアル:**
- [問題の診断](diagnosing-problems.html)
- [容量の計画](capacity-planning.html)
- **リファレンス:**
- [rippled APIリファレンス](http-websocket-apis.html)
- [`rippled`コマンドラインの使用](commandline-usage.html)
- [server_infoメソッド][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

349
content/infrastructure/rippled/troubleshooting/understanding-log-messages.md Normal file
View File

@@ -0,0 +1,349 @@
---
html: understanding-log-messages.html
parent: troubleshoot-the-rippled-server.html
blurb: Interpret and respond to warning and error messages in the debug log.
labels:
- Core Server
---
# Understanding Log Messages
The following sections describe some of the most common types of log messages that can appear in a [`rippled` server's](xrpl-servers.html) debug log and how to interpret them.
This is an important step in [Diagnosing Problems](diagnosing-problems.html) with `rippled`.
## Log Message Structure
The following shows the format of the log file:
```text
2020-Jul-08 20:10:17.372178946 UTC Peer:WRN [236] onReadMessage from n9J2CP7hZypxDJ27ZSxoy4VjbaSgsCNaRRJtJkNJM5KMdGaLdRy7 at 197.27.127.136:53046: stream truncated
2020-Jul-08 20:11:13.582438263 UTC PeerFinder:ERR Logic testing 52.196.126.86:13308 with error, Connection timed out
2020-Jul-08 20:11:57.728448343 UTC Peer:WRN [242] onReadMessage from n9J2CP7hZypxDJ27ZSxoy4VjbaSgsCNaRRJtJkNJM5KMdGaLdRy7 at 197.27.127.136:53366: stream truncated
2020-Jul-08 20:12:12.075081020 UTC LoadMonitor:WRN Job: sweep run: 1172ms wait: 0ms
```
Each line represents one log entry, with the following parts in order, separated by spaces:
1. The date the log entry was written, such as `2020-Jul-08`.
2. The time the log entry was written, such as `20:12:12.075081020`.
3. The time zone indicator `UTC`. (Log dates are always in UTC.) [New in: rippled 1.5.0][]
4. The log partition and severity, such as `LoadMonitor:WRN`.
5. The log message, such as `Job: sweep run: 1172ms wait: 0ms`.
For simplicity, the examples in this page omit the date, time, and time zone indicator.
## Crashes
Messages in the log that mention runtime errors can indicate that the server crashed. These messages usually start with a message such as one of the following examples:
```
Throw<std::runtime_error>
```
```
Terminating thread rippled: main: unhandled St13runtime_error
```
If your server always crashes on startup, see [Server Won't Start](server-wont-start.html) for possible cases.
If your server crashes randomly during operation or as a result of particular commands, make sure you are [updated](install-rippled.html) to the latest `rippled` version. If you are on the latest version and your server is still crashing, check the following:
- Is your server running out of memory? On some systems, `rippled` may be terminated by the Out Of Memory (OOM) Killer or another monitor process.
- If your server is running in a shared environment, are other users or administrators causing the machine or service to be restarted? For example, some hosted providers automatically kill any service that uses a large amount of a shared machine's resources for an extended period of time.
- Does your server meet the [minimum requirements](system-requirements.html) to run `rippled`? What about the [recommendations for production servers](system-requirements.html#recommended-specifications)?
If none of the above apply, please report the issue to Ripple as a security-sensitive bug. If Ripple can reproduce the crash, you may be eligible for a bounty. See <https://ripple.com/bug-bounty/> for details.
## Already validated sequence at or past
Log messages such as the following indicate that a server received validations for different ledger indexes out of order.
```text
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 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.
- The validator described in the message is behaving maliciously.
## async_send failed
The following log message indicates that [StatsD export](configure-statsd.html) failed:
```text
Collector:ERR async_send failed: Connection refused
```
This could mean:
- Your StatsD configuration has the wrong IP address or port.
- The StatsD server you were attempting to export to was down or not accessible from your `rippled` server.
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 work as normal except for the sending of StatsD metrics.
## Check for upgrade
The following message indicates that the server has detected that it is running an older software version than at least 60% of its trusted validators:
```text
LedgerMaster:ERR Check for upgrade: A majority of trusted validators are running a newer version.
```
This is not strictly a problem, but an old server version is likely to become [amendment blocked](amendments.html#amendment-blocked-servers). You should [update `rippled`](install-rippled.html) to the latest stable version. (If you are connected to [devnet](parallel-networks.html), update to the latest nightly version instead.)
## Connection reset by peer
The following log message indicates that a peer `rippled` server closed a connection:
```text
Peer:WRN [012] onReadMessage: Connection reset by peer
```
Losing connections from time to time is normal for any peer-to-peer network. **Occasional messages of this kind do not indicate a problem.**
A large number of these messages around the same time may indicate a problem, such as:
- Your internet connection to one or more specific peers was cut off.
- Your server may have been overloading the peer with requests, causing the peer to disconnect your server.
## Consumer entry dropped with balance at or above drop threshold
The following log message indicates that a client to the server's public API has been dropped as a result of [rate limiting](rate-limiting.html):
```text
Resource:WRN Consumer entry 169.55.164.21 dropped with balance 15970 at or above drop threshold 15000
```
The entry contains the IP address of the client that exceeded its rate limit, and the client's "balance", which is a score estimating the rate at which the client has been using the API. The threshold for dropping a client is [hardcoded to a score of 15000](https://github.com/ripple/rippled/blob/06c371544acc3b488b9d9c057cee4e51f6bef7a2/src/ripple/resource/impl/Tuning.h#L34-L35).
If you see frequent messages from the same IP address, you may want to block those IP addresses from your network to reduce the load on your server's public API. (For example, you may be able to configure your firewall to block those IP addresses.)
To avoid being dropped by rate limiting on your own server, [connect as an admin](get-started-using-http-websocket-apis.html#admin-access).
## InboundLedger 11 timeouts for ledger
```text
InboundLedger:WRN 11 timeouts for ledger 8265938
```
This indicates that your server is having trouble requesting specific ledger data from its peers. If the [ledger index](basic-data-types.html#ledger-index) is much lower than the most recent validated ledger's index as reported by the [server_info method][], this probably indicates that your server is downloading a [history shard](history-sharding.html).
This is not strictly a problem, but if you want to acquire ledger history faster, you can configure `rippled` to connect to peers with full history by adding or editing the `[ips_fixed]` config stanza and restarting the server. For example, to always try to connect to one of Ripple's full-history servers:
```
[ips_fixed]
s2.ripple.com 51235
```
## InboundLedger Want hash
Log messages such as the following indicate that the server is requesting ledger data from other servers:
```text
InboundLedger:WRN Want: 5AE53B5E39E6388DBACD0959E5F5A0FCAF0E0DCBA45D9AB15120E8CDD21E019B
```
This is normal if your server is syncing, backfilling, or downloading [history shards](history-sharding.html).
## LoadMonitor Job
Messages such as the following occur when a function takes a long time to run (over 11 seconds in this example):
```text
2018-Aug-28 22:56:36.180827973 LoadMonitor:WRN Job: gotFetchPack run: 11566ms wait: 0ms
```
The following similar message occurs when a job spends a long time waiting to run (again, over 11 seconds in this example):
```text
LoadMonitor:WRN Job: processLedgerData run: 0ms wait: 11566ms
LoadMonitor:WRN Job: AcquisitionDone run: 0ms wait: 11566ms
LoadMonitor:WRN Job: processLedgerData run: 0ms wait: 11566ms
LoadMonitor:WRN Job: AcquisitionDone run: 0ms wait: 11566ms
```
These two types of messages often occur together, when a long-running job causes other jobs to wait a long time for it to finish.
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 1000 ms, that may indicate that **your server does not have enough disk I/O, RAM, or CPU**. This may be caused by not having powerful enough 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:
```
[node_db]
type=RocksDB
# ... more config omitted
[shard_db]
type=RocksDB
```
## No hash for fetch pack
Messages such as the following are caused by a bug in `rippled` v1.1.0 and earlier when downloading historical ledgers for [history sharding](history-sharding.html):
```text
2018-Aug-28 22:56:21.397076850 LedgerMaster:ERR No hash for fetch pack. Missing Index 7159808
```
These can be safely ignored.
## Not deleting
Messages such as the following occur when [online deletion is interrupted](online-deletion.html#interrupting-online-deletion):
```text
SHAMapStore:WRN Not deleting. state: syncing. age 25s
```
The `state` indicates the [server state](rippled-server-states.html). The `age` indicates how many seconds since the last validated ledger was closed. (A healthy age for the last validated ledger is 7 seconds or less.)
During startup, these messages are normal and can be safely ignored. At other times, messages like this usually indicate that the server does not meet the [system requirements](system-requirements.html), especially disk I/O, to run online deletion at the same time as everything else the server is doing.
## Potential Censorship
Log messages such as the following are issued when the XRP Ledger detects potential transaction censorship. For more information about these log messages and the transaction censorship detector, see [Transaction Censorship Detection](transaction-censorship-detection.html).
**Warning Message**
```text
LedgerConsensus:WRN Potential Censorship: Eligible tx E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7, which we are tracking since ledger 18851530 has not been included as of ledger 18851545.
```
**Error Message**
```text
LedgerConsensus:ERR Potential Censorship: Eligible tx E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7, which we are tracking since ledger 18851530 has not been included as of ledger 18851605. Additional warnings suppressed.
```
## rotating validatedSeq
This message indicates that [online deletion](online-deletion.html) has started running:
```text
SHAMapStore:WRN rotating validatedSeq 54635511 lastRotated 54635255 deleteInterval 256 canDelete_ 4294967295
```
This log message is normal and indicates that online deletion is operating as expected.
The log message contains values describing the current online deletion run. Each keyword corresponds to the value immediately following it:
| Keyword | Value | Description |
|:-----------------|:-----------------|:---------------------------------------|
| `validatedSeq` | [Ledger Index][] | The current validated ledger version. |
| `lastRotated` | [Ledger Index][] | The end of the ledger range in the ["old" (read-only) database](online-deletion.html#how-it-works). Online deletion deletes this ledger version and earlier. |
| `deleteInterval` | Number | How many ledger versions to keep after online deletion. The [`online_delete` setting](online-deletion.html#configuration) controls this value. |
| `canDelete_` | [Ledger Index][] | The newest ledger version that the server is allowed to delete, if using [advisory deletion](online-deletion.html#advisory-deletion). If not using advisory deletion, this value is ignored. |
When online deletion finishes, it writes the following log message:
```text
SHAMapStore:WRN finished rotation 54635511
```
The number at the end of the message is the [ledger index][] of the validated ledger at the time online deletion started, matching the `validatedSeq` value of the "rotating" message. This becomes the `lastRotated` value the next time online deletion runs.
If the server falls out of sync while running online deletion, it interrupts online deletion and writes a ["Not deleting" log message](#not-deleting) instead of a "finished rotation" message.
## Shard: No such file or directory
Log messages such as the following can occur when you have [history sharding](history-sharding.html) enabled:
```text
ShardStore:ERR shard 1804: No such file or directory
```
This indicates that the server tried to start acquiring a new history shard, but it cannot write to the underlying file system. Possible causes include:
- Hardware failure of storage media
- The file system became unmounted
- The shard folder was deleted
**Tip:** It is generally safe to delete `rippled`'s database files when the service is stopped, but you should never delete them while the server is running.
## Unable to determine hash of ancestor
Log messages such as the following occur when the server sees a validation message from a peer and it does not know the parent ledger version that server is building on. This can occur when the server is not in sync with the rest of the network:
```text
Validations:WRN Unable to determine hash of ancestor seq=3 from ledger hash=00B1E512EF558F2FD9A0A6C263B3D922297F26A55AEB56A009341A22895B516E seq=12133675
```
{% include '_snippets/unsynced_warning_logs.md' %}
<!--_ -->
## [veto_amendments] section in config file ignored
<!-- SPELLING_IGNORE: veto_amendments -->
Log messages such as the following occur when your `rippled.cfg` file contains a legacy `[veto_amendments]` stanza. The first time the server starts on version 1.7.0 or higher, it reads the stanza to set amendment votes; on later restarts, it ignores the `[amendments]` and `[veto_amendments]` stanzas and prints this message instead.
```text
Amendments:WRN [veto_amendments] section in config file ignored in favor of data in db/wallet.db.
```
To resolve this error, remove the `[amendments]` and `[veto_amendments]` stanzas from your config file. For more information, see [Amendment Voting](amendments.html#amendment-voting).
## View of consensus changed during open
Log messages such as the following occur when a server is not in sync with the rest of the network:
```text
LedgerConsensus:WRN View of consensus changed during open status=open, mode=proposing
LedgerConsensus:WRN 96A8DF9ECF5E9D087BAE9DDDE38C197D3C1C6FB842C7BB770F8929E56CC71661 to 00B1E512EF558F2FD9A0A6C263B3D922297F26A55AEB56A009341A22895B516E
LedgerConsensus:WRN {"accepted":true,"account_hash":"89A821400087101F1BF2D2B912C6A9F2788CC715590E8FA5710F2D10BF5E3C03","close_flags":0,"close_time":588812130,"close_time_human":"2018-Aug-28 22:55:30.000000000","close_time_resolution":30,"closed":true,"hash":"96A8DF9ECF5E9D087BAE9DDDE38C197D3C1C6FB842C7BB770F8929E56CC71661","ledger_hash":"96A8DF9ECF5E9D087BAE9DDDE38C197D3C1C6FB842C7BB770F8929E56CC71661","ledger_index":"3","parent_close_time":588812070,"parent_hash":"5F5CB224644F080BC8E1CC10E126D62E9D7F9BE1C64AD0565881E99E3F64688A","seqNum":"3","totalCoins":"100000000000000000","total_coins":"100000000000000000","transaction_hash":"0000000000000000000000000000000000000000000000000000000000000000"}
```
{% include '_snippets/unsynced_warning_logs.md' %}
<!--_ -->
## We are not running on the consensus ledger
```text
NetworkOPs:WRN We are not running on the consensus ledger
```
{% include '_snippets/unsynced_warning_logs.md' %}
<!--_ -->
## See Also
- **Concepts:**
- [The `rippled` Server](xrpl-servers.html)
- [Technical FAQ](technical-faq.html)
- **Tutorials:**
- [Diagnosing Problems](diagnosing-problems.html)
- [Capacity Planning](capacity-planning.html)
- **References:**
- [rippled API Reference](http-websocket-apis.html)
- [`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' %}
{% include '_snippets/rippled_versions.md' %}