Cardano-db-sync: 恐慌/回滚的无限循环（NewEpochFailure）

这是主网吗？ 您是否要从一个版本的软件升级到另一个版本？

~错误信息的NewEpochFailure部分提示db-sync版本与node版本不兼容~

6.0.x的db-sync版本与节点的1.21.x兼容。

是的，主网，我建立了一个新的数据库，它现在正在使用相同的版本，所以不确定发生了什么

关闭这个。

我刚刚在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 。 这不太可能是巧合。

该区块很可能是新纪元的第一个区块。

@rhyslbw您正在使用的db-sync版本的 git 哈希是什么？

@mmahut在 #404 中使用的是提交https://github.com/input-output-hk/cardano-db-sync/commit/6187081a7ea66954c86094578bd37e01bca8aaec ，它缺少提交https://github.com/input-output- hk/cardano-db-sync/commit/afe68e08cf5f8b3b1b6690e411670908bc0f5942 ，其中包含对6.0.0标签在第二次提交之后。

在没有修复https://github.com/input-output-hk/cardano-db-sync/issues/256 的情况下进行调试是一项巨大的痛苦。

@erikd我正在使用发布标签提交3e68f3011bb156b9b799ccf056f9a73281479f9c

做了很多工作试图重现这个问题，但它不是确定性的。 我目前正在运行此代码的一个版本，它应该可以更好地捕获任何错误（并立即中止）。 我希望有机会在大约 14 小时后的下一个纪元边界再次触发此事件。

10 个节点，所有节点崩溃。 lstate是：

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具有三个不同的哈希值，这一事实有点出乎意料。

如果原因是账本状态损坏，可能这和 #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 个不同的实例（因为我需要元数据功能）。

十分之二的账本状态文件的版本已损坏（与其他人不同）。 正确的总数是：

/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-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.54 UTC] 数据库提示位于插槽 8092720，块 389107
[db-sync- node:Info :39] [2020-11-19 09:06:15.54 UTC] 运行数据库线程
[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] 删除编号的插槽：[]
````
需要为此检查代码。

我有一个临时的解决方法。 解决方法来自我正在进行的调试分支，但尚未经过全面测试、质量保证或发布。

如果有人正在运行6.0.0版本并且担心在大约 12 小时内发生 epoch 翻转，则有一个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

基本上发生的事情是：

• 块通过链同步到达并被放入队列。
• 回滚命令到达，账本状态的回滚立即完成。
• 从队列的另一端读取块并应用于分类帐状态。
• 新块到达，放入队列，当它到达另一端时，散列不匹配，因为已经应用了一个额外的错误块。

解决方法是将代码移动到从队列的写入端到读取端回滚账本状态。

在https://github.com/input-output-hk/cardano-db-sync/pull/413 中的master 上修复。

还将有6.0.1版本修复此问题。