MySQL主从复制

• 熟悉MySQL数据库常见的主从架构

• 理解MySQL主从架构的实现原理

• 掌握MySQL主从架构的搭建

集群概述

什么是集群？

简单地说，集群 就是指一组（若干个）相互独立的计算机，利用高速通信网络组成的一个较大的 计算机服务系统，每个集群节点（即集群中的每台计算机）都是运行各自服务的独立服务器。这些服务器之间可以彼此通信，协同向用户提供应用程序，系统资源和数据，并以单一系统的模式加以管理。当用户请求集群系统时，集群给用户的感觉就是一个单一独立的服务器，而实际上用户请求的是一组集群服务器。

打开谷歌，百度的页面，看起来好简单，也许你觉得用几分钟就可以制作出相似的网页，而实际上，这个页面的背后是由成千上万台服务器集群协同工作的结果。

若要用一句话描述集群，即一堆服务器合作做同一件事，这些机器可能需要统一协调管理，可以分布在一个机房，也可以分布在全国全球各个地区的多个机房。

为什么要使用集群？

一些国家重要的计算密集型应用（如 天气预报，核试验模拟 等），需要计算机有很强的运算处理能力。以全世界现有的技术，即使是大型机器，其计算能力也是有限的，很难单独完成此任务。因为计算时间可能会相当长，也许几天，甚至几年或更久。因此，对于这类复杂的计算业务，便使用了计算机集群技术，集中几十上百台，甚至成千上万台计算机进行计算。

假如你配一个 LNMP 环境，每次只需要服务 10 个并发请求，那么单台服务器一定会比多个服务器集群要快。

只有当并发或总请求数量超过单台服务器的承受能力时，服务器集群才会体现出优势。

通常一套系统集群架构，只需要几台或数十台服务器主机即可。与动辄价值上百万元的专用超级计算机相比便宜了很多。在达到同样性能需求的条件下，采用计算机集群架构比采用同等运算能力的大型计算机具有更高的性价比。

早期的淘宝，支付宝的数据库等核心系统就是使用上百万元的小型机服务器。后因使用维护成本太高以及扩展设备费用成几何级数翻倍，甚至成为扩展瓶颈，人员维护也十分困难，最终使用 PC 服务器集群替换之，比如，把数据库系统从小机结合 Oracle 数据库迁移到 MySQL 开源数据库结合 PC 服务器上来。不但成本下降了，扩展和维护也更容易了。

当服务负载，压力增长时，针对集群系统进行较简单的扩展即可满足需求，且不会降低服务质量。

通常情况下，硬件设备若想扩展性能，不得不增加新的 CPU 和存储器设备，如果加不上去了，就不得不购买更高性能的服务器，就拿我们现在的服务器来讲，可以增加的设备总是有限的。如果采用集群技术，则只需要将新的单个服务器加入现有集群架构中即可，从访问的客户角度来看，系统服务无论是连续性还是性能上都几乎没有变化，系统在不知不觉中完成了升级，加大了访问能力，轻松地实现了扩展。集群系统中的节点数目可以增长到几千乃至上万个，其伸缩性远超过单台超级计算机。

单一的计算机系统总会面临设备损毁的问题，如 CPU，内存，主板，电源，硬盘等，只要一个部件坏掉，这个计算机系统就可能会宕机，无法正常提供服务。在集群系统中，尽管部分硬件和软件还是会发生故障，但整个系统的服务可以是 7 × 24 7×247×24 小时可用的。

集群架构技术可以使得系统在若干硬件设备故障发生时仍可以继续工作，这样就将系统的停机时间减少到了最小。集群系统在提高系统可靠性的同时，也大大减小了系统故障带来的业务损失，目前几乎 100 % 的互联网网站都要求 7 × 24 小时提供服务。

集群的主要类型

计算机集群架构按功能和结构可以分成以下几类：

• 负载均衡集群，简称 LBC 或者 LB

• 高可用性集群，简称 HAC

• 高性能计算集群，简称 HPC

• 网格计算集群

