Cardano-db-sync: Erro aleatório de "Falha de pesquisa de banco de dados em insertABlock"

Criado em 28 set. 2020  ·  6Comentários  ·  Fonte: input-output-hk/cardano-db-sync

Conforme solicitado por @erikd sobre este outro problema , estou reabrindo este como um novo problema, já que fui atingido por isso na última versão 5.0.1 empacotada na imagem oficial hub.docker.com ( inputoutput/cardano-db-sync:5.0.1 [0]).
Devo dizer que o problema não reapareceu novamente desde a falha desses logs [1] [2].

Eu acho que pode ser causado por algum problema de conectividade postgresql , mas de qualquer forma, IMHO, no pior caso, o processo principal deve exit >0 (já que ele não se recupera do encerramento automático do thread de banco de dados) ou de banco de dados thread deve ser reiniciado quando essas exceções são levantadas.

[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
...

Todos 6 comentários

Eu tenho visto

DB lookup fail in insertABlock: block hash

antes, mas um foi devido ao postgres ficar sem espaço em disco e os outros foram depois que eu fiz manipulações potencialmente inseguras do banco de dados durante o teste.

Quanto à parte FROZEN FOREVER , não tenho controle direto sobre isso. Meu código chama o código de rede que faz o protocolo ChainSync, que então chama de volta outro trecho do meu código. Nesse caso, meu código interno lançou uma exceção que foi capturada pelo código de rede e não se propagou de volta para o meu código. Pode haver uma solução para isso, mas é improvável que seja simples.

Minha sugestão é:

  • Certifique-se de que a máquina tenha espaço em disco suficiente (totalmente sincronizado com a época 220, minha instância db-sync está usando 6 GB de disco).
  • Elimine e recrie o banco de dados (para garantir que a corrupção existente seja removida).
  • Monitore manualmente a sincronização (deve levar cerca de 3 horas).

Desculpe, esqueci de mencionar que isso não aconteceu mais desde aquela época a partir dos logs em anexo; é por isso que presumi que poderia ter sido algum problema excepcional com minha instância postgres (eu estava jogando com HA naquela época, IIRC).

Podemos manter isso aberto por um tempo para ver se encontramos mais pistas úteis.

JFTR, estou sincronizando mainnet do zero e descobri que ele realmente se recupera depois de um longo tempo (pelo menos na versão mais recente) e que é provavelmente causado por alguma indisponibilidade de soquete cardano-node [0].
Este último problema é devido ao compartilhamento do soquete via TCP para que seja acessível a diferentes serviços em execução em pods k8s diferentes (sem ipc compartilhado) e recebo algumas instabilidades (ainda não tenho certeza de onde elas vêm exatamente, preciso fazer mais ajustes de 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

é provavelmente causado por alguma indisponibilidade de soquete de nó cardano

Isso, por si só, não causaria falha na pesquisa do banco de dados.

No entanto, se db-sync estava fazendo uma pesquisa de banco de dados quando o soquete desapareceu, a exceção resultante pode fazer com que a pesquisa de banco de dados seja encerrada mais cedo, o que por sua vez pode ser relatado como uma pesquisa com falha.

Você notará que quando o soquete retorna, ele reverte para bloquear o hash 55f53f6d...2f60ef6d (o hash que falhou na pesquisa anteriormente) e, desta vez, a pesquisa deve ter sido bem-sucedida ou a sincronização em cadeia teria morrido bem ali.

Vale a pena manter isso aberto? O problema é que, em quase todos os casos, não consigo consertar problemas que não consigo reproduzir.

Esta página foi útil?
0 / 5 - 0 avaliações