几周前，《Oracle性能诊断艺术》（Troubleshooting Oracle Performance 的中文版）终于面市，现在线下的实体书店应该也可以买到了。这半年来一直有朋友在问什么时候能够出版，现在总算有个交代了。
关于中文版书名，图灵出版社编辑们费了不少心思，尽管最后敲定的书名中”艺术”两个字似乎有点托大，不过我个人觉得也还算好，恳请读者把重点放到内容的汲取上而不是和书名较劲。
这本书从接手到现在也快一年的时间了，整个过程尽管有辛苦，也已经成为过去式。这或许是我最后一本翻译的图书–除非以后出版自己写作的东西(如果内容还能过得去的话)。
如果朋友们针对书中内容有任何问题，可以访问 支持页面留言反馈或者发邮件给几位译者。相信译文中仍有欠妥的地方，译者将尽量提供技术支持以及延伸内容。
–EOF–
感谢这本书翻译过程中给予我们帮助的所有朋友们，有你们的支持，是几位译者的幸运。
如果有人问你一台 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–
在这次的 Oracle Open World 上，Hammerora 的作者 Steve Shaw 做了一个关于 Linux 平台 Oracle 调优的演讲，其中重点提到了 NUMA 架构对于 Intel Nehalem CPU 上跑 Oracle 的性能影响。
对于传统 SMP 来说，CPU 增多未必系统性能就好，因为共享系统总线的限制了 CPU 数量，CPU 越多内部通信量越大共享总线越容易达到瓶颈。而 NUMA 架构则多少缓解了这个扩展问题，其大致机理是通过给每个核提供单独的本地内存，进而提高可扩展性。而每个核访问本地内存和其它核上的内存时间是不一样的，所以，应用程度对于内存的访问是有比较大的讲究的。从硬件到操作系统再到应用程序，都要支持 NUMA 才会发挥真正的处理能力。
在这里倒是可以插入介绍一下阿姆达尔定律（Amdahl’s Law），这个定律指出并行处理器环境中的速度受制于程序串行的部分，也即暗示说多核未必性能就那么好。
Image via Wikipedia
对一个 DBA 来说，Intel 的 Nehalem CPU (右图为结构示意图）最值得关注的特性当属 NUMA (Non-Uniform Memory Access) 架构方面的改进。
从 Oracle 数据库 8i 开始支持 NUMA 特性，NUMA 在10.2.0.4 与 11.1 上是默认启用的，不过在之前的版本以及 11.2 之后默认是关闭该特性的。在 Intel 平台上，Oracle Validated RPM 包安装后将激活 NUMA。安装的时候，当 Oracle 检测到硬件与操作系统支持 NUMA 的时候，会自动启用 NUMA 支持，Linux 在内核 2.6.9-67 以后自动支持 NUMA 。至于硬件上的开关是通过 BIOS ，如果硬件支持，则 BIOS 默认是激活（enable)该特性的。操作系统层面的开启可以通过核心参数添加 numa=off 的方式来达到。
可以通过操作系统命令查看相关的状态：
# numactl --show
NUMA 这个常看到的术语，似乎一直以来没有得到 DBA 们足够的重视。需要注意的是，硬件、操作系统、应用软件(Oracle) 三者都要支持 NUMA ，才能充分利用这一特性。对于支持 NUMA 的 DB 环境，理论上来说内存请求的利用应该会更有效一些。至于具体的性能数据还要看实测结果，暂时恐怕难以给出，留待以后补充吧。必须要说的是，作为DBA，在启用某个特性的时候，一定要明白这个特性的来龙去脉，以及潜在的影响。
–EOF–
对于一些不能充分利用多核的软件，比如某些 Web 服务器或者 Proxy，或者需要考虑一下如何利用 NUMA 特性了。而类似跑数据统计的应用，”CPU的并行”得到利用之后或许应该考虑如何更充分利用 NUMA 特性了。
Image via Wikipedia
技术爱好者大多都知道 Google 是使用 Linux 的大户，但是一直以来对于他们如何使用 Linux 却知之甚少，甚至内核开发社区对 Google 内部使用的情况也了解不多。LWN 上的这篇 How Google uses Linux 给我们带来了不少信息。
Google 使用 Linux 肯定有很多令人震惊的地方，第一个令人”惊讶”的是他们使用的代码管理工具：Perforce 。代码维护方式看起来也比较落后，当前维护的代码版本远远落后于开源社区内核版本，因为 Google 自己要维护大量的内部特性，每一个大版本发布周期是大约 18 个月，而内部特性的回归也要折腾6个月。因为版本滞后，所以有不少向后移植(Backporting)的工作要做，这个比例大约是 25%，还是不小的。
Google 内部大约有 30 个内核开发人员，而之所以外界很少看到 Google 对 Linux 的 Patch 代码，主要的原因居然是–担心代码不够优雅。我想这应该说的是大实话。我也遇到过很好的开发者对开源软件做了改进之后不愿意把代码贴出来，原因就是担心代码不好看，怕被笑话。
因为应用程序类型之故，对于 Google 来说，完全公平调度器(Completely Fair Scheduler)并不适合，采用了 O(1) 调度器，一般 16-32 核的机器要跑 5000 个线程左右。
Google 倒是喜欢用 Out-of-memory (OOM) killer 特性，这倒是出乎我的意料。Google 对于内存管理方面的改进或许是不小的突破: 通过伪 NUMA 模式来保证不同类型应用对内存的使用。除此之外，有大量的代码用于系统的监控，针对磁盘、网络等子系统或者是针对应用程序性能。
对于计划中的将实现的新特性，在一堆列表中看到了在 I/O 层对于高速 Flash 盘的支持计划。在文末，另一个有趣的技巧是，Google 喜欢把文件系统的元数据 Pin 到内存里以便提高读取响应时间。
或许将来能看到 Google 为 Linux 内核贡献更多代码，那会是一件很有意义的事情。
–EOF–