提示：负载均衡集群 和 高可用性集群 是互联网行业常用的集群架构模式，也是我们要学习的重点。

负载均衡集群

负载均衡集群 为企业提供了更为实用，性价比更高的系统架构解决方案。

负载均衡集群可以把很多客户集中的访问请求负载压力尽可能平均地分摊在计算机集群中处理。

客户访问请求负载通常包括应用程序处理负载和网络流量负载。

这样的系统非常适合使用同一组应用程序为大量用户提供服务的模式，每个节点都可以承担一定的访问请求负载压力，并且可以实现访问请求在各节点之间动态分配，以实现负载均衡。

负载均衡集群运行时，一般是通过一个或多个前端负载均衡器将客户访问请求分发到后端的一组服务器上，从而达到整个系统的高性能和高可用性。

一般高可用性集群和负载均衡集群会使用类似的技术，或同时具有高可用性与负载均衡的特点。

负载均衡集群的作用为：

分摊用户访问请求及数据流量（负载均衡）。

保持业务连续性，即 7 × 24 7×247×24 小时服务（高可用性）。

应用于 Web 及数据库等服务器的业务。

负载均衡集群典型的开源软件包括 LVS，Nginx，Haproxy 等。

高可用性集群

一般是指在集群中任意一个节点失效的情况下，该节点上的所有任务会自动转移到其他正常的节点上。此过程并不影响整个集群的运行。

当集群中的一个节点系统发生故障时，运行者的集群服务会迅速作出反应，将该系统的服务分配到集群中其他正在工作的系统上运行。

考虑到计算机硬件和软件的容错性，高可用性集群的主要目的是使集群的整体服务尽可能可用。

如果高可用性集群中的主节点发生了故障，那么这段时间内将由备份节点代替它。备节点通常是主节点的镜像。

当它代替主节点时，它可以完全接管主节点（包括 IP 地址及其他资源）提供服务，因此，使集群系统环境对于用户来说是一致的，即不会影响用户的访问。

高可用性集群使服务器系统的运行速度和响应速度会尽可能的快。他们经常利用在多台机器上运行的冗余节点和服务器来相互跟踪。

如果某个节点失败，它的替补者将在几秒钟或更短时间内接管它的职责。因此，对于用户而言，集群里的任意一台机器宕机，业务都不会受影响（理论情况下）。

高可用性集群的作用为：

当一台机器宕机时，另外一台机器接管宕机的机器的IP资源和服务资源，提供服务。

常用于不易实现负载均衡的应用，比如负载均衡器，主数据库，主存储对之间。

高可用性集群常用的开源软件包括 Keepalived，Heartbeat 等，其架构图如下图所示：

如何衡量高可用

计算方法：

1年 = 365天 = 8760小时
​
99% = 8760 * 1% = 8760 * 0.01 = 87.6小时 = 3.65天
99.9% = 8760 * 0.1% = 8760 * 0.001 = 8.76小时
99.99% = 8760 * 0.01% = 8760 * 0.0001 = 0.876小时 = 0.876 * 60 = 52.6分钟
99.999% = 8760 * 0.001% = 8760 * 0.00001 = 0.0876小时 = 0.0876 * 60 = 5.26分钟

常用的集群架构

• MySQL Replication

  MySQL Replication一主多从的结构，主要目的是实现数据的多点备份（没有故障自动转移和负载均衡）。相比于单个的mysql，一主多从下的优势如下：

  • 如果让后台读操作连接从数据库，让写操作连接主数据库，能起到读写分离的作用，这个时候多个从数据库可以做负载均衡。

  • 可以在某个从数据库中暂时中断复制进程，来备份数据，从而不影响主数据的对外服务（如果在master上执行backup，需要让master处于readonly状态，这也意味这所有的write请求需要阻塞）。

  就各个集群方案来说，其优势为：

  • 主从复制是mysql自带的，无需借助第三方。

  • 数据被删除，可以从binlog日志中恢复。

  • 配置较为简单方便。

  其劣势为：

  • 从库要从binlog获取数据并重放，这肯定与主库写入数据存在时间延迟，因此从库的数据总是要滞后主库。

  • 对主库与从库之间的网络延迟要求较高，若网络延迟太高，将加重上述的滞后，造成最终数据的不一致。

  • 单一的主节点挂了，将不能对外提供写服务。

