MSN上的闲聊
A: 现在搞起mysql了？
B: 嗯
A: 现在比较多的项目在使用mysql了，所以现在mysql也变成一种趋势了
B: 在互联网行业，MySQL分布式是大势所趋
A: 呵呵，是的，现在我们这边也有很多mysql的项目在线上
B: 不过目前国内MySQL的交流是不太多
B: 而且要招一个合适的人相当的难
A: 呵呵，是的，很多mysql都是从Oracle转过来或者是带着做的，不过有Oracle的技术，转或者带着做问题还不是很大
A: 对于互联网的应用来说，DB这块主要的还是HA这块是重中之中，Mysql这块在分布式来说做的还行
B: 基本的技术原理什么的是没啥难的，不过要用好，尤其是分布式架构，要做好还是需要功力的
A: 呵呵，是的，对于技术这东西很多还是考经验和实践，上了几个项目后会有很大的积累
B: 嗯，是这样的
B: 去年我们开始推MySQL的时候，开发人员都有很大的担心和抵触
B: 现在是想不让他们用都不行，哈哈
A: 哈哈，其实mysql用起来还行，有些数据仓库还使用的呢
A: 但是对于大容量，高并发的事务处理，mysql还是有待提高的
A: 现在很多做互联网的，除了核心库外，别的基本上都在往这上面转，其实很多时候还是人的心理面在作梗
B: 分布式，其实把很多东西都交给应用架构了
B: 对于数据库本身，要求反倒很低了，就是用来存放持久数据而已
A: 没错，那样DB真的是DB了，就是简单的存储了
A: 哈哈，没错，哎，很多东西大家的想法很一直
B: 嗯，技术就那么点，关键是把想法落实，做出东西来
A: 是的，所以说你们那边还是比较幸福的
很多东西好落实
B: 我们也是在不断摸索
B: 不过摸索的过程，是比较长经验值的
A: 是的，摸索只是一种开始，实施的过程才是真正验证摸索的阶段，如果只有摸索，没有实践，那也只是空话，所以说你们那边是幸福的，很多时候有开始，有结束，但是很多时候，很多单位不是这样，摸索永远当作一种摸索，没有结束，呵呵
http://www.mysqldba.net/viewthread.php?tid=18&extra=page%3D1
用Amoeba构架MySQL分布式数据库环境
Amoeba是一个类似MySQL Proxy的分布式数据库中间代理层软件，是由陈思儒开发的一个开源的java项目。其主要功能包括读写分离，垂直分库，水平分库等，经过测试，发现其功能和稳定性都非常的不错，如果需要构架分布式数据库环境，采用Amoeba是一个不错的方案。目前Amoeba一共包括For aladdin,For MySQL和For Oracle三个版本，本文主要关注For MySQL版本的一个读写分离实现。实际上垂直切分和水平切分的架构也相差不大，改动几个配置就可以轻松实现。
下图是一个采用Amoeba的读写分离技术结合MySQL的Master-Slave Replication的一个分布式系统的架构：
Amoeba处于在应用和数据库之间，扮演一个中介的角色，将应用传递过来的SQL语句经过分析后，将写的语句交给Master库执行，将读的语句路由到Slave库执行（当然也可以到Master读，这个完全看配置）。Amoeba实现了简单的负载均衡（采用轮询算法）和Failover。如果配置了多个读的库，则任何一个读的库出现宕机，不会导致整个系统故障，Amoeba能自动将读请求路由到其他可用的库上，当然，写还是单点的依赖于Master数据库的，这个需要通过数据库的切换，或者水平分割等技术来提升Master库的可用性。
Amoeba可以在不同机器上启动多个，并且做同样的配置来进行水平扩展，以分担压力和提升可用性，可以将Amoeba和MySQL装在同一台机器，也可以装在不同的机器上，Amoeba本身不做数据缓存，所以对于内存消耗很少，主要是CPU占用。对于应用来说，图中的三个Amoeba就是三台一模一样的MySQL数据库，连接其中任何一台都是可以的，所以需要在应用端有一个Load balance和Failover的机制，需要连接数据库时从三台中随机挑选一台即可，如果其他任何一台出现故障，则可以自动Failover到剩余的可用机器上。MySQL的JDBC驱动从connector-j 3.17版本起已经提供了这样的负载均衡和故障切换的功能，那么剩下的事情对于应用来说就很简单了，不需要做太多的改动就能搭建一套高可用的MySQL分布式数据库环境，何乐而不为？
参考链接：
Amoeba开发者博客
Amoeba下载
Amoeba文档
JavaEye上关于Amoeba的讨论贴
MySQL5.1新特性（一）日志的增强
对于MySQL，很多印象其实都是来自比较老的4.x版本，实际上MySQL在后续的5.0，5.1和6.0版本中还是做出了很多的改进，特别是原来一些动不动要重启的操作，慢慢的都可以在线做了，如果要做企业级数据库，在线操作的支持是必不可少的。由于我们在产品库中大量开始使用5.1，所以打算写一个系列短文，介绍一些个人觉得比较实用的新特性。因为MySQL这样的开源软件，版本分支比较多，所以每篇文章涉及的一些小版本可能不太一样。
MySQL有很多种日志，包括error log，general query log，binary log，slow query log等。在以前的版本，这些日志的开启或者关闭，都是需要重启服务器的，而且都是记录到日志文件。从MySQL5.1.6版开始，general query log和slow query log开始支持写到文件或者数据库表两种方式，并且日志的开启，输出方式的修改，都可以在Global级别动态修改。
如果说日志是写到文件还是表，对于DBA来说不是那么在乎的话，那么可以动态的开启关闭日志真的可以说是DBA们梦寐以求的。尤其是slow log query，以前一直在头疼，开启吧，可能影响性能，不开吧，对于一些性能差的SQL又没有其他好用的捕获方式。因为开还是不开，涉及到重启服务的问题。
下面演示一下通过设置几个Global级别参数来开启关闭general query log和slow log query的过程：
root@NinGoo>select version(); +---------------+ | version() | +---------------+ | 5.1.25-rc-log | +---------------+ 1 row in set (0.00 sec)
设置日志输出方式为文件
root@NinGoo>set global log_output=file; Query OK, 0 rows affected (0.00 sec)
设置general log和slow query log的日志文件路径
root@NinGoo>set global general_log_file='/tmp/general.log'; Query OK, 0 rows affected (0.00 sec) root@NinGoo>set global slow_query_log_file='/tmp/slow.log'; Query OK, 0 rows affected (0.00 sec)
开启general log和slow query log，相应的，关闭只要设置参数为off
root@NinGoo>set global general_log=on; Query OK, 0 rows affected (0.04 sec) root@NinGoo>set global slow_query_log=on; Query OK, 0 rows affected (0.02 sec)
如果设置log_output=table的话，则日志结果会记录到名为gengera_log和slow_log的两张表中，这两张表的默认引擎都是CSV，其实就是将日志保存为CSV文件格式了。当然，也可以将这两张表改为MyISAM引擎，这不是问题。
更多关于MySQL5.1日志的新特性，请参考MySQL 5.1 Reference Manual
Drizzle:MySQL的瘦身运动
在Google Blogsearch中搜索MySQL关键字，发现一条有意思的消息，MySQL技术总监Brian Aker在OOSCON (O’Reilly Open Source Convention) 上宣布要推出MySQL的瘦身版本Drizzle，将4.1版本后逐步加入的一些高级特性如存储过程，视图等从核心代码剔除，改为可选模块，同时精简存储引擎的支持。毕竟不是所有的应用都需要那些特性，而且代码越多，稳定性也将受到更大的威胁，精简重构对于那些只需要最简单的select/insert/update/delete的用户来说，倒不失一个好消息。
在Sun收购MySQL后，有传言说Sun打算闭源部分代码。现在MySQL又准备推出基于GPL v2的开源版本Drizzle，这和红帽的Redhat企业版+Fedora社区版的策略何其相似，也从侧面印证了Sun闭源部分代码的传言可能是确有其事了。进入2008年后，云计算的概念红的发紫，Drizzle的出生也不能不借助云计算的影响力，据说这个项目的主要面向“Web基础架构后端和云计算组件”，但我看是醉翁之意不在酒吧，将社区版独立一个Drizzle出来，企业版才好名正言顺的走向盈利的大道嘛，只是不知道目前的社区版本将会何去何从呢？
