Live data from Hacker News

CockroachDB 1.0

cockroachlabs.com

361–366 of 366 posts

Re: CockroachDB 1.0

#362

Earlier quoted context omitted.

short answer: nope. cockroachdb replicates data for availability and in order to guarantee consistency across the replicas, it uses Raft[1] internally. Raft necessitates a majority of the replicas remain available in order to operate. it ensures that a new 'leader' for each group of replicas is elected if the former leader fails, so that transactions can continue and affected replicas can rejoin their group once they…

What are the recommended configurations then? If I want to survive multiple node failures could I have 9 replicas?

raft is premised on overlapping majorities, so to speak. in order to tolerate up to `n` node failures you'd need to run `2n + 1` instances (for nine nodes you'd tolerate up to four node failures).

Re: CockroachDB 1.0

#363

Say you scaled up to 100 nodes for the holiday season, is there any way to tell how many/much storage/nodes you have to keep running in order to keep 3 backups and maintain your new post holiday load?

We don't have any auto scaling for either up or down scaling, but if you're using a deployment tool such as Kubernetes, I don't see why it wouldn't be fairly easy. And it might be a good idea to add a message in the admin UI if you all of your nodes are experiencing a high load.

By just looking at your max load over the last 24h or perhaps week, it would be pretty easy to see when to down scale.

That being said, as long as you remove the cockroach nodes one at a time , it's pretty easy to down scale a cockroach cluster.

Re: CockroachDB 1.0

#364
post #356

Earlier quoted context omitted.

Currently, you need to run one node without --join for the initial bootstrapping (as soon as this bootstrapping is complete, you can and should restart it with --join to get everything into a homogenous configuration). I was hoping to make some changes here so you could start every node with --join from the beginning, but it was trickier than anticipated so it didn't make the cut for 1.0. Watch for improvements here…

Thank you for your answer. That's okay, for now, I run a simple StatefulSet where each pod checks whether the Service is reachable on port 26257 to determine if it should join or init the cluster. It's not as nice as if it was handled by Cockroach itself, but it does the job.

This bootstrapping problem is tricky. We publish kubernetes templates at https://github.com/cockroachdb/cockroach/tree/master/cloud/k... that contain our current best solution for the join/init problem.

Re: CockroachDB 1.0

#365

Earlier quoted context omitted.

We were told that the slides would be uploaded by Applicative (hence we didn't post a copy), but we can't seem to find it on the internet either, so here's a copy from our Google drive: https://drive.google.com/file/d/0ByQnrkOiRT_LMmZ6SXFmbk5wTDA...

Did y'all ever figure out a way to get goroutine leak detection working with parallel tests? (didn't expect to see that linked here)

We have started parallelizing our tests with the new subtest feature: leaktest in the top-level test, t.Parallel in the subtests. This means we only check for leaks in between batches of parallel subtests. This works OK for us for now since our slowest "test" is really a huge data-driven test suite, and that's the only place we're currently parallelizing, although it would be better if we could parallelize more of our tests.

Re: CockroachDB 1.0

#366

In an era where hot air and hip DB technologies prevail, I'd like to emphasize the fact that the CockroachDB engineers are consistently honest and down to earth, in all relevant HN posts. This builds up my confidence in their tech, so much so that even though I had no real reason to try this new DB, I'm gonna find one! :D

Exactly! The confidence that the devs inspire by taking the time to explain the choices behind the tech, makes me want to find a project to test it out on.
Post reply on HN