共计 1425 个字符，预计需要花费 4 分钟才能阅读完成。
每台机器都使用多实例的模型。每个机器放多个实例，每个实例放多个 DB。
多实例之间没有进行资源隔离，这么做是让每个实例都能发挥最大性能。
目前大部分核心业务已切换成 MyRocks 引擎，在机器硬件配置不变的情况，约可节省一半机器。
放在 MyRocks 上的核心业务主要有：Feed、Post、社交图谱等读写混合业务。
MyRocks 项目地址：https://github.com/facebook/mysql-5.6
另外，MariaDB 10.2 版本也即将整合 MyRocks 引擎。
采用基于 GTID 的一主多从结构，外加一个基于 lossless semi-sync 机制的 mysqlbinlog 实现的 binlog server（可以理解为 MySQL 5.7 的 loss zero replication）。
基于多数派实现自动选主。
基于配置中心实现切换，未使用 VIP。
在认为 semi-sync 复制可保证主从数据一致性的假设前提下，发生故障切换时，利用上述的 binlog server 中的日志进行补全后再选新主、切换。
若个别情况下由于特殊原因，出现从库全部挂掉的情况，会将全部请求切到主库，由它扛起所有的业务服务压力。
某个从库挂掉时，可以动态摘除。
所有的备份都是基于 mysqldump 实现，之所以采用 mysqldump 逻辑备份好处有：
- 无需备份索引，只备份数据；
- 备份文件压缩比高，更节省磁盘空间；
- 改进了 mysqldump，备份过程中还进行额外压缩；
上面提到，因为采用多实例、多 DB 结构，备份时可以多 DB 并行备份。当然了，也会控制并行备份的数量，避免影响在线业务性能。
备份放在集中存储（HDFS）上，据说已达 EB 级别容量。
关于备份的作用定位：
- 供数据分析环境拉数据
- 供灾难恢复
可使用 xtrabackup 在现有存活的 SLAVE 实例上备份，也可在主库上发起备份，再利用 WDT（或者是 BT）协议传输到异地，用于拉起从库。
关于 WDT 项目：https://github.com/facebook/wdt
面对大规模的数据库实例，手工处理完全不现实。目前在 facebook 主要是利用 Python 开发内部 DB 运维平台，所以 Python 技能方面要求比较高。
采用他们自已的 osc 工具执行 Online DDL（也是本次 DTCC 大会上 lulu 的分享主题），它最早用 PHP 开发，虽早已开源，但实在不好用，所以几乎只在内部使用。这个工具不同于 pt-osc，相对来说更有优势，比如可以避免使用 pt-osc 最常遇到的主从数据延迟问题。
项目地址：https://github.com/facebookincubator/OnlineSchemaChange
DBA 团队更多的是负责私有 DB 云平台的建设。
Schema 设计及 DB 拆分等由性能优化团队负责。
在线表结构变更：数据库资源申请由质量服务团队负责，做到资源的合理分布、分配，如果某个业务只需要个位数级别的 DB 实例，可以自行在私有 DB 云平台中申请部署，当数量比较大时，需要先经过质量服务团队评估通过。
数据库资源申请由质量服务团队负责，做到资源的合理分布、分配。如果某个业务需要小量 DB 实例，可以自行在私有 DB 云平台中申请部署；当数量比较大时，需要先经过质量服务团队评估通过才可以。
