Running the geth client  in default mode, requires after some time, quite a big amount of disc space. To optimize it, the fast syncmode can be enabled. What is does is basically syncing only the latest part of the blockckain instead of the whole chain.
So after running the Ethereum Pool on ethertrench.com  for some time, I noticed that the disc space was going down rapidly. To fix it, I decided to go for the fast-sync mode with some optimization.
It should be highlighted that for running geth in fast syncmode, the whole database has to be deleted and rebuild. Therefore, since the geth client on ethertrench.com  runs as main and backup on two servers, I first migrated the backup server.
To do so, the first step is to clean out the database by running:
After cleaning out the database, we can restart the geth client, with syncmode fast. Additionally I added the cache option, to increase the cache of geth from the default 16MB to 1GB. This should give the client an extra boost.
geth --syncmode=fast --cache=1024
To check the status of the syncing, you can log-in to geht with
and run the command
If the system shows you “false” then your syncing is complete.
After completing the backup node, I shut down the main geth node. So far so good, basically I saw that ethertrench.com connected to the backup geth client and continued without interruption.
So now I starting doing the same thing on the main node. And that’s the point where the sh*t hits the fan! After starting the syncing on fast mode on the main node, the mining process switched again from the backup to the main node. This resulted into a desaster, as miners then immediatley found 2 orphan blocks.
To fix it, I reconfigured the pool operating only with one geth node and restarted the processes. Furthermore I deleted the orphan blocks for the database. Neither the less the mining shares of the miners are gone with the old block. That’s definitly something to blame on me.