• MySQL Cluster

  MySQL Cluster是多主多从结构的

  就各个集群方案来说，其优势为：

  • mysql官方提供的工具，无需第三方插件。

  • 高可用性优秀，99.999%的可用性，可以自动切分数据，能跨节点冗余数据（其数据集并不是存储某个特定的MySQL实例上，而是被分布在多个Data Nodes中，即一个table的数据可能被分散在多个物理节点上，任何数据都会在多个Data Nodes上冗余备份。任何一个数据变更操作，都将在一组Data Nodes上同步，以保证数据的一致性）。

  • 可伸缩性优秀，能自动切分数据，方便数据库的水平拓展。

  • 负载均衡优秀，可同时用于读操作、写操作都都密集的应用，也可以使用SQL和NOSQL接口访问数据。

  • 多个主节点，没有单点故障的问题，节点故障恢复通常小于1秒。

  其劣势为：

  • 架构模式和原理很复杂。

  • 只能使用存储引擎 NDB ，与平常使用的InnoDB 有很多明显的差距。比如在事务（其事务隔离级别只支持Read Committed，即一个事务在提交前，查询不到在事务内所做的修改），外键（虽然最新的NDB 存储引擎已经支持外键，但性能有问题，因为外键所关联的记录可能在别的分片节点），表限制上的不同，可能会导致日常开发出现意外。

  • 作为分布式的数据库系统，各个节点之间存在大量的数据通讯，比如所有访问都是需要经过超过一个节点（至少有一个 SQL Node和一个 NDB Node）才能完成，因此对节点之间的内部互联网络带宽要求高。

  • Data Node数据会被尽量放在内存中，对内存要求大，而且重启的时候，数据节点将数据load到内存需要很长时间。

• MySQL Fabirc

  这是在MySQL Replication的基础上，增加了故障检测与转移，自动数据分片功能。不过依旧是一主多从的结构，MySQL Fabirc只有一个主节点，区别是当该主节点挂了以后，会从从节点中选择一个来当主节点。

  就各个集群方案来说，其优势为：

  • mysql官方提供的工具，无需第三方插件。

  • 数据被删除，可以从binlog日志中恢复。

  • 主节点挂了以后，能够自动从从节点中选择一个来当主节点，不影响持续对外提供写服务。

  其劣势为：

  • 从库要从binlog获取数据并重放，这肯定与主库写入数据存在时间延迟，因此从库的数据总是要滞后主库。

  • 对主库与从库之间的网络延迟要求较高，若网络延迟太高，将加重上述的滞后，造成最终数据的不一致。

  • 2014年5月推出的产品，数据库资历较浅，应用案例不多，网上各种资料相对较少。

  • 事务及查询只支持在同一个分片内，事务中更新的数据不能跨分片，查询语句返回的数据也不能跨分片。

  • 节点故障恢复30秒或更长（采用InnoDB存储引擎的都这样）。

• MHA [Keepalived | HeartBeat | LVS，HAProxy等技术构建高可用集群]

  MHA（Master High Availability）是多主多从结构，这是日本DeNA公司的youshimaton开发，主要提供更多的主节点，但是缺少VIP（虚拟IP），需要配合keepalived等一起使用。

  要搭建MHA，要求一个复制集群中必须最少有三台数据库服务器，一主二从，即一台充当master，一台充当备用master，另外一台充当从库。

  

  就各个集群方案来说，其优势为：

  • 可以进行故障的自动检测和转移

  • 具备自动数据补偿能力，在主库异常崩溃时能够最大程度的保证数据的一致性。

  其劣势为：

  • MHA架构实现读写分离，最佳实践是在应用开发设计时提前规划读写分离事宜，在使用时设置两个连接池，即读连接池与写连接池，也可以选择折中方案即引入SQL Proxy。但无论如何都需要改动代码；

  • 关于读负载均衡可以使用F5、LVS、HAPROXY或者SQL Proxy等工具，只要能实现负载均衡、故障检查及备升级为主后的读写剥离功能即可，建议使用LVS

