一、主从复制:架构一般是一主两从。
1.主从复制的模式:
mysql默认模式为异步模式:主库在更新完事务之后会立即把结果返回给从服务器,并不关心从库是否接收到以及从库是否处理成功。缺点:网络问题没有同步、防火墙的等因素导致同步失败。优点:快,效率高。
全同步模式:主库在更新完事务之后,立即把结果返回到从库,所有的从库执行完毕之后才能继续下一个同步。优点:安全。缺点:性能受到影响。
半同步模式:介乎于异步和全同步之间,主库更新完事务之后,也是同步到从库,同步完成之后有一个等待时间,等待时间是tcp/ip的往返时间,一般为5毫秒左右。即在一定程度上保证了效率,也在一定程度上保证了数据的完整性。
2.主从复制的特点:只能主复制到从,从不可以复制到主。都是主的情况下,可以相互复制。
3.主从复制的延迟问题及解决方案:
网络延迟
主从硬件设备(CPU主频、内存的读写性能IO、硬件IO)
同步复制而不是异步复制
解决方案:
硬件方面:主库一般来说不需要动的太多,从库的硬件配置要更好。提升随机写的性能。硬盘可以考虑缓存固态的、升级CPU的核数、扩展一下内存。尽量使用物理机(不要用云服务器)
网络层面:主从服务器都配置在一个局域网内,尽量避免跨网段和跨机房
架构方面:做读写分离,把写入控制在主,从库负责读,减轻从库的压力
配置MySQL方面:从配置文件的角度实现性能最大化
4.MySQL安全和性能配置:
追求安全性配置:数据库的存储引擎为innodb
双一配置:innodb_flush_log_at_trx_commit=1
每次事务提交时都会刷新事务日志。以确保持久性,最高级别的数据安全性,但是会影响性能,默认就是1
0就是事务提交时不会立刻刷新,而是每秒刷新一次,可以提高性能,但是发生故障会导致数据丢失。
2表示事务提交时,事务日志不会写入硬盘而是保存在系统缓存,同时也不会进行刷新。有一定的安全性和性能。但是对内存要求比较高。生成中一般都是默认1.
双一配置:sync binlog=1
#1也是默认值,每次提交事务之后,直接把二进制日志刷新到磁盘,以确保日志的持久性,占用性能比较高,但是安全性高
0表示二进制日志写入到缓存,也不会刷新日志,故障发生也会丢失数据,对内存的要求也提高了
自定义数字N:表示每N个事务才执行一次刷新到磁盘。提高性能,但是一旦崩溃数据也会大量丢失,一般设置为10。
5.追求性能化配置:
sync binlog=10:笔试题重点
innodb_flush_log_at_trx_commit=1
logs-slave-updates=0
#从库的更新不会写入二进制日志(不建议)
innodb buffer_pool_size 300M 500G
#控制innodb存储引擎缓冲池的大小,设置的数值越高,可以提高他的innodb的性能,更多的数据和索引都可以缓存在内存中。减少磁盘的访问次数。对系统内存要求比较高。
6.主从复制如何实现:基于mysql的二进制日志,根据主库的二进制文件的标志为,实现主和从的同步;主从服务器之间,服务器的时间要同步。
主从复制的实验:
主:192.168.127.10
从1:192.168.127.80
从2:192.168.127.90
1.关闭主、从服务器的防火墙及安全机制
2.给主、从安装ntp
3.查看主从服务器时间是否同步:
如果时间不同步的情况下命令行输入:ntpdate ntp.sliyun.com使主从时间一致。
4. 配置主服务器:vim /etc/my.cnf
5. 配置完主服务器的文件后重启主的数据库,并进入数据库
6. 创建从服务器的用户名并设置密码,给予从服务器连接主服务器的权限,最后查看主服务器的同步位置点(status),master-bin.000001为二进制同步文件,857为同步位置点。
6.配置两台从服务器vim /etc/my.cnf,从1的配置和从2的配置文件不同的地方就是server-id从1为2,从2为3。
从1服务器
从2服务器
7. 重启两台从服务器的数据库,并进入数据库
8.进入到两台从服务器的数据库内,配置同步
9.实现
二、读写分离:主从架构基础上,主库负责写,从库只负责读。
1.读写分离的方式:靠代码完成,性能好,不需要额外的硬件设备。
中间层代理服务器,基于客户端和主从架构之间有一个代理服务器,代理服务器收到客户端的请求之后通过客户端的sql语句进行判断,读转到从,写转到主。
2.读写分离最常见的客户端代理软件,java代码开发的一个软件:Amoeba
三.读写实验:用Amoeba来实现读写分离
1.关闭防火墙及安全机制
2.代理服务器安装amoebe及jdk环境
vim /etc/profile
三台Mysql设置权限,允许Amoeba的访问
主服务器
回到代理服务器:修改vim amoeba.xml及vim dbServers.xml的配置文件,修改前先备份
30行、31行、115行、117和120取消注释
23行、26行以下几行、46行以下几行、66行以下几行
启动代理服务器 &后台运行
查看java启动没有
客户端服务器:
安装好了之后重启客户端,查看端口是否启动
回到数据库:三个都需要更改
回到客户端连接代理服务器
创建数据库xy105
回到客户端连接代理服务器,并且创建表及插入数据
四、总结+面试题
1、主从同步复制原理
(1)Master节点将数据的改变记录成二进制日志(bin log),当Master上的数据发生改变时,则将其改变写入二进制日志中。
(2)Slave节点会在一定时间间隔内对Master的二进制日志进行探测其是否发生改变,如果发生改变,则开始一个I/O线程请求 Master的二进制事件。
(3)同时Master节点为每个I/O线程启动一个dump线程,用于向其发送二进制事件,并保存至Slave节点本地的中继日志(Relay log)中,Slave节点将启动SQL线程从中继日志中读取二进制日志,在本地重放,即解析成 sql 语句逐一执行,使得其数据和 Master节点的保持一致,最后I/O线程和SQL线程将进入睡眠状态,等待下一次被唤xing
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主从复制
若主从版本不一致,从的版本一定要高于主,保证可以向下兼容
因为若主的版本更新,低版本的从无法兼容的。