> <i>Unlike most applications, we are much heavier on writes than reads.</i><p>I think what they meant to say is that unlike most <i>web</i> applications, they are heavier on writes than reads.<p>Write-heavy workloads -- aka OLTP -- are the bread and butter of relational databases. To the point that people complain they aren't as good at read-heavy workloads.
I found this article incredibly interesting, because I've only worked on low-traffic Rails apps so far. I've always wanted to learn about sharding, but haven't needed to, and didn't know where to start.<p>Now I'm inspired to start up a few VMs and have a play with the gems they mentioned, and try to get replication and failover happening.
Its not scaling if its not chock full of numbers (and maybe even graphs). There's not one mention of requests per second or latency in this. Users/capacity per shard, bottlenecks run into, etc.
Yeah, DRDB is terrible for write heavy performance. It was probably the source of many of your MySQL issues as well, but it's good that you've found a new home regardless.
To author: For how long could you have avoided the need to chard if you would have off-loaded all the read-only queries to multiple hot-standby slaves instead? Your scaling story is almost identical to ours, same pg versions on same years, DRBD, etc. But we haven't split the database into multiple chards yet. I'm hoping to post-pone it for at least a year by off-loading read-only queries to a lot of synchronous slaves.
One thing that isn't mentioned which we are currently facing problems with is the change of timeline once a failover occurs. The code isn't yet merged to use the stream to push the timeline update so all slaves must read from the shared archive.<p>Maybe I've implemented things incorrectly, but this is a frustrating issue for the moment.