...
I'm not sure what the confusion is, but there was no pool outage.
As it says, uptime is 14hrs.
As I said, it was a ckdb restart.
The pool is made up of 2 parts:
1) ckpool that you mine to that handles all of that on the mining side
2) ckdb that gets all the data and deals with it on the data storage and web side.
An outage of 1) affects the miner.
An outage of 2) doesn't.
Great idea that hey
Hi Kano, when ckdb is down, does ckpool keep data in memory until ckdb comes back up and then send all kept data for ckdb to persist? Or does it keep it in a file and you have to manually transfer data to ckdb?
Not that it's important, I was just wondering.
Firstly, ckdb is a memory resident DB.
The postgresql backend is simply the permanent storage that is only read on a restart and written to with all the permanent data.
ckpool logs all it's data to hourly logfiles (about 1-1.5GB each at the moment) as well as sending it to ckdb.
A ckdb restart reloads the permanent storage DB, then using the info there, it goes and reloads the log files from where the DB was up to.
It can currently reload the log files about 50 times faster than they fill up, so a 1hr log file often takes less than a minute.
It obviously only needs to look in the last 1 or 2 log files since the down time is always very short
It is sometimes 2 logfiles since it may happen just around the time of the log file change over.
At the same time, it has been getting all the new incoming data from ckpool queued up.
When it hits a match in the log file vs the 1st incoming queued message from ckpool, it knows it has all the data it needs from the log files.
At this point everything is back to working - but out of sync.
It then has to sync/catch up on all the data queued in ram, that was transferred from ckpool while ckdb was reloading the log files.
That sync number is the number it shows on the bottom left of the web site
That number also grows whenever ckdb gets behind processing the data from ckpool, usually due to DB write delays.
Currently the reload takes from 3 to 5 minutes and the sync usually only takes a minute or two after that to get back down to zero.
I didn't have the chance to thank you for taking the time to explain various technical aspects of your system. I'm particularly interested on those aspects, being myself a software developer trying to find the time to invest my knowledge in the Bitcoin world. I think 24 hours in a day is not enough. Too many things I want to touch and do. Well in the meantime, my miners are working for me. Thanks again Kano!