前言
2022/8/14 8:14
暑假学习ing
推荐
【MySQL数据库教程天花板,mysql安装到mysql高级,强!硬!-哔哩哔哩】
第18章 主从复制
1. 主从复制概述
1.1 如何提升数据库并发能力
在实际工作中常常将Redis
作为缓存与MySQL
配合来使用,当有请求的时候,首先会从缓存中进行查找,如果存在就直接取出。如果不存在再访问数据库,这样就提升了读取的效率
,也减少了对后端数据库的访问压力
。Redis的缓存架构是高并发架构
中非常重要的一环。
此外,一般应用对数据库而言都是“ 读多写少 ”,也就说对数据库读取数据的压力比较大,有一个思路就是采用数据库集群的方案,做主从架构 、进行读写分离 ,这样同样可以提升数据库的并发处理能力。但并不是所有的应用都需要对数据库进行主从架构的设置,毕竟设置架构本身是有成本的。
如果我们的目的在于提升数据库高并发访问的效率,那么首先考虑的是如何 优化SQL和索引 ,这种方式简单有效;其次才是采用 缓存的策略 ,比如使用 Redis将热点数据保存在内存数据库中,提升读取的效率;最后才是对数据库采用主从架构 ,进行读写分离。
按照上面的方式进行优化,使用和维护的成本是由低到高的。
1.2 主从复制的作用
主从同步设计不仅可以提高数据库的吞吐量,还有以下 3 个方面的作用。
第1个作用:读写分离。
我们可以通过主从复制的方式来同步数据
,然后通过读写分离提高数据库并发处理能力
其中一个是Master主库,负责写入数据,我们称之为:写库。
其它都是slave从库,负责读取数据,我们称之为:读库。
当主库进行更新的时候,会自动将数据复制到从库中,而在客户端读取数据的时候,会从从库中进行读取。
面对“读多写少"的需求,采用读写分离的方式,可以实现更高的并发访问。同时还能对从服务器进行负载均衡,让不同的读请求按照策略均匀地分发到不同的从服务器上,让读取更加顺畅。读取顺畅的另一个原因,就是减少了锁表的影响,比如我们让主库负责写,当主库出现写锁的时候,不会影响到从库进行SELECT的读取。
第2个作用就是数据备份
第2个作用就是数据备份。通过主从复制将主库上的数据复制到了从库上,相当于是一种热备份机制
,也就是在主库正常运行的情况下进行的备份,不会影响到服务
第3个作用是具有高可用性
第3个作用是具有高可用性。数据备份实际上是一种冗余的机制,通过这种冗余的方式可以换取数据库的高可用性,也就是当服务器出现故障
或宕机
的情况下,可以切换
到从服务器上,保证服务的正常运行。
关于高可用性的程度,我们可以用一个指标衡量,即正常可用时间/全年时间。比如要达到全年99.999%的时间都可用,就意味着系统在一年中的不可用时间不得超过365*24*60*(1-99.999%)=5.256分钟(含系统崩溃的时间、日常维护操作导致的停机时间等),其他时间都需要保持可用的状态。
实际上,更高的高可用性,意味着需要付出更高的成本代价。在现实中需要结合业务需求和成本来进行选择。
2. 主从复制的原理
Slave
会从 Master
读取 binlog
来进行数据同步。
2.1 原理剖析
三个线程
实际上主从同步的原理就是基于 binlog 进行数据同步的。在主从复制过程中,会基于 3 个线程
来操作,一个主库线程,两个从库线程。
二进制日志转储线程 (Binlog dump thread)是一个主库线程。当从库线程连接的时候, 主库可以将二进制日志发送给从库,当主库读取事件(Event)的时候,会在 Binlog 上 加锁 ,读取完成之后,再将锁释放掉。–>二进制日志转储线程负责将数据发送出去。
从库 I/O 线程 会连接到主库,向主库发送请求更新 Binlog。这时从库的 I/O 线程就可以读取到主库的二进制日志转储线程发送的 Binlog 更新部分,并且拷贝到本地的中继日志 (Relay log)。
从库 SQL 线程 会读取从库中的中继日志,并且执行日志中的事件,将从库中的数据与主库保持同步。
注意:
不是所有版本的MySQL都默认开启服务器的二进制日志。在进行主从同步的时候,需要先检查服务器是否已经开启了二进制日志。
除非特殊指定,默认情况下从服务器会执行所有主服务器中保存的事件。也可以通过配置,使从服务器执行特定的事件。
复制三步骤
步骤1: Master
将写操作记录到二进制日志( binlog )。这些记录叫做二进制日志事件(binary log event)
步骤2: Slave
将 Master
的binary log events拷贝到它的中继日志( relay log
);
步骤3: Slave
重做中继日志中的事件,将改变应用到自己的数据库中。 MySQL复制是异步的且串行化的,而且重启后从接入点
开始复制。
复制的问题
复制的最大问题:延时
2.2 复制的基本原则
- 每个
Slave
只有一个Master
- 每个
Slave
只能有一个唯一的服务器ID - 每个
Master
可以有多个Slave
3. 一主一从架构搭建
一台主机
用于处理所有写请求
,一台从机
负责所有读请求
,架构图如下:
3.1 准备工作
1、准备 2台
CentOS 虚拟机
2、每台虚拟机上需要安装好MySQL (可以是MySQL8.0 )
说明:前面我们讲过如何克隆一台CentOS。大家可以在一台CentOS上安装好MySQL,进而通过克隆的方式复制出1台包含MySQL的虚拟机
第01章 Linux下MySQL的安装与使用【1.MySQL架构篇】【MySQL高级】
注意:克隆的方式需要修改新克隆出来主机的:① MAC地址 ② hostname ③ IP 地址 ④ UUID 。
vim /etc/hostname vim /etc/sysconfig/network-scripts/ifcfg-ens33 systemctl restart network ip addr
TYPE=Ethernet PROXY_METHOD=none BROWSER_ONLY=no #BOOTPROTO=dhcp 改成静态 BOOTPROTO=static DEFROUTE=yes IPV4_FAILURE_FATAL=no IPV6INIT=yes IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_FAILURE_FATAL=no IPV6_ADDR_GEN_MODE=stable-privacy NAME=ens33 UUID=3bd21fb4-a2f2-40f2-bb12-d00fff5b2283 DEVICE=ens33 ONBOOT=yes #IP地址 IPADDR=192.168.253.140 NETMASK=255.255.255.0 #网关 GATEWAY=192.168.253.1 #域名解析器 DNS1=192.168.253.1
此外,克隆的方式生成的虚拟机(包含MySQL Server),则克隆的虚拟机MySQL Server的UUID相同,必须修改,否则在有些场景会报错。比如: show slave status\G ,报如下的错误:
Last_IO_Error: Fatal error: The slave I/O thread stops because master and slave have equal MySQL server UUIDs; these UUIDs must be different for replication to work.
修改MySQL Server 的UUID方式:
vim /var/lib/mysql/auto.cnf systemctl restart mysqld
3.2 主机配置文件
建议mysql版本一致且后台以服务运行,主从所有配置项都配置在 [mysqld]
节点下,且都是小写字母。
具体参数配置如下:
- 必选
#[必须]主服务器唯一ID server-id=1 #[必须]启用二进制日志,指明路径。比如:自己本地的路径/log/mysqlbin log-bin=atguigu-bin
- 可选
#[可选] 0(默认)表示读写(主机),1表示只读(从机) read-only=0 #设置日志文件保留的时长,单位是秒 binlog_expire_logs_seconds=6000 #控制单个二进制日志大小。此参数的最大和默认值是1GB max_binlog_size=200M #[可选]设置不要复制的数据库 binlog-ignore-db=test #[可选]设置需要复制的数据库,默认全部记录。比如:binlog-do-db=atguigu_master_slave binlog-do-db=需要复制的主数据库名字 #[可选]设置binlog格式 binlog_format=STATEMENT
重启后台mysql服务,使配置生效。
演示
vim /etc/my.cng ··· [mysqld] #[必须]主服务器唯一ID server-id=1 #[必须]启用二进制日志,指明路径。比如:自己本地的路径/log/mysqlbin log-bin=atguigu-bin binlog-do-db=atguigu_master_slave binlog_format=STATEMENT ··· systemctl restart mysqld
注意:
先搭建完主从复制,再创建数据库。
MySQL主从复制起始时,从机不继承主机数据。