MySQL 5.6主从复制及经典报错的处理过程

本文详细介绍了MySQL5.6环境下主从复制的搭建流程及常见故障处理,包括单向、双向、链式级联复制原理,通过具体步骤演示如何在线搭建主从环境,以及如何使用percona-toolkit等工具解决主从复制中常见的1062、1032、1593、1236错误。

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

.MySQL5.6在线搭建主从复制实验与主从经典故障处理

1.MySQL主从复制概述

mysql支持单向,双向,链式级联,异步复制,半同步复

制(mysql5.5版本之后),复制过程中,

一台服务器当主master,而一个或者多个服务器slave.

复制可以是单向:M-->S,也可以双向M<-->M

如设置了链式级联复制,那么从服务器本身除了

充当slave之外,还是其下面从服务器的主服务器

结构如是:M-->S1-->S2-->S3的复制形式

2.主从复制原理

复制是mysql数据库提供的一种高可用、高性能的解决方案,一般用来建立大型的应用。复制的工作原理分为三个步骤:

1.主服务器把数据更新记录到二进制日志中.

2.从服务器把主服务器的二进制日志拷贝到自己的中继日志(relay log)中.这个过程是通过IO Thread完成的。

3.从服务器重做中继日志中的时间,把更新应用到自己的数据库上,通过从库的SQL线程来达到数据的一致性。

工作原理的剖析:就是完全备份和二进制日志备份的还原。二进制日志的还原操作基本上是实时进行。但不是完全的实时,而是异步的实时。其中存在主从服务器之间的执行延时。因为sql线程为单线程,是一条一条地执行。如果主服务器的压力很大,则这个延时可能会更长。

主服务器的一个工作线程:

I/O线程

作用:接收到从库发来的请求后,负责给slave服务器发送二进制日志

从服务器的两个工作线程:

I/O线程

作用:负责读取主服务器的二进制日志,并将其保存到自己的中继日志文件中。

SQL线程

作用:来复制执行中继日志。

主从复制原理图:

 

3、在线搭建主从环境

(1)在主库初始化数据,通过mysqldump把数据导出来

/usr/local/mysql/bin/mysqldump --single-transaction -uroot -p123123 -A --master-data=2 > all.sql

 

vi all.sql    查看

 

(2)把数据拷贝到从库

scp -r /data/mysql/all.sql root@bigdata14:/data/mysql/all.sql

 

(3)在从库执行恢复操作

mysql -uroot -p123123 < /data/mysql/all.sql

 

(4)在主库授权,指定从库

grant replication slave on *.* to 'repl'@'192.168.100.14' identified by '123456';

flush privileges;

 

 

(5)在从库搭建主从复制

change master to master_host='192.168.100.13',master_user='repl',

master_password='123456',master_log_file='mysql-bin.00001',master_log_pos=120;

 

(6)在从库开启主从开关

start slave;

 

(7)查看主从的状态show slave status\G;  当IO线程和 SQL线程都为OK时,表明主从搭建理论上成功。

(8)验证主从搭建是否成功?在主库新插入一条数据,看是否能够同步到从库?

主库

   select * from mytest.t1;

 

从库

 select * from mytest.t1;

 

证明备份成功,导入数据成功

在主库新插入数字id=6,name=ff

 insert into t1 (id,name) values(6,'ff');

在从库查看t1表

select * from mytest.t1;

 

发现主库和从库数据一样,证明了主从搭建成功。

注意:在搭建完单向主从时,只有在从库中才有master.info的信息

  vi /data/mysql/master.info

 

4、主从搭建的经典错误

主库:

CREATE TABLE `t`( `a` int(11) NOT NULL auto_increment, `b` varchar(20) DEFAULT NULL, PRIMARY KEY (`a`), KEY `b` (`b`) ) ENGINE=InnoDB auto_increment=1 DEFAULT CHARSET=utf8;

 

insert into t (b) values ('aa');

insert into t (b) values ('bb');

insert into t (b) values ('cc');

select * from t;

 

首先在从库中进行查看t表

 

发现主从数据一致

在从库进行写数据操作

insert into  t (b) values (‘dd’);

select * from t;

 

主库:

insert into  t (b) values (‘dd’);

