【NEM/Symbol技術勉強会】Symbol-bootstrap アップグレード手順書例（1.0.8の場合）

2021/9/8、ソフトウェアのアップグレードを適切にしていないノードが、同期に失敗して停止する事案が発生しました。さらに確定的ファイナライズのブロック高が進まなくなり、確率的ファイナライズのみでブロックが進行している状態になりました（Symbolは2段構えのファイナリティ機構を持っています）。それに伴い、9/15にsymbol-bootstrap1.0.8がリリースされ、Catapultバージョンは1.0.2.0に上がりました。これにより1.0.0.0のノードはネットワークから拒否されるようになりました。

ノードのアップグレードは神経を使いますし、手順は英語で提供されるため、アップグレードを躊躇したり、遅らせたりするノードも少なくありません。そこで、参考になるかと思い、しずいノード（ibone74）で使ったアップグレードプロトコールを公開します。しずいノードは、https-portalを使っていますので、その手順や、別サーバーへのバックアップ手順も含んでいます。ノードによって環境は微妙に異なりますが、これを参考にして自分のノードに合ったアップグレード手順書を作ってみてはいかがでしょうか。

1. cd https-portal
2. docker-compose stop
3. cd ~/
4. sudo systemctl stop symbol-platform
5. docker ps
6. cp -r symbol （バックアップ先ディレクトリ名）
7. cd symbol
8. check mypreset.yml contents
9. sudo npm install -g symbol-bootstrap
10. symbol-bootstrap -v
11. symbol-bootstrap verify
12. symbol-bootstrap config -p mainnet -a dual --upgrade -c mypreset.yml
13. Check the target/addreses.yml (are the addresses set properly?)
        name: node
        friendlyName: ibone74
        roles: 'Peer,Api'
        main:
            privateKey: ************************
            publicKey: ************************
            address: ************************
        transport:
            privateKey: ************************
            publicKey: ************************
            address: ************************
        remote:
            privateKey: ************************
            publicKey: ************************
            address: ************************
        vrf:
            privateKey: ************************
            publicKey: ************************
            address: ************************

14. Check the target/nodes/node/server-config/resources
        config-finalization.properties
		    unfinalizedBlocksDuration = 10m
        config-harvesting.properties 
            maxUnlockedAccounts = 20
            delegatePrioritizationPolicy = Age
            beneficiaryAddress = ************************
        config-node.properties
            minFeeMultiplier = 10
            transactionSelectionStrategy = oldest
            host = symbol.shizuilab.com
            friendlyName = ibone74
15. symbol-bootstrap compose --upgrade
16. symbol-bootstrap run
        Check the logs and see the blocks can catchup without critical errors. If ok, ctrl-C.
17. Restart server to release memory (update and upgrade os here if you want)
18. sudo mount -t nfs （ソースディレクトリ） （ターゲットディレクトリ）
19. sudo systemctl start symbol-platform
20. cd ~/symbol
21. symbol-bootstrap healthCheck
22. cd ~/https-portal
23. https://nemlog.nem.social/blog/63740 に従ってhttps-portalの内容もアップデート（上級者向け；一旦STAGE: 'production'をコメントアウトするところから。あひきさんのNode Listに載せるコメントなどもここでアップデートできます）．
24. docker ps

では，それぞれのステップについて解説していきます．

