关于proxysql 连接不到其他集群点的信息

本篇文章给大家谈谈proxysql 连接不到其他集群点，以及对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享proxysql 连接不到其他集群点的知识，其中也会对进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、springboot怎么配置连接ProxySQL？
• 2、MGR 实践及常见问题分析
• 3、基于Xtrabackup8的Mysql定时全量,增量备份及恢复实战演练
• 4、10个顶级Mongodb GUI工具，以图形方式管理数据库
• 5、垂直切分和水平切分经常一起使用吗

springboot怎么配置连接ProxySQL？

在springboot配置sqlserver文件步骤如下：
1、打开项目配置文件 application.properties。
2、这里推荐一个新的写项目属性配置文件的：application.yml。优点在于它不用重复写代码。
3、这二者选一即可，因而我用了application.yml就把application.properties删除了。
4、特别注意语法：每个冒号后面是有空格的。当然这里eclipse也通过颜色对这个语法进行了提示。
5、特别注意语法：每个冒号后面是有空格的。当然这里eclipse也通过颜色对这个语法进行了提示。
6、如果使用的是MySQL，则项目属性文件如下：（此处给出的例子是application.properties，可以对比显示出application.yml的优势）

MGR 实践及常见问题分析

来也科技使用 MGR （MySQL Group Replication）作为私有部署时 MySQL 的高可用架构proxysql 连接不到其他集群点，一年多以来proxysql 连接不到其他集群点，服务众多用户，稳定性得到proxysql 连接不到其他集群点了极大的保障。

本文记录自内部分享，需要一定的 MySQL 基础。欢迎大家在评论区讨论、交流~
MySQL Group Replication（简称 MGR）， MySQL 组复制。

MGR 是 MySQL 官方推出的一种基于 paxos 协议的状态机复制，实现了分布式下数据的最终一致性。MySQL 组复制提供了高可用、高扩展、高可靠的 MySQL 集群解决方案。

MGR 支持两种模式：单主、多主。其中单主模式是官方推荐的，也是在来也科技内部广泛应用的，我们接下来的内容都是以单主模式为背景的。
可能有同学会质疑，公有云上的高可用架构大多是主从啊，为什么来也科技要选择 MGR ？

那首先，我们就要知道 “主从” 和 MGR 的优缺点分别是什么？

来也科技作为一家重心放在 ToB 的企业，我们着重考虑私有部署时，如何保证客户环境的可用性。客户的环境，我们看不到，更无法控制，在这样的情况下，我们会尽量求稳。

维护主从高可用架构的应用，通常面向大规模集群运维，往往会引入复杂的交互和新的中间件。对于我们这种只需要部署一套集群的 ToB 需求，显然是不合适的。

综合考虑之下，我们选择 MGR 作为私有部署时的高可用架构。

    · 最少 3 个节点，最多 9 个节点

    · 节点越多，容错性越强，但交互越多，可能会影响效率

    · 存储引擎只能使用 InnoDB

    · 表中必须带有主键

    · 一次只能加入一个节点。如果一次性添加多个节点，可能能执行成功，也可能会报错

    · 只支持 IPv4 网络

    · 必须使用 row-base 格式的binlog

    · MGR 模式下不支持过滤指定信息的操作
来也科技在给客户做私有部署时，如果客户提供 MySQL 高可用环境，那么会直接使用客户的环境。

否则，部署团队将为客户搭建三节点的 MGR 高可用架构。整体架构图：

如图所示，在应用和 MGR 集群的中间层选用多节点 proxysql 做路由，配置读写分离和故障检测机制，确保读写流量分发正确。proxysql 只要有一个节点存活，即可正常提供服务。（除非扛不住压力！）

在这种架构下，我们可以实现：

    · 如果主库发生故障 -- 自动切换    

    · 如果从库发生故障 -- 将其下线

对于底层的 MGR 集群，宕机一个 mysql 实例时，不影响业务正常使用proxysql 连接不到其他集群点；宕机两个 mysql 实例时，集群只可读，不可写（因为此时已经无法满足 paxos 的多数投票要求）
首先，我们以一个“一波三折”的场景为例，切实感受下 MGR 是如何运作的。

