标签归档:redis

在微软Azure中用Redis为ASP.NET应用加速

Azure Redis Cache是微软Azure提供的一项托管服务。该服务基于开源Redis缓存构建,能够利用Redis引擎低延迟、高吞吐量的特性提高应用程序的响应速度。

目前,Azure Redis Cache包含以下三个服务等级:

  • 基本服务:仅有一个缓存节点,适合开发/测试和非关键工作负载,无SLA。
  • 标准服务:有两个节点(主节点/备用节点),具备自动故障转移和自动复制功能,提供高可用SLA。
  • 高级服务(预览):包含标准服务的所有特性,性能更好,安全性更高,支持更大的工作负载及灾难恢复。要了解更多特性,请查看这里

其中,基本/标准服务缓存上限为53GB,而高级服务的缓存上限为530GB。价格信息可以查看这里

Scott Hanselman是微软Web平台&工具部门的一名项目经理。去年,他曾撰文介绍Azure Redis Cache的基本用法。近日,他又介绍了一种新的Azure Redis Cache应用场景,即将其作为ASP.NET应用的缓存。

重要通知:接下来InfoQ将会选择性地将部分优秀内容首发在微信公众号中,欢迎关注InfoQ微信公众号第一时间阅读精品内容。

据Scott介绍,ASP.NET现在提供了很好的Redis支持,可以从NuGet上下载Microsoft.Web.RedisSessionStateProvider库:

Install-Package Microsoft.Web.RedisSessionStateProvider

该库底层使用了StackExchange,但允许ASP.NET使用Session对象,并在Redis中保存结果,而不是在Web服务器的内存中。使用下面的代码在web.config中添加该库:

Redis Desktop Manager中可以看到存储在Redis中的ASP.NET Session数据,如下图所示:

Redis Cache不仅可以用于存储Session State,而且还可以用于Output Cache,即将整个HTTP响应缓存。相应的库在ASP.NET 4.x中的安装方法同Session State Provider类似:

Install-Package Microsoft.Web.RedisOutputCacheProvider

这样,当在MVC Controller中使用[OutputCache]属性或在Web Forms中使用OutputCache指令(如<%@ OutputCache Duration="60" VaryByParam="*" %>)时,响应就会通过Redis来处理。对于类似产品目录这样的应用,可使其响应速度提高4~10倍。

用户也可以通过编程使用Redis,微软提供了在.NETNode.jsJavaPython中使用Azure Redis Cache的文档。如果不想在Azure甚或Linux上运行Redis,那么可以选用MSOpenTech的Redis on Windows分支。安装完成后,就可以通过命令行使用redis-cli.exe同Azure Redis Cache交互。而如果使用了本地Redis服务器(redis-server.exe),那么在部署到Azure的时候需要修改应用的Redis连接字符串。

Redis 未授权访问配合 SSH key 文件利用分析

Date: 2015-11-11

Redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库,并提供多种语言的API。

Redis 未授权访问的问题是一直存在的问题,知道创宇安全研究团队历史上也做过相关的应急,今日,又出现 Redis 未授权访问配合 SSH key 文件被利用的情况,导致一大批 Redis 服务器被黑,今天我们来简要的分析下。

一、漏洞概述

Redis 默认情况下,会绑定在 0.0.0.0:6379,这样将会将 Redis 服务暴露到公网上,如果在没有开启认证的情况下,可以导致任意用户在可以访问目标服务器的情况下未授权访问 Redis 以及读取 Redis 的数据。攻击者在未授权访问 Redis 的情况下可以利用 Redis 的相关方法,可以成功在 Redis 服务器上写入公钥,进而可以使用对应私钥直接登录目标服务器。

1、漏洞描述

Redis 安全模型的观念是: “请不要将 Redis 暴露在公开网络中, 因为让不受信任的客户接触到 Redis 是非常危险的” 。

Redis 作者之所以放弃解决未授权访问导致的不安全性是因为, 99.99% 使用 Redis 的场景都是在沙盒化的环境中, 为了0.01%的可能性增加安全规则的同时也增加了复杂性, 虽然这个问题的并不是不能解决的, 但是这在他的设计哲学中仍是不划算的。

