mysql的主从复制和读写分离

主从复制 面试必问

主从复制的原理?

主从复制的模式

1、MySQL的默认模式:

异步模式:主库在更新完事务之后会立即把结果返回给从服务器,但是并不关心从库是否接收到,以及从库是否处理成功。

网络问题可能没有同步,或者其他因素的影响导致同步失败。

效率高

2、全同步模式:

主库在更新完事务之后也是立即把结果返回给从库,所有的从库执行完毕之后才能执行下一个同步,安全,性能受到影响。

3、半同步模式:

介乎于异步和全同步之间,主库更新完事务之后,也是同步到从库。同步完成之后有一个等待时间。

等待时间是一个tcp/ip的往返时间。在5毫秒左右。

即在一定程度上保证了效率也在一定程度上保证了数据的完整性。

特点:

只有在主上创建的库才能复制给从,从不能复制给主。

主从复制的延迟怎么解决:

1、网络问题,防火墙原因

2、硬件设备问题,cpu、内存、磁盘出了问题

3、配置文件问题,配置文件写错了

在配置文件当中进行设置的方式提高数据的安全性。

数据库的存储引擎要是innodb

双一设置:

innodb_flush_log_at_trx_commit=1

每次提交都会刷新事务日志,确保事务的持久性。但是会影响性能。

sync_binlog=1

每次提交事务都会把二进制日志的内容保存到磁盘,确保日志的持久性。提高了安全性。

性能化设置:

sync_binlog=10 / N

最多提交几次事务会进行磁盘刷新。10条之后日志内容保存到磁盘

innodb_flush_log_at_trx_commit=2

每次更新都保存在内存当中,不进行刷新。

innodb_buffer_pool_size=60m

控制innodb缓冲池的大小,增大可以提高数据库的性能,但是占用的是系统内存,配置的时候要注意合理化时间。

主从复制如何实现

实现基于mysql的二进制日志,根据主库的二进制文件的标志位,实现主和从的同步。

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

结构:

三台服务器

192.168.65.11 MySQL8.0 主

192.168.65.12 MySQL8.0 从

192.168.65.13 MySQL8.0 从

log-slave-updates=true

允许从主库复制数据时可以写入从库自己的二进制日志里。

mysql> CREATE USER 'myslave'@'192.168.65.%' IDENTIFIED WITH mysql_native_password BY '123456';
Query OK, 0 rows affected (0.02 sec)
​
mysql> GRANT REPLICATION SLAVE ON *.* TO 'myslave'@'192.168.65.%';
Query OK, 0 rows affected (0.00 sec)
​
mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.01 sec)
relay-log=relay-log-bin
从服务器上获取二进制日志的开头,开启从库的二进制日志
relay-log-index=slave-relay-bin.index
二进制日志的索引文件名称
relay_log_recovery=1
配置从服务器在启动时是否执行二进制日志的恢复操作
Slave_l0_Running: Yes
从库和主机的读写通信是否正常
Slave SQL Running: Yes
slave mysgl进程状态是否正常,
CHANGE master to master_host='192.168.65.11',master_user='myslave',master_password='123456',master_log_file='master-bin.000001',master_log_pos=855;
CREATE USER 'myslave'@'192.168.65.%' IDENTIFIED WITH mysql_native_password BY '123456';
log-bin=master-bin
binlog_format=MIXED
log-slave-updates=true
relay-log=relay-log-bin
relay-log-index=slave-relay-bin.index
relay_log_recovery=1
​
relay-log=relay-log-bin
relay-log-index=slave-relay-bin.index
relay_log_recovery=1
​
CREATE USER 'myslave'@'192.168.65.%' IDENTIFIED WITH mysql_native_password BY '123456';
grant replication slave on *.* to 'myslave'@'192.168.65.%';
flush privileges;

读写分离

读写分离的架构:

在整个主从架构中,主库只负责写,从库只负责读。

读写分离的方式:

1、代码 开发人员纯靠代码完成,涉及到数据库的二次开发,性能好,不需要额外的硬件设备。

2、中间层代理 代理服务器。在客户端和主从架构之间有一个代理服务器。代理服务器收到客户端的请求之后,通过客户端desql语句来进行判断,读转到从,写转到主

Amoeba:读写分离最常见的客户端代理软件。java代码开发的一个软件。

192.168.65.11 MySQL8.0 主

192.168.65.12 MySQL8.0 从

192.168.65.13 MySQL8.0 从

192.168.65.41

192.168.65.42

1、主从同步复制原理

2、读写分离你们使用什么方式? amoeba 代理 mycat 代码 sql_proxy

通过amoeba代理服务器,实现只在主服务器上写,只在从服务器上读; 主数据库处理事务性查询,从数据库处理select 查询; 数据库复制被用来把事务查询导致的变更同步的集群中的从数据库

3、如何查看主从同步状态是否成功

在从服务器上内输入 show slave status\G 查看主从信息查看里面有IO线程的状态信息,还有master服务器的IP地址、端口事务开始号。 当 Slave_IO_Running和Slave_SQL_Running都是YES时 ,表示主从同步状态成功

4、如果I/O不是yes呢,你如何排查?

首先排查网络问题,使用ping 命令查看从服务器是否能与主服务器通信 再查看防火墙和核心防护是否关闭(增强功能) 接着查看从服务slave是否开启 两个从服务器的server-id 是否相同导致只能连接一台 master_log_file master_log_pos的值跟master值是否一致

5、show slave status能看到哪些信息(比较重要)

IO线程的状态信息 master服务器的IP地址、端口、事务开始的位置 最近一次的错误信息和错误位置 最近一次的I/O报错信息和ID 最近一次的SQL报错信息和id

6、主从复制慢(延迟)会有哪些可能?怎么解决?

主服务器的负载过大,被多个睡眠或 僵尸线程占用 导致系统负载过大,从库硬件比主库差,导致复制延迟 主从复制单线程,如果主库写作并发太大,来不及传送到从库,就会到导致延迟 慢sql语句过多 网络延迟

mysql主从复制

若主从版本不一致,从的版本一定要高于主,保证可以向下兼容 因为若主的版本更新,低版本的从无法兼容的。

  • 29
    点赞
  • 30
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值