文章目录
引言：
一、读写分离
1、什么是读写分离?
读写分离，基本的原理是让主数据库处理事务性增、改、删操作( INSERT、UPDATE、 DELETE) ，而从数据库处理SELECT查询操作。数据库复制被用来把事务性操作导致的变更同步到集群中的从数据库。
2、为什么要读写分离呢?
因为数据库的“写”(写10000条数据可能要3分钟)操作是比较耗时的。
但是数据库的“读”(读10000条数据可能只要5秒钟)
所以读写分离，解决的是，数据库的写入，影响了查询的效率。
3、什么时候要读写分离?
数据库不一定要读写分离，如果程序使用数据库较多时，而更新少，查询多的情况下会考虑使用。利用数据库主从同步，再通过读写分离可以分担数据库压力，提高性能。
4、主从复制与读写分离
在实际的生产环境中，对数据库的读和写都在同一个数据库服务器中，是不能满足实际需求的。无论是在安全性、高可用性还是高并发等各个方面都是完全不能满足实际需求的。因此，通过主从复制的方式来同步数据，再通过读写分离来提升数据库的并发负载能力。有点类似于rsync，但是不同的是rsync是对磁盘文件做备份，而mysql主 从复制是对数据库中的数据、语句做备份。
二、MySQL读写分离原理
只在主服务器上写，只在从服务器上读
主数据库处理事务性查询，从数据库处理SELECT查询
数据库复制用于将事务性查询的变更同步到集群中的从数据库
环境搭建
四台服务器
Master 服务器: 192.168.161.11 mysql5.7
Slave1 服务器: 192.168.161.12 mysql5.7
Slave2 服务器: 192.168.161.13 mysql5.7
Amoeba 服务器: 192.168.161.14 jdk1.6、Amoeba
客户端服务器: 192.168.102.137 mysql
Amoeba服务器配置
安装Java环境
因为Amoeba基于是jdk1.5 开发的，所以官方推荐使用jdk1.5 或1.6版本，高版本不建议使用。
[root@rocketmq-slave2 ~]# cd /opt/
[root@rocketmq-slave2 opt]# cp jdk-6u14-linux-x64.bin /usr/local/
[root@rocketmq-slave2 opt]# cd /usr/local/
[root@rocketmq-slave2 local]# chmod +x jdk-6u14-linux-x64.bin
[root@rocketmq-slave2 local]# ./jdk-6u14-linux-x64.bin
//按yes， 按enter
[root@rocketmq-slave2 local]# mv jdk1.6.0_14/ /usr/local/jdk1.6
[root@rocketmq-slave2 local]# vim /etc/profile
export JAVA_HOME=/usr/local/jdk1.6
export CLASSPATH=$CLASSPATH:$JAVA_HOME/lib:$JAVA_HOME/jre/lib
export PATH=$JAVA_HOME/lib:$JAVA_HOME/jre/bin/:$PATH:$HOME/bin
export AMOEBA_HOME=/usr/local/amoeba
export PATH=$PATH:$AMOEBA_HOME/bin
[root@rocketmq-slave2 local]# source /etc/profile
[root@rocketmq-slave2 local]# java -version
验证Java环境
** 环境变量**
安装amoeba
[root@rocketmq-slave2 jdk1.6]# mkdir /usr/local/amoeba
[root@rocketmq-slave2 jdk1.6]# cd /opt
[root@rocketmq-slave2 opt]# !t
tar zxvf amoeba-mysql-binary-2.2.0.tar.gz -C /usr/local/amoeba
[root@rocketmq-slave2 opt]# chmod -R 755 /usr/local/amoeba/
[root@rocketmq-slave2 opt]# /usr/local/amoeba/bin/amoeba
amoeba start|stop ##如显示amoeba start|stop说明安装成功
配置Amoeba读写分离，两个Slave读负载均衡
##先在Master、Slave1、Slave2的mysql上开放权限给Amoeba访问
GRANT ALL ON *.* TO 'amoeba'@'192.168.161.%' IDENTIFIED BY '123456';
回到amoeba服务器配置amoeba服务
再回到amoeba服务器配置amoeba服务
[root@rocketmq-slave2 opt]# cd /usr/local/amoeba/conf/
[root@rocketmq-slave2 conf]# cp amoeba.xml amoeba.xml.bak
[root@rocketmq-slave2 conf]# vim amoeba.xml
#修改amoeba配置文件
--30行--
<property name="user">amoeba</property>
--32行--
<property name="password">123456</property>
--115行--
<property name="defaultPool">master</property>
--117去掉注释-
<property name="writePool">master</property>
<property name="readPool">slaves</property>
cp dbServers.xml dbServers.xml.bak
vim dbServers.xml
#修改数据库配置文件
--23行-- 注释掉作用:默认进入test库以防mysql中没有test库时，会报错
<!-- <property name="schema">test</property> -->
--26--修改
<property name="user">test</property>
--28-30--去掉注释
<property name="password">123456</property>
--45--修改，设置主服务器的名Master
<dbServer name="master" parent="abstractServer">
--48--修改，设置主服务器的地址
<property name="ipAddress">192.168.102.133</property>
--52--修改，设置从服务器的名slave1
<dbServer name="slave1" parent="abstractServer">
--55--修改，设置从服务器1的地址
<property name=" ipAddress">192.168.102.134</property>
--58--复制上面6行粘贴，设置从服务器2的名slave2和地址
<dbServer name="slave2" parent="abstractServer">
<property name=" ipAddress">192.168.102.130</property>
--66行--修改
<dbServer name="slaves" virtual="true">
--71行--修改
<property name="poolNames">slave1,slave2</property>
/usr/local/amoeba/bin/amoeba start& #启动Amoeba软件，按ctrl+c返回
netstat -anpt | grep java #查看8066端口是否开启，默认端口为TCP 8066
三、测试读写分离
1、在客户端服务器上测试
yum install -y mariadb-server mariadb
mysql -u amoeba -p123456 -h 192.168.161.11 -P8066
四、数据库主从延迟的原因与解决方案
主从延迟是怎样定义的呢？
与主从数据同步相关的时间点有三个
主库执行完一个事务，写入binlog，我们把这个时刻记为 T1;
主库同步数据给从库，从库接受完这个binlog的时刻，记录为 T2；
从库执行完这个事务，这个时刻记录为 T3。
所谓主从延迟，其实就是指同一个事务，在从库执行完的时间和在主库执行完的时间差值，即 T3-T1。
哪些情况会导致主从延迟呢？
如果从库所在的机器比主库的机器性能差，会导致主从延迟，这种情况比较好解决，只需选择主从库一样规格的机器就好。
如果从库的压力大，也会导致主从延迟。比如主库直接影响业务，大家可能使用会比较克制，因此一般查询都打到从库了，结果导致从库查询消耗大量CPU，影响同步速度，最后导致主从延迟。这种情况的话，可以搞一主多从架构，即多接几个从库分摊读的压力。另外，还可以把binlog接入到Hadoop这类系统，让它们提供查询的能力。
大事务也会导致主从延迟。如果一个事务执行就要10分钟，那么主库执行完后，给到从库执行，最后这个事务可能就会导致从库延迟10分钟啦。日常开发中，我们为什么特别强调，不要一次性delete太多SQL，需要分批进行，其实也是为了避免大事务。另外，大表的DDL语句，也会导致大事务，大家日常开发关注一下哈。
网络延迟也会导致主从延迟，这种情况你只能优化你的网络啦，比如带宽20M升级到100M类似意思等。
如果从数据库过多也会导致主从延迟，因此要避免复制的从节点数量过多。从库数据一般以3-5个为宜。
低版本的MySQL只支持单线程复制，如果主库并发高，来不及传送到从库，就会导致延迟。可以换用更高版本的Mysql，可以支持多线程复制。
如果同步失败可使用以下方法尝试解决
#忽略当前的错误执行下一步的同步
先 stop slave;
① slave数据库中：SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;
START SLAVE;
问题：I/O线程 一直处于connecting
第一件事，看laster error,报错项内容是为支点找不到
先 stop slave;
② slave数据库中：
CHANGE MASTER TO MASTER_LOG_FILE=‘mysql-bin.000001’,MASTER_LOG_POS=0;
首先遇到这个是因为binlog位置索引处的问题，生产环境下不要直接reset slave（删除change master 操作的）；
reset slave会将主从同步的文件以及位置恢复到初始状态，一开始没有数据还好，有数据的话，相当于重新开始同步，可能会出现一些问题；
一般做主从同步，都是要求以后的数据实现主从同步，而对于旧的数据完全可以使用数据库同步工具先将数据库同步，完了再进行主从同步；
好了遇到上面的问题，正确做法是：
1.打开主（master)服务器，进入mysql
2.执行flush logs；//这时主服务器会重新创建一个binlog文件；
3.在主服务上执行show master status\G;显示如下：
4.来到从服务器的mysql；
5.stop slave;
6.change master to master_log_file=‘mysql-bin.000012’,master_log_pos=154;//这里的file和pos都是上面主服务器master显示的。
7.start slave; //这时候就应可以了
五、总结
1、主从同步原理
首先client端（tomcat）将数据写入到master节点的数据库中，master节点会通知存储引擎提交事务，同时会将数据以（基于行、基于sql、基于混合）的方式保存在二进制日志中
SLAVE节点会开启I/O线程，用于监听master的二进制日志的更新，一旦发生更新内容，则向master的dump线程发出同步请求
master的dump线程在接收到SLAVE的I/O请求后，会读取二进制文件中更新的数据，并发送给SLAVE的I/O线程
SLAVE的I/O线程接收到数据后，会保存在SLAVE节点的中继日志中
同时，SLAVE节点钟的SQL线程，会读取中继日志钟的熟，更新在本地的mysql数据库中
最终，完成slave——>复制master数据，达到主从同步的效果
2、如何查看主从同步状态是否成功
在从服务器内输入命令 show slave status\G，查看主从信息进行查看，里面有IO线程的状态信息，还有master服务器的IP地址、端口、事务开始号，
当 slave_io_running 和 slave_sql_running 都显示为yes时，表示主从同步状态成功
3、如果I/O和SQL不是yes呢,你是如何排查的
首先排除网络问题，使用ping命令查看从服务是否能与主服务器通信
再者查看防火墙和核心防护是否关闭
接着查看从服务器内的slave是否开启
两个从服务器的 server-id 是否相同导致只能连上一台
master_log_file 和 master_log_pos 的值要是否与Master查询的一致
4、show slave status能看到哪些信息(比较重要的)
IO线程的状态信息
master服务器的IP地址、端口、事务开始位置
最近一次的报错信息和报错位置等
5、主从复制慢(延迟)有哪些可能
主服务器的负载过大，被多个睡眠或者僵尸线程占用，导致系统负载过大
从库硬件比主库差，导致复制延迟
主从复制单线程，如果主库写并发太大，来不及传送到从库，就会导致延迟。
慢SQL语句过多
网络延迟
6604
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
