Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

高可用数据库平台及日常管理经验介绍

468 views

Published on

  • Be the first to comment

  • Be the first to like this

高可用数据库平台及日常管理经验介绍

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

×