Mycat配置文件schema.xml参数配置

Mycat原理：

Mycat的原理中最重要的一个动词是"拦截"，它拦截了用户发送过来的SQL语句，首先对SQL语句做了一些特定的分析：如分片分析、路由分析、读写分离分析、缓存分析等，然后将此SQL发往后端的真实数据库，并将返回的结果做适当的处理，最终再返回给用户。

Xml的语法相对与HTML来说要严格许多。它要求每一个标签都有开始和结束标记，例如：

开始标记<book  ...>，结束标记为</book>;   或者写在一起：<book  ... />

MyCAT目前主要途过配置文件的方式来定义逻辑库和相关配置：配置文件修改，需要重启Mycat或者通过9066端口reload

schema.xml中定义逻辑库，表、分片节点等内容

rule.xml中定义分片规则

server.xml中定义用户以及系统相关变量，如端口等。是mycat服务器参数调整和用户授权的配置文件

log4j.xml日志存放在logs/log中，每天一个文件，日志的配置是在conf/log4j.xml中，根据自己的需要可以调整输出级别为debug，debug级别下，会输出更多的信息，方便排查问题。

注意：Linux下部署安装MySQL，默认不忽略表名大小写，需要修改 my.cnf 下配置 lower_case_table_names=1 使Linux环境下MySQL忽略表名多小写，否则使用MyCAT的时候会提示找不到表的错误！

MYCAT常用的分片规则如下，另外还有一些其他分片方式这里不全部列举：
（1）分片枚举：     sharding-by-intfile
（2）主键范围约定：auto-sharding-long    此分片适用于，提前规划好分片字段某个范围属于哪个分片
（3）一致性hash：  sharding-by-murmur
（4）字符串hash解析：  sharding-by-stringhash
（5）按日期（天）分片：sharding-by-date
（6）按单月小时拆分：  sharding-by-hour
（6）自然月分片：       sharding-by-month
（7）取模：           mod-long  此规则为对分片字段求摸运算

（8）取模范围约束：sharding-by-pattern 此种规则是取模运算与范围约束的结合，主要为了后续数据迁移做准备，即可以自主决定取模后数据的节点分布。

balance属性，读操作负载均衡类型，目前的取值有4种： 决定了哪些MySQL服务器参与到读SQL的负载均衡中

1. balance="0", 不开启读写分离机制，所有读操作都发送到当前可用的writehost上。

2. balance="1"，(默认)所有读操作都随机的发送到readhost和standby writehost上。全部的readhost与standby writehost参与select语句的负载均衡，简单的说，当双主双从模式(M1->S1，M2->S2，并且M1与 M2互为主备)，正常情况下，M2,S1,S2都参与select语句的负载均衡。

3. balance="2"，所有读操作都只随机的发送到readhost上。即所有的writeHost不参与读负载

writeType属性，写操作负载均衡类型，目前的取值有3种：

1. writeType="0"   (默认)所有写操作发送到配置的第一个writeHost,第一个挂了切到还生存的第二个writeHost,重新启动后已切换后的为准，切换记录在配置文件中：dnindex.properties.

2. writeType="1"，所有写操作都随机的发送到readHost。

3. writeType="2"，所有写操作都随机的在writeHost、readhost分上发。

readHost是从属于writeHost的，即意味着它从那个writeHost获取同步数据，因此，当它所属的writeHost宕机了，则它也不会再参与到读写分离中来，即“不工作了”，这是因为此时，它的数据已经“不可靠”了。基于这个考虑，目前mycat 1.3和1.4版本中，若想支持MySQL一主一从的标准配置，并且在主节点宕机的情况下，从节点还能读取数据，则需要在Mycat里配置为两个writeHost并设置banlance=1。

Mycat里面要将MySQL Slave配置为WriteHost，而不是readHost，这样当第一个WriteHost宕机，Mycat就会自动切换到第二个WriteHost，即MySQL Slave
上，完成自动的故障切换(多主模式)，

readHost是从属于writeHost的，即意味着它从那个writeHost获取同步数据，因此，当它所属的writeHost宕机了，则它也不会再参与到读写分离中来，即“不工作了”，这是因为
此时，它的数据已经“不可靠”了。所以注意，如果只有一个writeHost，主挂了，其所属的readHost读也不能用，所以建议把其中一台slave主机也配成writeHost，比如则需要在一主三从的模式中配置为两个writeHost并设置banlance=1

switchType指的是切换的模式:

1. switchType='-1'  表示不自动切换，意味着当主挂掉的时候，不进行自动切换，即hostS1和hostS2并不会被提升为主，仍只提供读的功能。这就避免了将数据写入slave的可能性，毕竟，单纯的MySQL主从集群并不允许将数据读进slave中，除非配置的是双master。

2. switchType='1'   表示自动切换(默认值)

3. switchType='2'   基于MySQL主从同步的状态决定是否切换,心跳语句为 show slave status

当配置switchType='1'时，如果第一个writeHost宕机，则Mycat会在默认的3次心跳检查失败后，自动切换到下一个可用的writeHost执行DML SQL语句，并在conf/dnindex.properties
文件里自动更新记录当前所用的writeHost的index（第一个为0，第二个为1，依次类推），注意，此文件不能删除和擅自改变，除非你深刻理解了它的作用以及你的目的。

数据切分：

简单来说，就是指通过某种特定的条件，将我们存放在同一个数据库中的数据分散存放到多个数据库（主机）上面，以达到分散单台设备负载的效果。

数据的切分（Sharding）根据其切分规则的类型，可以分为两种切分模式。一种是按照不同的表（或者Schema）来切分到不同的数据库（主机）之上，这种切可以称之为数据的垂直（纵向）切分；另外一种则是根据表中的数据的逻辑关系，将同一个表中的数据按照某种条件拆分到多台数据库（主机）上面，这种切分称之为数据的水平（横向）切分。

垂直切分的最大特点就是规则简单，实施也更为方便，尤其适合各业务之间的耦合度非常低，相互影响很小，业务逻辑非常清晰的系统。在这种系统中，可以很容易做到将不同业务模块所使用的表分拆到不同的数据库中。根据不同的表来进行拆分，对应用程序的影响也更小，拆分规则也会比较简单清晰。由于垂直切分是按照业务的分类将表分散到不同的库，所以有些业务表会过于庞大，存在单库读写与存储瓶颈，所以就需要水平拆分来做解决。

水平切分于垂直切分相比，相对来说稍微复杂一些。因为要将同一个表中的不同数据拆分到不同的数据库中，对于应用程序来说，拆分规则本身就较根据表名来拆分更为复杂，后期的数据维护也会更为复杂一些。相对于垂直拆分，水平拆分不是将表做分类，而是按照某个字段的某种规则来分散到多个库之中，每个表中包含一部分数据。简单来说，我们可以将数据的水平切分理解为是按照数据行的切分，就是将表中的某些行切分到一个数据库，而另外的某些行又切分到其他的数据库中