cnode 1.35.0 更新备忘
本次是一个大更新,官方计划的转主网的时间是 7月底。由于 1.35.0 的 release 已经放出,提前做一下升级。
基本的升级流程和以前版本一致,相同的部分略过不表。有一个小坑需要备忘一下
按以前的步骤git更新到目标版本, 然后运行 cabal_build_all.sh
本次是一个大更新,官方计划的转主网的时间是 7月底。由于 1.35.0 的 release 已经放出,提前做一下升级。
基本的升级流程和以前版本一致,相同的部分略过不表。有一个小坑需要备忘一下
按以前的步骤git更新到目标版本, 然后运行 cabal_build_all.sh
上文core node 遭遇分叉(fork)的问题无法启动正在修复中,出块时间又逼近。决定冒险执行 core 的迁移。
原本升级迁移的也在计划中,只是这次遇到情况提前了。万幸手边设备是就绪的,除了故障的core以外内网还有3个可用的relay在正常备选。
选之前众筹拿到的 r86s,配置16G RAM 和 128 eMMC+ 500G SSD 较高,应付将来 cardano-node 升级要求提高还有充分的冗余。
至少需要2台节点设备,建议3台。
建议有1 core 2 relay 3台,因为 迁移 relay至少得停掉其中2台,重启后如果没有relay保持在线,外部检测会认为你的pool完全脱机。
前文再续,书接上回 听从了大佬建议。以为自己只是遇上了意外重启,草率地在 db 目录下加了 clean
标记。
之后又过了两天,发现节点又卡在 starting 状态
检查日志,看到持续报在 slot 57200220 上对 tx MEMPOOL一直报错无法处理。提示与其他节点断开重置。 (Connection reset by peer)) "(recv errored)
没空究其原因,也许遭遇了其他分叉节点的数据污染,当务之急是修正数据启动节点,因为还有不到12个小时就到 leadlog 预告的出块时间。
而该死地这个问题发生在 core node 上
遭遇节点自动重启后长期处于 starting 状态(1个小时以上)
检查日志
cd $CNODE_HOME/logs
tail -f node0.json
发现正在验证区块
{"host":"cnoder86","pid":"3127081","loc":null,"at":"2022-04-04T03:43:18.66Z","ns":["cardano.node.ChainDB"],"sev":"Info","env":"1.34.1:73f9a","data":{"kind":"TraceImmutableDBEvent.ValidatedChunk","chunkNo":"2171"},"msg":"","thread":"5","app":[]}
在社区资讯过大佬们,答曰是一些 dirty data 造成的。或许是异常的重启或者来自分叉的节点的干扰数据。
无他,是节点的自纠和保护机制
如果赶时间又自信数据没有问题,可以用逃课的办法跳过这个自检:
cd $CNODE_HOME/db
touch clean
systemctl restart cnode
简单的说, 就是在 db 路径下新建一个名为clean
的空文件。节点启动的时候检查到有这个文件就会跳过自检。
但以上方法慎用,当你无法保证数据正确完整的时候跳过自检可能导致自己的chain db 进入错误的分叉,下文详述。
-待续-
应网友要求,此法可用于relay上。下文为实现流水账,文末有参考的 win/macos上实现方法
需要有个正常编译且运行中同步良好的 cardano-node, 有当前最新released版本的 cardano-submit-api
本例路径在 ~/.cabel/bin/cardano-submit-api
cd $CNODE_HOME/files
wget https://raw.githubusercontent.com/input-output-hk/cardano-node/master/cardano-submit-api/config/tx-submit-mainnet-config.yaml
貌似在linux cnode中,参数可直接为节点的 config.json
,未验证
对应修改各参数, 端口默认为 8090
"${HOME}"/.cabal/bin/cardano-submit-api --mainnet \
--config "${CONFIG}" \
--socket-path "${CARDANO_NODE_SOCKET_PATH}" \
--listen-address ${HOSTADDR} \
--port ${HOSTPORT}
启动后见提示
[cardano-tx-submit:Info:12] [2022-02-13 19:43:43.35 UTC] Running server on 192.168.0.86:8090
为方便执行和监控,后续会把上述启动命令写进 nohup 作为一个启动脚本
本地节点IP为 192.168.0.86 , 已检查过防火墙部分
http://192.168.0.86:8090/api/submit/tx
postman 测试得到正确响应
(方式:post, header添加参数 Content-Type: application/cbor)
"transaction read error RawCborDecodeError [DecoderErrorDeserialiseFailure \"Byron Tx\" (DeserialiseFailure 0 \"end of input\"),DecoderErrorDeserialiseFailure \"Shelley Tx\" (DeserialiseFailure 0 \"end of input\"),DecoderErrorDeserialiseFailure \"Shelley Tx\" (DeserialiseFailure 0 \"end of input\"),DecoderErrorDeserialiseFailure \"Shelley Tx\" (DeserialiseFailure 0 \"end of input\"),DecoderErrorDeserialiseFailure \"Shelley Tx\" (DeserialiseFailure 0 \"end of input\")]"
如何配置wallet部分略过;
题外话,截止至 1.33.1 cntools 自带的 scripts 内有一名叫 submitapi.sh
的脚本, 简单阅读内容发现正是实现上文相同功能的,而且做了注册为系统服务的功能,不过脚本并不完备且最后执行参数是在 testnet下,看来是实验中的东西未正式普及。
参考文:
https://cardanode.com.au/reducing-transaction-connecting-nami-to-daedalus/