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