http://www.infoq.com/cn/presentations/tuniu-multiple-data-centers-distributed-database-synchronization

解决跨数据中心的数据同步和一致性问题，实现跨机房的高可用访问（比如中国特殊网络状况，提供多个数据中心的情况下，解决数据的可用性、一致性）。

levelDB采用递增的数字作为版本号不适合大规模分布式系统用于底层存储使用，可以用当前的时间戳(微秒)作为版本号，这样在实现多版本控制的时候就非常方便了。

Golang1.1昨天发布，性能提升不少。让我想起去年写的mysql-proxy，于是拿出来又改了一下调用最为频繁的一个函数，发现性能已经非常理想。这里放出来给有兴趣的朋友试用。
目前支持的功能是读写分离（非事务，如果用事务的话不会分发到slave上）和slave的负载均衡，未做失效检查。另外prepare可能会有问题。
如果有什么需求可以后续添加，golang改起来非常方便，当初这个proxy我也就1个礼拜完成的。

下载地址：http://www.mysqlab.net/products/mysql-proxy/lbproxy64.tar.gz （linux 64位）
(有需要win版本的可以密我)

配置：
1. 需要配置用于连接proxy的用户名和密码（sha1(plain password)）
2. 需要配置连接后端master和slave的用户和密码（sha1(plain password))
3. slaves需要按照proxy.ini 格式写，因为解析ini文件的目前还没有容错
(本来是打算配置用web界面来做的，被其他事情给耽搁了)

启动：
目前启动方式很山寨
cd /path/to/proxy && ./proxy
(这个容易改，我已经有现成的python manager，套用过来就行)

大家有什么反馈可以q我或者这里留言（第一次需要审核，防止垃圾广告。）

之前的DMB系统，因为一直没有放出linux版本，使用范围比较窄。

这次应朋友们的要求，计划推出for linux单机版,暂时命名为LBOMP,现截图一张先睹为快。

后续推出的工具/系统 有：

MySQL多线程复制外挂
MySQL多主一从外挂
MySQL读写分离代理（这儿发布过）
MySQL健康检查及高可用组件
大规模MySQL集中管理平台

lbmysqlping (LegendBase MySQL Ping) is a tool that does MySQL service availability check for MySQL HA solution.

Of course, it could be used to monitor MySQL servers availability. If some server down, LBMySQLping will run “Down” command that could send email or message to your mobile.

有不少朋友在做MySQL数据库高可用(Heartbeat,keepalived)和主从负载均衡(LVS,F5,A10等)的时候都面对MySQL服务可用性检测的问题.

检测可用性面对的几个问题不太容易解决:

• 端口能连上,但是SQL语句很可能无法执行,其实这时候MySQL服务是不可用的
• 连上了,SQL语句执行堵塞,长时间不能返回,因为MySQL是堵塞式的
• MySQL Slave延时太大,应该从路由表里面清除

而且我了解到的有不少人都是用检测端口的方法,这是有风险的.

今天贡献的lbmysqlping通过可配置的方式,能够灵活的对MySQL服务进行检测,如果出现异常\超时或者Slave延时超过配置大小,可以执行指定的失效命令,当服务恢复可用的时候又可以执行恢复命令.

另外lbmysqlping还可以做简单的报警系统，配置好默认信息后，其他realserver 只需要配置ip地址即可，如果端口不一样，改下端口。然后在down命令和up命令里面填上相关的脚本或者报警程序，这样一个简单的MySQL服务可用性报警系统就出来了，简单、高效。

配置文件格式如下:

… 【阅读全文·MySQL实验室】

Go语言1.0出来之后,原来可用的MySQL驱动在新版本上基本不可用了,于是这几天自己写了个简单的MySQL的驱动,暂不支持prepare,没有implement sql/driver.　或许有能用的上的朋友,所以分享出来.　先介绍用法,后面提供下载链接.
先直接上例子

… 【阅读全文·MySQL实验室】

今天很高兴得知Go1 release, 其实我一只在等它正式发布,因为我用go语言自己实现了一个MySQL代理,命名为LegendBase Proxy for MySQL(LPM),等Go1 release之后,我也可以尽快release出来了.

代码摘录:

写这个的初衷是因为除了部分程序开发者自己实现了读写分离\或者采用sharding方式之外,还有大量的程序是针对单一的MySQL数据库接口.　然而随着业务量的增加,db压力增大,单台db没法承载,需要扩展MySQL数据库为主从架构,这时候需要代理层来分发读写,因为改造程序的代价往往太大.