假设存在一个三节点的 MGR 集群，三个节点分别部署在三台实例上。

此时，应用发起一个事务执行请求。 单主模式下，只有primary node 可以接收请求：

   1. primary 接受到请求后，想组所有成员同步请求，进行事务认证。事务认证包含 3 个部分：

        1-1. 冲突检测

        1-2. gtid分配器

        1-3. 事务组提交信息分配器

    2. 如果检测失败

        2-1. primary：回滚

        2-2. secondary：丢弃  binlog event （冲突检测时带来的）

    3. 如果检测成功：

        3-1. primary ：记 binlog， 分配 GTID

        3-2. secondary：将 binlog event （冲突检测时带来的）信息写入 relay log

    4. secondary 应用 relay log ，执行 sql ，并记录日志（通常情况下，我们建议将集群内所有 node 都配置在 seed 中，即：每个节点都可能成为 donor ，所以都要记 binlog）

以上，就是事务在 MGR 中完整的执行流程。

假设，运行一段时间后，其中某个 secondary 节点因服务器宕机原因脱离集群，且长时间未被发现。直至节前巡检时，才被报出来。

补充说明：来也监控项目已经提上日程了，部署后，便不会存在这个风险了。
此时，售后同学重启服务器，启动 mysql 实例（假设顺利启动），执行 start group_replication 操作。

这个命令会执行什么操作呢？

本地恢复：应用自己本地 relay log 中的日志

全局恢复：从集群中活跃的节点中任选一个作为 donor，用 recovery 线程 dump 它的binlog，来恢复自己的数据
恢复线程 requestdump 建立与 donor 的复制关系，该函数携带了待恢复节点的 gtid_executed 信息。

donor 端逆序遍历 binlog 文件，通过判断 binlog 文件的 Previous-GTIDs 来找到第一个不属于 gtid_executed 的事务，从该事务开始进行数据复制。

命令执行过后，观察 replication_group_members 表的数据，如果目标节点的状态是 ONLINE，则视为集群恢复成功。

但我们假设此操作并未成功，日志中有报错：the master has purged binary logs containing GTIDs that the slave requires

这个错误的意思是：节点脱离集群时间过长，已无法通过现存节点的 binlog 直接恢复了。
重做数据。当然是重做数据！

我们需要清除这个下线节点的信息，创建一个新的实例，选择任一正常节点进行数据全量备份，并将其应用至新实例上。

全量数据恢复完成后，执行 start group_replication 命令，开启 MGR 同步，追平数据后，MGR 会将节点状态置为 ONLINE，然后开始正常接收流量请求。
在传统的主从复制中，DBA 需要在 change master 时手动设置增量同步开始的 GTID（更早版本需要指定 binlog file 和 position）。

但是部署过 MGR 的同学会发现，MGR 同步时只需要指定用户名密码即可。那它是怎么找点的呢？

不同的备份方式，对应着不同的找点方式，接下来我们以 mysqldump 为例，详细的讲解下这个过程。

mysqldump 全量数据，使用 gtid_purged 记录备份时已经执行过的事务：

mysqldump --set-gtid-purged=ON --single-transaction --all-databases -uroot -p -h 127.0.0.1 mgr.sql

查看生成的 sql 文件，可以看到开始处有相关标识：

在新节点上使用如下命令清空 GTID 信息：

STOP GROUP_REPLICATION;

reset master;

接下来，应用文件 source mgr.sql，红框圈起来的语句会被一起执行。

完成后，开启 MGR 同步，就会自动跳过这些标识为 purged 的事务了。
当有成员加入或退出时，组会自动调整自身结构：

    · 成员的加入和退出需走 paxos  协议，由多数成员同意后方可执行成功

    · 如果多数节点已经处于离线状态了，那么不可执行主动离组操作（投票会无法通过）。

