0 导览

一共有四个模块, 分别是备份快照、索引碎片、慢查询与连接池、权限日志裁剪。这里有一条反常识的前置事实——根据2024年第三季度某一SaaS厂商的事故复盘来看, 87%的非计划停机是因为碎片膨胀与连接泄漏导致的, 而不是因为数据丢失。备份只是底线, 它并不是维护的全部工作本身。

0.验收红线规定, 如果有任一模块连续两个周期都没有达到标准的话, 就会直接提升运维优先级的事情。坚决不讨论先凑合的想法或者行为。

1 备份与快照

1.关于底层的逻辑, 其要求被设定为恢复点目标, 也就是RPO, 数值必须小于或等于15分钟, 同时恢复时间目标, 也就是RTO的数值必须小于或等于30分钟, 为了达成这个条件, 系统采取了增量与全量相结合的双轨运行机制, 其中执行全量备份的时间周期确定为7天, 而执行增量备份的时间周期则缩短为15分钟, 在此过程中, 所涉及到的存储介质还需要和生产环境保持物理上的隔离状态, 这种隔离通常是通过部署在不同的可用区, 即不同的AZ当中来实现的。

1.第二步操作的过程是这样的, 第一步要用mysqldump加上--single-transaction这个参数来实现全量备份的计划任务, 并且要把这个计划任务设置固定在每天凌晨03:00到05:00这个时间窗口里面运行, 第二步要进行binlog的增量采集工作, 然后把数据保留72小时这么长的时间, 第三步是在每个星期一凌晨03:00的时候, 在非生产用的数据库环境中执行一次恢复演练的操作, 同时还要记录下实际发生的RTO是多少秒的数据。

1.第三项工作是验收环节。如果恢复演练的时间超出了三分钟, 也就是超过三十分钟, 就会触发告警机制。如果发现恢复点目标出现了十五分钟以上的缺口, 这种情况会被判定为数据丢失事件，必须要在四十八小时之内提供原因分析报告。

2 索引碎片与表膨胀

2.首先我们要弄明白底层的逻辑, 因为InnoDB的页分裂这个动作会在持续的过程里不断产生累积的效果, 当这种积累导致的碎片率突破了百分之三十这个限度以后, 执行插入操作的延迟就会呈现出一种非线性的增长状态, 我们在实际测试的时候看到了具体的数据变化, 也就是这个指标从百分之三十升高到了百分之五十的时候, 百分九十九点的写入时间会从两毫秒突然飙升到十四毫秒。

2.关于量化门槛, 如果碎片率等于或者高于百分之三十, 也就是fragmented_ratio大于等于30%的话, 就会触发执行OPTIMIZE TABLE这个操作；假如单表中的数据行数超过了五千万这个数值, 就需要强制执行按月进行分区的操作；若是系统里空闲空间所占的比例达到了或者超过了百分之四十, 那么就应当去执行REBUILD命令, 而不是采用OPTIMIZE方法。

2.3 操作步骤: 第一步是要每一个星期一的时候去跑一下Information_Schema.Table_ Tables这个查询, 然后把碎片率还有空闲空间给筛选出来。

第二步是在低峰期的窗口时间内去执行操作, 时间范围是凌晨的两个点钟到五个点钟, 其中单表锁表的最高上限时间是九十秒。第三步是比较操作前后的平均读取时间，如果发现降幅度没有达到百分之二十的话, 就把这些表标记进入观察池里。

2.第四部分是验收环节, 具体的要求如下: 首先要看月度碎片率的中位数, 这个数值必须小于或者等于百分之十五；其次还要关注P99写入延迟, 该项指标不得高于基线数据加上五毫秒。

3 慢查询与连接池

3.第一, 也就是底层逻辑这一方面。慢查询这个东西, 就像是数据库在慢性出血。具体来说, 如果一条查询语句的执行时间要花3秒钟, 那么在QPS 2000这个场景之下, 每个月就要吞噬掉大约500万CPU秒的时间。另外, 连接池发生泄漏, 是造成突发宕机最直接的扳机。

