大规模MySQL运维陷阱：基于MyCat的伪分布式架构

分布式数据库已进入全面快速发展阶段。这种发展是随着时间的推移而进步的，与人们的需求密不可分。由于当前信息时代的快速发展，信息量和事件量不断增加。这种现象首先导致的就是存储瓶颈，因为MySQL数据库本质上是一个独立版本的数据库。只要是单机版，它必然要面临的问题之一就是存储问题，因为存储空间是一个硬性的要求，而CPU和内存如果没有足够的，就意味着性能很差，不直接消灭它。解决方案或架构。事实上，我们每个公司或个人都在为解决存储问题而努力。解决方案大概有三种： ： 增加磁盘 这个方法应该是最直接、最简单的解决方案，因为磁盘空间不够，加一块磁盘当然很容易。如果现在是800G，可以提升2T。这不是问题。如果现在达到了2T，当然还可以增加到5T盘，但事实上，DBA此刻可能会担心。那么，如此大的数据量，如何运维MySQL实例呢？如果数据损坏了，如何恢复？时间成本呢？ 5T的数据量已经非常恐怖了。估计业内大公司里，DBA要自己管理和维护的MySQL实例都达不到这个数量级吧？其实我个人认为这是一个无法忍受的量，最合适的办法就是控制在1吨以下。如果超出这个范围，我们就得想办法了。当然，数据量不应该达到这个大小的原因是有些人可能认为这是一个性能问题。其实不然，或者说性能问题很小，因为InnoDB采用的是B+树存储方案，最坏情况下小表是查询不到的。获取数据需要找到3个level，所以需要3个page IO，大表需要4个page IO影响不大。 数据压缩为了减少数据占用的磁盘空间，通常也会对数据进行压缩，只需一条命令即可完成。这是InnoDB原生支持的方法。一般情况下，数据是经过压缩的。使用率比原来减少了三分之一到一半，效果还是足够明显的。然而，以这种方式处理的数据的性能会降低。如果公司的应对要求比较高，可能需要慎重考虑，但这种方法可能还是治标不治本。如果数据量持续增长，在一段时间后你仍然会面临同样的问题。在这种情况下，您无法继续使用此方法来实现它。数据共享数据共享解决方案在当今行业中得到广泛使用。这个方案已经超越了MySQL本身，包括HBase、Redis等都使用这个方案。必须说，这个方案是可扩展性最强的，可以说是无限可扩展的，而上面的两种方案根本不具有可扩展性。为此，这种方案已经成为业界的主流，也只有这种方案才能称为分布式存储位置。有无数的特殊实现。当然，也有优秀的去中心化解决方案和一些“伪”去中心化解决方案。 分布式解决方案的要求 可扩展性 使用分布式时最重要的实际上是可扩展性。如果空间不够，可以轻松扩展节点数量，平衡数据。处理。此过程不得影响业务使用，并对公司透明。 支持交易。这是必要的，所以总而言之，去中心化的活动必须得到支持。 SQL语句无限制业务需求的多样性导致SQL需求种类繁多。为了业务透明性，如果不支持某些SQL语句，由此带来的问题是：一方面限制了业务程序的功能和性能；另一方面限制了业务程序的功能和性能。另一方面，它给业务程序与“分布式数据库”捆绑带来了问题。 性能足够好事实上，只有性能要求比较低的公司才会选择使用分布式数据库。尽管如此，性能越高，选择这种分布式数据库的人就越多。 。 元数据更改的透明度任何数据库中都存在元数据更改。在单点的情况下，我们有几种友好的方法来实现表编辑操作，但是在分布式环境中，这个操作就会成为问题，因为数据碎片导致元数据改变需要多次改变，就会出现很多问题，比如原子性。 、数据可见性、正确性等等，所以这是最简单的Problem。 后端数据库高可用都说财务基础决定上层建筑，分布式数据库也是如此。如果底层数据库不稳定，数据复制延迟，或者出现数据不一致问题，上层应用无法保证访问的正确性，所以底层数据库最根本的是保证数据一致性（高可用）。 。流行的分布式数据库解决方案中间件子库和分表（伪分布式）MySQL界一个长期存在的话题：哪个中间件实现了更好的子库和表架构？啊？当然，不同的人对同一问题的理解是不同的，而且都有两面性。有人说好，有人说不好。首先，让我们看看如何实现这个解决方案。

MyCat的实现架构大致如上图所示。事实上，如果单看图片的话，这个架构确实非常完美。自动分片、自动合并和分布平衡都实现得很好。但事实并非如此。

让我们通过问答一步步了解这个方法的核心问题：