离组分为主动离组和被动离组：

    · 主动离组：

            只有执行 stop replication 命令才算主动离组

            相当于总数变为 n-1

            无论主动离组多少成员，都不会影响投票 

    · 被动离组：

            因故障等原因导致意外下线

            总数不变

            影响投票

            当有多数节点被动离组后，集群不可用
    1. group_replication_applier：该通道用于回放本地 relay log 中的日志。

    2. group_replication_recovery：当有节点加入 Group 时，需要用到另一个复制通道 group_replication_recovery，它是一个传统的 Master-Slave 异步复制通道。

MGR 常见的调优方式有三种，分别是：

    并行复制

    压缩

    调整 GCT

如果设置了并行复制 slave_parallel_workers，那么这些参数也要被设置，用于确保所有的组成员按照相同的顺序执行并提交事务：

    slave_preserve_commit_order=1

    slave_parallel_type=LOGICAL_CLOCK
压缩语句：

STOP GROUP_REPLICATION;

SET GLOBALgroup_replication_compression_threshold = 2097152;

START GROUP_REPLICATION;

超出这个指定范围，就不压缩了。

官方文档中提示：当网络带宽成为瓶颈时，通过压缩消息，可以提高集群整体 30% - 40% 的性能。
mysql SET GLOBAL group_replication_poll_spin_loops= 10000;

GCT接收来自组和 MGR 插件的消息，处理与仲裁和故障检测相关的任务，发送一些保活的通讯消息，还处理 MySQLServer 与组之间传入和传出的事务。GCT 会等待队列中的传入消息。当队列中没有消息时，GCT将会进行等待。

在某些情况下，通过将这个等待配置得稍微长一些（进行主动等待），可以减少操作系统执行上下文切换时从处理器中换出GCT线程的次数。
常见的安全手段有两种：

    1. 控制节点白名单。设置 group_replication_ip_whitelist 参数，不再此范围的节点，不允许加入

    2. 配置 SSL：

         new_member SET GLOBAL group_replication_recovery_use_ssl=1;

        new_member SET GLOBAL group_replication_recovery_ssl_ca= '.../cacert.pem';

        new_member SET GLOBAL group_replication_recovery_ssl_cert= '.../client-cert.pem';

        new_member SET GLOBAL group_replication_recovery_ssl_key= '.../client-key.pem';
MySQL 5.7.22 之前，可能会出现数据不一致的风险。这种情况发生在成员短暂离组，在组感知前，自己又重新加入组内的时候，官方文档描述如下：

In this situation, the rejoining member forgets its previousstate, but if other members send it messages that are intended for itspre-crash state, this can cause issues including possible data inconsistency.

To counter this possibility, from MySQL 5.7.22, servers aregiven a unique identifier when they join a group . This enables GroupReplication to be aware of the situation where a new incarnation of the sameserver (with the same address but a new identifier) is trying to join the groupwhile its old incarnation is still listed as a member. The new incarnation isblocked from joining the group until the old incarnation can be removed by areconfiguration. If Group Replication is stopped and restarted on the server,the member becomes a new incarnation and cannot rejoin until the suspiciontimes out.
精准的定位问题是解决问题和优化系统的前提！当集群故障时，我们首先要判断集群当前处于什么状态，优先恢复使用，尽可能地保留现场进行故障排查和恢复。

所有节点上执行查看集群成员信息命令：

Q: 为什么要在所有节点上执行?

A: 因为可能会发生网络分区，出现若干节点互联，分成若干集群的情况。集群一旦分裂，互相感知不到对方存在。

以三个节点为例，常见分裂拓扑图：
如果大多数节点存活（n=2f + 1 ) 且在同一个 group 中提供服务，我们认为，这仍是一个可用集群。

即：同一个 group 中 node 数大于 f ，且状态都是 ONLINE 的情况下，认定集群可用。

此时，优先使用可用集群提供服务，并进行后续问题排查。
主节点提供读写服务，从节点提供只读服务。

无论是应用直连，还是通过代理层（proxy 等）进行连接，当务之急都是确认主节点是谁。

