mysql-proxy读写分离

转发到后端从库 读取。实现 主库负责--写入，从库负责--读取。

注意:Proxy其实不是一台机器，只是一个连接方式，读取数据的时候自动从Salve上取，写数据则自动向Master中写。

实验前先做好 主从架构

主---192.168.1.252 （mysql-5.7 ,三台版本一致）

从---192.168.1.101

proxy---192.168.1.102

vim /etc/mysql-proxy.cnf

内容如下：

注意：（在服务器上配置文件要把注释都去掉，不然会报错。）

保存退出。赋予660权限，不然会报错。

3.##修改读写配置文件

关闭可以用killall -9 mysql-proxy 或者kill -9 ID

在主执行：(事先做好主从架构，从库会自动吧这个 *** 作更新过去，或者在手动去从库也执行一遍)

使用客户端去链接mysql-proxy(1.102)(开2个以上客户端链接)

接下来，测试数据。（主从都开启时，先添加一条数据）

此时如果停掉slave，在添加数据

stop slave

发现并没有刚才添加的id为2的这条数据。

因为此时slave已经停掉了，没有负责给我们提供查询 *** 作的服务了，所以查不到了。刚才可以写入，也是意味着 写入 *** 作是有 master来完成的。

这时恢复slave，再查询

start slave

这时2已经有了，恢复了slave后，先主从通信同步了刚才的数据，再继续提供查询 *** 作。

到此，读写分离完成。

参考：

但我们仔细观察我们会发现，当我们的项目都是用的单体数据库时，那么就可能会存在如下问题：

为了解决上述提到的两个问题，我们可以准备两 (多) 台MySQL，一台主( Master )服务器，一台从( Slave )服务器，主库的 数据变更 (写、更新、删除这些 *** 作) ，需要 同步 到从库中 (主从复制) 。而用户在访问我们项目时，如果是 写 *** 作 (insert、update、delete)，则直接 *** 作 主库 ；如果是 读 *** 作 (select) ，则直接 *** 作从库，这种结构就是 读写分离 啦。

在这种读写分离的结构中，从库是可以有多个的

MySQL主从复制是一个 异步 的复制过程，底层是基于Mysql数据库自带的 二进制日志 功能。就是一台或多台MySQL数据库（slave，即 从库 ）从另一台MySQL数据库（master，即 主库 ）进行日志的复制，然后再解析日志并应用到自身，最终实现 从库 的数据和 主库 的数据保持一致。MySQL主从复制是 MySQL数据库自带功能，无需借助第三方工具。

二进制日志（BINLOG）记录了所有的 DDL（数据定义语言）语句和 DML（数据 *** 纵语言）语句，但是不包括数据查询语句。此日志对于灾难时的数据恢复起着极其重要的作用，MySQL的主从复制， 就是通过该binlog实现的。默认MySQL是未开启该日志的。

在环境搭建之前，我们需要准备好两台服务器，如果生活富裕使用的是两台云服务器的时候记得要开放安全组，即防火墙；如果是比狗子我生活好点但也是用的虚拟机的话，记得别分这么多内存启动蓝屏了（别问怎么知道的）

这里就不给大家展示数据库的安装和防火墙的 *** 作了，这个我感觉网上好多资源都能够满足遇到的问题，在搭建主从库的时候有在网上见到过说MySQL版本要一致的，我也没太留意直接就在之前的MySQL上 *** 作了，大家可以自己去验证一下。

服务器：192.168.150.100（别试了黑不了的，这是虚拟机的ip）

这里有三个方法都能重启MySQL，最简单的无疑就是一关一开：

登录进去MySQL之后才能够执行下面的命令，因为这是SQL命令，Linux不认识这玩意是啥。

这个时候还 不用退出MySQL ，因为下面的命令还是SQL命令，执行下面的SQL，可以拿到我们后面需要的两个重要参数。

执行完这一句SQL之后，==不要再 *** 作主库！不要再 *** 作主库！不要再 *** 作主库！==重要的事情说三遍，因为再 *** 作主库之后可能会导致红框中的 两个属性值会发生变化 ，后面如果发生了错误可能就和这里有那么两毛钱关系了。

服务器：192.168.150.101（别试了黑不了的，这也是虚拟机的ip）

这里要注意server-id和主库以及其他从库都不能相同，否则后面将会配置不成功。

这里有三个方法都能重启MySQL，最简单的无疑就是一关一开：

登录进去MySQL之后才能够执行下面的命令，因为这是SQL命令

参数说明：

这个时候还 不用退出MySQL ，因为下面的命令还是SQL命令，执行下面的SQL，可以看到从库的状态信息。通过状态信息中的 Slave_IO_running 和 Slave_SQL_running 可以看出主从同步是否就绪，如果这两个参数全为 Yes ，表示主从同步已经配置完成。

这可能是由于linux 是复制出来的，MySQL中还有一个 server_uuid 是一样的，我们也需要修改。 vim /var/lib/mysql/auto.cnf

这应该就是各位大牛设置server_id的时候不小心设置相同的id了，修改过来就行，步骤在上面的配置中。

这是狗子在 *** 作过程中搞出来的一个错误……

出错的原因是在主库中删除了用户信息，但是在从库中同步的时候失败导致同步停止，下面记录自己的 *** 作（是在进入MySQL的 *** 作且是从库）。

在数据库中 *** 作时，一定要注意当前所在的数据库是哪个，作为一个良好的实践：在SQL语句前加 USE dbname。

Sharding-JDBC定位为 轻量级Java框架 ，在Java的JDBC层提供的额外服务。 它使用客户端直连数据库，以 jar包 形式提供服务，无需额外部署和依赖，可理解为增强版的JDBC驱动， 完全兼容JDBC和各种ORM框架 。

使用Sharding-JDBC可以在程序中轻松的实现数据库 读写分离 。

Sharding-JDBC具有以下几个特点：

下面我们将用ShardingJDBC在项目中实现MySQL的读写分离。

在pom.xml文件中导入ShardingJDBC的依赖坐标

在application.yml中增加数据源的配置

这时我们就可以对我们项目中的配置进行一个测试，下面分别调用一个更新接口和一个查询接口，通过查看日志中记录的数据源来判断是否能够按照我们预料中的跑。

搞定！！！程序正常按照我们预期的成功跑起来了，成功借助ShardingJDBC在我们项目中实现了数据库的读写分离。

一.mysql主从库与读写分离的实现理论

二.mysql配置

1.准备两台服务器安装mysql(也可以在一台中装两个mysql修改端口号避免冲突)

2.分别连接mysql

3.配置mysql

1.配置主库 monster

打开binary log

2.配置从库

主库授权

账号repl后面的是从库的ip地址 mysql是账号repl的密码

刷新

后面master_log_pos=0 表示从零开始同步 master_log_file 是上面SHOW MASTER STATUS 下面的file文件

在从库中开启主从跟踪

查看从库状态

从库中终止主从同步 stop slave

查看 my.cnf 文件 把 server -id=1 的字段删除 保留server-id=2 修改后保存 重启mysql 重新连接 开启主从同步start slave

查看从库状态 发现没有错误 到此主从同步配置已经完成.

---