0

I keep having problem in getting local blockchain up to date to current height, including importing downloaded raw blockchain, each time it would get to a point where db gets corrupted & I have to wipe it out to start over. I get 58KB/s download speed from p2p network so I won't ever get synched starting from scratch, and no --prune-blockchain or --sync-pruned-blocks doesn't help at all. So after n-th trials, when I got stuck again, I try to connect to remote node from GUI and it said wallet synchronizing & daemon synchronizing. After they're fully synched, I switched back to local node and back to the same crap I started with

Monero 'Oxygen Orion' (v0.17.1.3-release)
Height: 1469833, target: 1469833

I thought the point of remote node is to connect to p2p network while synchronizing local blockchain db??

edit: I'll update with the status after an hour as local node

>>> status
[19/11/20 10:03] 2020-11-19 03:03:20.276 I Monero 'Oxygen Orion' (v0.17.1.3-release)
Height: 1469853/2233672 (65.8%) on mainnet, not mining, net hash 446.04 MH/s, v6, 142(out)+0(in) connections, uptime 0d 0h 13m 35s

half an hour

>>> status
[19/11/20 10:20] 2020-11-19 03:20:21.753 I Monero 'Oxygen Orion' (v0.17.1.3-release)
Height: 1469853/2233679 (65.8%) on mainnet, not mining, net hash 446.04 MH/s, v6, 269(out)+0(in) connections, uptime 0d 0h 30m 37s

instead of prioritize synching local db to close the gap to current height when starting up so I as node owner can use it for transaction, I have to keep up with new blocks first. There's literally no incentive for me to run a node if I have to run this 24/7 to be usable.

Improve this question
6
  • What kind of storage medium are you using? Because if it corrupts often, it may be a hardware issue unrelated to the Monero software.
    – dEBRUYNE ♦
    Nov 19, 2020 at 9:08
  • ZFS mirrored spinning disks & 16GB RAM. These flagsmonero-blockchain-import --dangerous-unverified-import=1 --input-file=<path>/Monero/blockchain.raw --data-dir=<path>/Monero/ --resume=true --log-level=1 --db-sync-mode=safe --db-salvage --batch-size=1 --block-sync-size=1 if i understand it correctly, means that multiple worker in async is off, and inserts txs one by one to db. Used it on monerod as well, tried every variations I could think of. Don't think hardware matters much when it's just inserting few kBs each
    – deadvoid
    Nov 19, 2020 at 17:46
  • --db-sync-mode=safe should safe-guard against any corruptions, even if the sync has not completed yet. Do you perhaps have a different storage medium that you could utilize? Then we can check whether the original drive is the root cause of your issue.
    – dEBRUYNE ♦
    Nov 19, 2020 at 17:53
  • Already did, but not everyone has free 120GB+ SSD just for synching, I ran out of space for SSD because I use it for more important stuff, like OS. Besides, it still doesn't answer why the design isnt well thought. Not only hard to understand how the softwares function (reading errors logs doesn't provide clarity either) already a very high barrier, importing from complete blockchain isn't fool proof enough, plus not ignoring newest blocks on mainnet if the height in local db is lagged. Then it's simply not user node friendly & certainly will progressively much more expensive to run a node.
    – deadvoid
    Nov 19, 2020 at 18:01
  • i didn't mention that i only used --dangerous-unverified-import after completed verifications twice, using it skips the process of verifying 70GB blockchain.raw that took more than half an hour iirc
    – deadvoid
    Nov 19, 2020 at 18:07

0

Reset to default

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.