命令：select MEMBER_HOST, MEMBER_PORT,MEMBER_STATE from performance_schema.replication_group_members m inner join performance_schema.global_status g on m.MEMBER_ID=g.VARIABLE_VALUE and VARIABLE_NAME = 'group_replication_primary_member';

知晓谁是主节点，谁是从节点后，应用或者代理，就可以进行相应的配置。
错误日志！错误日志！错误日志!

有故障，第一时间查看错误日志。错误日志存放位置：

打开日志文件，查看错误信息。

注意： 错误信息，不仅要在出故障的实例上查看。因为 MGR 是”大多数原则“，所以每一个实例上的错误信息，都可能不是完全的。

比如实例意外 down 掉，此时故障实例本身就可能来不及记录错误日志。

除了实例级别的错误日志外，MGR 视图还可能自己记录最后的错误信息，通常日志中会有相关提示。比如，日志中存在：

[ERROR] Plugin group_replication reported: 'For details please check performance_schema.replication_connection_status table and error log messages of Slave I/O for channel group_replication_recovery.'

常见错误：[GCS]Connection attempt from IP address 192.168.9.208 refused

出现场景：MGR 白名单设置不正确

解决办法：查看该实例所在的网段，是否在 MGR 的白名单中

命令：show global variables like 'group_replication_ip_whitelist';

通常我们建议直接设置成全网段访问，由其他层（region、安全组等）控制连通性。

不排除私有部署的客户对于安全性要求极高，要求设置指定网段访问，那么此时，就要查看一下实例是否存在于这个白名单中。

注意：MGR 中的节点，每个白名单配置都可能不一样（强烈不建议！建议配置成一致的！），所以，要把集群中所有的节点都查一遍，避免出现后续问题。

常见错误：This member has more executed transactions than those present in the group.

出现场景：

    1. 有应用直连，往里写数据

    2. 有人误在从库上直接操作

    3. 错误的恢复手段：这个最为常见

解决办法：

    1. 查看哪些数据被错误应用，进行相应处理

    2. 找到最后同步的 GTID 位点

    3. reset master

    4. 设置最后 gtid_purged 为要继续同步的 GTID 位点

常见错误：Member was expelled from the group due to network failures, changing member status to ERROR

出现场景：网络延迟

解决方法：等待网络恢复正常后，重新加入集群即可

常见错误：the master has purged binary logs containing GTIDs that the slave requires

出现场景：从库脱离群组时间太长，无法通过已有的 binlog 进行恢复了

解决方法：重做数据（mysqldump 或 xtrabackup）后，加入群组
select TABLE_SCHEMA, TABLE_NAME from information_schema.tables where TABLE_SCHEMA not in ('information_schema','mysql', 'performance_schema', 'test', 'sys') and  TABLE_NAME not in (select  table_name from information_schema.TABLE_CONSTRAINTS  where TABLE_SCHEMA not in ('information_schema','mysql', 'performance_schema', 'test', 'sys') and CONSTRAINT_TYPE = 'PRIMARY KEY');
select TABLE_SCHEMA, TABLE_NAME from information_schema.tables where TABLE_SCHEMA not in ('information_schema','mysql', 'performance_schema', 'test', 'sys')  and engine < 'InnoDB';
本文作者、编辑：刘桐烔

欢迎大家点赞、在看、关注~

基于Xtrabackup8的Mysql定时全量,增量备份及恢复实战演练

所有mysql实例皆为MYSQL8版本,使用的Xtrabackup备份组件为xtrabackup8.

生产mysql使用基于percona的分支,相对于原版mysql多了一些性能调教和监控视图,版本为:percona-server-server-8.0.22,备份相关工具对mysql8的官方版本也是完全兼容的.percona的分支相关信息: https://www.percona.com/software/mysql-database/percona-server

生产环境mysql一共3个实例,使用MGR组成集群以实现灵活的高可用与读写分离.并由前置的proxysql进行数据的路由与转发.

