前几日有人在论坛上发了下面这个问题

2.4.4 和2.2.21比较

举得还蛮有意思的，这里写出我的解决方案

hiro@v-pc:~$ echo $a
2.3.4
hiro@v-pc:~$ echo $b
2.1.9
hiro@v-pc:~$ echo -e “$a\n$b” | sort -V | head -n 1 | grep -q “$a” && echo “$a < $b” || echo “$a > $b”
2.3.4 > 2.1.9
hiro@v-pc:~$ b=’2.11.2′
hiro@v-pc:~$ echo -e “$a\n$b” | sort -V | head -n 1 | grep -q “$a” && echo “$a < $b” || echo “$a > $b”
2.3.4 < 2.11.2

P.S.

抗议 老张，现在怎么没有代码编辑插件了？

对于MySQL的安装我们熟悉的不能在陌生了，但是呢，当随着MySQL版本不断更新升级，从之前的5.1，到中间过渡的5.5，再到现如今让人夸赞的5.6.10，其实不同版本的mysql_install_db的初始化db的操作也在悄然发生的变化，正因为这个微小的变化，在我们原来的安装步骤下，你就会不小心遇到标题上的这个Error提示，那么究其原因就往下看吧。
      » 继续阅读 InnoDB: Error: Table “mysql”.”innodb_table_stats” not found.

相关参数

binlog-checksum={NONE|CRC32} —  NONE表示binlog  中的事件里面不记录checksum值，保持与老版本兼容；而CRC32则在事件中加入用来确认事件是否正常的checksum值。

master-verify-checksum={0|1} –  该参数用来判断主库写入到binlog中的事件是否正常，Dump Thread用来将主库更新事件读出发给从库的I/O Thread，当它读出事件时会进行checksum校验，对于复制来说这此判断不太需要，只需要在复制端判读出过来的事件事件是否正常即可，默认设置为0关闭checksum检查；另外，当我们执行命令SHOW BINLOG EVENTS的时候也会触发checksum校验。

slave-sql-verify-checksum={0|1} – 该参数用来判断从库SQL Thread从relay log中读出的事件是否正常，默认设置为1。

Checksum校验过程

      » 继续阅读 MySQL5.6复制之Replication Event Checksums

相关参数

binlog_order_commits  — 控制事务的提交顺序，1为和binlog的写入顺序一致，0为事务并行进行；一般情况下两者在性能上并没有明显差别。

binlog_max_flush_queue_time – 是指在flush queue里扫描的时长。

WHY 2PC

      » 继续阅读 MySQL5.6复制之Binary Log Group Commit

备份上的差异

mysqldump –set-gtid-purged = on

在mysqldump备份里面就会多出这么几行：

SET @MYSQLDUMP_TEMP_LOG_BIN = @@SESSION.SQL_LOG_BIN;

SET @@SESSION.SQL_LOG_BIN= 0;

SET @@GLOBAL.GTID_PURGED=’42954c98-89f8-11e2-8133-00e081b9892e:1-7′;

      » 继续阅读 MySQL5.6复制之GTID使用技巧(Updated until 0403)

MySQL 5.5引入了半同步复制（Semi-synchronous Replication），以下是对于半同步复制的认知和理解：

1. 半同步启动需要主从两端都需要加载安装各自对应的semi模块，从库端支持半同步功能的数量至少一台；主库端当一个事务成功提交后，并不及时反馈给前端用户，该线程会被临时block，等待由从库端返回确认该条事务也同时成功写入到relay log中的receipt（回执确认），这时主库线程才返回给当前session告知操作完成，半同步复制并不关心在从库一端该事务是否都被执行并被提交完成。
      » 继续阅读 MySQL半同步复制(Semisynchronous Replication)

年初时，有幸代表MySQL中国用户组参加了在Oracle全球总部举行的用户组Leader大会。

下面是大会对参加此会议的中国Leader的采访。

MHA是一位日本MySQL大牛用Perl写的一套MySQL故障切换方案，来保证数据库系统的高可用。近期，在田老师的推动下，开始一步步深入了解这个HA方案，并也计划在公司线上尝试部署。下面的东西是这段时间的学习笔记和个人理解，没有具体的实战经验，只是人为测试模拟故障的发生，通过日志来分析MHA背后的自动切换过程。
      » 继续阅读 MHA自动Failover过程解析(updated)

之前写过两篇关于MooseFS的相关概念以及操作管理的BLOG，我们可以看到MFS一些好的地方，比如：通过copy数来保证数据的可靠存，当MFS系统中有个别chunkserver宕机发生，也不会影响应用的正常使用；同时，相比ext3它还能节省存储空间。这里说到，“可靠”，并非这个系统就真的如想象一样，和NFS相比的确，多份copy确实可靠了不少，但是它们都有一个共同的问题，那就是主控server的单点问题。MFS系统中，即便有metalogger server的这个作为master的角色，但问题依然存在。下面就说说使用中的体会。
      » 继续阅读 DRBD使MooseFS跑得更安全

从5.5.16开始，在MySQL的商业化版本中将Thread Pool作为plugin提供官方功能支持。在之前的版本中，线程处理模式包括两种：no-threads(单线程处理，多用于debug)、one-thread-per-connection（每个请求对应一个线程，目前被作为默认值）；在支持thread pool功能的版本中，thread_handling则需设置为dynamically-loaded。
      » 继续阅读 MySQL为什么要引入Thread Pool的线程处理模式