有很多同学,在使用过Galera Cluster之后,发现很多问题,最大的比如DDL的执行,大事务等,从而导致服务的不友好,这也是导致很多人放弃的原因.
- DDL执行卡死传说:使用过的同学可能知道,在Galera Cluster中执行一个大的改表操作,会导致整个集群在一段时间内,是完全写入不了任何事务的,都卡死在那里,这个情况确实很严重,导致线上完全不可服务了,原因还是并发控制,因为提交操作设置为串行的,DDL执行是一个提交的过程,那么串行执行改表,当然执行多久,就卡多久,直到改表执行完,其它事务也就可以继续操作了,这个问题现在没办法解决,但我们长期使用下来发现,小表可以这样直接操作,大一点或者更大的,都是通过osc(pt-online-schema-change)来做,这样就很好的避免了这个问题.
- 挡我者死:由于Galera Cluster在执行DDL时,是Total Ordered Isolation(wsrep_OSU_method=TOI)的,所以必须要保证每个节点都是同时执行的,当然对于不是DDL的,也是Total Order的,因为每一个事务都具有同一个GTID值,DDL也不例外,而DDL涉及到的是表锁,MDL锁(Meta Data Lock),只要在执行过程中,遇到了MDL锁的冲突,所有情况下,都是DDL优先,将所有的使用到这个对象的事务,统统杀死,不管是读事务,还是写事务,被杀的事务都会报出死锁的异常,所以这也是一个Galera Cluster中,关于DDL的闻名遐迩的坑.不过这个现在确实没有办法解决,也没办法避免,不过这个的影响还算可以接受,先可以忍忍.
- 不死之身:继上面的“挡我者死”,如果集群真的被一个DDL卡死了,导致整个集群都动不了了,所有的写请求都Hang住了,那么可能会有人想一个妙招,说赶紧杀死,直接在每个节点上面输入kill connection_id,等等类似的操作,很不愿意看到的信息报了出来:You are not owner of thread connection_id.此时可能有些同学要哭了,不过这种情况下,确实没有什么好的解决方法(其实这个时候,一个故障已经发生了,一年的KPI也许已经没有了,就看敢不敢下狠手了),要不就等DDL执行完成(所有这个数据库上面的业务都处于不可服务状态),要不就将数据库直接Kill掉,快速重启,赶紧恢复一个节点提交线上服务,然后再考虑集群其它节点的数据增量的同步等,这个坑非常大,也是在Galera Cluster中,最大的一个坑,需要非常小心,避免出现这样的问题.
4. 适用场景
现在对Galera Cluster已经有了足够了解,但这样的“完美”架构,在什么场景下才可以使用呢?或者说,哪种场景又不适合使用这样的架构呢?针对它的缺点,及优点,我们可以扬其长,避其短.可以通过下面几个方面,来了解其适用场景.
- 数据强一致性:因为Galera Cluster,可以保证数据强一致性的,所以它更适合应用于对数据一致性和完整性要求特别高的场景,比如交易,正是因为这个特性,我们去哪儿网才会成为使用Galera Cluster的第一大户.
- 多点写入:这里要强调多点写入的意思,不是要支持以多点写入的方式提供服务,更重要的是,因为有了多点写入,才会使得在DBA正常维护数据库集群的时候,才会不影响到业务,做到真正的无感知,因为只要是主从复制,就不能出现多点写入,从而导致了在切换时,必然要将老节点的连接断掉,然后齐刷刷的切到新节点,这是没办法避免的,而支持了多点写入,在切换时刻允许有短暂的多点写入,从而不会影响老的连接,只需要将新连接都路由到新节点即可.这个特性,对于交易型的业务而言,也是非常渴求的.
- 性能:Galera Cluster,能支持到强一致性,毫无疑问,也是以牺牲性能为代价,争取了数据一致性,但要问:”性能牺牲了,会不会导致性能太差,这样的架构根本不能满足需求呢?”这里只想说的是,这是一个权衡过程,有多少业务,QPS大到Galera Cluster不能满足的?我想是不多的(当然也是有的,可以自行做一些测试),在追求非常高的极致性能情况下,也许单个的Galera Cluster集群是不能满足需求的,但毕竟是少数了,所以够用就好,Galera Cluster必然是MySQL方案中的佼佼者.
5. 总结
综上所述,Galera Cluster是一个完全可依赖的,MySQL数据一致性的绝杀利器,使用中完全不需要担心数据延迟,数据不一致的问题,DBA从此就从繁复的数据修复、解决复制延迟、维护时担心影响业务的问题中彻底解脱了.可以说Galera Cluster是DBA及业务系统的福音,也是MySQL发展的大趋势,我希望它会越来越好,也希望也有越来越多的人使用它,共同维护这个美好的大环境.
原文来自微信公众号:Qunar技术沙龙
(编辑:ASP站长网)
|