前言
在企业应用中，成熟的业务通常数据量都比较大；
单台MySQL在安全性、高可用性和高并发方面都无法满足实际的需求；
配置多台主从数据库服务器以实现读写分离；
一、概念
1.1 什么是读写分离？
读写分离，基本的原理是让主数据库处理事务性增、改、删操作（INSERT、UPDATE、DELETE），而从数据库处理SELECT查询操作。数据库复制被用来把事务性操作导致的变更同步到集群中的从数据库。
1.2 为什么要读写分离呢？
因为数据库的“写”（写10000条数据可能要3分钟）操作是比较耗时的。
但是数据库的“读"（读10000条数据可能只要5秒）。
所以读写分离，解决的是，数据库的写入，影响了查询的效率。
1.3 什么时候要读写分离？
数据库不一定要读写分离，如果程序使用数据库较多时，而更新少，查询多的情况下会考虑使用。利用数据库主从同步，再通过读写分离可以分担数据库压力，提高性能。
1.4 主从复制与读写分离
在实际的生产环境中，对数据库的读和写都在同一个数据库服务器中，是不能满足实际需求的。无论是在安全性、高可用性还是高并发等各个方面都是完全不能满足实际需求的。因此，通过主从复制的方式来同步数据，再通过读写分离来提升数据库的并发负载能力。有点类似于rsync，但是不同的是rsync是对磁盘文件做备份，而mysql主从复制是对数据库中的数据、语句做备份。
1.5 mysql支持的复制类型
（1）STATEMENT：基于语句的复制。在服务器上执行sql语句，在从服务器上执行同样的语句，mysql默认采用基于语句的复制，执行效率高。
（2）ROW：基于行的复制。把改变的内容复制过去，而不是把命令在从服务器上执行一遍。
（3）MIXED：混合类型的复制。默认采用基于语句的复制，一旦发现基于语句无法精确复制时，就会采用基于行的复制。
1.6 主从复制的工作过程
主节点开启binary log，从节点开启relay log
1.主节点有更新（增删改），写入到自己的二进制日志中
2.从节点I/O线程定期勘测主节点二进制日志有无更新，请求读取
3.主节点开启dump线程，发送二进制事件给从节点
4.从节点保存二进制事件到中继日志中
5.然后通过SQL线程进行读取和存放，完成主从复制
注：
中继日志通常会位于OS缓存中，所以中继日志的开销很小。
复制过程有一个很重要的限制，即复制在slave上是串行化的，也就是说Master上的并行更新操作不能在slave上并行操作。
半同步复制，多一个ack确认线程
1.7 数据库主从数据不一致解决方案（面试常问）
方法一：忽略错误后，继续同步
该方法适用于主从库数据相差不大，或者要求数据可以不完全统一的情况，数据要求不严格的情况
方式二：重新做主从，完全同步
该方法适用于主从库数据相差较大，或者要求数据完全统一的情况
1.8 MySQL读写分离原理
读写分离就是只在主服务器上写，只在从服务器上读。基本的原理是让主数据库处理事务性操作，而从数据库处理select查询。数据库复制被用来把主数据库上事务性操作导致的变更同步到集群中的从数据库。
1.9 目前较为常见的MysQL读写分离分为以下两种
1）基于程序代码内部实现
在代码中根据select、insert进行路由分类，这类方法也是目前生产环境应用最广泛的。
优点是性能较好，因为在程序代码中实现，不需要增加额外的设备为硬件开支；缺点是需要开发人员来实现，运维人员无从下手。
但是并不是所有的应用都适合在程序代码中实现读写分离，像一些大型复杂的Java应用，如果在程序代码中实现读写分离对代码改动就较大。
2）基于中间代理层实现
代理一般位于客户端和服务器之间，代理服务器接到客户端请求后通过判断后转发到后端数据库，有以下代表性程序。
（1）MySQL-Proxy。MySQL-Proxy为MysQL开源项目，通过其自带的1ua脚本进行sQL判断。
（2）Atlas。是由奇虎360的Web平台部基础架构团队开发维护的一个基于MysQL协议的数据中间层项目。它是在mysql-proxy 0.8.2版本的基础上，对其进行了优化，增加了一些新的功能特性。360内部使用atlas运行的mysql业务，每天承载的读写请求数达几干保条。支持事物以及存储过程。
（3）Amoeba。由陈思儒开发，作者曾就职于阿里巴巴。该程序由Java语言进行开发，阿里巴巴将其用于生产环境。但是它不支持事务和存储过程。
（4）Mycat。是一款流行的基于Java语言编写的数据库中间件，是一个实现了MySq1协议的服务器，其核心功能是分库分表。配合数据库的主从模式还可以实现读写分离
由于使用MysQLProxy需要写大量的ua脚本，这些Lua并不是现成的，而是需要自己去写。这对于并不熟悉MysQLProxy 内置变量和MySQL Protocol的人来说是非常困难的。
Amoeba是一个非常容易使用、可移植性非常强的软件。因此它在生产环境中被广泛应用于数据库的代理层。
二、MySQL主从复制延迟原因
1、master服务器高并发，形成大量事务
2、网络延迟
3、主从硬件设备导致（cpu主频、内存io、硬盘io）
4、是同步复制、而不是异步复制
从库优化Mysql参数。比如增大innodb_buffer_pool_size，让更多操作在Mysql内存中完成，减少磁盘操作。
从库使用高性能主机。包括cpu强悍、内存加大。避免使用虚拟云主机，使用物理主机，这样提升了i/o方面性。
从库使用SSD磁盘
网络优化，避免跨机房实现同步
三、MySQL主从复制的几个同步模式
●异步复制（Asynchronous replication）
MySQL默认的复制即是异步的，主库在执行完客户端提交的事务后会立即将结果返给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，主如果crash掉了，此时主上已经提交的事务可能并没有传到从上，如果此时，强行将从提升为主，可能导致新主上的数据不完整。
●全同步复制（Fully synchronous replication）
指当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响。
●半同步复制（Semisynchronous replication）
介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay log中才返回给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。所以，半同步复制最好在低延时的网络中使用。
四、主从复制案例（异步复制）
实验环境
Master 服务器：192.168.109.137 mysql5.7 centos7-7
Slave1 服务器：192.168.109.134 mysql5.7 centos7-4
Slave2 服务器：192.168.109.135 mysql5.7 centos7-5
每台服务器关闭防火墙和selinux
#关闭防火墙以及其开机自启 systemctl disable --now firewalld setenforce 0
主服务器7-7 192.168.109.137
#安装时间同步工具（本地设置时钟源） yum install -y ntp #末尾加入 vim /etc/ntp.conf server 127.127.109.0 #设置本地是时钟源，注意修改网段（109是网段） fudge 127.127.109.0 stratum 8 #设置时间层级为8（限制在15以内） #开启ntpd systemctl start ntpd
从服务器 7-5 192.168.109.135
从服务器 7-4 192.168.109.134
#安装时间同步工具 yum install -y ntp #开启ntpd systemctl start ntpd #进行时间同步 /usr/sbin/ntpdate 192.168.109.137 crontab -e */30 * * * * /usr/sbin/ntpdate 192.168.109.137
主服务器
--—-主服务器的mysql配置---- vim /etc/my.cnf server-id = 1 #服务器标识 log-bin=mysql-bin #添加，主服务器开启二进制日志 binlog_format = MIXED #二进制日志模式 log-slave-updates=true #添加，允许slave从master复制数据时可以写入到自己的二进制日志 expire_logs_days = 7 #设置二进制日志文件过期时间，默认值为0，表示logs不过期 max_binlog_size = 500M #设置二进制日志限制大小，如果超出给定值，日志就会发生滚动，默认值是1GB #重启服务 systemctl restart mysqld #进入mysql mysql -uroot -p000000 #给从服务器授权 GRANT REPLICATION SLAVE ON *.* TO 'myslave'@'192.168.109.%' IDENTIFIED BY '000000'; #刷新权限 FLUSH PRIVILEGES; #查看主服务器状态 #File 列显示日志名，Position 列显示偏移量 mysql> mysql> show master status; +------------------+----------+--------------+------------------+-------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +------------------+----------+--------------+------------------+-------------------+ | mysql-bin.000002 | 604 | | | | +------------------+----------+--------------+------------------+-------------------+ 1 row in set (0.00 sec)
从服务器
vim /etc/my.cnf server-id = 2 #修改，注意id与Master的不同，两个Slave的id也要不同 relay-log=relay-log-bin #添加，开启中继日志，从主服务器上同步日志文件记录到本地 relay-log-index=slave-relay-bin.index #添加（索引文件），定义中继日志文件的位置和名称，一般和relay-log在同一目录 relay_log_recovery = 1 #选配项 #当 slave 从库宕机后，假如 relay-log 损坏了，导致一部分中继日志没有处理，则自动放弃所有未执行的 relay-log，并且重新从 master 上获取日志，这样就保证了 relay-log 的完整性。默认情况下该功能是关闭的，将 relay_log_recovery 的值设置为 1 时， 可在 slave 从库上开启该功能，建议开启。 #重启服务 systemctl restart mysqld #进入mysql mysql -uroot -p000000 #配置同步，注意 master_log_file 和 master_log_pos 的值要与Master查询的一致 CHANGE master to master_host='192.168.109.137',master_user='myslave',master_password='000000',master_log_file='mysql-bin.000002',master_log_pos=604; start slave; #启动同步，如有报错执行 reset slave; show slave status\G #查看 Slave 状态 #确保 IO 和 SQL 线程都是 Yes，代表同步正常。 Slave_IO_Running: Yes #负责与主机的io通信 Slave_SQL_Running: Yes #负责自己的slave mysql进程 #一般 Slave_IO_Running: No 的可能性： 1、网络不通 2、my.cnf配置有问题(server-id重复) 3、密码、file文件名、pos偏移量不对 4、防火墙没有关闭
测试