因为其他受信任用户需要使用 Redis 或者因为运维人员的疏忽等原因,部分 Redis 绑定在 0.0.0.0:6379,并且没有开启认证(这是Redis 的默认配置),如果没有进行采用相关的策略,比如添加防火墙规则避免其他非信任来源 ip 访问等,将会导致 Redis 服务直接暴露在公网上,导致其他用户可以直接在非授权情况下直接访问Redis服务并进行相关操作。

利用 Redis 自身的提供的 config 命令,可以进行写文件操作,攻击者可以成功将自己的公钥写入目标服务器的 /root/.ssh 文件夹的authotrized_keys 文件中,进而可以直接使用对应的私钥登录目标服务器。

2、漏洞影响

Redis 暴露在公网(即绑定在0.0.0.0:6379,目标IP公网可访问),并且没有开启相关认证和添加相关安全策略情况下可受影响而导致被利用。

通过ZoomEye 的搜索结果显示,有97707在公网可以直接访问的Redis服务。

QQ20151111-0@2x

根据 ZoomEye 的探测,全球无验证可直接利用Redis 分布情况如下:

1

全球无验证可直接利用Redis TOP 10国家与地区:

2

3、漏洞分析与利用

首先在本地生产公私钥文件:

ssh-keygen

然后将公钥写入 foo.txt 文件

再连接 Redis 写入文件

redis_ssh

这样就可以成功的将自己的公钥写入 /root/.ssh 文件夹的 authotrized_keys 文件里,然后攻击者直接执行:

即可远程利用自己的私钥登录该服务器。

当然,写入的目录不限于 /root/.ssh 下的authorized_keys,也可以写入用户目录,不过 Redis 很多以 root 权限运行,所以写入 root 目录下,可以跳过猜用户的步骤。

4、Redis 未授权的其他危害与利用

a)数据库数据泄露

Redis 作为数据库,保存着各种各样的数据,如果存在未授权访问的情况,将会导致数据的泄露,其中包含保存的用户信息等。

redis_user

b)代码执行

Redis可以嵌套Lua脚本的特性将会导致代码执行, 危害同其他服务器端的代码执行, 样例如下        一旦攻击者能够在服务器端执行任意代码, 攻击方式将会变得多且复杂, 这是非常危险的.

redis_lua

通过Lua代码攻击者可以调用 redis.sha1hex() 函数,恶意利用 Redis 服务器进行 SHA-1 的破解。

c)敏感信息泄露

通过 Redis 的 INFO 命令, 可以查看服务器相关的参数和敏感信息, 为攻击者的后续渗透做铺垫。

redis_info

可以看到泄露了很多 Redis 服务器的信息, 有当前 Redis 版本, 内存运行状态, 服务端个数等等敏感信息。

5、漏洞验证

