揭秘MySQL主从复制：打造高可用性与数据冗余的强效引擎

news2024/11/24 6:48:19

  •  作者简介：我是团团儿，是一名专注于云计算领域的专业创作者，感谢大家的关注
  •  座右铭：   云端筑梦，数据为翼，探索无限可能，引领云计算新纪元
  •  个人主页：团儿.-CSDN博客

目录

前言：

1.全年无故障率(非计划内故障停机)

2.高可用架构方案

正文：

一.MySQL Replication(主从复制)

1.职责

2. 主从复制介绍

3. 主从复制的前提 (搭建主从复制) 

4. 主从复制搭建过程(生产)

（1）两台服务器实现主从：

master:    192.168.8.10

slave: 192.168.8.20

（2）主库创建复制用户

（3） "复制历史数据"

主: 

从:

（4）告诉从库信息

先查看主库的二进制日志名和position号：

 在从库使用命令连接主库：

（5）从库开启复制线程(IO,SQL)

（6）在从库检查主从复制状态

（7）测试主从同步

主库:

从库:

二.主从复制原理 *****

1.主从复制中涉及的文件

主库: 

从库:   

2.主从复制中涉及的线程

主库:  

从库:   

3.主从复制工作(过程)原理******

补充说明:

4.主从复制监控 

命令:

主库有关的信息(master.info):

从库relay应用信息有关的(relay.info):

从库线程运行状态(排错)

            过滤复制有关的信息:            

从库延时主库的时间(秒):  

延时从库（延时误操作）:

GTID复制有关的状态信息          

5.主从复制故障 *****

5.1 IO 线程故障 

(1) 连接主库: connecting

网络,连接信息错误或变更了,防火墙,连接数上限排查思路:

解决: 

(2) 请求Binlog

解决：

终极解决方案:

(3) 存储binlog到relaylog

5.2 SQL线程故障

合理处理方法: 

暴力的解决方法

方法一：

方法二：

常见错误代码:

为了避免SQL线程故障

(1) 从库只读

(2) 使用读写分离中间件

6.主从延时监控及原因 *****

6.1 主库方面原因

(1) binlog写入不及时

(2) 默认情况下dump_t 是串行传输binlog *****

(3) 主库极其繁忙

6.2 从库方面原因

6.3 主从延时的监控

主库方面原因的监控

主库:

从库

从库方面原因监控:

拿了多少:

执行了多少:

前言：

1.全年无故障率(非计划内故障停机)

99.9%        0.001*365*24*60       525.6Min
99.99%       0.0001*365*24*60       52.56Min
99.999%      0.00001*365*24*60       5.256Min        

2.高可用架构方案

（1）负载均衡:有一定的高可用性 
    LVS  Nginx haproxy
（2）主备系统:有高可用性,但是需要切换,是单活的架构
    Keepalived , MHA, MMM
（3）真正高可用(多活系统): 
    NDB Cluster  Oracle RAC  Sybase cluster   , InnoDB Cluster（MGR）,PXC(percona) , MGC(mariadb)

本文将带领大家深入探索mysql之主从复制的奥秘！

正文：

一.MySQL Replication(主从复制)

1.职责

（1） 搭建主从复制   
（2） 主从原理熟悉   
（3） 主从的故障处理 
（4） 主从延时，同步不及时       
（5） 主从的特殊架构（过滤复制、延时从库）的配置使用 
（6） 主从架构的演变（读写分离、高可用、分布式架构） 

2. 主从复制介绍

(1) 主从复制基于binlog来实现的
(2) 主库发生新的操作,都会记录binlog
(3) 从库取得主库的binlog进行回放
(4) 主从复制的过程是异步


3. 主从复制的前提 (搭建主从复制) 

