Zenn
Open1

NEM NIS1ノードのバージョンアップ方法メモ

ブロックチェーン
Java
#
nem
#
nis1
松岡靖典松岡靖典

元々このスクラップを書き始めたのは、以下リンクのHarlock HardForkにおいて、NEM(NIS1)のクライアントのv0.6.97からv0.6.98へのバージョンアップ対応比率があまり高くない状況を懸念したことがきっかけでした。
https://zenn.dev/y_matsuoka/scraps/e47ea7d7598723

公式なリソースは以下2記事が一番参考になるのではないかと思います。
https://hackmd.io/@syndicate/governance#NEM
https://nemproject.github.io/nem-docs/pages/Guides/node-operation/docs.en.html

上記公式リソースを見てもバージョンアップ方法がわからずハードフォークに対応できていない人の参考になれば＆次のバージョンアップ時に自分への参考になればと思い以下にメモしてみました。正確性に保証はありませんが、良かったら参考にしてみてください。

その後、Harlock対応バージョンのマイナーパッチリリースとして、v0.6.99がリリースされ、Harlock対応バージョンのv0.6.98またはv0.6.99が多数派となり、無事Harlockハードフォークが成功するかに思えましたが、v0.6.98, v0.6.99の実装にバグがあったことと、一部のv0.6.98, v0.6.99のノードの設定に誤りがあってHarlock HardForkに必要な設定が消えた状態でノードが動いてしまっていたこと等が原因で、Harlock HardForkは仕切り直しとなりました。

(この際、ハードフォーク予定ブロック高さ以降の数時間は、ブロックチェーンの状態が「本来の仕様からはそれた意図しない状態の多数派ノードでブロック高さ先行したネットワーク」と「本来の仕様の意図通りの状態の少数派ノードでブロック高さの歩が非常に遅くなってブロック高さが遅れたネットワーク」の異なるネットワークに分岐したイレギュラーな状態となっていました。最終的には「本来の仕様の意図通りの状態」のネットワークが多数派ノード群にブロック高さで追いついて、「本来の仕様の意図通りの状態」の安定したネットワーク状態に収束するという出来事がありました...)

そして、2021/11/24に改めてバグフィックスされたHarlock(2)対応バージョンとしてNIS1 v0.6.100がリリースされました。
https://github.com/NemProject/nis/releases/tag/v0.6.100

上記の経緯に伴い、ノードオーナーの皆様は、NIS1 v0.6.100へのバージョンアップ対応をお願いします。以下はNIS1 v0.6.100へのバージョンアップ手順のメモです。現時点では手順を未検証ですが、前回とさほど大きく変わらないだろうと推測しています。

  1. DBのデータが配置されているフォルダを把握(~/nemであるという前提で説明)
  2. NIS1のクライアント自身やconfigファイルが配置されているフォルダを把握(~/packageであるという前提で説明)
  3. ノードを停止させる(方法は色々あると思うが、curl localhost:7890/shutdownコマンドを叩くのがもっとも手っ取り早いだろうか？)
  4. lockファイルを消しておく(rm ~/nem/nis.lock)
  5. 2のフォルダをリネームして設定をバックアップしておく(~/package -> ~/backup-package-0698とか？、自分でわかりやすいようにバージョン番号等つけておくとよいかも。)
  6. ホームディレクトリ(~/)でNIS1のクライアントをダウンロード
  • cd ~/
  • curl -o nis1.tgz https://bob.nem.ninja/nis-0.6.100.tgz
  • これで~/nis1.tgzとしてNIS1のクライアントの圧縮ファイルがダウンロードされる
  1. ダウンロードしたクライアントを展開する
  • tar -xzvf nis1.tgz
  • これで~/packageディレクトリにNIS1ノードのクライアントが展開される
  1. cd ~/packageで対象ディレクトリに移動し、~/package/nisディレクトリ配下の.propertiesを含む3ファイルの必要な箇所に、2, 5でバックアップしたファイルから必要な設定を書き移す ... この時にバックアップのconfigを丸ごとコピペするのは新しいバージョンのconfigの差分を取りこぼす結果になりやすく、危ないようです。
  • config.properties ←取り急ぎメモ: このファイル直接編集するのはNGでconfig-user.propertiesというファイルを作成して、そちらに各ユーザーの設定を記述するのが正しいそうです。(追記: 正直、そんなのドキュメントに書いてあったっけ？と思ったけど、そういうやり方をしたほうが、書き換えてはいけないconfig項目を書き換えるリスクが減らせるということのようで、必ずしもやっちゃだめということではなさそうです。)
    • nem.host = 自分のドメインやIPアドレス
  • db.properties ... 普通触らなくてもよいと思うが、DB配置ディレクトリがデフォルト通りでない場合は設定必要かも？触る場合は、db-user.propertiesを作ってなのかなあ？
  • logalpha.properties ... 普通触らなくてもよいと思うが、logに何らかの特殊な設定加えていた場合は設定必要かも？触る場合は、logalpha-user.propertiesを作ってなのかなあ？
  1. ~/package/nix.runNis.shの中をバックグラウンド実行や割り当てメモリ増やすために修正加えておく
  • 2, 5でバックアップした同名ファイルと同様に修正すればOK
  1. cd ~/packageコマンドで対象ディレクトリに移動し、bash nix.runNis.shコマンドを実行してノードを起動
  2. 動作確認 ... 再開直後はデータの整合性を改めて再同期しなおしているように見えていて、これはそれなりに時間がかかる模様。その間、ブロック高さ確認のAPIは少しずつ最新ブロック高さにおいついて行っている様子がわかるが、node/infoやheartbeat等の大部分のAPIは有効な値を返せない状態になる模様。焦らず最新ブロック高さに同期されるまで待ちましょう。
  • curl localhost:7890/chain/heightでブロック高さを確認
  • curl localhost:7890/node/infoでノード情報を確認
  • curl localhost:7890/heartbeatでノードのヘルスチェック状況を確認

