主从复制 面试必问
主从复制的原理?
主从复制的模式
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主从复制
若主从版本不一致,从的版本一定要高于主,保证可以向下兼容 因为若主的版本更新,低版本的从无法兼容的。