1
Sherlocker 2018-05-24 11:38:34 +08:00
说实话我们公司试了各种方案,还是主从靠谱
|
2
nullen 2018-05-24 11:51:54 +08:00
MGR 晚点再考虑吧,目前的话用 MHA。
|
3
biubiu2018 2018-05-24 12:23:23 +08:00
看你这配置也不像土豪公司, 老实用主从。 如果有事务需求,就更加只能先主从了。 数据同步要求比较大的,就做个半同步。
|
4
koalawang 2018-05-24 13:38:00 +08:00
Azure Cosmos DB
|
5
jeffcott 2018-05-24 15:57:30 +08:00
我们是用 keepalived+主从做的,主要考虑到配置比较简单,运维成本低,也有基本的故障切换,基本上已经能够满足需求了...强答一下,抛砖引玉
|
6
AlfredL 2018-05-24 16:05:52 +08:00 1
感觉稳定性上来说 还是用主从吧...
比较小的公司和系统 用高可用方案 更大概率是高可用方案的可靠性还没有 mysql 本身可靠性高 碰到出问题的时候切换失败或者没出问题瞎切换都是自己给自己找麻烦... |
7
q397064399 2018-05-24 16:27:15 +08:00
上云了,就直接买 阿里的服务吧,别整那些乱七八糟的,你想要的基本上云都有,何必自己折腾?
|
8
zktz OP @q397064399 国企,有自建机房,所以不能上云。
|
9
20has 2018-05-24 18:57:49 +08:00 via Android
|
10
yanginfor 2018-05-24 20:31:34 +08:00 via iPhone
我们公司用的组复制,大概一年了,比较稳定
|
11
update 2018-05-24 21:04:37 +08:00
@Sherlocker
请教下减少主从延迟这块有没有什么军规技巧之类的? |
12
sadaharu09 2018-05-24 23:14:21 +08:00 via iPhone
我觉得除了 Azure Cosmos DB,我再也找不到第二种选择了。
|
13
Raymon111111 2018-05-24 23:26:52 +08:00 2
HA 做好
1. 核心库监控慢查询, 一旦有风险(突然增多)立马优化处理. 新上线导致立马回滚. 2. 权限回收, 手动执行 sql 一定 review(如果成本不是问题, 直接拉一台从库专门用作各种手动执行 sql) 3. 也是成本不是问题的话, 业务隔离. 核心业务和非核心业务用分离开的从库(非核心的业务往往有很多复杂易造成慢查询的 sql). 表也尽可能的根据业务拆分到不同库里, 尽可能解耦. 4. 监控读写 QPS, 能抗多少做压测. 然后打个 7 折, 每周有 review, 时时有报警. 如果是正常业务增长, 尽快着手拆库拆表. 5. 做好代码 review, 所有新上 sql 认真 review. 必要时压测再上线. 注意新增的量, 评估之后太大提早扩容. 6. sql 尽可能简单, 能不能关联查就不关联查(事务之类的更是尽可能不要用). 复杂查询直接上 es. 7. 尽量不要用批量 insert update 之类的语句, 会产生不太准的 QPS 指标从而影响容量判断. |
15
yangqi 2018-05-24 23:28:32 +08:00
|
16
XiaoxiaoPu 2018-05-25 01:06:41 +08:00
场景:运维平台,读多,写入相对较少,期望达到无人介入快速自恢复。
架构:MGR,三节点一主两从,读写分离,实际演练写入中断 7s 左右,读服务影响很小 |
17
realpg 2018-05-25 01:26:19 +08:00
E5 2650+8G 内存这种奇怪的组合……
一代二代 E5 的平台 内存那么便宜 怎么不得 64G 128G 192G 啊 |
18
whx20202 2018-05-25 01:30:48 +08:00
话说共享存储不会是 IPSAN FCSAN 把,实际底层磁盘到底是什么 能力咋样
要考虑到多个数据库在一起 IO 爆炸的情况。 |
19
incompatible 2018-05-25 01:38:34 +08:00
@Raymon111111 你说的全都挺好,但每条都跟高可用没关系啊
|
20
Raymon111111 2018-05-25 01:52:18 +08:00
@incompatible 难道高可用全是临场发挥完全不预防?
成天写慢 sql 一点不管高可用从何而来, 主库写过高从库同步都好几秒延迟了这等发现再把相关业务下掉? 昨天下午上了个新业务, 从库读翻两倍因为低峰期抗过去了, 完全没报警, 谁也没发现, 今天中午高峰期来了直接把数据库打挂了再处理? |
21
wweir 2018-05-25 07:26:24 +08:00 via Android
MySQL 自身是个有状态的东西,它的高可用真心不是很多人想的那么简单。当然,如果你的业务对丢数据不敏感,也可以直接把一些无状态的手法往上套,这样下面的内容也就不用看了。
group replication 的底层实现依赖 paxos,而这玩意只是分布式共识协议。想用它做高可用,需要在其上做一系列的判断和调度。 普通的主从复制,如果丢数据啥的无所谓,可以上。不过依然需要有一些列计算来判断主实例的好坏。 其它还有一个更坑的半同步,这玩意是听起来简单,实际坑巨多。作为一个被坑得体无完肤的过来人,建议直接上 group replication。 还有,整个系统高可用的自恢复方案考虑过吗?不能一个节点挂了,就一直挂在那里。不然再挂一次,可就没有任何高可用冗余可用了 |
22
tianjusanren 2018-05-25 10:25:55 +08:00
其实你应该想一想,为什么外聘的 DBA 只愿意做主从?
|
23
tianjusanren 2018-05-25 10:27:58 +08:00
高可用的集群是需要人维护的,没有一套方案是配置完成以后,就可以一直跑下去的。
如果你有专职的 DBA,可以做高可用;如果没有,或者说能力不够维护高可用方案的话,还是怎么简单怎么来吧 |
24
zktz OP @whx20202 不太懂这个,只知道是 EMC 牌的,其实数据库放到一个实例,还是多个实例,最终数据库都是在同一个存储上。目前从实际使用来说,io 队列延迟问题不大。
|
25
zktz OP @tianjusanren 他说他就没做过其他方案。我看了好多 DBA 都是这样,一套方案用到老的样子,轻易不会改变。
|
26
yingfengi 2018-05-25 12:19:28 +08:00 via Android
买一台应用交付设备
|
27
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。 |
28
incompatible 2018-05-25 16:58:28 +08:00
@Raymon111111 你说的都是应用层面如何防止单 mysql 节点性能下降或故障的准则。题主想问的是基础设施层面的高可用架构。
|
29
zktz OP @incompatible 您说的对,应用层面由开发管(不让我做开发了)。我到时候开个慢查询日志给他们挑毛病就行了。我关心的重点是 1 高可用,2 易维护。
|
30
wps353 2018-06-13 13:45:35 +08:00
现在 MHA 靠谱。
|