Tag Archives: MySQL

从 MySQL 迁移到 Oracle (傻瓜篇)

如果用关键字 “MySQL 迁移 Oracle” 在网上搜索，基本上得到的内容都是关于从 Oracle 如何迁移到 MySQL 的，而从 MySQL 迁移到 Oracle 的信息则少之又少。

抛开那些手工一点点做的方法不谈，网络上也可以找到一些第三方工具来做这个事情，免费的? 我只找到了一个，那就是 Oracle SQL Developer 了。如果采用比较傻瓜化的方法，不妨考虑这个工具。在这个工具之前，Oracle 提供了单独的 Migration Workbench 工具。在 SQL Developer 1.2 版中，Oracle 干脆把这个功能集成进来。

数据流示意图:

Source Database(MySQL/DB2 etc.) --->SQL Developer (ETL)-->Target Database (Oracle)

MySQL JDBC 下载地址：

http://dev.mysql.com/downloads/connector/j/5.0.html

配置 MySQL JDBC:

还需要注意一点就是需要调整一下迁移时候的参数:

剩下的事情就简单了，配置到不同数据库以及准备存放 Metadata 数据库的信息。然后就可以迁移了。不赘述。

这个方法只是够傻瓜化，由于运行机制的限制，速度不是非常好。对于迁移过程中产生的变化数据，也无能为力。

–EOF–

DRBD 提升了 MySQL 的集群能力

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

注意到主备服务器之间的 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–

FeedLounge 使用 PostgreSQL 的经验

这是我唯一看到的 Web 2.0 公司使用 PostgreSQL 的，可惜还失败了。

FeedLounge 是一个提供在线 RSS Reader 的站点。已经在今年 6 月 1 日黯然宣布失败。这里不去讨论他们失败的各种原因，只说说从他们 Blog 上看来的关于他们选择数据库的经验。

FeedLounge 在数据库的使用上路线是这样的：

MySQL(MyISAM) --> MySQL(InnoDB) --> PostgreSQL

最初是 MyISAM 方式，迁移到 InnoDB ，数据库从大约 1G 膨胀超出了 10G，而且发现引发了新的性能问题，经过尝试发现不能解决后，迁移到 PostgreSQL，总存储从 InnoDB 方式的 34G 缩小到 9.6G,而且，恢复时间也只是原来的大约 1/5 (导出用 Mysqldump,载入用 psql ). 此外，关于内存利用方式上也有一些差异, MySQL : innodb_buffer_pool 6GB + O_DIRECT flush, PostgreSQL 设置上限 2G，只用了 1.2 G。遗憾的是，看不到切换前后性能数据更为详细的对比。

FeedLounge 当时每天要处理的事务量：每天超过 400 万次查询，超过 200 万次的更新/插入操作，高峰期每秒钟有 2000 个更新/插入操作(这应该是批处理阶段)。硬件如何呢? 数据库服务器的硬件：两路 Opteron CPU，8 GB 内存， 6 SATA 7200RPM 16MB 硬盘， RAID 5 ，控制器有 128M. 可以看出来了吧， 7200 转的硬盘 + RAID 5 根本不适合这样的应用。从这一点上说，数据库类型切换其实解决不了本质的问题。

另外看到的有趣参考信息：

FeedDigest 在当时每天有超过 400 万次的查询，超过 200 万次插入，机器硬件只用了双奔四 CPU(2.8GHz) ，1G内存

–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