(1) 2个或以上的数据库实例
(2) 主库需要开启二进制日志 
(3) server_id要不同,区分不同的节点
(4) 主库需要建立专用的复制用户 (replication slave)
(5) 从库应该通过备份主库、恢复的方法进行复制历史数据
(6) 人为告诉从库一些复制信息(ip port user pass,二进制日志起点)
(7) 从库应该开启专门的复制线程
 

4. 主从复制搭建过程(生产)

（1）两台服务器实现主从：

master:    192.168.8.10
cat > /etc/my.cnf << EOF
[mysqld]
user=mysql
basedir=/usr/local/mysql
datadir=/usr/local/mysql/data
socket=/tmp/mysql.sock
server_id=1
log_bin=/data/binlog/master-bin
port=3306
[mysql]
socket=/tmp/mysql.sock
prompt=master>
EOF
mkdir -p /data/binlog
chown -R mysql.mysql /data 

systemctl restart mysqld

slave: 192.168.8.20
cat > /etc/my.cnf << EOF
[mysqld]
user=mysql
basedir=/usr/local/mysql
datadir=/usr/local/mysql/data
socket=/tmp/mysql.sock
server_id=2
log_bin=/data/binlog/slave-bin
port=3306
[mysql]
socket=/tmp/mysql.sock
prompt=slave>
EOF
mkdir -p /data/binlog
chown -R mysql.mysql /data 

systemctl restart mysqld


（2）主库创建复制用户

登录数据库：

grant replication slave on *.* to repl@'192.168.8.%' identified by '123';


（3） "复制历史数据"

主: 
mysqldump -uroot  -A --master-data=2 --single-transaction -R -E --triggers >/tmp/full.sql
scp /tmp/full.sql  root@192.168.10/root
从:
set sql_log_bin=0;
source /root/full.sql
set sql_log_bin=1;

（4）告诉从库信息

先查看主库的二进制日志名和position号：
    show master status;
 
在从库使用命令连接主库：
CHANGE MASTER TO   
       MASTER_HOST='192.168.8.9',  
       MASTER_USER='repl',  
       MASTER_PASSWORD='123',  
       MASTER_PORT=3306,  
       MASTER_LOG_FILE='master-bin.000001',  
       MASTER_LOG_POS=447,  
       MASTER_CONNECT_RETRY=10;


（5）从库开启复制线程(IO,SQL)

start slave;


（6）在从库检查主从复制状态

show slave status \G

显示信息：
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

（7）测试主从同步

主库:
create database ms;
use ms;
create table t1 (id int,name varchar(20));
insert into t1 values (1,'z3'),(2,'l4'),(3,'w5');

从库:
show databases;
use ms;
select * from t1;


二.主从复制原理 *****

1.主从复制中涉及的文件

主库: 

binlog             主库的二进制日志

从库:   

    relaylog          中继日志
    master.info      主库信息文件
    relaylog.info     relaylog应用的信息

2.主从复制中涉及的线程

主库:  

 Binlog_Dump Thread : DUMP_T

从库:   

    SLAVE_IO_THREAD     : IO_T
    SLAVE_SQL_THREAD    : SQL_T

3.主从复制工作(过程)原理******

 1.从库执行change master to 命令(主库的连接信息+复制的起点)
 2.从库会将以上信息,记录到master.info文件
 3.从库执行 start slave 命令,立即开启IO_T和SQL_T
 4. 从库 IO_T,读取master.info文件中的信息,获取到IP,PORT,User,Pass,binlog的位置信息
 5. 从库IO_T请求连接主库,主库专门提供一个DUMP_T,负责和IO_T交互
 6. IO_T根据binlog的位置信息(mysql-bin.000004 , 444),请求主库新的binlog
 7. 主库通过DUMP_T将最新的binlog,通过网络TP给从库的IO_T
 8. IO_T接收到新的binlog日志,存储到TCP/IP缓存,立即返回ACK给主库,并更新master.info
 9.IO_T将TCP/IP缓存中数据,转储到磁盘relaylog中.
 10. SQL_T读取relay.info中的信息,获取到上次已经应用过的relaylog的位置信息
 11. SQL_T会按照上次的位置点回放最新的relaylog,再次更新relay.info信息
 12. 从库会自动purge应用过relay进行定期清理
 

