MySQL主从复制和读写分离

主从复制

主从复制架构图和数据流向

主从复制：主MySQL上的数据，新增、修改库、表、表里的数据，都会同步到从MySQL上

Q：MySQL的主从复制模式

A：1、异步复制：MySQL的默认复制，就是异步复制

异步：类似于udp。只要执行完之后，客户提交事务，主MySQL会立即把结果返回给从服务器，主MySQL并不关心从MySQL是否已经接受并且处理。

主一旦崩溃，主MySQL的事务可能没有传到从MySQL，这个时候强行把从提升为主，可能新的主MySQL数据不完整。（很少见，工作中都是异步复制）

2、全同步复制

主库执行完成一个事务之后，所有的从库都执行了该事务，才会返回客户端。

因为需要等待所有从库全部执行完成，性能必然下降（适用于：对数据一致性和数据完成要求很好的场景）

3、半同步复制

介于异步复制和全同步复制之间。主库执行完一个客户端提交的事务之后，至少等待一个从库接收并处理完成之后才会返回给客户端。

半同步在一定程度上提高了数据的安全性，也会有一定的延迟（延迟：一般是一个tcp/ip的往返时间）（从发送到接收的时间，单位是毫秒）【半同步复制最好在低延时的网络中使用】

时间=20ms：round-trip time RTT

---------------------------------------------------------------------------------------------------------------------------------

主从复制的实验

架构主从复制和读写分离

MySQL1 主  10

MySQL2 从 20

MySQL3 从 30

test1 读写分离的服务器 40

test2 客户端 50

主：

vim /etc/ntp.cnf

server 127.127.233.0

fudge 127.127.233.0 stratum 8

数字越小，时间精确度越高，设置fudge 8 时间级是8 最高到15。从本地获取时间源同步

systemctl restart ntpd

主从同步

date

主

vim /etc/my.cnf

log-bin=master-bin

打开二进制日志

binlog_format=MIXED

log-salve-updates=true

允许从服务器复制数据时，可以从主的二进制日志写到自己的二进制日志当中

mysql -u root -p123456

grant replication slave on *.* to ‘myslave’@’192.168.233.%’ identified by ‘123456’;

flush privileges;

show master status;

然后去从20

vim /etc/my.cnf

server -id = 2

relay-log=relay-log-bin

relay-log-index=slave-relay-bin.index

relay_log_recovery=1

#默认是0，1是开启中继服务器的恢复。从服务器出现异常或者崩溃时，从服务器会从主服务器的二进制日志的争取读取和应用中继日志。同步

:wq!

systemctl restart mysql

从3

vim /etc/my.cnf

server -id = 3

relay-log=relay-log-bin

relay-log-index=slave-relay-bin.index

relay_log_recovery=1

:wq!

systemctl restart mysql

从2、3

mysql -u root -p123456

change master to master_host='192.168.233.10',master_user='myslave',master_password='123456',master_log_file='master-bin.000010',master_log_pos=604;

start slave;

shoow slave status\G;

负责和主库的IO通信

负责自己的slave mysql进程是否开启

两个必须都是YES

Q：如果slave_IO-running=NO

A：1、网络问题

2、my.cnf配置文件写错了

3、CHANGE  master  to

master_host='192.168.233.10',master_user='myslave',master_password='123456',master_log_file='master-bin.000010',master_log_pos=604;要么是文件名错了，要么就是位置偏移量不对

4、防火墙和安全机制的问题

navicat 主

create database kgc;

create table test (name varchaer(10));

vavicat 从

create databaes abc;

注意：

主从复制是单向的，只能从主复制到从，不会从从复制到主

---------------------------------------------------------------------------------------------------------------------------------

Q：主从复制的延迟问题

A：1、网络延迟

2、主从的硬件设备【CPU的主频率、内存的IO、硬件的IO】

3、使用同步复制而不是异步复制

解决方案：

1、硬件方面

主库一般不需要动的太多，从库的硬件配置要更好。提升他的随机写的性能。硬盘可以换成固态的、升级CPU的核数、扩展一下内存。尽量使用物理机（不要用云服务器）2、网络层面

2、网络层面

主从服务器都配置在一个局域网内，尽量避免跨网段和跨机房

3、架构方面

做读写分离，把写入控制在主库，从库只负责读

4、配置方面

MySQL配置。从配置文件的角度实现性能最大化

追求安全性的配置：

innodb_flush_log_at_trx_commit=1

1  默认值。每次事务提交时，都会刷新事务日志，以确保持久性。最高级别的数据安全性，但是会影响性能。

0  事务提交时不会立刻刷新，而是每秒刷新一次，可以提高性能，但是发生故障会导致数据丢失

2  事务提交时，事务日志不会写入硬盘，而是保存在系统缓存，也不会进行刷新，提供了一定的安全性和性能，但是对内存要求比较高

生产中默认是1

sync binlog=1

1  也是默认值。每次事务提交之后，直接把二进制日志刷新到磁盘，以确保日志的持久性。占用比较高的性能，但是安全性高

0  把二进制日志写入缓存，也不会刷新日志。故障发生，数据会丢失。对内存的要求高

