单主模式
一个mysql集群包括一个master点和2个slave节点。所有写操作都要经由master节点，在承担数据冲突风险的前提下，亦可从slave节点写入。
当前配置是将数据库cname指向master节点，当master节点出现故障时，dba team利用工具将一个slave节点切换成主节点并将cname指向新的master。
单主的主要挑战是，多地域部署的应用代码访问主节点时的延迟不一致。
通过cname切换访问入口带来的问题是dns ttl cache。
读写分离
默认情况下，用户只知道master的cname，读写均从此cname进行，用户是不知道其他访问入口的。需要承担的代价是跨域访问的高延迟。
针对某些比较大的读操作（比如拉报表数据），可能会影响master性能，业务需要找DBA提需求，DBA会将slave的地址共享给业务，业务需要承担的代价是，写入master后，到数据sync到slave的延迟。这个延迟在毫秒级，业务基本可以承受。
分库分表
如果数据量大，则会分离数据库，比如用户信息，商品信息，交易信息，需要dba与业务约定分库的规则，比如按照某些重要属性做sharding，业务既定规则决定访问哪个数据库instance。
故障处理
如果slave出现故障，做failover就好了。
如果master出现故障，则涉及到域名切换，TDO（site admin）会在配置中心mark down掉数据库应用实例，业务看到mark down以后，会暂停数据库访问直到恢复。
多主模式（很少用）
支持Galera cluster，所有节点都是主节点，不同节点部署在不同数据中心。客户端通过DAL层实现就近访问。
只有低IO需求的DB能运行在此模式，因为双向同步显著降低DB性能。