补充说明:

一旦主从复制构建成功,主库当中发生了新的变化,都会通过dump_T发送信号给IO_T,增强了主从复制的实时性.

4.主从复制监控 

命令:

show slave status \G

主库有关的信息(master.info):

Master_Host: 192.168.8.9
Master_User: repl
Master_Port: 3306
Connect_Retry: 10
*******************************
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 608

*******************************

从库relay应用信息有关的(relay.info):

Relay_Log_File: mysql-relay-bin.000002
Relay_Log_Pos: 479
Relay_Master_Log_File: mysql-bin.000001

从库线程运行状态(排错)

Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Last_IO_Errno: 0
Last_IO_Error: 
Last_SQL_Errno: 0
Last_SQL_Error:             

            
过滤复制有关的信息:            

Replicate_Do_DB: 
Replicate_Ignore_DB: 
Replicate_Do_Table: 
Replicate_Ignore_Table: 
Replicate_Wild_Do_Table: 
Replicate_Wild_Ignore_Table: 
 

从库延时主库的时间(秒):  

Seconds_Behind_Master: 0
                

延时从库（延时误操作）:

SQL_Delay: 0
SQL_Remaining_Delay: NULL

GTID复制有关的状态信息          

Retrieved_Gtid_Set: 
Executed_Gtid_Set: 
Auto_Position: 0

5.主从复制故障 *****

5.1 IO 线程故障 

(1) 连接主库: connecting
网络,连接信息错误或变更了,防火墙,连接数上限
排查思路:

1. 使用复制用户手工登录
测试是否用户名、密码、IP出错。

解决: 

从库
1. stop slave         #停止同步
2. reset slave all;      #清空master.info
3. change master to ...    #重新查看master，再次连接master
4. start slave        #再次开启同步

(2) 请求Binlog

binlog 没开
binlog 损坏,不存在

解决：

主库开启binlog

终极解决方案:

主库 reset master 处理:
从库 

stop slave ;
reset slave all; 
CHANGE MASTER TO 
MASTER_HOST='192.168.8.10',
MASTER_USER='repl',
MASTER_PASSWORD='123',
MASTER_PORT=3306,
MASTER_LOG_FILE='master-bin.000001',
MASTER_LOG_POS=154,
MASTER_CONNECT_RETRY=10;
start slave;
(3) 存储binlog到relaylog


5.2 SQL线程故障

relay-log损坏
回放relaylog
研究一条SQL语句为什么执行失败?
insert delete  update     ---> t1 表 不存在
create table  t1     ---> t1 已存在
约束冲突(主键,唯一键,非空..)

合理处理方法: 

把握一个原则,一切以主库为准进行解决.
如果出现问题,尽量进行反操作
最直接稳妥办法,重新构建主从


暴力的解决方法
方法一：
stop slave; 
set global sql_slave_skip_counter = 1;
start slave;

#将同步指针向下移动一个，如果多次不同步，可以重复操作。
start slave;

方法二：
/etc/my.cnf

slave-skip-errors = 1032,1062,1007

常见错误代码:

1007:对象已存在
1032:无法执行DML,可能对象不存在
1062:主键冲突,或约束冲突

但是，以上操作有时是有风险的，最安全的做法就是重新构建主从。把握一个原则,一切以主库为主.

为了避免SQL线程故障
(1) 从库只读
read_only
super_read_only
(2) 使用读写分离中间件

amoeba
atlas 
mycat
ProxySQL 
MaxScale

6.主从延时监控及原因 *****

6.1 主库方面原因

(1) binlog写入不及时
sync_binlog=1
(2) 默认情况下dump_t 是串行传输binlog *****

