想问各位大大 MySQL 是怎么做高可用的？

我刚刚接手这个事。之前看过 Galera Cluster 方法。再之前还有 NDB 方案（不过好多人说那个不好维护）。但是以前的外聘 DBA 只愿意做主从，然后手动切换（之前故障过一点都不高可用啊）。他说用脚本切换可能出现脚本误判一直切换。之前还看 QQ 群里说阿里 mycat 方案。我看这个主要是为了提高性能的。目前我觉得首要是解决稳定性。今年我看了 MySQl 5.7 官方提供的 MGR(MySQL Group Replication)，不知道这个有没有什么坑。想请问各位大大的公司都是如何处理的。

一般来说应该从需求来定标准，我这个小公司一直都是需求不确定，用户量数据量其实不大，饼大。因为自建机房（归别的部门管）本身稳定性不靠谱，所以想用软件策略来补偿一下。所以稳定性优先，在保障稳定性的前提下，性能越高越好。

目前用的硬件配置是 E5-2650，内存 8G，磁盘用的是共享存储。之前各个项目数据库独立，现在为了节省成本打算数据库都放在一起，所以更多的是考虑稳定。

30 条回复 • 2018-06-13 13:45:35 +08:00

Sherlocker

2018-05-24 11:38:34 +08:00

说实话我们公司试了各种方案，还是主从靠谱

nullen

2018-05-24 11:51:54 +08:00

MGR 晚点再考虑吧，目前的话用 MHA。

biubiu2018

2018-05-24 12:23:23 +08:00

看你这配置也不像土豪公司，老实用主从。如果有事务需求，就更加只能先主从了。数据同步要求比较大的，就做个半同步。

koalawang

2018-05-24 13:38:00 +08:00

Azure Cosmos DB

jeffcott

2018-05-24 15:57:30 +08:00

我们是用 keepalived+主从做的，主要考虑到配置比较简单，运维成本低，也有基本的故障切换，基本上已经能够满足需求了...强答一下，抛砖引玉

AlfredL

2018-05-24 16:05:52 +08:00

感觉稳定性上来说还是用主从吧...
比较小的公司和系统用高可用方案更大概率是高可用方案的可靠性还没有 mysql 本身可靠性高碰到出问题的时候切换失败或者没出问题瞎切换都是自己给自己找麻烦...

q397064399

2018-05-24 16:27:15 +08:00

上云了，就直接买阿里的服务吧，别整那些乱七八糟的，你想要的基本上云都有，何必自己折腾？

zktz

2018-05-24 17:21:47 +08:00

@q397064399 国企，有自建机房，所以不能上云。

20has

2018-05-24 18:57:49 +08:00 via Android

主从吧 😅
我家也是小公司，之前很多想法，后面还是老实用主从。你的稳定些不好难道是经常物理机被关？？
优化方面就是多关注下慢查询优化 sql 语句索引优化 @AlfredL

yanginfor

2018-05-24 20:31:34 +08:00 via iPhone

我们公司用的组复制，大概一年了，比较稳定

update

2018-05-24 21:04:37 +08:00

@Sherlocker
请教下减少主从延迟这块有没有什么军规技巧之类的？

sadaharu09

2018-05-24 23:14:21 +08:00 via iPhone

我觉得除了 Azure Cosmos DB，我再也找不到第二种选择了。

Raymon111111

2018-05-24 23:26:52 +08:00

HA 做好

1. 核心库监控慢查询, 一旦有风险(突然增多)立马优化处理. 新上线导致立马回滚.
2. 权限回收, 手动执行 sql 一定 review(如果成本不是问题, 直接拉一台从库专门用作各种手动执行 sql)
3. 也是成本不是问题的话, 业务隔离. 核心业务和非核心业务用分离开的从库(非核心的业务往往有很多复杂易造成慢查询的 sql). 表也尽可能的根据业务拆分到不同库里, 尽可能解耦.
4. 监控读写 QPS, 能抗多少做压测. 然后打个 7 折, 每周有 review, 时时有报警. 如果是正常业务增长, 尽快着手拆库拆表.
5. 做好代码 review, 所有新上 sql 认真 review. 必要时压测再上线. 注意新增的量, 评估之后太大提早扩容.
6. sql 尽可能简单, 能不能关联查就不关联查(事务之类的更是尽可能不要用). 复杂查询直接上 es.
7. 尽量不要用批量 insert update 之类的语句, 会产生不太准的 QPS 指标从而影响容量判断.

iyaozhen

2018-05-24 23:27:35 +08:00

@update 5.7 后 MGR 基本没啥延迟
平均单表千万级数据量