新开发的MySQL proxy的配置如下:

其中配置的密码是明文密码的sha1, 防止非相关人员获取数据库的密码,安全性能得到一定的保障.
通过其他的配置也可以看出proxy实现的功能,即能够配置多个slave,并且能够指定它们的权重.

这几天CSDN数据库明文密码泄密闹得满城风雨，人人自危。大家开始关注网络安全和隐私问题。由这次的问题，对加密验证过程我也思考过，有没有一套相对安全的存储和验证方法？这里我根据各种验证方法，确实总结了一套可行且相对安全的存储和验证方法，且看我细细道来，最后提出MySQL当前验证方法的改进。– by 谭俊青

一个系统对用户请求的合法性验证都是通过sessionid来判断的，这个层面的攻击和破解这里不涉及，我们只关心在session建立前的验证过程。密码存储的方式和验证方法大致可以归结为以下几种：

1. 密码明文存储。比如CSDN的做法，用户登陆系统的时候直接提交明文密码，跟数据库中保存的密码进行比较，如果一直，验证通过，建立session。这时最简单，也是最傻的一种做法，所以导致了这次的泄密。对于密码一致的用户已经体会到了它的危害严重性。
2. 密码加密存储。对用户密码进行加密存储，登陆验证的过程跟上面的验证过程类似，只是对密码进行了加密，或者对存储的密文进行了解密，然后验证。这种方法稍微提高了一定的安全性，但是还远远不够，没有从根本上解决问题，因为如果黑客拿到了密文，然后破解加密算法，可以解密所有的密文，获得所有用户的明文密码，还会导致像今天CSDN这样的局面。
3. 密码单向hash存储。这个应该说在根本上解决了问题所在。比如存储md5(password),sha1(password)，验证时只需要比较用户输入的密码的hash值跟存储的是否一致即可验证。当然这里问题又来了因为有人会提出md5破解的问题，破解碰撞的概率现在还是相当低的，比中5亿彩票大奖的概率要低得多。但是现在有很多现有的密码字典，并且已经生成了hash值，值需要比较hash值，即可获得等价的登陆密码。因此我们对这个方法进行改进，得出下面的方法。
4. 密码还是hash存储，不过是采用hash(hash(passwordd)+salt)的方式。这里salt可以在注册是随机生成，也可以取巧用用户名，这样可以在验证的过程增加随机串，而不用将salt输出止客户端。

对第4种方法进行变种，可以得到很多验证方法，都相对安全可靠得多，但是都存在一个问题，这个问题在mysql4.1之前的版本也存在着，就是如果有人得到存储的hash值，即可以模拟登陆，并验证通过。

现在我们回到MySQL密码的存储和验证过程。在4.1之前，mysql的验证方法相对简单，方法如下：

1. 首先server给client发送一个随机串
2. client将用户输入的password的hash值对随机串进行加密，并将加密串发送给server
3. server用存储在user表中的password hash串对之前发送给client的随机串进行加密，生成加密串
4. server对接收道的加密串和生成的加密串进行比较，如果一致，验证通过。

这样的验证方法看似比较安全可靠，即使你监听网络也不会获得password或者其hash值。但是如果有人通过其他途径，获得了password的hash值，那么就可以模拟登陆系统，因此我们需要对验证过程进行改进。下面介绍mysql4.1之后的密码存储和登陆验证过程：

• server存储mysql.user.Password = sha1(sha1(password))
• server 发送随机串random_string至client
• client 计算
  • stage1_hash  = sha1(password) –password为用户输入的明文密码
  • token = sha1( random_string + sha1(stage1_hash)) xor stage1_hash
• client 将 token 发送给server
• server 计算
  • stage1_hash_2 = token xor sha1( random_string + mysql.user.Password)
• sever 比较 sha1(stage1_hash_2) 跟 mysql.user.Password 即可验证

这个验证过程看似复杂，其实整个过程就是为了保证 sha1(password)不被监听到，用随机串进行了干扰。至此我们的密码存储方式和验证方法的安全性都得到了极大的提升。 当然我们发现mysql 4.1之后的密码存储还是有点小问题，没有加salt，因此存在一定的风险，可以建议官方版本改进，比如将 salt 用用户名代替，整个验证过程几乎不用大的改动。

Manager端下载

