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

[zktz]

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

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

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

[wweir]

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

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

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

[tianjusanren]

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

[tianjusanren]

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

[zktz]

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

[zktz]

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

[yingfengi]

买一台应用交付设备

[bash99]

@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]

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

[zktz]

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

[wps353]

现在 MHA 靠谱。