```
[db-sync- node:Info :64] [2020-11-07 15:28:05.27 UTC] ChainSyncClient starten
[db-sync- node:Info :64] [2020-11-07 15:28:05.31 UTC] Cardano.Db-Tipp befindet sich auf Steckplatz 13132763, Block 4917327
[db-sync- node:Info :69] [2020-11-07 15:28:05.31 UTC] Laufender DB-Thread
[db-sync- node:Info :69] [2020-11-07 15:28:06.16 UTC] Rollback auf Slot 13132763, Hash c19c89792973fe2fff25e5b715e785d549da9647c2f9b7940aefcd29759dcd70
[db-sync- node:Info :69] [2020-11-07 15:28:06.17 UTC] Löschen von Slots nummeriert: []
[db-sync- node:Error :69] [2020-11-07 15:28:08.93 UTC] runDBThread: Panik! applyHeaderTransition fehlgeschlagen: [[NewEpochFailure (EpochFailure (NewPpFailure (UnexpectedDepositPot (Coin 804642000000) (Coin 804640000000)))]]
CallStack (von HasCallStack):
Fehler, aufgerufen unter src/Shelley/Spec/Ledger/API/Validation.hs:92:15 in shelley-spec-ledger-0.1.0.0- inplace:Shelley.Spec.Ledger.API.Validation
[db-sync- node:Error :64] [2020-11-07 15:28:08.93 UTC] ChainSyncWithBlocksPtcl: Panik! applyHeaderTransition fehlgeschlagen: [[NewEpochFailure (EpochFailure (NewPpFailure (UnexpectedDepositPot (Coin 804640000000) (Coin 804640000000))))]]
CallStack (von HasCallStack):
Fehler, aufgerufen unter src/Shelley/Spec/Ledger/API/Validation.hs:92:15 in shelley-spec-ledger-0.1.0.0- inplace:Shelley.Spec.Ledger.API.Validation
[db-sync-node.Subscription :Error :60] [2020-11-07 15:28:08.93 UTC] [String "Application Exception: LocalAddress {getFilePath = \"/opt/cardano/cnode/sockets/node0. socket\"} Panic! applyHeaderTransition failed: [[NewEpochFailure (EpochFailure (NewPpFailure (UnexpectedDepositPot (Coin 80464200000) (Coin 804640000000))))]]\nCallStack (von HasCallStack):\n Fehler, aufgerufen bei src/Shelley/Spec/ Ledger/API/Validation.hs:92:15 in shelley-spec-ledger-0.1.0.0- inplace:Shelley.Spec.Ledger.API.Validation ",String "SubscriptionTrace"]
[db-sync-node.Er rorPolicy:Error :4] [2020-11-07 15:28:08.93 UTC] [String "ErrorPolicyUnhandledApplicationException Panic! applyHeaderTransition failed: [[NewEpochFailure (EpochFailure (NewPpFailure (UnexpectedDepositPot) (Coin 80464200000)) Coin 804640000000)))]]\nCallStack (von HasCallStack):\n Fehler, aufgerufen unter src/Shelley/Spec/Ledger/API/Validation.hs:92:15 in shelley-spec-ledger-0.1.0.0- inplace :Shelley.Spec.Ledger.API.Validation ",String "ErrorPolicyTrace",String "LocalAddress {getFilePath = \"/opt/cardano/cnode/sockets/node0.socket\"}"]
```
Ist das Mainnet? Führen Sie ein Upgrade von einer Version der Software auf eine andere durch?
~Der NewEpochFailure
Teil der Fehlermeldung weist darauf hin, dass die db-sync
Version nicht mit der node
Version kompatibel ist.~
Version 6.0.x
von db-sync
ist mit 1.21.x
des Knotens kompatibel.
Ja, Mainnet, ich habe eine neue DB gebaut und sie funktioniert jetzt mit der gleichen Version, also bin ich mir nicht sicher, was passiert ist
Schließen Sie dies.
Ich habe dies gerade auf dem cardano-graphql
CI-Server erreicht, ohne dass sich das Interesse wie Versionsaktualisierungen geändert hat. Verbindung zum Mainnet mit dieser Konfiguration .
[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\"}"]
~Nachdem ich mit Rhys auf Slack gechattet habe, vermute ich, dass in seinem Fall db-sync
über 1000 Blöcke vor diesem Fehler Probleme hatte und was er sieht, ist das Ergebnis des Neustarts und Rotieren der Protokolle.~
Das Problem tritt beim Epochen-Rollover auf.
Diejenigen, die @rhyslbw und @mmahut erwischt haben, haben beide beim letzten angewendeten Block gekotzt, Hash 5d8ea0d4cf2d4f46cc91aa48e83c029691f836d7200e11e26402f9a2bcb25987
. Dass das kein Zufall ist, ist sehr unwahrscheinlich.
Sehr wahrscheinlich ist dieser Block der erste Block einer neuen Epoche.
@rhyslbw was ist der Git-Hash der db-sync
Version, die Sie verwenden?
Diejenige, die @mmahut in #404 verwendet hat, war der Commit https://github.com/input-output-hk/cardano-db-sync/commit/6187081a7ea66954c86094578bd37e01bca8aaec fehlt der Commit https://github.com/input-output- hk/cardano-db-sync/commit/afe68e08cf5f8b3b1b6690e411670908bc0f5942, das Änderungen an der Ledger-State-Konfiguration enthält. Bei diesem Problem geht es darum, dass der Code im Zusammenhang mit dem Ledger-Status stirbt, aber diese Änderung sollte im Mainnnet keinen Unterschied machen. Das Tag 6.0.0
befindet sich nach dem zweiten Commit.
Das Debuggen ohne Fix für https://github.com/input-output-hk/cardano-db-sync/issues/256 ist ein RIESIGER Schmerz im Nacken.
@erikd Ich verwende das Release-Tag-Commit 3e68f3011bb156b9b799ccf056f9a73281479f9c
Habe viel Arbeit gemacht, um dieses Problem zu reproduzieren, aber es ist nicht deterministisch. Ich führe derzeit eine Version dieses Codes aus, die Fehler besser abfangen (und sofort abbrechen sollte). Ich hoffe, dass es eine Chance gibt, dies an der nächsten Epochengrenze, die in etwa 14 Stunden stattfindet, erneut auszulösen.
10 Knoten, die alle mit diesem speziellen Fehler
65bce9e6463a324d612d24588afbdecc 13996555.lstate
77b5e894f8a22cb49605b9bfd474588a 13996568.lstate
12c4be3b0fac587d1b6485284e218404 13996582.lstate
f0b29f6768c836e7283f7033799ce146 13996626.lstate
ba72f63cf8185150c8120f3466756479 13996646.lstate
a2b45038665701084196a238b3beb329 13996669.lstate
7e8cccd8f0f1c3ac519ef7471a998ac1 13996713.lstate
ab304c279c8209e4b21a623b1a6dd80f 13996756.lstate
und mit git rev 6187081a7ea66954c86094578bd37e01bca8aaec
(das sind ein paar Commits hinter dem 6.0.0
Tag).
Die aktuelle Hypothese ist, dass der Ledger-Zustand irgendwann beschädigt wird und dass die Beschädigung nur an der Epochengrenze bemerkt wird .
Endlosschleife 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
2 von 3 Instanzen haben den NewEpochFailue
Fehler ausgelöst.
Git-Revision 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
Die Snapshots der nicht betroffenen Instanz wurden ausgerollt.
Die Tatsache, dass dieselbe Ledger-Statusdatei, zB 13996756.lstate
drei verschiedene Hashes hat, ist etwas unerwartet.
Wenn die Ursache ein beschädigter Hauptbuchstatus ist, sind dies und #405 wahrscheinlich das gleiche Problem
@SebastienGllmt Ja, das ist möglich, aber ich hatte noch nicht einmal die Gelegenheit, mir #405 anzusehen.
2 von 4 Instanzen abgeworfen
MD5-Prüfsummen einer ausgefallenen Instanz:
189def79f03972649fdcdcd811def1bb 13996555.lstate
dc6865de6149fdf4879a4659bcf02ef0 13996568.lstate
85bf1965fdadee3ee42c10dfd32e0bdb 13996582.lstate
c452477105dc4041c17d718a32f12056 13996626.lstate
9eb0f1fd0a165a8eff3ec4835f370d6d 13996646.lstate
4d5180ba656234020a71f2d46f1d9d0e 13996669.lstate
521ae28570c1630a18bc721cc4707eaa 13996713.lstate
9a2485e192578c1d3c22059648fba79f 13996756.lstate
(die andere fehlgeschlagene Instanz hat andere Hashes)
Gesunde Instanz:
98d46070c972d7b4ec564e4053e29eda 14033709.lstate
5c2443fe558a928a86606136337f3648 14033754.lstate
6c180d350ba7becf0f02d698ac160397 14033800.lstate
d655e560b8a43e064b671266795d262c 14033812.lstate
99bfbf88ec497e7e40865c920f8e8e26 14033839.lstate
bec82d94fe348d843389853cd24a3e5b 14033845.lstate
14faba941a24f02b236d784af85f8d32 14033890.lstate
c96d18f7bdadebed8e3b723b4e6691fc 14033936.lstate
Ich habe versucht, 10 verschiedene Instanzen beim Commit bcd82d0a3eada57fdf7cc71670a46c9b3b80464f
zu synchronisieren (da ich die Metadatenfunktion benötige).
2 von 10 hatten eine beschädigte Version der Ledger-Statusdateien (anders als der Rest). Die richtigen Summen sind:
/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
Ich habe auch eine Inkonsistenz in den Dateien festgestellt. 14040345.lstate
fehlte bei der Hälfte der Instanzen, aber diese Instanzen 14040553.lstate
stattdessen
Zu Ihrer Information, dasselbe Problem noch einmal beim Übergang zur Epoche 230 ...
Okay, ich weiß, was das Problem verursacht. Dies zu beheben ist relativ einfach. Der Fix erfordert keine DB-Neusynchronisierung, es sei denn, der Ledger-Status ist bereits beschädigt (was von der korrigierten Version der Software erkannt wird).
Das Problem ist:
db-sync
bereits vom Node validierte Blöcke bekommt, erschien es sinnvoll, die schnelle Version zu verwenden.@erikd Ist es möglich, dies zu einem Konfigurationswechsel zwischen vollständiger Überprüfung und schneller Überprüfung zu machen? Ich würde es vorziehen, alles im "sicheren" Modus auszuführen und zusätzliche Ressourcen zu verwenden, um sicherzustellen, dass es betriebsbereit bleibt.
@CyberCyclone Sobald der Hash überprüft wurde, kann mit einer höheren Wahrscheinlichkeit als der Wahrscheinlichkeit einer 256-Bit-Hash-Kollision nichts mehr schief gehen. Der Hash hätte überprüft werden sollen. Ich dachte, es wird überprüft. Sobald es überprüft ist, gibt es keinen Grund mehr zu überprüfen.
Super, toll zu hören! Die Art und Weise, wie es formuliert wurde, hörte sich an, als wäre noch viel mehr los. Aber ja, Hash-Kollisionen sind kein Grund zur Sorge.
Da ich die schnelle Version verwende und mein Code auf einen bestimmten Slot zurückrollt, ist es möglich, dass er auf die richtige Slotnummer, aber den falschen Block zurückrollt (dh die Slotnummer korrekt, aber falscher Hash und daher falscher Block).
Es sollte _nicht möglich sein, auf die richtige Slot-Nummer, sondern auf den falschen Block zurückzurollen_.
Die Kettensynchronisierung weist an, zu einem bestimmten Punkt in der Kette zurückzurollen (Punkt ist ein Slot + Hash), aber dieser Punkt ist garantiert in der Kette des Verbrauchers vorhanden. Ja, es ist sehr vernünftig zu überprüfen, aber wenn diese Überprüfung fehlschlägt, deutet dies auf einen Logikfehler hin.
Daher denke ich, dass dies mehr untersucht werden muss, bevor wir es als behoben bezeichnen können. Das Hinzufügen einer Assertion sollte das Problem viel schneller an dem Punkt erkennen, an dem es auftritt, und nicht viel später an der Epochengrenze. Das Hinzufügen einer Assertion ist selbstverständlich keine Lösung.
Es sollte nicht möglich sein, auf die richtige Slot-Nummer, sondern auf den falschen Block zurückzurollen.
Dies ist möglich, wenn beim Rollback nur die Slot-Nummer, nicht aber der Hash überprüft wird.
Die Protokollierung hat nun folgendes ergeben:
[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.
was ein wenig seltsam ist. Ein Neustart führt zu:
```
[db-sync- node:Info :34] [2020-11-19 09:06:15.54 UTC] Datenbank-Tipp befindet sich auf Slot 8092720, Block 389107
[db-sync- node:Info :39] [2020-11-19 09:06:15.54 UTC] Laufender DB-Thread
[db-sync- node:Info :42] [2020-11-19 09:06:15.55 UTC] getHistoryInterpreter: erworben
[db-sync- node:Info :39] [2020-11-19 09:06:15.55 UTC] Rollback auf Slot 8092720,
Hash e1e78605937bb8cfc842d1ee7280b92fa9fce813c26fa66a88eaca74d7af9f05
[db-sync- node:Info :39] [2020-11-19 09:06:15.56 UTC] Löschen von Slots nummeriert: []
````
Dazu muss der Code überprüft werden.
Ich habe einen temporären Work-Around-Fix dafür. Die Problemumgehung stammt aus meinem in Arbeit befindlichen Debugging-Zweig, wurde jedoch nicht vollständig getestet, QAed oder veröffentlicht.
Wenn jemand die Version 6.0.0
ausführt und sich Sorgen macht, dass der Epochen-Rollover in ~12 Stunden stattfindet, gibt es einen erikd/tmp-fix-6.0.x
Zweig (commit 3a6e7199c1f2) mit der Problemumgehung. Die Problemumgehung erkennt, dass etwas fehlschlägt, Panik, die Ausnahme wird auf einer höheren Ebene wiederholt und dann wird db-sync fortgesetzt.
Es gibt keine Datenbankänderungen relativ zu 6.0.0
daher ist keine Neusynchronisierung erforderlich.
Die Ausführung dieser Version kann jedoch einen bereits beschädigten Ledger-Status erkennen (ich bin mir nicht einmal sicher, wie das aussehen würde). In diesem Fall ist eine Neusynchronisierung erforderlich.
Nachdem Sie eine Reihe von Debug-Code hinzugefügt und dann darauf gewartet haben, dass das Problem ausgelöst wird.
Es stellte sich heraus, dass dieses Problem eine Racebedingung ist. Aus den Protokollen:
[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
Grundsätzlich passiert Folgendes:
Die Lösung besteht darin, den Code vom Schreibende der Warteschlange zum Leseende in den Status des Rollback-Ledgers zu verschieben.
Auf Master in https://github.com/input-output-hk/cardano-db-sync/pull/413 behoben .
Es wird auch 6.0.1
Release geben, das dies behebt.
Hilfreichster Kommentar
Okay, ich weiß, was das Problem verursacht. Dies zu beheben ist relativ einfach. Der Fix erfordert keine DB-Neusynchronisierung, es sei denn, der Ledger-Status ist bereits beschädigt (was von der korrigierten Version der Software erkannt wird).
Das Problem ist:
db-sync
bereits vom Node validierte Blöcke bekommt, erschien es sinnvoll, die schnelle Version zu verwenden.