模拟故障为:在生产环境mysql8 的MGR集群完全不可用,有前一天的Xtrabackup全量备份和增量备份,需要从之前的全量和增量备份完整恢复到故障最近的时间点.本次故障恢复的要求是读取前一天的所有增量和全量数据并恢复.快速重组生产MGR集群.

在这里会用ansible脚本快速搭建3个mysql实例,以模拟生产环境(略过).

backup_func.sh :

策略是每天的0:30做一次全量备份,之后每两个小时的半点会做一次增量备份.

注: 本次恢复属于完整的生产环境集群恢复,下面的 获取备份文件 , 准备备份 , 开始恢复 相关流程,需要在每一台服务器上执行,实际操作中,如果只需要恢复并查看数据则只做一个点就可以了.

这里取的是前一天的打过包的备份文件,根据备份脚本的规则,每天凌晨的全量备份之前,会自动将前一天的全量备份和增量备份目录全部打包并以前一天的日期命名:

20210609.tar.gz

将其scp到待恢复的服务器上并解压:

解压后的目录结构:

确保需要恢复的服务器有mysql实例,xtrabackup8工具已安装,由于备份是经过压缩的,确保qpress也已安装.

由于备份脚本在备份时使用了 --compress 指令,在恢复备份前,需要先解压缩备份,

这里将所有增量和全量备份路径均执行一下解压缩指令:

在同时存在全量和增量备份需要合并的情况下,准备备份时需要带上 --apply-log-only 参数,但是要注意在准备最后一个增量备份的时候,不需要加该参数.

以上操作会将所有的增量备份合并到全量备份中.

根据各自安装时指定的相关路径去删除数据.(data,binglog,logs,undolog),一般在my.cnf中有指定

如果my.cnf不是在默认路径(/etc/my.cnf),需要指定一下mysql配置文件的路径: --defaults-file=${DB_CONF}

至此,备份数据在单节点上的恢复已经完成了.

查看下最后一份增量备份里才会有的一些数据

先确保同样的mysql恢复操作分别在三台服务器上执行完成.(如果在新建服务器上恢复MGR集群,一定要检查my.cnf中MGR集群相关配置,比如 loose-group_replication_local_address , loose-group_replication_group_seeds , loose-group_replication_start_on_boot )

master节点启动:
MGR的三台节点的权重实际上是一样的,选择其中的一台做master即可.

mster节点启动完成后,再分别在两台slave节点启动MGR:

由于3台mysql实例的数据是一样的,节点间状态同步迅速就OK了.

至此,3台mysql的MGR状态均为 online ,整个集群启动完成,全演练流程结束.

10个顶级Mongodb GUI工具，以图形方式管理数据库

MongoDB是一个面向文档的数据库proxysql 连接不到其他集群点，属于NoSQL数据库，它使用类似JSON的文档和schemata。

MongoDB的默认接口是（CLI）命令行，新用户很难像专业人员那样处理数据库。因此，有一些MongoDB管理工具来提供GUI界面以提高生产力。就像phpmyadmin为MySQL/MariaDB数据库提供基于HTTP网络的GUI界面一样。但是，此处包含的所有工具都不是基于HTTP的，只有少数工具为MongoDB提供Web界面。以下是使用GUI的比较流行的MongoDB管理工具列表：

