Cardano-db-sync: パニック/ロールバックの無限ループ（NewEpochFailure）

これはメインネットですか？ ソフトウェアのあるバージョンから別のバージョンにアップグレードしていますか？

〜エラーメッセージのNewEpochFailure部分は、 db-syncバージョンがnodeバージョンと互換性がないことを示しています。〜

バージョン6.0.xのdb-syncと互換性があります1.21.xノードの。

はい、メインネット、新しいDBを作成しましたが、同じバージョンで動作しているので、何が起こったのかわかりません

これを閉じます。

cardano-graphql CIサーバーでこれをヒットしたばかりで、バージョンの更新などの関心の変更はありません。 この設定でメインネットに接続します。

[db-sync-node:Error:62741] [2020-11-12 06:02:09.50 UTC] runDBThread: Panic! applyHeaderTransition failed: [[NewEpochFailure (EpochFailure (NewPpFailure (UnexpectedDepositPot (Coin 831366000000) (Coin 831368000000))))]]
CallStack (from HasCallStack):
  error, called at src/Shelley/Spec/Ledger/API/Validation.hs:92:15 in shelley-spec-ledger-0.1.0.0-3QeazRqhkmeDSfJ73hDh1U:Shelley.Spec.Ledger.API.Validation
[db-sync-node:Error:62736] [2020-11-12 06:02:09.50 UTC] ChainSyncWithBlocksPtcl: Panic! applyHeaderTransition failed: [[NewEpochFailure (EpochFailure (NewPpFailure (UnexpectedDepositPot (Coin 831366000000) (Coin 831368000000))))]]
CallStack (from HasCallStack):
  error, called at src/Shelley/Spec/Ledger/API/Validation.hs:92:15 in shelley-spec-ledger-0.1.0.0-3QeazRqhkmeDSfJ73hDh1U:Shelley.Spec.Ledger.API.Validation
[db-sync-node.Subscription:Error:62732] [2020-11-12 06:02:09.50 UTC] [String "Application Exception: LocalAddress {getFilePath = \"/node-ipc/node.socket\"} Panic! applyHeaderTransition failed: [[NewEpochFailure (EpochFailure (NewPpFailure (UnexpectedDepositPot (Coin 831366000000) (Coin 831368000000))))]]\nCallStack (from HasCallStack):\n  error, called at src/Shelley/Spec/Ledger/API/Validation.hs:92:15 in shelley-spec-ledger-0.1.0.0-3QeazRqhkmeDSfJ73hDh1U:Shelley.Spec.Ledger.API.Validation",String "SubscriptionTrace"]
[db-sync-node.ErrorPolicy:Error:4] [2020-11-12 06:02:09.50 UTC] [String "ErrorPolicyUnhandledApplicationException Panic! applyHeaderTransition failed: [[NewEpochFailure (EpochFailure (NewPpFailure (UnexpectedDepositPot (Coin 831366000000) (Coin 831368000000))))]]\nCallStack (from HasCallStack):\n  error, called at src/Shelley/Spec/Ledger/API/Validation.hs:92:15 in shelley-spec-ledger-0.1.0.0-3QeazRqhkmeDSfJ73hDh1U:Shelley.Spec.Ledger.API.Validation",String "ErrorPolicyTrace",String "LocalAddress {getFilePath = \"/node-ipc/node.socket\"}"]
[db-sync-node.Handshake:Info:62759] [2020-11-12 06:02:17.54 UTC] [String "Send (ClientAgency TokPropose,MsgProposeVersions (fromList [(NodeToClientV_1,TInt 764824073),(NodeToClientV_2,TInt 764824073),(NodeToClientV_3,TInt 764824073)]))",String "LocalHandshakeTrace",String "ConnectionId {localAddress = LocalAddress {getFilePath = \"\"}, remoteAddress = LocalAddress {getFilePath = \"/ipc/node.socket\"}}"]
[db-sync-node.Handshake:Info:62759] [2020-11-12 06:02:17.54 UTC] [String "Recv (ServerAgency TokConfirm,MsgAcceptVersion NodeToClientV_3 (TInt 764824073))",String "LocalHandshakeTrace",String "ConnectionId {localAddress = LocalAddress {getFilePath = \"\"}, remoteAddress = LocalAddress {getFilePath = \"/ipc/node.socket\"}}"]
[db-sync-node:Info:62763] [2020-11-12 06:02:17.54 UTC] Starting chainSyncClient
[db-sync-node:Info:62763] [2020-11-12 06:02:17.55 UTC] Cardano.Db tip is at slot 13564796, block 4938498
[db-sync-node:Info:62768] [2020-11-12 06:02:17.55 UTC] Running DB thread
[db-sync-node:Info:62768] [2020-11-12 06:02:18.01 UTC] Rolling back to slot 13564796, hash 5d8ea0d4cf2d4f46cc91aa48e83c029691f836d7200e11e26402f9a2bcb25987
[db-sync-node:Info:62768] [2020-11-12 06:02:18.01 UTC] Deleting slots numbered: []
[db-sync-node:Error:62768] [2020-11-12 06:02:19.47 UTC] runDBThread: Panic! applyHeaderTransition failed: [[NewEpochFailure (EpochFailure (NewPpFailure (UnexpectedDepositPot (Coin 831366000000) (Coin 831368000000))))]]
CallStack (from HasCallStack):
  error, called at src/Shelley/Spec/Ledger/API/Validation.hs:92:15 in shelley-spec-ledger-0.1.0.0-3QeazRqhkmeDSfJ73hDh1U:Shelley.Spec.Ledger.API.Validation
