Linux、MySQL--主从、MHA知识整理

最新推荐文章于 2023-07-25 10:51:25 发布

1BeLiEvEr1

最新推荐文章于 2023-07-25 10:51:25 发布

阅读量1.9k

点赞数

文章标签： mysql linux 数据库

本文链接：https://blog.youkuaiyun.com/BeliefWish/article/details/121168569

版权

本文介绍了Linux环境下的MySQL主从复制与MHA（Master High Availability）的原理和搭建过程，包括MHA的故障切换机制。同时，文章探讨了Linux的CPU、内存、I/O、磁盘容量和网络等五大负载的监控与优化，并对TCP协议进行了深入解析，对比了TCP与UDP的区别。此外，还涉及了内核管理、Nginx的使用及系统资源管理策略。

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

一.MySQL主从复制

主MySQL服务器做的增删改，都会写入自己的二进制日志（Binary log），然后从MySQL服务器打开自己的I/O线程连接主服务器，进行读取主服务器的二进制日志，备份写入到从服务器的中继日志（Relay log）当中，然后从服务器打开SQL线程，将中继日志中的数据重放到自己的服务器中，复制完成。

先复制一份表，做为临时表，保存在内存中，给与用户修改，当事务提交后，再将内存中的临时表数据修改、保存到磁盘中I/o sql线程主要用于主从复制
增删改查中查询和写入→消耗线程资源（是一种连接机制) mysql的线程池处理能力较差→多线程处理能力不够→并发处理能力不够→线程/任务处理能力进行优化redis + MQ

二.MHA

2.1原理

基于二进制日志故障备份＋基于VIP的健康检查＋故障自动切换(master→backup master)

2.2如何搭建MHA

① 首先搭建主从复制

② 软连接（一条是做MySQL命令，mysqlbinlog 软连接）

③ ssh 免交互

④ manager 提权

以上是MySQL集群的操作

node组件

在所有服务器上优先部署

→ 抢救

→ 同步中继日志

→ 在mha节点上的node组件还会汇总其他node组件的信息，用于将详细信息提供给Manager组件

manager

→ 维护mysql集群信息

→ 健康检查+故障切换

核心的配置文件 2个

master_ip_failover → VIP +VIP所在的虚拟接口，如下：

my $vip ='192.168.226.200'; #浮动IP

my $ifdev='ens33' ; #使用的网卡为ens33

my $key='1'; #虚拟接口

app1.cnf

定义了mysql节点的主机(以server的方式来表示)

定义了从节点信息

可定义主备服务器（需要忽略检查策略）

→ 执行两个健康检查+启动MHA

→ 首次启动时，在master节点创建VIP

三.Linux五大负载

3.1CPU

排查cPU负载过高＋CPü怎么看负载过大，多少的数值算是负载，多少算为高负载

→ CPU 占用过高 →进程级别

→ CPU 使用百分比 →哪个CPU 压力过高

3.2内存

内存使用过高，内存溢出out memory 怎么解决 → 内存过高的话，内存中的数据是否可以删除，如

何减缓压力，如何持久化后，再清理，如何选择性的清理内存中的数据 → redis

3.3 I/O

→ I/0负载过高，如何定义I/o的负载，read 和write速率或者压力是多大，多少算是负载

3.4磁盘容量

如何定位磁盘容量使用最高的目录/文件位置

→引申出:如果我的磁盘负载过高了，在定位到磁盘负载最高的文件/目录后，执行了删除（如何删除）删除后的话，发现磁盘的容量大小，没有发生变化，是什么原因?(inode号排除，进阶:排除进程占用)

3.5网络

防火墙、linux防火墙策略、DNS 解析 → 假设我在网上申请了一个域名www.cat.com,发现无法进行解析，是啥情况 → 换一个DNS服务端，是解决方式之一、配置的安全组(云上)、防火墙的选择WAF防火墙，第三方的网络插件，使用的协议TCP为例

TCP协议中：重传机制

四.TCP协议

4.1TCP介绍

TCP/IP协议簇:指TCP和IP协议对应的通信协议

TCP/IP在数据包设计中使用了封装和分用的策略

封装:应用程序发送数据的过程中，每层都增加了一些首部信息，用于发送方与接收方这一层次进行交互

分用:对于不同通信、交互方式使用了不同的协议规范

TCP重要的机制:三次握手、四次挥手

为什么要三次握手:为了防止已失效的连接延迟后连接到server端，当server端收到请求后，会误认为是新建连接，然后会向Client端发送ACK建立连接，而Client端已经放弃了此次请求，也并不会向Server端发送数据，如此，server端就会浪费很多资源，所以第三次握手是为了解决这个问题，而如果为四次挥手的话再次确认会浪费资源