总结

集群的好处

• 高可用性：故障检测及迁移，多节点备份。

• 可伸缩性：新增数据库节点便利，方便扩容。

• 负载均衡：切换某服务访问某节点，分摊单个节点的数据库压力。

集群要考虑的风险

• 网络分裂：群集还可能由于网络故障而拆分为多个部分，每部分内的节点相互连接，但各部分之间的节点失去连接。

• 脑裂：导致数据库节点彼此独立运行的集群故障称为“脑裂”。这种情况可能导致数据不一致，并且无法修复，例如当两个数据库节点独立更新同一表上的同一行时。

MySQL复制

什么是MySQL复制

• Replication可以实现将数据从一台数据库服务器（master）复制到一台到多台数据库服务器(slave)

• 默认情况下，属于异步复制，所以无需维持长连接

MySQL复制原理

主从复制是通过重放binlog实现主库数据的异步复制。即当主库执行了一条sql命令，那么在从库同样的执行一遍，从而达到主从复制的效果。

在这个过程中，master对数据的写操作记入二进制日志文件中(binlog)，生成一个 log dump 线程，用来给从库的 i/o线程传binlog。

而从库的i/o线程去请求主库的binlog，并将得到的binlog日志写到中继日志（relaylog）中，从库的sql线程，会读取relaylog文件中的日志，并解析成具体操作，通过主从的操作一致，而达到最终数据一致。

当主从同步配置完毕后：

1. slave端的IO线程发送请求给master端的binlogdump线程

2. master端binlogdump线程获取二进制日志信息(文件名和位置信息)发送给slave端的IO线程

3. slave端IO线程获取到的内容依次写到slave端relay log(中继日志)里，并把master端的bin-log文件名和位置记录到master.info里

4. slave端的SQL线程，检测到relaylog中内容更新，就会解析relaylog里更新的内容，并执行这些操作，从而达到和master数据一致

relaylog中继日志

作用：记录从（slave）服务器接收来自主（master)服务器的二进制日志

场景：用于主从复制

master主服务器将自己的二进制日志发送给slave从服务器，slave先保存在自己的中继日志中然后再执行自己本地的relaylog里的sql达到数据库更改和master保持一致。

如何开启relaylog？

默认中继日志没有开启，可以通过修改配置文件完成开启，如下：

vim my.cnf
​
[mysqld]
# 指定二进制日志存放位置及文件名
relay-log=/mysql_3306/data/relaylog

MySQL复制架构

一主多从复制架构

在主库读取请求压力非常大的场景下，可以通过配置一主多从复制架构实现读写分离，把大量的对实时性要求不是特别高的读请求通过负载均衡分部到多个从库上(对于实时性要求很高的读请求可以让从主库去读)，降低主库的读取压力，如下图所示。

在主库出现异常宕机的情况下，可以把一个从库切换为主库继续提供服务。

默认情况下，master接受读写请求，slave只接受读请求以减轻master的压力。

多级复制架构

一主多从的架构能够解决大部分读请求压力特别大的的场景的需求，考虑到MySQL的复制需要主库发送BINLOG日志到从库的I/O线程，主库的I/O压力和网络压力会随着从库的增加而增长(每个从库都会在主库上有一个独立的BINLOG Dump线程来发送事件)，而多级复制架构解决了一主多从场景下的，主库额外的I/O和网络压力。

MySQL的多级复制架构如下图所示。

对比一主多从的架构，多级复制仅仅是在主库Master1复制到从库Slave1、Slave2、Slave3的中间增加了一个二级主库Master2，这样，主库Master1只需要给一个从库Master2发送BINLOG日志即可，减轻了主库Master1的压力。二级主库Master2再发送BINLOG日志给所有的从库Slave1、Slave2和Slave3的I/O线程。