[db-sync-node:Error:62763] [2020-11-12 06:02:19.47 UTC] ChainSyncWithBlocksPtcl: Panic! applyHeaderTransition failed: [[NewEpochFailure (EpochFailure (NewPpFailure (UnexpectedDepositPot (Coin 831366000000) (Coin 831368000000))))]]
CallStack (from HasCallStack):
  error, called at src/Shelley/Spec/Ledger/API/Validation.hs:92:15 in shelley-spec-ledger-0.1.0.0-3QeazRqhkmeDSfJ73hDh1U:Shelley.Spec.Ledger.API.Validation
[db-sync-node.Subscription:Error:62759] [2020-11-12 06:02:19.47 UTC] [String "Application Exception: LocalAddress {getFilePath = \"/node-ipc/node.socket\"} Panic! applyHeaderTransition failed: [[NewEpochFailure (EpochFailure (NewPpFailure (UnexpectedDepositPot (Coin 831366000000) (Coin 831368000000))))]]\nCallStack (from HasCallStack):\n  error, called at src/Shelley/Spec/Ledger/API/Validation.hs:92:15 in shelley-spec-ledger-0.1.0.0-3QeazRqhkmeDSfJ73hDh1U:Shelley.Spec.Ledger.API.Validation",String "SubscriptionTrace"]
[db-sync-node.ErrorPolicy:Error:4] [2020-11-12 06:02:19.47 UTC] [String "ErrorPolicyUnhandledApplicationException Panic! applyHeaderTransition failed: [[NewEpochFailure (EpochFailure (NewPpFailure (UnexpectedDepositPot (Coin 831366000000) (Coin 831368000000))))]]\nCallStack (from HasCallStack):\n  error, called at src/Shelley/Spec/Ledger/API/Validation.hs:92:15 in shelley-spec-ledger-0.1.0.0-3QeazRqhkmeDSfJ73hDh1U:Shelley.Spec.Ledger.API.Validation",String "ErrorPolicyTrace",String "LocalAddress {getFilePath = \"/node-ipc/node.socket\"}"]

〜SlackでRhysとチャットした後、彼の場合、 db-syncがこのエラーの前に1000ブロックを超える問題に遭遇し、彼が見ているのはログを再起動してローテーションした結果だと思います。〜

問題はエポックロールオーバーで発生します。