yangqi

2018-05-24 23:28:32 +08:00

参考这个架构，不过需要读写分离。

https://thoughts.t37.net/how-we-upgraded-a-22tb-mysql-cluster-from-5-6-to-5-7-in-9-months-cc41b391895d

XiaoxiaoPu

2018-05-25 01:06:41 +08:00

场景：运维平台，读多，写入相对较少，期望达到无人介入快速自恢复。

架构：MGR，三节点一主两从，读写分离，实际演练写入中断 7s 左右，读服务影响很小

realpg

2018-05-25 01:26:19 +08:00

E5 2650+8G 内存这种奇怪的组合……

一代二代 E5 的平台内存那么便宜怎么不得 64G 128G 192G 啊

whx20202

2018-05-25 01:30:48 +08:00

话说共享存储不会是 IPSAN FCSAN 把，实际底层磁盘到底是什么能力咋样
要考虑到多个数据库在一起 IO 爆炸的情况。

incompatible

2018-05-25 01:38:34 +08:00

@Raymon111111 你说的全都挺好，但每条都跟高可用没关系啊

Raymon111111

2018-05-25 01:52:18 +08:00

@incompatible 难道高可用全是临场发挥完全不预防?

成天写慢 sql 一点不管高可用从何而来, 主库写过高从库同步都好几秒延迟了这等发现再把相关业务下掉?

昨天下午上了个新业务, 从库读翻两倍因为低峰期抗过去了, 完全没报警, 谁也没发现, 今天中午高峰期来了直接把数据库打挂了再处理?

wweir

2018-05-25 07:26:24 +08:00 via Android

MySQL 自身是个有状态的东西，它的高可用真心不是很多人想的那么简单。当然，如果你的业务对丢数据不敏感，也可以直接把一些无状态的手法往上套，这样下面的内容也就不用看了。

group replication 的底层实现依赖 paxos，而这玩意只是分布式共识协议。想用它做高可用，需要在其上做一系列的判断和调度。
普通的主从复制，如果丢数据啥的无所谓，可以上。不过依然需要有一些列计算来判断主实例的好坏。
其它还有一个更坑的半同步，这玩意是听起来简单，实际坑巨多。作为一个被坑得体无完肤的过来人，建议直接上 group replication。

还有，整个系统高可用的自恢复方案考虑过吗？不能一个节点挂了，就一直挂在那里。不然再挂一次，可就没有任何高可用冗余可用了

tianjusanren

2018-05-25 10:25:55 +08:00

其实你应该想一想，为什么外聘的 DBA 只愿意做主从？

tianjusanren

2018-05-25 10:27:58 +08:00

高可用的集群是需要人维护的，没有一套方案是配置完成以后，就可以一直跑下去的。
如果你有专职的 DBA，可以做高可用；如果没有，或者说能力不够维护高可用方案的话，还是怎么简单怎么来吧

zktz

2018-05-25 10:51:06 +08:00

@whx20202 不太懂这个，只知道是 EMC 牌的，其实数据库放到一个实例，还是多个实例，最终数据库都是在同一个存储上。目前从实际使用来说，io 队列延迟问题不大。

zktz

2018-05-25 10:54:12 +08:00

@tianjusanren 他说他就没做过其他方案。我看了好多 DBA 都是这样，一套方案用到老的样子，轻易不会改变。

yingfengi

2018-05-25 12:19:28 +08:00 via Android

买一台应用交付设备

bash99

2018-05-25 14:47:50 +08:00

@wweir 说的比较对，keepalived 这玩意没法用来做有状态的高可用。

MGR 之前，要么就是 MHA ；我们现在自用 Orchestrator

“ For replication, take a look at MHA and MySQL Orchestrator. Both are great tools to perform failover of a Replica.”
引自 https://www.percona.com/blog/2016/06/07/choosing-mysql-high-availability-solutions/
参考 https://www.percona.com/blog/2016/03/08/orchestrator-mysql-replication-topology-manager/

此外做了半同步，没处理物理 fence 防止脑裂。
自己做些点简单脚本切换 ip 以及切换 readonly。

incompatible

2018-05-25 16:58:28 +08:00

@Raymon111111 你说的都是应用层面如何防止单 mysql 节点性能下降或故障的准则。题主想问的是基础设施层面的高可用架构。

zktz

2018-05-29 17:32:37 +08:00

@incompatible 您说的对，应用层面由开发管（不让我做开发了）。我到时候开个慢查询日志给他们挑毛病就行了。我关心的重点是 1 高可用，2 易维护。

wps353

2018-06-13 13:45:35 +08:00

现在 MHA 靠谱。