大规模MySQL运维陷阱：使用MyCat踩坑篇
|
我们现在讨论的是分布式架构方案，而这个问题讲的情况是，某一个MyCat发现了后端数据库连不上了，会自动切换的功能，这就非常明显了，我们要的是分布式，某“一个”MyCat节点认为的问题就真的是他所认为的吗?也就是说，一个节点并不能保证他判断的或者他看到的现象是真实的，那这种情况下就存在误切换的情况，而如果其它中间层节点还不知道这个情况，或者未及时收到切换的消息，就出现了多点写入的问题，挺可怕的。这不是自相矛盾吗?我们要的是分布式，结果又存在“独断”的环节，可靠性又下降了不少。关于分布式监控切换的问题，因为在去哪儿用的mysql-sentinel对Galera Cluster做的监控，我对这点深有感触，所以不得不在这里讲一下。 在MyCat上面备份是如何做的?能做到恢复一个快照吗? 说起备份，做为数据库使用者，应该没有一个不清楚，没有一个人会觉得他不重要吧?当然，重要是重要，但这种事情属于重要不紧急的工作，但没有是不行的，这个连公司内审这一关都过不了，也许我们每一个人都不会希望能用到他。 言归正传，话说这么重要的备份工作，在MyCat上又是什么情况呢?可能了解一些基本原理的人都比较清楚，Xtrabackup、mysqldump等也都是可以用的，但备份完了之后呢，可能心里还是感觉没底，因为这样的工具，只能对一个MySQL节点做备份，如果分10个分片(10个MySQL节点)的话，可以通过备份十次即可完成，但需要注意的是，备份了十次产生了十个备份集，而并不是一个备份集，这十个备份集之间是完完全全没有关系的，此时我可能就提出一个比较极端的问题来： 如果哪天(当然我们都不希望有这样的一天)，整个机房挂了，当然假如“幸运”的是，有备份，那在这种情况下，如何恢复一个可用的数据一致及完整的集群快照呢? 这个时候可能会有人很快地说，将十个备份集都恢复了启动了即可。但问题是这十个没有关系，备份时间又不是同一时刻完成的，同一个表的十个分片，最新数据有的是8点的，有的是9点的，或者有的甚至是昨天的。这样恢复出来的表，能用么?基于这样的表产生的查询结果，靠谱么?可想而知。 当然可能也有人会说，我们的数据不需要一致快照，或者更有甚者只需要备份元数据路由表或者配置文件即可，那这样就没问题了，如果MyCat只是定位于用来存储Zabbix监控数据，或者日志数据，可以丢失不要的数据，一文不值的数据，那我觉得没毛病。 或许有人还会说，我们的机房不会挂，或者我们的存储本来就是跨机房的，挂了的话直接切到另外的机房就行了，那此时又有问题了，如果切换的时候，有复制延迟，丢失了部分数据，那整个集群又会出问题，因为只要有一个分片的数据出问题，整个集群就有问题了。或者另一个问题就是，假设你的机房真的不会挂，但我们经常会遇到的需求是，我要取前几天某时刻的数据，那此时还是需要通过备份然后恢复一个快照，这个时候还有何话可说，你告诉我究竟如何做到? 可能还会有人有疑问，他会说我们是逻辑备份啊，这样备份出来的是整个库或者表的一致性快照，这不就解决问题了么?我很同意这位同学的看法，说得对极了，是可以很完美地解决一致性问题，但只要熟悉一点点MySQL的人都知道，类似mysqldump这样的逻辑备份工具，是何其慢?现在都用分布式存储了，那肯定是数据量非常大，这个时候还在使用这样的逻辑备份?你是想干哈?即使备份完成了，那有没有试过逻辑数据的恢复?几个G的数据要恢复多久，你算过没有?想想都头疼。一条不归路。。。 如果已经在使用MyCat了，发现他的风险确实太大了，我如何能下掉呢? 这个问题非常好，说明你已经在思考做为一个数据负责人，如何保证数据的可靠性和避免风险的问题了，MyCat风险确实高，但如果已经上了“贼船”并且想下掉的话，此时我可能想问一下(做一回事后诸葛亮)，上这个架构的时候为什么不多考虑一下呢?公司的数据就是金钱，你这样想上就上，想下就下，来回折腾，能升值么?万一数据写乱了，这个时候可没有人赔你钱，还不如上云呢。 不过既然上了，那咱就聊聊如何下掉的问题，我目前感觉最靠谱最稳妥的办法，貌似只有一个，步骤如下： 先停业务，将所有的写业务都停止(也不用找深夜时间了，因为12小时根本搞不完)。 通过上面所讲的mysqldump做逻辑备份，将所有的库导出来，生成.sql文件。 然后找一个靠谱的MySQL架构(真正的分布式数据库，或者磁盘足够大的话可以不采用分布式，采用Share Nothing的方案即可，也许你需要的并不是分布式，只是被忽悠了)，将.sql文件导入进去。 然后就将读业务迁移到新的数据库架构上面去。 将写业务也迁移到新的数据库架构上面去，然后启动他们，这个时候应该是可以提供正常的数据库服务了。 我们可以注意一下这个过程，从第1步，到第5步，需要多少时间?这个当然是硬时间，是要移动数据的，逻辑备份和恢复都那么慢，我觉得时间的单位可以用天来统计了。 这个时候负责人就可以想想，我用MyCat是图什么啊，业务的免战牌挂了好几天，只是为了弥补当年的一个错误决定，追悔莫及。 当然也许有些人也会有其它办法，但因为各个分片都是相互独立的，还是存在上面的所说的在不停止业务的情况下的“一致性快照”的问题。 最后我想说的是，对公司的数据，一定要慎之又慎，要时刻保持负责的态度，折腾数据真的不能升值啊。 MyCat的配置复杂吗?上手容易么? 我们只需要看一个图片就行了。你能想象这是它的配置文件么?看了之后我估计你也没有任何使用它的欲望了，很多人在使用之后，是这样评价的：  配置文件如下：  竟然是一个XML文件，这个产品经理当时是如何想的?后面也没有想着做个优化? 最后一个问题，现在做分库分表做得好的有哪些? （编辑：三明站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |