Database 类别下的文章

前几天 MySQL 站点上有个为期 12 天以 Scale-Out 为主题的活动,列举了不少成功的案例,每个页面有下方的这个图很引人注意:

scaleout_diagram_sm.png

注意到主备服务器之间的 HA 是通过 DRBD(Distributed Replicated Block Device)做到的。DRBD 号称是 "网络 RAID",开源软件,由 LINBIT 公司开发,MySQL 与 LINBIT 达成了合作关系,大张旗鼓的搞了这个 "12 天 Scale-Out" 活动也是这个商业合作驱动的吧。DRBD 助力 MySQL, 号称可以得到四个 9 的可靠性,这不低于任何一款商业数据库软件了。

DRBD 的出现的确对 MySQL 集群的可用性有很大提高。而且,有独到的特点,非常适合面向互联网的应用。因为是在存储层的数据块同步,很容易的做到应用层的 IO 负载均衡(备机承担一定的读压力),不但支持数据库失败接管,还能做到 IP 失败接管,接管时间小于 30 秒,真是穷人的绝佳集群解决方案(相比 Oracle 下的一些方案,比如 eBay 采用的方案,性价比还是不错的)。国外已经有很多成功的实现案例,国内的 Web 2.0 站点不知道是否已经有人在用,在这里推荐一下。更为有趣的是,已经有人通过 DRBD 来实现 Oracle 的另类集群。

怪不得前一阵子已经有开源爱好者开始宣称类似 "RAID即将成为过去式" 的激进言论。

--EOF--

在过去的 Blog 中, 我(插一嘴:这里的"我" 如果替换成 "Fenng" 似乎有些自恋, 也不是我喜欢的行文语气, 可发现转贴不留名的行为太多了,他大爷的)曾经介绍过 《eBay 的应用服务器规模》 , 也介绍过 《eBay 的数据量》,在这篇文章中提到过 "eBay 购买了 Quest Share Plex 全球 Licence 用于数据复制",这个地方其实没有说开来。

对于 eBay 这样超大规模的站点来说,瓶颈往往最容易在数据库服务器上产生,必定有一部分数据(比如交易记录这样不容易水平分割的数据)容易带来大量的读操作,而不管用什么存储,能承担的 IO 能力是有限的。所以,如果有效的分散 IO 的承载能力就是一个很有意义的事情。

经过互联网考古学不断挖掘,路路续续又现了一些蛛丝马迹能够多少说明一些问题。客观事实加上主观想象,简单的描述一下。见下图:

ebay_shareplex_F5.jpg

通过 Quest 公司的 Share Plex 近乎实时的复制数据到其他数据库节点,F5 通过特定的模块检查数据库状态,并进行负载均衡,IO 成功的做到了分布,读写分离,而且极大的提高了可用性。F5 真是一家很有创新性的公司,虽然从这个案例来说,技术并无高深之处,但方法巧妙,整个方案浑然一体。

F5公司专门为Oracle 9i 数据库开发了专用的健康检查模块,通过调用F5专有的扩展应用校验(EAV)进程,F5能够随时得到Oracle 9i数据库的应用层服务能力而不是其他的负载均衡设备所采用的 ICMP/TCP 层进行健康检查。

这个图来自一篇《F5助力eBay数据库服务器负载均衡》的软文,真是一篇很好的软文,国外恐怕不会出现这样"含金量"极高的东西。

当然,这个技术架构可不算便宜。Quest 的 Share Plex License 很贵,而且,对于每个结点来说,都需要数据库 License 与硬件费用。但优点也很多:节省了维护成本; 数据库层面的访问也能做到 SOA; 高可用性。

国内的一些厂商比较喜欢给客户推存储级别的解决方案。通过存储底层复制来解决数据分布以及灾备问题。这个思路似乎太传统了,对于互联网企业来说多少有点过时。

BTW: 对 Amazon 的存储架构非常感兴趣,谁/哪里能提供点线索呢?

--EOF--

Oracle 11g 的两个特性

Oracle 11g 快发布了,相关特性的介绍断断续续可以看到,有些特性与其说是锦上添花,还不如说是"雾件",实用性不大。不过今天了解到的两个新特性,倒是令我比较感兴趣。

归档日志压缩

其中一个是归档日志压缩的功能。通过设置初始化参数 log_archive_dest_n 中 compression 选项,可以对归档文件进行压缩生成。对于网络传输比较吃紧的环境,这个功能会很有价值。

物理 Standby 可以联机查询

11g 据说也可以对物理的 Standby 进行联机查询,前提条件是激活 Redo Apply 。10g 之前,物理 Standby 都是要么恢复状态,要么 Read Only 状态。如果能够边恢复边查询的话,那么简直是一个比较完美的 IO 分布的技术方案了。SharePlex 之类的产品市场会又小不少。

还没有看到最终的官方文档说明,这些特性具体还有哪些限制不得而知。不管千变万化,11g 如果能够提供 9iR2 的稳定程度就是万幸了。10g 是一个比较失败的版本,如果不算失败,就算是过渡版本好了。

--EOF--

Automated Workload Repository (AWR) 与 Active Session History (ASH) 是随着 Oracle 10g 的两个关键功能,可以说是性能优化的一个很大的进步,但是,用户使用这两个特性是要单独收取 License 费用的(Oracle 企业管理器Diagnostic Pack,价格不菲)。Pythian Group 的 Mark Brinsmead 日前发布了一篇 An Open Letter to Larry Ellison on AWR and ASH Licensing,阐述了 "这样收取 License 的方式导致用户接受 Oracle 优秀特性更慢"的观点。后面附有准备发给 Oracle CEO Larry Ellison 的公开信,正在倡议 DBA 签名。

当然,公开信的要求不是很过分的,仅仅是希望 Oracle 能够重新考虑修改 License 方式或者允许用户能够访问 底层视图以及 AWRASHAPI 即可。国外 DBA 的这份较真的劲儿值得学习。虽然,技术圈子里的这类公开信总有些自我炒作的嫌疑。

在过几天, 7 月 11 日, Oracle 11g 就要正式发布了,期待这封公开信能起到一定的效果。

--EOF--

Google 助力 MySQL

MySQL 应该给 Google 发感谢信: Google 在 Google Code 上发布的 Google Mysql Tools 使得 MySQL 在性能、可管理性、稳定性上都增色不少。

在该项目的首页将这个工具集分为三部分:

* mypgrep.py - a tool, similar to pgrep, for managing mysql connections
* compact_innodb.py - compacts innodb datafiles
by dumping and reloading all tables
* patches - patches to add features to MySQL 4.0.26 and MySQL 5.0.37

这份介绍似乎已经不能完全概括 Google Mysql Tools 了。现在的重点似乎是补丁包部分。根据版本号分为 MySQL4 与 MySQL 5,MySQL 5 的 Patch 现在很少,而 MySQL 4 部分内容真的比较丰富,关键改进列表:

* SemiSyncReplication - block commit on a master until at least one slave acknowledges receipt of all replication events.
* MirroredBinlogs - maintain a copy of the master's binlog on a slave
* TransactionalReplication - make InnoDB and slave replication state consistent during crash recovery
* UserTableMonitoring - monitor and report database activity per account and table
* InnodbAsyncIo - support multiple background IO threads for InnoDB InnoDB 异步IO的支持相信对性能会有很明显的提升
* FastMasterPromotion - promote a slave to a master without restart

MySQL 在联机备份方面是弱势,倒是期待 Google 也能在这个方面做出改进(我非常好奇对于 Google Checkout 数据库是如何备份的).

在 Code 上的另外一个 关键项目 Google Perftools 中的 TCMalloc 对 MySQL 的性能也有很大的改进,相信国内很多出色的 Web 2.0 公司都已经用到这个东西了吧。TCMalloc : Thread-Caching Malloc 号称是目前最快的 Malloc ,对于解决 MySQL 遇到的 Malloc 扩展问题有很大的影响。

没有 Google 的支持,相信 Firefox 不会有现在这么大的影响力。有了 Google 的支持, MySQL 会发展多快 ?

--EOF--

Updated: 2008 年 9 月,Google又发布了一系列的新 Patch

Oracle 10g R2 的 Data Pump 是一个好工具,弥补了传统 export/import 工具的很多不足。相关信息可以参考一下我以前对 Data Pump 的介绍

最近在 Linux 平台上经常遇到 ORA-39095 错误。这个错误。这个错误号,文档的解释:

ORA-39095:Dump file space has been exhausted: Unable to allocate string bytes
Cause: The Export job ran out of dump file space before the job was completed.
Action: Reattach to the job and add additional dump files to the job restarting the job.

这个解释只针对一般情况。我遇到的这个案例,目录的空间还有很多,可是也一样报错了。而且,一般在第 100 个 导出文件出错(更正:%U参数是2位,定长的,最大99)。开始以为是 Bug,可是遍查 Metalink,发现和 ORA-39095 错误有关只有两条信息,和我遇到的情况不符。

偶然在阅读 Oracle Database Utilities 手册的时候,发现了这一段话:

Because each active worker process or I/O server process writes exclusively to one file at a time, an insufficient number of files can have adverse effects. Some of the worker processes will be idle while waiting for files, thereby degrading the overall performance of the job. More importantly, if any member of a cooperating group of parallel I/O server processes cannot obtain a file for output, then the export operation will be stopped with an ORA-39095 error. Both situations can be corrected by attaching to the job using the Data Pump Export utility, adding more files using the ADD_FILE command while in interactive mode, and in the case of a stopped job, restarting the job.

真是孤陋寡闻了,我的并行度用的是 4 ,减小这个并行度,该错误不再出现。

