MySQL at Facebook – Current & Future

Around 45 min. Good talk. I jotted down some quick notes and couple of slides that captured my interest:

UDB – Universal DB (Was called User database before)
Shards:
- Remote references in both shards
- Backout mechanisms
- Async job that fixes problems
Replication
- Binlog consumers eg. memcache invalidators for geographical replication
- Backup consumers for binary logs
Facebook has a single cluster!
- Ease of setup
- Uniformity of Access patterns
Custom Facebook build of 5.1(we can get it, open source), InnoDB
- Admission Control Feature (Specific to their build) looks interesting
Hardware with more cores, but I/O bound
Looking at newer Compression Algorithms
- qpress (quickLZ)
- snappy compression alg (Google)
InnoDB purge Lag – Happens if the DB is busy all the time, eg. backup doesn’t give purge to clean fully
Custom Tooling
- Per-Table restore
- Truly incremental backup
- Online schema changes
Monitoring
When you have 10,000 servers averages hide things. So need top N monitoring
They track and analyze stalls
- Stall tools like dogpiled, aspera
- Started with multi-second stalls, now track subsecond stalls
- Kernel mutex stall – see it constantly
MySQL never a solved problem!
The Top N monitoring and stall monitoring is applicable outside MySQL as well
Have attached a few slides that I found interesting …