MySQL主从搭建流程,主从三问,什么是?为什么?实现原理?

本文详细介绍了MySQL主从复制的搭建过程,包括主库和从库的配置,并探讨了为何使用主从复制以实现读写分离,减轻数据库压力。此外,还解析了主从复制的实现原理,以及可能出现的数据一致性问题及解决方案。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

目录

主库搭建

从库搭建

什么是MySQL主从?

为什么要使用MySQL主从?

MySQL主从的实现原理

​编辑 MySQL主从数据一致性问题


我们先来最重要的,代码部分,先来明白主从怎么搭建。

首先我们需要准备两台服务器,docker,虚拟机都是可以的。但是使用虚拟机可能会出现,关机再开启后从库连接不上主库的问题。小编这里使用了自己的线上服务器来搭建。

主库搭建

进入到mysql的配置文件,在 [mysqld] 下面加入下面这串代码,然后重载我们的mysql配置让其生效(/etc/my.cnf)

#主服务器唯一ID
server-id=1
#启用二进制日志
log-bin=mysql-bin
#设置logbin格式
binlog_format=STATEMENT
# 设置不要复制的数据库,可以设置多个
binlog-ignore-db=mysql 
#设置需要同步的数据库(未创建的数据库)
binlog-do-db=table1 
#binlog-do-db设置后,可以不设置binlog-ignore-db
#重载mysql配置
service mysqld restart

然后我们进入mysql,为我们的从服务器创建远程连接,完成后以防万一,我们可以查看一下是否创建OK

#创建远程连接账号密码
GRANT REPLICATION SLAVE ON *.* TO 'slave'@'%' IDENTIFIED BY '111222';
#刷新mysql系统权限相关表
flush privileges;
#查看是否建立完成
select user from mysql.user where user='slave';

这一切都完成后,我们主库的配置就完成了,我们查看一下master的状态,这里面的内容,我们在从库连接时需要使用

  • File:binlog日志的名字
  • Position :接入点 
  • Binlog_Do_DB :需要复制的数据库
  • Binlog_Ignore_DB :不需要复制的数据库
  • Executed_Gtid_Set:写入binlog日志的事务产生的Gtid的集合
show master status;

从库搭建

同样的,我们打开mysql的配置文件,在 [mysqld] 下添加下面的代码 ,重载生效(/etc/my.cnf)

#主服务器唯一ID
server-id=2
#启用中继日志
relay-log=mysql-relay
#启用二进制日志
log-bin=mysql-bin
#重载mysql配置
service mysqld restart

然后我们进入到mysql中,连接我们的主库服务器,返回OK成功,如果从库曾配置过主从,我们需要先重启服务再进行配置

#停止从服务
stop slave;
#重置master
reset master;
CHANGE MASTER TO MASTER_HOST='主服务器IP地址',
MASTER_USER='远程连接账号',
MASTER_PASSWORD='远程连接密码',
MASTER_LOG_FILE='主库binlog日志名称',
MASTER_LOG_POS=主库接入点;

然后我们启动从服务,让主从生效,然后我们查看一下slave状态,\G的目的是为了让内容格式化输出,因为内容较多,格式化输出会更清晰的看到

#启动从服务
start slave;
#查看slave状态
show slave status\G

 我们可以看到,IO线程和SQL线程都是YES状态,表示主从搭建成功,接下来就可以尝试再主库进行写的操作然后在从库查找啦。

这里呢,小编总结了一下搭建过程中的报错,mysql的主从整体还是比较简单的,容易错的点只有两个:

  • 1. 远程连接不上主服务器,这里首先确保账号密码的正确,如果正确,一般就是主服务器的mysql端口号3306没有开启,线上服务器可以去服务器页面防火墙里配置规则,虚拟机或者别的可以手动打开
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 3306 -j ACCEPT
  •  2. 依然是连接不上的问题,如果端口号也开启了,就可以去主库里看一下主库的host权限是否允许远程连接,如果查看的权限列表中没有%,那就证明无法通过远程连接到这个库。可以执行修改权限,然后重载,这样就可以连接了
use mysql;
#查看host权限
select host from user where User='root';
#修改权限
update user set host='%' where Host='localhost';
#重载
flush privileges;

 解决完这些,基本上就可以连接上主库了,如果有别的报错,可以留言给我,也可以复制报错内容去搜索。

到这里呢,我们的主从就搭建好了!但是也只是搭建好了,我们在做每一个功能的时候呢,都应该明白为什么要使用,使用了有什么好处等等,这样我们的思路才会清晰,才能有更深入的理解。所以,我们接下来就来讲解一下

什么是MySQL主从?

