mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-19 19:25:51 +00:00
Merge pull request #2292 from tequdev/ja-infrastructure
[JA] translate infrastructure pages
This commit is contained in:
Rome Reginelli
@@ -0,0 +1,56 @@
|
||||
---
|
||||
html: configure-grpc.html
|
||||
parent: configure-rippled.html
|
||||
blurb: gRPC APIを有効にして設定します。
|
||||
labels:
|
||||
- コアサーバ
|
||||
---
|
||||
# gRPCの設定
|
||||
|
||||
`rippled`サーバは[P2Pモードサーバ](rippled-server-modes.html)が提供できる限定的な[gRPC API](https://grpc.io/)を持っています。レポートモードのサーバはこのAPIを使って、最新の有効なレジャーやトランザクションに関するデータを取得します。新しい設定を使って、サーバ上でgRPC APIを有効にすることができます。
|
||||
|
||||
**注意:** gRPCのサポートは、特にP2Pモードサーバからレポートモードサーバにデータを提供することを目的としています。gRPC APIは予告なく変更される可能性がありますし、将来のバージョンで完全に削除される可能性もあります。
|
||||
|
||||
## 前提条件
|
||||
|
||||
gRPCを有効にするには、次の前提条件を満たす必要があります。
|
||||
|
||||
- [rippledのインストール](install-rippled.html)が必要です。.
|
||||
|
||||
- サーバは選択したポートに接続できる必要があります。
|
||||
|
||||
## 手順
|
||||
|
||||
サーバでgRPCを有効にするには、以下の手順を実行します。
|
||||
|
||||
1. `[port_grpc]`が`rippled`設定ファイルにあることを確認してください。
|
||||
|
||||
[port_grpc]
|
||||
port = 50051
|
||||
ip = 127.0.0.1
|
||||
|
||||
- `port`はサーバがクライアントアプリケーションからのgRPC接続を待ち受けるポートを定義します。推奨されるポートは`50051`です。
|
||||
- ip`はサーバが待ち受けるインタフェースを定義します。127.0.0.1`はローカルループバックネットワーク(同じマシン)への接続を制限し、デフォルトで有効になっています。この値を`0.0.0.0`に変更すると、利用可能なすべてのネットワークインターフェイスを待ち受けます。
|
||||
|
||||
{% include '_snippets/conf-file-location.ja.md' %}
|
||||
|
||||
2. `rippled`サービスを開始（または再起動）します。
|
||||
|
||||
sudo systemctl restart rippled
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [XRP Ledgerの概要](xrp-ledger-overview.html)
|
||||
- [`rippled`サーバのモード](rippled-server-modes.html)
|
||||
- **チュートリアル:**
|
||||
- [HTTP / WebSocketAPIを使ってみる](get-started-using-http-websocket-apis.html)
|
||||
- [信頼できるトランザクションの送信](reliable-transaction-submission.html)
|
||||
- [rippledサーバの管理](manage-the-rippled-server.html)
|
||||
- **リファレンス:**
|
||||
- [HTTP / WebSocket APIリファレンス](http-websocket-apis.html)
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,66 @@
|
||||
---
|
||||
html: configure-statsd.html
|
||||
parent: configure-rippled.html
|
||||
blurb: StatsDの統計データでrippledサーバを監視します。
|
||||
labels:
|
||||
- コアサーバ
|
||||
---
|
||||
# StatsDの設定
|
||||
|
||||
`rippled`は自分自身に関するヘルスや動作情報を[StatsD](https://github.com/statsd/statsd)フォーマットでエクスポートできます。これらの情報は、[`rippledmon`](https://github.com/ripple/rippledmon)やStatsDフォーマットの統計情報を受け付ける他のコレクターを通して取得し、可視化することができます。
|
||||
|
||||
## 設定の手順
|
||||
|
||||
`rippled`サーバでStatsDを有効にするには、以下の手順を実行します。
|
||||
|
||||
1. 別のマシンで`rippledmon`インスタンスをセットアップし、統計情報を受信して集計します。
|
||||
|
||||
$ git clone https://github.com/ripple/rippledmon.git
|
||||
$ cd rippledmon
|
||||
$ docker-compose up
|
||||
|
||||
上記の手順を実行する際には、[Docker](https://docs.docker.com/)と[DockerCompose](https://docs.docker.com/compose/install/)がマシンにインストールされていることを確認してください。`rippledmon`の設定については、[`rippledmon`リポジトリ](https://github.com/ripple/rippledmon)をご覧ください。
|
||||
|
||||
0. `[insight]`を`rippled`の設定ファイルに追加します。
|
||||
|
||||
[insight]
|
||||
server=statsd
|
||||
address=192.0.2.0:8125
|
||||
prefix=my_rippled
|
||||
|
||||
- `address`には`rippledmon`が接続しているIPアドレスとポートを指定します。デフォルトでは、このポートは8125です。
|
||||
- `prefix`には設定する`rippled`サーバを識別する名前を指定します。prefixには、空白、コロン":"、または縦棒"|"を含めてはいけません。このprefix(接頭辞)は、このサーバからエクスポートされるすべてのStatsDの統計情報に表示されます。
|
||||
|
||||
{% include '_snippets/conf-file-location.ja.md' %}<!--_ -->
|
||||
|
||||
1. `rippled`サービスを再起動します。
|
||||
|
||||
$ sudo systemctl restart rippled
|
||||
|
||||
2. 統計情報がエクスポートされていることを確認します。
|
||||
|
||||
$ tcpdump -i en0 | grep UDP
|
||||
|
||||
`en0`をあなたのマシンの適切なネットワークインターフェースに置き換えてください。あなたのマシンのインターフェースの完全なリストを取得するには`$ tcpdump -D`を使ってください。
|
||||
|
||||
出力の例:
|
||||
|
||||
00:41:53.066333 IP 192.0.2.2.63409 > 192.0.2.0.8125: UDP, length 196
|
||||
|
||||
`rippledmon`インスタンスの設定されたアドレスとポートへの送信トラフィックを示すメッセージが定期的に表示されるはずです。
|
||||
|
||||
StatsDの各データの説明については、[`rippledmon`リポジトリ](https://github.com/ripple/rippledmon)をご覧ください。
|
||||
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [XRP Ledgerの概要](xrp-ledger-overview.html)
|
||||
- [`rippled`サーバ](xrpl-servers.html)
|
||||
- **チュートリアル:**
|
||||
- [`rippled`のインストール](install-rippled.html)
|
||||
- [容量の計画](capacity-planning.html)
|
||||
- **リアファレンス:**
|
||||
- [server_infoメソッド](server_info.html)
|
||||
- [printメソッド](print.html)
|
||||
@@ -48,7 +48,7 @@ labels:
|
||||
- 指示された場合にのみオンライン削除を実行するには、`advisory_delete`を`1`に設定します。（`0`に設定すると、新しいレジャーバージョンが使用可能になると自動的にオンライン削除が実行されます。）
|
||||
- `online_delete`を、オンライン削除の実行後に維持するレジャーバージョンの最小数に設定します。オンライン削除が実行されるまでに蓄積される履歴は、この値よりも多くなります。
|
||||
|
||||
{% include '_snippets/conf-file-location.md' %}<!--_ -->
|
||||
{% include '_snippets/conf-file-location.ja.md' %}<!--_ -->
|
||||
|
||||
2. サーバーに対してオンライン削除を指示する[can_deleteメソッド][]の実行をテストします。
|
||||
|
||||
|
||||
@@ -40,7 +40,7 @@ labels:
|
||||
|
||||
**注意:** RocksDBで履歴をすでにダウンロードしている場合は、NuDBへ切り替えるときに構成ファイルでデータベースのパスを変更するか、またはそのデータを削除する必要があります。`[node_db]`スタンザの`path`設定**および**`[database_path]`（SQLiteデータベース）設定の両方を変更する必要があります。このようにしないと、サーバーの[起動が失敗する](server-wont-start.html#状態dbエラー)可能性があります。
|
||||
|
||||
{% include '_snippets/conf-file-location.md' %}<!--_ -->
|
||||
{% include '_snippets/conf-file-location.ja.md' %}<!--_ -->
|
||||
|
||||
0. サーバーの構成ファイルで`[ledger_history]`スタンザを`full`に設定します。
|
||||
|
||||
|
||||
@@ -30,7 +30,7 @@ labels:
|
||||
|
||||
`rippled.cfg`ファイルを編集し、`[shard_db]`スタンザを追加します。
|
||||
|
||||
{% include '_snippets/conf-file-location.md' %}<!--_ -->
|
||||
{% include '_snippets/conf-file-location.ja.md' %}<!--_ -->
|
||||
|
||||
以下のスニペットに、`[shard_db]`スタンザの例を示します。
|
||||
|
||||
|
||||
@@ -42,7 +42,7 @@ labels:
|
||||
|
||||
`online_delete`を、オンライン削除の実行後に維持するレジャーバージョンの最小数に設定します。自動削除が設定されている場合（デフォルト）、サーバーは通常、この数の約2倍のレジャーバージョンが蓄積されると削除を実行します。
|
||||
|
||||
{% include '_snippets/conf-file-location.md' %}<!--_ -->
|
||||
{% include '_snippets/conf-file-location.ja.md' %}<!--_ -->
|
||||
|
||||
0. `rippled`サービスを起動（または再起動）します。
|
||||
|
||||
|
||||
@@ -14,7 +14,7 @@ labels:
|
||||
|
||||
- [sign][signメソッド]
|
||||
- [sign_for][sign_forメソッド]
|
||||
- [submit][submitメソッド](in "sign-and-submit" mode)
|
||||
- [submit][submitメソッド]("sign-and-submit"モード)
|
||||
|
||||
これらのメソッドを使用するにあたり、管理者接続からパブリック署名を有効にする必要は**ありません**。
|
||||
|
||||
@@ -26,7 +26,7 @@ labels:
|
||||
|
||||
vim /etc/opt/ripple/rippled.cfg
|
||||
|
||||
{% include '_snippets/conf-file-location.md' %}<!--_ -->
|
||||
{% include '_snippets/conf-file-location.ja.md' %}<!--_ -->
|
||||
|
||||
2. 以下のスタンザを構成ファイルに追加し、変更を保存します。
|
||||
|
||||
|
||||
@@ -27,7 +27,7 @@ labels:
|
||||
|
||||
vim /etc/opt/ripple/rippled.cfg
|
||||
|
||||
{% include '_snippets/conf-file-location.md' %}<!--_ -->
|
||||
{% include '_snippets/conf-file-location.ja.md' %}<!--_ -->
|
||||
|
||||
2. プライベートピアリングを有効にします。
|
||||
|
||||
|
||||
@@ -0,0 +1,79 @@
|
||||
---
|
||||
html: configure-the-peer-crawler.html
|
||||
parent: configure-peering.html
|
||||
blurb: rippledサーバーがステータスとピアについてどの程度の情報を公表するか設定します。
|
||||
labels:
|
||||
- Core Server
|
||||
- Security
|
||||
---
|
||||
# ピアクローラの設定
|
||||
|
||||
デフォルトでは、[`rippled`サーバ](xrpl-servers.html)は、[ピアクローラAPI](peer-crawler.html)を使って要求してきた人に統計を公開し、[XRP Ledgerのピアツーピアネットワーク](peer-protocol.html)の健全性と状況を追跡しやすくしています。より多くの情報を提供したり、より少ない情報を提供したり、あるいはピアクローラーのリクエストを完全に拒否するように、サーバを設定することができます。
|
||||
|
||||
このドキュメントには、2つのオプションについて説明しています。
|
||||
|
||||
- [ピアクローラが報告する情報の変更](#ピアクローラが報告する情報の変更)
|
||||
- [ピアクローラの無効化](#ピアクローラの無効化)
|
||||
|
||||
## ピアクローラが報告する情報の変更
|
||||
|
||||
ピアクローラからの要求に対してサーバが提供する情報量を設定するには、以下の手順を実行します。
|
||||
|
||||
1. `rippled`の設定ファイルを編集します。
|
||||
|
||||
vim /etc/opt/ripple/rippled.cfg
|
||||
|
||||
{% include '_snippets/conf-file-location.ja.md' %}<!--_ -->
|
||||
|
||||
2. 設定ファイルに`[crawl]`を追加または更新し、変更を保存します。
|
||||
|
||||
[crawl]
|
||||
overlay = 1
|
||||
server = 1
|
||||
counts = 0
|
||||
unl = 1
|
||||
|
||||
このスタンザのフィールドは、サーバが[peer crawlerレスポンス](peer-crawler.html#レスポンスのフォーマット)で返すフィールドを制御します。設定フィールドの名前はAPIレスポンスのフィールドと一致します。値が`1`の設定は、レスポンスにそのフィールドを含めることを意味します。0`の値は、そのフィールドをレスポンスから省略することを意味します。この例では、各設定のデフォルト値を示しています。
|
||||
|
||||
3. 設定ファイルに変更を保存したら、`rippled`サーバを再起動して、更新された設定を適用します。
|
||||
|
||||
systemctl restart rippled
|
||||
|
||||
|
||||
## ピアクローラの無効化
|
||||
|
||||
サーバのピアクローラAPIを無効にして、ピアクローラーリクエストにまったく応答しないようにするには、以下の手順を実行します。
|
||||
|
||||
1. `rippled`の設定ファイルを編集します。
|
||||
|
||||
vim /etc/opt/ripple/rippled.cfg
|
||||
|
||||
{% include '_snippets/conf-file-location.ja.md' %}<!--_ -->
|
||||
|
||||
2. 設定ファイルに`[crawl]`を追加または更新し、変更を保存します。
|
||||
|
||||
[crawl]
|
||||
0
|
||||
|
||||
`[crawl]`の他のすべての内容を削除するか、コメントアウトしてください。
|
||||
|
||||
3. 設定ファイルに変更を保存したら、`rippled`サーバを再起動して、更新された設定を適用します。
|
||||
|
||||
systemctl restart rippled
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [ピアプロトコル](peer-protocol.html)
|
||||
- **チュートリアル:**
|
||||
- [rippledサーバの管理](manage-the-rippled-server.html)
|
||||
- **リファレンス:**
|
||||
- [server_infoメソッド][]
|
||||
- [peersメソッド][]
|
||||
- [ピアクローラ](peer-crawler.html)
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
html: enable-link-compression.html
|
||||
parent: configure-peering.html
|
||||
blurb: ピアツーピア通信を圧縮して帯域幅を節約します。
|
||||
labels:
|
||||
- コアサーバ
|
||||
---
|
||||
# 回線圧縮の有効化
|
||||
|
||||
`rippled`サーバは[ピアツーピア通信](peer-protocol.html)を圧縮することで帯域幅を節約できますが、その代償としてCPU使用率が高くなります。回線圧縮を有効にすると、サーバーは回線圧縮を有効にしているピアサーバとの通信を自動的に圧縮します。
|
||||
|
||||
## 手順
|
||||
|
||||
サーバで回線圧縮を有効にするには、以下の手順を実行します。
|
||||
|
||||
### 1. `rippled`サーバの設定ファイルを編集します。
|
||||
|
||||
```sh
|
||||
$ vim /etc/opt/ripple/rippled.cfg
|
||||
```
|
||||
|
||||
{% include '_snippets/conf-file-location.ja.md' %}<!--_ -->
|
||||
|
||||
### 2. 設定ファイルに`[compression]`を追加またはコメントアウトします。
|
||||
|
||||
圧縮を有効にするには
|
||||
|
||||
```text
|
||||
[compression]
|
||||
true
|
||||
```
|
||||
|
||||
圧縮を無効にするには`false`を使用します（デフォルト）。
|
||||
|
||||
### 3. `rippled` サーバを再起動します。
|
||||
|
||||
```sh
|
||||
$ sudo systemctl restart rippled.service
|
||||
```
|
||||
|
||||
再起動後、サーバは回線圧縮を有効にしている他のピアとの間で自動的に回線圧縮を使用します。
|
||||
|
||||
## 関連項目
|
||||
|
||||
- [容量の計画](capacity-planning.html)
|
||||
- [ピアプロトコル](peer-protocol.html)
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -17,7 +17,7 @@ labels:
|
||||
|
||||
$ vim /etc/opt/ripple/rippled.cfg
|
||||
|
||||
{% include '_snippets/conf-file-location.md' %}<!--_ -->
|
||||
{% include '_snippets/conf-file-location.ja.md' %}<!--_ -->
|
||||
|
||||
2. 構成ファイルで、`[peers_max]`スタンザのコメントを解除して編集するか、まだない場合は追加します。
|
||||
|
||||
|
||||
@@ -60,7 +60,7 @@ lables:
|
||||
|
||||
vim /etc/opt/ripple/rippled.cfg
|
||||
|
||||
{% include '_snippets/conf-file-location.md' %}<!--_ -->
|
||||
{% include '_snippets/conf-file-location.ja.md' %}<!--_ -->
|
||||
|
||||
3. 前のステップで生成した`validation_seed`値を使用して、`[node_seed]`スタンザを追加します。
|
||||
|
||||
|
||||
@@ -5,9 +5,9 @@ blurb: XRPを統合する人のための汎用的な構成。
|
||||
labels:
|
||||
- コアサーバー
|
||||
---
|
||||
# ウォレットサーバーとしてrippledを実行する
|
||||
# ウォレットサーバーとしてのrippledの実行
|
||||
|
||||
ウォレットサーバーは `rippled` のための汎用的な構成です。ウォレットサーバーを利用することで、XRP Ledger へのトランザクションの送信、レジャーの履歴へのアクセス、XRP と統合するための最新の [ツール](software-ecosystem.html) を利用することができます。
|
||||
ストックサーバは`rippled`用の汎用的な設定です。ストックサーバを利用することで、XRP Ledgerにトランザクションを送信したり、レジャーの履歴にアクセスしたり、XRPやXRP Ledgerと統合するための最新の[ツール](software-ecosystem.html)を利用したりすることができます。このサーバを使って、クライアントアプリケーションをXRP Ledgerに接続することができます。
|
||||
|
||||
|
||||
ウォレットサーバーは、次のすべてのことを行います。
|
||||
@@ -18,35 +18,28 @@ labels:
|
||||
|
||||
- 完全な共有グローバル[レジャー](ledgers.html)のローカルコピーを維持
|
||||
|
||||
- [コンセンサスプロセス](consensus.html)にバリデーターとして参加
|
||||
|
||||
バリデータとして[コンセンサスプロセス](consensus.html)に参加するには、代わりに[バリデータとしてrippledを実行](run-rippled-as-a-validator.html)してください。
|
||||
|
||||
|
||||
## 1. `rippled` のインストール
|
||||
## `rippled`のインストールと実行
|
||||
|
||||
詳しくは、[`rippled` のインストール](install-rippled.html) を参照してください。
|
||||
デフォルトのパッケージインストールでは、取引履歴の少ないストックサーバーがインストールされます。インストール手順については、[`rippled`のインストール](install-rippled.html)をご覧ください。
|
||||
|
||||
## 2. ウォレットサーバーでのバリデーションを有効にする
|
||||
|
||||
詳しくは、[rippledサーバーで検証を有効化](run-rippled-as-a-validator.html#3-enable-validation-on-your-rippled-server) を参照してください。
|
||||
|
||||
**注意:** バリデーターは、一般にアクセスできないようにする必要があります。ウォレットサーバーへのWebSocketアクセスなど、一般からのアクセスを許可しないでください。
|
||||
|
||||
## 3. ドメイン検証の提供
|
||||
|
||||
詳しくは、[ドメイン検証の提供](run-rippled-as-a-validator.html#6-provide-domain-verification)をご覧ください。
|
||||
インストール後、サーバーが一度に保存する履歴の量を調整することができます。この方法については、[オンライン削除の設定](configure-online-deletion.html)をご覧ください。
|
||||
|
||||
## トラブルシューティング
|
||||
|
||||
詳しくは、[`rippled`のトラブルシューティング](troubleshoot-the-rippled-server.html) を参照してください。
|
||||
詳しくは、[`rippled`のトラブルシューティング](troubleshoot-the-rippled-server.html)をご覧ください。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [XRP Ledgerの概要](xrp-ledger-overview.html)
|
||||
- [`rippled`サーバー](xrpl-servers.html)
|
||||
- [`rippled`サーバ](xrpl-servers.html)
|
||||
- **チュートリアル:**
|
||||
- [rippledサーバーのクラスター化](cluster-rippled-servers.html)
|
||||
- [rippledサーバのクラスター化](cluster-rippled-servers.html)
|
||||
- [`rippled`のインストール](install-rippled.html)
|
||||
- [容量の計画](capacity-planning.html)
|
||||
- **リファレンス:**
|
||||
|
||||
@@ -0,0 +1,19 @@
|
||||
---
|
||||
html: build-on-linux-mac-windows.html
|
||||
parent: install-rippled.html
|
||||
blurb: Linux、Mac（macOS）、Windows上でrippledをビルドします。
|
||||
labels:
|
||||
- コアサーバ
|
||||
- ブロックチェーン
|
||||
top_nav_grouping: 人気ページ
|
||||
---
|
||||
# Linux、Mac（macOS）、Windows上でのrippledのビルド
|
||||
|
||||
Windows、Linux、macOSなど様々なプラットフォームで`rippled`をビルドするには、C++開発環境が必要です。Git、Python、Conan、CMake、そして適切なC++コンパイラなどのツールが必要です。
|
||||
|
||||
続きを読むには、[GitHubの最新の`rippled`ビルド手順](https://github.com/XRPLF/rippled/blob/develop/BUILD.md)をご覧ください。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,348 @@
|
||||
---
|
||||
html: build-run-rippled-in-reporting-mode.html
|
||||
parent: install-rippled.html
|
||||
blurb: 検証済みデータのリモートプロシージャコール(RPC)を処理するrippledの特別なモードをビルドし、実行します。
|
||||
labels:
|
||||
- コアサーバ
|
||||
- ブロックチェーン
|
||||
top_nav_grouping: 人気ページ
|
||||
---
|
||||
# レポートモードでの`rippled`のビルドと実行
|
||||
|
||||
[レポートモード](rippled-server-modes.html)は、[HTTPとWebSocket API](http-websocket-apis.html)の提供に特化したXRP Ledgerのコアサーバのモードです。
|
||||
|
||||
レポートモードでは、サーバはピアツーピアネットワークに接続しません。その代わりに、gRPCを使用して、P2Pネットワークに接続されている1つまたは複数の信頼できるサーバから有効なデータを取得します。
|
||||
|
||||
そしてAPIコールを効率的に処理し、P2Pモードで動作している`rippled`サーバの負荷を軽減することができます。
|
||||
|
||||
{{ include_svg("img/reporting-mode-basic-architecture.svg", "図 1: レポートモードでの`rippled`の動作") }}
|
||||
|
||||
`rippled`のレポートモードでは2種類のデータストアを使用します。
|
||||
|
||||
* トランザクションのメタデータ、アカウントの状態、レジャーのヘッダーを含む`rippled`のプライマリ永続データストア。プライマリ永続データストアとしてNuDB(ソースに付属)または[Cassandra](https://cassandra.apache.org/)を使用できます。Cassandraを使用する場合、複数のレポートモードサーバが単一のCassandraインスタンスまたはクラスター内のデータへのアクセスを共有できます。
|
||||
|
||||
* リレーショナルデータを保持する[PostgreSQL](https://www.postgresql.org/)データベース。主に[txメソッド][]と[account_txメソッド][]で使用されます。
|
||||
|
||||
レポートモードサーバはAPIリクエストを受信すると、可能であればこれらのデータストアからデータをロードします。P2Pネットワークからのデータが必要なリクエストの場合、レポートモードはリクエストをP2Pサーバに転送し、レスポンスをクライアントに返します。
|
||||
|
||||
複数のレポートモードサーバが同じネットワークのアクセス可能なデータベース(PostgreSQLとCassandra)へのアクセスを共有することができます。
|
||||
|
||||
## レポートモードの実行方法
|
||||
|
||||
### 前提条件
|
||||
|
||||
1. お使いのシステムが[システム要件](system-requirements.html)を満たしていることを確認してください。
|
||||
|
||||
**注記:** データベースとしてCassandraを選択した場合、データがローカルディスクに保存されないため、`rippled`のディスク要件は低くなります。
|
||||
|
||||
2. 少なくとも1台の`rippled`サーバをP2Pモードで動作させる必要があります。
|
||||
|
||||
3. 互換性のあるバージョンのCMakeがインストールされている必要があります。
|
||||
|
||||
4. レポートモードで`rippled`を実行するために必要なデータストアをインストールして設定します。
|
||||
|
||||
1. PostgreSQLをインストールします。
|
||||
|
||||
2. プライマリ永続データストアとして使用するデータベースをインストールして構成します。CassandraまたはNuDBを選択できます。
|
||||
|
||||
3. macOSでは、Cassandraのcppライバを手動でインストールする必要があります。その他のプラットフォームでは、Cassandraドライバは`rippled`ビルドの一部としてビルドされます。
|
||||
|
||||
brew install cassandra-cpp-driver
|
||||
|
||||
#### PostgreSQLのインストール
|
||||
|
||||
**LinuxにPostgreSQLをインストール**
|
||||
|
||||
1. LinuxにPostgreSQLをダウンロードし[インストール](https://www.postgresqltutorial.com/install-postgresql-linux/)してください。
|
||||
|
||||
2. `psql`を使用してPostgreSQLデータベースサーバに接続し、ユーザ`newuser`とデータベース`reporting`を作成します。
|
||||
|
||||
psql postgres
|
||||
CREATE ROLE newuser WITH LOGIN PASSWORD ‘password’;
|
||||
ALTER ROLE newuser CREATEDB;
|
||||
\q
|
||||
psql postgres -U newuser
|
||||
postgres=# create database reporting;
|
||||
|
||||
|
||||
**macOSにPostgreSQLをインストール**
|
||||
|
||||
1. macOSにPostgreSQLをダウンロードしてインストールします。
|
||||
|
||||
brew install postgres
|
||||
brew services start postgres
|
||||
|
||||
2. `psql` を使用してPostgreSQLデータベースサーバに接続し、ユーザ`newuser`とデータベース`reporting`を作成します。
|
||||
|
||||
psql postgres
|
||||
CREATE ROLE newuser WITH LOGIN PASSWORD ‘password’;
|
||||
ALTER ROLE newuser CREATEDB;
|
||||
\q
|
||||
psql postgres -U newuser
|
||||
postgres=# create database reporting;
|
||||
|
||||
#### プライマリ永続データストアのインストールと設定
|
||||
|
||||
**Cassandra**
|
||||
|
||||
Cassandraをインストールし、レプリケーションを使用して`rippled`用のキースペースを作成します。
|
||||
|
||||
レプリケーション係数は3が推奨されますが、ローカルで実行する場合はレプリケーションは不要なので、`replication_factor`を1に設定することができます。
|
||||
|
||||
$ cqlsh [host] [port]
|
||||
> CREATE KEYSPACE `rippled` WITH REPLICATION =
|
||||
{'class' : 'SimpleStrategy', 'replication_factor' : 1 };
|
||||
|
||||
**NuDB**
|
||||
|
||||
ローカルネットワークのレポートモードで`rippled`を実行している場合、バックエンドデータベースとしてCassandraの代わりにNuDBを選択できます。
|
||||
|
||||
NuDBは`rippled`ビルドセットアップの一部としてインストールされ、追加のインストール手順は必要ありません。
|
||||
|
||||
|
||||
### 手順
|
||||
|
||||
1. [UbuntuまたはmacOS](https://github.com/XRPLF/rippled/blob/release/BUILD.md)のレポートモード用に`rippled`をビルド。
|
||||
|
||||
<!-- 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. レポートモードで`rippled`を実行するための設定ファイルを作成します。
|
||||
|
||||
設定ファイル例`rippled-example.cfg`をコピーして、非rootユーザで`rippled`を実行できる場所に`rippled-reporting-mode.cfg`として保存してください。例えば
|
||||
|
||||
mkdir -p $HOME/.config/ripple
|
||||
cp <RIPPLED_SOURCE>/cfg/rippled-example.cfg $HOME/.config/ripple/rippled-reporting-mode.cfg
|
||||
|
||||
3. rippled-reporting-mode.cfgを編集して必要なファイルパスを設定してください。あなたが`rippled`を実行する予定のユーザは、ここで指定したすべてのパスに書き込み権限を持っている必要があります。
|
||||
|
||||
1. `[node_db]`のパスには、レジャーデータベースを保存する場所を設定します。
|
||||
|
||||
2. `[database_path]`には他のデータベースデータを格納する場所を設定してください。(これには設定データを格納したSQLiteデータベースも含まれ、通常は`[node_db]`パスフィールドの一つ上の階層になります)。
|
||||
|
||||
3. `[debug_logfile]`に`rippled`がロギング情報を書き込めるパスを設定します。
|
||||
|
||||
これらは`rippled`が正常に起動するために必須の設定だけであることに注意してください。他の設定はすべてオプションであり、サーバが動作するようになってから調整することができます。
|
||||
|
||||
4. `rippled-reporting-mode.cfg`ファイルを編集してレポートモードを有効にします：
|
||||
|
||||
1. `[reporting]`スタンザのコメントを外すか、新しいスタンザを追加してください：
|
||||
|
||||
[reporting]
|
||||
etl_source
|
||||
read_only=0
|
||||
|
||||
2. データを抽出する`rippled`ソース(ETLソース)をリストアップします。これらの`rippled`サーバはgRPCが有効になっている必要があります。
|
||||
|
||||
注記: レポートモードはP2Pネットワークに接続しないため、データがネットワークのコンセンサスレジャーと実際に一致しているかどうかを検証できないため、信頼できるサーバだけを含めるようにしてください。
|
||||
|
||||
[etl_source]
|
||||
source_grpc_port=50051
|
||||
source_ws_port=6006
|
||||
source_ip=127.0.0.1
|
||||
|
||||
5. データベースの設定
|
||||
|
||||
1. `[ledger_tx_tables]`にPostgres DBを指定します。
|
||||
|
||||
[ledger_tx_tables]
|
||||
conninfo = postgres://newuser:password@127.0.0.1/reporting
|
||||
use_tx_tables=1
|
||||
|
||||
2. `[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. `rippled`の設定を変更してポートを開放してください。
|
||||
|
||||
1. パブリックWebSocketのポートを開きます。
|
||||
|
||||
[port_ws_admin_local]
|
||||
port = 6006
|
||||
ip = 127.0.0.1
|
||||
admin = 127.0.0.1
|
||||
protocol = ws
|
||||
|
||||
|
||||
2. ポートを開きます。
|
||||
|
||||
[port_grpc]
|
||||
port = 60051
|
||||
ip = 0.0.0.0
|
||||
|
||||
|
||||
3. レポートシステムのIPに安全なゲートウェイを追加します。
|
||||
|
||||
secure_gateway = 127.0.0.1
|
||||
|
||||
7. レポートモードで`rippled`を実行します。
|
||||
|
||||
./rippled --conf /home/ubuntu/.config/ripple/rippled-reporting-example.cfg
|
||||
|
||||
|
||||
### 予想される結果
|
||||
|
||||
ターミナルに表示される内容の抜粋です。
|
||||
|
||||
```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...
|
||||
```
|
||||
|
||||
## よくある質問
|
||||
|
||||
|
||||
**レポートモードを使用するには、`rippled`インスタンスを実行する必要がありますか？**
|
||||
|
||||
はい。レポートモードで動作している`rippled`サーバはピアツーピアネットワークに接続せず、ネットワークに接続されている一つ以上の`rippled`サーバから有効なデータを抽出します。そのため、少なくとも一つのP2Pモードサーバを動作させる必要があります。
|
||||
|
||||
**すでに`rippled`をインストールしています。設定ファイルを更新して`rippled`を再起動しレポートモードを有効にすることはできますか？**
|
||||
|
||||
現在のところ、レポートモードではソースをダウンロードして`rippled`をビルドする必要があります。レポートモード用のパッケージを提供するための作業が進められています。
|
||||
|
||||
|
||||
**レポートモードで`rippled`を実行するには、P2Pモードで動作している`rippled`サーバが少なくとも1つ必要です。これはディスク容量が2倍必要ということですか？**
|
||||
|
||||
答えは、プライマリデータストアの場所に依存します。プライマリデータストアにCassandraを使用する場合、レポートモードサーバがローカル・ディスクに保存するデータはかなり少なくなります。PostgreSQLサーバはリモートでもかまいません。複数のレポートモードサーバで同じデータを共有できます。
|
||||
|
||||
最後に、P2Pモードサーバはごく最近の履歴しか保持する必要がありませんが、レポートモードサーバは長期間の履歴を保持します。
|
||||
|
||||
`rippled`を実行するためのシステム要件については、[`rippled`のシステム要件](system-requirements.html)をご覧ください。
|
||||
|
||||
**PostgreSQLまたはCassandraデータベースから送られてくるデータの信頼性を確認するにはどうすればよいですか。**
|
||||
|
||||
レポートモードで`rippled`を実行すると、設定ファイルで指定されたETLソースからの有効なデータのみを提供します。P2Pモードで他人の`rippled`サーバをETLソースとして使用している場合、そのサーバを暗黙的に信頼することになります。そうでない場合は、自分の`rippled`ノードをP2Pモードで実行する必要があります。
|
||||
|
||||
**APIを使用するのではなく、リレーショナルデータベースに対して従来のSQLクエリを実行することは可能ですか？**
|
||||
|
||||
技術的には、データベースに直接アクセスすることも*可能*です。しかし、データはバイナリーBlobとして保存されており、その中のデータにアクセスするにはBlobをデコードしなければなりません。このため、従来のSQLクエリは、データの個々のフィールドを検索したりフィルタリングしたりすることができず、あまり役に立ちません。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,154 @@
|
||||
---
|
||||
html: install-clio-on-ubuntu.html
|
||||
parent: install-rippled.html
|
||||
blurb: Ubuntu Linuxにコンパイル済みのClioバイナリをインストールします。
|
||||
labels:
|
||||
- Clioサーバ
|
||||
---
|
||||
# Ubuntu LinuxへのClioのインストール
|
||||
|
||||
このページでは、[`apt`](https://ubuntu.com/server/docs)を使用して、**Ubuntu Linux 20.04 以降**にClioの最新安定版をインストールするための推奨手順を説明します。
|
||||
|
||||
これらの手順はRippleによってコンパイルされたバイナリをインストールします。Clioをソースからビルドする方法については、[Clioソースコードリポジトリ](https://github.com/XRPLF/clio)をご覧ください。
|
||||
|
||||
|
||||
## 前提条件
|
||||
|
||||
Clioをインストールする前に、以下の条件を満たしている必要があります。
|
||||
|
||||
- お使いのシステムが[システム要件](system-requirements.html)を満たしていることを確認してください。
|
||||
|
||||
**Note:** Clioのシステム要件は`rippled`サーバと同じですが、同じ量のレジャー履歴を保存するのに必要なディスク容量はClioの方が少なくなります。
|
||||
|
||||
- 互換性のあるバージョンのCMakeとBoostが必要です。ClioにはC++20とBoost 1.75.0以上が必要です。
|
||||
|
||||
- ローカルまたはリモートで実行されているCassandraクラスタにアクセスします。[Cassandraのインストールほうほ](https://cassandra.apache.org/doc/latest/cassandra/getting_started/installing.html)に従ってCassandraクラスタを手動でインストールして構成するか、次のコマンドのいずれかを使用してDockerコンテナ上でCassandraを実行できます。
|
||||
|
||||
- Clioデータを永続化する場合は、DockerコンテナでCassandraを実行し、Clioデータを格納する空のディレクトリを指定します：
|
||||
|
||||
docker run --rm -it --network=host --name cassandra -v $PWD/cassandra_data:/var/lib/
|
||||
cassandra cassandra:4.0.4
|
||||
|
||||
- Clioのデータを永続化したくない場合は、以下のコマンドを実行してください。
|
||||
|
||||
docker run --rm -it --network=host --name cassandra cassandra:4.0.4
|
||||
|
||||
- P2Pモードでは1つ以上の`rippled`サーバにgRPCでアクセスする必要があります。この`rippled`サーバはローカルでもリモートでも構いませんが、信頼する必要があります。最も確実な方法は、[`rippled`を自分でインストール](install-rippled.html)することです。
|
||||
|
||||
|
||||
## インストールの手順
|
||||
|
||||
1. リポジトリを更新します。
|
||||
|
||||
sudo apt -y update
|
||||
|
||||
**ヒント:** すでに同じマシンに`rippled`の最新版をインストールしている場合、Rippleのパッケージリポジトリと署名キーを追加する以下のステップは省略できます。ステップ5の"Rippleリポジトリを取得します。"から再開します。
|
||||
|
||||
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`で始まる部分です。）
|
||||
|
||||
4. 使用しているオペレーティングシステムのバージョンに対応する適切な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**向けのものです。
|
||||
|
||||
5. Rippleリポジトリを取得します。
|
||||
|
||||
sudo apt -y update
|
||||
|
||||
6. Clioソフトウェアパッケージをインストールします。オプションは2つあります。
|
||||
|
||||
- 同じマシン上で`rippled`を実行するには、両方のサーバーをセットアップする`clio`パッケージをインストールしてください：
|
||||
|
||||
sudo apt -y install clio
|
||||
|
||||
- Clio を`rippled`とは別のマシンで実行するには、Clioのみをセットアップする`clio-server`パッケージをインストールしてください：
|
||||
|
||||
sudo apt -y install clio-server
|
||||
|
||||
7. 別のマシンで`rippled`を実行している場合は、Clioの設定ファイルを修正して、そちらを指すようにします。`clio`パッケージを使って同じマシンに両方をインストールした場合は、この手順を省略できます。
|
||||
|
||||
|
||||
|
||||
1. Clioサーバの設定ファイルを編集して`rippled`サーバの接続情報を変更します。パッケージはこのファイルを`/opt/clio/etc/config.json`にインストールします。
|
||||
|
||||
"etl_sources":
|
||||
[
|
||||
{
|
||||
"ip":"127.0.0.1",
|
||||
"ws_port":"6006",
|
||||
"grpc_port":"50051"
|
||||
}
|
||||
]
|
||||
|
||||
以下の情報が含まれます。
|
||||
|
||||
- `rippled`サーバのIPアドレス
|
||||
- `rippled`が暗号化されていないWebSocket接続を受け付けるポート番号
|
||||
- `rippled`がgRPCリクエストを受け付けるポート番号
|
||||
|
||||
**注記** `etl_sources`セクションに項目を追加することで、複数の`rippled`サーバをデータソースとして使用することができます。そうすると、Clioはリスト内のすべてのサーバでリクエストを負荷分散し、少なくとも`rippled`サーバの一つが同期している限り、ネットワークに追いつくことができます。
|
||||
|
||||
[設定ファイル例](https://github.com/XRPLF/clio/blob/develop/example-config.json)は、ローカルのループバックネットワーク(127.0.0.1)上で動作している`rippled`サーバに、ポート6006のWebSocket(WS)とポート50051のgRPCでアクセスします。
|
||||
|
||||
2. Clioサーバが接続できるように`rippled`サーバの設定ファイルを更新します。パッケージはこのファイルを`/etc/opt/ripple/rippled.cfg`にインストールします。
|
||||
|
||||
* 暗号化されていないWebSocket接続を受け付けるポートを開きます。
|
||||
|
||||
[port_ws_public]
|
||||
port = 6005
|
||||
ip = 0.0.0.0
|
||||
protocol = ws
|
||||
|
||||
* gRPCリクエストを処理するポートを開き、`secure_gateway`項目にClioサーバのIPを指定します。
|
||||
|
||||
[port_grpc]
|
||||
port = 50051
|
||||
ip = 0.0.0.0
|
||||
secure_gateway = 127.0.0.1
|
||||
|
||||
**ヒント:** もし`rippled`と同じマシンでClioを実行していない場合は、サンプルの`secure_gateway`を変更して、ClioサーバのIPアドレスを使用してください。
|
||||
|
||||
8. Clioのsystemdサービスを有効にして起動します。
|
||||
|
||||
sudo systemctl enable clio
|
||||
|
||||
9. `rippled`サーバとClioサーバを起動します。
|
||||
|
||||
sudo systemctl start rippled
|
||||
sudo systemctl start clio
|
||||
|
||||
新しいデータベースで始める場合、Clioは完全なレジャーをダウンロードする必要があります。これには時間がかかります。両方のサーバを初めて起動する場合、Clioはレジャーを抽出する前に`rippled`の同期を待つため、さらに時間がかかることがあります。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [Clioサーバ](the-clio-server.html)
|
||||
@@ -37,7 +37,7 @@ labels:
|
||||
|
||||
gpg /usr/local/share/keyrings/ripple-key.gpg
|
||||
|
||||
出力に、次のようなRipple用のエントリーが含まれています。
|
||||
出力に、次のようなRipple用のエントリーが含まれていることを確認してください。
|
||||
|
||||
gpg: WARNING: no command supplied. Trying to guess what you mean ...
|
||||
pub rsa3072 2019-02-14 [SC] [expires: 2026-02-17]
|
||||
@@ -52,7 +52,7 @@ labels:
|
||||
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`という単語を次のいずれかに置き換えます。
|
||||
上記の例は、**Ubuntu 20.04 Focal Fossa**向けのものです。。その他のオペレーティングシステムについては、`focal`という単語を次のいずれかに置き換えます。
|
||||
|
||||
- `bionic` for **Ubuntu 18.04 Bionic Beaver**
|
||||
- `buster` for **Debian 10 Buster**
|
||||
|
||||
@@ -0,0 +1,443 @@
|
||||
---
|
||||
html: private-network-with-docker.html
|
||||
name: Run a Private Network with Docker
|
||||
parent: use-stand-alone-mode.html
|
||||
blurb: DockerとDocker Composeを使って独自のXRPプライベートレジャーネットワークを構築する方法を紹介します。
|
||||
labels:
|
||||
- コアサーバー
|
||||
---
|
||||
|
||||
# プライベートネットワークをDockerで構築する
|
||||
|
||||
このチュートリアルでは、[Docker](https://docs.docker.com/get-docker/)と最新バージョンの[rippled](https://hub.docker.com/r/xrpllabsofficial/xrpld)を使って、あなたのコンピュータ上でプライベートなXRP Ledgerネットワークを実行する方法を説明します。
|
||||
|
||||
公開されているXRPテストネットのサーバを利用することは簡単ですが、プライベートネットワークを実行することは、XRP Ledgerの仕組みを理解しようとするときや、新しい機能を単独でテストするときに便利です。
|
||||
|
||||
**注意:** このチュートリアルは開発またはテスト目的のみに適しており、実際の資金を使用するものではありません。本番ネットワークではこの設定を使用しないでください。
|
||||
|
||||
## 学習のゴール
|
||||
|
||||
このチュートリアルでは、次のことを学びます：
|
||||
|
||||
- 3つの`rippled`バリデータノードを持つ _小規模な_ ネットワークのセットアップと設定方法(各ノードの鍵の生成方法を含む)
|
||||
|
||||
- [Docker Compose](https://docs.docker.com/compose/)でネットワークを動かす方法.
|
||||
|
||||
- ネットワークが稼働していることを確認する方法
|
||||
|
||||
次の図は、これからセットアップするコンテナ型プライベートネットワークの概要を示したものです。
|
||||
|
||||
{{ include_svg("img/xrp-ledger-private-network-docker.svg", "図1：3つのノードのコンテナ型プライベートレジャーネットワークの構成図") }}
|
||||
|
||||
## 前提条件
|
||||
|
||||
このチュートリアルに従うには、最新の**Docker**があなたの選択したプラットフォームにインストールされていることを確認してください。
|
||||
|
||||
## バリデータキーの生成
|
||||
|
||||
`rippled`で提供されている`validator-keys`ツールを使って、バリデータノードの**それぞれ**のキーを生成します。生成されたキーは、後で使用するためにコンピュータのテキストファイルに保存しておく必要があります。
|
||||
|
||||
1. ターミナルで以下を実行し、`rippled`のDockerコンテナシェル内でコマンドを実行します：
|
||||
|
||||
docker run -it --entrypoint /bin/bash xrpllabsofficial/xrpld:latest
|
||||
|
||||
**注記:** Apple M1またはM2チップの場合は、代わりに`docker run -it --platform linux/amd64 --entrypoint /bin/bash xrpllabsofficial/xrpld:latest`を実行してください。
|
||||
|
||||
出力の例:
|
||||
|
||||
root@7732bd585b14:/#
|
||||
|
||||
2. `create_keys`コマンドを使ってバリデータのキーペアを生成します。
|
||||
|
||||
cd /opt/ripple/bin &&
|
||||
./validator-keys create_keys --keyfile /PATH/TO/YOUR/validator-<NUMBER>-keys.json
|
||||
|
||||
出力の例:
|
||||
|
||||
バリデータのキーは/PATH/TO/YOUR/validator-<NUMBER>-keys.jsonに保存されています。
|
||||
|
||||
このファイルは安全に保管し、決して他人と共有しないようにしてください。
|
||||
|
||||
**注意:** 本番環境やテスト環境では、常にベストプラクティスに従い、生成された鍵は暗号化されたUSBフラッシュドライブなど、安全でオフラインかつ復元可能な場所に保管してください。しかし、このチュートリアルはローカルの開発セットアップの例なので、鍵をコンピュータに保存するだけで十分です。
|
||||
|
||||
3. JSON出力から**public_key**の値をコピーし、コンピュータ上のテキストファイルに保存します。
|
||||
|
||||
cat /PATH/TO/YOUR/validator-<NUMBER>-keys.json
|
||||
|
||||
出力の例:
|
||||
|
||||
{
|
||||
"key_type" : "ed25519",
|
||||
"public_key" : "nHD9jtA9y1nWC2Fs1HeRkEisqV3iFpk12wHmHi3mQxQwUP1ywUKs",
|
||||
"revoked" : false,
|
||||
"secret_key" : "paLsUUm9bRrvNBPpvJQ4nF7vdRTZyDNofGMMYs9EDeEKeNJa99q",
|
||||
"token_sequence" : 0
|
||||
}
|
||||
|
||||
4. `create_token`コマンドを使ってバリデータトークンを作成します。
|
||||
|
||||
./validator-keys create_token --keyfile /PATH/TO/YOUR/validator-<NUMBER>-keys.json
|
||||
|
||||
出力から次のようなトークンの値をコピーし、コンピュータ上のテキストファイルに保存します。
|
||||
|
||||
[validator_token]
|
||||
eyJ2YWxpZGF0aW9uX3NlY3J|dF9rZXkiOiI5ZWQ0NWY4NjYyNDFjYzE4YTI3NDdiNT
|
||||
QzODdjMDYyNTkwNzk3MmY0ZTcxOTAyMzFmYWE5Mzc0NTdmYT|kYWY2IiwibWFuaWZl
|
||||
c3QiOiJKQUFBQUFGeEllMUZ0d21pbXZHdEgyaUNjTUpxQzlnVkZLaWxHZncxL3ZDeE
|
||||
hYWExwbGMyR25NaEFrRTFhZ3FYeEJ3RHdEYklENk9NU1l1TTBGREFscEFnTms4U0tG
|
||||
bjdNTzJmZGtjd1JRSWhBT25ndTlzQUtxWFlvdUorbDJWMFcrc0FPa1ZCK1pSUzZQU2
|
||||
hsSkFmVXNYZkFpQnNWSkdlc2FhZE9KYy9hQVpva1MxdnltR21WcmxIUEtXWDNZeXd1
|
||||
NmluOEhBU1FLUHVnQkQ2N2tNYVJGR3ZtcEFUSGxHS0pkdkRGbFdQWXk1QXFEZWRGdj
|
||||
VUSmEydzBpMjFlcTNNWXl3TFZKWm5GT3I3QzBrdzJBaVR6U0NqSXpkaXRROD0ifQ==
|
||||
|
||||
5. 残りのバリデータノードについても**2-4**の手順を繰り返します。すべてのバリデータのキーとトークンを生成したら、ターミナルで`exit`と入力してDockerコンテナを終了します。
|
||||
|
||||
## ネットワークの設定
|
||||
|
||||
このセクションでは、ネットワーク内のバリデータノードを設定する方法について説明します。
|
||||
|
||||
**注記:** このチュートリアルの設定により、ネットワークはある程度のレジャー履歴を保持できるようになりますが、保存される取引履歴の量は、ネットワークがオンラインになってからの時間によって異なります。
|
||||
|
||||
### ノードのディレクトリを作成
|
||||
|
||||
コンピュータに、プライベートネットワーク内のすべてのノードのディレクトリと、それぞれの設定フォルダを作成します。
|
||||
|
||||
xrpl-private-network/
|
||||
├── validator_1/
|
||||
│ └── config
|
||||
├── validator_2/
|
||||
│ └── config
|
||||
└── validator_3/
|
||||
└── config
|
||||
|
||||
ターミナルで以下のコマンドを実行し、ディレクトリを作成します。
|
||||
|
||||
mkdir -p xrpl-private-network/{validator_1/config,validator_2/config,validator_3/config}
|
||||
|
||||
### バリデータ設定ファイルの作成
|
||||
|
||||
各バリデータノードについて、以下の手順を実行します。
|
||||
|
||||
1. バリデータの`config`ディレクトリに`rippled.cfg`ファイルを作成します。
|
||||
|
||||
2. 以下の`rippled.cfg`テンプレートの情報をファイルにコピーします。
|
||||
|
||||
[server]
|
||||
port_rpc_admin_local
|
||||
port_rpc
|
||||
port_ws_admin_local
|
||||
port_ws_public
|
||||
port_peer
|
||||
# ssl_key = /etc/ssl/private/server.key
|
||||
# ssl_cert = /etc/ssl/certs/server.crt
|
||||
|
||||
[port_rpc_admin_local]
|
||||
port = 5005
|
||||
ip = 127.0.0.1
|
||||
admin = 127.0.0.1
|
||||
protocol = http
|
||||
|
||||
[port_ws_admin_local]
|
||||
port = 6006
|
||||
ip = 127.0.0.1
|
||||
admin = 127.0.0.1
|
||||
protocol = ws
|
||||
|
||||
[port_ws_public]
|
||||
port = 80
|
||||
ip = 0.0.0.0
|
||||
protocol = ws
|
||||
|
||||
[port_peer]
|
||||
port = 51235
|
||||
ip = 0.0.0.0
|
||||
protocol = peer
|
||||
|
||||
[port_rpc]
|
||||
port = 51234
|
||||
ip = 0.0.0.0
|
||||
admin = 127.0.0.1
|
||||
protocol = https, http
|
||||
|
||||
[node_size]
|
||||
small
|
||||
# tiny
|
||||
# small
|
||||
# medium
|
||||
# large
|
||||
# huge
|
||||
|
||||
[node_db]
|
||||
type=NuDB
|
||||
path=/var/lib/rippled/db/nudb
|
||||
advisory_delete=0
|
||||
|
||||
# How many ledgers do we want to keep (history)?
|
||||
# Integer value that defines the number of ledgers
|
||||
# between online deletion events
|
||||
online_delete=256
|
||||
|
||||
[ledger_history]
|
||||
# How many ledgers do we want to keep (history)?
|
||||
# Integer value (ledger count)
|
||||
# or (if you have lots of TB SSD storage): 'full'
|
||||
256
|
||||
|
||||
[database_path]
|
||||
/var/lib/rippled/db
|
||||
|
||||
[debug_logfile]
|
||||
/var/log/rippled/debug.log
|
||||
|
||||
[sntp_servers]
|
||||
time.windows.com
|
||||
time.apple.com
|
||||
time.nist.gov
|
||||
pool.ntp.org
|
||||
|
||||
[ips_fixed]
|
||||
validator_1 51235
|
||||
validator_2 51235
|
||||
validator_3 51235
|
||||
|
||||
[validators_file]
|
||||
validators.txt
|
||||
|
||||
[rpc_startup]
|
||||
{ "command": "log_level", "severity": "warning" }
|
||||
# severity (order: lots of information .. only errors)
|
||||
# debug
|
||||
# info
|
||||
# warn
|
||||
# error
|
||||
# fatal
|
||||
|
||||
[ssl_verify]
|
||||
0
|
||||
|
||||
[validator_token]
|
||||
<Add your validator token here>
|
||||
|
||||
3. チュートリアルの[最初](#バリデータキーの生成)に作成した次のようなバリデータトークンを追加します。
|
||||
|
||||
[validator_token]
|
||||
eyJtYW5pZmVzdCI6IkpBQUFBQUZ4SWUwcVd3ZnpLZ2tacWJTL01QVGxHVXlOeTVJZ2kzYzlG
|
||||
V1JvTDFIMGoydkNobk1oQTBOc2RHeFNXbWF6b0xkdU5NeDVmaVVZU2h3bjk2SnpSaUFReFJz
|
||||
cENuR2dka1l3UkFJZ1dLazV4cklSN3FNRWd1UmJwOTRrN0E0QnBOZmwrT2VYUm92bTNIOGtS
|
||||
YkVDSUZXYmVocHd5ZS9UWFpZRGYwUEgwTkxjN2I1cWNEOXUvbzVYUjA4YW1pUEJjQkpBYjEw
|
||||
NE95bG5IS0JSZTJmRW1qSVVjT24vZ2ZacE44bXdhZ1dGbUxlemc2RFRLL0hpTVkyektNQ3l0
|
||||
aksreHpHNWpjc3JlS3k5Q29sRGtpKzk3V0JHQ2c9PSIsInZhbGlkYXRpb25fc2VjcmV0X2tl
|
||||
eSI6IjZFNTNFQjA1M0IwNEM1RTczNDc4M0VCMEU0RTBFOTg1NDVDNDQ0QzI3OTBFQjdBMzA2
|
||||
NUQzMUVBOTU1QjQyMTIifQ==
|
||||
|
||||
各バリデータノードは固有のトークンを持たなければなりません。
|
||||
|
||||
### validators.txtファイルの作成
|
||||
|
||||
バリデータの設定ファイルを作成したので、次は`validator.txt`ファイルを追加します。このファイルは、どのバリデータがネットワークから信頼されるかを定義します。
|
||||
|
||||
各ノードにて以下の手順を実行します：
|
||||
|
||||
1. 設定ディレクトリに`validators.txt`ファイルを作成します。
|
||||
2. チュートリアルの[最初](#バリデータキーの生成)に生成した`validator-keys.json`ファイルから公開鍵をコピーします。
|
||||
3. 次のようにすべてのバリデータの公開鍵を追加します。
|
||||
|
||||
[validators]
|
||||
nHBgaEDL8buUECuk4Rck4QBYtmUgbAoeYJLpWLzG9iXsznTRYrQu
|
||||
nHBCHX7iLDTyap3LumqBNuKgG7JLA5tc6MSJxpLs3gjkwpu836mY
|
||||
nHU5STUKTgWdreVqJDx6TopLUymzRUZshTSGcWNtjfByJkYdiiRc
|
||||
|
||||
## ネットワークを開始する
|
||||
|
||||
Docker Composeを使用すると、簡単な`yaml`ファイルの設定でコンピュータ上の複数のコンテナを管理することができます。このセクションでは、Docker Composeでネットワークを実行する方法と、ネットワークが正常に実行されていることを確認する方法について説明します。
|
||||
|
||||
**注記:** Docker Composeはデフォルトでコンテナが同じDocker仮想ネットワークに属していることを保証するので、`rippled`コンテナ同士が通信するために追加の手順を踏む必要はありません。
|
||||
|
||||
プライベートネットワークの使用を始めるには、次の手順を実行します。
|
||||
|
||||
1. `xrpl-private-network`ディレクトリのルートに`docker-compose.yml`ファイルを作成し、次の内容を追加します。
|
||||
|
||||
version: "3.9"
|
||||
services:
|
||||
validator_1:
|
||||
platform: linux/amd64
|
||||
container_name: validator_1
|
||||
image: "xrpllabsofficial/xrpld"
|
||||
ports:
|
||||
- "8001:80"
|
||||
- "5006:5005"
|
||||
- "4001:6006"
|
||||
- "9001:51235"
|
||||
volumes:
|
||||
- ./validator_1/config:/config/
|
||||
validator_2:
|
||||
platform: linux/amd64
|
||||
container_name: validator_2
|
||||
image: "xrpllabsofficial/xrpld"
|
||||
ports:
|
||||
- "8002:80"
|
||||
- "5007:5005"
|
||||
- "4002:6006"
|
||||
- "9002:51235"
|
||||
volumes:
|
||||
- ./validator_2/config:/config/
|
||||
validator_3:
|
||||
platform: linux/amd64
|
||||
container_name: validator_3
|
||||
image: "xrpllabsofficial/xrpld"
|
||||
ports:
|
||||
- "8003:80"
|
||||
- "5008:5005"
|
||||
- "4003:6006"
|
||||
- "9003:51235"
|
||||
volumes:
|
||||
- ./validator_3/config:/config/
|
||||
|
||||
各 `service`の`volumes`キーは、設定ファイルが保存されている場所を表します。例えば、`./validator_1/config:/config/`はホストコンピュータの`/validator_1/config`ディレクトリをDockerコンテナの`/config/`マップします。ホストのディレクトリで行われた変更は、自動的にコンテナに反映されます。
|
||||
|
||||
2. ターミナルから`docker-compose.yml`ファイルを作成した場所で`docker-compose up -d`を実行してください。以下のような出力が表示されるはずです。
|
||||
|
||||
[+] Running 4/4
|
||||
✔ Network xrpl-private-network_default Created 0.0s
|
||||
✔ Container validator_3 Started 0.5s
|
||||
✔ Container validator_1 Started 0.5s
|
||||
✔ Container validator_2 Started 0.5s
|
||||
|
||||
## ネットワークを検証する
|
||||
|
||||
プライベートレジャーのネットワークが立ち上がったので、**各**バリデータノードが期待通りに動作していることを確認する必要があります。
|
||||
|
||||
1. ターミナルで`docker exec -it <validator_name> bin/bash`を実行し、バリデータのDockerコンテナでコマンドを実行します。`<validator_name>`はコンテナ名に置き換えてください(例:`validator_1`)。
|
||||
|
||||
2.
|
||||
|
||||
rippled server_info | grep server_state
|
||||
|
||||
出力の例:
|
||||
|
||||
"server_state" : "proposing"
|
||||
|
||||
**注記:** server_stateが**proposing**に更新されない場合は、レジャーの更新に時間がかかることがあるため、数分後にステップ**2**を繰り返してください。
|
||||
|
||||
3. バリデータに接続しているピア数を確認します。
|
||||
|
||||
rippled server_info | grep peers
|
||||
|
||||
出力の例:
|
||||
|
||||
"peers" : 2
|
||||
|
||||
4. 以下のコマンドを実行して、genesisのアカウント情報を確認します。
|
||||
|
||||
rippled account_info rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh validated strict
|
||||
|
||||
出力の例:
|
||||
|
||||
{
|
||||
"result" : {
|
||||
"account_data" : {
|
||||
"Account" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
|
||||
"Balance" : "100000000000000000",
|
||||
"Flags" : 0,
|
||||
"LedgerEntryType" : "AccountRoot",
|
||||
"OwnerCount" : 0,
|
||||
"PreviousTxnID" : "0000000000000000000000000000000000000000000000000000000000000000",
|
||||
"PreviousTxnLgrSeq" : 0,
|
||||
"Sequence" : 1,
|
||||
"index" : "2B6AC232AA4C4BE41BF49D2459FA4A0347E1B543A4C92FCEE0821C0201E2E9A8"
|
||||
},
|
||||
"ledger_hash" : "CFCEFB049A71E26DE812529ABB212F330FAF583A98FE073F14713B0644D7CEE9",
|
||||
"ledger_index" : 10181,
|
||||
"status" : "success",
|
||||
"validated" : true
|
||||
}
|
||||
}
|
||||
|
||||
5. Dockerコンテナシェルから抜けるには、ターミナルで`exit`と入力します。
|
||||
|
||||
### テストトランザクションの実行
|
||||
|
||||
アカウントに送金できることを確認するため、**テスト**トランザクションを実行してください。
|
||||
|
||||
1. ターミナルで以下のコマンドを実行し、トランザクションを送信します。
|
||||
|
||||
docker exec -it validator_1 \
|
||||
rippled submit 'snoPBrXtMeMyMHUVTgbuqAfg1SUTb' '{ "Account": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", "Amount": "1000000000", "Destination": "r9wRwVgL2vWVnKhTPdtxva5vdH7FNw1zPs", "TransactionType": "Payment", "Fee": "10" }'
|
||||
|
||||
出力の例:
|
||||
|
||||
{
|
||||
"result" : {
|
||||
"engine_result" : "tesSUCCESS",
|
||||
"engine_result_code" : 0,
|
||||
"engine_result_message" : "The transaction was applied. Only final in a validated ledger.",
|
||||
"status" : "success",
|
||||
"tx_blob" : "1200002280000000240000000161400000003B9ACA0068400000000000000A73210330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD02074463044022057CCEED351A4278F35C13FD104A55338DC8F48C1F9902D58045A4CD0CE89C92A0220184026BD3B1E2C21239017CAF1BBF683 35EDC57F6F98D952E263763DE449561B8114B5F762798A53D543A014CAF8B297CFF8F2F937E883145988EBB744055F4E8BDC7F67FD53EB9FCF961DC0",
|
||||
"tx_json" : {
|
||||
"Account" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
|
||||
"Amount" : "1000000000",
|
||||
"Destination" : "r9wRwVgL2vWVnKhTPdtxva5vdH7FNw1zPs",
|
||||
"Fee" : "10",
|
||||
"Flags" : 2147483648,
|
||||
"Sequence" : 1,
|
||||
"SigningPubKey" : "0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020",
|
||||
"TransactionType" : "Payment",
|
||||
"TxnSignature" : "3044022057CCEED351A4278F35C13FD104A55338DC8F48C1F9902D58045A4CD0CE89C92A0220184026BD3B1E2C21239017CAF1BBF68335EDC57F6F98D952E263763DE449561B",
|
||||
"hash" : "EB516738841794B24819C68273E0F853A3D234350E6534F7F2841F620CE99437"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
2. 各バリデータについて、宛先アカウント `r9wRwVgL2vWVnKhTPdtxva5vdH7FNw1zPs` に 1000000000 XRP があることを確認します。
|
||||
|
||||
docker exec -it validator_1 \
|
||||
rippled account_info r9wRwVgL2vWVnKhTPdtxva5vdH7FNw1zPs validated strict
|
||||
|
||||
出力の例:
|
||||
|
||||
{
|
||||
"result" : {
|
||||
"account_data" : {
|
||||
"Account" : "r9wRwVgL2vWVnKhTPdtxva5vdH7FNw1zPs",
|
||||
"Balance" : "1000000000",
|
||||
"Flags" : 0,
|
||||
"LedgerEntryType" : "AccountRoot",
|
||||
"OwnerCount" : 0,
|
||||
"PreviousTxnID" : "EB516738841794B24819C68273E0F853A3D234350E6534F7F2841F620CE99437",
|
||||
"PreviousTxnLgrSeq" : 36,
|
||||
"Sequence" : 1,
|
||||
"index" : "0F2E4615AE24EEF58EE82BD1E67D237234ED41BFC8B7885630B7AC05082E97AA"
|
||||
},
|
||||
"ledger_hash" : "6F9F54903CC4546F7A426CD78AFD68D907F5DC40B1780DF31A662CF65920E49C",
|
||||
"ledger_index" : 51,
|
||||
"status" : "success",
|
||||
"validated" : true
|
||||
}
|
||||
}
|
||||
|
||||
すべてのバリデータノードは、`r9wRwVgL2vWVnKhTPdtxva5vdH7FNw1zPs`アカウントの同じ残高1000000000XRPで応答する必要があります。
|
||||
|
||||
## ネットワークを停止する
|
||||
|
||||
プライベートネットワークの使用を終了したい場合、
|
||||
|
||||
1. ターミナルで`xrpl-private-network`ディレクトリに移動します。
|
||||
2. 以下のコマンドを実行して、ネットワークをシャットダウンします。
|
||||
|
||||
docker-compose down
|
||||
|
||||
出力の例:
|
||||
|
||||
[+] Running 4/4
|
||||
✔ Container validator_3 Removed 1.7s
|
||||
✔ Container validator_1 Removed 1.6s
|
||||
✔ Container validator_2 Removed 1.6s
|
||||
✔ Network xrpl-private-network_default Removed 0.0s
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **ネットワークとサーバ:**
|
||||
- [ピアプロトコル](peer-protocol.html)
|
||||
|
||||
- **References:**
|
||||
- [XRPL TestnetのDocker用セットアップスクリプト](https://github.com/UNIC-IFF/xrpl-docker-testnet)
|
||||
@@ -0,0 +1,117 @@
|
||||
---
|
||||
html: health-check-interventions.html
|
||||
parent: troubleshoot-the-rippled-server.html
|
||||
blurb: 自動化されたインフラ監視の一環として、rippledサーバのヘルスチェックを使用します。
|
||||
labels:
|
||||
- コアサーバー
|
||||
---
|
||||
# ヘルスチェックの導入
|
||||
|
||||
[Health Checkメソッド](health-check.html)は、自動監視によって`rippled`サーバが正常でないことを認識し、サーバの再起動や人間の管理者への警告などの介入を促すために利用することができます。
|
||||
|
||||
インフラモニタリング、そしてより一般的な信頼性の設計は、複数のデータソースを利用して状況に応じて意思決定を行う高度な学問分野です。本書では、ヘルスチェックを最も効果的に使用する方法についていくつかの提案を行いますが、これらの提案は、より大きな対策の一環としてのガイドラインに過ぎません。
|
||||
|
||||
## 瞬間的な障害
|
||||
|
||||
ヘルスチェックの[metrics][]の中には、急速に正常でない範囲に変動し、その後すぐに自動的に回復するものがあります。ヘルスチェックが不正常なステータスを報告するたびにアラートを上げることは不要であり、望ましくありません。自動化されたモニタリングシステムは、health checkメソッドを頻繁に呼び出しますが、問題が深刻で一貫している場合にのみ、より高いレベルの介入に拡張する必要があります。
|
||||
|
||||
例えば、1秒に1回サーバーのヘルスチェックを行う場合、サーバが「警告」ステータスを3回連続して報告した場合、または5秒間に4回報告した場合にアラートを発生させることができます。また、サーバが5秒間に2回"critical"ステータスを報告した場合にも、アラートを発生させることができます。通常、サーバが"warning"と報告するたびにアラートを発生させるのは過剰です。
|
||||
|
||||
**ヒント:** サーバは通常、起動後の最初の数秒間は"critical"ステータスを報告し、ネットワークへの接続が確立されると"warning"ステータスに切り替わり、ネットワークへの同期が完了すると"healthy"ステータスを報告します。再起動後、追加の介入を行う前に、サーバーの同期に5～15分ほど時間が必要です。
|
||||
|
||||
## 特殊なケース
|
||||
|
||||
サーバの構成によっては、正常に動作していても常に”warning"ステータスを報告する場合があります。あなたのサーバがこのような特殊なケースに当てはまる場合は、正常なステータスと実際の問題の違いを認識できるように自動監視を設定する必要があります。これにはおそらく、ヘルスチェックメソッドのJSONレスポンスボディを解析し、その値を期待される正常な範囲と比較することが含まれます。
|
||||
|
||||
特殊なケースの例としては、次のようなものがあります。
|
||||
|
||||
- [プライベートピア](peer-protocol.html#private-peers)は通常、既知のサーバのみに接続するごく少数のピアツーピア接続を持ちますが、サーバが7つ以下のピアに接続している場合、ヘルスチェックは`peers`メトリックで警告を報告します。サーバが設定されているピア数を正確に把握し、その値をチェックする必要があります。
|
||||
- 新しいトランザクションが継続的に送信されていない[並列ネットワークまたはテストネットワーク](parallel-networks.html)では、ネットワークは新しいトランザクションを最大20秒待ってから新しいレジャーバージョンの検証を試みますが、検証された最新のレジャーが7秒以上古い場合、ヘルスチェックは`validated_ledger`メトリックで警告を報告します。本番環境でないネットワークで`rippled`を実行している場合、トランザクションが定期的に送信されていることが分かっていない限り、これに対する`warning`メッセージを無視することができます。XRP Ledgerプロトコルは、処理する新しいトランザクションがなくても、少なくとも20秒に一度は新しいレジャーバージョンを検証するように設計されているからです。
|
||||
|
||||
## 推奨される対策
|
||||
|
||||
ヘルスチェックに失敗し、それが単なる[瞬間的な障害](#瞬間的な障害)でない場合、障害から回復するために取るべき行動は原因によって異なります。インフラストラクチャを設定することで、いくつかのタイプの障害を自動的に修正できるかもしれません。組織の構造によっては、管理者のレベルが異なり、スキルの低い下位レベルの管理者が単独で特定の問題を解決できても、より大規模で複雑な問題を解決するには上位レベルの管理者に連絡する必要があります。いつ、どのように対応するかは、固有の状況によって異なりますが、ヘルスチェックの結果で報告される情報は、これらの決定の要因になる可能性があります。
|
||||
|
||||
以下のセクションでは、試みるべき一般的な介入と、それらの介入を促す可能性が最も高いヘルスチェックのステータスを提案します。自動化されたシステムや人間の管理者は、これらの介入やその他の介入によって選択的に状況を確認することができます。
|
||||
|
||||
- [トラフィックのリダイレクト](#トラフィックのリダイレクト): 影響を受けたサーバーからトラフィックをリダイレクトします。
|
||||
- [再起動](#再起動): サーバーソフトウェアまたはハードウェアを再起動します。
|
||||
- [更新](#更新): `rippled`をアップグレードします。
|
||||
- [ネットワークの調査](#ネットワークの調査): 問題が他の場所で発生した場合のためにネットワークを調査します。
|
||||
- [ハードウェアの交換](#ハードウェアの交換)
|
||||
|
||||
|
||||
### トラフィックのリダイレクト
|
||||
|
||||
一般的な信頼性のためのテクニックは、1つ以上の負荷分散プロキシを通して冗長なサーバのプールを実行することです。これは`rippled`サーバではできますが、[バリデータ](rippled-server-modes.html)ではすべきではありません。場合によっては、ロードバランサはプール内のサーバの健全性を監視し、現在健全であると報告しているサーバだけにトラフィックを向けることができます。これにより、サーバは一時的な過負荷から回復し、自動的にアクティブなサーバのプールに戻ることができます。
|
||||
|
||||
特に`health`ステータスが`warning`と表示されたサーバに対しては、不健全なサーバからトラフィックをリダイレクトすることが適切な対応です。`critical`の範囲にあるサーバはより重要な介入が必要かもしれません。
|
||||
|
||||
|
||||
### 再起動
|
||||
|
||||
最も簡単な方法は、サーバを再起動することです。これにより、以下の[metrics][]のいずれかを含む、いくつかのタイプの障害の一時的な問題を解決できます。
|
||||
|
||||
- `load_factor`
|
||||
- `peers`
|
||||
- `server_state`
|
||||
- `validated_ledger`
|
||||
|
||||
`rippled`サービスのみを再起動するには、`systemctl`を使ってください：
|
||||
|
||||
```
|
||||
$ sudo systemctl restart rippled.service
|
||||
```
|
||||
|
||||
より強力な介入は、マシン全体を再起動することです。
|
||||
|
||||
**注意n:** サーバの起動後、ネットワークへの同期には通常最大15分を要します。この間、ヘルスチェックはcriticalまたはwarningステータスを報告する可能性があります。自動化システムでは、サーバを再起動する前に、同期に十分な時間をかける必要があります。
|
||||
|
||||
|
||||
### 更新
|
||||
|
||||
サーバがヘルスチェックで`"amendment_blocked": true`と報告した場合、これはXRP Ledgerがサーバが理解できない[プロトコルの修正(Amendment)](amendments.html)を有効にしたことを示しています。ネットワークの改訂されたルールを誤って解釈して損害を被らないようにするため、このようなサーバーは正常に動作する代わりに"amendment blocked(Amendmentブロック)"となります。
|
||||
|
||||
Amendmentブロックを解消するには、[サーバをアップデート](install-rippled.html)して、Amendmentプログラムを理解できる新しいバージョンのソフトウェアにしてください。
|
||||
|
||||
また、ソフトウェアのバグによってサーバが[同期できない](server-doesnt-sync.html)状態になることもあります。この場合、`server_state`メトリクスはwarningまたはcriticalな状態になっている可能性があります。最新の安定版リリースを使用していない場合は、アップグレードして、この問題を引き起こす可能性のある既知の問題に対する最新の修正を入手してください。
|
||||
|
||||
|
||||
### ネットワークの調査
|
||||
|
||||
信頼性の低いネットワーク接続や不十分なネットワーク接続が原因で、サーバーが停止を報告することがあります。以下の[Metrics][]のwarningまたはcriticalの値は、ネットワークの問題を示している可能性があります。
|
||||
|
||||
- `peers`
|
||||
- `server_state`
|
||||
- `validated_ledger`
|
||||
|
||||
この場合、必要な介入には、次のような他のシステムへの変更が含まれることがあります。
|
||||
|
||||
- 必要なトラフィックがサーバに到達できるようにする、または外部からの有害なトラフィックをブロックするためのファイアウォールルールの調整
|
||||
- ネットワークインターフェース、スイッチ、ルーター、ケーブルの再起動または交換
|
||||
- 他のネットワークサービスプロバイダーに連絡して、そのプロバイダー側での問題の解決
|
||||
|
||||
|
||||
|
||||
### ハードウェアの交換
|
||||
|
||||
ハードウェアの故障や、ハードウェアの処理能力を超える高負荷が原因で障害が発生した場合、コンポーネントの交換やサーバ全体の交換が必要になることがあります。
|
||||
|
||||
XRP Ledgerのサーバにかかる負荷の量は、ネットワークのトランザクション量に一部依存し、それはランダムに変化します。また、負荷は利用者の利用パターンにも依存します。状況に応じて適切なハードウェアと設定を計画する方法については、[容量の計画](capacity-planning.html)をご覧ください。
|
||||
|
||||
次の [metrics][]のwarningまたはcriticalの値は、ハードウェアが十分でないことを示している可能性があります。
|
||||
|
||||
- `load_factor`
|
||||
- `server_state`
|
||||
- `validated_ledger`
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
[metrics]: health-check.html#response-format
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
html: server-doesnt-sync.html
|
||||
parent: troubleshoot-the-rippled-server.html
|
||||
blurb: Troubleshoot problems that make a rippled server unable to sync with the rest of the XRP Ledger.
|
||||
blurb: rippledサーバがXRP Ledgerの他の部分と同期できない問題のトラブルシューティング。
|
||||
labels:
|
||||
- コアサーバー
|
||||
---
|
||||
@@ -89,7 +89,7 @@ labels:
|
||||
[database_path]
|
||||
/var/lib/rippled/db_new
|
||||
|
||||
{% include '_snippets/conf-file-location.md' %}<!--_ -->
|
||||
{% include '_snippets/conf-file-location.ja.md' %}<!--_ -->
|
||||
|
||||
4. `rippled`サーバーを再起動します。
|
||||
|
||||
|
||||
@@ -0,0 +1,131 @@
|
||||
---
|
||||
html: server-is-amendment-blocked.html
|
||||
parent: troubleshoot-the-rippled-server.html
|
||||
blurb: Amendmentによる変更を実行できないサーバーのトラブルシューティング
|
||||
labels:
|
||||
- コアサーバー
|
||||
---
|
||||
# rippledサーバがAmendmentブロックされた
|
||||
|
||||
Amendmentブロックされたサーバは、レジャーの有効性を判断したり、トランザクションを送信または処理したり、コンセンサスプロセスに参加したりすることができません。
|
||||
|
||||
あなたの`rippled`サーバが[Amendmentブロック](amendments.html#amendmentブロックされたサーバ)されたことを示す最初の兆候の一つは、トランザクションを送信したときに返される`amendmentBlocked`エラーです。以下は`amendmentBlocked`エラーの例です。
|
||||
|
||||
```json
|
||||
{
|
||||
"result":{
|
||||
"error":"amendmentBlocked",
|
||||
"error_code":14,
|
||||
"error_message":"Amendment blocked, need upgrade.",
|
||||
"request":{
|
||||
"command":"submit",
|
||||
"tx_blob":"479H0KQ4LUUXIHL48WCVN0C9VD7HWSX0MG1UPYNXK6PI9HLGBU2U10K3HPFJSROFEG5VD749WDPHWSHXXO72BOSY2G8TWUDOJNLRTR9LTT8PSOB9NNZ485EY2RD9D80FLDFRBVMP1RKMELILD7I922D6TBCAZK30CSV6KDEDUMYABE0XB9EH8C4LE98LMU91I9ZV2APETJD4AYFEN0VNMIT1XQ122Y2OOXO45GJ737HHM5XX88RY7CXHVWJ5JJ7NYW6T1EEBW9UE0NLB2497YBP9V1XVAEK8JJYVRVW0L03ZDXFY8BBHP6UBU7ZNR0JU9GJQPNHG0DK86S4LLYDN0BTCF4KWV2J4DEB6DAX4BDLNPT87MM75G70DFE9W0R6HRNWCH0X075WHAXPSH7S3CSNXPPA6PDO6UA1RCCZOVZ99H7968Q37HACMD8EZ8SU81V4KNRXM46N520S4FVZNSJHA"
|
||||
},
|
||||
"status":"error"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
次の`rippled`ログメッセージは、サーバーがAmendmentブロックされていることを示しています。
|
||||
|
||||
```
|
||||
2018-Feb-12 19:38:30 LedgerMaster:ERR One or more unsupported amendments activated: server blocked.
|
||||
```
|
||||
|
||||
あなたの`rippled`サーバがAmendmentブロックされているかどうかは`server_info`コマンドで確認できます。レスポンスの中で`result.info.amendment_blocked`を探してください。もし`amendment_blocked`が`true`になっていれば、あなたのサーバはAmendmentブロックされています。
|
||||
|
||||
**JSON-RPCレスポンスの例:**
|
||||
|
||||
```json
|
||||
{
|
||||
"result": {
|
||||
"info": {
|
||||
"amendment_blocked": true,
|
||||
"build_version": "0.80.1",
|
||||
"complete_ledgers": "6658438-6658596",
|
||||
"hostid": "ip-10-30-96-212.us-west-2.compute.internal",
|
||||
"io_latency_ms": 1,
|
||||
"last_close": {
|
||||
"converge_time_s": 2,
|
||||
"proposers": 10
|
||||
},
|
||||
...
|
||||
},
|
||||
"status": "success"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
## サーバのブロックを解除する
|
||||
|
||||
最も簡単な解決策は`rippled`の最新バージョンにアップデートすることですが、場合によっては、サーバをブロックするAmendmentを含む古いバージョンにアップデートすることもできます。
|
||||
|
||||
**注意:** 最新の`rippled`バージョンがセキュリティやその他の緊急の修正を提供する場合は、できるだけ早く最新バージョンにアップグレードしてください。
|
||||
|
||||
最新バージョンより古いバージョンにアップグレードすることで`rippled`サーバのブロックを解除できるかどうかを調べるには、どの機能がサーバをブロックしているかを調べ、ブロックされた機能をサポートしている`rippled`バージョンを調べます。
|
||||
|
||||
どの機能が`rippled`サーバをブロックしているかを調べるには、[`feature`](feature.html)管理者コマンドを使います。以下のような機能を探してください。
|
||||
|
||||
```
|
||||
"enabled" : true
|
||||
"supported" : false
|
||||
```
|
||||
これらの値は、最新のレジャーではAmendmentが必要だが、サーバがその実装をサポートしていないことを意味します。
|
||||
|
||||
** JSON-RPCレスポンスの例:**
|
||||
|
||||
```json
|
||||
{
|
||||
"result": {
|
||||
"features": {
|
||||
"07D43DCE529B15A10827E5E04943B496762F9A88E3268269D69C44BE49E21104": {
|
||||
"enabled": true,
|
||||
"name": "Escrow",
|
||||
"supported": true,
|
||||
"vetoed": false
|
||||
},
|
||||
"08DE7D96082187F6E6578530258C77FAABABE4C20474BDB82F04B021F1A68647": {
|
||||
"enabled": true,
|
||||
"name": "PayChan",
|
||||
"supported": true,
|
||||
"vetoed": false
|
||||
},
|
||||
"1562511F573A19AE9BD103B5D6B9E01B3B46805AEC5D3C4805C902B514399146": {
|
||||
"enabled": false,
|
||||
"name": "CryptoConditions",
|
||||
"supported": true,
|
||||
"vetoed": false
|
||||
},
|
||||
"157D2D480E006395B76F948E3E07A45A05FE10230D88A7993C71F97AE4B1F2D1": {
|
||||
"enabled": true,
|
||||
"supported": false,
|
||||
"vetoed": false
|
||||
},
|
||||
...
|
||||
"67A34F2CF55BFC0F93AACD5B281413176FEE195269FA6D95219A2DF738671172": {
|
||||
"enabled": true,
|
||||
"supported": false,
|
||||
"vetoed": false
|
||||
},
|
||||
...
|
||||
"F64E1EABBE79D55B3BB82020516CEC2C582A98A6BFE20FBE9BB6A0D233418064": {
|
||||
"enabled": true,
|
||||
"supported": false,
|
||||
"vetoed": false
|
||||
}
|
||||
},
|
||||
"status": "success"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
この例では、以下の機能との競合が`rippled`サーバのAmendmentブロックを引き起こしています。
|
||||
|
||||
* `157D2D480E006395B76F948E3E07A45A05FE10230D88A7993C71F97AE4B1F2D1`
|
||||
|
||||
* `67A34F2CF55BFC0F93AACD5B281413176FEE195269FA6D95219A2DF738671172`
|
||||
|
||||
* `F64E1EABBE79D55B3BB82020516CEC2C582A98A6BFE20FBE9BB6A0D233418064`
|
||||
|
||||
どの`rippled`バージョンがこれらの機能をサポートしているか調べるには、[既知のAmendment](known-amendments.html)をご覧ください。
|
||||
@@ -0,0 +1,93 @@
|
||||
---
|
||||
html: peer-crawler.html
|
||||
parent: peer-port-methods.html
|
||||
blurb: ネットワークの情報とステータスの統計を共有するための特別なAPIメソッドです。
|
||||
labels:
|
||||
- コアサーバ
|
||||
- ブロックチェーン
|
||||
---
|
||||
# ピアクローラ
|
||||
|
||||
ピアクローラは、ピアツーピアネットワークの健全性と統計情報を報告するための特別な[peer portメソッド](peer-port-methods.html)です。このAPIメソッドは、デフォルトでは[ピアプロトコル](peer-protocol.html)のポートを通して非rootベースで利用可能で、コンセンサスやレジャーの履歴、その他の必要な情報についての`rippled`サーバのピアツーピア通信にも使用されます。
|
||||
|
||||
ピアクローラによって報告された情報は事実上公開され、XRP Ledgerのネットワーク全体やその健全性、統計情報について報告するために使用することができます。
|
||||
|
||||
## リクエストのフォーマット
|
||||
|
||||
ピアクローラ情報をリクエストするには、以下のHTTPリクエストを送信します。
|
||||
|
||||
- **プロトコル:** https
|
||||
- **HTTPメソッド:** GET
|
||||
- **ホスト:** (任意の`rippled`サーバ(ホスト名またはIPアドレス))
|
||||
- **ポート:** (`rippled`サーバがピアプロトコルを使用するポート番号、通常は51235です。)
|
||||
- **パス:** `/crawl`
|
||||
- **セキュリティ:** ほとんどの`rippled`サーバはリクエストに応答するために自己署名証明書を使います。デフォルトでは、(ウェブブラウザを含む)ほとんどのツールは、そのようなレスポンスは信頼できないとしてフラグを立てたりブロックしたりします。これらのサーバからの応答を表示するには、証明書のチェックを無視しなければなりません(たとえば、cURLを使用している場合は`--insecure`フラグを追加します)。
|
||||
|
||||
|
||||
## レスポンスのフォーマット
|
||||
|
||||
レスポンスにはステータスコード**200 OK**とメッセージ本文にJSONオブジェクトがあります。
|
||||
|
||||
JSONオブジェクトは次のフィールドを含んでいます。
|
||||
|
||||
| `フィールド` | 値 | 説明 |
|
||||
|:-----------------|:-----------|:-------------------------------------------------|
|
||||
| `counts` | オブジェクト | _(省略可)_ [get_countsメソッド][]のレスポンスと同じように、このサーバの状態に関する統計情報を返します。デフォルトの設定では、このフィールドは報告されません。報告される情報には、レジャーデータベースとトランザクションデータベースのサイズ、アプリケーション内キャッシュのキャッシュヒット率、さまざまな種類のオブジェクトがメモリにキャッシュされている数などがあります。メモリに保存されるオブジェクトの種類には、レジャー(`Ledger`)、トランザクション(`STTx`)、検証メッセージ (`STValidation`)などがあります。 |
|
||||
| `overlay` | オブジェクト | _(省略可)_ [peersメソッド][]のレスポンスに似ています。`active`というフィールドがあり、これはオブジェクトの配列です(下記参照)。 |
|
||||
| `server` | オブジェクト | _(省略可)_ このサーバに関する情報。[server_stateメソッド][]の公開フィールドを含みます。どの`rippled`バージョン(`build_version`)か、どの[レジャーバージョン](ledger-history.html)が利用可能か(`complete_ledgers`)、サーバーの負荷量などです。[更新: rippled 1.2.1][]. |
|
||||
| `unl` | オブジェクト | _(省略可)_ [validatorsメソッド][]や[validator_list_sitesメソッド][]のレスポンスと同様です。[更新: rippled 1.2.1][]. |
|
||||
| `version` | 数値 | このピアクローラのレスポンスフォーマットのバージョンを示します。現在のピアクローラのバージョン番号は`2`です。[更新: rippled 1.2.1][]. |
|
||||
|
||||
`overlay.active`配列の各メンバーは、次のフィールドを持つオブジェクトです。
|
||||
|
||||
| `Field` | 値 | 説明 |
|
||||
|:-------------------|:-----------------------|:-----------------------------------|
|
||||
| `complete_ledgers` | 文字列 | このピアで利用可能な[レジャーバージョン](ledger-history.html)の範囲。 |
|
||||
| `complete_shards` | 文字列 | _(省略可)_ このピアが利用可能な[レジャー履歴シャード](history-sharding.html)の範囲。 |
|
||||
| `ip` | 文字列 (IPv4アドレス) | _(省略可)_この接続ピアの IPアドレス。ピアがバリデータまたは[プライベートピア](peer-protocol.html#プライベートピア)として設定されている場合は省略されます。[更新: rippled 1.2.1][]. |
|
||||
| `port` | 文字列 (数値) | _(省略可)_ RTXPを提供するピアサーバのポート番号。通常は`51235`。ピアがバリデータまたは[プライベートピア](peer-protocol.html#プライベートピア)として設定されている場合は省略されます。[更新: rippled 1.2.1][]. |
|
||||
| `public_key` | 文字列 (Base64エンコード) | このピアがRTXPメッセージに署名するために使用するECDSA鍵ペアの公開鍵。(これはピアサーバの[server_infoメソッド][]で報告される`pubkey_node`と同じデータです)。 |
|
||||
| `type` | 文字列 | `in`または`out`の値で、ピアへのTCP接続が着信か発信かを示します。 |
|
||||
| `uptime` | 数値 | サーバがこのピアに接続している秒数。 |
|
||||
| `version` | 文字列 | 相手が使用していると報告した`rippled`バージョン番号。 |
|
||||
|
||||
#### 例
|
||||
|
||||
リクエスト:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*HTTP*
|
||||
|
||||
```
|
||||
GET https://localhost:51235/crawl
|
||||
```
|
||||
|
||||
*cURL*
|
||||
|
||||
```
|
||||
curl --insecure https://localhost:51235/crawl
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
レスポンス:
|
||||
|
||||
```json
|
||||
200 OK
|
||||
|
||||
{% include '_api-examples/peer-crawler/crawl.json' %}
|
||||
```
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- [ピアプロトコル](peer-protocol.html)
|
||||
- [ピアクローラの設定](configure-the-peer-crawler.html)
|
||||
- [Validator History Service](https://github.com/ripple/validator-history-service)は、検証関連データの取り込み、集計、保存、配布にピアクローラを使用するサービスの一例です。
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
Reference in New Issue
Block a user