This Saturday we trimmed data of shadow of ropsten network, however the syncing speed is too low (~2 blocks/sec):
[2021-07-24T14:51:28Z TRACE darwinia_shadow::mmr::runner[] Pushed leaf 9813360: 2678caf23fb9e6d48dc900e53f1b75f42586f35f311c65e4dfaf69c7f6367c1b at position 19626707
[2021-07-24T14:51:28Z TRACE darwinia_shadow::mmr::runner[] Pushed leaf 9813361: 402a60d09232bbd2a42726169c95316e6647f1cf2dd246128f855918e1616c6d at position 19626708
[2021-07-24T14:51:29Z TRACE darwinia_shadow::mmr::runner[] Pushed leaf 9813362: 443fa720b68450adbf6d636839ee09aa30d3d1a2ae89197c8a6a247bccf1a70b at position 19626710
[2021-07-24T14:51:29Z TRACE darwinia_shadow::mmr::runner[] Pushed leaf 9813363:
So a tuff decision was made - we have to stop the geth service and re-import the database. But this doesn't sound ideal if the problem was on the mainnet. Since geth endpoint is unavailable during the import, other apps rely on our public geth endpoint will stop work. I think we should consider the impact if have to re-import the data from geth. If we can't solve the syncing speed issue, we might have to run multiple geth nodes in order to prevent the interruption of geth in case.
This Saturday we trimmed data of shadow of ropsten network, however the syncing speed is too low (~2 blocks/sec):
So a tuff decision was made - we have to stop the geth service and re-import the database. But this doesn't sound ideal if the problem was on the mainnet. Since geth endpoint is unavailable during the import, other apps rely on our public geth endpoint will stop work. I think we should consider the impact if have to re-import the data from geth. If we can't solve the syncing speed issue, we might have to run multiple geth nodes in order to prevent the interruption of geth in case.
Internal discussion: