MySQL 主从复制

MySQL 主从复制把写入集中到主库，再同步到从库，读请求可以走从库。

核心要点

• 主库写入并生成 binlog
• 从库拉取 binlog 并重放
• 主从需要稳定网络身份

K8s 中的思路

• StatefulSet 保障实例顺序
• Headless Service 提供稳定 DNS
• 读写分离可用两个 Service

风险提示

• 复制延迟会影响读取一致性
• 主库不可用时需要故障切换

实操要点

• 先做快速盘点：kubectl get nodes、kubectl get pods -A、kubectl get events -A。
• 对比“期望状态”和“实际状态”，kubectl describe 往往能解释漂移或失败原因。
• 名称、Label、Selector 要一致，避免 Service 或控制器找不到 Pod。

快速检查清单

• 资源定义与业务意图一致。
• Namespace、权限、镜像与环境匹配。
• 上线前具备健康探针与可观测日志。

数据与身份的稳定性

有状态应用需要稳定身份与稳定存储。MySQL 复制 通过持久卷、稳定 DNS 与有序生命周期提供这种稳定性，目标是在自动调度与数据安全之间取得平衡。

复制拓扑与一致性

复制系统需要明确一致性模型。常见的是主从或多副本仲裁。Kubernetes 只负责调度与生命周期，不负责共识。你需要理解数据库的主从切换与客户端发现方式。

存储规划与隔离

每个副本应独立 PVC，除非应用明确支持共享卷。规划容量时要考虑增长空间，并通过反亲和性将副本分散到不同节点，降低单点故障影响。

备份与恢复习惯

持久卷不等于备份。建议结合快照与逻辑备份，并定期演练恢复。对于复制系统，恢复顺序会影响主从角色，要在文档中明确步骤。

升级与故障处理

有状态升级更慢，需要分批推进。准备好 readiness 探针，避免误判可用性。节点故障时卷重新挂载可能耗时，需监控挂载状态并考虑更长恢复窗口。

可观测与调优

关注复制延迟、磁盘延时与使用率。资源限制过紧会导致抖动，requests 要合理留出余量。数据库场景下 IO 延迟往往比 CPU 更关键。

主从路由与客户端策略

写流量应指向主节点，读流量可通过 Service 分发到从节点。需要直连时使用稳定 DNS 名称，并在客户端配置明确的角色路由。

维护与自动化

定期进行压缩、清理与一致性校验，选择低峰窗口执行。使用 Operator 或自动化任务管理备份、升级与故障恢复，降低人工操作风险。

kubectl get pods -n demo
kubectl get pvc -n demo
kubectl describe pod db-0 -n demo

运维清单

检查反亲和、PDB、备份任务是否到位。确认每个副本都有独立卷，并演练故障切换流程。稳定性来自配置与习惯的共同作用。

实战补充

把快速入门应用到真实业务时，建议固定一套检查项：资源 requests、就绪探针、日志覆盖、告警阈值、回滚步骤。清单要短小、可重复，并随仓库一起维护，这样每次发布都能快速对齐标准。

排障路径

从现象入手，不要先猜原因。先看事件，再看日志，最后验证流量路径和配置版本是否一致。若访问异常，先确认 readiness 和 endpoints，再逐段排查入口到后端的链路。记录每一步改动，方便回滚和复盘。

小练习

在测试环境做几次常见操作：扩缩容、重启单个 Pod、调整一项配置并验证效果。通过这些小练习，你能更直观地感受到系统收敛速度和异常时的行为。

维护与责任

明确服务归属、值班人和升级窗口，准备常见故障的处理步骤。依赖服务也需要纳入监控和备份计划，确保问题出现时能快速定位和恢复。

交付提醒

发布后用用户视角快速验证一次：访问核心接口、观察延迟和错误率，确认新旧 Pod 的状态稳定。如果涉及存储或网络，顺手核对磁盘用量、DNS 和 endpoints 是否正常。

回滚预案

写下最小可行的回滚步骤，包括需要恢复的配置、镜像版本和校验方式。这样在出现异常时可以迅速还原，而不是现场临时拼步骤。

参考链接

• MySQL 复制
• StatefulSet
• Headless Service