@rhyslbwと@mmahutは、最後に適用された同じブロック、ハッシュ5d8ea0d4cf2d4f46cc91aa48e83c029691f836d7200e11e26402f9a2bcb25987両方ともbarfedをキャッチしました。 それが偶然である可能性は非常に低いです。

そのブロックは、新しいエポックの最初のブロックである可能性が非常に高いです。

@rhyslbw使用しているdb-syncバージョンのgitハッシュは何ですか？

@mmahutが＃404で使用していたのはコミットhttps://github.com/input-output-hk/cardano-db-sync/commit/6187081a7ea66954c86094578bd37e01bca8aaecでしたが、コミット。 hk / cardano-db-sync / commit / afe68e08cf5f8b3b1b6690e411670908bc0f5942には、元帳状態の構成への変更が含まれています。 この問題は、元帳の状態に関連するコードで死ぬことに関するものですが、その変更によってmainnnetに違いが生じることはありません。 6.0.0タグは、2回目のコミットの後にあります。

これは、の修正なしでのデバッグに首の巨大な痛みですhttps://github.com/input-output-hk/cardano-db-sync/issues/256 。

@erikdリリースタグを使用しています3e68f3011bb156b9b799ccf056f9a73281479f9c

この問題を再現しようと多くの作業を行いましたが、決定論的ではあり

10ノード、それらすべてがこの特定のバグで

65bce9e6463a324d612d24588afbdecc  13996555.lstate
77b5e894f8a22cb49605b9bfd474588a  13996568.lstate
12c4be3b0fac587d1b6485284e218404  13996582.lstate
f0b29f6768c836e7283f7033799ce146  13996626.lstate
ba72f63cf8185150c8120f3466756479  13996646.lstate
a2b45038665701084196a238b3beb329  13996669.lstate
7e8cccd8f0f1c3ac519ef7471a998ac1  13996713.lstate
ab304c279c8209e4b21a623b1a6dd80f  13996756.lstate

git rev 6187081a7ea66954c86094578bd37e01bca8aaec （これは6.0.0タグの背後にあるいくつかのコミットです）。

現在の仮説は、元帳の状態はある時点で破損し、破損はエポック境界でのみ認識されるというものです。

無限ループNewEpochFailue

99d3e16a319a20ff689ca9582425ddae  13996555.lstate
8205deb9c2b3ad946a99bc7692d4434e  13996568.lstate
8eeb20d372cf5214db7c8287a052707b  13996582.lstate
7133fb72aa8194efa80e95c3fa4af1fb  13996626.lstate
f7199d4a131c6fd4649a76a51167275f  13996646.lstate
faa8d71771e8cc68703fa4f1f08dfce7  13996669.lstate
f6cbf62dad57439dc126f8b56061a863  13996713.lstate
504ea06cb925868c25c100d7d05d6afd  13996756.lstate

cardano-db-sync-extended 6.0.0 - linux-x86_64 - ghc-8.6
git revision 3e68f3011bb156b9b799ccf056f9a73281479f9c

3つのインスタンスのうち2つがNewEpochFailueエラーをスローしました。
gitリビジョン3e68f3011bb156b9b799ccf056f9a73281479f9c

0eb144b880dcb07c8347b560ea77db27  13996555.lstate
6ee65fc1f5d47fbb858e92770e109f0f  13996568.lstate
c526b055c731173bb7a94cbf3144855d  13996582.lstate
932f8a4807537c43332a4b9a91c0c4a7  13996626.lstate
95163e7b5351b04ae5909d221a4ee2e2  13996646.lstate
c584485911b8f246d01e37572b0f4175  13996669.lstate
449a7c5b2669288dfec995867507211a  13996713.lstate
ba8c8f7f1657727c826ca07be4f7d2e2  13996756.lstate

影響を受けていないインスタンスのスナップショットがロールアウトされました。

同じ元帳状態ファイル、たとえば13996756.lstateに3つの異なるハッシュがあるという事実は、少し予想外です。

