Skip to content

Latest commit

 

History

History
 
 

level4

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
 
 
 
 

Stripe CTF3: level4

Description

Last night, your master MySQL database fell over in the middle of the night, causing you to wake up and perform an emergency failover. In the meanwhile, your entire site was down, relying on your sleepy self to remember and run the correct sequence of commands.

This has you thinking: there's got to be a better way. You know that there are lots of systems out there which provide automatic failover and high-availability. Why can’t you have that for your MySQL database too?

Starting today, you can.

In this level, your goal is to build a multi-node highly-available SQL database that behaves identically to a single node, even in the presence of network or node failures.

We’ve given you starter code for such a database, written in Go. The database uses a home-grown failover scheme, which it turns out doesn’t work very well in practice.

You’ll likely find README.md to be helpful in getting your bearings.

To actually test how your code handles failure scenarios, test/harness uses our network simulator, Octopus, which will spin up your nodes and proxy their communication (acting as a lossy network). Octopus will then start issuing SQL queries to all nodes at once, checking at each step to make sure your output looks exactly like what it gets by running the same queries locally.

Write-up

The hard part of distributed databases really comes down to state replication — given one server that’s received a write request, how does it make sure the other servers know about that write before it’s accepted? Fortunately, there are a number of algorithms for this, such as Paxos and Raft.

One solution would be to add the Go implementation of the Raft distributed consensus protocol to the provided starter code.

(TODO)

Other write-ups or solutions