http://download.mysqlab.net/download/DMB/dmbmanager.zip
安装：直接解压 dmbmanager.zip(比如解压至 c:\dmbmanager) ，然后打开 c:\dmbmanager 执行 setup.exe
依次执行 保存配置项、初始化系统、获取key文件，然后将申请获得的dmb.key文件保存到安装目录，即对应的目录 c:\dmbmanager
然后点启动服务。

Agent端下载

http://download.mysqlab.net/download/DMB/dmbagent.zip

安装：直接解压 dbmagent.zip 至安装目录，比如 c:\dmbagent
配置安装目录下的 dmb.ini文件，将url地址改为Manager端安装的地址
然后执行 install.bat (win7右键以管理员身份执行)

系统管理

Manager安装好之后 用浏览器打开

http://localhost:8288/ (远程用 http://ip:8288/)进行管理
默认用户名和密码为：
用户:root
密码: mysqlab.net
进入系统之后，在右上角的系统配置里面修改用户名、密码等相关信息。
其中smtp用于报警发送邮件，收件人地址及为用户信息里配置的邮件地址。

补充：
1：目前DMBManager和DMBAgent只支持Windows平台。
2：本机备份的时候IP地址请填127.0.0.1
3：实例添加/编辑的时候，my.ini 请填写windows地址，比如：c:\windows\my.ini
4：备份配置的时候，本地备份目录请填写windows目录，比如：c:\dbbackup

版本更新主要解决的问题：
1：默认配置有些填充的是linux格式目录，造成部分用户混淆，先改成windows格式；
2：v2.2可以直接获取key文件。

欢迎大家使用，如有问题请直接反馈在本blog，我会及时给予回复和和更新。

很多企业，特别是中、大型互联网企业都在大量的使用MySQL数据库，并且绝大部分情况下使用的都是InnoDB存储引擎。使用InnoDB存储引擎有很多因素，比如事务安全、自动恢复、行锁、在线备份等等特性。

在MySQL数据库应用和运维中，除了数据库状态和性能监控之外，数据库的备份一直没有很好的工具去管理，DMB数据库监控及灾备系统就是为解决这一矛盾而诞生的。

DMB系统中备份配置中总共有7种备份模式，下面将针对它们分别介绍，什么样的情况下应该选择什么样的备份模式，以实现最高效的备份，且尽可能的减少对业务的影响。

• MYSQLDUMP:
  • 调用MySQL系统的mysqldump命令进行备份。其中在只有InnoDB的情况下，可以实现在线热备，不会影响线上业务；在有MyISAM表的情况下，在备份过程当中会增加全局锁，这时候系统是只读的。备份之后会生成 master信息，可以通过备份的SQL文件和master_info.sql 创建slave服务。
• IBBACKUP_ALL:
  • 备份所有的InnoDB和MyISAM表，在没有MyISAM表的情况下，备份过程中不会对线上业务造成影响，属于在线热备；如果存在MyISAM表，那么在备份完InnoDB之后，备份MyISAM的过程中MySQL数据库是只读的。备份会生成master_info.sql，用于创建slave。
• IBBACKUP_INNODB:
  • 针对只有InnoDB表的情况，不会备份MyISAM表，属于在线热备，不会造成写堵塞。备份会生成master_info.sql，用于创建slave。
• IBBACKUP_NONBLOCK:
  • 针对只有InnoDB的情况，不备份MyISAM表，属于在线热备，对系统不造成任何堵塞。备份不生成master_info.sql，不能用该备份创建slave，只用于备份用。
• XTRABACKUP_ALL: 同 IBBACKUP_ALL
• XTRABACKUP_INNODB: 同 IBBACKUP_INNODB
• XTRABACKUP_NONBLOCK: 同 IBBACKUP_NONBLOCK

说明：

1. 备份模式中以IBBACKUP开头的调用的是 ibbackup，以XTRABACKUP开头的调用的是xtrabackup。
2. 所有备份都包含MySQL数据库系统库mysql和配置文件my.ini
3. 在不清楚的情况下备份模式可以选择MYSQLDUMP、IBBACKUP_ALL、XTRABACKUP_ALL 。
4. IBBACKUP、XTRABACKUP都属于物理备份，恢复速率比MYSQLDUMP要大，能缩短恢复时间。
5. 其中 IBBACKUP_NONBLOCK、XTRABACKUP_NONBLOCK不会调用flush操作，因此在任何情况下都不会影响在线业务。而其他几种备份模式因为为了取得master info信息，有些会在瞬间加上全局锁然后释放，在极端情况下会对数据库造成一定影响。具体情况以及针对现有MySQL的patch会在后续的blog中加以阐述。

