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

[zktz]

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

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

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

[Sherlocker]

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

[nullen]

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

[biubiu2018]

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

[koalawang]

Azure Cosmos DB

[jeffcott]

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

[AlfredL]

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

[q397064399]

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

[zktz]

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

[20has]

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

[yanginfor]

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

[update]

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

[sadaharu09]

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

[Raymon111111]

HA 做好

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

[iyaozhen]

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

[yangqi]

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

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

[XiaoxiaoPu]

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

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

[realpg]

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

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

[whx20202]

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

[incompatible]

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

[Raymon111111]

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

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

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