Jiangxl~-CSDN博客

原创《MySQL DBA封神打怪之路》专栏学习大纲

jiangxl~🔥个人简介🔥CSDN博客专家、51CTO专家博主、阿里云博客专家、华为云享专家、DevOps运维领域优质创作者、2021年度博客之星运维与安全领域TOP1，某厂高级运维工程师擅长Linux系统运维、开源监控软件维护、Kubernetes容器技术、CI/CD持续集成、自动化运维、大规模互联网WEB集群架构、开源软件部署维护等领域。🎉博客领域🎉云原生、云计算、数据库、DevOps运维开发。⭐️获得的奖项⭐️《Kubernetes集群方方面面进阶之路》《阿里云入门到精通实战》...........

2022-07-17 11:32:06 16391 443

原创 Kubernetes集群方方面面实战教程学习线路指南

Kubernetes集群方方面面实战教程学习线路指南学习路线指南欢迎大家来到jiangxl~的《Kubernetes集群方方面面进阶之路》专栏，本文给大家详细列出Kubernetes集群方方面面每一章节文章指南，大家可以根据自己的需求阅读想要学习的文章。本专栏涵盖Kubernetes集群方方面面的技术总结，包括高可用集群、Pod资源、Pod资源控制器、配置存储、数据存储、安全框架等各方面深入解析、Helm包管理机制、Istio网格服务，以及基于Kubernetes集群的CI/CD流程设计及实现，总文章

2021-10-31 11:05:35 78108 217

原创二进制方式搭建Kubernetes高可用集群（超丰富的组件概念理论总结）

二进制方式部署Kubernetes高可用集群文章目录二进制方式部署Kubernetes高可用集群1.环境准备1.1.Kubernetes高可用集群部署方式1.2.Kubernetes集群弃用docker容器1.3.Kubernetes集群所需的证书1.4.环境准备1.5.安装cfssl证书生成工具2.操作系统初始化配置3.部署Etcd集群3.1.使用cfssl证书工具生成etcd证书3.2.部署etcd集群4.部署Docker服务4.1.安装docker4.2.为docker创建systemctl启动脚本

2021-09-23 10:04:38 73608 157

原创基于Kubernetes集群的Jenkins CI/CD版本上线流程部署

基于kubernetes平台的CICD持续集成文章目录基于kubernetes平台的CICD持续集成1.基于k8s集群的Jenkins持续集成2.将Jenkins部署在k8s集群2.1.编写Jenkins namespace文件2.2.编写Jenkins rbac授权文件2.3.编写Jenkins statefulset资源文件2.4.编写Jenkins StorageClass资源文件2.5.编写Jenkins svc资源文件2.6.准备Jenkins镜像并推送至harbor2.7.创建所有资源并查看资

2021-08-23 09:54:12 65182 70

原创部署ELK+Kafka+Filebeat日志收集分析系统

ELK+Kafka+Filebeat日志系统文章目录ELK+Kafka+Filebeat日志系统1.环境规划2.部署elasticsearch集群2.1.配置es-1节点2.2.配置es-2节点2.3.配置es-3节点2.4.使用es-head插件查看集群状态3.部署kibana4.部署zookeeper4.1.配置zookeeper-1节点4.2.配置zookeeper-2节点4.3.配置zookeeper-3节点4.4.启动所有节点5.部署kafka5.1.配置kafka-1节点5.2.配置kafka

2021-08-16 15:16:05 27927 28

原创 Prometheus+Grafana全方位监控Kubernetes集群资源利用率

Prometheus+Grafana全方位监控Kubernetes集群文章目录Prometheus+Grafana全方位监控Kubernetes集群1.k8s监控指标2.k8s基础环境准备2.1.环境准备2.2.部署nfs作为prometheus存储2.3.获取prometheus yaml文件2.4.创建命名空间prometheus3.在k8s中部署prometheus3.1.prometheus-yaml准备3.2.创建rbac资源3.3.创建configmap资源3.4.创建statefulset资

2021-01-06 17:03:20 18641 17

原创 Prometheus+Grafana监控系统配合Cadvisor监控Docker容器

