喜欢把枯燥的技术文档变成手把手教程不讲空话只讲怎么连、怎么写、怎么优化。数据库选型花了三个月POC 测了五家产品报告写了四十页。选型会上拍板的那一刻所有人都松了一口气。然后呢然后数据库装上了用了默认配置没有监控没有备份策略没有开发规范没有应急预案。三个月后连接数打满、磁盘快满了没人知道、一次误删表花了两天恢复、慢查询把整个系统拖慢——这个时候才想起来数据库不是装上就能跑的。选型只完成了 30%。剩下 70% 是部署、配置、运维、扩展。这部分做不好选型时的所有努力都会打折扣。今天把选型之后的完整落地链路讲清楚。从单机到集群的架构演进、不同负载的参数基线、运维体系搭建、容量规划、团队能力建设。跟着这个流程走一遍新数据库上线不会慌。01 部署架构演进从单机到分布式数据库的部署架构不是一步到位的是随着业务增长逐步演进的。阶段一单机部署应用 → 数据库单机适用阶段项目初期数据量小并发低。怎么做一台服务器装数据库配好基础参数本地磁盘存储数据定期手动备份这个阶段最重要的是把参数配好、备份做好。不要觉得单机随便跑跑就行参数不对单机的性能也会很差。阶段二主备高可用应用 → 主库写 ↓ 流复制 备库只读故障时提升为主适用阶段业务上线运行不能接受长时间停机。怎么做主库处理写入备库通过流复制同步数据主库故障时备库提升为主库自动或手动备库可以承担部分只读查询分担主库压力主备架构的核心是复制延迟控制。同步复制保证数据不丢但影响写入性能异步复制性能好但有丢数据风险。通常核心业务用同步非核心用异步。金仓 KES 的主备部署基于流复制协议同步和异步模式都支持配合自动故障切换组件可以实现秒级切换。在一些金融和政务项目里这是最常用的基础高可用方案。阶段三一主多备 读写分离应用 → 主库写 ↓ 流复制 备库1只读 备库2只读适用阶段读压力增大主库扛不住查询负载。怎么做增加备库数量分散读压力应用层或代理层实现读写分离写入走主库查询按权重分配到备库读写分离的关键是复制延迟监控。如果备库延迟过大读到的是旧数据。需要在应用层处理这个边界情况。阶段四集群/分布式应用 → 代理层 → 数据节点1分片A → 数据节点2分片B → 数据节点3分片C适用阶段单机数据量或并发量到达极限需要横向扩展。怎么做数据分片每个节点只存储一部分数据代理层负责路由和结果汇总写入和读取都可以水平扩展分库分表是最后一步不是第一步。能垂直扩容的先垂直扩容能读写分离的先读写分离扛不住了再分片。02 初始参数配置不同负载的基线数据库装完的默认配置离生产就绪差得远。不同负载类型需要不同的参数基线。OLTP 负载高并发事务核心关注点写入性能、连接数、事务隔离。-- 内存配置以 16GB 服务器为例 shared_buffers 4GB -- 总内存的 25% effective_cache_size 12GB -- 总内存的 75% work_mem 64MB -- 单操作内存注意总并发数 maintenance_work_mem 1GB -- 维护操作内存 -- 连接配置 max_connections 500 -- 按实际需求设不是越大越好 superuser_reserved_connections 5 -- WAL/刷盘配置 wal_level replica synchronous_commit on -- OLTP 建议 on保证数据不丢 checkpoint_completion_target 0.9 wal_buffers 64MB -- 查询优化器 random_page_cost 1.1 -- SSD 环境 effective_io_concurrency 200 -- SSD 环境踩坑提醒work_mem不是全局限制是每个排序/哈希操作的内存上限。如果 max_connections500每个连接同时有 2 个大排序理论最大内存 500 × 2 × 64MB 64GB。所以 work_mem 要结合 max_connections 和实际并发操作数来设。OLAP 负载分析查询核心关注点大查询性能、并行计算、批量读取。-- 内存配置以 32GB 服务器为例 shared_buffers 8GB effective_cache_size 24GB work_mem 256MB -- OLAP 可以设大一些 maintenance_work_mem 2GB -- 并行查询 max_parallel_workers_per_gather 4 max_parallel_workers 8 max_parallel_maintenance_workers 4 -- 查询优化器 random_page_cost 1.1 effective_io_concurrency 200混合负载OLTP OLAP 混合的场景参数需要折中。更好的做法是主库跑 OLTP备库跑 OLAP通过流复制保持数据同步。金仓 KES 在这类场景下支持动态内存调整不需要重启数据库就能修改大部分内存参数。这在做负载切换的时候比较方便——比如白天 OLTP 为主、夜间跑分析报表时动态调大 work_mem 和并行度。03 运维体系搭建备份、监控、告警运维体系不是出了问题再补的事是上线前就该搭好的。备份策略三层备份层级方式频率恢复粒度恢复时间全量备份pg_basebackup / 物理备份每周一次整个数据库小时级增量备份WAL 归档持续按时间点小时级逻辑备份pg_dump / 逻辑导出每天一次单表/单 schema分钟级三层备份缺一不可。全量备份兜底增量备份支持时间点恢复逻辑备份用于单表误删的快速恢复。监控体系核心监控指标维度指标告警阈值可用性数据库进程状态进程异常立即告警连接当前连接数 / 最大连接数 70% 告警磁盘数据目录使用率 80% 预警 90% 紧急复制主备延迟秒 10 秒告警性能慢查询数量每分钟 10 条告警资源CPU、内存、I/O 利用率CPU 持续 80% 告警告警通道紧急告警数据库不可用、磁盘满短信 电话重要告警连接数超限、复制延迟大钉钉/企微预警磁盘 80%、慢查询增多邮件 工单告警不能只报磁盘 85% 了要报磁盘 85%按当前增长率 15 天后满建议本周内扩容。带预测的告警才有行动价值。金仓 KES 配合 KEMCC 统一管控平台可以把监控、告警、巡检集中到一个界面管理。对于有多套数据库实例的场景集中管控比逐台登录查状态效率高很多。日常巡检可以自动化出报告不用人工逐台检查。04 容量规划按增长率预测提前扩容容量规划的核心不是查磁盘用了多少是预测还能撑多久。记录趋势每天固定时间记录以下数据连续 30 天数据库大小当前连接数 / 历史最大连接数缓存命中率CPU 利用率日均、峰值算增长率日均增长量 (当前大小 - 30 天前大小) / 30 剩余天数 (磁盘总容量 × 80% - 当前已用) / 日均增长量注意用 80% 算不是 100%。到了 80% 就该告警了不能等到 100%。提前规划剩余天数行动 30 天紧急扩容30-60 天启动扩容流程60-90 天评估扩容方案 90 天持续关注容量瓶颈也不只是磁盘。连接数打满、内存不够、CPU 持续高位——这些都需要持续监控和趋势分析。05 团队能力建设人比工具重要数据库出问题最后是人来解决。团队能力跟不上再好的工具和架构都没用。开发规范给开发团队定几条硬规矩SQL 上线前必须过执行计划。不加索引的 SQL 不能上线。禁止在生产库做 DDL。改表结构走变更流程先在测试库验证。禁止全表扫描查询。WHERE 条件必须有索引。禁止 N1 查询。一次能查完的不要循环查。连接用完必须释放。连接泄漏是最隐蔽的性能杀手。DBA 手册至少要有以下内容日常巡检清单每天/每周/每月做什么备份恢复流程怎么恢复单表、怎么恢复整个库故障排查流程慢查询怎么定位、连接打满怎么处理、锁冲突怎么解应急预案主库故障怎么切换、磁盘满怎么处理应急预案每个场景都要有书面预案不能只存在某个人脑子里场景预案要点主库宕机备库提升步骤、连接切换方式、回退条件磁盘满紧急清理路径、临时扩容方式、根因排查流程连接打满定位异常连接、kill 策略、连接池调整误删数据时间点恢复步骤、逻辑备份恢复流程复制中断断点定位、重建复制流程对比不同阶段的数据库能力需求阶段架构运维重点团队要求工具需求初期单机单机部署参数配置、备份1 人兼管基础监控成长期主备主备高可用复制监控、切换演练1-2 人专职监控告警 备份自动化扩展期读写分离一主多备负载分配、延迟控制2-3 人专职读写分离代理 性能分析成熟期集群分布式集群分片管理、容量规划专职 DBA 团队统一管控平台 自动化运维决策框架按团队规模和业务阶段选择投入重点团队规模业务阶段投入重点可以暂时不做的事1 人兼管项目上线初期参数配置 备份 基础监控自动化运维、统一管控平台1-2 人业务稳定运行主备高可用 监控告警 开发规范分布式集群、精细化容量规划2-3 人业务快速增长读写分离 容量规划 应急预案分库分表专职 DBA 团队核心业务集群部署 全链路监控 性能基线 自动化—核心原则投入匹配阶段。不要在单机阶段搞分库分表也不要在集群阶段还靠人工巡检。深度分析为什么选型之后总是用不好很多团队数据库用不好的根本原因是选型和落地是两拨人。选型的人做完 POC、出了报告、开了评审会项目移交运维团队。运维团队拿到的是一个可以跑的数据库但不是生产就绪的数据库——参数是默认的、没有监控、没有备份策略、没有开发规范。这种断档导致选型的成果无法落地。选型时的要求性能指标、高可用能力、兼容性承诺在落地阶段被稀释了。解决这个问题的方法只有一个选型和落地是同一个团队负责到底。选型的人要参与部署、参与参数调优、参与监控搭建。只有把选型报告里的承诺变成生产环境的实际配置选型才算真正完成。总结数据库选型之后的落地链路部署架构从单机逐步演进到集群参数按负载类型配基线运维体系上线前就搭好容量规划看趋势不看单点团队能力是最终保障。选型只完成 30%剩下 70% 在落地。部署、配置、运维、扩容、团队——每一个环节都是用到位的一部分。选型的时候看的是能不能落地的时候看的是好不好。能把能不能变成好不好的团队数据库这块才算真正过关。后续我会继续分享数据库运维实战、性能调优这些话题跟着我一篇篇学数据库这块就没问题了。有问题评论区见。喜欢把枯燥的技术文档变成手把手教程。关注我数据库这块我们一起搞定。