要从具有图形用户界面的MongoDB开始，MongoDB是最好的方法之一。MongoDB Compass Community由MongoDB开发人员开发，这意味着更高的可靠性和兼容性。它为MongoDB提供GUI mongodb工具，以 探索 数据库交互；具有完整的CRUD功能并提供可视方式。借助内置模式可视化，用户可以分析文档并显示丰富的结构。为proxysql 连接不到其他集群点了监控服务器的负载，它提供了数据库操作的实时统计信息。就像MongoDB一样，Compass也有两个版本，一个是Enterprise（付费），社区可以免费使用。适用于Linux，Mac或Windows。
NoSQLBooster是MongoDB CLI界面中非常流行的GUI工具。它正式名称为MongoBooster。NoSQLBooster是一个跨平台，它带有一堆mongodb工具来管理数据库和监控服务器。这个Mongodb工具包括服务器监控工具，Visual Explain Plan，查询构建器，SQL查询，ES2017语法支持等等......它有免费，个人和商业版本，当然，免费版本有一些功能限制。NoSQLBooster也可用于Windows，MacOS和Linux。
ClusterControl是另一个MongoDB工具，具有管理数据库基础结构的GUI。它还有两个版本 - 社区和企业版。不用说，ClusterControl社区版可以免费使用，而企业则是付费的。它不仅限于MongoDB，还支持MySQL，MySQL复制，MySQL NDB集群，Galera集群，MariaDB，PostgreSQL，TimescaleDB，Docker和ProxySQL。
ClusterControl为数据库基础架构提供全自动安全性，该基础架构具有单个图形用户界面，可操作和自动化MongoDB和MySQL数据库环境。它可通过YUM/APT提供回购，适用于Linux平台（RedHat，Centos，Ubuntu或Debian）。

Nosqlclient是一个免费的开源MongoDB管理工具，基于Web的GUI意味着不再需要命令行来管理数据库。我们可以使用Nosqlclient在MongoDB中插入，删除或更新数据，而无需使用查询。它可作为桌面应用程序，Docker和Web应用程序使用。Web使用HTTP为MOngoDB提供基于浏览器的界面。
Robo 3T由MongoDB客户端Studio 3T的开发人员维护和提供。以前，Robo 3T被称为Robomongo。它也是适用于Windows，MacOS和Linux的跨平台MongoDB GUI管理工具。它具有相同的引擎和环境，是MongoDB shell（3.2）的一部分。
上面提到的Robomong被3T收购并更名为Robot 3T；现在是Studio 3T的一部分。那么，Studio 3T是什么proxysql 连接不到其他集群点？与其proxysql 连接不到其他集群点他提到的MongoDB管理GUI工具一样，Studio 3T也是一个基于GUI的工具，用于管理数据库，但在付费类别中。但是，此工具的30天免费试用版允许用户在投入资金之前使用并了解其功能。与免费和开源Robot 3T相比，Studio 3T具有更多功能并提供企业支持。与Robo 3T相同，它也适用于Windows，Linux（Ubuntu和CentOS）和MacOS。
Mongo Management Studio是一个用于数据库管理的免费MongoDB GUI工具。它轻巧，界面清晰，易于开发基于MongoDB的项目。它使用nodeJs，Electron框架，MongoDB和AngularJs开发。MMS与MongoDB 3.0/3.2/3.4兼容。
与上述所有MongoDB管理工具一样，用户可以轻松安装它，但免费版仅适用于Windows；而企业和个人则适用于Linux，Windows和MacOS。企业版（Web服务器）支持MongoDB Web界面HTTP GUI，这意味着我们可以在主服务器上安装，之后可以在本地或远程使用浏览器的任何系统上访问。但是，个人版和免费版只能在已安装它们的本地系统上使用。

它是面向关系，NoSQL和云平台的数据库开发人员的通用集成开发环境（IDE）。因此，支持各种数据库来开发，访问，管理和可视化分析数据。
对于MongoDB，Aqua Data Studio使用具有管理和数据库查询功能的图形用户界面作为管理工具。Aqua Data studio的Visual界面允许用户浏览和修改数据库结构，包括模式对象和集合，以及维护数据库安全性。

它提供了一个MongoDB数据库工具包，包括各种工具，如Visual Analytics，MongoSQL查询参考，MongoJS查询分析器，MongoShell MongoShell，FluidShell，查询和分析工具，网格和数据透视图，表数据编辑器，导入和导出工具，实体关系建模；Visual Query Builder；比较工具：架构比较，文件比较；SQL 历史 记录，Open API脚本环境，集成安全Shell（SSH）和版本控制：Subversion（SVN），Git，CVS，Perforce。