MyCat是如何知道信息共享的原理或者说它是如何决定路由路径的？

这个问题在图片中看不到。 MyCat如何定义或决定如何执行SQL语句，或者如何决定从哪里获取数据以及将数据写入哪里？为了解决这样的问题，你需要一个特定的地方来存放它。实现方法是 - schema.xml 配置文件，它实际上是使用配置文件解析的。那么问题就很多了。编辑子库和表规则后如何保证配置和数据同步更新？即使不使用schema.xml配置文件，而是使用数据库存储，配置规则的变更以及跨数据节点的数据迁移也不能保证一致，不可避免地会对业务产生影响。

如果你想扩大结并重新平衡，你该怎么做？

很多用户基本准备一个新的集群，或者先手动一点点导出导入数据，然后导入到目标节点，然后手动编辑schema.xml配置文件，然后执行reload操作。这是实现的。需要重新路由，但这也会导致上面提到的结果。另外，这个过程需要大量的数据处理、处理完成后的各种检查，并且占用两倍的空间。受到这样的诱惑，DBA可能会有辞职的冲动。

什么是全局表？

MyCat 支持所谓的全局表，解决节点之间数据合并的问题。实现方法就是为每个分片创建一个这样的全局表。它的定义没有太大改变，查询也更加频繁。它可以被定义为一个全局数组。这样的话，只要使用这张表，就可以在各个分片节点上实现本地查询连接等操作。这样可以解决一些问题，但问题是如果分片很多（比如说100个分片），如何保证数据的一致性？ XA交易对这么多节点有什么影响？如果出现不一致或者操作错误，问题就是数据输出不正确。这样的结果绝对不是一个企业愿意看到的不是吗？这还不是最重要的。数据库集群如此特殊对待的原因是什么？

MyCat 到底是做什么的？

作为中间层，我的工作应该是接收客户端的SQL请求，然后利用语法分析，根据读写原理，从集群中确定读写节点并等待返回。从结果集中。中间层不需要关心结果集本身。它所需要做的就是将结果集（或异常）完整地发送回客户端。 MyCat 的作用远不止于此。语法分析后，进行语义分析，得到对应的数据库表结构。同时，它确定这张表的分发的路由规则，查找语句及其关联列中的信息，然后确定路由到哪个分片。如果分发时路由规则配置不正确或者程序计算不正确，则整个指令的结果是不可预测的。请问这就是中间层应该做的前半部分吗？你甚至还得关心表结构、主键、数据等与表达式相关的信息。这实际上是数据库的工作。事实上，这只是越界了。再说一遍，你能比专业数据库做更多这些事情吗？好的？我们再看下半场。 MyCat收到一个结果集后，为了处理一些结果集聚合计算，需要解析各个节点封装的结果集（二进制MySQL协议流数据），然后根据需要进行计算（这样计算可能会很慢而且不能全部计算）可以做到）。计算完成后，打包成MySQL协议数据流转发给客户端。这样一个中间层做了这么多事情，性能如何保证呢？ ？处理这些聚合计算是数据库自己排序分组的事情，但实际上还是别人来做的。

通过改造SQL语句实现分布式是不是有点困难？

MyCat，中间层，代表了一种声称是分布式数据库的实现，但这种实现实际上是基于SQL语句的。从客户处收到 SQL 命令，该命令稍后给出。最终的数据库也是一条SQL语句，只不过这两条SQL语句进行了变换。当然这种方式只能是这样，因为后端数据库只接收SQL命令。请问，复杂的SQL语句查询操作可以通过SQL改造或者重写分布式查询到不同的分片数据库来实现吗？当你想一想就清楚了。虽然SQL语句通用且灵活，但是可扩展性或者重写逻辑还是有点复杂，对吧？当然，有人可能会说我们有保证。最坏的情况下，我们可以只更改该命令的库和数组名称，并保持其他内容相同，并将它们分配给每个节点来执行。这样就不会有问题了。是的，你错了。错误的。

如何编辑同一个交易中不同节点的数据？

这个问题通常称为分布式事务。究竟发生了什么？ MyCat面向MySQL Server，这意味着MyCat只能使用SQL语句与MySQL Server通信，这受到限制，现在MySQL有SQL语句的工作，在分布式实现方面，有多少人使用MySQL XA本身？如果MyCat在没有MySQL XA的情况下实现跨节点数据更新，还能用什么？没有其他选择。它基于一个没有多少人使用的功能，并且可能存在很多问题，包括性能和错误。如何保证上层MyCat乃至应用的可靠性？当然，基于这些问题，有些解决方案选择不使用XA。如果某些节点出现故障，它们会选择忽略它并且不解决它。这当然是完全没问题的。这是一种妥协——没有最终结果。

