MySQL数据库运维管理规范

MySQL数据库运维管理规范文档编号：OPS-DB-001版本：V1.0适用范围：公司自建及云托管MySQL5.7/8.0数据库实例一、总则1.1编制目的本规范旨在将MySQL数据库的日常运维工作标准化、可追溯化，解决以下三类实际问题：1.职责不清：故障发生后出现「没人改、没人查、没人恢复」的三无状态；2.操作随意：直接在生产库执行变更、跳过审批、无备份回滚方案；3.响应迟缓：故障发生30分钟后才有人发现，超过业务可容忍的恢复时限。本规范适用于所有持有生产库操作权限的DBA、后端开发、运维工程师。1.2术语与分级定义术语定义生产库承载线上业务读写的MySQL实例，含主库与从库核心库故障停机30分钟内直接导致交易/下单/支付中断的生产库变更窗口经审批的业务低峰时段，默认为每日02:00—04:00RTO故障恢复目标时间：核心库30分钟，一般生产库2小时RPO数据丢失容忍量：核心库不超过5分钟，一般生产库不超过30分钟二、组织架构与职责2.1数据库管理小组角色人员配置核心职责DBA负责人1人变更审批、重大故障总指挥、月度运维报告值班DBA2人轮值（每周轮换）日常巡检、告警处置、备份核验应用开发接口人各业务线1人SQL评审、慢查询治理、索引变更提案云资源管理员1人实例开通/销毁、容量扩缩、网络策略值班表由DBA负责人每月25日前编制次月排班，报运维总监备案。值班DBA交接时必须以书面形式（企业微信/邮件）交接未关闭的告警与变更工单，接手人确认后原值班人方可离岗。2.2权限管理•生产库账号按最小权限原则分配：开发人员一律不持有生产库账号，调试需求通过跳板机只读审计账号操作；•超级权限（SUPER、ALLPRIVILEGES）仅限DBA负责人与值班DBA两人持有，密码每90天轮换一次；•所有生产库连接启用skip-name-resolve并限制来源IP至跳板机段，严禁将生产库端口直接暴露至办公网或公网（一旦暴露，攻击者可在数小时内完成拖库，导致用户数据外泄，触发监管处罚与舆情事件）。三、日常运维操作规程3.1每日巡检（值班DBA执行）巡检时间为每日上午10:00前，使用巡检脚本采集以下指标并填写《数据库巡检记录表》（附件一）：巡检项正常区间判定为异常的标准主从延迟Seconds_Behind_Master0∼连续3次采样>60连接数使用率<80%达到90%慢查询数（阈值1秒）日新增<50日新增>200磁盘剩余空间><20备份任务状态全部成功任何一次失败InnoDB缓冲池命中率><巡检发现异常时，10分钟内在工单系统登记，按第四章分级处置；未登记视为漏检，纳入值班考核。3.2备份策略为什么：无备份或备份不可恢复是数据库事故中最致命的一类——磁盘损坏、误删表、勒索加密发生时，唯一退路是备份。备份策略必须同时满足RPO与可验证性两项要求。怎么做：1.全量备份：每日01:30使用XtraBackup物理备份，核心库留存30天，一般生产库留存14天，每周备份同步上传一份至异地对象存储（跨地域）；2.增量备份：每4小时一次基于binlog的增量备份，binlog开启ROW格式与GTID，保留7天；3.备份核验：每月5日前，值班DBA必须完成一次恢复演练——将上月随机一天的备份恢复至临时实例，执行表行数抽检（抽检5张核心业务表）与应用只读登录验证，演练记录归档至工单系统。未经恢复验证的备份不视为有效备份。出问题怎么办：备份任务失败时，当天必须人工补跑；连续2天失败，DBA负责人升级为II级事件（见4.1），排查存储空间、权限、锁冲突原因并出具书面说明。3.3高可用架构要求•核心库采用一主两从+半同步复制（rpl_semi_sync_master_wait_for_slave_count=1），通过MHA或同等方案实现自动故障切换；•从库同时承担只读查询分担，读写分离由应用层中间件路由，严禁业务代码直连主库IP（主库切换后IP变更，直连会导致业务中断，这也是历史上多起「切换成功但业务仍报错」事故的根因）。四、故障与应急管理4.1事件分级与响应级别判定标准响应时限处置权限升级路径I级（严重）核心库不可用、主从复制中断、数据疑似损坏5分钟内响应，30分钟内恢复或给出降级方案DBA负责人现场指挥，可执行任何恢复操作立即电话通知运维总监与业务负责人II级（重要）从库不可用、主从延迟>5分钟、备份连续失败、磁盘15分钟内响应，2小时内处置值班DBA1小时内未解决升级至DBA负责人III级（一般）慢查询激增、单表锁等待、告警抖动30分钟内响应，下一工作日内闭环值班DBA记录工单即可4.2典型故障处置流程场景一：主库宕机1.确认故障真实（ping+从库SHOWSLAVESTATUS观察IO线程状态），排除网络抖动误判——避免因误判触发非必要的强制切换；2.启动MHA自动切换；若切换失败，值班DBA手工执行：选取数据最新的从库（SHOWSLAVESTATUS中Read_Master_Log_Pos最大者），执行RESETSLAVEALL后提升为主库；3.切换完成10分钟内，在值班群通报新主库信息与应用影响范围；4.故障恢复后24小时内出具《故障报告》，含时间线、根因、修复措施与改进项，DBA负责人签字归档。严禁：在未确认主库实际停机的情况下强行对其执行kill-9或拔电——旧主库若仍存活，会造成双主脑裂、binlog分叉，进而导致数据不可逆丢失。场景二：误执行DELETE/UPDATE无WHERE语句1.立即在所有从库执行STOPSLAVE（防止错误语句复制扩散）——这是黄金60秒内最重要的动作；2.若binlog为ROW格式且未超出保留期，使用mysqlbinlog反解析生成反向SQL恢复受影响行；3.反向修复不可行时，使用最近全量+增量binlog恢复至临时实例，导出受影响表后回写主库；4.处置全程需DBA负责人口头确认每一步，事后24小时内复盘并评估是否收紧审批规则。4.3降级预案当主库切换无法在RTO内完成时，按以下顺序降级，保障交易链路优先可用：1.关闭非核心业务对数据库的访问（报表、日志分析类）；2.将读请求全部切回应用本地缓存或只读从库快照；3.写请求若持续失败超过15分钟，业务方启动队列缓冲（订单类写入消息队列，恢复后重放），缓冲上限按队列磁盘容量与重放速度测算，一般不超过2小时数据量。五、变更管理5.1变更审批流程所有生产库结构变更（DDL）与大事务（DML影响行数>100001.申请人提交变更单，附：变更SQL、影响范围评估、回滚方案、预计耗时；2.接口开发人SQL评审（重点：是否锁表、是否全表扫描、索引是否生效）；3.DBA负责人审批，核心库变更需运维总监会签；4.变更在审批通过后的变更窗口内执行，执行前先在预发环境完成同等操作验证。禁止性条款：•严禁在工作时间（09:00—19:00）对超过100万行的表直接执行ALTERTABLE（MySQL5.7大部分DDL仍会锁表或造成主从延迟，将直接拖垮线上读写）→改用pt-online-schema-change或gh-ost在低峰期在线变更；•严禁跳过审批直接在生产库执行DDL——即使变更成功，无回滚方案时任何异常都无退路→任何紧急变更也须至少获得DBA负责人电话+企业微信文字双确认，事后2小时内补录工单。5.2回滚要求每张变更单的回滚方案必须具体到可执行语句或明确的回退手段（如DROP前的表结构备份、gh-ost的原表保留），「出问题再想办法」视为方案缺失，审批环节直接驳回。六、性能与容量管理6.1慢查询治理1.每周一值班DBA从慢查询日志导出上周Top20慢SQL，分派至对应业务接口人；2.接口人5个工作日内给出优化方案（加索引、改写SQL、加缓存），DBA复核后实施；3.单条SQL执行时间超过10秒且日均调用量>100次的，必须当周处理完毕，可通过强制超时参数max_execution_time6.2容量规划•磁盘使用率连续7天增速>2•单表行数估算超过5000万行（按InnoDB每行平均200字节、单表建议数据量上限推算）时，评估分库分表或归档方案；•历史数据归档：超过12个月的日志类、流水类数据迁移至归档库，归档操作每季度集中执行一次，执行前冻结相关表写入30分钟。七、安全与审计1.审计日志：生产库开启全量SQL审计（通过审计插件或数据库代理层），日志保留180天；2.高危操作拦截：跳板机部署SQL上线工具，拦截DROPDATABASE、TRUNCATE无条件、无WHERE的DELETE/UPDATE；3.漏洞修复：MySQL官方发布安全补丁（CVE评级为高危及以上）后，DBA负责人5个工作日内组织评估，30日内完成升级；升级前必须验证备份可用；4.离岗交接：持有生产权限人员离岗当天，由DBA负责人回收全部账号并轮换相关密码。八、考核与持续改进1.每月5日前，DBA负责人出具《月度数据库运维报告》，内容含：可用率（目标核心库≥99.952.每次重大故障（I级）后召开复盘会（48小时内），产出改进项并指定责任人与完成时限，改进项闭环率纳入季度考核；3.本规范每半年评审一次，由DBA负责人牵头，根据故障复盘与架构变化修订条款。附件一：数据库每日巡检记录表（样表）日期巡检人实例名主从延迟(s)连接使用率慢查询新增磁盘剩余备份状态异常描述处置工单号2024-XX-XX张某某order-db-01245%1262%成功（无）（无）2024-XX-XX张某某order-db-028571%3541%失败从库延迟升高，备份空间不足INC-XXXX附件二：数据库应急联络通讯录（样表）角色姓名手机备用联系方式备份人DBA负责人李某某138******企业微信王某某值班DBA（本周）张某某138******企业微信赵某某