在并发事务量大时或者大事务,由于dump_t 是串型工作的,导致传送日志较慢
如何解决问题?
必须GTID,使用Group commit方式.可以支持DUMP_T并行

(3) 主库极其繁忙

慢语句
锁等待
从库个数
网络延时

6.2 从库方面原因

(1) 传统复制(Classic)中 *****

如果主库并发事务量很大,或者出现大事务
由于从库是单SQL线程,导致,不管传的日志有多少,只能一次执行一个事务.
5.6 版本,有了GTID,可以实现多SQL线程,但是只能基于不同库的事务进行并发回放.(database) 
5.7 版本中,有了增强的GTID,增加了seq_no,增加了新型的并发SQL线程模式(logical_clock),MTS技术
(2) 主从硬件差异太大
(3) 主从的参数配置
(4) 从库和主库的索引不一致
(5) 版本有差异


6.3 主从延时的监控

show slave  status\G
Seconds_Behind_Master: 0
主库方面原因的监控
主库:
show master status ;

File: mysql-bin.000001
Position: 1373

从库

Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 1373

从库方面原因监控:
拿了多少:

Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 691688

执行了多少:

Relay_Log_File: db01-relay-bin.000004
Relay_Log_Pos: 690635
Exec_Master_Log_Pos: 691000
Relay_Log_Space: 690635

期待您的关注~

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.coloradmin.cn/o/2160947.html

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！

相关文章

从Web2到Web3：探索下一代互联网的无限可能性

从Web2到Web3：探索下一代互联网的无限可能性

互联网经历了从Web1到Web2的重大变革&#xff0c;现在正迈向Web3。Web2通过社交媒体、电子商务和内容平台改变了我们的数字生活&#xff0c;但同时也伴随着中心化平台的垄断和用户数据被广泛控制的问题。而Web3的出现&#xff0c;则试图通过去中心化技术解决这些挑战&#xff0…
阅读更多...
人到中年，最清醒的活法—沉浸式做自己

人到中年，最清醒的活法—沉浸式做自己

生活中&#xff0c;你是不是常常被这样的事情所困扰&#xff1f; 工作的时候&#xff0c;每天被千头万绪的杂事缠身&#xff0c;看着一堆待完成事项&#xff0c;和工作群里一堆的消息在轰炸你&#xff0c;内心顿感烦躁甚至暴怒。 经常因为领导&#xff0c;同事或者熟人甚至陌生…
阅读更多...
java 洛谷题单【算法1-7】搜索

java 洛谷题单【算法1-7】搜索

P1219 [USACO1.5] 八皇后 Checker Challenge 解题思路 回溯法 递归与回溯: 从第0行开始&#xff0c;为每个行尝试放置棋子的位置&#xff0c;检查放置是否违反约束条件。如果放置合法&#xff0c;则继续递归处理下一行&#xff08;即下一层递归&#xff09;。如果当前行无法找…
阅读更多...
【Go语言】深入解读Go语言中的指针，助你拨开迷雾见月明

【Go语言】深入解读Go语言中的指针，助你拨开迷雾见月明

✨✨ 欢迎大家来到景天科技苑✨✨ &#x1f388;&#x1f388; 养成好习惯&#xff0c;先赞后看哦~&#x1f388;&#x1f388; &#x1f3c6; 作者简介&#xff1a;景天科技苑 &#x1f3c6;《头衔》&#xff1a;大厂架构师&#xff0c;华为云开发者社区专家博主&#xff0c;…
阅读更多...
浅谈提示工程之In-context learning技术

浅谈提示工程之In-context learning技术

提示工程之In-context learning技术&#xff1b; 通过一张图片围绕下边几个方面进行简单说明 概念起因本质结构注意事项 日常总结
阅读更多...
SQL语法学习与实战应用

SQL语法学习与实战应用