-Xmx14Gの箇所は、ノードのメモリ量に応じて無理の無い値を設定する必要がある。←ここ、公式のドキュメントでは6Gになっていて、ここを無駄に大きな数字にしてしまうと意図しない状態になってしまう可能性あるかも？

~/package/nis.runNis.sh
#!/bin/bash

cd nis
nohup java -Xms4G -Xmx14G -cp ".:./*:../libs/*" org.nem.deploy.CommonStarter &
cd -

自分自身の設定ファイルをメモ ... ドメイン名の設定、ハーベストの枠をデフォルトの4から32に変更、トランザクションハッシュでのクエリを全期間サポートできるよう設定。過去の情報を参照できる(HISTORICAL_ACCOUNT_DATAの)設定では再同期にかなり時間がかかって結果的にノードが死んだので、パフォーマンス的な懸念や設定的な問題があるかもしれない。

~/package/nis/config-user.properties
# protocol, host, ports, paths
nem.host = nem-main-1.next-web-technology.com

# Maximum number of unlocked accounts. Meaning: maximum number of accounts that are allowed to use this NIS for harvesting
# Keep the value within a reasonable range, a too large value an cause problems for all harvesting accounts.
nis.unlockedLimit = 32

# The number of hours to keep the hashes of transactions in memory (-1 = keep forever, 36 is the minimum)
# If transaction hashes are in memory, it is possible to query transactions by hash.
nis.transactionHashRetentionTime = -1

# Optional features supported by the local node (pipe-separated).
# TRANSACTION_HASH_LOOKUP: transactions can be retrieved by supplying the transaction hash.
# HISTORICAL_ACCOUNT_DATA: historical account data can be retrieved.
nis.optionalFeatures = TRANSACTION_HASH_LOOKUP

追記: DBデータをあらかじめダウンロードしておいて、ノード起動することで、かなり時間短縮可能と思われるが、以下の通りやってみても自分の場合、うまくノード起動できなかった... なぜだろう？optionalFeaturesとかがデフォルトじゃない場合は、この方法ダメだったりするのかな？

  1. cd ~/
  2. curl -o nis1_mainnet_latest.h2.db.gz https://bob.nem.ninja/nis5_mainnet-latest.h2.db.gz
  3. gzip -d nis1_mainnet_latest.h2.db.gz
  4. mv ~/nis1_mainnet_latest.h2.db ~/nis5_mainnet.mv.db
  5. rm ~/nem/nis/data/nis5_mainnet.mv.db
  6. mv ~/nis5_mainnet.mv.db ~/nem/nis/data/nis5_mainnet.mv.db
  7. rm ~/nem/nis.lock
  8. cd package
  9. bash nix.runNis.sh

追記: ノードが死んでしまった場合は、プロセスを殺すなり、サーバーを再起動するなりして、動作を止めて、以下のようにDBのファイルと、ロックファイルを削除して、ゼロから再同期するのがシンプルで間違いがないかもしれません。ただし、この方法は、再同期にかなり時間がかかります。直近だと、自分の場合、1日+6～9時間くらいかかりました。

  1. rm ~/nem/nis/data/nis5_mainnet.mv.db でDBファイルを削除
  2. rm ~/nem/nis.lock でロックファイルを削除
  3. cd package でノード起動のシェルスクリプトが置いてあるディレクトリに移動
  4. bash nix.runNis.sh でノード起動
  5. 後は再同期完了まで待つ

0から再同期していく際には、(途中のデータからデータの整合性を再同期していくときと異なり、)以下のAPI全て、その時点でのノードの状態を正常に返してくれる仕様になっているように見えます。

  • curl localhost:7890/chain/heightでブロック高さを確認
  • curl localhost:7890/node/infoでノード情報を確認
  • curl localhost:7890/heartbeatでノードのヘルスチェック状況を確認

幣ノード情報メモ

全ノードリスト