Cardano-db-sync: Erreur aléatoire « échec de la recherche de base de données dans insertABlock »

Créé le 28 sept. 2020  ·  6Commentaires  ·  Source: input-output-hk/cardano-db-sync

Comme demandé par @erikd sur cet autre problème , je rouvre ce nouveau problème car j'ai été touché par cela dans la dernière version 5.0.1 empaquetée dans l'image officielle hub.docker.com ( inputoutput/cardano-db-sync:5.0.1 [0]).
Je dois dire que le problème n'est plus réapparu depuis le crash de ces journaux [1][2].

Je pense que cela pourrait être causé par un problème de connectivité postgresql , mais de toute façon, à mon humble avis, dans le pire des cas, le processus principal devrait exit >0 (car il ne récupère pas automatiquement de l'arrêt du thread db) ou db thread doit être redémarré lorsque ces exceptions sont levées.

[0] inputoutput/cardano-db-sync<strong i="15">@sha256</strong>:b09f440d868749135e74c0bfe6154f210d5836bc2d24a44e484c7dbb4b837689
[1]

[db-sync-node:Info:3354] [2020-09-26 04:29:44.87 UTC] insertByronBlock: slot 3025000, block 3023467, hash 43b510c9fa0d1021d4efbfb0a07c1e90f40258c05d7d66b266aee4fb9963f678
[db-sync-node:Error:3354] [2020-09-26 04:29:59.56 UTC] DB lookup fail in insertABlock: block hash f8452c44591e3db7d5534ceaaff56922609d81deed45b953e7220601bfd4ec87
[db-sync-node:Info:3354] [2020-09-26 04:29:59.56 UTC] Shutting down DB thread
[db-sync-node:Error:3357] [2020-09-26 04:29:59.56 UTC] recvMsgRollForward: AsyncCancelled
...
FROZEN FOREVER
...

[2]

Generating PGPASS file
Connecting to network: mainnet
[db-sync-node:Info:4] [2020-09-26 09:01:38.91 UTC] NetworkMagic: 764824073
[db-sync-node:Info:4] [2020-09-26 09:02:11.59 UTC] Initial genesis distribution present and correct
[db-sync-node:Info:4] [2020-09-26 09:02:11.59 UTC] Total genesis supply of Ada: 31112484745.000000
[db-sync-node:Info:4] [2020-09-26 09:02:11.69 UTC] Inserting Shelley Genesis distribution
[db-sync-node:Info:4] [2020-09-26 09:02:11.83 UTC] epochPluginOnStartup: Checking
[db-sync-node:Info:4] [2020-09-26 09:02:11.86 UTC] localInitiatorNetworkApplication: connecting to node via "/node-ipc/node.socket"
[db-sync-node.Handshake:Info:30] [2020-09-26 09:02:11.86 UTC] [String "Send 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:30] [2020-09-26 09:02:11.87 UTC] [String "Recv MsgAcceptVersion NodeToClientV_3 (TInt 764824073)",String "LocalHandshakeTrace",String "ConnectionId {localAddress = LocalAddress {getFilePath = \"\"}, remoteAddress = LocalAddress {getFilePath = \"/ipc/node.socket\"}}"]
[db-sync-node:Info:34] [2020-09-26 09:02:11.87 UTC] Starting chainSyncClient
[db-sync-node:Info:34] [2020-09-26 09:02:13.97 UTC] Cardano.Db tip is at slot 3025325, block 3023792
[db-sync-node:Info:39] [2020-09-26 09:02:13.97 UTC] Running DB thread
[db-sync-node:Info:39] [2020-09-26 09:02:14.45 UTC] Rolling back to slot 3025325, hash f8452c44591e3db7d5534ceaaff56922609d81deed45b953e7220601bfd4ec87
[db-sync-node:Info:39] [2020-09-26 09:02:14.46 UTC] Deleting blocks numbered: []
[db-sync-node:Info:42] [2020-09-26 09:02:14.58 UTC] getHistoryInterpreter: acquired
[db-sync-node:Error:39] [2020-09-26 09:02:42.88 UTC] DB lookup fail in insertABlock: block hash ff6d511e65fb979ac511e8658c20cfe608bdfe7d3e6172f49115e52487812423
[db-sync-node:Info:39] [2020-09-26 09:02:42.88 UTC] Shutting down DB thread
[db-sync-node:Error:42] [2020-09-26 09:02:42.89 UTC] recvMsgRollForward: AsyncCancelled
...
FROZEN FOREVER
...

Tous les 6 commentaires

J'ai vu

DB lookup fail in insertABlock: block hash

avant, mais l'un était dû au manque d'espace disque de postgres et les autres après que j'ai effectué des manipulations potentiellement dangereuses de la base de données pendant les tests.

Quant à la partie FROZEN FOREVER , ce n'est pas quelque chose sur laquelle j'ai un contrôle direct. Mon code appelle le code réseau qui exécute le protocole ChainSync, qui rappelle ensuite un autre morceau de mon code. Dans ce cas, mon code interne a lancé une exception qui a été interceptée par le code réseau et non propagée dans mon code. Il peut y avoir un correctif pour cela, mais il est peu probable que ce soit simple.

Ma suggestion est :

  • Assurez-vous que la machine dispose de suffisamment d'espace disque (entièrement synchronisée à l'époque 220, mon instance db-sync utilise 6 Go de disque).
  • Supprimez et recréez la base de données (pour vous assurer que la corruption existante est supprimée).
  • Surveillez manuellement la synchronisation (cela devrait durer jusqu'à 3 heures environ).

Désolé, j'ai oublié de mentionner que cela ne s'est plus produit depuis ce temps à partir des journaux ci-joints ; c'est pourquoi j'ai supposé que cela aurait pu être un problème exceptionnel avec mon instance postgres (je jouais avec HA à l'époque IIRC).

Nous pouvons garder cela ouvert pendant un certain temps pour voir si nous trouvons des indices plus utiles.

JFTR, je resynchronise le réseau principal à partir de zéro et j'ai constaté qu'il récupère en fait après un long moment (au moins sur la dernière version) et que cela est probablement dû à une indisponibilité de cardano-node socket [0].
Ce dernier problème est dû au fait que je partage le socket via TCP, il est donc accessible à différents services exécutés à partir de différents pods k8s (pas d'ipc partagé), et j'obtiens des instabilités (je ne sais pas encore d'où elles viennent exactement, je dois faire plus de réglage TCP) .

[0]

[db-sync-node:Info:217] [2020-10-20 08:09:02.03 UTC] epochPluginInsertBlock: epoch 182
[db-sync-node:Info:217] [2020-10-20 08:11:01.01 UTC] insertByronBlock: slot 3955000, block 3952915, hash d5941f934cf5eb5c3105b584c07aa6c872272dbd0d4fbe78efb36682ed59f211
[db-sync-node:Info:217] [2020-10-20 08:15:22.01 UTC] insertByronBlock: slot 3960000, block 3957915, hash 92494b54140f9db989618f93f11be579b1112d66c173d09cdfb5ac8f9ae6d9ce
[db-sync-node:Error:217] [2020-10-20 08:15:54.86 UTC] DB lookup fail in insertABlock: block hash 55f53f6ddf3546aa29079945eb995244c4a5a205bb287ca76c89a85e2f60ef6d
[db-sync-node:Info:217] [2020-10-20 08:15:54.86 UTC] Shutting down DB thread
[db-sync-node:Error:220] [2020-10-20 08:15:54.86 UTC] recvMsgRollForward: AsyncCancelled
[db-sync-node:Error:211] [2020-10-20 08:34:04.83 UTC] ChainSyncWithBlocksPtcl: AsyncCancelled
[db-sync-node.Subscription:Error:207] [2020-10-20 08:34:04.83 UTC] [String "Application Exception: LocalAddress {getFilePath = \"/node-ipc/node.socket\"} MuxError MuxBearerClosed \"<socket: 12> closed when reading data, waiting on next header True\"",String "SubscriptionTrace"]
[db-sync-node.ErrorPolicy:Warning:4] [2020-10-20 08:34:04.83 UTC] [String "ErrorPolicySuspendPeer (Just (ApplicationExceptionTrace (MuxError MuxBearerClosed \"<socket: 12> closed when reading data, waiting on next header True\"))) 20s 20s",String "ErrorPolicyTrace",String "LocalAddress {getFilePath = \"/node-ipc/node.socket\"}"]
[db-sync-node.Handshake:Info:1879] [2020-10-20 08:34:05.83 UTC] [String "Send 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:1879] [2020-10-20 08:34:05.85 UTC] [String "Recv MsgAcceptVersion NodeToClientV_3 (TInt 764824073)",String "LocalHandshakeTrace",String "ConnectionId {localAddress = LocalAddress {getFilePath = \"\"}, remoteAddress = LocalAddress {getFilePath = \"/ipc/node.socket\"}}"]
[db-sync-node:Info:1883] [2020-10-20 08:34:05.85 UTC] Starting chainSyncClient
[db-sync-node:Info:1883] [2020-10-20 08:34:07.63 UTC] Cardano.Db tip is at slot 3960564, block 3958479
[db-sync-node:Info:1889] [2020-10-20 08:34:07.63 UTC] Running DB thread
[db-sync-node:Info:1889] [2020-10-20 08:34:08.16 UTC] Rolling back to slot 3960564, hash 55f53f6ddf3546aa29079945eb995244c4a5a205bb287ca76c89a85e2f60ef6d
[db-sync-node:Info:1889] [2020-10-20 08:34:08.17 UTC] Deleting blocks numbered: []
[db-sync-node:Info:1889] [2020-10-20 08:37:42.51 UTC] insertByronBlock: slot 3965000, block 3962915, hash c1fa47cd48391aa3774e61c8830b5d1e8bbf62c4720b856a952fdd6d95dcd5e6
[db-sync-node:Info:1889] [2020-10-20 08:41:59.70 UTC] insertByronBlock: slot 3970000, block 3967915, hash 71dcc988afa8fbf6e2f5c88b165f7ee7dbbe8a1a07141df8a5f2c42986494528
[db-sync-node:Info:1889] [2020-10-20 08:46:19.05 UTC] epochPluginInsertBlock: epoch 183
[db-sync-node:Info:1889] [2020-10-20 08:46:43.59 UTC] insertByronBlock: slot 3975000, block 3972915, hash 9be00c8a13eeaa21b24b070fe9254c6b30c3e1953e8625604c86e8c8d5695213
[db-sync-node:Info:1889] [2020-10-20 08:51:42.20 UTC] insertByronBlock: slot 3980000, block 3977915, hash ec3903b66e2a7638315e9d4b9a19ed904b71eae3e5e4cdd412a9b8ed5875b970
[db-sync-node:Info:1889] [2020-10-20 08:57:17.01 UTC] insertByronBlock: slot 3985000, block 3982915, hash 527077e870a8fa8648fb035107c906cc72e3ea2438a674020dc472ec9e2b8d50
[db-sync-node:Info:1889] [2020-10-20 09:01:33.12 UTC] insertByronBlock: slot 3990000, block 3987915, hash 2d6ed2788d5a694d05866d5c08002e46b9e119cab71c2e56d5b76432f37b8eda
[db-sync-node:Info:1889] [2020-10-20 09:05:17.18 UTC] insertByronBlock: slot 3995000, block 3992915, hash e043d137b267ed16b73b41cb92889b37cad381c53c80390598b547dc9fc58892
[db-sync-node:Info:1889] [2020-10-20 09:06:00.19 UTC] epochPluginInsertBlock: epoch 184
[db-sync-node:Info:1889] [2020-10-20 09:09:43.66 UTC] insertByronBlock: slot 4000000, block 3997915, hash a1f93a150ed43de21591124248b27ba0c830bed8c8e81c9a17d7823b5a6cfc97
[db-sync-node:Info:1889] [2020-10-20 09:14:39.01 UTC] insertByronBlock: slot 4005000, block 4002914, hash 3ad70e79c62b3f0cafac5a6bcce66702cac04ea16b7487ceb4627cd61eb9ca42

cela est probablement dû à une certaine indisponibilité du socket cardano-node

Cela en soi ne provoquerait pas l'échec d'une recherche dans la base de données.

Cependant, si db-sync effectuait une recherche dans la base de données lorsque le socket a disparu, l'exception résultante pourrait entraîner l'arrêt prématuré de la recherche dans la base de données, ce qui pourrait à son tour être signalé comme un échec de la recherche.

Vous remarquerez que lorsque le socket revient, il revient en arrière pour bloquer le hachage 55f53f6d...2f60ef6d (le hachage qui a précédemment échoué à la recherche) et cette fois, la recherche doit avoir réussi ou la synchronisation de la chaîne serait morte juste là.

Cela vaut-il la peine de garder cela ouvert? Le problème est que dans presque tous les cas, je ne peux pas résoudre les problèmes que je ne peux pas reproduire.

Cette page vous a été utile?
0 / 5 - 0 notes