多级复制解决了一主多从场景下，主库的I/O负载和网络压力，当然也有缺点：MySQL的传统复制是异步的，多级复制场景下主库的数据是经历两次复制才到达从库Slave1、Slave2、Slave3的，期间的延迟要比一主多从复制场景下只经历一次复制的还大。

双主复制架构

双主(Dual Master)复制架构适用于DBA做维护时需要主从切换的场景，通过双主复制架构避免了重复搭建从库的麻烦，双主复制架构如下图所示。

主库Master1和Master互为主从，所有Web Client的写请求都访问主库Master1或Master2。加入，DBA需要做日常维护操作，为了避免影响服务，需进行一下操作。

• 首先，在Master1库上停止Slave线程(STOP SLAVE)，避免后续对Master2库的维护操作操作被实时复制到Master1库上对服务造成影响。

• 其次，在Master2库上停止Slave线程(STOP SLAVE)，开始日常维护操作，例如修改varchar字段从长度10增加到200。

• 然后，在Master2库上完成维护操作之后，打开Master2库上的Slave线程(STRART SLAVE),让Master2的数据和Master1库同步，同步完成后，把应用的写操作切换到Master2库上。

• 最后，确认Master1库上没有应用访问后，打开Master1的Slave线程(START SLAVE)即可。

通过双主复制架构能够大大减轻一主多从架构下对主库进行维护带来的额外搭建从库的工作。

当然双主架构还能和主从复制联合起来使用：在Master2库下配置从库Slave1、Slave2等，这样既可通过从库Slave1等来分担读取压力，同时在DBA做维护的同时，避免了重建从库的额外工作，但需要注意从库的复制延迟。MySQL双主多级复制架构如下所示。

MySQL主从搭建

传统复制架构

说明：在配置MySQL主从架构时，必须保证数据库的版本一致

准备工作

克隆两台全新的数据库服务器，MASTER/SLAVE

更改静态IP配置

Master:

# vim /etc/sysconfig/network-scripts/ifcfg-ens33
...
IPADDR=192.168.66.143
...

Slave:

# vim /etc/sysconfig/network-scripts/ifcfg-ens33
...
IPADDR=192.168.66.144
...

Master/Slave:

# systemctl stop NetworkManager
# systemctl disable NetworkManager

设置完成后，重启网络，然后使用MX连接Master与Slave。

关闭防火墙与SELinux

# systemctl stop firewalld
# systemctl disable firewalld
# setenforce 0

配置yum源

时间同步

# ntpdate ntp.aliyun.com

mysql的安装

检查本机是否已经安装mysql

# rpm -qa | grep mysql
​
# rpm -qa | grep mariabd

如已经安装，卸载已安装的mysql，不检查依赖关系

# rpm -e --nodeps 已经安装程序名称

修改 yum 源为阿里云

省略...

安装 mysql 源

CentOS 7 的默认软件仓库中并不包含 MySQL 社区版，在 CentOS 7 中直接使用 yum install -y mysql-community-server 来安装 MySQL 通常是不行的。

首先需要添加 MySQL 官方提供的 Yum 仓库，可以通过下载并安装一个特殊的 RPM 包来实现

下载 mysql 源安装包

mysql80-community-release-el7-8.noarch.rpm 是一个 RPM 包，它用于在 CentOS 7 系统上配置 MySQL 8.0 Community Edition 的官方 Yum 仓库。这个包安装后，系统就能够通过 Yum 命令从官方仓库中安装、更新或卸载 MySQL 8.0 的相关软件包。

简要说明：

mysql80：标识这是 MySQL 8.0 版本的配置包。

community-release：表明这是 MySQL 社区版的发布包，非商业版。

el7：代表这个包适用于基于 Red Hat Enterprise Linux 7 或与其兼容的操作系统，比如 CentOS 7。

8：可能是该配置包的版本号。

noarch：表示这是一个与架构无关的包，也就是说它可以在任意 CPU 架构的 CentOS 7 系统上安装。

安装这个包之后，可以通过 yum repolist 查看已添加的仓库，然后使用 yum install mysql-community-server 安装 MySQL 8.0 Server。

