mysql主从复制和读写分离

mysql主从复制和读写分离

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

面试题：

mysql的主从复制的模式：

1、异步复制：mysql的默认复制就是异步复制。只要执行完之后，客户端提交事务，主mysql会立即把结果返回给从服务器，主mysql并不关心从mysql是否已经接收，并且处理。

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

2、全同步复制：主库执行完成一个事务，要等所有的从库都执行了该事务之后才会返回客户端

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

3、半同步复制：介于异步复制和全同步复制之间。主库执行完一个客户端提交的事务之后，至少要等待一个从库接收并处理完成之后才会返回给客户端。半同步在一定程度上提高了数据的完全性。也会有一定的延迟

这个延迟一般是一个tcp/ip的往返时间（从发送到接收的时间，单位是毫秒），半同步复制最好在低延时的网络中使用

时间<1ms：round-trip time RTT

架构主从复制和读写分离：

mysql1 主 192.168.233.110

mysql2 从 192.168.233.120

mysql3 从 192.168.233.130

wyh1  读写分离的服务器 192.168.233.30

wyh2  客户端 192.168.233.100

主从服务器之间的时间也要同步

fudge 127.127.233.0 stratum 8：数字越小，时间越精确越高，设置fudge 8 时间层级是8 最高可以到15（但没必要），从本地获取时间源同步，不连接网络

log-slave-updates=true：允许从服务器复制数据时，可以从主的二进制日志写到自己的二进制日志当中

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

CHANGE master to master_host='192.168.233.21',master_user='myslave',master_password='123456',master_log_file='master-bin.000001',master_log_pos=604;

slave_IO_Running:Yes：负责和主库的IO通信

Slave_SQL_Running:Yes：负责自己的slave mysql进程

面试题：

slave io running 是no

1、网络问题

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

3、CHANGE master to master_host='192.168.233.21',master_user='myslave',master_password='123456',master_log_file='master-bin.000001',master_log_pos=604;要么是文件名错了，要么位置偏移量不对

主从复制是单向的，只能从主复制到从服务器

面试题：

主从复制延迟的问题：

1、网络延迟

2、主从硬件设备（CPU主频、内存IO、硬件IO）

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

解决方案：

1、硬件方面，主库一般来说不需要动的太多，从库的硬件配置要更好。提升随机写的性能，硬盘可以考虑换成固态的

升级cpu的核数，扩展一下内存。尽量使用物理机（不要用云服务器）4核8G，硬盘

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

3、架构方面：读写分离，把写入控制在主库，从库负责读，降低从库的压力

4、配置方面mysql配置。从配置文件的i导读实现性能最大化

追求安全性的配置:

innodb flush log at trx commit=1

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

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

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

sync binlog1

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

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

3，每3个事务执行一次刷新到磁盘，提高性能，但是一旦崩溃，数据会大量丢失

追求性能化:

sync binlog-0

innodb flush log at trx commit=2

logs-slave-updates=0

从库的更新不会写入二进制日志(不建议)

主从复制的工作过：

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

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

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

面试题

主从复制的问题:

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

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

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

读写分离:

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

读写分离: 所有的写入操作都在主库，从库只负责读。(select)。

为什么要有读写分离:

1、数据库在写入数据时，比较耗时 (写10000条数据 3分)

2、数据库在读的时候，速度很快(读10000条，4.96s)

读写分离之后，数据的写入和读取是分开的，哪怕写入的数据量比较大，但是不影响查询的效率。什么场景下需要读写分离:

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

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

生产库一般都会做读写分离

测试库一般不管

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

mysql读写分离的原理:

1. 根据脚本实现。在代码中实现路由分类。select insert进行路由分类。这种方式是最多的.性能好，在代码中就可以实现，不需要额外的硬件设备缺点:开发实现的，跟我们无关。如果大型的复杂的应用，设计改动的代码非常多。

2、基于中间代理层实现:

mysgql-proxy自带的开源项目，基于自带的lua脚本。这些ua脚本不是现成的，要自己写，不熟悉他的内置变量写不出来的atlas 360内部做自己使用的代理工具。每天的读写请求承载量可以到几十亿条。支持事务，支持存储过程

Amoeba 陈思儒，之前在阿里就职。是由iava开发的一个开源团建，不支持事务，也不支持存过程，但是Amoeba还是用的最多的

功能比较强大的软件。

Amoeba:来实现读写分离

面试题:

1、主从复制的原理

2、读写分离的视线方式: 脚本 amoeba实现，mycat实现

