archive snowblossom slack dev
prev 2019-02-25 next
2019-02-25 10:20:33
GitHub
Old logfiles for the database node and pool (LOG.old*) are not restricted in growth or deleted. In particular the log files for the node db can grow to several gigabytes after a few months. Suggestion: Limit size via config files or delete after x days. Workaround: Delete old files via cron job
2019-02-25 18:20:27
GitHub
[snowblossomcoin/snowblossom] Issue closed by fireduck64
2019-02-25 18:27:11
Rotonen
why rotate yourself at all?
2019-02-25 18:27:42
Fireduck
These are not human readable logs, they are binary db transaction logs
2019-02-25 18:27:53
Fireduck
so to me, it makes sense to let the db layer handle it
2019-02-25 18:29:37
Rotonen
gotcha, ~ postgres write ahead logs
2019-02-25 18:30:43
Fireduck
yeah, at least I think that is what they are
2019-02-25 18:30:59
Rotonen
i guess in production one would have some pickup method and stream those to a cold (lukewarm?) spare?
2019-02-25 18:31:20
Rotonen
rocksdb users are not very verbose
2019-02-25 18:31:55
Fireduck
of course, my normal pessimism applies. Never trust a single filesystem or database with anything critical.
2019-02-25 18:32:18
Fireduck
yeah, if you have an authoritative rocksdb that you absolutely could not lose state on I'm not sure what you would do
2019-02-25 18:32:25
Fireduck
probably not use rocksdb for that
2019-02-25 18:32:42
Fireduck
at least without a paxos layer on top
2019-02-25 18:33:09
Rotonen
do you need the performance there? JDBC / sqlite / postgres?
2019-02-25 18:34:06
Rotonen
the best arguments i see for rocksdb have to do with tight hardware coupling, which is unlikely to happen in this kind of a scope
2019-02-25 18:34:26
Fireduck
for cryptocurrency stuff, were people love having everything locally hosted, rocksdb is great. It is fast and holds a lot of data without breaking.
2019-02-25 18:34:55
Rotonen
true, sqlite is nightmare fuel
2019-02-25 18:35:08
Fireduck
if I actually needed an authoritative state for something, I'd probably pay the dollars for google bigtable or spanner and make it their problem
2019-02-25 18:35:13
Fireduck
google is really good at that sort of thing
2019-02-25 18:35:29
Fireduck
but minimum cluster size is on the order of $6/hr so not for cheap little things
2019-02-25 18:36:37
Rotonen
well, that’s way cheaper than a competent DBA, and especially so if you need 24/7 rotations and sickleave redundancy
2019-02-25 18:37:35
Fireduck
yeah, my estimate is that it takes about 6 people to cover 24/7 if you need to treat them like humans
2019-02-25 18:38:51
Fireduck
If mostly up and mostly not my problem is good enough, the Amazon RDS or Google Cloud SQL are quite good.
2019-02-25 18:39:42
Rotonen
yeah, that team, including side costs, seats, walls, would probably run at up to 2M per year
2019-02-25 18:39:57
Rotonen
aka why managers love IaaS
2019-02-25 18:40:08
Fireduck
right