可以使用Pocsuite(http://github.com/knownsec/pocsuite)执行以下的代码可以用于测试目标地址是否存在未授权的Redis服务。

二、安全建议

  1. 配置bind选项,限定可以连接Redis服务器的IP,修改 Redis 的默认端口6379
  2. 配置认证,也就是AUTH,设置密码,密码会以明文方式保存在Redis配置文件中
  3. 配置rename-command 配置项 “RENAME_CONFIG”,这样即使存在未授权访问,也能够给攻击者使用config 指令加大难度
  4. 好消息是Redis作者表示将会开发”real user”,区分普通用户和admin权限,普通用户将会被禁止运行某些命令,如config

三、参考链接

  1. http://www.sebug.net/vuldb/ssvid-89339
  2. http://antirez.com/news/96
  3. http://www.secpulse.com/archives/5366.html
  4. http://www.sebug.net/vuldb/ssvid-89715

安全半月谈:细思恐极的移动应用后门和企业开发之困

安全要闻

“移动安全的引爆点还没有到来,所有在PC上发生过的安全问题,在移动端都会一一重现。”吴瀚清和大牛蛙都曾发表过类似的观点。

愈演愈烈XcodeGhost后门事件

“30年前 Ken Thompson那个在编译器里留后门的点子,现在终于被黑产用上了。”TK教主如是说

9月14日,国家互联网应急中心发布了“关于使用非苹果官方Xcode存在植入恶意代码情况的预警通报”。随后,苹果公司官方也发布了公告。9月17日,第三方安全漏洞平台乌云网发布了《Xcode编译器里有鬼–XcodeGhost样本分析》的报告,
9月19日,一位自称是XcodeGhost事件主导者的网友发微博声明称,这只是实验项目,无任何危险,更不会获取用户的隐私数据。

但各安全平台显然不这么认为,腾讯安全应急相应中心(TSRC)发布了事件报告,乌云网对 XcodeGhost样本进行了分析,看雪安全论坛进行了详细的分析,来自四叶草安全组织的Saic则分析了 XcodeGhost的用途。有人干脆录制了 XcodeGhost恶意推广应用演示视频。腾讯玄武实验室发布了家用路由器检查 iPhone 是否感染了 XcodeGhost,国内著名iOS越狱团队盘古则释出了iPhone移动版 Xcode病毒检测工具。

然而,如果你以为事情这样就结束了未免言之过早。本月,安全公司FireEye发布报告,称 XcodeGhost新变种已经进化到可以支持 iOS 9版本,报告指出仍有210家美国企业在运行被XcodeGhost恶意感染的苹果应用。

因此,有人称,这是 App Store“自2008年上线以来遭受的规模最大的攻击。”也不无道理。

不得不说的百度“全家桶”

知乎上有个帖子,问为什么有人说“「百度全面降低了中国的互联网体验」”?不得不说,乌云网曝出的百度“WormHole后门”事件令国产软件厂商再次蒙羞。该漏洞存在于百度公司开发的Moplus SDK中,其中包括4014款百度官方Android应用,尽管百度第一时间升级了SDK,但趋势科技随后发布报告认为危害亦然存在。

有研究人员认为该漏洞危害超过Stagefright。由于影响较大,除了乌云网的分析报告,传统安全厂商绿盟科技也分析了该漏洞。随着事态的发展,安全界将该后门认定为安全漏洞。安卓用户可以点击这里进行漏洞检测。

正当大家要松一口气的时候,FireEye又发布了一则安全报告,发现 App Store中有2846个APP携带疑似”后门”行为的广告库mobiSage——又一款国产第三方广告平台(目前该厂商已经公布相应的处理方案),黑客通过这些APP可控制用户的手机。这一次iOS和Android同时中招。

安全开发

令人嗔目结舌的Redis后门植入

正当全国人民都沉浸在“双十一”的狂欢中时,知道创宇发布了一则Redis安全报告,造成这个安全漏洞的根源在于 Redis不当的默认配置已经安全运维人员的疏忽,使其暴露在公网中,从而被攻击者非法登录。乌云网随后发布了 Redis后门植入的分析报告。据了解,国内互联网遭到了全网性入侵,上万家暴露的Redis服务器被入侵。建议企业运维人员及时查看Redis服务的端口情况以及认证机制是否开启认证或存在弱口令;同时检查Redis服务root的.ssh目录下是否出现非法的Key。

丧心病狂的Java反序列化

“一波还未平息一波又来侵袭。”2015年11月6日,国外 FoxGlove安全研究团队于在其博客上公开了一篇关于常见 Java应用如何利用反序列化操作进行远程命令执行的文章。Java在进行反序列化操作的时候会使用 ObjectInputStream类调用 readObject()方法去读取传递过来的序列化对象字节流进行处理,利用 Apache Commons Collections库恰好可以构造出了一个在反序列化操作时能够自动执行命令的调用链。乌云网对该漏洞导致的RCE进行了分析。

目前全球使用Java语言的网站有453,342个。基于Jenkins的网站有11,059个,基于JBoss的网站有29,194,基于WebSphere的网站有2,076个。该漏洞在最新版的WebLogic、WebSphere、JBoss、Jenkins、OpenNMS中都可实现远程代码执行。更为严重的是,在漏洞被发现的9个月后依然没有有效的Java库补丁来针对受到影响的产品进行加固。中、美两国是Java语言使用大户,而中国境内共有128,032个网站使用Java语言……整个世界都不好了

黑哥称这次 Java反序列化漏洞“覆盖面会很大,将持续N年。”绿盟科技给出的临时解决方案如下:

[/crayon]

官方解决方案暂无。

鏖战双十一,电商技术力量揭秘

今年的“双十一”全民网购狂欢节已经落下帷幕,从各电商企业发布出来的数据来看,今年的热烈程度再次毫无悬念狂刷以往的记录。而在这一切的背后,是一场“真枪实弹”的技术硬仗,更是一场能令技术人“热血沸腾”的技术狂欢。本文中,牛小七将总结国内各大知名电商的技术架构实践,带大家一睹它们如何鏖战“双十一”?
 

鏖战双十一,电商技术力量揭秘

当当:促销系统和交易系统双系统重构

重构促销系统:当当原促销系统模型较陈旧、扩展性差、不成熟并且与其它系统耦合严重,因此,此次的核心改进点在于促销系统的扩展性、灵活性,系统解耦和更强大的数据处理能力。在确定基本促销模型并抽象后,重点在于实施解耦,当当将直读DB和存储冗余促销数据的系统修改为调用服务及监听MQ;在逻辑回收方面,将促销校验与促销计算提取为交易服务,回收原先由购物车、交易系统自行处理的促销逻辑。此外,还做了提取促销工具属性及完善促销系统查询服务的工作。在应用架构实现上,从前端页面到后端逻辑,尽量避免有逻辑与促销类型直接绑定,全部以插件化方式与促销模型对接,完全根据促销类型的配置进行组装。鉴于促销的时效性和实时性要求,当当在数据库前加Redis缓存,以提高响应速度,同时监听MQ,根据事件清理相应的缓存数据。

重构交易系统:当当交易系统的重构使用了业界较成熟的系统方案,重构过程主经包括易于管理的集中化配置、将大流程计算结果进行缓存提高页面刷新速度、小版本结算与统一结算合并、巧借Nginx的reload配置进行灰度发布等。由于交易系统的计算都和金钱有关,当当还提出线上并行比对方案,根据老交易系统比对新交易,保证其逻辑正确。此外,还开发了分流功能,按照用户id分流前,先使用测试白名单中的用户进行预验证,预验证通过后,再按比例由低至高逐步切换。值得一提的是,基于灰度发布技术,新交易系统的Web服务器很容易做到按需伸缩。 

苏宁:主抓四大方向

系统拆分:技术上分析主流程、分离主干系统和枝叶系统、根据业务内聚性独立出主干系统,做到分别部署。并根据业务功能拆分出会员、商品、库存、价格、购物车、交易、订单和内容管理几大系统,组建对应的研发中心来维护;根据交易环节的系统压力,独立出抢购和秒杀系统,拆分出购物券、云钻等营销类的系统,并组建营销中心。

基础平台:基础平台主要抓基础架构、通用系统、中间件及包括运维监控、持续集成、大数据分析、风控系统在内的平台。主要工作包括系统之间的通讯、统一验证和内部管理系统的统一权限、Session共享、分布式调用链、Redis分片存储、数据库的分库分表中间件、统一配置管理和流控等。


研发流程:除通过代码走查、sonar平台、各种测试等手段,中心也采用代码飞检来确保代码质量。代码飞检即定期快速评审系统核心代码,主要由各个系统负责人、架构师以及总监负责。流程发布检查单为系统的最后一关,需经过产品负责人、开发负责人、QA、测试负责人、DBA、运维人员、以及线上验证人员对各个环节进行确认,确保系统上线过程少出问题或出问题能及时下架。 

系统保障:主要重视提高系统负载能力和应急预案两方面。在提高系统负载能力方面,根据历史数据对双11流量进行预估,细化到每个系统的PV、UV、峰值TPS,并对目前系统压力、容量和相关指标进行统计。此外,对系统进行了自上而下的体检,针对发现问题制定相关方案。具体体现在对系统架构梳理、关键代码优化以及中间件调优。在应急预案方面,主要涉及拒绝黑名单、限流及降级策略。限流通过防火墙流控、中间件流控功能和组件实现。

蘑菇街:五个关注焦点

稳定性:对已遇到过的问题,及时采用各种方式解决或规避。 

多维度的阈值监控:实时pid数量监控、调整容器内存计算算法更精确监控内存、修改container里的rsyslog配置,只让宿主机去读kernel以解决日志乱序。在压力大的情况下,为个别容器进行动态的CPU、内存等扩容或缩容,调整甚至放开磁盘iops限速和网络的TC限速。此外,定期扫描线上潜在风险。

灾备和紧急故障处理:如在不启动DockerDaemon情况下,离线恢复Docker中数据的方法。方法是:用dmsetup create命令创建一个临时的dm设备,映射到Docker实例所用的dm设备号,通过mount临时设备,恢复原有数据。支持Docker容器冷迁移。通过管理平台界面一键实现跨物理机迁移。 

与已有运维系统的对接:Docker集群须能与现有运维系统无缝对接,才能快速响应,做到秒级的弹性扩容/缩容。因而以统一的容器管理平台,实现对多个Docker集群的管理,从下发指令到完成容器的创建可以在7秒内完成。

性能优化:针对磁盘IO的性能瓶颈,调优部分内核参数。引入Facebook的开源软件flashcache,将SSD作为cache,提高docker容器的IO性能。通过合并镜像层次优化docker pull镜像的时间。在docker pull时,每一层校验的耗时很长,通过减小层数,不仅大小变小,docker pull时间也大幅缩短。

唯品会:六个设计要点

系统模块有效切分:原业务系统在实际运作中业务耦合严重、模块划分不合理,导致模块之间边界不清楚。唯品会从整个系统角度出发,梳理整个流程,重新做系统定位,将不同业务子系统做物理分离,减少彼此依赖,使各个子系统独立部署,出现问题后能快速采取措施,隔离出问题模块,将故障影响降到最低。

服务化解耦,集中服务治理:基于Spring的Java开发框架独立自主开发Venus系统,涵盖数据库访问层封装、缓存接口封装、CRUD服务代码自动生成、OSP/REST服务调用接口封装及异步支持等方面,降低开发复杂度,、提高开发效率、提升代码质量,、规范开发流程。

增加异步访问:对于系统间实时性要求不高、执行耗时的操作,可通过异步处理提高调用者性能、响应能力。通过异步调用通知非主要流程,加快系统主要业务流程的反应速度和性能,异步处理机制可起到缓冲的作用,被通知的下游系统可依据自身能力控制处理数据量,避免遭受超负荷的冲击,保证系统稳定运行,增加系统可用性。分布式异步消息队列服务器可在宕机后确保消息不丢失,异步系统有重试机制,从而提高系统可用性、健壮性和扩展性。

多阶段缓存,降低后端压力:做动静分离降低后端压力。引入分布式缓存,对缓存数据服务节点做统一集中管理,支持缓存集群弹性扩展,通过动态增加或减少节点应对变化数据访问负载;冗余机制实现高可用性,无单点失效,不会因服务器故障而导致缓存服务中断或数据丢失。应用端使用统一的API接口访问缓存服务器。此外,唯品会还巧用应用服务器本地缓存,将基本不修改的配置数据、全局数据缓存在应用服务器本地,减少对后端缓存服务器实例的峰值冲击。

优化数据库访问:优化复杂查询和关键模块的数据库慢查询。保证在实现功能的基础上,减少对数据库的访问次数;通过查询参数,减少对表的访问行数,最小化结果集,减轻网络负担。采用读写分离技术,通过一主多从,写操作只发生在主表,多操作发生在从表上以缓解对主数据库的访问压力。并借助于分布式缓存,提供远大于数据库访问的性能。在设计时,需要防止缓存失效带来的缓存穿透压力,容许一定程度的数据冗余。对于关键模块,为防止因依赖而影响当前模块的性能和可靠性,可适度保存其它模块的关键数据,减少由于访问其它模块服务带来的系统损耗和可靠性压力。使用NoSQL数据库对海量大数据进行存储和处理。


加强系统监控:在系统和网络层面的监控,主要监控服务器指标(如CPU、内存、磁盘、流量、TCP连接数等)和数据库指标(如QPS、主从复制延时、进程、慢查询等)。业务层面监控主要通过在指定页面做埋点,和从业务系统的数据库两种方法,将需要监控的数据抽取出分析处理,存入自己维护的数据库中,然后通过浏览器页面、展示监控数据,页面同时提供各种时间维度上的筛选、汇总。此外,独立研发应用性能监控平台Mercury,通过在应用程序中植入探针逻辑实现对应用代码、关系数据库、缓存系统的实时监控。Mercury通过收集日志、上报日志的方式即时获取相关性能指标并进行智能分析,及时发现分布式应用系统的性能问题以及异常和错误,为系统解决性能和程序问题提供方便可靠的依据。

巧用云服务,挖金“双十一”

对于电商平台来讲,如果Web服务、业务数据库及静态资源部署在同一台服务器上,会相互影响执行效率;此外,还会有单点故障的问题,面对以上问题,最直接的方案则是做动静分离。而电商平台多重图片应用,需要消耗大量的带宽资源,同时图片的存储和处理会产生大量的成本。因此,使用第三方的存储服务将使得电商企业可以从容应对业务增长,特别是在“双十一”这种关键的场景下更显得尤为重要。在电商的业务场景中,七牛的技术方案将主要帮助他们解决如下难题。

KODO对象存储:电商平台有着诸如图片及部分社区电商平台的视频存储的需求。静态资源从业务服务器上剥离出来存储在七牛,加载时性能会提高。对于此,七牛把存储系统(甚至是主机系统和未来大的计算系统)进行孵化和提取出来,存储系统的扩容可达100PB级。

融合CDN加速:在类似“双十一”这样的大促活动中,宝贝刷不出来会严重影响电商平台用户的体验,而将电商平台的宝贝图片通过CDN缓存到靠近用户的节点,能提高CDN效率。同时,由于七牛云服务的弹性扩容,也避免了电商因大促自建存储而耗费各种资源等情况,让电商平台能自如应对突发业务的流量。此外,七牛特有的融合CDN加速平台,是引入主流CDN厂商优质节点与七牛自有高质量节点相结合而形成的,全面覆盖各运营商,真正做到了无盲区,特别关注小运营商区域,确保各区域的网购用户都能享受到最优的服务体验。七牛融合CDN加速成功实现了节点级互备,确保服务高可用高性能及持续可用。

DORA数据处理:电商平台上图片的各种转码需求非常大。由于移动设备种类繁多、屏幕分辨率不一致,就需要非常多的规格。如果图片一有改动,就需要让后台运维遍历所有图片重新转化。这样不仅加大了运维人员的工作量,还需要大量的存储空间。七牛图片实时转码功能,可帮助电商用户实时扩展新的图片规格,并且将转码生成的新规格图片放在七牛提供的缓存层供App调用,不用占用存储空间。这种服务器端只需存储一份原图,其他规格实时生成且不占用存储空间的机制,自然能帮助其节省大量的存储成本,同时用户体验也能得到很好的提升。此外,存储于七牛的所有JPEG格式的图片均可实时转码成WebP格式,还可进一步提升用户访问图片的流畅度,同时帮用户节省流量。

目前,七牛已为包括有赞、帮5买、有货(YOHO)、美柚、穿衣助手、明星衣橱、蘑菇街、1626奥特莱斯等在内的电商客户提供安全存储、双向加速及图片处理服务。

七牛融合CDN已于“双十一”前全面降价,降幅达42%

温馨提醒:这是一个最好的时代,七牛融合CDN已于“双十一”前全面降价,降幅达42%

声明:本文部分内容根据微信公众账号InfoQ的《盘点电商大战背后的技术力量支撑》一文整理而成。

 

MySQL 必须调整的 10 项参数

你需要经常察看以下3个配置项。不然,可能很快就会出问题。

innodb_buffer_pool_size:这是你安装完InnoDB后第一个应该设置的选项。缓冲池是数据和索引缓存的地方:这个值越大越好,这能保证你在大多数的读取操作时使用的是内存而不是硬盘。典型的值是5-6GB(8GB内存),20-25GB(32GB内存),100-120GB(128GB内存)。

innodb_log_file_size这是redo日志的大小。redo日志被用于确保写操作快速而可靠并且在崩溃时恢复。一直到MySQL 5.1,它都难于调整,因为一方面你想让它更大来提高性能,另一方面你想让它更小来使得崩溃后更快恢复。幸运的是从MySQL 5.5之后,崩溃恢复的性能的到了很大提升,这样你就可以同时拥有较高的写入性能和崩溃恢复性能了。一直到MySQL 5.5,redo日志的总尺寸被限定在4GB(默认可以有2个log文件)。这在MySQL 5.6里被提高。

一开始就把innodb_log_file_size设置成512M(这样有1GB的redo日志)会使你有充裕的写操作空间。如果你知道你的应用程序需要频繁的写入数据并且你使用的时MySQL 5.6,你可以一开始就把它这是成4G。

max_connections:如果你经常看到‘Too many connections’错误,是因为max_connections的值太低了。这非常常见因为应用程序没有正确的关闭数据库连接,你需要比默认的151连接数更大的值。max_connection值被设高了(例如1000或更高)之后一个主要缺陷是当服务器运行1000个或更高的活动事务时会变的没有响应。在应用程序里使用连接池或者在MySQL里使用进程池有助于解决这一问题。

InnoDB配置

从MySQL 5.5版本开始,InnoDB就是默认的存储引擎并且它比任何其他存储引擎的使用都要多得多。那也是为什么它需要小心配置的原因。

innodb_file_per_table:这项设置告知InnoDB是否需要将所有表的数据和索引存放在共享表空间里(innodb_file_per_table = OFF) 或者为每张表的数据单独放在一个.ibd文件(innodb_file_per_table = ON)。每张表一个文件允许你在drop、truncate或者rebuild表时回收磁盘空间。这对于一些高级特性也是有必要的,比如数据压缩。但是它不会带来任何性能收益。你不想让每张表一个文件的主要场景是:有非常多的表(比如10k+)。

MySQL 5.6中,这个属性默认值是ON,因此大部分情况下你什么都不需要做。对于之前的版本你必须在加载数据之前将这个属性设置为ON,因为它只对新创建的表有影响。

innodb_flush_log_at_trx_commit:默认值为1,表示InnoDB完全支持ACID特性。当你的主要关注点是数据安全的时候这个值是最合适的,比如在一个主节点上。但是对于磁盘(读写)速度较慢的系统,它会带来很巨大的开销,因为每次将改变flush到redo日志都需要额外的fsyncs。将它的值设置为2会导致不太可靠(unreliable)因为提交的事务仅仅每秒才flush一次到redo日志,但对于一些场景是可以接受的,比如对于主节点的备份节点这个值是可以接受的。如果值为0速度就更快了,但在系统崩溃时可能丢失一些数据:只适用于备份节点

innodb_flush_method: 这项配置决定了数据和日志写入硬盘的方式。一般来说,如果你有硬件RAID控制器,并且其独立缓存采用write-back机制,并有着电池断电保护,那么应该设置配置为O_DIRECT;否则,大多数情况下应将其设为fdatasync(默认值)。sysbench是一个可以帮助你决定这个选项的好工具。

innodb_log_buffer_size: 这项配置决定了为尚未执行的事务分配的缓存。其默认值(1MB)一般来说已经够用了,但是如果你的事务中包含有二进制大对象或者大文本字段的话,这点缓存很快就会被填满并触发额外的I/O操作。看看Innodb_log_waits状态变量,如果它不是0,增加innodb_log_buffer_size。

其他设置

query_cache_size: query cache(查询缓存)是一个众所周知的瓶颈,甚至在并发并不多的时候也是如此。 最佳选项是将其从一开始就停用,设置query_cache_size = 0(现在MySQL 5.6的默认值)并利用其他方法加速查询:优化索引、增加拷贝分散负载或者启用额外的缓存(比如memcache或redis)。如果你已经为你的应用启用了query cache并且还没有发现任何问题,query cache可能对你有用。这是如果你想停用它,那就得小心了。

log_bin:如果你想让数据库服务器充当主节点的备份节点,那么开启二进制日志是必须的。如果这么做了之后,还别忘了设置server_id为一个唯一的值。就算只有一个服务器,如果你想做基于时间点的数据恢复,这(开启二进制日志)也是很有用的:从你最近的备份中恢复(全量备份),并应用二进制日志中的修改(增量备份)。二进制日志一旦创建就将永久保存。所以如果你不想让磁盘空间耗尽,你可以用 PURGE BINARY LOGS 来清除旧文件,或者设置 expire_logs_days 来指定过多少天日志将被自动清除。
记录二进制日志不是没有开销的,所以如果你在一个非主节点的复制节点上不需要它的话,那么建议关闭这个选项。


skip_name_resolve:
当客户端连接数据库服务器时,服务器会进行主机名解析,并且当DNS很慢时,建立连接也会很慢。因此建议在启动服务器时关闭skip_name_resolve选项而不进行DNS查找。唯一的局限是之后GRANT语句中只能使用IP地址了,因此在添加这项设置到一个已有系统中必须格外小心。

总结

当然还有其他的设置可以起作用,取决于你的负载或硬件:在慢内存和快磁盘、高并发和写密集型负载情况下,你将需要特殊的调整。然而这里的目标是使得你可以快速地获得一个稳健的MySQL配置,而不用花费太多时间在调整一些无关紧要的MySQL设置或读文档找出哪些设置对你来说很重要上。

原文连接:http://www.oschina.net/translate/10-mysql-settings-to-tune-after-installation