第一章 引言 1.1 MySQL数据库概述 MySQL&#xff0c;作为一种广泛使用的关系型数据库管理系统&#xff0c;自其问世以来&#xff0c;便凭借开源、高性能及低成本等显著特点&#xff0c;迅速占据了广泛的市场份额。这一系统不仅支持大规模并发访问&#xff0c;更提供了多样化的…
阅读更多...
【最新华为OD机试E卷-支持在线评测】绘图机器(100分)多语言题解-(Python/C/JavaScript/Java/Cpp)

【最新华为OD机试E卷-支持在线评测】绘图机器(100分)多语言题解-(Python/C/JavaScript/Java/Cpp)

🍭 大家好这里是春秋招笔试突围 ，一枚热爱算法的程序员 💻 ACM金牌🏅️团队 ｜ 大厂实习经历 ｜ 多年算法竞赛经历 ✨ 本系列打算持续跟新华为OD-E/D卷的多语言AC题解 🧩 大部分包含 Python / C / Javascript / Java / Cpp 多语言代码 👏 感谢大家的订阅➕ 和 喜欢�…
阅读更多...
【ARM】MDK-当选择AC5时每次点击build都会全编译

【ARM】MDK-当选择AC5时每次点击build都会全编译

1、 文档目标 解决MDK中选择AC5时每次点击build都会全编译 2、 问题场景 在MDK中点击build时&#xff0c;正常会只进行增量编译&#xff0c;但目前每次点击的时候都会全编译。 3、软硬件环境 1 软件版本&#xff1a;Keil MDK 5.38a 2 电脑环境&#xff1a;Window 10 4、解决…
阅读更多...
新手操作指引：快速上手腾讯混元大模型

新手操作指引：快速上手腾讯混元大模型

引言 腾讯混元大模型是一款功能强大的AI工具&#xff0c;适用于文本生成、图像创作和视频生成等多种应用场景。对于新手用户&#xff0c;快速上手并充分利用这一工具可能会有些挑战。本文将提供详细的新手操作指引&#xff0c;帮助您轻松开始使用腾讯混元大模型。 步骤一&…
阅读更多...
kubernetes网络(二)之bird实现节点间BGP互联的实验

kubernetes网络(二)之bird实现节点间BGP互联的实验

摘要 上一篇文章中我们学习了calico的原理&#xff0c;kubernetes中的node节点&#xff0c;利用 calico 的 bird 程序相互学习路由&#xff0c;为了加深对 bird 程序的认识&#xff0c;本文我们将使用bird进行实验&#xff0c;实验中实现了BGP FULL MESH模式让宿主相互学习到对…
阅读更多...
个人行政复议在线预约系统开发+ssm论文源码调试讲解

个人行政复议在线预约系统开发+ssm论文源码调试讲解

第二章 开发工具及关键技术介绍 2.1 JAVA技术 Java主要采用CORBA技术和安全模型&#xff0c;可以在互联网应用的数据保护。它还提供了对EJB&#xff08;Enterprise JavaBeans&#xff09;的全面支持&#xff0c;java servlet API&#xff0c;JSP&#xff08;java server pages…
阅读更多...
Pygame中Sprite实现逃亡游戏2

Pygame中Sprite实现逃亡游戏2

在《Pygame中Sprite实现逃亡游戏1》中实现了奔跑的玩家&#xff0c;接下来实现显示追赶玩家的飞龙以及对面过来的飞火。 1 显示飞龙 显示飞龙的代码如图1所示。 图1 显示飞龙的代码 其中&#xff0c;第93行代码创建了精灵类MySprite的实例dragon&#xff1b;第94行代码导入飞…
阅读更多...
《十年国庆游，洞察中国旅游新趋势》

《十年国庆游，洞察中国旅游新趋势》