select * from t;

 

在主库插入刚才在从库插入的语句,因为这是单向同步的,只能从主库同步到从库。因此主库少了一条数据,所以需要在主库进行插入。

查看从库的状态show slave status\G;

 

(1)主从的第一个经典的错误1062  主键冲突

用percona-toolkit-2.2.20 来修复,这个工具被称为业界的瑞士军刀。

安装percona-toolkit-2.2.20工具之前,需要安装他的依赖

yum -y install perl-Digest-MD5

yum install -y perl-DBI

yum -y install perl-DBD-MySQL

 

cd  /root/training/percona-toolkit-2.2.20/bin

./pt-slave-restart -uroot -p123123

 

它是实时监控的,下回还会报错。

然后查看从库的状态:show slave status\G; 主从的状态又OK了。

 

(2)主从第二个经典错误1032

在从库删一条数据,

 

在主库更新一条数据

 

在从库查询主从的状态:show slave status\G;

 

解决办法:

在主库中查看binlog日志mysql-bin.000004

/usr/local/mysql/bin/mysqlbinlog --no-defaults -v -v --base64-output=decode-

rows /data/mysql/mysql-bin.000004 > /data/mysql/1.log

 

 

 

 

vi 1.log

 

从binlog日志中可以看出我们做了两个操作,所以在从库中插入与主库一致的数据的数据

在从库:

insert into t(a,b) values (4,’ddd’);

 

再用pt工具集

 

查看主从的状态:

 

 

 

在主库继续更新操作

update t set b=’dddd’ where a=4;

 

在从库查看更新的情况

 

发现数据可以同步过来了

(3)主从第三个经典错误1593

把从库的server_id修改成与主库的一样,在配置文件中进行修改,然后重新启动数据库。

查看主从的状态,show slave status\G;

 

解决办法,在配置文件中把server_id修改为不一样的就行了。

(4)主从第四个经典错误1236

 

这个问题产生的原因为:从数据库读取的 mysqlbin 文件的pos 位置与主数据库不一致所产生的。

  1. 停止从数据库的同步

  stop slave;

    2.在主数据库上查看当前的日志  pos

show master status;

 

3.根据上述的位置,在从数据库上执行

  change master to master_log_file='mysql-bin.000003',master_log_pos= 4141;

 

4.开启从库,并查看状态

      start slave;

      show slave status\G;

 

