业务架构演进过程中异构数据库的高效运维探索实践 - 赖坤炽

赖 坤 炽 广 东 移 动 数 据 库 运 维 专 家 中国移动IT运维专家、卓越工程师。深度参与广东移动的IT数智化转型和数据库国产化改造，拥有丰富的数据库运维经验。 数据库的发展现状及面临挑战 目录 广东移动数据库运维体系探索 异构数据库运维未来演进展望 数据库的发展现状及面临挑战 破局：广东移动数据库运维，如何转型提升效能？ 广东移动数据库运维体系探索 02 流程篇--流程优化，规范运维为尺工具篇--工具赋能，效能提升为要服务篇--服务全面，业务连续为根组织篇--组织建设，专业技能为核 流程篇--标准化运维，织就安全防护网 痛点：异构数据库管理复杂、运维操作多样、技术特征独有、不同角色协作不畅、知识难以传承 思路：统一制定数据库转维标准、开发与设计规范、运维规范、应急预案成效：织就"四位一体"的数据库标准运维安全防护网，形成一个规范指导实践、实践优化规范的良性循环 基于商业和开源数据库的丰富运维实践， 沉淀出一套规范高效的数据库运维标准规范。 运维规范 应急预案 广东移动ORACLE数据库故障应急操作手册广东移动MYSQL数据库故障应急操作手册广东移动OceanBase数据库故障应急操作手册广东移动GoldenDB数据库故障应急操作手册 广东移动ORACLE数据库日常运维规范及操作手册广东移动MYSQL数据库日常运维规范及操作手册广东移动OceanBase数据库日常运维规范及操作手册广东公司OceanBase数据库巡检操作手册广东公司OceanBase数据库监控对接手册广东移动GoldenDB数据库日常运维规范及操作手册广东公司GoldenDB数据库巡检操作手册广东公司GoldenDB数据库监控对接手册 开发与设计规范 转维标准 广东移动MYSQL数据库参数最佳实践广东移动OceanBase数据库转维交接文档广东移动OceanBase数据库参数最佳实践广东移动GoldenDB数据库转维交接文档广东移动GoldenDB数据库参数最佳实践 流程篇--集中化运维，夯实全局数据底座 痛点：异构数据库监控指标不一、跨平台操作繁琐、配置管理复杂。 思路：通过JDBC非侵入式地在同一平台接入多种类型和版本的数据库，实现了异构数据库的集中化管理，提供统一的操作界面和管理流程。成效：配置了超过150个告警指标，覆盖了600多套业务支撑系统，达到了对所有异构数据库的集中化“监控、管理、控制”。 数据库运行状态相关指标 故障发生高度相关指标 工程变更重点关注指标 流程篇--白屏化运维，提升故障处理效率 故障分级机制 快速响应流程 标准化故障处理流程 •制定统一的故障处理步骤并固化到平台上•建立故障处理checklist•故障处理白屏化操作，实现实时跟踪和留痕 •全面的事后复盘机制•实施故障预测和预防措施•不断优化故障处理流程和工具 •建立清晰的故障等级定义•根据业务影响和紧急程度分类•制定不同级别的响应时间标准•建立跨团队协作流程•明确各角色职责和权限 •通过平台实现7*24监控和告警•实施自动化初步诊断•通过各项指标快速确认故障影响范围•建立快速升级机制 广东移动数据库运维体系探索 02 流程篇--流程优化，规范运维为尺工具篇--工具赋能，效能提升为要服务篇--服务全面，业务连续为根组织篇--组织建设，专业技能为核 工具篇--工具赋能，效能提升为要 痛点：运维工作存在重复性劳动、人为错误、效率低下和资源分配不均等痛点思路：将日常工作和常见问题交由平台高效处理实现复杂工作简单化、例行工作自动化成效：形成14个通用运维场景，20+个定制运维场景，日常高频操作覆盖率60%以上 故障处理手段 日常变更工作 全面梳理运维场景,聚焦核心痛点 提炼关键要素,构建标准规范 匹配能力模型,设计自动化方案 整合贯通,实现端到端自动化 工具篇--统一深度巡检，及时发现隐患问题 痛点：异构数据库巡检平台不同、巡检模板不同，如何减少跨节点跨类型数据库巡检，实现快速一键巡检？ 思路：根据各数据库特点，定制化巡检模板 •Oracle数据库巡检模板•资源配置状态（RAC集群组件状态、参数配置等）•实例资源监控(CPU、内存、I/O等)•数据库对象监控(表空间、索引、锁等)•数据库性能分析（告警日志、等待事件、高消耗SQL等）... •OB数据库巡检模板 •资源配置状态（OB、OBPROXY集群状态、参数配置等）•集群拓扑和资源监控（CPU、内存、I/O、租户线程等）•数据复制和一致性检查（DML、DDL耗时、事务耗时等）•数据库性能分析（转储、合并、分布式事务响应、XA事务等）... 定期发起巡检任务，输出巡检结果 •GDB数据库巡检模板 •实例状态和性能监控(CPU、内存、I/O等)•备份和主备同步检查（主从状态、同步延迟等）•数据库性能分析（关键报错、锁等待数、响应时长等）... 针对不同数据库选择不同的关键指标和权重设置，模板可配置、可扩展。 工具篇--实例性能分析，快速发现性能瓶颈 因各数据库架构差异、性能关键指标不同，我们采用多种指标组合可配置方式，针对性展示数据库各项性能指标，从而可以快速定位问题指标，不需要在后台通过脚本逐个分析，降低运维复杂度。 异构数据库性能指标 GDB关键性能指标 核心性能指标 Oracle关键性能指标 OB关键性能指标 •CPU使用率•内存利用率•I/O吞吐量•网络流量•活动会话数•响应时间 •等待事件•缓存命中率•锁争用数量•高消耗SQL •集群负载均衡•多租户资源隔离•租户线程使用率•XA事务量 •InnoDB缓冲池使用率•查询缓存效率•内存命中率•失败事务量 性能分析思路 工具篇--SQL智能诊断，打磨性能隐患探针 痛点：传统的数据库异常SQL检测和优化过程复杂且耗时，需要依赖专家进行大量的指标对比和人工分析，这不仅效率低下，而且成本高昂。思路：参照原来基于ORACLE建立的SQL智能诊断模型，针对异构OceanBase数据库特性建立新模型，通过实时获取SQL，结合每条SQL历史运行情况及性能特征，及时发现并预警慢SQL，模型结合预测数据与运维经验形成合理的优化方案，为一线运维人员的数据库优化提供指引。成效：已成功接入超过200套Oracle和OceanBase数据库，覆盖了90%以上的生产资源，从发现到优化5分钟内即可完成。 2、智能分析，定位异常 工具篇--数据生命周期管理，精细管理降成本 针对不同数据库数据存储特点，通过建立统一完善的数据生命周期管理体系，有效管控系统整体数据增长，既降低系统运营成本，又满足最终用户的数据需求。 36.4TB 每月数据清理量（以BOSS系统六大区域为例） 需求管理 策略管理 技术管理 •现网数据模型治理，梳理生产系统数据的在线保存周期,进行分区改造等；•新建表必须提供生命周期管理策略；•建立清晰、合理、完整，可操作性强的数据生命周期管理基线和规范。 •建立一个多层次的数据分级存储技术体系；•引入自动化手段，配置定期任务，完成数据自动转储和清理。•建立数据生命周期执行制度，实现数据生命周期管理策略实施的标准化和规范化 •数据库特性需求： ORACLE-无分区数限制、没有启用存储压缩，根据清理策略每月清理分区数据OB：有分区数限制、存储压缩比1:4以上，根据清理策略每月删除过期分区和数据GDB：无分区数限制、没有启用存储压缩，根据清理策略每月删除过期分区和数据MySQL：有分区数限制、没有启用存储压缩，根据清理策略每月删除过期分区和数据 •建立数据生命周期需求管理基线，有效管理各方面数据保留需求。 G O P S全 球 运 维 大 会 暨 研 运 数 智 化 技 术 峰 会2 0 2 4·上 海 站 广东移动数据库运维体系探索 02 流程篇--流程优化，规范运维为尺工具篇--工具赋能，效能提升为要服务篇--服务全面，业务连续为根组织篇--组织建设，专业技能为核 服务篇--服务全面，业务连续为根 针对异构数据库建设过程，我们数据库运维团队始终坚持以业务连续性为根本,提供事前、事中、事后全生命周期数据库服务保障。 以广东移动核心系统数据库ZZKK为例,我们事前从功能、性能、兼容性等多个维度深入评估国产数据库的适用性,事中根据业务特点和国产数据库特性实施规范分区策略,全面质量保障测试，确保迁移过程平稳高效,事后持续监控国产数据库运行状况并开展精准优化,确保了业务系统平稳迁移和高效运行。 服务篇--事前全域测试风险评估 在国产数据库替代过程中,面临适配性风险、成熟度考验和运维模式转变等挑战。为应对这些挑战,我们提出了"运维前移"的测试策略,旨在提前评估国产数据库的适配性和成熟度,并完善相应的运维体系，有效规避系统迁移风险。 产品非功能测试:对标成熟的商业数据库,全面评估国产库在兼容性、性能、事务处理、高可用等关键特性方面的表现,及早发现并解决适配问题,确保系统稳定运行。 运维监控保障测试:超前规划并严格测试监控、告警、备份等运维体系,适配国产库的运维模式,提升系统的可运维性,为日后的稳定运行提供坚实保障。 服务篇--事中分区压降，保障平稳迁移（1/2） OB 3.x最佳实践建议每个节点分区数不超过3万，而BOSS系统江门区域单节点达6万，存在业务处理性能缓慢以及OB副本切主效率慢的高可用风险。因此我们对迁移的用户进行分区清理和压降专项工作，并制定分区规范方案，目标是每个地市分区数压降到2.5万，并根据OB特性初步制定了国产化后的分区规范/建议。 针对OCEANBASE对分区数限制的特性，新增如下注 意事项： 1.版本新需求上线，在线数据使用单表，过程数据使用分区表，上线时需提交数据保留策略和清理策略；2.单表日分区数不大于730，单表月分区数不大于48，分区表建议按照按照清理策略进行管控限制分区数量；3.创建分区表规范建议：•过程数据月增长记录超过百万，并且业务需要频繁访问的表，建议创建成按月分区表•过程数据月增量超过1G，并且业务需要频繁访问的表，建议创建成按月分区表•过程数据日增长记录超过百万或日增量超过5G，建议创建成按日分区表 xx万 当前压降中分区数 服务篇--事中全面质量保障，提升数据库稳定性(2/2) 由于数据库国产化改造的复杂性和风险性,为充分保障数据迁移的一致性、系统安全和业务连续性,我们重点关注了数据质量、系统安全和外围系统对接三大领域。 数据质量方面 •数据涉及从oracle迁移到ob，需要对所有迁移同步数据进行数据量和数据hash值进行对账•OB数据库不支持dblink刷新物化视图，需要通过数据同步工具将省级数据库公共参数同步至节点生产库•为应对割接后的突发故障或性能问题,以及承载剩余未解耦的全省性业务，需要搭建国产库到Oracle库的实时数据回流机制 系统安全方面 •国产化替换后,原有的4A平台安全访问机制不再适用•国产库在用户权限管控、操作审计、日志提取等安全审计能力上与成熟的Oracle库存在差距 外围系统对接 •CRM核心库与众多外围系统存在数据交互,采用了OGG实时同步、DBLink物化视图、JDBC直连等多种方式•国产化后OGG、DBLink等传统同步方式的不再支持 服务篇-事后绑定表组，提升响应性能(1/2) OB上线后，发现性能上与现网Oracle存在一定差距，部分集团考核接口指标无法满足要求。经分析，发现是涉及多表连接的业务SQL需要跨节点分布式事务处理，导致系统及时性无法满足要求。为解决此问题，需对涉及SQL的非分区表进行绑定表组，并根据SQL关联库表运行效果进行绑定和解绑优化调整，以减少跨节点分布式事务，从而提升SQL性能以满足考核接口指标性能。 绑定表组 SQL筛选 绑定节点评估 服务篇--事后持续监控，精准优化业务(2/2) 在对国产库的持续监控过程中，对标现网与ORACLE数据库性能，发现部分接口响应及