作者：谭俊青@MySQL实验室（转载请保留该行及作者信息和原文链接，谢谢！）

NoSQL最近很火，因为它在K/V存储的优异性能表现，催生出很多产品，比如：Memcached、MongoDB、Redis、TT等等. 然而他们或多或少都有自己的某些缺陷，比如存在单点、数据安全持久化等等。然而这些随着新的技术和思路的在MySQL上面产品化，这些东西会被慢慢取代，MySQL重回她的王者地位。在这之前我说过Memcached会被MySQL+handler socket取代，现在情况有所变化，为了兼容现有大量的Memcache客户端，将handler socket用memcached替换掉，就出现了如下构架：

MySQL+InnoDB with Memcached

MySQL+InnoDB with Memcached 具有大量的优势： … 【阅读全文·MySQL实验室】

在去年MySQL用户大会的时候，Sun发布了MySQL5.5。今天Oracle MySQL在MySQL User Conference 2011（MySQL用户大会）又扔出了个重磅炸弹，MySQL5.6发布。

列举下MySQL5.6部分新特性：

• InnoDB现在可以限制大量表打开的时候内存占用过多的问题（比如这里提到的）(第三方已有补丁)
• InnoDB性能加强。如分拆kernel mutex;flush操作从主线程分离;多个perge线程;大内存优化等
• InnoDB死锁信息可以记录到 error 日志，方便分析
• MySQL5.6支持延时复制，可以让slave跟master之间控制一个时间间隔，方便特殊情况下的数据恢复。
• 表分区功能增强
• MySQL行级复制功能加强，可以降低磁盘、内存、网络等资源开销（只记录能确定行记录的字段即可）
• Binlog实现 crash-safe
• 复制事件采用crc32校验，增强master/slave 复制数据一致性
• 新增 log_bin_basename （以前variables里面没有binlog位置信息，对数据库的监管很不方便）

更多信息见：http://dev.mysql.com/doc/refman/5.6/en/mysql-nutshell.html

为了这系统宅了很多个周末，又一个小长假过去了, DMB v2.1终于可以那得出手了，现在分享出来让朋友们使用，希望能得到更多更好的建议。DMB 对InnoDB存储引擎支持在线热备(ibbackup, xtrabackup等)，还可以根据用户需求选择备份模式，是否加锁获取Master信息等。
“DMB数据库监控及灾备系统(监控、备份) for MySQL” 简单介绍见 http://www.mysqlab.net/tool/dmb/

Manager端下载

– ———————
update: 2011/10/1
根据朋友们的反馈信息，这里补充几点。
1：目前DMBManager和DMBAgent只支持Windows平台。
2：本机备份的时候IP地址请填127.0.0.1
3：实例添加/编辑的时候，my.ini 请填写windows地址，比如：c:\windows\my.ini
4：备份配置的时候，本地备份目录请填写windows目录，比如：c:\dbbackup
– ———————

作者：谭俊青@MySQL实验室
测试日期：2010/01/28

硬件环境：
– ———————————————————————-
CPU: Intel(R) Xeon(R) CPU E5620 @ 2.40 GHz ( x 2)
Memory: 32GB
Disk: 300GB*4, Raid 10 , BBU(wb)
– ———————————————————————-

MySQL配置：
– ———————————————————————
innodb_buffer_pool_size = 8G
innodb_additional_mem_pool_size = 20M
innodb_log_file_size = 128M
innodb_log_buffer_size = 8M
innodb_flush_log_at_trx_commit = 2
innodb_lock_wait_timeout = 50
innodb_file_per_table = 1
innodb_thread_concurrency = 0
query_cache_size = 0
– ———————————————————————

sysbench r/w 测试
– ———————————————————————
oltp-table-size=1000000
oltp-test-mode=complex
– ———————————————————————

测试结果如下：
– ———————————————————————

– ———————————————————————

结论：
– ———————————————————————
在低并发情况下，MySQL5.1跟MySQL5.5性能持平，而实际应用中大部分并发数都低于10，因此绝大部分用户没有必要立即更换至5.5版本；
在高并发情况下，MySQL5.5的性能优势明显。