prometheus使用cadvisor监控docker容器1.cadvisor概述一般公司会有很多docker主机，那么就需要对docker进行监控了，docker监控可以采用docker stats配合shell命令来取值做监控，但是无法传递给prometheus进行采集，zabbix监控docker又比较麻烦，因此就有了谷歌的cadvisorcadvisor不仅可以搜集一台机器上的所有运行的容器信息，还提供基础查询界面的http接口，方便prometheus进行数据抓取cadvisor可以对节

2020-12-24 14:43:43 17393 11

原创利用zabbix api批量添加数百台监控主机

利用zabbix api批量添加监控主机在公司规模很庞大的时候，每次都手动添加监控主机将会很麻烦，我们可以利用zabbix的api去批量添加监控主机本次我们将实现用一台主机虚拟出100台主机，并通过api的方式自动添加监控主机有了本次方法，无需要了解python，也不需要写python脚本1.获取批量添加主机的api{ "jsonrpc": "2.0", "method": "host.create", "params": { "host": "192.16

2020-12-18 16:33:32 2614 8

原创第⑯讲：Ceph集群Pool资源池管理以及PG的数据分布的核心技术要点

如果一个Pool资源池中的PG数量很多，就意味着会通过CRUSH算法将Object数据分散写入到更多的OSD中，数据分散存储在OSD的数量越多，对于数据的安全性就越高，相反，如果Pool中的PG数量过少，那么通过CRUSH算法将数据分散存储到OSD的数量就越少，数据的丢失概率就会很高。在使用公式计算PG的数量时，建议使用OSD*200，可以方便后期的数据量的扩展，随着数据量的增长，PG的数量也需要增长，如果一开始设置的数量很多，再后期就不需要扩容了。例子：集群有200个OSD，Pool资源池的副本数为3。

2024-04-23 09:25:33 896 17

原创第⑮讲：Ceph集群管理与监控操作指南

命令可以查看集群中每个OSD的资源利用率，包括使用率和可用空间的大小，以及OSD的状态，通过此命令可以观察OSD的空间剩余，如果OSD的空间不足，也会导致集群出现问题，当OSD空间不足时，可以扩容OSD或者删除上层文件来解决。命令可以看到集群的资源利用率，会显示出Ceph集群的总空间容量、剩余容量、使用的容量，还会显示出集群中Pool资源池的利用率。通过集群状态信息可以看到集群的健康状态、各个组件的运行状态以及数据使用情况。类似于tail命令，持续变化刷新集群的状态信息。

2024-04-17 09:29:57 4006 19

原创第⑭讲：Ceph集群管理：守护进程管理、日志管理和端口号配置

官方操作文档：https://docs.ceph.com/en/pacific/rados/operations/operating/带@符号的都是可以对一个主机或者某一个组件进行管理操作，以target结尾的都是全局性质的。快速记忆：带target的表示管理所有该组件的进行，带@的表示管理单一组件。这几种方式中，循序渐进，越来越细微划分，从整体到分组到单体到个体。Ceph所有组件的守护进程：ceph.target。Ceph组件守护进程管理是通过。

2024-04-15 09:50:56 7462 31

原创第⑬讲：OSD硬盘故障处理实战：从诊断到恢复的全流程指南

如果硬盘出现了坏道的情况，就会影响整个集群的性能，从而拖垮整个Ceph集群，遇到这种情况执行上述命令不会显示down的状态，因为磁盘出现了坏道，磁盘还是可以用的，只不过性能有所下降。OSD从集群中踢出时，也会触发Reblanceing数据重分布机制，将OSD中的数据迁移到其他的OSD中，当OSD的数据全部同步完成后，再将OSD彻底移除。将故障的OSD硬盘修复好之后，将该盘的LVM卷删除，然后通过添加OSD的方式，将该OSD重新加入集群即可。原来集群中有8个OSD，选择已经变成7个OSD了，删除成功。

2024-04-11 09:27:15 891 17

原创第⑫讲：Ceph集群OSD扩缩容中Reblanceing数据的重分布

在实际生产环境中，如果PG中的数据量非常大，在触发Reblanceing机制时，会对集群的性能有所影响，如果一次性增加很多个OSD节点，那么就意味着会有大量的PG被移动，此时就会对集群的性能产生巨大的影响，因此建议，每次在扩容OSD时，只扩容一个OSD。在扩容前集群有两个OSD节点，这两个OSD中分布着十个PG，扩容后，集群中有三个OSD节点，此时就会触发Reblanceing数据重分布机制，将原有的两个OSD中的一部分PG移动到第三个OSD中，使的每个OSD中的PG数量均衡。

2024-04-09 09:40:04 1077 16

原创第⑪讲：Ceph集群OSD扩容方案及实现横向和纵向扩容

ceph-node-1节点已经有3个OSD，一个硬盘就对应一个OSD节点。这条命令其实就是执行了一个dd命令，将硬盘的数据清空。

2024-04-07 09:36:36 855 23

原创第117讲：深入MySQL性能优化：从多个角度提升数据库性能

一般情况下，IO要和CPU参照对比分析，CPU高的情况下，IO也会很高，如果CPU的wait很高，IO很低，那么有可能就是磁盘出问题，如果CPU的sys很高，IO很低，那么可能就是数据库层面出问题，可能是锁，需要进一步的分析和判断。，如果服务器的并发请求量比较大，可以去调高这个值，当然是要在服务器能够承受的压力下，去调整这个参数的值，随着连接数越来越多，MySQL会为每个连接提供缓冲区，就会导致开销越来越多的内存，对于连接数这个值不能随便去调高。

2024-04-03 09:16:04 1599 29

原创第116讲：使用Mycat-eye管理Mycat数据库服务

Mycat-web(Mycat-eye)是对mycat-server提供监控服务，功能不局限于对mycat-server使用。他通过JDBC连接对Mycat、Mysql监控，监控远程服务器(目前仅限于linux系统)的cpu、内存、网络、磁盘。

2024-04-01 09:43:38 1601 35

原创第115讲：Mycat核心配置文件各项参数的作用以及概念

在Mycat中核心的配置文件有schema.xml和rule.xml以及server.xml三个，其中schema.xml是用来配置数据库、表、读写分离、分片节点、分片规则等信息，rule.xml主要是用来定义拆分表的规则，server.xml包含了mycat的系统配置信息。在user标签中主要是配置那些用户可以登陆到Mycat，该用户必须在数据库中存在，并且可以配置用户针对逻辑库、逻辑表的一些权限，如果同时对逻辑库或者逻辑表都设置了权限，那么逻辑表的权限大于逻辑库的权限。

2024-03-28 09:22:49 1473 15

原创第114讲：Mycat实践指南：按照单位为月的日期实现水平分表

如下图所示，设置分表的属性为10天进行一次分表，分表周期是2022-01-01到2022-01-30这个时间范围，每隔10天进行一次分表，那么在这个范围内一共会进行3次分片，注意以时间范围进行分表，分表的次数要与分片的节点数相对应，否则将会分表失败。可以看到1月的数据写入到分片1中，2月的数据写入到了分片2中，3月的数据写入到了分片2中，4月的数据写入到了分片1中。设置了按月分片后，1月的数据写入到分片1，2月的数据写入到分片2，3月的数据写入分片3，4月的数据写入分片1。

2024-03-26 09:07:33 1252 22

原创第113讲：Mycat实践指南：按照单位为天的日期实现水平分表

如下图所示，设置分表的属性为10天进行一次分表，分表周期是2022-01-01到2022-01-30这个时间范围，每隔10天进行一次分表，那么在这个范围内一共会进行3次分片，注意以时间范围进行分表，分表的次数要与分片的节点数相对应，否则将会分表失败。可以看到1号到15号的数据写入到了分片1中，15-30号的数据写入到了分片2中，31号的数据相当于下一个轮回，写入到分片1。按照日期进行分片，单位为天，根据设置的规则属性，例如10天一分表，每10天就会进行一次分表。

2024-03-22 09:38:54 1411 10

原创第112讲：Mycat实践指南：字符串Hash算法分片下的水平分表详解

当字段值为word时，首先根据截取的子字符串长度（0:2）截取3位，截取后子字符串为wor，然后通过Hash运算得到一个二进制数，再通过固定Hash，将二进制数与1111111111进行位运算，得到一个十进制数5，拿着这个十进制数5在数组集合中查找，最后查找到5位于0-511之内，0-511属于分片1，此时这条数据就会路由到分片1中存储。在0-511之间数组的结构中，会记录上第一个分片节点的ID0，512-1023之间的数组的结构中，记录第二个分片节点的ID1。

2024-03-20 09:37:38 1030 13

原创第111讲：Mycat实践指南：固定Hash算法分片下的水平分表详解

例如当字段值为515，经过固定Hash算法运算，将515转换成二进制数，与1023的二进制数进行位运算，最后的出来位运算的结果是十进制数515，515位于512-1023数组之间，此时就会拿导512-1023数组对应的分片ID号，然后将这条数据写入到对应的分片节点中。我们可以将分片策略设置0-255之间划分到分片1，256-512之间划分到分片2，512-1023划分到分片3，当依据字段被固定Hash转换成2进制数并且位运算完后，得到一个十进制数时，根据十进制数所在的分片，将数据写入到对应的分片节点中。

2024-03-18 09:40:51 1020 14

原创第110讲：Mycat实践指南：指定Hash算法分片下的水平分表详解

应用指定Hash算法分片指的是，由应用自主决定路由到哪一个分片节点，根据分片的字段通过Hash算法计算出分片号，最终将数据写入到特定的分片节点中应用指定Hash算法分片的字段必须是数字类型的内容，否则没有分片的条件。字段值的内容例如是01xxxx，我们在配置分片规则时，就可以取前两个数字，然后根据Hash算法写入到对应的分片中。

2024-03-15 10:07:24 773 18

原创第109讲：Mycat实践指南：一致性Hash分片下的水平分表详解

所谓的一致性哈希，指的是相同的哈希因子计算值总是会被划分到相同的分片节点上，也就是作为分表依据的字段说通过Hash计算的哈希因子计算值，具有相同计算值的数据会被划分到相同的分片节点中，是按照哈希因子的计算值进行水平分表的。如果我们以id列作为一致性哈希分片的依据列，那么就不需要调整分片规则了，只需要调整分片规则函数中的节点数量即可。通过一致性哈希分片不会因为将来分片节点数的增加，而改变数据原来的存放位置，有效解决了分布式数据的问题。分片依旧是2个，还是之前垂直分库分表时使用的两套双主双从集群。

2024-03-13 09:12:53 1871 16

原创第108讲：Mycat实践指南：枚举分片下的水平分表详解

枚举分片使用时，需要先定义一个配置文件，在配置文件中声明枚举字段的值对应的分片节点ID，需要实现规划好枚举字段值的所有可能出现的值，避免有漏掉的字段值，没有在配置文件中定义，导致无法写入数据，当然如果在枚举函数中配置了defaultNode参数，可以避免此问题，当这条数据中的枚举字段值没有在配置文件中指定对应的节点ID，这条数据就被写入到默认的分片节点中。含义：当枚举字段的值为bj时，该数据写入到分片ID为0的的分片节点，当值为sh时，写入到分片ID为1的分片节点。下面我们通过枚举分片来实现这个需求。

2024-03-11 09:18:15 1434 25

原创第107讲：Mycat实践指南：取模分片下的水平分表详解

根据id列进行取模分片，写入数据的id为15，分片节点数为2个，运算过程：15/2=7余1，余数为1，取模分片此时就会将这个数据写入到分片2中，因为在Mycat分片中，分片的ID都是从0开始的，余数的值就是要写入对应分片节点的ID号，余数为1就对应分片2这个节点。指定取模分片的字段一定要是数字类型的字段，否则是无法进行运算的。在Rule分片规则配置文件中，我们要配置主要是根据表中的那个字段进行范围分片，如果做取模分片的字段也是id字段，就不需要调整这个配置文件，只需要调整取模分片中传入的参数。

2024-03-08 10:16:53 916 19

原创第106讲：Mycat实践指南：范围分片下的水平分表详解

如果是生产环境的某张表进行水平分表，比如说表数据400w行都在分片1中读写的，水平分表时，分片1中的数据可以不动，按照范围，400w以后的数据在分表完成后，会自动路由到分片2上，因此只需要在所有的分片上准备好表结构即可，旧数据就在原实例。如果同时由多个表需要范围分片，并且做范围分片的字段都是不同的，我们也可以自己定义一个分片规则，只是给分片规则改个名而已，然后指定做分片的字段，指定调用哪一个函数即可，范围分片的函数是rang-long，在配置文件下面有显示。

2024-03-06 09:38:30 927 21

原创第105讲：Mycat垂直分表实战：从规划到解决问题的完整指南

我们的商城系统数据库，目前是单点数据库，随着业务量越来越大，每日产生的数据量越来越多，单台数据库的存储能力和计算能力是有限的，为了保证用户的体验度和满意度，在数据库性能到达瓶颈之前，我们先对数据进行性能优化，目前的优化方案是对商城库进行垂直分表，扩展数据库节点，将不同业务的表存储在多个数据库节点中，提高数据库的性能。垂直分库指的是将一个库中的多个表，拆分到多个数据库实例中，也就是拆分到了多台不同的数据库服务器上，缓解了单台数据库所承担的压力。为了保证数据库的高可用性和读写分离，我们在前面准备了2套双主双从的

2024-03-04 09:32:46 1159 24

原创第104讲：数据库分库分表的意义与实现策略（MyCat）

水平分库是按照一定的策略以字段作为依据，将一个表的数据拆分到多张表中，缓解单表的压力，拆分出来的多张表只是名字不同，表数据都相同，用户的读写操作会被路由到其中一个分表中，拆分出来的所有表的数据量加起来才是完整的数据量。水平分库是按照一定的策略以字段作为依据，将一个库的所有表拆分到多个库中，每个库中的表结构都是相同的，只是数据量不同，用户的读写操作会被路由到某一个分库中，缓解单库的压力，水平分库后，所有库的数据量才是完整的数据量。垂直分库指的是将一个库中的多个表，拆分到不同的库中，这就是垂直分库。

2024-02-29 09:28:15 1738 22

原创第103讲：配置Mycat的Schema逻辑库列表

首先添加多个Schema，一个Schema看不出来效果，然后配置Mycat显示那些Schema。1）定义多个Schema

2024-02-28 09:33:48 518 8

原创第102讲：MySQL多实例与Mycat分布式读写分离的架构实践

logs目录:wrapper.log #mycat启动日志 mycat.log #mycat详细工作日志 conf目录:schema.xml #主配置文件（读写分离、高可用、分布式策略定制、节点控制） server.xml #mycat软件本身相关的配置 rule.xml #分片规则配置文件,记录分片规则列表、使用方法等定义一个逻辑库，一般都和真实的数据库库名保持一致，在配置文件中定义了几个schema逻辑库，通过mycat连接之后就只能看见定义的这些逻辑库，其他未定义的数据库将看不到。

2024-02-26 09:21:12 2538 29

原创第101讲：Mycat分布式数据库代理系统的核心概念以及部署

Mycat是开源的、活跃的、基于JAVA语言编写的MySQL数据库中间件，可以把它看做是一个代理程序，开发人员可以像使用MySQL一样来使用Mycat，连接上Mycat就可以操作管理的数据库，无需知道底层到底有哪些数据库，每一台数据库都做了怎样的配置。Mycat是一个开源的分布式数据库系统，在企业环境中，只要涉及分布式的数据库架构，大多数都会采用Mycat去实现，Mycat的核心功能有读写分离、分库分表等等。

2024-02-23 09:29:59 1054 14

原创第100讲：MHA+Atlas实现MySQL主从复制读写分离分布式集群

Atlas是由 Qihoo 360, Web平台部基础架构团队开发维护的一个基于MySQL协议的数据中间层项目。它是在mysql-proxy 0.8.2版本的基础上，对其进行了优化，增加了一些新的功能特性。Atlas是一个位于应用程序与MySQL之间中间件。在后端DB看来，Atlas相当于连接它的客户端，在前端应用看来，Atlas相当于一个DB。Atlas作为服务端与应用程序通讯，它实现了MySQL的客户端和服务端协议，同时作为客户端与MySQL通讯。

2024-02-21 09:47:27 1570 22

原创第99讲：MHA高可用集群配置实战：邮件告警和Binlog服务器搭建详解

在高可用环境中，如果主库故障宕机，从库们无法SSH到主库，如果主从延时较大，可能就会导致数据丢失，因为从库被选举为新的主库后，会获取新主库与故障主库差异的Binlog日志，如果SSH无法连接，此时差异的Binlog就无法获取，就会导致数据丢失。因此我们可以搭建一个Binlog服务器，专门实时同步主库产生的Binlog日志文件，当主库故障宕机后，MHA直接从Binlog服务器中读取主库的Binlog日志。因此下面我们来配置当MHA故障切换完成后，就发送一个邮件告警，通知我们去维护MHA。

2024-02-20 09:12:26 973 15

原创第98讲：MHA高可用集群VIP地址配置与漂移实践

当主库发生故障，从库切换成主库后，程序是无感知的，程序并不知道谁成为了主库，程序还是会连接曾经的主库，就会导致平台访问异常，因此我们需要准备一个VIP漂移地址，当主库故障后，VIP就漂移到新的主库上，保证平台的高可用。第一次配置VIP地址，需要现在主库对应的网卡上配置好VIP地址，否则当故障出现时，VIP地址不能漂移到新的主库，并且还会报错，因为脚本要先删掉主库中的VIP，然后在新的主库上添加，如果一开始就不存在，肯定会报错。目前mysql-3成为了主库，VIP也漂移到了mysql-3的服务器中。

2024-02-18 10:09:23 934 29

原创第97讲：MHA高可用集群模拟主库故障以及修复过程

我们并没有在MHA中配置强制主库的参数，因此第一个算法不会生效，根据所有从库的信息来看，和主库的数据是一模一样的，不存在数据差异，因此第二个算法也不会生效，而在MHA的配置文件中，是根据主从从节点的顺序来书写的，mysql-1、mysql-2、mysql-3，根据第三个算法，那么当主库故障后，mysql-2这个节点的从库会提升为主库。mysql-2中的从库已经成为新的主库了，当查看slave的状态时，没有任何输出，就表示它是主库。故障的主库已经成功的修复完成，并且已经成为mysql-2新主库的从库。

2024-02-05 09:40:17 1100 16

原创第96讲：MySQL高可用集群MHA的核心概念以及集群搭建

MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton（现就职于Facebook公司）开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。

2024-02-02 10:01:26 1968 22

原创第95讲：MySQL主从复制半同步复制与传统复制的区别

半同步复制模式下，当从库的I/O线程接收到主库传来的Binlog日志后，写入到TCP/IP缓存区后，不会立即给主库的Dump线程返回ACK，而是要通过ack_sed插件监控，当传来的Binlog真正写入到Relaylog落盘之后，由ack_sed插件给主库的Dump线程发送一个ACK确认信息，主库的acl_receiver只有收到从库发来的ACK确认信息，才会进行新事物的提交工作。相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。

2024-02-02 09:58:05 366 1

原创第94讲：MySQL主从复制过滤复制的概念以及使用

在MySQL主从复制集群中，既可以对全库进行主从复制，也可以对数据库实例中的某个数据库进行主从复制，对单个库进行主从复制的场景我们称为过滤复制，只对指定的库实现主从复制机制。在db_1数据库中创建一个表，写入数据，验证是否会被复制到从库。过滤复制可以在主库层面实现，也可以在从库层面实现。db_1数据库只要有操作就会被复制到从库。再创建一个db_5数据库观察是否会同步。此时只会复制db_1数据库产生的操作。db_5数据库不会被复制过去。在从库的配置文件里操作。只复制db_1数据库。

2024-01-31 09:37:06 495 14

原创第93讲：MySQL主从复制集群延时从库的核心概念以及使用

在还有277秒就要将主库操作同步到从库时，我们发现了主库的误操作行为，为了防止将从库的数据也误删除，我们决定先停止掉从库的SQL线程，然后通过从库延时还未执行的主库传来的Binlog日志，恢复主库误删除的数据。延时从库指的是经过一段时间后，再执行主库传输的Binlog，主库传输的Binlog会写入到Relaylog中，我们要截取主库误删除操作之前的Binlog，通过Binlog去还原主库误删除的数据。在主库中执行下面的SQL，创建一个数据库，创建一个表，写入几条数据，然后删除数据库。

2024-01-29 09:59:52 1546 23

原创第92讲：MySQL主从复制集群故障排查思路汇总

主库重新生成了新的Binlog日志，并且也产生了数据，我们不好确定从库故障时，主库的Binlog位置号，因此我们直接从154号开始同步，一定是最全的数据，重新配置主从同步信息，Binlog指对之后，从库的I/O状态正常。I/O状态目前处于No的状态，我们已经知道原因了，就是从库要请求主库的Binlog日志不对，我们调整一下请求的Binlog日志，然后指定Binlog标识位号为从库I/O线程故障时的标识位号，保证主从的数据同步。二进制日志，没有从库要请求的日志，因此I/O会报错。二进制日志，但是主库只有。

2024-01-24 09:26:46 1348 8