所以说，上述的特点非常契合目前我们在数据库应用设计上碰到的问题。经过评估，我们开始着手安排部署和测试，在备份、监控、故障恢复和扩展几个方面有以下的一些心得：
官方提供了一套基于 mydumper 和 myloader 的工具套件，是基于逻辑备份的方式，对于迁移来说是很便捷的；
监控用的是应用内置上报 Prometheus 的方案，可以写脚本与自有的监控系统对接；
有状态的KV层采用的是 Raft 协议来保证高可用，Leader 的选举机制满足了故障自恢复的需求；
无状态的 TiDB-Server 查询层可以在前段搭建LVS 或HAProxy来保证故障的切换；
KV 层的 Region 分裂保证了集群无感知的扩展。
测试之后发现数据库运维中比较重要的几项都已经闭环的解决了，但有得有失，实测结论是：
TiDB 是分布式结构，有网络以及多副本开销，导致 Sysbench OLTP 测试中 单 server 的读性能不如 MySQL，但在大数据量下性能相较于MySQL不会产生明显下滑，且弹性扩展能力评估后可以满足业务的峰值需求；
Read full article from 去分库分表的亿级数据NewSQL实践之旅
No comments:
Post a Comment