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 경우

문제는 Epoch 롤오버에서 발생합니다.

@rhyslbw 와 @mmahut 은 모두 동일한 마지막 적용된 블록인 hash 5d8ea0d4cf2d4f46cc91aa48e83c029691f836d7200e11e26402f9a2bcb25987 barfed를 잡았습니다. 그것은 우연의 일치일 가능성이 매우 낮습니다.

해당 블록이 새로운 시대의 첫 번째 블록일 가능성이 높습니다.

@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개의 노드, 모두 이 특정 버그로 인해

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 오류가 발생했습니다.
자식 수정 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 가 있습니다.

참고로, Epoch 230 전환에서 동일한 문제가 다시 발생합니다.

알겠습니다. 문제의 원인을 알고 있습니다. 이것을 고치는 것은 비교적 간단합니다. 원장 상태가 이미 손상되지 않은 한 수정 프로그램에는 db 재동기화가 필요하지 않습니다(소프트웨어의 고정 버전에서 감지됨).

문제는:

• 블록을 원장 상태에 적용하는 두 가지 버전의 함수가 있습니다. 전체 검사를 수행하는 느린 것과 더 적은 검사를 수행하는 빠른 것.
• db-sync 는 이미 노드에 의해 검증된 블록을 가져오기 때문에 빠른 버전을 사용하는 것이 현명해 보였습니다.
• 빠른 버전의 검사에는 블록의 이전 해시가 원장 상태의 헤드 해시 값과 일치하는지 확인하는 것이 포함되어 있다고 들었지만 이 해시 검사는 수행 되지 않았습니다.
• 프로토콜은 때때로 둘 이상의 슬롯 리더가 특정 슬롯에 대한 블록을 생성하도록 허용하고 그들이 생성하는 블록은 다른 해시를 갖습니다(즉, 블록에는 슬롯 리더에 특정한 데이터가 포함됨).
• 빠른 버전을 사용 중이고 코드가 지정된 슬롯으로 롤백되기 때문에 올바른 슬롯 번호로 롤백할 수 있지만 잘못된 블록(예: 슬롯 번호는 정확하지만 잘못된 해시로 인해 잘못된 블록)으로 롤백할 수 있습니다.
• 이제 롤포워드할 때 해시 검사가 없다는 것은 다음 에포크가 시작될 때까지 문제가 감지되지 않는다는 것을 의미합니다.

@erikd 전체 검사와 빠른 검사 사이에서 구성을 토글하도록 할 수 있습니까? 모든 것을 "안전" 모드로 실행하고 추가 리소스를 사용하여 계속 작동하는지 확인하고 싶습니다.

@CyberCyclone 해시가 확인되면 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 쓰레드 실행 중
[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 릴리스도 있습니다.