通过本地配置文件不会更改物理库的数据,但是要注意在原型库建立对应的物理库物理表.

注解使用SQL注释方式表达,可以用于动态更新Mycat配置并且把配置持久化,它的设计目标是为了动态的更新mycat的配置.但是由于配置的属性复杂,它不会自动的更改真实数据库的schema.

通过注解配置不会自动创建物理库物理表(与直接使用自动化建表语句不同,它会自动建物理库物理表),所以要保证物理库物理表的在真实数据库上是与配置对应的.一般来说,原型库(prototype)上必须存在与逻辑库逻辑表完全一致得物理库物理表,以便mycat读取表和字段信息.

如果搞不懂配置,可以尝试使用自动化建表语句创建测试的物理库物理表,它会自动生成配置文件,然后通过查看本地的配置文件,观察它的属性,就可以知道什么回事.因为自动化建表语句过于简单,可能不适合公司的业务,此时需要更改配置文件的属性来调整.这种自己更改调整的属性值不属于mycat的开发测试范畴之内,也不能受mycat为自动化建表的测试保证.

命名约定

在mycat2配置中每个项都有name属性,每项的name属性在整个配置必须是唯一的.

prototype服务器

谨记,Mycat2内置的所有集群名字或者数据源名字必须有一个是prototype.该服务器用来处理非select,update,delete,insert.当Mycat2完全实现系统表的时候,该prototype服务能被去掉.

Mycat2自动化DDL

Mycat2 提供自动化的DDL,在Mycat2的命名约定下,可以在sql界面通过hint命令添加集群和使用DDL语句建库建表.
自从实现自动化DDL之后Mycat2就更像数据库了!
如果业务系统与数据分布规划,比如物理库,物理表的命名与mycat命名约定不符,则要自己更改配置.或者先使用自动化建表DDL生成配置,然后再手动更改配置

配置管理发展历史

Mycat2最初的版本是本地文件配置,通过更改配置,启动/重启mycat2,配置就可以生效.
后来通过实现动态更新运行时Mycat2必须的运行时对象.当配置更新时,会经历下面的阶段
1.创建配置更新操作对象,该对象会记录变更的项.
2.把变更的项与当前配置结合,得出新的配置,然后使用该配置生成完整的,新的运行时对象,由于生成新的运行时对象会进行一系列检查,如果都能生成,则配置正常,否则报错.
3.把新的运行时对象与当前内存中的运行时对象整体替换,并把新的配置持久化到本地或者集群
4.在编写代码时候需要主要,如果涉及到多个运行时对象的使用,涉及配置之间的一致性,要把整个配置上下文取出再在上下文使用,忽略在多次在上下文取出运行时对象期间遇上配置导致的一致性问题.
自从实现自动化DDL之后,Mycat2的测试变得很简单,按照命名约定,我们要测试一个功能,只需在客户端向Mycat2添加数据源,添加集群,马上建库建表,清理数据,然后就可以测试了.当然我们可能会错过一些非自动化配置的测试样例.