```
[db-sync- node:Info :64] [2020-11-07 15:28:05.27 UTC] Memulai chainSyncClient
[db-sync- node:Info :64] [2020-11-07 15:28:05.31 UTC] Tip Cardano.Db ada di slot 13132763, blok 4917327
[db-sync- node:Info :69] [07-11-2020 15:28:05.31 UTC] Menjalankan utas DB
[db-sync- node:Info :69] [2020-11-07 15:28:06.16 UTC] Kembali ke slot 13132763, hash c19c89792973fe2fff25e5b715e785d549da9647c2f9b7940aefcd29759dcd70
[db-sync- node:Info :69] [2020-11-07 15:28:06.17 UTC] Menghapus slot bernomor: []
[db-sync- node:Error :69] [2020-11-07 15:28:08.93 UTC] runDBThread: Panic! applyHeaderTransition gagal: [[NewEpochFailure (EpochFailure (NewPpFailure (UnexpectedDepositPot (Coin 804642000000) (Coin 804640000000))))]]
CallStack (dari HasCallStack):
kesalahan, dipanggil di src/Shelley/Spec/Ledger/API/Validation.hs:92:15 di shelley-spec-ledger-0.1.0.0- di tempat:Shelley.Spec.Ledger.API.Validation
[db-sync- node:Error :64] [2020-11-07 15:28:08.93 UTC] ChainSyncWithBlocksPtcl: Panik! applyHeaderTransition gagal: [[NewEpochFailure (EpochFailure (NewPpFailure (UnexpectedDepositPot (Coin 804642000000) (Coin 804640000000))))]]
CallStack (dari HasCallStack):
kesalahan, dipanggil di src/Shelley/Spec/Ledger/API/Validation.hs:92:15 di shelley-spec-ledger-0.1.0.0- di tempat:Shelley.Spec.Ledger.API.Validation
[db-sync-node.Sub scription:Error :60] [2020-11-07 15:28:08.93 UTC] [String "Application Exception: LocalAddress {getFilePath = \"/opt/cardano/cnode/sockets/node0. socket\"} Panik! applyHeaderTransition gagal: [[NewEpochFailure (EpochFailure (NewPpFailure (UnexpectedDepositPot (Coin 804642000000) (Coin 804640000000))))]]\nCallStack (dari HasCallStack):\n kesalahan, dipanggil di src/Shelley/Spec/ Ledger/API/Validation.hs:92:15 di shelley-spec-ledger-0.1.0.0- di tempat:Shelley.Spec.Ledger.API.Validation ",String "SubscriptionTrace"]
[db-sync-node.Er rorPolicy:Error :4] [07-11-2020 15:28:08.93 UTC] [String "ErrorPolicyUnhandledApplicationException Panic! applyHeaderTransition gagal: [[NewEpochFailure (EpochFailure (NewPpFailure (UnexpectedDepositPot) Coin 804640000000))))]]\nCallStack (dari HasCallStack):\n kesalahan, dipanggil di src/Shelley/Spec/Ledger/API/Validation.hs:92:15 di shelley-spec-ledger-0.1.0.0- di tempat :Shelley.Spec.Ledger.API.Validation ",String "ErrorPolicyTrace",String "LocalAddress {getFilePath = \"/opt/cardano/cnode/sockets/node0.socket\"}"]
```
Apakah ini jaringan utama? Apakah Anda meningkatkan dari satu versi perangkat lunak ke versi lain?
~Bagian NewEpochFailure
dari pesan kesalahan menunjukkan bahwa versi db-sync
tidak kompatibel dengan versi node
.~
Versi 6.0.x
dari db-sync
kompatibel dengan 1.21.x
dari node.
ya, mainnet, saya membuat DB baru dan sekarang berfungsi dengan versi yang sama, jadi tidak yakin apa yang terjadi
Menutup ini.
Saya baru saja menemukan ini di server CI cardano-graphql
, tanpa perubahan minat seperti pembaruan versi. Menghubungkan ke mainnet dengan konfigurasi ini.
[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\"}"]
~Setelah mengobrol dengan Rhys di Slack, saya menduga bahwa dalam kasusnya db-sync
mengalami masalah lebih dari 1000 blok sebelum kesalahan ini dan apa yang dia lihat adalah hasil dari restart dan memutar log.~
Masalah terjadi pada epoch rollover.
Yang @rhyslbw dan @mmahut tertangkap keduanya muntah di blok terakhir yang sama, hash 5d8ea0d4cf2d4f46cc91aa48e83c029691f836d7200e11e26402f9a2bcb25987
. Itu sangat tidak mungkin kebetulan.
Sangat mungkin blok itu adalah blok pertama dari zaman baru.
@rhyslbw apa hash git dari versi db-sync
Anda gunakan?
Yang @mmahut gunakan di #404 adalah komit https://github.com/input-output-hk/cardano-db-sync/commit/6187081a7ea66954c86094578bd37e01bca8aaec yang tidak ada komit https://github.com/input-output- hk/cardano-db-sync/commit/afe68e08cf5f8b3b1b6690e411670908bc0f5942 yang berisi perubahan pada konfigurasi status buku besar. Masalah ini tentang kematian dalam kode terkait status buku besar, tetapi perubahan itu seharusnya tidak membuat perbedaan di mainnnet. Tag 6.0.0
berada setelah komit kedua.
Ini adalah rasa sakit BESAR di leher untuk men-debug tanpa perbaikan untuk https://github.com/input-output-hk/cardano-db-sync/issues/256 .
@erikd Saya menggunakan tag rilis commit 3e68f3011bb156b9b799ccf056f9a73281479f9c
Melakukan BANYAK pekerjaan mencoba menciptakan kembali masalah ini, tetapi itu tidak deterministik. Saat ini saya menjalankan versi kode ini yang seharusnya menangkap kesalahan dengan lebih baik (dan segera membatalkan). Saya berharap ada kesempatan untuk memicu ini lagi pada batas zaman berikutnya yang terjadi sekitar 14 jam dari sekarang.
10 node, semuanya macet dengan bug khusus ini. Statusnya adalah:
65bce9e6463a324d612d24588afbdecc 13996555.lstate
77b5e894f8a22cb49605b9bfd474588a 13996568.lstate
12c4be3b0fac587d1b6485284e218404 13996582.lstate
f0b29f6768c836e7283f7033799ce146 13996626.lstate
ba72f63cf8185150c8120f3466756479 13996646.lstate
a2b45038665701084196a238b3beb329 13996669.lstate
7e8cccd8f0f1c3ac519ef7471a998ac1 13996713.lstate
ab304c279c8209e4b21a623b1a6dd80f 13996756.lstate
dan menggunakan git rev 6187081a7ea66954c86094578bd37e01bca8aaec
(yang merupakan beberapa komit di balik tag 6.0.0
).
Hipotesis saat ini adalah bahwa status buku besar rusak di beberapa titik dan korupsi hanya terlihat pada batas zaman.
Loop tak terbatas 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 dari 3 contoh memunculkan kesalahan NewEpochFailue
.
git revisi 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
Cuplikan instans yang tidak terpengaruh telah diluncurkan.
Fakta bahwa file status buku besar yang sama, misalnya 13996756.lstate
memiliki tiga hash yang berbeda sedikit tidak terduga.
Jika penyebabnya adalah status buku besar yang rusak, mungkin ini dan #405 adalah masalah yang sama
@SebastienGllmt Ya, itu mungkin, tapi saya bahkan belum sempat melihat #405.
2 dari 4 kasus dilemparkan ke bawah
Checksum MD5 dari instance yang gagal:
189def79f03972649fdcdcd811def1bb 13996555.lstate
dc6865de6149fdf4879a4659bcf02ef0 13996568.lstate
85bf1965fdadee3ee42c10dfd32e0bdb 13996582.lstate
c452477105dc4041c17d718a32f12056 13996626.lstate
9eb0f1fd0a165a8eff3ec4835f370d6d 13996646.lstate
4d5180ba656234020a71f2d46f1d9d0e 13996669.lstate
521ae28570c1630a18bc721cc4707eaa 13996713.lstate
9a2485e192578c1d3c22059648fba79f 13996756.lstate
(contoh gagal lainnya memiliki hash yang berbeda)
Contoh sehat:
98d46070c972d7b4ec564e4053e29eda 14033709.lstate
5c2443fe558a928a86606136337f3648 14033754.lstate
6c180d350ba7becf0f02d698ac160397 14033800.lstate
d655e560b8a43e064b671266795d262c 14033812.lstate
99bfbf88ec497e7e40865c920f8e8e26 14033839.lstate
bec82d94fe348d843389853cd24a3e5b 14033845.lstate
14faba941a24f02b236d784af85f8d32 14033890.lstate
c96d18f7bdadebed8e3b723b4e6691fc 14033936.lstate
Saya mencoba menyinkronkan ulang 10 contoh berbeda pada komit bcd82d0a3eada57fdf7cc71670a46c9b3b80464f
(karena saya memerlukan fitur metadata).
2 dari 10 memiliki versi file status buku besar yang rusak (berbeda dari yang lain). Jumlah yang benar adalah:
/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
Saya juga melihat adanya inkonsistensi dalam file. 14040345.lstate
hilang pada setengah dari instance, tetapi instance ini memiliki 14040553.lstate
sebagai gantinya.
FYI, masalah yang sama lagi pada transisi epoch 230...
Oke, saya tahu apa yang menyebabkan masalah. Memperbaiki ini relatif sederhana. Perbaikan tidak akan memerlukan sinkronisasi ulang db kecuali status buku besar sudah rusak (yang akan dideteksi oleh versi perangkat lunak yang diperbaiki).
Masalahnya adalah:
db-sync
mendapatkan blok yang telah divalidasi oleh node, tampaknya masuk akal untuk menggunakan versi cepat.@erikd Apakah mungkin untuk membuat ini beralih konfigurasi antara pemeriksaan penuh dan pemeriksaan cepat? Saya lebih suka menjalankan semuanya dalam mode "aman" dan menggunakan sumber daya tambahan untuk memastikannya tetap menyala.
@CyberCyclone Setelah hash diperiksa, tidak ada lagi yang bisa salah dengan probabilitas yang lebih besar daripada kemungkinan tabrakan hash 256 bit. Hash harus diperiksa. Saya pikir itu sedang diperiksa. Setelah diperiksa, tidak ada alasan untuk melakukan pemeriksaan lebih lanjut.
Luar biasa, bagus untuk didengar! Cara kata-katanya terdengar seperti ada lebih banyak hal yang terjadi. Tapi ya, tabrakan hash tidak perlu dikhawatirkan.
Karena saya menggunakan versi cepat dan kode saya memutar kembali ke slot yang ditentukan, itu mungkin untuk memutar kembali ke nomor slot yang benar, tetapi blok yang salah (yaitu nomor slot benar, tetapi hash salah dan karena itu blok salah).
Seharusnya _tidak mungkin untuk memutar kembali ke nomor slot yang benar, tetapi blok yang salah_.
Sinkronisasi rantai menginstruksikan untuk memutar kembali ke titik tertentu pada rantai (titik menjadi slot+hash), tetapi titik ini dijamin ada di rantai konsumen. Ya itu sangat masuk akal untuk diperiksa, tetapi jika pemeriksaan ini gagal maka itu menunjukkan bug logika di suatu tempat.
Jadi saya pikir ini perlu penyelidikan lebih lanjut sebelum kita bisa menyebutnya diperbaiki. Menambahkan pernyataan harus mendeteksi masalah jauh lebih cepat pada titik di mana itu terjadi, daripada jauh kemudian di batas zaman. Menambahkan pernyataan itu sendiri bukanlah perbaikan tentu saja.
Seharusnya tidak mungkin untuk memutar kembali ke nomor slot yang benar, tetapi blok yang salah.
Dimungkinkan jika rollback hanya memeriksa nomor slot tetapi bukan hash.
Logging sekarang telah menghasilkan ini:
[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.
yang sedikit aneh. Memulai ulang menghasilkan:
```
[db-sync- node:Info :34] [2020-11-19 09:06:15.54 UTC] Tip basis data ada di slot 8092720, blok 389107
[db-sync- node:Info :39] [2020-11-19 09:06:15.54 UTC] Menjalankan utas DB
[db-sync- node:Info :42] [2020-11-19 09:06:15.55 UTC] getHistoryInterpreter: diperoleh
[db-sync- node:Info :39] [2020-11-19 09:06:15.55 UTC] Kembali ke slot 8092720,
hash e1e78605937bb8cfc842d1ee7280b92fa9fce813c26fa66a88eaca74d7af9f05
[db-sync- node:Info :39] [2020-11-19 09:06:15.56 UTC] Menghapus slot bernomor: []
````
Perlu memeriksa kode untuk ini.
Saya memiliki pekerjaan sementara untuk memperbaiki ini. Solusinya berasal dari cabang debugging pekerjaan-dalam-proses saya, tetapi belum sepenuhnya diuji, QAed atau dirilis.
Jika ada yang menjalankan rilis 6.0.0
dan khawatir tentang rollover epoch yang terjadi dalam ~12 jam, ada cabang erikd/tmp-fix-6.0.x
(commit 3a6e7199c1f2) dengan solusinya. Solusinya mendeteksi sesuatu yang menyimpang, panik, pengecualian dicoba lagi pada tingkat yang lebih tinggi dan kemudian sinkronisasi db berlanjut.
Tidak ada perubahan basis data relatif terhadap 6.0.0
jadi tidak diperlukan sinkronisasi ulang.
Namun, menjalankan versi ini dapat mendeteksi status buku besar yang sudah rusak (saya bahkan tidak yakin seperti apa bentuknya) dalam hal ini sinkronisasi ulang akan diperlukan.
Setelah menambahkan banyak kode debug dan kemudian menunggu masalah dipicu.
Ternyata masalah ini adalah kondisi balapan. Dari log:
[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
Pada dasarnya yang terjadi adalah:
Cara mengatasinya adalah dengan memindahkan kode ke status rollback buku besar dari akhir antrian tulis ke akhir baca.
Diperbaiki pada master di https://github.com/input-output-hk/cardano-db-sync/pull/413 .
Juga akan ada rilis 6.0.1
memperbaiki ini.
Komentar yang paling membantu
Oke, saya tahu apa yang menyebabkan masalah. Memperbaiki ini relatif sederhana. Perbaikan tidak akan memerlukan sinkronisasi ulang db kecuali status buku besar sudah rusak (yang akan dideteksi oleh versi perangkat lunak yang diperbaiki).
Masalahnya adalah:
db-sync
mendapatkan blok yang telah divalidasi oleh node, tampaknya masuk akal untuk menggunakan versi cepat.