垂直分表2——mycat垂直切分

节点1的schema.xml:

（配置节点2(节点3、4一样的步骤)：192.168.1.3的dataHost name="mysql0103"，连接池1000，最小初始化连接数10，balance、writeType、dbtype、dbDriver、switchType参考：https://blog.51cto.com/5660061/2388925，heartbeat对后端数据库可用性检测）

（此处配置switchType意义不大，因为没有配置主从复制）

（节点1是master，节点2、3、4是从）

（配置好dataNode，对应到真实的拆分后数据库）

（schema配置逻辑库。checkSQLschema、sqlMaxLimit参考https://blog.51cto.com/5660061/2388925）

（table配置切分到三个库的逻辑表们）

在节点1建立用户并授予权限：

（拆分前的库，什么表就以什么开头+下划线，如：customer_、order_、product_）

node1的server.xml:

（配置的含义，参考：https://blog.51cto.com/5660061/2388455）

注意：真实环境配置的密码最好加密：

登录mycat，查看逻辑库、表：

说明确实是逻辑库、逻辑表

如果在mycat中跨库/分片查询会报错：

解决跨库/分片的问题的方法：

1. 通过api的方式，前端应用程序分别去订单模块中分别获取信息拼接在一起
   

2. 通过数据冗余的方式，把省市区的信息冗余到对应的表中

实际上，上面两种方法在此处不是太适合，这里介绍下mycat的全局表的方式：

好在mycat提供全局表，什么是全局表呢？像区域信息表，如果通过api的方式来获取，显然查询频率高，api调取的频次会很高，而且通过应用来拼接非常耗时；而做数据冗余，数据冗余度会非常大，区域信息表还好，如果是其他的，要修改所有相关表，工作量也大。

也就是说，会把region_info以相同的数据存储在3个物理节点中。现在这3个节点都是主节点，已经不存在mysql主从复制关系了，这个时候如果再维护region_info表，也就是全局表的话，就要通过mycat来进行，这样才能同时维护3个节点的数据，也就是mycat会采用多写的方式，将region_info全局表维护同时在3个节点中进行

后续工作：

切换应用通过mycat连接数据库

减少跨库查询，适当对表冗余

（还可以配置mycat的全局表）

启动mycat

如何确定mycat是否正常启动？可以查看日志：

验证mycat是否能正常访问，对应用来说，mycat就是mysql，所以可以使用连接mysql的方式连接mysql：

（server version说明连接的是mycat，而不是mysql）

此时，往node1写数据，还是会同步到mode2、3、4，显然达不到垂直切分的目的，所以要停掉主从同步：

先在node4(node2、3一样的步骤)停掉主从同步：

还需要把所有主从同步信息停掉：

然后，node2、3、4就成了真正的独立的主数据库节点了

在node2、3、4清理多余数据，只保留各自分库后的数据：

......

配置全局表：

尽量将要一起关联的表放到同一个分片节点上，因为mycat在进行分片查询中性能很差

第一步：把region_info表拷贝到除node2之外的其他两个节点中（在node2操作）

拷贝到node3、4（在node2操作）：

分别在node3、4中导入：

接下来修改mycat的schema.xml配置（node1）：

（把ordb、prodb、custdb三个分库增加了全局配置信息）

重启mycat生效：

然后登上mycat，可以“跨库”查询了：

接下来，看能否正确将全局表内容写入三个服务器中：

上面出现了报错，运行在read-only模式下，分别在node2、3、4上关闭read_only（非mycat操作）：

通过mycat修改region_info数据：

通过mycat查看region_info数据：

分别在node2、3、4上查看，也是如此

（一旦用了mycat全局表，全局表的维护就要通过mycat进行，否则会造成全局表数据不一致）

垂直切分的优缺点：

转载于:https://blog.51cto.com/5660061/2391759