版本号的比较

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

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.

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

InnoDB: Error: Table “mysql”.”innodb_table_stats” not found.

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

MySQL5.6复制之Replication Event Checksums

相关参数

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校验过程

replication_process


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

MySQL5.6复制之Binary Log Group Commit

相关参数

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

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

WHY 2PC

innodb_2pc


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

MySQL5.6复制之GTID使用技巧(Updated until 0924)

Note: 今天当我再次看到这篇文章时,觉得之前的测试与理解很是垃圾,请跳过,发现有些东西并没有理解,下面不负责任的文字请大家谅解,稍后我会再次进一步学习,重新更新。抱歉!!!

 

备份上的差异

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 0924)

MySQL半同步复制(Semisynchronous Replication)

MySQL 5.5引入了半同步复制(Semi-synchronous Replication),以下是对于半同步复制的认知和理解:

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

Oracle 用户组Leader大会

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

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

MHA自动Failover过程解析(updated)

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

DRBD使MooseFS跑得更安全

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

MySQL为什么要引入Thread Pool的线程处理模式

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