在当前目录下载

# wget http://dev.mysql.com/get/mysql80-community-release-el7-8.noarch.rpm

上面命令执行后，会在当前目录下查看已下载的安装包 mysql80-community-release-el7-8.noarch.rpm

安装mysql源

# yum localinstall -y mysql80-community-release-el7-8.noarch.rpm

检查源是否安装成功

yum repolist enabled | grep mysql

这个命令是用来列出当前系统中所有已启用（enabled）的 Yum 仓库，并从中筛选出包含 “mysql” 关键字的仓库

yum repolist enabled：这条命令会列出所有当前启用状态的 Yum 仓库及其相关信息，包括仓库的名称、状态、URL、是否启用等。

|（管道符号）：用于将前面命令的输出结果作为后面命令的输入。

grep mysql：这是一个文本搜索工具，它会在接收到的输入流中搜索包含字符串 “mysql” 的行。

所以整个命令的目的是为了检查系统中是否有启用了的包含 “mysql” 字样的软件仓库，这通常用于确定 MySQL 的相关仓库是否已经正确添加并启用，以便于后续通过 Yum 安装或管理 MySQL 相关软件包。

安装mysql,上面的 yum 源安装完成后，下面就可以开始正式安装 mysql 了

使用 yum 安装 mysql [yum 安装，可以自动处理软件包之间的依赖关系。]

当你安装一个软件包时，yum 会检查并自动下载、安装所需的任何依赖包，避免了手动寻找和安装依赖的麻烦

yum install -y mysql-community-server

上面面命令是通过 yum 安装 MySQL 服务器，在安装前会自动检查依赖包，并自动完成查找和下载

注意：这一步可能需要等待几分钟才能完成下载和安装

注意：最后一步，提示错误

Failing package is: mysql-community-client-8.0.36-1.el7.x86_64 GPG Keys are configured as: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-mysql-2022, file:///etc/pki/rpm-gpg/RPM-GPG-KEY-mysql

这个是由于由于GPG密钥验证问题引起的

# yum -y install mysql-community-server --nogpgcheck

行完成后，可以检查是否安装完成

rpm -qa |grep mysql

启动mysql

安装完成后，开始启动 MySQL 服务器

# systemctl start mysqld

查看mysql密码

一般都会返回一串无规律的字符串，如果没有返回则为空密码

# cat /var/log/mysqld.log | grep password

修改密码,为了后面登录方便，还需要修改为自己容易记住的密码

ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '123456';

当修改密码的时候会报错：

ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '123456';

ERROR 1819 (HY000): Your password does not satisfy the current policy requirements

出现问题的主要原因是 MySQL 有默认的密码策略：

• 至少包含 1 位大小写

• 至少包含 1 位数字

• 包含 1 个特殊符号

• 必须 8 位及以上

如果不想把密码设置的那么复杂，就需要修改默认的密码策略。

修改配置文件以使修改的密码策略永久生效。

打开MySQL的配置文件，添加下面的内容到文件中：

validate_password.policy=LOW
validate_password.length=6
validate_password.number_count=1
validate_password.special_char_count=1
validate_password.mixed_case_count=1

重启 MySQL 服务以应用更改：

sudo systemctl restart mysql

MySQL主从复制核心思路

主从复制的核心流程：

1. 当master节点接收到一个写请求时，这个写请求可能是增删改操作，此时会把写请求的操作都记录到binlog日志中。

2. master节点会把数据赋值给slave节点，如图中的两个slave节点。这个过程首先得要每个slave节点连接到master节点上，当slave节点连接到master节点上时，master节点会为每一个slave节点分别创建一个binlog dump线程，用于向每个slave节点发送binlog日志。

3. 此时，binlog dump线程会读取master节点上的binlog日志，然后将binlog日志发送给slave节点上的I/O线程。

4. slave几点上的I/O线程接收到binlog日之后，会将binlog日志先写入到本地的relaylog中，relaylog中就保存了master的binlog日志。