MyCat后台数据库的架构是怎样的，如何保证稳定性、可靠性和高可用性？

根据一些文章，以前可以选择主从复制，但现在可以选择 Galera Cluster，也可以选择较新的 MGR。当然，不得不说，从前到后确实能够保证更好的可靠性。但很大的问题是Galera的门槛比较高。如果遇到问题，很少有人能解决（我很自豪去哪儿可以说是世界上少数几个越来越多地使用Galera的人之一。（比较不错的努力），然后MGR还得等，而且还要很久才能用，这个问题还没有回到主从复制，这是老问题了，很难保证主从复制的一致性，如果MyCat使用读-写分离策略是从上往下读，正好有延迟，导致整个应用的计算结果可能会出错，当然你可以说是延迟检查，问题出在延迟检查上，如果那么，还有其他参数可以设置吗？如果延迟超过100秒，检查主数据库？没错，但是延迟不是100秒吗？可以设置为0。你认为你看到的0真的是0吗? 其实还是主从复制的一个缺点。所以问题还是回到了起点。经济基础决定上层建筑。如果基础不好，上层怎么办？

碎片过多时如何保证性能损失最小？

关于这个问题，我不知道MyCat是否优化过。例如，如果有10个分片，如果一条指令的执行涉及这十个分片，那么重写为每个分片编写的指令后，针对这十个分片执行相应的指令。性能是串行还是并行？如果是串行的话，性能必然会下降10倍以上，所以如果做得更好的话，那就是并行了。但并行的实现是在MyCat连接上创建10个线程来执行这十个节点。 ，如果这样的连接太多，MyCat会对系统产生巨大的影响，性能仍然很差。当然，这里也可以说是使用了连接池。是的，这是可能的，但是 MyCat 能做到这一点吗？如果这样做的话性能如何？如果超时，整个访问就会失败。

如果配置文件或配置库出现问题，整个集群会怎样？

前面提到，MyCat 使用 schema.xml 文件来定义子库和表策略。这是一个配置文件。 MyCat 本身非常易于访问。如果定义了多个集合，如何解决它们的同步问题？从哪里来？如果没有同步（或者同步问题或者延迟等），某个特定的MyCat挂掉了，当服务切换到另一个MyCat时，目前的情况是失败...错误...因为数据乱了。一个可能的问题是写入了错误的位置，在这种情况下整个集群的数据被写入损坏。感觉比直接去掉还糟糕。我也有同样的问题。我认为 MyCat 可以对此进行优化，也许而不是将其集中存储在特定的数据库中。这样就不需要同步进行集中管理。想法是好的，但这相当于把鸡蛋放到数据库里。如果购物车这个配置库出了问题，业务去哪里？

DDL 如何工作？

这个问题可能是大家都担心的。 MyCat将数据分发到不相关的分片MySQL节点。这样一来，某一点上的很多表修改策略就无法使用了，而DDL又是需要保证每个节点同时执行事情的。如何以去中心化的方式确保这一点？从我的研究看来​​​​​​现在使用MyCat的人都是用“同时开始更新每个节点的表结构”的方法。当然，你必须选择在半夜进行。当然，我个人认为是有可能的。因为已经用了，也没有更好的办法解决问题。当然，让我们谈谈后果。如果不能实现无缝的原子转换，那么对业务的影响不可谓不大，SQL报表可能会有很多不存在的问题。如果一个句子和另一个句子的编辑完成时间相差较大，则两次时间相减就是失败时间。

根据我的研究，MyCat还实现了自动容错功能。这可靠吗？

现在讨论分布式架构方案，本题讲的是某MyCat检测到后端数据库无法自动合并切换。这是非常明显的。我们想要去中心化，问题是“一个”MyCat节点真的想它所想吗？换句话说，节点无法保证它评估或看到的现象是真实的。这样的话就出现了错误连接的情况，而如果其他中间层节点没有意识到这种情况或者当我收到连接消息时没有及时收到信息，就出现了多点问题。写作，这是相当可怕的。这不是矛盾吗？我们想要的是共享，但结果却是“任意”链接，可靠性下降很多。关于切换分布式监控的问题，由于我在Qunari中使用mysql Sentinel监控Galera Cluster，对此感触颇深，所以这里不得不说一下。

如何在MyCat中备份？是否可以恢复快照？

说到备份，作为数据库用户应该不会不清楚。没有人会认为这微不足道，不是吗？当然重要，但是这样的事情重要，但是不紧急，但是没有它也是不行的。它甚至无法通过公司的内部审核，我们可能都不想使用它。

