#dusk $PORTAL は今日燃えている。元々、@Duskでノードをアップグレードすることは、バイナリを置き換えて、同じ役割を持つ同じマシンを再起動することだと考えていた。

しかし、オペレーターガイドの中にある1つの注意書きで考え直した。

@Dusk sのインストーラは、コンセンサスキー、チェーン状態、選択したサービス設定を保持します。ですが、rusk.toml、genesis.toml、そしてRuskのsystemdユニットなどのファイルは意図的に再生成します。

さらに重要なのは、オペレーターがノードの既存のネットワークおよび機能フラグを繰り返し指定しなければならないことです。ちょっと待って、利確を予約するね：$CYS

アーカイブのオペレーターが、"--feature archive"なしでインストーラを再実行すると、インストールはデフォルトのRuskバイナリで置き換えられます。マシンは引き続き動作し、ピアに接続してブロック高を進めるかもしれませんが、アプリが依存していたアーカイブ機能は提供されなくなります。

それが引っかかった部分だ。

Duskは、Ruskを停止する前に置き換え用バイナリをダウンロードして検証することで、アップグレードのリスクを減らします。また、オンラインに戻す前にオペレーターが生成された設定を確認できるように、その後サービスを停止したままにします。

しかし、自動化では、どの古いカスタム設定が今も有効なのかを判断できません。Duskは特に、以前のrusk.tomlを比較し、必要な設定だけを再適用するようオペレーターに警告しています。新しい設定に古いファイル全体をそのままコピーしてはいけない、ということです。

つまり、正常にインストールできたことは、復元されたサービスが正しく動作することと同じではありません。

それでは、設定を再生成することでDuskのノードアップグレードはよりクリーンで安全になるのか？ それとも、ノードが意図した役割を維持することが最も重要なオペレーターの確認ポイントなのか？

#dusk @Dusk k $DUSK

Duskノードのアップグレード後に最も重要なのは何？