5. 最后，slave节点上的SQL线程会读取relaylog中的biinlog日志，将其解析成具体的增删改操作，把这些在master节点上进行过的操作，重新在slave节点上也重做一遍，打到数据还原的效果，这样就可以保证master节点和slave节点的数据一致性了。

MySQL主从复制

主服务器配置

#创建二进制日志存储路径
mkdir /var/log/mysql/mysql.binlog/ 
​
#授权，如果/var/log/mysql 请先给这个目录授权
chown -R mysql:mysql /var/log/mysql/mysql.binlog

添加my.cnf参数

[mysqld]
#二进制日志存储路径
log-bin=/var/log/mysql/mysql.binlog
​
#配置唯一的服务器ID
server-id=1

可选参数

# 0表示读写 (主机)，1表示只读(从机)
read-only=0
​
#设置日志文件保留的时长，单位是秒
binlog_expire_logs_seconds=6000
​
#控制单个二进制日志大小。此参数的最大和默认值是1GB
max_binlog_size=20
​
#设置不要复制的数据库
binlog-ignore-db=test
​
#设置需要复制的数据库,不写参数则默认全部记录，可以填写多个
binlog-do-db=需要复制的主数据库名字
例如:
binlog-do-db=dbtest01
binlog-do-db=dbtest02

检查是否生效

#看看配置的id是否生效
mysql> show variables like 'server_id';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| server_id     | 1     |
+---------------+-------+
1 row in set (0.00 sec)
​
#是否开启二进制日志
mysql> show variables like 'log_bin';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_bin       | ON    |
+---------------+-------+
1 row in set (0.00 sec)
​
#默认是OFF关闭状态，启用后主从将无法通信
mysql> show variables like '%skip_networking%';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| skip_networking | OFF   |
+-----------------+-------+
1 row in set (0.00 sec)

主节点创建主从复制账号

#创建slave用户
mysql> create user 'slave'@'%' identified by '123456';
Query OK, 0 rows affected (0.01 sec)
​
#给slave授权
mysql> grant replication slave on *.* to 'slave'@'%';
Query OK, 0 rows affected (0.00 sec)
​
#使用mysql_native_password插件认证
mysql> alter user 'slave'@'%' identified with mysql_native_password by '123456';
Query OK, 0 rows affected (0.00 sec)
​
#刷新
mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)

查看主节点的二进制日志的名称

其中File和Position两个参数需要在从库配置中使用

mysql> show master status;
+--------------+----------+--------------+------------------+-------------------+
| File         | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+--------------+----------+--------------+------------------+-------------------+
| mysql.000011 |     2388 |              |                  |                   |
+--------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

从节点配置

配置my.cnf文件

[mysqld]
#配置唯一的服务器ID，一般使用IP最后一位
server-id=2
​
#开启中继日志，从主服务器上同步日志文件记录到本地
relay-log=relay-log-bin

把master主服务器的数据目录同步到slave从服务器

推荐使用scp完成

把MASTER服务器中的mysqld停止掉

# service mysqld stop

把/usr/local/mysql/data目录下的auto.cnf文件删除

# rm -rf /usr/local/mysql/data/auto.cnf

每安装一个mysql软件，其data数据目录都会产生一个auto.cnf文件，里面是一个唯一性的编号，相当于我们每个人的身份证号码。

把MASTER服务器中/usr/local/mysql中的data目录拷贝一份到SLAVE从服务器的/usr/local/mysql目录

# rsync -av /usr/local/mysql/data root@192.168.66.1430:/usr/local/mysql/

同步完成后，把主服务器与从服务器中的mysqld启动

# service mysqld start

配置MASTER-SLAVE主从同步

mysql> flush tables with read lock;
mysql> show master status;
​
+---------------+----------+--------------+------------------+-------------------+
| File          | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+---------------+----------+--------------+------------------+-------------------+
| binlog.000003 |     1364 |              |                  |                   |
+---------------+----------+--------------+------------------+-------------------+

在SLAVE从服务器中，使用change master to指定主服务器，并实现数据同步

change master to master_host='192.168.66.143', master_user='slave',master_password='123456', master_port=3306, master_log_file='binlog.000003', master_log_pos=1330;