作者&#xff1a;侯炯 一、十年国庆旅游数据总览 过去十年&#xff0c;中国国庆旅游市场呈现出丰富的变化和强劲的发展态势。从接待游客人次来看&#xff0c;2014 年接待国内游客 4.75 亿人次&#xff0c;到 2019 年已增长至 7.82 亿人次&#xff0c;2023 年国内旅游出游人数更…
阅读更多...
如何使用ssm实现新媒体视域下的中国古诗词展演+vue

如何使用ssm实现新媒体视域下的中国古诗词展演+vue

TOC ssm678新媒体视域下的中国古诗词展演vue 绪论 课题背景 身处网络时代&#xff0c;随着网络系统体系发展的不断成熟和完善&#xff0c;人们的生活也随之发生了很大的变化。目前&#xff0c;人们在追求较高物质生活的同时&#xff0c;也在想着如何使自身的精神内涵得到提…
阅读更多...
SpringBoot文档管理系统：架构与功能

SpringBoot文档管理系统：架构与功能

第2章相关技术 2.1 Java技术介绍 Java语言擅长开发互联网类应用和企业级应用&#xff0c;现在已经相当的成熟&#xff0c;而且也是目前使用最多的编程语言之一。Java语言具有很好的面向对象性&#xff0c;可以符合人的思维模式进行设计&#xff0c;封装是将对象的属性和方法尽可…
阅读更多...
FileLink：企业级跨网文件交换解决方案，效率与安全并存

FileLink：企业级跨网文件交换解决方案，效率与安全并存

在数字化转型的时代&#xff0c;企业面临着日益增长的文件交换需求。尤其是在跨网环境中&#xff0c;如何高效、安全地共享文件&#xff0c;成为企业运营的关键。FileLink 正是针对这一需求而生&#xff0c;为企业提供了一个高效、安全的文件交换解决方案。 一、FileLink的核心…
阅读更多...
基本定时器的预分频器和技术周期的计算

基本定时器的预分频器和技术周期的计算

从表中可见APB1和APB2他们的总线频率和时钟频率则是不一样的 APB1的总线频率是42MHZ 定时器的时钟频率则为84MHZ APB2的总线频率则为84MHZ 定时器则为168MHZ 如我们要使用某个寄存器则我们需要了解他们的定时器的频率则为多少 了解后则进行计算所需要的时间 列如:配置定时…
阅读更多...
【CSS in Depth 2 精译_032】5.4 Grid 网格布局的显式网格与隐式网格（上）

【CSS in Depth 2 精译_032】5.4 Grid 网格布局的显式网格与隐式网格（上）

当前内容所在位置&#xff08;可进入专栏查看其他译好的章节内容&#xff09; 第一章 层叠、优先级与继承&#xff08;已完结&#xff09; 1.1 层叠1.2 继承1.3 特殊值1.4 简写属性1.5 CSS 渐进式增强技术1.6 本章小结 第二章 相对单位&#xff08;已完结&#xff09; 2.1 相对…
阅读更多...
揭秘隐世秘学与千门八将的智慧，为什么说是你人生必学？

揭秘隐世秘学与千门八将的智慧，为什么说是你人生必学？

引言 在浩瀚的人类文化长河中&#xff0c;隐藏着无数神秘的隐世秘学&#xff0c;它们或源于古老的传说&#xff0c;或深植于民间的智慧之中。这些秘学不仅承载着人类对未知世界的探索与想象&#xff0c;更蕴含着丰富的哲理与策略。其中&#xff0c;“千门八将”以其独特的智慧体…
阅读更多...
ITU标准引领车内通讯新纪元

ITU标准引领车内通讯新纪元

在现代汽车科技更迭的今天&#xff0c;车内通讯与免提通话系统的性能与稳定性成为了消费者购车时不可忽视的重要因素。随着国际电信联盟&#xff08;ITU&#xff09;一系列标准的推出&#xff0c;车内通讯体验正迈向新的高度。本文将深入探讨ITU-T P.1100、P.1110、P.1120、P.1…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023