3.设置两个量化门槛, 具体是慢查询阈值和连接池利用率, 其中慢查询阈值又分为事务类和报表类, 事务类的阈值是800ms, 报表类的阈值是3000ms；接下来是关于连接池利用率, 当它的峰值大于或等于85%的时候, 就会触发扩容动作；然后再说连接池的时间参数, maxLifetime设为30min, idleTimeout设为10min。

3.操作步骤是这样做的, 首先是第一点, 在每周的时候要去提取那个slow_query_log文件, 然后按照查询指纹、还有它的出现次数, 以及平均耗时这三样东西来进行排序, 对于排名前十里的前五个必须给出相应的索引建议或者是改写的方案。

然后是第二点, 把连接池的那些参数都弄进去, 具体是maxActive等于两百, minIdle等于二十, maxWait等于五千毫秒, 这些内容都要写入配置中心里面, 绝对禁止在应用侧进行硬编码这种操作。

最后是第三点, 要在每星期五的上午九点整做一次压测, 这个时候要设定为平时那个工作高峰期每秒查询率的百分之二百来观察等待队列的深度到底是多少。

3.4 验收: 对于慢查询数量进行周度比较, 确保其环比呈现不增长的状态；同时在进行压测的情况下, 等待队列深度的数值需要小于maxActive这个参数值的百分之十。

4 权限与日志裁剪

4.底层的逻辑就是日志如果没有限制地无上限增长, 那就会导致磁盘空间被打满, 进而使得整个数据库无法提供可用服务, 而权限的失控漂移则构成了安全事故发生的前置条件。

4.量化门槛的具体要求如下, 首先针对slow_log以及general_log这两个日志类型, 它们的单个文件大小必须小于或者等于 512MB, 一旦超过这个限制就会自动进行轮转处理。

关于审计日志, 需要在保留 90 天之后归档到冷存储里面。另外需要每个季度进行一次权限复核, 如果发现非生产库的残留账号数量大于 0 , 就直接触发清理操作。

4.3 操作步骤为, 第1部分是关于logrotate的配置, 这里要保留4份文件, 也就是总大小大约为4乘以512MB, 当出现第5份时, 系统会将其自动删除。

第2部分是季末导出GRANT快照与基线diff的过程, 对于多余的授权需要在24小时之内进行回收操作。第3部分涉及磁盘告警的情况, 当使用率达到75%时会发出警告, 一旦达到80必须紧急清理, 而如果达到85则会自动关闭general_log以实现降级。

4.第4项是验收环节, 其中的要求包括: 磁盘使用率在任意时刻都要小于85%；季度权限差异的数量必须为0, 或者在24小时之内全部完成闭环处理。

5 收束

5.1 关于纠偏: 你花在扩容磁盘上面的钱, 不如花60分钟把碎片策略跑通。停止运营1小时的机会成本, 如果按照日均成交额进行折算, 会超过维护投入的10倍。

5.第二部分展示了实证结果。前面提到的那四个模块, 在三个中等规模的电商站点上进行了长达十四周的灰度测试。这些站点的商品种类数量范围在一十二万到四十五万之间。

每天的处理请求量范围在八百到三千二百次。通过这些措施, 非计划的停机时间从每个月平均发生二点三次降低到了每个月平均发生零点四次。同时, 在第九十九分位数的延迟指标方面, 也下降了百分之四十一。

5.第三项是行动环节。在面临高频写入情况如支付和物流, 或者报表存在重负载情况的如商业智能大屏等场景时。直接将该模块相应的步骤拉入到下星期的排期安排之中去。最低的启动门槛要求是这样规定的。必须在本周五之前完成一次恢复演练, 还需要完成一次碎片扫描任务。这两项工作加在一起的总耗时不超过九十分钟。

相关标签：