原因が破損した元帳の状態である場合、おそらくこれと＃405は同じ問題です

@SebastienGllmtはい、それは可能ですが、私はまだ＃405を見る機会さえありませんでした。

スローされた4つのインスタンスのうち2つ
失敗したインスタンスのMD5チェックサム：

189def79f03972649fdcdcd811def1bb  13996555.lstate
dc6865de6149fdf4879a4659bcf02ef0  13996568.lstate
85bf1965fdadee3ee42c10dfd32e0bdb  13996582.lstate
c452477105dc4041c17d718a32f12056  13996626.lstate
9eb0f1fd0a165a8eff3ec4835f370d6d  13996646.lstate
4d5180ba656234020a71f2d46f1d9d0e  13996669.lstate
521ae28570c1630a18bc721cc4707eaa  13996713.lstate
9a2485e192578c1d3c22059648fba79f  13996756.lstate

（他の失敗したインスタンスは異なるハッシュを持っています）

健全なインスタンス：

98d46070c972d7b4ec564e4053e29eda  14033709.lstate
5c2443fe558a928a86606136337f3648  14033754.lstate
6c180d350ba7becf0f02d698ac160397  14033800.lstate
d655e560b8a43e064b671266795d262c  14033812.lstate
99bfbf88ec497e7e40865c920f8e8e26  14033839.lstate
bec82d94fe348d843389853cd24a3e5b  14033845.lstate
14faba941a24f02b236d784af85f8d32  14033890.lstate
c96d18f7bdadebed8e3b723b4e6691fc  14033936.lstate

コミットbcd82d0a3eada57fdf7cc71670a46c9b3b80464f 10個の異なるインスタンスを再同期しようとしました（メタデータ機能が必要なため）。

10人中2人は、元帳状態ファイルのバージョンが破損していました（他のファイルとは異なります）。 正しい合計は次のとおりです。

/var/lib/csyncdb/14040345.lstate | b1df6bdb2cf6f798d9baf83373a4698f
/var/lib/csyncdb/14040390.lstate | 5694a00b12b47052125178175289ba24
/var/lib/csyncdb/14040394.lstate | b45a5e4b82362def92225a3eec5d1afb
/var/lib/csyncdb/14040412.lstate | 8319589d1b66dffd97f5233c3dcfddd0
/var/lib/csyncdb/14040436.lstate | 9d0fec3f4693bd78f426c34c5aaa5d5d
/var/lib/csyncdb/14040462.lstate | 8afe16d592a57ed5ef79a27adf0803d9
/var/lib/csyncdb/14040481.lstate | bcc2648eb09b0d5503f6397569b33e67
/var/lib/csyncdb/14040527.lstate | 588d787363bfe02cf0fd34ac8f412dd4
/var/lib/csyncdb/14040553.lstate | e1f2f42a1ac49d2ec3a53351d1b267b5

また、ファイルに不整合があることに気づきました。 14040345.lstateはインスタンスの半分で欠落していましたが、これらのインスタンスには代わりに14040553.lstateました。

参考までに、エポック230の移行についても同じ問題が発生します...

わかりました、問題の原因はわかっています。 これを修正するのは比較的簡単です。 元帳の状態がすでに破損していない限り、修正ではdbの再同期は必要ありません（ソフトウェアの修正バージョンによって検出されます）。

問題は：

• ブロックを元帳状態に適用する関数には2つのバージョンがあります。 完全なチェックを行う遅いものと、少ないチェックを行う速いもの。
• db-syncは、ノードによってすでに検証されているブロックを取得しているため、高速バージョンを使用するのが賢明であるように思われました。
• 高速バージョンのチェックには、ブロックの前のハッシュが元帳状態のヘッドハッシュの値と一致することのチェックが含まれていると言われていましたが、このハッシュチェックは実行されていませんでした。
• このプロトコルでは、複数のスロットリーダーが特定のスロットのブロックを作成できる場合があり、それらが生成するブロックのハッシュは異なります（つまり、ブロックにはスロットリーダーに固有のデータが含まれます）。
• 高速バージョンを使用していて、コードが指定されたスロットにロールバックするため、正しいスロット番号にロールバックする可能性がありますが、ブロックが間違っています（つまり、スロット番号は正しいが、ハッシュが間違っているため、ブロックが間違っています）。
• 現在ロールフォワードしている場合、ハッシュチェックがないということは、次のエポックが始まるまで問題が検出されないことを意味します。

