《高可用数据库平台架构及日常管理经验介绍整理ppt.ppt》由会员分享，可在线阅读，更多相关《高可用数据库平台架构及日常管理经验介绍整理ppt.ppt（19页珍藏版）》请在三一文库上搜索。
1、高可用数据库平台架构 及日常管理经验介绍,研发中心 邵宗文 ,传统基础设施平台 无法解决拥堵问题，不适合繁华地区。,高可用的基础设施平台,为何需要搭建数据库平台,各大部门自己申请数据库服务器，运维成本过高。 操作系统，数据库版本不一。 出现突发热点，造成数据库读写访问巨增，受限于部门数据库资源机器，而错失扩大业务良机。 缺乏统一的数据库服务器性能监控和报警。 新项目产品上线数量过多，单个部门的数据库资源无法满足。 无专门的人进行全局数据库各种读写操作统计的分析。 存在磁盘故障导致不可访问，无自动切换的问题。,目前新浪数据库平台现状,多个IDC数据中心 Mysql5.0 数据库服务几百台.(不断
2、增长中) 约有几百T的数据量.（线上+备份存档） 约有几百个项目产品使用。 平台重点产品有：财经，体育，统一通行证，无线wap，读书，音乐，空间, 通用投票，博客圈，博客杂志，汽车，科技，发布系统等。,不可避免的故障,数据库网络结构简图,数据库平台的其他好处：,提升全球扩展性，包括新浪香港和北美等都能共享到重要数据资源，如体育，财经数据。 让用户访问就近IDC，提升服务质量。 很多刚开始的项目可以混用同一个服务器资源。,关于一些数据库日常管理的经验介绍,如何去了解应用项目的数据库使用情况？ 大项目的有效切分方式？ 一个库下多少表比较合适？ 长期运行的数据库，如何避免表性能下降？ 减少慢查询语句
3、的方法有哪些？ 数据库服务器负载急剧上升的主要原因？,不要超过自身运输能力,数据库应用项目规划和优化原则,1. 了解自己的应用 应用类型 读多写少（如体育，读书），读写比例差不多（如音乐），和写多读少（如投票，统计） 预计数据量 半年？一年？后续扩展？ 决定单表还是多表，扩展的方法(hash分表) 预计访问量 多少读？多少写？峰值？ Com_select,Com_update(insert,delete) 实时数据和非实时数据 哪些必须实时查询？哪些可以预先准备或可以cache？哪些用于统计汇总？ 时间的要求 实时性高的项目，如财经，体育，实时性低的项目如博客圈等。,合理分配调度，实现全球快速
4、到达。,2.如何对大应用项目切分,保证数据库单个实例尽量不要超过150G。 切分尽量多的小实例，一个机器跑7-8个实例，平常load avg不超过1-2，峰值不超过6-7为合理。 分表原则的选择 按时间(财经) 按ID号hash分(统一通行证) 按业务项目(通用投票),3. 单库表数量的限制 - 为什么？ - 受文件系统操作限制，文件数过大需要更多文件句柄，且大目录 操作造成复制、压缩、备份效率低。 - 打开表占用数据库资源（table_cache） 建议一个库不应超过300-400个表 建议一般带char字段的表不应超过500万rows.基于数字的字段为主的表不要超过1000万rows.,4
5、.表的优化,正确使用索引，避免全表搜索 使用定长表,且定期做OPTIMIZE TABLE命令（注意这个命令会锁表，请在数据库访问小的时候做） 在对大表进行添加索引，一定要选择访问小的时间段做，否则会导致严重问题。 注:一般临晨2-3点时候是大部分项目访问的低谷。,5.索引优化、选择和试验,稳妥地改进 将需要优化的相关表复制到测试环境 在测试环境启动一个测试daemon，关闭query cache或是使用select SQL_NO_CACHE 方式。 未优化时测试若干次查询时间，以及explain检查扫描集。 选择合适的索引试验建立。可以通过use index(xx)来强制使用。检查是否有效。 测试查询时间变化，反复试验得到最优结果 保持关注，根据情况随时改变索引设置,6.关于排序的问题,尽量使用带主键的字段做order by 的排序 尽量不要多提供页面的查找（最好只提供100页内），避免机器爬虫抓取数据，导致数据库压力负载过高。因为做order by field1 limit xxxxxx,20是非常消耗数据库资源。,结语,“结合实际情况不断优化” “让数据库多做它擅长的工作” 谢谢参与！ 问题和讨论,