<think>我们正在讨论MySQL主从复制原理,特别是通信机制和数据同步过程。根据引用[2]和[3],我们可以知道:引用[2]提到:从节点执行start slave命令后,会创建一个I/O线程连接主节点,请求主节点的Binlog。主节点有一个logdump线程,将更新发送给从节点。从节点将更新保存到本地的中继日志(relay log)中,然后由SQL线程执行这些更新。引用[3]提到:MySQL主从复制是借助binlog日志文件里面的SQL命令实现的。主节点执行SQL命令,从节点也会执行同样的SQL命令,从而达到数据同步。因此,我们可以将MySQL主从复制的工作原理分为以下几个步骤:1.主节点将数据更改记录到二进制日志(binlog)中。2.从节点通过I/O线程连接主节点,请求binlog。3.主节点的log dump线程读取binlog事件并发送给从节点。4.从节点的I/O线程将接收到的binlog事件写入中继日志(relay log)。5.从节点的SQL线程读取中继日志中的事件,并在从节点上执行这些事件,从而同步数据。关于通信机制:主节点和从节点之间通过TCP/IP协议进行通信。从节点主动连接主节点,主节点在指定的端口上监听从节点的连接请求。关于从节点如何得知需要同步的数据:从节点会记录已经同步的binlog位置(通过masterlogfile和master logposition)。当连接主节点时,从节点会从这个位置开始请求新的binlog事件。如果从节点第一次连接,则可能需要进行全量同步(即主节点生成一个快照并发送给从节点)。但是,引用[1]虽然提到的是Redis的主从复制,但其中关于全量同步和增量同步的概念与MySQL类似。在MySQL中,全量同步(即从节点第一次连接或者落后太多时)会通过主节点生成一个数据快照(例如使用mysqldump)并传输给从节点,然后从节点再通过增量同步(即应用binlog)来保持更新。因此,我们可以这样描述:数据同步过程:1.全量同步(当从节点第一次连接或落后太多时):-主节点生成一个数据快照(使用mysqldump或类似工具)。-将快照文件传输给从节点。-从节点导入快照数据。-然后从节点从快照对应的binlog位置开始进行增量同步。2.增量同步(正常情况):-主节点将新的数据更改写入binlog。-从节点的I/O线程读取binlog事件并写入中继日志。-从节点的SQL线程执行中继日志中的事件。注意:在MySQL中,全量同步并不是自动触发的,通常需要手动设置(例如使用mysqldump导出数据并导入到从节点),或者通过设置复制参数(如`gtid_mode`和`gtid_purged`)来实现自动的全量同步。但在实际复制过程中,如果从节点请求的binlog位置在主节点上已经被清除(即binlog文件被删除了),那么从节点就会报错,需要手动进行全量同步。现在,我们根据以上理解来组织回答。</think>### MySQL主从复制工作原理详解 #### 一、核心通信机制 1. **线程架构** - **主节点线程**: `Binlog Dump线程`(1个/从节点)负责发送binlog事件[^2] $$ \text{通信模型} = \text{主节点Binlog Dump} \xrightarrow{\text{TCP/IP}} \text{从节点I/O线程} $$ - **从节点线程**: - `I/O线程`:连接主节点请求binlog[^2] - `SQL线程`:执行中继日志中的事件[^2] 2. **连接建立过程** ```mermaid sequenceDiagram 从节点->>主节点: 1. 发起连接请求(3306端口) 主节点-->>从节点: 2. 创建Binlog Dump线程 从节点->>主节点: 3. 发送同步位置(文件名+偏移量) 主节点-->>从节点: 4. 开始推送binlog事件 ``` #### 二、数据同步过程 1. **全量同步(首次连接)** - 主节点生成数据快照(mysqldump或物理备份) - 通过`RBR`(Row-Based Replication)格式传输全量数据[^3] - 从节点导入数据后记录`master_log_file`和`master_log_pos` 2. **增量同步(持续复制)** | 阶段 | 主节点操作 | 从节点操作 | |------|-----------|-----------| | 写入 | 事务提交后写入binlog | - | | 传输 | Binlog Dump线程推送事件 | I/O线程接收并写入relay log | | 执行 | - | SQL线程按顺序执行relay log | | 反馈 | - | 更新`relay_log_info`文件[^2] 3. **位置追踪机制** - 从节点通过`SHOW SLAVE STATUS`记录: ```sql Relay_Master_Log_File: master-bin.000002 Exec_Master_Log_Pos: 107 ``` - 主节点通过`SHOW MASTER STATUS`提供: ```sql File: master-bin.000002 Position: 107 ``` #### 三、关键同步技术 1. **Binlog格式** - `STATEMENT`:记录SQL语句(易受函数影响) - `ROW`:记录行变化(数据量大但安全)[^3] - `MIXED`:智能切换两种模式 2. **GTID机制(MySQL 5.6+)** ```sql -- 启用GTID SET GLOBAL gtid_mode=ON; ``` - 全局唯一事务ID:`server_uuid:transaction_id` - 从节点通过`Retrieved_Gtid_Set`跟踪已接收事务 3. **并行复制** - `slave_parallel_workers`:多SQL线程并行执行 - 基于逻辑时钟的冲突检测算法 #### 四、故障恢复机制 1. **断点续传** - 网络中断后从`master_log_pos`位置恢复 - 通过`CHANGE MASTER TO`指定位置: ```sql CHANGE MASTER TO MASTER_LOG_FILE='master-bin.000002', MASTER_LOG_POS=107; ``` 2. **数据一致性校验** - `pt-table-checksum`工具检测主从不一致 - `pt-table-sync`工具修复差异数据 --- **案例演示**:从节点同步延迟分析 ```sql SHOW SLAVE STATUS\G -- 观察 Seconds_Behind_Master 值 -- 若>0 检查: -- 1. 网络延迟 (ping master) -- 2. SQL线程阻塞 (processlist) -- 3. 主节点写入压力 (iostat) ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值