MYSQL高可用性案例精讲

1. 系统项目经验 – bbs.55bbs.com
   1.1 项目特点:
       1.1.1 论坛活跃度高 ( 1.5 – 2 贴/秒 );
       1.1.2 在线浏览人数多 ( 1000 万 PV/日、6 万人在线 );
       1.1.3 数据库查询频繁,高并发量 ( 3000+ 次/秒/台 );
       1.1.4 业务要求高可用性,在线生产数据库要求 7 * 24;
   1.2 实施经验:
       1.2.1 在着手进行实施改造之前做大量的前期分析工作,尽量确保收集到准确全面的性能问题点。
             在论坛社区应用领域中,尤其对于大型论坛而言,几乎每个论坛都有自己独特的问题类型;
       1.2.2 使用了大量数据库缓存技术:文件缓存、帖子缓存、memcached 缓存;
       1.2.3 数据库使用分布式部署,将一些耗费资源的功能分布到不同的数据库服务器中,同时保证
             各个数据库服务器中的数据高度一致;
       1.2.4 使用 MySQL 分区技术有效解决数据表体积过大带来的性能降低;
       1.2.5 全面仔细的评估所需的硬件资源,避免造成不必要的硬件成本浪费;

            
2. 实现高可用性的技术途径以及系统性能优化方法

   2.1 硬件资源以及操作系统的准备
       2.1.1 MySQL 是一个存储 I/O 密集型应用;
       2.1.2 充足的内存是保证 MySQL 稳定高性能的重要条件;
       2.1.3 在 MySQL 集群体系的规划中,尽量保证各服务器的硬件配置一致性;
       2.1.4 在 MySQL 集群体系的规划中,尽量使用高速专用网络作为传输介质,降低延时;
       2.1.5 尽量选择 64 位 Unix/Linux 操作系统作为应用平台;

   2.2 MySQL 版本选择
       2.2.1 在保证稳定的前提下尽量选择高版本 MySQL;
       2.2.2 可以选择 ICC 编译器构建的 MySQL 版本,极端情况下可根据需要自行从源代码编译 MySQL;
       2.2.3 避免激进,如果 ChangeLog 中未列出关键性更新,则尽量选择保持现有版本,规避可能存在的风险;

   2.3 应用程序(PHP)对于 MySQL 的优化
       2.3.1 MySQL – 数据存储引擎,明确数据库应用的角色,不要将其作为数据处理运算中心;
       2.3.2 根据需求灵活适当的选择数据表类型(MyISAM、HEAP、InnoDB);
       2.3.3 合理规划数据库结构,以及数据索引;
       2.3.4 尽量不要让 MySQL 处理数据运算操作,运算操作可交由前端程序进行处理;
       2.3.5 评估每一条查询语句的执行效能,尤其是在重负载下可能带来的性能降低(leftjoin 拆分);
       2.3.6 程序设计当中,注重缓存的使用,尽量将需要频繁查询的数据缓存在外部(文件、BDB、Memcached);

   2.4 MySQL 自身优化
       2.4.1 MySQL 应用服务优化的依据不是人云亦云,而是对当前数据库进行长期不断的运行状态分析
             得出的数据,这才是最真实,最准确,最有用的优化依据,要明白为什么优化,优化什么;
       2.4.2 使用 MySQL 状态监测工具以及监控平台对 MySQL 运行状态进行长期监测,一方面发现问题,
             另一方面能够得到宝贵的变化趋势分析;
       2.4.3 经常查看 MySQL 日志,发现隐含的问题,修复数据库、索引,优化数据表;
       2.4.4 数据库体积日益增大的情况下,提早准备好应对方案(分表、分区、归档等等);
       2.4.5 my.cnf 中各个参数的优化,熟读手册,明确各个参数的含义,不要人云亦云(query_cache);
       2.4.6 MySQL 的优化是个不断进行的过程,不存在一劳永逸的优化方案;

   2.5 MySQL 数据安全性保障
       2.5.1 数据库/服务器的损坏是个必然的结果,只是时间问题;
       2.5.2 在数据库建立初期,就要设计并部署好一套优良的备份方案,最大程度保障数据的安全性;
             2.5.2.1 非关键性应用?可以考虑用短暂的停机时间换取安全可靠的备份数据;
             2.5.2.2 关键性应用?可以通过增加设备的方式换取 7 * 24 的运行状态,同时安全的备份数据;
       2.5.3 尽量对数据库备份保留 3 天甚至更长的备份;
       2.5.4 定期验证备份的有效性;
       2.5.5 提前制订当灾难发生时的恢复/回滚策略;

来源:http://www.tbqu.com/post/281.html

发表评论

电子邮件地址不会被公开。 必填项已用*标注

请启用Javascript,以完成验证!