Cardano-db-sync: Бесконечный цикл паники / отката (NewEpochFailure)

Это основная сеть? Вы переходите с одной версии программного обеспечения на другую?

~ Часть сообщения об ошибке NewEpochFailure предполагает, что версия db-sync несовместима с версией node . ~

Версия 6.0.x из db-sync совместима с 1.21.x узла.

да, основная сеть, я построил новую БД, и теперь она работает с той же версией, поэтому не уверен, что произошло

Закрытие этого.

Я только что нажал это на сервере cardano-graphql CI, без каких-либо изменений интереса, таких как обновления версий. Подключение к mainnet с этой конфигурацией .

[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, я подозреваю, что в его случае db-sync столкнулся с проблемами за 1000 блоков до этой ошибки, и то, что он видит, является результатом его перезапуска и ротации журналов. ~

Проблема возникает при смене эпох.

Те, кто @rhyslbw и @mmahut поймали оба barfed на одном и том же последнем примененном блоке, hash 5d8ea0d4cf2d4f46cc91aa48e83c029691f836d7200e11e26402f9a2bcb25987 . Маловероятно, что это совпадение.

Весьма вероятно, что этот блок - первый блок новой эпохи.

@rhyslbw какой хеш git у используемой вами версии db-sync ?

Тот, который @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 Я использую тег выпуска commit 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

2 из 3 экземпляров выдали ошибку 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.

2 раза из 4 сброшены
Контрольные суммы 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

Я попытался повторно синхронизировать 10 разных экземпляров при фиксации bcd82d0a3eada57fdf7cc71670a46c9b3b80464f (так как мне нужна функция метаданных).

2 из 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 Можно ли сделать в этой конфигурации переключение между полной проверкой и быстрой проверкой? Я бы предпочел запускать все в «безопасном» режиме и использовать дополнительные ресурсы, чтобы убедиться, что все работает.

@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: Информация : 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: Информация : 39] [2020-11-19 09: 06: 15.56 UTC] Удаление пронумерованных слотов: []
`` ''
Для этого нужно проверить код.

У меня есть временное решение для этого. Обходной путь исходит из моей незавершенной отладочной ветки, но не был полностью протестирован, QAed или выпущен.

Если кто-то использует выпуск 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

В основном происходит следующее:

• Блок прибывает через цепную синхронизацию и помещается в очередь.
• Приходит команда отката, и откат состояния реестра выполняется немедленно.
• Блок считывается с другого конца очереди и применяется к состоянию реестра.
• Приходит новый блок, помещается в очередь, и когда он поступает на другой конец, хэши не совпадают, потому что уже был применен дополнительный, неправильный блок.

Исправление состоит в том, чтобы переместить код в состояние реестра отката из конца записи очереди в конец чтения.

Исправлено на мастере в https://github.com/input-output-hk/cardano-db-sync/pull/413 .

Также будет выпуск 6.0.1 исправляющий это.