@erikdこれを完全チェックと高速チェックの間で設定を切り替えることは可能ですか？ すべてを「セーフ」モードで実行し、追加のリソースを使用して、それが稼働していることを確認したいと思います。

@Cyber​​Cycloneハッシュがチェックされると、256ビットのハッシュ衝突の可能性よりも確率大きいと間違って行くことができる他には何もありません。 ハッシュがチェックされているはずです。 チェックされていると思いました。 一度チェックすると、それ以上チェックする理由はありません。

素晴らしい、聞いて素晴らしい！ それが表現された方法は、もっとたくさんのことが起こっているように聞こえました。 しかし、ええ、ハッシュの衝突は心配する必要はありません。

高速バージョンを使用していて、コードが指定されたスロットにロールバックするため、正しいスロット番号にロールバックする可能性がありますが、ブロックが間違っています（つまり、スロット番号は正しいが、ハッシュが間違っているため、ブロックが間違っています）。

_正しいスロット番号にロールバックすることはできませんが、ブロックが間違っています_。

チェーン同期は、チェーン上の指定されたポイント（ポイントはスロット+ハッシュ）にロールバックするように指示しますが、このポイントはコンシューマーのチェーン上に存在することが保証されています。 はい、チェックするのは非常に賢明ですが、このチェックが失敗した場合は、どこかにロジックバグがあることを示しています。

したがって、これを修正済みと呼ぶには、さらに調査が必要だと思います。 アサーションを追加すると、エポック境界で問題が発生した後ではなく、問題が発生した時点で問題をより迅速に検出できるはずです。 もちろん、アサーションの追加自体は修正ではありません。

正しいスロット番号にロールバックすることはできませんが、ブロックが間違っています。

ロールバックがスロット番号のみをチェックし、ハッシュはチェックしない場合は可能です。

ロギングにより、これが生成されました。

[db-sync-node:Info:39] [2020-11-19 08:47:21.84 UTC] Rolling back to slot 8092720, 
        hash e1e78605937bb8cfc842d1ee7280b92fa9fce813c26fa66a88eaca74d7af9f05
[db-sync-node:Info:39] [2020-11-19 08:47:21.84 UTC] Deleting slots numbered: [8092760]
Ledger state hash mismatch. Ledger expects 6f1940937d806865a6e96b25a640deb8c1393852fd3d311dbd648e2bfa89056e
        but block provides e1e78605937bb8cfc842d1ee7280b92fa9fce813c26fa66a88eaca74d7af9f05. 