3、如何查看主从复制是否成功?

show slave statuslG.

Slave lO Running: Yesslave SQL Running: Yes

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

4、如果slave_lo_running no 排查思路是什么?

85%配置文件中

*5、show slave status\G;能看到的信息有哪些

（1、lO和sql的线程状态信息

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

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

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

（5、最近一次sl的报错信息

6、主从复制的延迟如何解决

实验：

架构主从复制和读写分离：

mysql1 主 192.168.233.110

mysql2 从 192.168.233.120

mysql3 从 192.168.233.130

wyh1  读写分离的服务器 192.168.233.30

wyh2  客户端 192.168.233.100

systemctl stop firewalld

systemctl disable firewalld

setenforce 0

----------------------搭建 MySQL主从复制--------------------------------

----Mysql主从服务器时间同步----

##主服务器设置##

yum install ntp -y

vim /etc/ntp.conf

--末尾添加--

server 127.127.233.0 #设置本地是时钟源，注意修改网段

fudge 127.127.233.0 stratum 8 #设置时间层级为8（限制在15内）

#数字越小表示时钟源越精确。通常，

本地时钟源被设置为较高的 stratum 等级（例如，8）以表示它不是通过网络获取的，

而是本地的。

service ntpd start

##从服务器设置##

yum install ntp ntpdate -y

service ntpd start

/usr/sbin/ntpdate 192.168.233.110 #进行时间同步

crontab -e

*/30 * * * * /usr/sbin/ntpdate 192.168.233.110

----主服务器的mysql配置-----

vim /etc/my.cnf

server-id = 1

log-bin=master-bin #添加，主服务器开启二进制日志

binlog_format = MIXED

log-slave-updates=true #添加，允许slave从master复制数据时可以写入到自己的二进制日志

systemctl restart mysqld

mysql -u root -p123456

GRANT REPLICATION SLAVE ON *.* TO 'myslave'@'192.168.233.%' IDENTIFIED BY '123456';

#给从服务器授权

FLUSH PRIVILEGES;

show master status;

//如显示以下

+-------------------+----------+--------------+------------------+

| File              | Position | Binlog_Do_DB | Binlog_Ignore_DB |

+-------------------+----------+--------------+------------------+

| master-bin.000001 |    604   |              |                  |

+-------------------+----------+--------------+------------------+

1 row in set (0.00 sec)

#File 列显示日志名，Position 列显示偏移量

----从服务器的mysql配置----

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_recovery = 1

relay-log=relay-log-bin:

指定了从服务器上中继日志的基本文件名。在这个例子中，

中继日志的文件名将以 "relay-log-bin" 开头。

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

指定了中继日志索引文件的名称。中继日志索引文件用于记录中继日志文件的顺序和位置。

在这个例子中，索引文件名为 "slave-relay-bin.index"。

relay_log_recovery=1:

用于配置从服务器在启动时是否执行中继日志的恢复操作。设置为 1 表示启用中继日志的恢复，

通常在从服务器出现异常或崩溃后重启时使用。

这有助于确保从服务器能够从主服务器的二进制日志中正确地读取和应用中继日志，以保持数据一致性

systemctl restart mysqld

mysql -u root -p123456

CHANGE master to master_host='192.168.233.110',master_user='myslave',master_password='123456',master_log_file='master-bin.000001',master_log_pos=604;

#配置同步，注意 master_log_file 和 master_log_pos 的值要与Master查询的一致

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配置有问题

3、密码、file文件名、pos偏移量不对

4、防火墙没有关闭

----验证主从复制效果----

主服务器上进入执行 create database db_test;

去从服务器上查看 show databases;

*主从复制的设计初衷是在主服务器上进行写操作，而从服务器用于读操作，以提高系统的读取性能和冗余备份。

这是一个单向的过程，从服务器不能将变更写回到主服务器

默写：

1、mysql 左连 右连 内连

select * from test a left join test1 b on a.id=b.id;

select * from test a right join test1 b on a.name=b.name;

select * from test a inner join test1 b on a.name=b.name;

2、mysql将查询结果插入到另一张表

insert into test select * from test1;

3、二进制日志的保存方式

STATEMNET(基于sql语句)高并发的情况可能会导致数据插入的顺序有误

ROW（基于行）精准匹配，但是恢复数据时，效率低

MIXED 一般情况下用sql，高并发会自动切换到row

4、mysql主从复制的原理

slave I/O yes 获取主服务器的更新

slave sql 执行sql语句，保证主从一致