mysql 主从复制与读写分离

MySQL主从复制原理

1、MySQL的复制类型

• 基于语句的复制

• 基于行的复制

• 混合类型的复制

2、MySQL主从复制的工作过程

主从进行复制，为什么复制？

保证数据完整性

谁复制谁？

slave角色复制master角色的数据

数据放在什么地方？

二进制日志文件当中

mysql-bin.00001 -------> 记录完整的sql

slave复制而精致日志到本地节点，保存为中继日志文件的方式，最后基于这个中继日志进行 “ 恢复 ”操作，将执行的sql同步执行在自己的数据库内，最终达到

主从复制原理：

两个日志：

• 二进制日志

• 中继日志

三个线程：

• master dump线程

  ①用于监听 I/O线程请求

  ②将二进制日志中更新的数据发送给slave I/O线程

• slave I/O线程

• sql线程

主从复制原理：

• Master节点将数据的改变记录成二进制日志 (bin log)，当Master上的数据发生改变时，则将其改变写入二进制日志中

• slave节点会在一定时间间隔内对Master的二进制日志进行探测其是否发生改变，如果发生改变，则开始一个I/O线程请求 Master的二进制日志

• 同时Master节点为每个I/O线程启动一个dump线程，用于向其发送二进制事件，并保存至Slave节点本地的中继日志 (Relaylog)中，SLave节点将启动SQL线程从中继日志中读取二进制日志，在本地重放，即解析成 sq1 语句逐一执行，使得其数据和Master节点的保持一致，最后I/0线程和SQL线程将进入睡眠状态，等待下一次被唤醒。

MYSQL主从复制延迟的原因

• master服务器高并发，形成大量事务

• 网络延迟

• 主从硬件设备导致 【cpu主频 内存io 硬盘io】

• 本来就不是同步复制，而是异步复制

异步复制：

master只要完成就会返回给客户端，并不关心从库是否已经接受并处理数据

同步复制：

等从库完成同步之后才会向客户端返回结果

半同步复制：

只要有一个从库完成同步数据，master就会返回给客户端

主从复制实验：

三台数据库：
主：192.168.86.11
从：192.168.86.22   和   192.168.86.33

yum  -y install  ntp   三台都需要要安装ntp服务
ntpdate ntp.aliyun.com   #同步时间

主配置：
vim /etc/my.cnf
server-id = 1  【ps: 三台数据库的id需不同】
log-bin=master-bin	 #添加，主服务器开启二进制日志
binlog_format = MIXED
log-slave-updates=true	#添加，允许slave从master复制数据时可以写入到自己的二进制日志

systemctl restart mysqld   #重启数据库

mysql -u root -pabc123   #进入数据库
GRANT REPLICATION SLAVE ON *.* TO 'myslave'@'192.168.86.%' IDENTIFIED BY '123456';     #给192.168.86网段进行授权

flush privileges;   #刷新
show master status;   #查看

从配置
vim /etc/my.cnf   
server-id = 2		
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 -u root -pabc123
change master to master_host='192.168.86.11',master_user='myslave',master_password='123456',master_log_file='master-bin.000001',master_log_pos=754;

【ps ：master_host='192.168.86.11'   #主的ip地址
master_log_file 和  master_log_pos 要和主库中show master status 的数据一样】

start slave;     #启动同步，如有报错执行 reset slave;
show slave status\G					#查看 Slave 状态  

【确保 IO 和 SQL 线程都是 Yes，代表同步正常：
Slave_IO_Running: Yes	#负责与主机的io通信
Slave_SQL_Running: Yes	#负责自己的slave mysql进程】

验证 ：
主库中创建数据库： create database 库名;
去从上进行查看： show databases;

MYSQL主从复制延迟的原因

• master服务器高并发，形成大量事务

• 网络延迟

• 主从硬件设备导致 【cpu主频 内存io 硬盘io】

• 本来就不是同步复制，而是异步复制

主从复制的策略：

异步复制：（mysql默认的）

     master只要完成就会返回给客户端，并不关心从库是否已经接受并处理数据

同步复制：

     等从库完成同步之后才会向客户端返回结果

半同步复制：

     只要有一个从库完成同步数据，master就会返回给客户端

 

主从分离的架构

 一、一主多备

• 一般用来读写分离，master写，slave读，这种架构最大问题 “I/O” 压力集中在master上，多台同步影响 “I/O”

二、M-S-S 

• 为中继代理，来分担master的压力，slave中继需要开启bin-log，并配置log-slave-updates
• slave中继使用black-hole 存储引擎，不会把数据源存储在磁盘，只记录在二进制日志

三、M-M/双主互为主备（互为主从）

• 很多人误以为这样可以做mysql负载均衡，实际上没有好处，每个服务器需要同样的同步更新，破坏了事物的隔离性和数据的一致性

读写分离

读写分离原理

• 读写分离就是只在主服务器上写，只在从服务器上读

• 基本的原理是让主数据库处理事务操作，而从数据库处理select查询，数据库复制被用来把主数据库上事务性操作导致的变更同步到集群中的从数据库

读写分离存在的意义

• 因为数据库的 写10000条数据可能要3分钟，操作是比较耗时的，但是数据库的读10000条数据可能只要5秒中。

• 所谓读写分离，解决的是，数据库的写入，影响了查询的效率

什么时候要读写分离？

        数据库不一定要读写分离，如果程序使用数据库较多时，而更新少，查询多的情况下会考虑使用，利用数据库主从同步，再通过读写分离可以分担数据库的压力，提高性能

读写分离的方式

1、基于程序代码内部实现

• 在代码中根据select、insert进行路由分类， 这类方法也是目前生产环境应用最广泛的。

• 优点是性能较好： 因为在程序代码中实现，不需要增加额外的设备为硬件开支。

• 缺点：是需要开发人员来实现，运维人员无从下手。

• 但是并不是所有的应用都适合在程序代码中实现读写分离，像一些大型的java应用，如果在程序代码中实现读写分离对代码改动就较大。

2、基于中间代理层实现

• 代理一般位于客户端和服务器之间，代理服务器接收到客户端请求后通过判断后转发到后端数据库，有以下代表程序。

1. MySql-Proxy 、MySql-Proxy为MySQL开源项目，通过其自带的lua脚本进行判断。

2. Atlas 是由奇虎360的web平台部基础架构团队开发维护的一个基于mysql协议的数据中间层项目，它是在mysql-proxy0.8.2版本的基础上。对于进行了优化，增加了一些新的功能特性，360内部使用atlas运行mysql业务，每条承受的读写请求数达几十亿条，支持事务以及存储过程。

3. Amoeba。 由陈思儒开发，作者曾就职于阿里巴巴，该程序由java语言进行开发，阿里巴巴将其应用于生产环境，但它不支持事务和存储过程。

Amoeba：是一个以mysql为底层的数据存储，并对应提供mysql协议接口的proxy（代理），外号变形虫

• 读取请求发送给从服务器是采用轮询调度算法。

• amoeba使用的java语言编写，配置文件为xml

• amoeba主要负责对外的一个代理ip

• 访问这个ip时，发送的请求为“写”请求，则会转给主服务器。

• 当发送的请求为“读”时，会通过调度转发给从服务器，使用轮询算法，轮流分配给两台从服务器。

• amoeba可以视为调度器，如果主服务器挂掉（单点故障），则会有HMA解决这个问题。