MySQL在Square的拆分实践

Square是面向美国，加拿大，英国，日本，澳大利亚提供金融服务的公司。现在所有的交易相关信息存储在MySQL中。这种电商类的网站，整体规模及也有一些值得学习的地方。 下面一起看看Square在MySQL方面的经验。

目前Square使用MySQL的规模如下：

• 超过4000个实例，基于Percona Server 5.6 使用GTID+Row格式复制
• 超过800台物理机器
• 数据总量在1PB左右
• 300多个服务构成
• 全年达99.95%的可用度。 每天低于43s，全年4个小时23分的停机。

最大的成功经验： 把每个库控制在一定的大小之下（1T以下），不要出现大库大实例。

面对这么大的规模的DB集群，Square的成功经验总结如下：

1. 利用复制技术，每个IDC里一个从库，各IDC内提供切换技术。其它IDC里的从库只是用是来提供读的能力。 因为Square有MySQL主从结构更多的是在多IDC之间部署，考虑到机房之间IDC的可用性问题，并没有把业务过度的依赖的其它从库，而且把所有的业务尽量压在了主节点上。业务请求也集中一个IDC内完成，当当前的IDC不用时，才切换到其它IDC中。

在设计上拒绝大库。

2. 高可用切换使用基于域名和VIP结合的方式. 主节点担任更多的读写工作。 每个节点在不同的IDC中。利用GTID+Row格式复制，其中节点故障，如果需要重建，首先借助 备份重建，如果备份完成，借助于主库下面的从节点备份后重建。

整体结构如下：

标准化每个集群，做到多IDC中可用，这个可用，实质上是多IDC提供容灾能力，其它IDC不提供写能力。

3. 备份上使用percona的xtrabackup备份。每天进行全备，对备份进行加密及切分成4G一个块进行存储。做好备份工作的就监控，Report备份失败的任务，备份存储到本地的Raid做的存储上，也有部分存到云盘上面。 每天有随机抽样检验备份是否可用，也可以用备份恢复故障的节点，例如：备份重建失败的节点等等。

Square在使用MySQL方面的建议：

1. 考虑到所有节点都有可能会失败

2. 每个进程都要考虑到管理

3. MySQL的Replcaiton是一个不错的架构

4. 注意自动化运维的时间控制（拒绝超级大实例）

5. 保持每个分组单元独立

6. 告警通知可以及时的能下发到DBAs或是相关开发人员

7. 选择一个稳定可信的版本（统一版本）

8. 把MySQL当成队例或是Cache来用

9. HA环境，生产中要进行定期测试

10. 从应用层考虑拆分

11. 限制每个应用拆分的DB大小在1TB以内

12. 保持较小的集群， 拒绝大实例

13. 自动化每一个操作

14. 监控MySQL活着或是死掉，复制是不是正常

15. 监控指标使用PMM，VividCortex等相关工作及内部的指标

16. 定期利用pt-table-checksum进行检查主从数据是不是一致。

备注：文章是作者阅读总结，如有疑问欢迎留言。