まず、https-portalのディレクトリに移動します。
docker-compose stopでhttps-portalを停止。
一旦ユーザーディレクトリに移動します。
しずいノードはsystemctlのユニットファイルを使うデーモンによる自動起動を使用していますので、まずそれを停止してノードを止めます。
docker psを使って、https-portalとsymbolのすべてのプロセスが停止している事を確認します。
symbolディレクトリをバックアップします。しずいノードは外部のファイルサーバーにまるごとバックアップしてから、アーカイブしています。ディレクトリごとバックアップを取っておけば、アップデートに失敗したり、トラブルが起きた時に、一時的にバックアップディレクトリからも前バージョンで起動ができます。
symbolディレクトリに移動します。
mypreset.ymlの内容をチェックして、変更したい項目があれば編集します。
しずいノードでは、npmをユーザー権限で-gオプション付きで実行するとエラーになるので、sudoを使って管理者権限でsymbol-bootstrapのインストールをおこないます。
symbol-bootstrapのバージョンが最新になっているかを確認します。
symbol-bootstrap verifyで、サーバーの環境がsymbolの実行に合格しているかを確認します。
symbol-bootstrap configで設定のアップグレードをします。
targetディレクトリに入り、addresses.ymlの内容が合っているか、バックアップのaddresses.ymlの内容と突き合わせてチェックします。ここでaddresses.ymlが新しいものに書き換わっていたらカスタムプリセットファイルの内容や文法が合っているかをチェックします。
target/nodes/node/server-config/resourcesディレクトリにある設定ファイルの中身を確認します。カスタムプリセットファイルの設定や数値と一致しているか確認します。齟齬が見つかってもこれらの設定ファイルの設定を直接変更してはいけません。カスタムプリセットファイルの書式が間違っている可能性があるので、そちらを確認・修正してから、もういちどsymbol-bootstrap configコマンドでアップグレードします。
symbolのディレクトリに戻り、symbol-bootstrap composeで、dockerファイル類を構築します。dockerの設定にも変更が及んでいた場合のために（symbol-bootstrap v.1.0.6の時がそうでした）–upgradeオプションをつけた方が安心です。
symbol-bootstrap run で、実行します。ログを見ながらrest-gateway, api, dbなどがエラーで終了したりしていないか確認します。できれば、ノードが最新ブロックに追いついて、新しいブロックが承認されるまでログを流しておくと良いです。ノードが正常に動いていることが確認できたら、一旦control-Cで停止させます．
ここでサーバーを再起動しておくと、アップグレード作業で増加したメモリー領域を開放することができます。OSのアップデートも必要ならばここですると良いでしょう。
メンテナンスのために、バックアップ用のディレクトリを再マウントしておきます（メインストーレージの容量が足りなくなりそうな時などに、すぐにスイッチしてバックアップディレクトリから起動するための準備も兼ねてます）。
systemctlでsymbolを起動させます。
symbolのディレクトリに移動します。
symbol-bootstrap healthCheckでノードが正常に動いているか確認します。
https-portalディレクトリに移動します。
docker-compose.ymlのSTAGEの行をコメントアウト（先頭に#を付け加える）してから、うにやさんのガイドに従って、https-portalを再スタートさせます。STAGEのproductionを一旦外さないとエラーになるようです。あひきさんのSymbol Node Listにコメント反映させたい場合には、こちらの記事を参照してください。
すべてのdockerプロセスが起動しているかをdocker psで確認します。

symbol-bootstrapには、ノード環境やノードの起動状態をチェックする便利なコマンドがあります。symbolをインストールしてあるディレクトリで下記のようなコマンドを実行することでノードの状態を確認できます。

symbol-bootstrap verifyOSにインストールされたいろいろなコンポーネントのバージョンやテストを行う

symbol-bootstrap healthCheckSymbolのさまざまな機能が正常に動いているかチェックする

さらに、Webブラウザを使って自分のノード（下記のリンクのsymbol.shizuilab.comの部分を自分のノードのドメイン名かIPアドレスに変更してください）に問い合わせをおこない、設定が反映されてちゃんと動いているか、委任ハーベストがはずれていないかなどを最終確認できます。ブロック高のチェック：http://shizuinet.tplinkdns.com/3000/chain/infoノードの設定のチェック：http://shizuinet.tplinkdns.com/:3000/node/info委任ハーベスターのチェック：http://shizuinet.tplinkdns.com/:3000/node/unlockedaccount

https化している場合はhttpをhttps、3000を3001にしてチェック。

あひきさんNode List のURL
うにやさんによる、Node List情報表示変更手順書にしたがって、ノードの説明文や詳細リンクを編集してもよいですね。

これらに異常がなければ、ノードは正常にアップグレードされています。Symbol node listで自分のノードがちゃんとリストされ、ブロック高が他とそろっているかも確認しておきましょう。今回、大きなバグの修正などがなくても、バージョンアップにともない少しずつ仕様が変更されて、古いバージョンのノードが最新のバージョンのノードと同期できなくなることがあることがわかりました。

ノードオーナーの皆さんは、遅滞ないアップデートとバックアップでこれからもSymbolを共に支えていきましょう。