mysql主从就是说,使用多台mysql服务器,实现对于数据的读写分离,分担单台mysql服务器的压力,使用一台服务器作为mysql主库,在这台服务器上实现对数据的写的操作,然后使用一台或多台服务器作为mysql从库,来实现对数据的读的操作

为什么要使用MySQL主从?

我们都知道mysql是一个关系型数据库,用来存储我们的数据,那么就会有对于某一张表的curd,当我们的访问量和操作量 都比较大时,我们就有可能出现读写冲突,或者压力过大等问题。所以我们采用主从的方式来将数据的读写操作分离,一方面防止读写冲突,另一方面也能减轻单台mysql的压力,提高系统的扩展性和可用性。

MySQL主从的实现原理

  • 当我们在mysql主库上进行写的操作时,主库会将操作进行备份,存储到二进制日志binlog中
  • 由从库的I/O线程来读取binlog日志的内容,将主库中写的操作读取到从库并转存到从库的中继日志relaylog中
  • 从库通过SQL线程将relaylog中的内容进行读取并写入库中,实现主从数据同步

 MySQL主从数据一致性问题

首先,我们先来了解为什么会出现一致性问题,我总结了以下几点

  • 主从服务器的性能差距过大,一般主库的性能都是没有问题的,也就是说从库的性能太差,读取日志时发生问题而导致数据不一致
  • 从库数量不合理,有的主从搭建好后从库数量过少,在大量数据的写入时,从库的同步压力过大导致从库出现问题,亦或者说从库数量过多,在同步数据时也会造成一定量的数据不一致,一般3 ~ 5台从库即可
  • 大事务的执行,一条事务执行的时间过长,导致其他事务阻塞,binlog日志写入不一致等问题发生
  • mysql自身版本过低,低版本的mysql不支持并发,而在并发场景时就有可能造成数据不一致问题
  • 还有就是网络问题,一般来说也不会发生

具体的解决办法呢有三种

  • 保证主从库的性能一致或者说差距较小
  • 在主库中存在一个线程,是专门用来维持主从库的长链接的,这个可以用来保证数据一致性,所以要保证主库的性能不能过低
  • 另外一个是binlog日志的格式,binlog日志存在三种格式,这个可以在sql配置文件中配置,上面搭建主从中有提到
    • 第一种是statement,这是binlog的默认格式,它是将原生的sql语句存储进来,然后提供给从库,由于他直接记录了sql语句,自然也会提高很多性能,但是当我们数据库存在多条索引时,我们可能无法保证主从库对于同一条语句执行同一个索引,那么在同步数据时就有可能造成数据不一致
    • 第二种是row,row是记录了两个事件(event):table_map和delete_rows,table_map是记录要操作的表,delete_rows是记录行为,记录每一行要修改的细节,这样就基本不会出现数据不一致的问题,但当修改或删除的数据量特别大时,row格式的binlog会很占空间,造成内存上的消耗
    • 第三种是mixed,mixed相当于是前两者的折中版,他会对每一条记录的sql进行判断,如果是一般的sql,就使用statement格式的binlog,如果觉得statement处理不好,便会使用row,其实它本身并没有什么格式,只是在每次记录前进行判断,区别使用上面两种格式

其实在新版本的mysql中对row格式进行了优化,与其说是优化,更像是将mixed格式赋予进了row中,新版本的row格式会判断sql语句,如果涉及到整表改动或者大量数据的改动时,会使用statement来进行处理,提高效率,一般的update,delete依然使用row来记录变更细节。

这一版关于mysql主从的就到此结束了,希望每一个程序员都不只是敲代码。

 

