首页
技术小册
AIGC
面试刷题
技术文章
MAGENTO
云计算
视频课程
源码下载
PDF书籍
「涨薪秘籍」
登录
注册
01 | 基础架构:一条SQL查询语句是如何执行的?
02 | 日志系统:一条SQL更新语句是如何执行的?
03 | 事务隔离:为什么你改了我还看不见?
04 | 深入浅出索引(上)
05 | 深入浅出索引(下)
06 | 全局锁和表锁 :给表加个字段怎么有这么多阻碍?
07 | 行锁功过:怎么减少行锁对性能的影响?
08 | 事务到底是隔离的还是不隔离的?
09 | 普通索引和唯一索引,应该怎么选择?
10 | MySQL为什么有时候会选错索引?
11 | 怎么给字符串字段加索引?
12 | 为什么我的MySQL会“抖”一下?
13 | 为什么表数据删掉一半,表文件大小不变?
14 | count(*)这么慢,我该怎么办?
15 | 答疑文章(一):日志和索引相关问题
16 | “order by”是怎么工作的?
17 | 如何正确地显示随机消息?
18 | 为什么这些SQL语句逻辑相同,性能却差异巨大?
19 | 为什么我只查一行的语句,也执行这么慢?
20 | 幻读是什么,幻读有什么问题?
21 | 为什么我只改一行的语句,锁这么多?
22 | MySQL有哪些“饮鸩止渴”提高性能的方法?
23 | MySQL是怎么保证数据不丢的?
24 | MySQL是怎么保证主备一致的?
25 | MySQL是怎么保证高可用的?
26 | 备库为什么会延迟好几个小时?
27 | 主库出问题了,从库怎么办?
28 | 读写分离有哪些坑?
29 | 如何判断一个数据库是不是出问题了?
30 | 答疑文章(二):用动态的观点看加锁
31 | 误删数据后除了跑路,还能怎么办?
32 | 为什么还有kill不掉的语句?
33 | 我查这么多数据,会不会把数据库内存打爆?
34 | 到底可不可以使用join?
35 | join语句怎么优化?
36 | 为什么临时表可以重名?
37 | 什么时候会使用内部临时表?
38 | 都说InnoDB好,那还要不要使用Memory引擎?
39 | 自增主键为什么不是连续的?
40 | insert语句的锁为什么这么多?
41 | 怎么最快地复制一张表?
42 | grant之后要跟着flush privileges吗?
43 | 要不要使用分区表?
44 | 答疑文章(三):说一说这些好问题
45 | 自增id用完怎么办?
当前位置:
首页>>
技术小册>>
MySQL 实战 45 讲
小册名称:MySQL 实战 45 讲
### 27 | 主库出问题了,从库怎么办? 在数据库管理系统中,尤其是在使用MySQL这类关系型数据库进行高可用性和数据冗余设计时,主从复制架构是极其常见的选择。这种架构通过将一个数据库实例(主库)的数据实时或异步地复制到一个或多个数据库实例(从库)上,以实现数据的备份、读写分离、负载均衡等目的。然而,当主库遭遇故障或问题时,如何确保业务的连续性和数据的一致性,便成为了数据库管理员和开发者需要面对的重要课题。本章将深入探讨当主库出现问题时,从库应如何应对及后续的处理策略。 #### 一、主库故障的常见类型 在讨论从库如何应对之前,首先需了解主库可能遇到的几类常见故障: 1. **硬件故障**:如硬盘损坏、服务器宕机等。 2. **软件故障**:操作系统崩溃、MySQL服务异常终止等。 3. **网络问题**:主从库之间的网络连接中断,导致复制中断。 4. **配置错误**:复制配置不当,如binlog未开启、复制用户权限不足等。 5. **数据不一致**:由于某种原因(如跳过了某些事务的复制)导致主从数据不一致。 #### 二、从库的即时响应措施 一旦检测到主库出现问题,从库虽不能直接修复主库的问题,但可以采取一系列措施来减轻影响,并为后续的恢复工作做准备: 1. **监控与报警**: - 确保监控系统能够及时发现主库故障,并触发报警机制。 - 报警信息应包括故障类型、影响范围及初步判断原因。 2. **停止数据写入**(如果适用): - 如果应用支持读写分离,且业务允许,可暂时停止向从库写入数据,避免数据进一步混乱。 - 注意,这一操作需谨慎,因为停止写入可能会影响业务功能。 3. **保持从库状态**: - 确保从库正常运行,不因主库故障而中断服务(特别是如果从库承担读请求)。 - 检查并调整从库的复制状态,确保在问题解决前,复制不会进一步出错。 4. **数据一致性校验**(可选): - 如果条件允许,可以在从库之间进行数据一致性校验,确认从库间数据是否一致。 - 使用如`pt-table-checksum`等工具可以帮助完成这一过程。 #### 三、主库恢复策略 主库的恢复是解决问题的核心,根据故障类型的不同,恢复策略也有所不同: 1. **硬件故障**: - 更换损坏的硬件部件,如硬盘、服务器等。 - 恢复系统后,需重新配置MySQL服务,并尝试从备份中恢复数据。 2. **软件故障**: - 重启MySQL服务,检查日志文件确定具体原因。 - 根据错误日志修复配置错误或软件缺陷。 3. **网络问题**: - 检查网络连接,确保主从库之间的网络通畅。 - 如果网络问题复杂,可能需要联系网络管理员协助解决。 4. **配置错误**: - 仔细检查复制配置,确保所有必要的参数都已正确设置。 - 重启复制线程,观察是否能正常同步数据。 5. **数据不一致**: - 使用MySQL的`CHANGE MASTER TO`命令重新定位复制起点,跳过错误的事务。 - 如果数据丢失严重,可能需要考虑使用备份文件进行恢复。 #### 四、从库接管策略 在某些情况下,如果主库无法快速恢复,或者恢复成本过高,可能需要将从库提升为主库来继续提供服务: 1. **选择最佳从库**: - 评估各从库的数据一致性、性能及负载情况,选择最合适的从库进行提升。 - 确保该从库的数据完整性和一致性达到要求。 2. **执行提升操作**: - 停止该从库的复制进程。 - 修改其配置,使其不再作为从库。 - 更新应用配置,将新的主库地址更新到所有依赖该数据库的应用中。 3. **重新配置从库**: - 将其他从库重新配置为指向新的主库进行复制。 - 确保复制过程正常,数据能够持续同步。 4. **数据校验**: - 在完成提升和重新配置后,进行全面的数据校验,确保数据的一致性和完整性。 #### 五、后续处理与预防 1. **故障复盘**: - 组织团队对故障进行复盘,分析故障原因,总结经验教训。 - 编写故障报告,记录故障处理过程和解决方案。 2. **优化复制配置**: - 根据故障处理过程中发现的问题,优化复制配置,提高系统的稳定性和可靠性。 3. **备份与恢复演练**: - 定期进行数据库备份和恢复演练,确保在真实故障发生时能够快速恢复数据。 4. **高可用架构设计**: - 考虑引入更高级的高可用架构,如MySQL Group Replication、ProxySQL等,以增强系统的容错能力和自动恢复能力。 5. **监控与报警系统优化**: - 持续优化监控与报警系统,确保能够及时发现并响应各种潜在问题。 总之,当MySQL主库出现问题时,从库的角色虽以辅助为主,但通过及时响应、数据校验、合理提升及后续优化,可以有效减轻主库故障对业务的影响,保障数据的完整性和服务的连续性。同时,通过持续的优化和演练,可以不断提升系统的稳定性和应对突发情况的能力。
上一篇:
26 | 备库为什么会延迟好几个小时?
下一篇:
28 | 读写分离有哪些坑?
该分类下的相关小册推荐:
细说MySQL(零基础到高级应用)
MySQL从入门到精通(一)
MySQL必会核心问题
SQL零基础到熟练应用(增删改查)
MySQL从入门到精通(三)
MySQL从入门到精通(四)
MySQL从入门到精通(二)
MySQL从入门到精通(五)
MySQL8.0入门与实践