回归正题，说起这么重要的备份工作，MyCat 的情况怎么样了？了解一些基本原理的人可能知道，Xtrabackup、mysqldump等也可以使用，但备份后你可能还是感觉不安全，因为此类工具只能备份一个MySQL节点。如果分成10个分片（10个MySQL节点），则可以通过备份十次来执行。但需要注意的是，十个备份产生十个备份集，而不是一个备份集。这十个备份系列之间没有任何联系。此时，我可能会提出一个更极端的问题：

如果有一天（当然我们不希望有这样的一天），整个机房宕机了，当然如果“还好有备份，但是在这种情况下，如何恢复具有可用数据的一致且完整的集群快照呢？

此时，有人可能会很快说恢复所有十个备份集并启动它们，但问题是这十个与互不影响，且备份时间不是同时完成的，同一个表的十个分片，最新的数据有的在8点，有的在9点，有的甚至是昨天的，可以吗这样返回的表可以用吗？这样的表生成的查询结果可靠吗？可想而知。

当然，有人可能会说我们的数据不需要一致的快照，或者更糟糕的是我们只需要备份元数据路由表或者配置文件，那么这不是问题，如果MyCat只用于保存Zabbix监控数据或者日志数据时，可能会丢失不必要的数据和无价值的数据，所以我认为没有什么问题。

也有人会说我们机房不插电话或者我们的仓库本来就在机房对面。如果坏了，我们可以切换到另一个机房。那么现在又出现了另一个问题。如果我们切换的话，如果出现复制延迟，部分数据丢失，那么整个集群就会出现问题，因为只要其中一个分片的数据出现问题，整个集群就会出现问题。或者另一个问题是，假设你的机房并没有真正宕机，但是我们经常遇到的一个需求是我想检索过去几天的某个特定时间的数据。现在我仍然需要备份和恢复快照。这我还能说什么，告诉我该怎么做？

有些人可能还有疑问。他们说我们做了逻辑备份。这样，备份就是整个库或表的一致快照。这不就解决问题了吗？我完全同意这位同学的观点。他是绝对正确的。可以完美解决一致性问题。然而熟悉MySQL的人都知道，像mysqldump这样的逻辑备份工具是非常慢的。现在采用分布式存储的时候，数据量肯定非常大。您现在还在使用这种逻辑备份吗？你想做吗？即使备份完成，您是否尝试过逻辑数据恢复？您是否计算过恢复几GB数据需要多长时间？光是想想就让人头疼。到了没有回头路的地步。 。 。

如果您已经使用MyCat并且发现它风险太大，我该如何下载它？

这是一个非常好的问题。这说明你作为信息的负责人，已经在思考如何保证信息的可靠性，规避风险。 MyCat 的风险确实很高，但如果你已经登上了“隐形船”并想要如此的话，我可能会问此时（只是事后诸葛亮）你为什么没有多考虑一下。当你采用这种架构时？公司信息就是金钱。如果你想涨多少，你就可以跌多少。如果不断地来来回回，它还能增值吗？如果数据搞乱了，现在没有人会补偿你，所以你还不如去云端。

不过既然说到了这个话题，我们就来说说如何出去吧。目前，我认为只有一种最可靠、最安全的方法。步骤如下：

首先停止业务，记下所有的书写工作。停止（无需寻找深夜时间，因为你无法在 12 小时内停止）。

进行逻辑备份，导出所有库并使用上面提到的 mysqldump 创建 .sql 文件。

那就找一个可靠的MySQL架构（真正的分布式数据库，或者磁盘足够大的话，就不用分布式了，用Share Nothing就可以了。也许你需要的不是分布式的，只是你被骗了.），将.sql文件导入其中。

然后将阅读业务迁移到新的数据库架构上。

将写作业务迁移到新的数据库架构上，然后启动它们。此时应该提供正常的数据库服务。

我们可以关注这个过程。从步骤 1 到步骤 5 需要多长时间？当然，这是一个困难的时期，因为需要传输数据。逻辑备份和恢复太慢了。我觉得时间的单位可以用天来衡量。

此时，负责人可以想想我用MyCat做什么。营业免检证挂了好几天了，就是为了纠正当年的错误决定，后悔已经来不及了。

当然，有些人可能还有其他方法，但由于各个分片相互独立，所以在业务不停止的情况下，仍然存在上述“统一快照”问题。

最后我想说的是，大家一定要非常小心自己的公司信息，时刻保持负责的态度。混合数据并不能真正增加价值。

配置MyCat复杂吗？容易上手吗？

