MySQL主从复制原理以及docker安装MySQL主从复制遇到的问题
undefinedundefined
1.简介#
mysql从3.23版本开始提供复制功能,复制是将主库的DDL和DML操作通过二进制日志传递到复制服务器(从库)上,然后从库对这些日志重新执行(重做),从而使得主库和从库保持数据一致。#
2.MySQL 主从复制的原理#
MySQL主从复制涉及到三个线程,一个运行在主节点(log dump thread),其余两个(I/O thread, SQL thread)运行在从节点,如下图所示:
1)主节点 log dump 线程
当从节点连接主节点时,主节点会为其创建一个log dump 线程,用于发送和读取bin-log的内容。在读取bin-log中的操作时,log dump线程会对主节点上的bin-log加锁,当读取完成,在发送给从节点之前,锁会被释放。主节点会为自己的每一个从节点创建一个log dump 线程。
2)从节点 I/O线程
当从节点上执行`start slave`命令之后,从节点会创建一个I/O线程用来连接主节点,请求主库中更新的bin-log。I/O线程接收到主节点的blog dump进程发来的更新之后,保存在本地relay-log(中继日志)中。
3)从节点 SQL线程
SQL线程负责读取relay-log中的内容,解析成具体的操作并执行,最终保证主从数据的一致性。
对于每一个主从连接,都需要这三个进程来完成。当主节点有多个从节点时,主节点会为每一个当前连接的从节点建一个log dump 进程,而每个从节点都有自己的I/O进程,SQL进程。从节点用两个线程将从主库拉取更新和执行分成独立的任务,这样在执行同步数据任务的时候,不会降低读操作的性能。比如,如果从节点没有运行,此时I/O进程可以很快从主节点获取更新,尽管SQL进程还没有执行。如果在SQL进程执行之前从节点服务停止,至少I/O进程已经从主节点拉取到了最新的变更并且保存在本地relay日志中,当服务再次起来之后,就可以完成数据的同步。
要实施复制,首先必须打开Master 端的binary log(bin-log)功能,否则无法实现。
因为整个复制过程实际上就是Slave 从Master 端获取该日志然后再在自己身上完全顺序的执行日志中所记录的各种操作。如下图所示:
4)复制的基本过程
- 在从节点上执行sart slave命令开启主从复制开关,开始进行主从复制。从节点上的I/O 进程连接主节点,并请求从指定日志文件的指定位置(或者从最开始的日志)之后的日志内容;
- 主节点接收到来自从节点的I/O请求后,通过负责复制的I/O进程(log dump 线程)根据请求信息读取指定日志指定位置之后的日志信息,返回给从节点。返回信息中除了日志所包含的信息之外,还包括本次返回的信息的bin-log file 的以及bin-log position(bin-log中的下一个指定更新位置);
- 从节点的I/O进程接收到主节点发送过来的日志内容、日志文件及位置点后,将接收到的日志内容更新到本机的relay-log(中继日志)的文件(Mysql-relay-bin.xxx)的最末端,并将读取到的binary log(bin-log)文件名和位置保存到master-info 文件中,以便在下一次读取的时候能够清楚的告诉Master“我需要从某个bin-log 的哪个位置开始往后的日志内容,请发给我”;
- Slave 的 SQL线程检测到relay-log 中新增加了内容后,会将relay-log的内容解析成在主节点上实际执行过SQL语句,然后在本数据库中按照解析出来的顺序执行,并在relay-log.info中记录当前应用中继日志的文件名和位置点。
docker 安装MySQL主从复制遇到的问题记录
一. 登录MySQL提示密码错误 ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)
解决:1.挂载出MySQL的配置目录,修改配置文件my.cnf ;追加skip-grant-tables
2.重启MySQL容器,并进入,此时密码为空 mysql -uroot -p 即可
3.更新root密码为空
use mysql;
select user,authentication_string,host from user;
update user set authentication_string='' where user='root';
flush privileges;
4.退出MySQL,把追加的skip-grant-tables 注释,再次重启MySQL容器
5.再次进入MySQL,修改root密码即可
alter user 'root'@'localhost' IDENTIFIED BY '123456' ;
alter user 'root'@'%' IDENTIFIED BY '123456';
select user,authentication_string,host from user;
flush privileges;
二、主从同步报错:Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'
解决办法:1.停止slave服务器的主从同步 stop slave
2.对Master数据库加锁 flush tables with read lock;
3.备份Master上的数据 mysqldump -uroot -p -B db1 db2 >bak.sql
4.重置Master服务 reset master;
#reset master 将删除所有的二进制日志,创建一个名为 ****.000001的空日志文件。reset master 并不会影响slave服务器的工作状态。盲目执行这个命令有可能导致 slave报这个错误:“Got fatal error 1236 from master when reading data from binary log: 'could not find next log'” 造成主从同步失败。
此时需要重置同步,所以需要执行一下
5.对Master解锁 unlock tables;
6.将Master备份文件拷贝到slave上去 scp bak.sql root@192.168.35.68 /root/
7.删除slave上的旧数据 drop database db1; drop database db2;
8.导入数据 source /root/bak.sql
9.重置slave reset slave #reset slave 将清除slave上的同步位置信息,删除所有的中继日志,不管SQL线程是否执行完毕。
10.开启slave start slave
转载参考链接:
https://blog.csdn.net/K_520_W/article/details/117135287
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· TypeScript + Deepseek 打造卜卦网站:技术与玄学的结合
· 阿里巴巴 QwQ-32B真的超越了 DeepSeek R-1吗?
· 【译】Visual Studio 中新的强大生产力特性
· 【设计模式】告别冗长if-else语句:使用策略模式优化代码结构
· AI与.NET技术实操系列(六):基于图像分类模型对图像进行分类