MongoJS查询分析器Javascript编辑器允许执行JavaScript命令并支持自动完成和语法突出显示。结果可以在树层次结构，网格结果和文本中看到。

作为付费产品，Aqua Data Studio的试用版提供14天，具有所有企业功能。所以，如果你正在寻找一些付费产品，那么你可以在花钱之前免费试用它。它适用于Windows，Linux和MacOS。

这听起来像phpMyAdmin工具。但是，phpMoAdmin也是PHP编写的但是可用于MongoDB。它基于Vork PHP框架。很轻巧，易于安装。它只有115KB的moadmin.php文件，用户可以放在网站的任何地方开始工作。
它是一个跨平台的MongoDB管理工具，在Open Source许可下发布，使用Electron框架和Angular JS构建。可在GitHub上找到。
以上谈到了Windows，Linux和MacOS MongoDB管理客户端，所以那些正在寻找智能手机和平板电脑的用户mongoDB管理可以试试Mongolime。它为MongoDB移动客户端提供了轻松连接和访问MongoDB服务器的功能。它具有内置的SSH隧道，可以通过SSL轻松验证和连接远程服务器。MongoLime是免费增值MongoDB客户端应用程序，支持iOS和Android平台。

使用Node.js，Express和Bootstrap3编写的基于Web的MongoDB管理界面。它允许连接多个数据库；查看/添加/删除数据库，集合和文档；预览音频/视频/图像资产；GridFS支持 - 添加/获取/删除难以置信的大文件；在文档中使用BSON数据类型，Mobile / Responsive - Bootstrap以及更多功能。

垂直切分和水平切分经常一起使用吗