<think>好的,用户之前了对象的序列化和反序列化,现在又转向了MySQL主从复制。我需要先确保自己准确理解主从复制的概念,然后考虑用户可能的背景和需求。 首先,用户可能是开发人员或者刚接触数据库的学习者,他们可能正在搭建高可用性系统,或者需要优化数据库性能。主从复制是MySQL中常用的技术,用户可能想了解其基本原理、应用场景以及如何配置。 接下来,我需要回忆主从复制的工作原理。主库将数据变更记录到二进制日志(binlog),从库通过IO线程读取这些日志并入自己的中继日志,再由SQL线程重放这些日志来同步数据。这个过程需要明确步骤,比如主库的配置、从库的连接和启动复制。 用户可能关心主从复制的优点,比如读分离、负载均衡、数据备份和高可用性。需要分点说明,每个优点具体应用在什么场景,比如电商系统用主库处理操作,从库处理读操作,提升性能。 另外,还要考虑主从复制的架构类型,比如一主一从、一主多从、链式复制等,用户可能想知道不同架构的适用情况。同时,延迟题也是常见痛点,需要解释延迟的原因和解决方法,比如并行复制或者半同步复制。 安全性和配置注意事项也是关键点,比如网络稳定性、主从版本一致性、权限控制等。用户可能在配置过程中遇到题,需要提醒他们注意这些细节。 最后,总结主从复制的核心作用,帮助用户理解其在现代应用中的重要性。确保回答结构清晰,逐步展开,覆盖基本概念、工作原理、优点、架构、注意事项和典型场景,让用户有一个全面的认识。</think>--- #### MySQL 主从复制(Master-Slave Replication) ##### 一、基本概念 1. **定义** MySQL 主从复制是一种**数据同步机制**,通过将主数据库(Master)的数据变更**自动复制**到一个或多个从数据库(Slave),实现数据的分布式存储和读分离。 2. **核心角色** - **主库(Master)**:负责处理操作(INSERT/UPDATE/DELETE),并记录数据变更到二进制日志(Binary Log)。 - **从库(Slave)**:接收主库的变更日志,重放这些操作以保持数据一致,默认仅处理读操作(SELECT)。 --- ##### 二、工作原理 1. **主库记录二进制日志(Binlog)** - 主库将数据变更(如 SQL 语句或行级数据变化)入二进制日志。 - 例如:用户下单时,主库记录一条 `INSERT INTO orders ...` 的日志。 2. **从库拉取日志并同步** - **步骤 1**:从库通过 **IO 线程** 连接主库,请求并接收二进制日志。 - **步骤 2**:从库将日志入本地的**中继日志(Relay Log)**。 - **步骤 3**:从库的 **SQL 线程** 读取中继日志,重放 SQL 语句,更新本地数据。 3. **异步 vs 半同步** - **默认异步复制**:主库提交事务后立即响应客户端,不等待从库确认(高性能,但可能丢失数据)。 - **半同步复制**:主库等待至少一个从库确认收到日志后再响应客户端(数据一致性更强)。 --- ##### 、核心作用 1. **读分离** - 主库处理操作,从库处理读操作,分散负载。 - 例如:电商系统中,用户下单()由主库处理,查询订单(读)由从库处理。 2. **数据备份与容灾** - 从库可作为主库的**实时备份**,主库故障时可快速切换为从库提供服务。 - 例如:主库宕机时,从库升级为新主库,避免服务中断。 3. **高可用性与扩展性** - 通过多从库横向扩展读能力,支撑高并发查询。 - 例如:社交媒体平台的用户动态查询,分散到多个从库执行。 4. **数据分析与离线计算** - 从库可专门用于运行大数据分析任务,避免影响主库性能。 - 例如:在从库上执行每日销售报表生成。 --- ##### 四、配置步骤(简版) 1. **主库配置** - 修改 `my.cnf`,开启二进制日志并设置唯一 `server-id`: ```ini [mysqld] server-id=1 log-bin=mysql-bin ``` 2. **创建复制账号** - 主库创建用于从库连接的账号: ```sql CREATE USER 'repl'@'%' IDENTIFIED BY 'password'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%'; ``` 3. **从库配置** - 修改 `my.cnf`,设置唯一 `server-id`: ```ini [mysqld] server-id=2 ``` 4. **启动复制** - 从库执行命令指向主库: ```sql CHANGE MASTER TO MASTER_HOST='主库IP', MASTER_USER='repl', MASTER_PASSWORD='password', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=154; START SLAVE; ``` 5. **验证状态** - 检查从库复制状态: ```sql SHOW SLAVE STATUS\G ``` - 确认 `Slave_IO_Running` 和 `Slave_SQL_Running` 均为 `Yes`。 --- ##### 五、常见题与优化 1. **主从延迟** - **原因**:从库 SQL 线程重放速度慢、网络延迟、主库入压力过大。 - **解决**: - 使用并行复制(MySQL 5.7+ 支持多线程复制)。 - 减少大事务,拆分批量操作。 2. **数据一致性校验** - 使用工具如 `pt-table-checksum` 检查主从数据差异。 3. **主库单点故障** - 部署**双主架构**或结合 **MHA(Master High Availability)** 实现自动故障转移。 --- ##### 六、典型应用场景 1. **Web 应用读分离** - 主库处理用户注册、订单提交,从库处理商品浏览、搜索。 2. **异地多活** - 跨地域部署从库,用户就近访(如北京主库,上海从库)。 3. **灰度发布** - 在从库测试新版本 SQL 语句或数据库配置,验证无误后同步到主库。 --- **总结**:MySQL 主从复制通过**日志同步**实现数据冗余与读分离,是构建高可用、高性能数据库架构的基石。需根据业务需求选择复制策略(异步/半同步),并持续监控延迟与一致性。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值