我们所要做的就是看图片。你能想象这是它的配置文件吗？读完之后，我想你不会想使用它。很多人用后都这样评价：

。配置文件如下：

原来是一个XML文件。产品经理当时在想什么？从哪里来？后期没有考虑优化吗？

最后一个问题，现在共享数据库和表的最佳方式是什么？

还有什么？那里没人。这是一条不归路。因为坦率地说，这是一个看似去中心化的解决方案。底层不好，上层应付不了，所以总是代替各种陷阱，对别人、对自己来说都是很累很累的。现在你回过头来可能会想，为什么一些非常有实力的知名公司做的中间件产品，比如ProxySQL、Maxscale、MySQL Router等，不做这些事情。为什么？他们的技术很差吗？或者有这样的需求吗？我觉得还是有需求的。人和公司的需求是一样的，但解决方案可能不同。他们可能早就认为这是一条错误的路，所以他们不去那里。如果您决定采用像 MyCat 这样的解决方案，您可能必须回顾并思考未来。 互联网处理大规模在线使用数据的方法断开连接的思想渗透到互联网技术堆栈的各个方面。为什么要这样做？我想是因为大家都不想拖延，不想影响整个局势。在MySQL数据库层面，使用了重度的中间层之后，你会发现合并看起来不错，但是却能牵一发而动全身，这其实并不是一件好事。 MySQL这样的数据库诞生于互联网领域并得到广泛应用。它们还应用于很多关键行业，例如会计、订购、进销存等。在大型互联网公司中，MySQL的使用必须分为数据库和表。借助各种纵向和横向切分，由一个数据库形成一组数据库，即所谓的数据库集群。然而，在使用它的时候，你很少会看到一个沉重的所谓的built for MySQL。分布式中间层。这导致紧密耦合，这与互联网的高效多式联运相矛盾。互联网上的所有数据库集群必须是物理隔离的，每个实例都可以自由控制和移动，这就是解耦。

解耦的好处是可以让你自由地处理每个独立的实例或集群，更容易根据实际情况反应公司带来的变化，该更新的更新，该减少的减少。每个公司或每个公司数据库定义了不同的维护级别，可以灵活控制并随机更改。

解耦的好处可以提高数据库的绝对性能。从公司到磁盘或从磁盘到公司的路径越短，效率就越好。 MySQL的许多用途都是使用简单的中间层来分发SQL。这样的中间层功能明确，结构简单，灵活高效，通常不会损失太多性能。这就好比国内流行的MySQL出品的MySQL Router、MariaDB出品的Maxscale、Percona出品的ProxySQL、极数云舟的Arkproxy，他们的活动都表明了利用中间层实现信息架构的方向。

解耦的好处是数据库只能做数据库最擅长的事情。它可以确保您的数据的安全存储、数据的高效访问以及数据的同步处理。灵活访问您的数据，这还不够吗？

总而言之，我们再次确信MySQL简单而强大，并且因为它的效率而受到欢迎。不要忽视基础知识，听信欺骗而误入歧途。

当然，如果你不想在业务层面创建单独的数据库和表来容纳MySQL数据库架构，而是想通过对业务透明的分布式数据库来提供业务服务，我真的推荐一个分布式数据库解决方案。它们可以解决强大的存储扩展能力、分布式计算、透明的业务读写、友好的容错等问题。这是他们的兴趣和初衷。 真正去中心化的解决方案真正去中心化的解决方案无需多言，只要满足上述要求即可。并且目前已经有比较成熟的解决方案。比较有代表性的产品有Google的Spanner&F1以及国产数据库SequoiaDB、TiDB等。关于红杉数据库，我之前写过一篇文章。有兴趣的同学可以看一下《【原创首发】兼容MySQL的开源分布式数据库SequoiaDB在去哪儿网的实践》相比之下，这个去中心化的数据库并不干扰业务。 MySQL数据实现云存储功能，与MySQL 100%兼容。它的可扩展性能非常好。它天然支持分布式事务，数据节点和路由节点之间的延迟非常低。采用一致性算法保证数据的强一致性。这一切都是基于正确的基点来建造高楼大厦。构建不可避免地将基于MyCat的伪分布式数据库解决方案推向无人关心的深渊，直到它被移除和销毁。 总结MyCat 有很多用户使用。现在了解了行业市​​场，更加了解了，因为有需求，但确实没有解决方案。它的使用其实也是无奈的。毕竟它是开源的，所以没有什么可抱怨的，即使被批评，因为它是免费的，好用又如何呢？我也推荐大家尝试一下。只有当你知道这很痛苦时，你才能感受到现在可用的新解决方案的美妙之处。