技巧：主从复制的change master to语句记不住怎么办？答：求帮助，mysql> help change master to;

CHANGE MASTER TO

MASTER_HOST='master2.example.com',

MASTER_USER='replication',

MASTER_PASSWORD='password',

MASTER_PORT=3306,

MASTER_LOG_FILE='master2-bin.001',

MASTER_LOG_POS=4,

MASTER_CONNECT_RETRY=10;

启动slave数据同步

mysql> start slave;
mysql> show slave status\G;

常见问题

从服务器连接出现问题

Error connecting to source 'slave@192.168.66.144:3306'. This was attempt 2/86400, with a delay of 60 seconds between attempts. Message: Authentication plugin 'caching_sha2_password' reported error: Authentication requires secure connection.

ALTER USER 'slave'@'%' IDENTIFIED WITH mysql_native_password BY '123456';

在配置主从时，一般遇到错误，大部分都是change master to语句写错了（80%），解决方案：

mysql> stop slave;
mysql> reset slave;
mysql> change master to 
    -> master_host='192.168.66.143', 
    -> master_user='slave', 
    -> master_password='123', 
    -> master_port=3306, 
    -> master_log_file='binlog.000002', 
    -> master_log_pos=597;
mysql> start slave;

解决方案

1. 检查当前 Slave 状态

在执行任何操作之前，先检查 Slave 的状态以了解当前的复制状态：

SHOW SLAVE STATUS\G;

重点关注以下字段：

• Slave_IO_Running: 表示 IO 线程是否正在运行。

• Slave_SQL_Running: 表示 SQL 线程是否正在运行。

• Last_Error: 如果有错误，这里会显示具体的错误信息。

如果这两个线程都为 Yes，说明 Slave 正常运行；否则需要进一步排查问题。

2. 停止 Slave

在重新启动 Slave 之前，先停止当前的 Slave 进程：

STOP SLAVE;

3. 重置 Slave 配置

如果你需要完全重置 Slave 的状态（例如修复主从同步错误），可以使用以下命令：

RESET SLAVE ALL;

注意：

• RESET SLAVE ALL 会清除所有与主库相关的配置信息（如主库的连接信息、复制位置等）。

• 执行此命令后，你需要重新配置主从复制关系。

4. 配置主从关系（如果需要）

如果执行了 RESET SLAVE ALL 或者 Slave 配置丢失，需要重新配置主从关系：

CHANGE MASTER TO
MASTER_HOST='主库IP地址',
MASTER_USER='复制用户',
MASTER_PASSWORD='复制用户的密码',
MASTER_LOG_FILE='主库二进制日志文件名',
MASTER_LOG_POS=主库二进制日志位置;

其中：

• MASTER_HOST: 主库的 IP 地址或主机名。

• MASTER_USER: 主库上用于复制的用户名。

• MASTER_PASSWORD: 复制用户的密码。

• MASTER_LOG_FILE 和 MASTER_LOG_POS: 通过 SHOW MASTER STATUS; 在主库上获取。

5. 启动 Slave

配置完成后，启动 Slave：

START SLAVE;

6. 再次检查 Slave 状态

启动后，再次检查 Slave 的状态：

SHOW SLAVE STATUS\G;

确保以下字段的状态正常：

• Slave_IO_Running: 应为 Yes。

• Slave_SQL_Running: 应为 Yes。

• Last_Error: 应为空。

5.主MASTER服务器解锁

mysql> unlock tables;
Query OK, 0 rows affected (0.00 sec)

总结：

1. 主从复制必须保证两台数据库实例的server-id不一致

2. 主服务器必须开启二进制日志；从服务器必须开启中继日志

3. 主从复制搭建必须保证初始数据一致

4. 主服务器必须要给从服务器创建一个复制用户，并授予复制权限

5. Master->Slave架构，主写会同步到从；而从写不会同步到主

作业任务

1.搭建一个一主一从集群 （1master,1slave)

2.搭建一个一主多从集群 （1master,2slave)

3.作业使用录屏形式上交