介绍
分布式数据库已经进入全面快速的发展阶段，这种发展与时俱进，与人类的需求密不可分，由于信息时代的快速发展，数据量和交易量不断增加。因为MySQL数据库本质上是独立版本的数据库，所以首先出现的就是存储瓶颈。存储题是存储是一项硬性要求，因此没有足够的CPU和内存将导致性能不佳，并且不会直接使您的解决方案或架构失效。
事实上，我们一直在努力解决存储题。解决方案大概有三个方面
增加磁盘
由于磁盘空间不足，这可能是最直接、最简单的解决方案。当然，添加磁盘是一个快速解决方案。比如现在是800G，但是可以增加到2T。这不是题。当然，磁盘可以增加到5T，但事实上，这可能是DBA关心的题。这么大数据量的MySQL实例该如何运维？如果数据损坏了怎么办？恢复需要多少时间？5T的数据量已经很吓人了。估计业界没有哪家大企业有DBA愿意运维这种规模的MySQL实例。其实我个人认为这个量已经让人无法接受，最优量最好保持在1T以下。如果超过这个范围，你就需要找到一种方法。当然，之所以数据量不应该达到这个大小，是因为有些人可能会认为这是一个性能题，但实际上并非如此，或者由于InnoDB使用B+树存储，所以性能题很小。这是一个解决方案，在最坏的情况下，它几乎没有影响，因为没有针对小表的查询，因此要获取数据，您必须找到3层，即3页IO，对于大表，您需要4页IO。
数据压缩
数据通常也会被压缩以减少其占用的磁盘空间，这可以通过单个语句来完成。这是InnoDB原生支持的方法。正常情况下，数据占用减少三分之一。在原来的1/2范围内效果仍然足够明显，但是这样处理后的数据性能有所下降。对于响应要求比较高的企业来说，这可能需要慎重考虑，但这种方法仍然治标不治本。如果为了治本而数据量继续增加，一段时间后你仍然会遇到同样的题，这种情况下你就不能继续使用这种方法。
数据分片
数据分片方案目前在业界得到广泛应用，除了MySQL本身之外，HBase、Redis等也在使用这种方案，这种方案可以说是最具扩展性和可行性的。尽管可以无限扩展，但上述两种解决方案根本不具有可扩展性。因此，这种方案已经成为业界的主流，只有这种方案才能称为分布式存储。具体的实现层出不穷。当然，有好的分布式解决方案，也有一些“伪”分布式解决方案。
分布式解决方案要求
可扩展性
事实上，使用分布式最重要的是可扩展性，如果空间不足，可以很容易地扩展节点数量和数据重新平衡。此过程不得影响业务使用，并且必须对业务透明。
支持工作
对于业务本身来说，分布式数据库的使用与单机的使用没有太大区别，对业务来说是透明的。因为MySQL支持事务，即使MySQL去中心化之后，事务功能仍然是必不可少的，所以总体来说，好吧，我们仍然需要支持分布式事务。
无限的SQL语句
业务需求的多样性导致SQL需求相对广泛，如果为了业务透明而不支持某些SQL语句，那么带来的题是，一方面了业务程序的功能和性能。另一方面，它导致了将业务程序与“分布式数据库”捆绑在一起的题。
性能足够好
使用分布式数据库实际上只有性能要求比较低的公司才会选择，但性能越高，选择分布式数据库的人就越多。
元数据更改透明度
所有数据库都存在元数据变更，虽然在单点情况下有很多熟悉的方法来实现表修改操作，但在分布式环境中这可能会出现题，因为数据分片需要多次更改元数据。这是最基本的题，修改它会带来很多题，如原子性、数据可见性、正确性等。
主数据库高可用
俗话说经济基础决定上层建筑，分布式数据库也是如此，如果底层数据库不稳定，数据复制延迟，或者出现数据不一致，上层应用的访准确性就无法保证。因此，主数据库最根本的就是保证数据的一致性和高可用性。
流行的分布式数据库解决方案
中间件子库和表伪部署
MySQL世界中长期存在的主题包括
哪个中间件对分库分表实现了更好的解决方案？
当然，不同的人对同一个题有不同的看法，都有矛盾的特点，有人说好，有人说不好，首先我们看一下这个方案是如何实现的。
MyCat的实现架构和上图大致是一样的，看图就知道这个架构真的很完美。自动分片、自动聚合、分布式均衡都实现得很好。但事实并非如此。
法可以帮助您逐步理解该方法的关键题。
MyCat如何知道数据分片如何工作或如何确定路由路径？
这个题在图片中是看不出来的。在MyCat中，解决诸如如何定义或确定如何执行SQL语句或如何确定从哪里获取数据以及将数据写入哪里等题需要将其存储在特定的位置。该方法是——schemaxml配置文件，实际上是使用配置文件完成的。那么题就很多了，修改分库分表规则后，如何保证配置和数据同步更新呢？即使不使用schemaxml配置文件，使用数据库存储，配置规则和数据迁移数据节点节点没有办法保证一致性，这不可避免地影响业务。
如果我需要扩展和重新平衡我的节点怎么办？
很多用户做重路由基本上都是准备一个新的集群或者先手动一点点导出导入数据，然后导入到目标节点，然后手动修改Schemaxml配置文件然后做reload操作，但这也是可以做到的使用上面的方法就会得到结果。而且，由于这个过程需要处理大量数据，处理完成后必须进行多次检查，并且占用两倍的空间，DBA可能做一次就想退出。
什么是全局表？
MyCat支持所谓的全局表来解决节点之间的数据聚合题。我们实现的方式是在每个分片中创建这些全局表。定义没有显着修改。可以全局定义经常查询的表。对于表来说，只要每个分片节点使用这张表，就可以实现本地查询连接等操作，这样可以解决一些题，但是题是当分片很多或者100个分片的时候。如何保证数据一致性XA事务对这么多节点有什么影响？如果出现不一致或访错误，题将是数据结果不正确。这些绝对不是您的企业希望看到的结果。不是最重要的，而是数据库集群，为什么要做这样特别的事情呢？
MyCat到底是做什么的？
作为中间层，它的工作是接收客户端的SQL请求，对其进行解析，根据读写原理确定集群中的读写节点，并等待结果集返回。对于结果集本身，不需要担心中间层，只需将结果集或异常按原样发送回客户端即可。MyCat的作用远不止于此它解析后进行语义分析，获取对应的数据库表结构，同时确定该表的分发路由规则，然后在与语句关联的列中查找数据。然后决定路由到哪些分片，在部署过程中，如果路由规则配置错误或者程序计算不正确，那么整个语句的结果将变得不可预测。我想前半部分是不是中间层应该做的事情？您必须处理表结构、主键、语句中包含的数据以及其他信息，这才是数据库真正应该做的事情。事实上，它正在跨越界限。请再一次。这些任务可以比专门的数据库更好地执行吗？我们再看下半场。MyCat收到结果集后，需要处理结果集的一些聚合计算。二进制MySQL协议封装来自每个节点的结果，收集流数据，解析它，并根据需要进行计算。此计算可能非常慢并且可能无法完成所有操作。计算完成后，进行打包。将其转换为MySQL协议流数据并发送给客户端。这是真的？中间层在如何保证性能方面做了很多工作。这些聚合计算OrderBy和GroupBy本身的处理是数据库的事情。但实际上还是别人做的。
通过SQL语句的改造来实现分布式是不是有点困难？
MyCat等中间层代表一种用法，号称是分布式数据库，但这种实现方式实际上是基于SQL语句，从客户端获取到的变成SQL语句传递到后端数据库。这也是一条SQL语句，只不过这两条SQL语句进行了转换，当然，由于后端数据库只接收SQL语句，所以这种方式是不可避免的，下面我们通过SQL来一下复杂的SQL语句查询操作。改造或者重写，可以实现不同分片数据库的分布式查询。想一想。尽管SQL语句通用且灵活，但其扩展性或重写逻辑仍然有些复杂。当然，有些人可能会说我们正处于谷底。哦，最坏的情况，只要把这条语句里的库名和表名改一下，剩下的就这样，分配到各个节点上，运行一下就没有题了，是的，没错。
如何在同一个交易中修改另一个节点上的数据
这个题就是我们通常所说的分布式事务。怎么了？MyCat面对的是MySQL服务器，这意味着MyCat只能通过SQL语句与MySQL服务器进行通信。这是MySQL特有的SQL。对于查询功能方面的分布式实现，有多少人使用MySQLXA本身？如果MyCat在没有MySQLXA的情况下实现跨节点数据更新，我还能用什么？由于它是由人类使用的，因此可能存在许多题，例如性能、错误功能等。如何保证上层MyCat及应用的可靠性？当然，基于这些题，一些解决方案决定不使用XA，如果某些节点出现故障，他们决定忽略它而不修复它。另外，您不必在————上妥协，因为这是可能的。
MyCat后端数据库的架构是怎样的，如何保证稳定性、可靠性和高可用性？
根据一些文章，以前您可以选择主从复制，但现在您可以选择GaleraCluster或较新的MGR。当然，我想说的是，它可以保证前后更好的稳定性。但最大的题是Galera的门槛比较高。当题出现时，很少有人能够解决。去哪儿很自豪地说，我们是世界上少数更多使用Galera的公司之一。公司和MGR本身都需要等待，而且需要很长时间才能可用。这个题还是要回到主从复制上。这是一个老题了。主从一致性Slave复制很难保证，如果MyCat采用写分离策略从上面读取，就会出现延迟，这可能会导致整个应用的计算结果不正确，当然，你可以这么说。题是有一个参数可以设置如果延迟检查继续的话，如果延迟超过100秒，检查主库是正确的，但是100秒就不是延迟了。然后你可以这样设置
本篇文章讲解关于mycat停止维护和mycat还维护吗的相关热议题，希望能帮助到各大网友。
No Comment