1. 为什么要拆分数据库？
单体项目在构建之初，数据库的负载和数据量都不大，所以不需要对数据库做拆分，小型财务系统、文书系统、ERP系统、OA系统，用一个MySQL数据库实例基本就够用了。
就像《淘宝技术这十年》里面说到的，电商业务的数据量增长飞快，所以最开始的PHP+MySQL的架构已经不能满足实际要求了，于是淘宝想到的第一个办法就是把MySQL替换成Oracle。但是没过了多久，在08年前后，单节点的Oracle数据库也不好用了，于是淘宝终于告别了单节点数据库，开始拆分数据库。从一个节点，变成多个节点。
拆分数据库是有讲究的，比如说拆分方法有两种：垂直切分和水平切分。那你是先水平切分还是垂直切分呢？顺序无所谓？不，顺序有所为，次序绝对不能错：先水平切分，然后垂直切分。
2. 什么是垂直切分？
垂直切分是根据业务来拆分数据库，同一类业务的数据表拆分到一个独立的数据库，另一类的数据表拆分到其他数据库。
比如说一个新零售的电商数据库，我们可以把跟商品相关的数据表拆分成一个数据库，然后在这些数据表的基础之上，构建出商品系统。比如用JAVA或者PHP语言，创建出一个商城系统。然后把跟进销存相关的数据表拆分到另外一个数据库上，再用程序构建出仓库系统。
垂直切分解决了什么问题
垂直切分可以降低单节点数据库的负载。原来所有数据表都放在一个数据库节点上，无疑所有的读写请求也都发到这个MySQL上面，所以数据库的负载太高。如果把一个节点的数据库拆分成多个MySQL数据库，这样就可以有效的降低每个MySQL数据库的负载。
垂直切分不能解决什么问题
垂直切分不能解决的是缩表，比如说商品表无论划分给哪个数据库节点，商品表的记录还是那么多，不管你把数据库垂直拆分的有多细致，每个数据表里面的数据量是没有变化的。
MySQL单表记录超过2000万，读写性能会下降的很快，因此说垂直切分并不能起到缩表的效果。
3. 什么是水平切分？
水平切分是按照某个字段的某种规则，把数据切分到多张数据表。一张数据表化整为零，拆分成多张数据表，这样就可以起到缩表的效果了。
很多人，都会水平切分存在误解，以为水平切分出来的数据表必须保存在不同的MySQL节点上。其实水平切分出来的数据表也可以保存在一个MySQL节点上面。不是水平切分一定需要多个MySQL节点。为什么这么说呢？
许多人不知道MySQL自带一种数据分区的技术，可以把一张表的数据，按照特殊规则，切分存储在不同的目录下。如果我们给Linux主机挂载了多块硬盘，我们完全可以利用MySQL分区技术，把一张表的数据切分存储在多个硬盘上。这样就由原来一块硬盘有限的IO能力，升级成了多个磁盘增强型的IO。如果你感兴趣数据分区的具体效果，可以看《MySQL数据库集群》这门实战课。
水平切分的用途
水平切分可以把数据切分到多张数据表，可以起到缩表的作用。
但是也不是所有的数据表都要做水平切分。数据量较大的数据表才需要做数据切分，比如说电商系统中的，用户表、商品表、产品表、地址表、订单表等等。有些数据表就不需要切分，因为数据量不多，比如说品牌表、供货商表、仓库表，这些都是不需要切分的。
水平切分的缺点
不同数据表的切分规则并不一致，要根据实际业务来确定。所以我们在选择数据库中间件产品的时候，就要选择切分规则丰富的产品。常见的数据库中间件有：MyCat、Atlas、ProxySQL等等。有些人觉得MyCat是Java语言开发的，就怀疑MyCat运行效率。其实数据库中间件的作用相当于SQL语句的路由器。你家路由器硬件配置不怎么高，但是不影响你享用百兆宽带。MyCat也是一个道理，它仅仅是起到SQL语句转发的作用，并不会实际执行SQL语句。我推荐使用MyCat最主要的原因是它自带了非常多的数据切分规则，我们可以按照主键求模切分数据，可以按照主键范围切分数据，还可以按照日期切分数据等等。因此说，为了满足业务的需要，MyCat目前来说算是非常不错的中间件产品。
水平切分的另一个缺点就是扩容比较麻烦，日积月累，分片迟早有不够用的时候。这时候不是首先选择增加新的集群分片。因为一个MySQL分片，需要4~8个MySQL节点（最小规模），增加一个分片的投入成本是很高的。所以正确的做法是做冷热数据分离，定期对分片中的数据归档。把过期的业务数据，从分片中转移到归档库。目前来说数据压缩比最高的MySQL引擎是TokuDB，而且带着事物的写入速度是InnoDB引擎的6-14倍。用TokuDB作为归档数据库最适合不过。
4. 为什么先做水平切分，后作垂直切分？
随着数据量的增加，最先应该做的是数据分片，利用多块硬盘来增大数据IO能力和存储空间，这么做的成本是最低的。几块硬盘的钱就能收获不错的IO性能。
进入到下一个阶段，数据量继续增大，这时候我们应该把数据切分到多个MySQL节点上，用MyCat管理数据切分。当然还要做数据的读写分离等等，这里不展开讨论。在后台做水平切分的同时，业务系统也可以引入负载均衡、分布式架构等等。理论上，使用了冷热数据分离之后，水平切分这种方式可以继续维持很长一段时间，数据量再大也不怕，定期归档就好了。
数据库到了水平切分的阶段，数据量的增加已经不是更改架构设计的主要原因了。反而这个阶段业务系统承受不住了，如果再不对系统做模块拆分，业务系统也撑不下去了，所以按照模块和业务，把一个系统拆分成若干子系统。若干子系统之间，数据相对独立。比如淘宝不会跟支付支付宝分享全部数据，共享同一套数据表，这也影响各自业务的发展。所以就要弄垂直切分了，把数据表归类，拆分成若干个数据库系统。
讲到这里，你仔细想想。如果过早的对数据库做了垂直切分，势必要重新构建若干独立的业务系统，工作量太巨大。水平切分并不需要业务系统做大幅度的修改，因此说应该先从水平切分开始做。 关于proxysql 连接不到其他集群点和的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 proxysql 连接不到其他集群点的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于、proxysql 连接不到其他集群点的信息别忘了在本站进行查找喔。