これは少し奇妙です。 再起動すると、次のようになります。
`` `
[db-sync- node：Info ：34] [2020-11-19 09：06：15.54UTC]データベースのヒントはスロット8092720、ブロック389107にあります
[db-sync- node：Info ：39] [2020-11-19 09：06：15.54 UTC] DBスレッドを実行しています
[db-sync- node：Info ：42] [2020-11-19 09：06：15.55 UTC] getHistoryInterpreter：取得しました
[db-sync- node：Info ：39] [2020-11-19 09：06：15.55 UTC]スロット8092720にロールバックし、
ハッシュe1e78605937bb8cfc842d1ee7280b92fa9fce813c26fa66a88eaca74d7af9f05
[db-sync- node：Info ：39] [2020-11-19 09：06：15.56 UTC]番号付きスロットの削除：[]
「」
このためのコードを確認する必要があります。

私はこれを修正するための一時的な回避策を持っています。 回避策は、進行中のデバッグブランチからのものですが、完全にテスト、QA、またはリリースされていません。

誰かが6.0.0リリースを実行していて、エポックロールオーバーが約12時間で発生することを心配している場合は、回避策を備えたerikd/tmp-fix-6.0.xブランチ（コミット3a6e7199c1f2）があります。 回避策は、何かが間違っていることを検出し、パニックに陥り、実行がより高いレベルで再試行されてから、db-syncが続行されます。

6.0.0関連するデータベースの変更はないため、再同期は必要ありません。

ただし、このバージョンを実行すると、すでに破損している元帳の状態が検出される場合があります（どのようになるかはわかりません）。その場合、再同期が必要になります。

一連のデバッグコードを追加し、問題がトリガーされるのを待った後。

この問題は競合状態であることが判明しました。 ログから：

[2020-11-21 08:27:09.90 UTC] insertShelleyBlock: epoch 230, slot 14380936, block 4978632,
    hash f984eead753a149efad752dd58471d0c53c3fcf973d281acf4fdcbc6fda799c7
[2020-11-21 08:27:34.22 UTC] insertShelleyBlock: epoch 230, slot 14380962, block 4978633,
    hash bfe35e62b322d397fa6c5080ccd8294c0d2eaca5695e604df59f27f82292227a
[2020-11-21 08:27:36.69 UTC] loadLedgerState: slot 14380962
    hash bfe35e62b322d397fa6c5080ccd8294c0d2eaca5695e604df59f27f82292227a
[2020-11-21 08:27:37.15 UTC] insertShelleyBlock: epoch 230, slot 14380964, block 4978634,
    hash 1ef4771244b95d35c59371521d19fc145646f89f28bf7a18c4f6c8d7485da2b3
[2020-11-21 08:27:40.01 UTC] Rolling back to slot 14380962,
    hash bfe35e62b322d397fa6c5080ccd8294c0d2eaca5695e604df59f27f82292227a
[2020-11-21 08:27:40.02 UTC] Deleting slots numbered: [14380964]
[2020-11-21 08:27:40.35 UTC] ChainSyncWithBlocksPtcl: FatalError {fatalErrorMessage = "Ledger state hash
    mismatch. Ledger head is slot 14380964 hash
    1ef4771244b95d35c59371521d19fc145646f89f28bf7a18c4f6c8d7485da2b3 but block previous hash is 
    bfe35e62b322d397fa6c5080ccd8294c0d2eaca5695e604df59f27f82292227a and block current
    hash is 136956bd1c6ce536e3c3bb0cef07b3e380441522317c88274f1455a7b11ca2d5."}
[2020-11-21 08:27:41.35 UTC] Starting chainSyncClient
[2020-11-21 08:27:41.36 UTC] Database tip is at slot 14380962, block 4978633
[2020-11-21 08:27:41.36 UTC] Running DB thread
[2020-11-21 08:27:41.54 UTC] Rolling back to slot 14380962,
    hash bfe35e62b322d397fa6c5080ccd8294c0d2eaca5695e604df59f27f82292227a
[2020-11-21 08:27:41.54 UTC] Deleting slots numbered: []
[2020-11-21 08:27:42.54 UTC] loadLedgerState: slot 14380962
    hash bfe35e62b322d397fa6c5080ccd8294c0d2eaca5695e604df59f27f82292227a

基本的に何が起こるかです：

• ブロックはchainsyncを介して到着し、キューに入れられます。
• ロールバックコマンドが到着し、元帳状態でのロールバックがすぐに実行されます。
• ブロックはキューのもう一方の端から読み取られ、元帳の状態に適用されます。
• 新しいブロックが到着し、キューに入れられます。もう一方の端に到着すると、余分な間違ったブロックがすでに適用されているため、ハッシュが一致しません。

修正は、コードをキューの書き込み側から読み取り側にロールバック元帳状態に移動することです。

https://github.com/input-output-hk/cardano-db-sync/pull/413のマスターで修正されました。

これを修正する6.0.1リリースもあります。