You can supply multiple file_name specifications as a comma-delimited list or in separate DUMPFILE parameter specifications. If no extension is given for the filename, then Export uses the default file extension of .dmp. The filenames can contain a substitution variable (%U), which implies that multiple files may be generated. The substitution variable is expanded in the resulting filenames into a 2-digit, fixed-width, incrementing integer starting at 01 and ending at 99. If a file specification contains two substitution variables, both are incremented at the same time. For example, exp%Uaa%U.dmp would resolve to exp01aa01.dmp, exp02aa02.dmp, and so forth.

--EOF--

这可能是 Oracle 在 AIX 平台上最重要的一个潜在问题。

一般情况下,AIX 的逻辑卷前 4k 用于存储 control block (LVCB),在 Oracle 9iR2 之前,Oracle 软件自动跳过这 4k 而不用。这带来了一个潜在的问题,当 Oracle 的 db_block_size 大于 4k 的时候,一个 Block 可能跨在两个 PV/LUN/磁盘 上(如果做了条带化,那么将总有数据块跨在两个条带上--其实也还是将跨在不同的 PV/LUN/磁盘上。这样当系统崩溃的时候,很有可能造成大量的 IO 不完整,一个 PV 上 IO 写入,另一边可能未完成,启动 Oracle 的时候将会看到 ORA-1578 错误,这几乎是致命的。

为了解决这个问题,AIX 推出了 Big Volume Groups 作为应对。建立 Big VG 后,创建 LV 的时候可以通过 -T O 的参数强制征用 LV 的前 4K 空间, LVCB 的信息保存在 VGDA(volume group describe area) 里面。前 4k 空间被使用的 LV 有了一个新的设备子类型(devsubtype)标记: DS_LVZ,通过 lslv 可以看到。(Oracle 也在 9.2.0.3 之后自动识别 AIX 的新 LV 类型,直接开始使用 LV 的前 4K 空间)

对于 AIX 的可扩展性 VG,则默认创建的 LV 就会 DS_LVZ 类型,不使用 -T O 也是这样子。Big VG 可能只是一个过度类型。

在 IBM 的系统手册中可以看到:

The IOCINFO ioctl operation returns the devinfo structure, as defined in the /usr/include/sys/devinfo.h file

如何知道当前裸设备创建的时候使用了 -TO ? Oracle 10g 的文档中说 $ORACLE_HOME/bin/offset 工具可以做到。可是我居然找不到这个工具。莫非是忽悠人来着? 通过另一个工具可以看到相关信息:

$ dbfsize /dev/rfoo01_pay
Database file: /dev/rfoo01_pay
Database file type: raw device without 4K starting offset
Database file size: 920 8192 byte blocks


要想得到完美的东西太难了, AIX 在 BIG VG 上仍然还有很多问题,目前已知的当属这个“MKLV -TO ON BIG VOLUME GROUPS FAILS TO PUT SOME LV INFORMATION”最为严重--得不到正确的devsubtype 类型,Oracle 则会报告读取数据文件头错误,这个更要人命。

DBA 这个工作,还真是脑袋悬在腰带上,风险莫测。

--EOF--

Updated: offset 命令工具需要安装 RAC 组件才可用,Oracle 另外提供了一个补丁来弥补这个问题,在 Patch 3242957 中可以找到,直接解压缩,把工具提取出来即可用。

前几天收到了一封来自 SI Object Browser 公司人员的一封电子邮件,说这款来自日本的数据库工具正在中国寻找商业合作伙伴。(邮件里说是通过 ACE 的页面找到的我)

要不是收到这封邮件可能我还不知道 SI Object Browser 这款数据库工具。据说这个工具在日本市场"very popular":

SI Object Browser is a development tool for Oracle database, providing all required functions, SQL creation, Object creation, removal of stored program's bugs in the operation by GUI(Graphical User Interface), which can contribute to your database development productivity. And it prepares functions for DBA, data export, user monitoring and tracing. SI Object Browser provides and prepares any other many functions for Oracle development, and we've already distributed 90,000 licenses over in Japan since released in 1997.

以前倒是对来自日本的另外一个数据库性能优化工具 Performance Insight(PI) 挺有兴趣的,不过据我所知,这个 PI 在国内也没什么市场。还不如卖服务更容易让用户接受。

这些第三方 Oracle 开发工具,包括 Quest 的 Toad,国内的用户群体还是不小的,但是掏钱买 License 的寥寥无几,抛开国内用盗版的一贯习性,另外一个主要原因还是和价格策略有关吧。我们的收入毕竟和欧美的还有很大差距。

话说回来,如果国内有哪家代理商愿意与 SI Object Browser 合作,可以直接着他们联系,或者我代为转达。

--EOF--

关于归档

本页包含 Database 类别下的所有文章.

上一类别为 Arch.

Geek 为下一类别.

回到 首页 查看最近发表的文章或者查看所有 归档文章.