ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-28 23:55:49 +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

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' %}