读写分离

读写分离需要借助MyCat来实现，我们要借助MyCat的两个标签(writeHost、readHost)以及一个属性(balance)进行控制

配置 MyCat控制后台数据库的读写分离和负载均衡由/usr/local/mycat/conf目录的schema.xml文件里面的'datahost标签的balance属性'来控制

balance指的是负载均衡策略，目前取值有四种(0、1、2、3。其中1和3是用于读写分离，3是用于一主一从分离，1是既可以一主一从也可以双主双从)如下 第一种:0(默认)，表示不开启读写分离机制，所有读操作都发送到当前可用的writeHost上。也就是读写操作只会被路由到单台特定服务器 第二种:1，表示全部的readHost与备用的writeHost都参与select语句的负载均衡，主要用于双主双从模式 第三种:2，表示所有的读写操作都随机在writeHost，readHost上分发。也就是读写操作会被随机路由到任意服务器 第四种:3，所有的读请求随机分发到writeHost对应的readHost上执行。writeHost不负担读压力，只负担写压力

具体演示

1、在主库(第一台服务器)配置/usr/local/mycat/conf目录的schema.xml文件(我会打包放在模板文件里面)

2、在主库(第一台服务器)配置/usr/local/mycat/conf目录的rule.xml、server.xm文件(我会打包放在模板文件里面)

3、在第一台服务器启动mycat

#停止
cd /usr/local/mycat && bin/mycat stop
#启动
cd /usr/local/mycat && bin/mycat start
#通过查看mycat日志文件来验证是否启动成功。日志末尾为successfully表示启动成功、Wrapper Stopped表示启动失败
cd /usr/local/mycat && tail -f logs/wrapper.log(需要大概10秒才能启动成功)

4、确保自己的主库(第一台服务器)、从库(第二台服务器)都有duxiefenli_itcast数据库，没有的话，去上一节课把命令运行一遍

5、在第一台服务器登录进mycat

mysql -h 192.168.127.138 -P 8066 -u root -p123456

6、验证。查看ITCAST_RW逻辑库里面有没有tb_user逻辑表，并在tb_user逻辑表里面进行读和写操作，看会被路由到哪个服务器

show databases;
use ITCAST_RW;
show tables;
select * from tb_user;
insert into tb_user(id,name,sex) values(4,'张三',0);
select * from tb_user;

如何知道MyCat在我们读数据的时候，到底路由的是哪台服务器，我们可以用下面的思路 分析:由于我们主库的数据会同步到从库，但是从库的数据是不会被同步到主库的，所以我们可以在从库对某条数据进行更新，此时 这条数据在主库和在从库是不一样的，我们在查一下，看查到这条数据是什么，如果是从库的数据，就证明是路由到从库，如下 在从库(第二台服务器)登录进mysql，并执行use duxiefenli_itcast; update tb_user set name = '乌拉' where id = 1;

select * from tb_user; #结论是查询到的数据是从库里面的，所以证明查操作是被路由到从库

如何知道MyCat在我们写数据的时候，到底路由的是哪台服务器，我们可以用下面的思路 分析:一定是路由到主库。原因:如果插入数据是修改的从库的数据，那我们查看主库的时候，主库的数据还是原来的没更新的，但是 我们在查看主库的数据，发现主库是更新过来了的，也就是说明写操作是被路由到主库

insert into tb_user(id,name,sex) values(5,'李四',1);

优点:

1、主库的数据会实时同步到从库

2、主库宕机了，查询业务不会受影响，因为查询操作是只查从库

存在的问题:

1、由于只有一台主库、一台从库，所以当主库宕机了，所有的增删改操作都无法执行(只能执行查操作)，就存在高可用问题

2、下节课会学习双主双从，来解决这里的高可用问题