orczhou.com

  • Xtrabackup Tips

    Percona are doing great job on Xtrabackup which help us a lot. We use it on most of our MySQL server, and it works quite fine. Xtrabckup not only helps us make the daily backup(sometimes recovery), but also help a lot setup the replication with less impact on the online server.

    It is pleasure to share my experience here,which may make Xtrabackup works better.

    1. Is the process of “copy-back” necessary?

    Although the wiki tells us do the “copy-back” after the “apply-log”, but people found it is not necessary. Actually it will take a lot of time if you have a huge databases(e.g. > 50G).

    Here is the usual process to make recovery from a tar backup,which I did in the last month.

    * Extraction of the tar stream:

    date && tar -izxvf xtrabak_20100309_0200.tar.gz && date
    Wed Mar 10 15:17:32 CST 2010
    Wed Mar 10 16:10:01 CST 2010

    (more…)

  • DTCC关于MySQL的未来

    在这次数据库技术大会会议结束的时候，有一个简单的圆桌会议，由大辉主持，里面讨论了关于MySQL前景的话题，几位与会的嘉宾给出了一些值得思考的观点，这里分享给大家（这里把脑子中记得都写下来，所以不是原话）：

    all

    宁海元@淘宝：对于MySQL我简单的说说我们的现状，淘宝现在已经有几百台MySQL的主机了，到今年年底这个规模还在非常快速的增长。有这些的用户，有这样的使用规模，有这样的市场，相信MySQL也会有相应的发展。

    盖国强@恩墨：未来不可预测。当初Oracle产品开发之初，Larry当时愿望是希望未来公司能够发展到50人，但是现在看看Oracle的规模（编者注：即时是Larray Ellison这样的人，对未来的发展趋势也是一样预料不准的）。最后，MySQL也罢，此时此刻，选择对你合适产品。

    徐景春@盛大：关注的是数据本身的存储方式，而不是某一个数据库，无论MySQL也好Cassandra也好，稳定、合适的性价比存储我们的数据才是关键的。

    （图片来源：http://dtcc.it168.com/3.html；如有疑问联系我）

    谭俊青@爱可生：早些时候，InnoDB被Oracle收购，InnoDB发展明显缓慢，虽然最近Plugin有一些改进，但多是情况又都是迫于其他开源社区、团体的压力。所以MySQL的前景到底如何，仍然有很多堪忧的地方。不过好在现在开源社区非常积极活跃，也希望国内也能在开源上有所贡献。

    崔玉明@Tencent：无论怎样的底层结构，永远都是用于支持上层业务。关于开源，希望自己、团队在未来的6个月能有所贡献。

    (另曝小道消息：Tencent可能会有自己的RDBMS。)

    你怎么看？

  • InnoDB Plugin特性介绍-1

    迫于开源社区、团体（Google Facebook Percona Xaprb等）的巨大压力，InnoDB Plugin相比Built-in版本有了很大的提升，这些提升多数来自开源社区贡献的代码，虽然本身也有一些改进。

    1. 关于Fast locking

    在多个线程并发访问相同资源的时候，需要使用一些InnoDB实现的互斥量（mutex）和读写锁（read/write lock）。在Unix-like平台上，InnoDB是通过Pthread的互斥量（这是POSIX标准的一部分）来实现的。在现代OS和硬件平台中，一般都有了更有效的替代方案，多数情况下这些替代方案使用更少的CPU指令和时钟周期来完成这些互斥处理。
    (more…)

  • FireFox+支付宝登录框

    在众多支付平台中，无疑支付宝是最好用的，支持的商户、银行也是最多的。不过在FireFox下，支付宝的登录框，用起来有一点点不方便。

    背景：我是不用鼠标的，需要鼠标操作的时候，就用小红点代替之，所以移动光标的操作代价相对较大。

    现象：在FireFox下打开支付宝页面（控件已安装），填写“账户名”，按TAB键焦点转移到密码框，输入“登录密码”。对于一般的表单，这时候使用回车键就可以提交了。不过，在支付宝的这个登录页面，怎么按回车都没用。

    zhifubaologin-5

    接着，在Firefox下尝试登录百付宝和财付通。百付宝是正常的，回车后每次都能正常提交表单；财付通很杯具，刷新首页后焦点不会自动跳到输入框，更别说使用TAB和回车提交了（很大概率发生），但是如果运气好，回车提交表单也不会有任何问题。不过财付通需要多输入一个验证码，这也可能是财付通绕过回车问题的办法：最后一个输入框是普通输入框，而不是控件。

    其他办法：在支付宝首页，虽然在输入完密码后，立刻按回车是无效的，但可以通过再按一次TAB键，将焦点移到“登录”按钮上，然后回车就可以了。

    最后：也许，我的要求苛刻了点~~，毕竟支付宝除了支持Firefox，还是国内唯一支持Chrome浏览器的。说到Chrome再唠叨几句，Chrome下别说回车提交，现在就连TAB键都不能使用，这是很费劲的。难道这是Chrome自己内伤吗？（截图内容来自支付志）

    zhifubaologin-4

    貌似这个问题在“日程”上很久了。

    PS:作为一个支付宝的普通用户，上面是我的一些体验

    UPDATE:Firefox版本3.5.8；Chrome版本5.0.342.8Beta；OS版本WinXP.SP3

  • InnoDB Plugin新特性：压缩表

    Plugin的一个重要的特性就是增加了压缩存储。对于数据中有很多Long column(包括TEXT BLOB或者大VARCHAR)的场景能够大幅节约空间，并提升效率。

    1. 谁需要压缩？

    在InnoDB中，是以16K的页（Page）为基本的存储单位的。我们知道，InnoDB是的数据是在Clustered index中存储的，在Secondary index中仅存储对应数据的PK。Clustered index和Secondary index都是B-Tree结构的，所以对InnoDB数据页和索引页的压缩很大程度上就是对B-Tree节点页的压缩。

    在InnoDB中，除了B-Tree节点页，还有一类数据页（Page），称为“overflow page”。当需要存储Long column时，如果当前页能够完全存储全部字段时，则存储在当前页中；如果当前页不足以存储全部，则InnoDB选择最长的字段，将其存储到一个单独的页中，我们称这样的页为“overflow page”，而原数据页仅仅需存储一个20Bytes的指针。参考下图：

    InnoDB_overflow_page

    所以InnoDB除了有上面的B-Tree页外，InnoDB还存储overflow页。事实上，需要压缩的数据页也就是这两类，InnoDB为了获得更好的效率，针对这两类数据页的压缩是使用不同的策略的。

    (more…)

  • InnoDB Plugin文件格式(概述)

    本文将介绍InnoDB Plugin数据表格式的基本概念。

    1. 配置参数innodb_file_format

    这是一个很容易混淆的概念。目前，在InnoDB Plugin（1.0.6）配置文件中innodb_file_format支持两种：Antelope/ˈæntɪləʊp/、Barracuda/ˌbærəˈkjuːdə/。他们分别是两种文件格式的代号，在未来版本中，InnoDB将继续延续这种代号机制，它们会是Antelope, Barracuda, Cheetah, Dragon, Elk, Fox等等。

    Antelope_Barracuda

    (more…)