N  自定义数字。每提交N次事务执行一次刷新到磁盘。可以提高性能，但是一旦崩溃，数据会大量丢失

追求性能化：

sync binlog=0

innodb_flush_log_at_trx_commit=2

logs-slave-updates=0

从库的更新不会写入二进制日志

innodb_buffer_pool_size 300M  8888G

size后面的随便写。innodb存储引擎的缓冲池大小，设置的数值越高，可以提高innodb的性能

更多的数据和所引都可以缓存在内存中。减少磁盘的访问次数，对系统内存要求比较高

主从复制的工作过程

1、主节点的数据记录发生变化都会记录在二进制日志

2、slave节点会一定时间内对主库的二进制文件进行探测，看其是否发生变化。如果有变化，从库会开启I/O的线程，请求的主库的二进制事件

3、主库会给每一个I/O的线程启动一个dump（mysqldump），用于发送二进制事件给从库，从库通过I/O线程获取更新，slave_sql负责将更新写入到从库本地，实现主从一致

主从复制的问题

1、只能在主库上发生变化，然后同步到从

2、复制过程是串行化过程，在从库上复制是串行的，主库的并行更新不能在从库上并行操作

3、主从复制的设计目的就是为在主库上写，在从库上查。读写分离，实现高可用

读写分离

读写分离

要实现读写分离，就必须要实现主从复制

读写分离：所有的写入操作都在主库，从库只负责读。（select）如有更新，是从主库复制到从库

为什么要有读写分离？

1、数据库在写入数据时比较耗时

以MySQL为例：写10000条数据，需要3分左右

2、读比较快

以MySQL为例：读10000条需要4.96s

读写分离之后，数据的写入和读取是分开的，哪怕写入的数据量比较大，但是不影响查询的效率

什么场景下需要读写分离？

数据库不是一定需要读写分离的，只有在某些程序在使用数据库过程中，更新少，但是查询较多，这种情况可以考虑读写分离

读和查的需求差不多，也可以考虑读写分离

生产库一般都会做读写分离，测试库一般不会

在工作中，数据库的读写不会在同一个库中完成。这样既不安全，也不能满足高可用，也不能实现高并发。工作中都会做读写分离

MySQL读写分离的原理

1、根据脚本实现

在代码当中实现路由分类。对开发的要求较高，在select或者insert中进行路由分类。这种方式是最多的。

优点：性能好，在代码中就可以实现，不需要额外的硬件设备

缺点：①开发实现的，和咱无关；②如果大型的复杂的应用，设计改动的代码非常多

2、基于中间代理层实现

mysql-proxy 是MySQL自带的开源项目，基于自带的lua脚本。这些lua脚本不是现成的，要自己写，不熟悉他的内置变量写不出来

3、atlas（阿特拉斯）

360内部的自己使用的代理工具。每天的读写请求承载量可以达到几十亿条。支持事务、支持存储过程

4、Amoeba

开发人：陈思儒，之前在阿里就职。是由Java开发的一个开源软件。不支持事务、不支持存储过程。但是Amoeba还是用的最多的，功能比较强大的软件

Amoeba来实现读写分离

---------------------------------------------------------------------------------------------------------------------------------

读写分离的实验

MySQL1 主  10

MySQL2 从 20

MySQL3 从 30

test1 读写分离的服务器 40

test2 客户端 50

读写分离的数据流向

---------------------------------------------------------------------------------------------------------------------------------

Q1：主从复制的原理

A1：

Q2：读写分离的实现方式

A2：amoeba实现、mycat实现

通过amoeba代理服务器，实现只在主服务器上写，只在从服务器上读；

主数据库处理事务性查询，从数据库处理select 查询；

数据库复制被用来把事务查询导致的变更同步的集群中的从数据库

Q3：如何查看主从同步的状态是否成功

A3：

在从服务器上内输入 show slave status\G; 查看主从信息查看里面有IO线程的状态信息，还有master服务器的IP地址、端口事务开始号。

当 Slave_IO_Running和Slave_SQL_Running都是YES时 ，表示主从同步状态成功

或者

在主库创建一个库或者表，看是否能同步到从库

Q4：如果slave_IO_running=NO，排查思路是什么？

A4：首先排查网络问题，使用ping 命令查看从服务器是否能与主服务器通信

再查看防火墙和核心防护是否关闭（增强功能）

接着查看从服务slave是否开启

两个从服务器的server-id 是否相同导致只能连接一台

master_log_file master_log_pos的值跟master值是否一致

Q5：show slave status\G;能看到的信息有哪些？【⭐⭐⭐】

A5：

1、IO和sql的线程状态信息

2、master服务的ip地址，端口，事务开始的位置

3、最近一次的错误信息和错误的位置

4、最近一次的IO报错信息

5、最近一次的sql的报错信息

Q6：主从复制的延迟如何解决

A6：

mysql语句过多

网络延迟

mysql主从复制对版本的要求：若主从版本不一致，从的版本一定要高于主，保证可以向下兼容。因为若主的版本更新，低版本的从无法兼容的