针对 MySQL 数据库的版本也做个调查。分析一下大家使用 MySQL 的趋势与习惯。选择大家都选择的，总不会有更大的错误。而如果使用了一个不太合适的版本，或许会后患无穷。
点击访问在线调查 (如果你不能访问这个 URL，需要动动脑子想想为什么)。
现阶段收集到的统计数据：
国内用户用 5.0 的是最多的。如果小版本加起来还是 5.1 的居多。4.1 的版本渐渐推出历史舞台。如果你也在考虑选择 MySQL 的版本，这个数据是否对你有参考性呢?
–EOF–
Tag Archives: MySQL
SmugMug 的架构介绍
本文介绍的 SmugMug 是一家提供付费图片托管服务的站点，在 2002 年由 Chris MacAskill 与 Don MacAskill 父子二人创建，最初提供面向游戏的视频服务，随后转型为现在的模式。网站流量现在是全球 1800 多，盈利能力自称良好。
在 MySQL Conf 2009 上，SmugMug 的 Don MacAskill 做了一次关于SmugMug 网站架构的分享。
SmugMug 整个网站采用 LAMP 架构(其实也有 OpenSolaris)，300 多台 4 核（或更多）的服务器（大多是 AMD 的 CPU） ，分散在四个机房，两个运营的人员。SmugMug 充分运用了云计算服务，是 Amazon 的一个大客户，图片和视频总计达到了 PB 级，托管在 Amazon S3 上，图片和视频的处理也在 Amazon EC2 上。使用了 Akamai 的服务做前端的 CDN 加速，主要是 JavaScript/CSS 等文件的加速，此外，DNS 加速也带来了很好的收益。
结构化数据放在 MySQL 中，存储引擎多数用的 InnoDB，数据超过 2TB 的空间，数据库服务器为 4 核或更高配置，内存多达 64GB。缓存方面，用了 Memcached 做加速，有 1TB 的数据在这里面，平均命中率达到 96%。Memcached 里面尽量存放 MySQL 行数据，减小对 DB 的冲击。数据库设计思路是尽量做垂直分区，没有 Sharding。不过在反范式(denormalized)方面做得比较彻底，不用表连接(JOIN)方法者复杂的查询。多数查询依赖主键，更新或者删除数据也是单行，依赖主键。InnoDB 引擎打了 Percona 的 Patch，并发能力也有了很大增强。
对 DB 的数据完整性与写能力的要求高，而对于读的扩展性还是相对比较好解决。Linux 上的文件系统是 SmugMug 不太满意的地方，备份也成问题。ZFS 倒是能满足相关的需求，可惜不支持 Linux(妈的，早该支持 Linux了)。所以他们迁移到了 OpenSolaris 上。另外，对于复制中可能出现的风险，尝试了第三方提供的一些 Patch (参考 Google 发布的 MySQL Patch)。
采用 OpenSolaris 后，MySQL 放在 Sun Sushi Toro(Storage 7410，这个东西也支持 SSD ) 上，走 NFSv3 协议。写到这里，发现 SmugMug 的解决方案非常不具有通用行，看起来 Sun 是给了他们不小的硬件优惠，否则一般情况下不会有人这么搞的，用 NFS 协议走数据库，除非是测试环境或者是复制(我怀疑只是 Slave 端通过 NFS 走)，产品上真的有人跑么?
网站架构的进化，其实也是选定一个方向(比如用开源工具解决)，然后一直试错的过程。
–EOF–
OpenDNS 的统计(Stats)服务的实现
对国内互联网用户来说，OpenDNS.com 这个服务在技术圈子里还是有些知名度的，当然这要归功于国内电信服务商对域名的无耻劫持行为。
OpenDNS 的员工 Richard Crowley 在 Velocity 2009 上和与会者分享了关于 OpenDNS Stats 服务的实现。当时的数据是每天有 140 亿次的 DNS 查询，而现在从公开的数据看，每天已经超过 180 亿次查询。这个 PPT 的内容就是讲 OpenDNS 是如何处理并统计这些查询记录的。
主要的策略分两步，第一步，根据网段切数据；第二步，聚合与存储。体现到 DB 层面是给每个网段单独分配一个表，尽可能的让表更小，让主键更小。
选择合适的方式存储域名。如果表使用 auto_increment 字段做主键是不太合适的做法–不同的引擎都有或多或少的锁问题，OpenDNS 采用域名的 SHA1 摘要值用来做域名的主键(SHA1 是20个字节，倒也不算浪费空间)。用了两台机器，每台 48GB 左右的存储空间，另外通过跨在 8 台机器上总共 28GB 的 Memcached 来避免对数据库的读操作。
对于聚合数据的进程会产生内存溢出的问题，采取的办法是清空内存，重启进程（而不是释放内存)的思路。利用了 supervise 这个小工具来做到。这地方其实值得商榷。
开始曾发现 80% 的 I/O 等待表的打开与关闭上。通过 Strace 发现存在大量的 open() 与 close() 调用。通过設置 ulimit -n 600000 解决(关于 ulimit 参数的意义参考。这意味着 OpenDNS 用了大约 60 万个表(网段)！(?) 这的确是比较极端的做法。
而在 DB 存储引擎的选择开始用了 MyISAM ，也是不合适的，通过迁移到 InnoDB 速度得到了很大提升。这似乎是缺乏评估与规划的表现，或许 OpenDNS 在这方面并非十分擅长。
(Copyright by Richard Crowley )
上图从右向左看，查询日志通过 rsync 同步到 Stage 1 的服务器上（位于旧金山)，根据查询到的域名把查询日志映射为中间文件，然后把数据文件同步到 Stage 2 的服务器，启动聚合进程把中间文件读入，修剪(Pruning)进程把拼装好的 SQL 语句写入 DB。整个步骤其实暗合 MapReduce 的思路。虽然不是严格的 MapReduce 实现。
听说国内提供类似服务的 DNSPod 因为上次的暴风长老事件受到了广泛瞩目，前不久成立了公司旨在专门提供智能 DNS 服务。不知道每天查询量有多大。[Updated: 见楼下 DNSPod 站长的回复 “DNSPod请求数每天20来个亿” ]
–EOF–
几句题外话：因为逐渐远离一线技术环境，为保持对技术的兴趣，每天多读一些 PPT 也是有乐趣的事情，或许一年没有敲多少条命令，但是看的 PPT 恐怕没有几个人比我多。看到一些还算有趣的 PPT 就做点笔记和大家分享。或许对人有用呢。
Updated：Google 开始提供 DNS 了。Google Public DNS
还可以参考一下这篇：OpenDNS MySQL abuses，另外，Richard Crowley 已经在2010 年2月份从 OpenDNS 离职…
DRBD 与 Pacemaker
如果有人问你一台 PC 服务器是否可以达到 99.99% 的高可用，该如何回答呢? 或许没有一台机器能”确保”达到这样的可用率，当然在某个时间段或许不会出问题，但这个肯定是看运气，而高可用基本上是没办法通过一台来达到目标的，我们更多的时候是设计方案确保在出问题的时候尽快接管故障机器，当然这要付出更大的成本。
对于 Oracle 的高可用方案可以参考 Maximum Availability Architecture (MAA) 白皮书，不过 Oracle 并不推崇操作系统级别的解决方案。MySQL 的指导策略倒是更为灵活一些，DRBD® (Distributed Replicated Block Device) 就是个可以考虑的选择。以前关注过这东西，但是据我了解，好像国内实现的案例不多，不知道是不是处于对网卡同步速度的限制考虑。现在这个有了新的转机，在 8.3 版本上已经能够支持 InfiniBand 。而原来通过网卡同步数据块的方式毕竟受网卡延时和带宽的限制，InfiniBand 的支持的实现相信能赢得一部分企业用户的信赖。
Linux Kernel Summit 2009 上这次有对 DRBD 的介绍(注意对数据一致性的介绍)，这意味着能正式进入 Kernel 么?
相对专有的集群管理工具，也有开源的集群管理工具 Pacemaker (支持 Heartbeat 与 OpenAIS 标准)可供配套使用。Pacemaker 能够较为灵活的实现主备、N+1 、N-N 等多种模式。感人感觉会比较有生命力。
好的开源解决方案就是设计活动木板房，廉价灵活环保，当然，牢固肯定是第一目标。
补充：
根据 MySQLPerformanceBlog 的说法，MySQL 几种高可用解决方案能达到的可用性如下：
–EOF–