10月20日，Monty专门撰文解释了MariaDB商标相关的协议，也解释了背后这么做的原因和历史。本文也顺便介绍了一下MariaDB的代码分发协议。

MariaDB商标讨论很早之前邮件组就有，例如：Jeremy Cole的邮件The MariaDB Foundation and MariaDB trademark?，Federico Razzoli的邮件trademarks，Mark Callaghan也关注过这个问题：Google search for "mariadb trademark"。因为一些原因，MariaDB商标归属一直都没有明确对外说明，这次算是敲定了。

MariaDB Corporation和MariaDB Foundation

先解释两个组织或公司：MariaDB Corporation和MariaDB Foundation。

MariaDB Corporation Ab(有时也叫MariaDB Corporation): 是一家商业公司(stock company)，前身是SkySQL，是一家支持MariaDB，MySQL培训、咨询的商业公司，提供MariaDB Enterprise和MariaDB Enterprise Cluster等服务。

MariaDB Foundation: 致力于推广、保护、改进MariaDB的代码、社区、和相关生态系统。是一个非盈利组织，在特拉华州(delaware)注册。

虽说是两个独立的组织，其核心都是MariaDB。现在MariaDB Foundation的临时董事(Directors)是如下四人：Rasmus Johansson (chair)，Michael "Monty" Widenius，Jeremy Zawodny，Sergei Golubchik，除了Jeremy Zawodny是就职于Craigslist.com，其他人都就职于MariaDB Corporation Ab。[......]

Read more

mysqladmin是MySQL一个重要的客户端，最常见的是使用它来关闭数据库，除此，该命令还可以了解MySQL运行状态、进程信息、进程杀死等。本文介绍一下如何使用mysqladmin extended-status(因为没有"歧义"，所以可以使用ext代替)了解MySQL的运行状态。

1. 使用-r/-i参数

使用mysqladmin extended-status命令可以获得所有MySQL性能指标，即show global status的输出，不过，因为多数这些指标都是累计值，如果想了解当前的状态，则需要进行一次差值计算，这就是mysqladmin extended-status的一个额外功能，非常实用。默认的，使用extended-status，看到也是累计值，但是，加上参数-r(--relative)，就可以看到各个指标的差值，配合参数-i(--sleep)就可以指定刷新的频率，那么就有如下命令：[......]

Read more

如果需要恢复的二进制日志较多，较复杂，强烈建议使用MySQL自身复制来恢复binlog，而不要使用mysqlbinlog。

在MySQL手册中一直是推荐使用mysqlbinlog工具来实现指定时间点的数据恢复，事实上，这是一个经常"让人郁闷"的办法。更好的办法是，使用MySQL内部复制线程中的SQL Thread来做恢复。

这个idea来自Lazydba同学；在Google稍作搜索，在Xaprb上Baron Schwartz也很早提到了使用类似的方法来恢复binlog，在那篇讨论中，还可以看到Jeremy Cole也提到：使用MySQL手册中推荐的方法是困难重重的，而且mysqlbinlog这个办法从逻辑上来说也是一个错误--因为这样MySQL不得不在两个不同的地方实现一套相同的逻辑，最终难免会出错。使用mysqlbinlog来恢复，你可能会需要以下“让人郁闷”的问题：

(*) Max_allowed_packet问题
(*) 恼人的Blob/Binary/text字段问题
(*) 特殊字符的转义问题
(*) 没有"断点恢复"：执行出错后，没有足够的报错，也很难从失败的地方继续恢复

1. 如何操作

本文不打算写一个step by step的文档，只介绍主要的思路和粗略的操作步骤。

1.1 将binlog作为relay log来执行

优点：实施简单；缺点：需要关闭一次数据库(不确定不关闭数据库行不行)；

思路：直接将要恢复的binlog拷贝到relay log目录，并修改slave-info相关的文件，让MySQL把binlog当做relay log来执行

简单的操作步骤：[......]

Read more

在你的程序(或者工程)中，如果编译阶段需要检测当前环境中是否存在MySQL客户端相关的库文件时，你可以使用Autoconf来帮你完成这个工作，轻盈、优雅、无痛。阅读本文需要了解简单GNU Autoconf使用。

1. 本文的目标

目的：编译时，根据configure参数(如果有--with-mysql)，选择性编译对应的MySQL相关的功能。

实现：使用已经写好的m4脚本：ax_lib_mysql.m4

2. 如何利用Autoconf实现

大部分你想到的事情都已经有人做过尝试了。这件事情也不例外，Autoconf中有很多脚本和指令帮你做事情。这里，需要使用ax_lib_mysql.m4来帮助我们。先把该文件放到程序/工程目录中，并在configure.ac中新增如下指令来检测MySQL库文件和版本：

说明：AX_LIB_MYSQL()设置了三个变量，可以在Makefile.am中直接使用，分别是MYSQL_CFLAGS、MYSQL_LDFLAGS、MYSQL_VERSION，另外还会在config.h中预定义宏HAVE_MYSQL；AM_CONDITIONAL(...)则会根据是否需要开启MySQL支持，来设置变量BUILD_MYSQL_SUPPORT，这个变量可以在Makefile.am中使用。

在程序源代码中一般有两种方式可以获取HAVE_MYSQL宏的方式：一个是直接包含config.h；另一个是在你程序的CFLAGS中新增-DHAVE_MYSQL。(注意：有的变量是可以在Makefile.am中使用，有的则是可以在C源代码中使用)[......]

Read more

前面一篇介绍了如何最大限度的榨取SCP的传输速度，有了这个基础，就可以进一步的使用压缩来加速传输速度了。只使用scp，传输速率最快约90MB，本文通过压缩将把最快传输速率提升到约250MB/s(包括解压的过程)。

1. 结论

使用tar+lz4+ssh的方式能够获得最大的传输性能：

time tar -c sendlog/|pv|lz4 -B4|ssh -c arcfour128  \
-o"MACs umac-64@openssh.com" 10.xxx.xxx.36 "lz4 -d |tar -xC /u01/backup_supu"
3.91GiB 0:00:16 [ 249MiB/s] 

real	0m16.067s
user	0m15.553s
sys	0m16.821s

249MB/s，妥妥的。是最原始scp(40MB/s)的6倍，原来400GB传输需要约3小时，现在只需要27分钟了。

注1：lz4在解压方面的优异表现，使得他在本案例中非常重要。如果无需解压的传输，则可以考虑使用pigz/pbiz2

注2：使用pv观察，网络流量约80MB，所以使用nc替换ssh并不会有明显的性能提升

注3：lz4压缩使用-B4(64KB块大小)，解压使用-B7(4MB块大小)，是本案例的测试最优值[......]

Read more

当需要在机器之间传输400GB文件的时候，你就会非常在意传输的速度了。默认情况下(约125MB带宽，网络延迟17ms，Intel E5-2430，本文后续讨论默认是指该环境)，scp的速度约为40MB，传输400GB则需要170分钟，约3小时，如果可以加速，则可以大大节约工程师的时间，让攻城师们有更多时间去看个电影，陪陪家人。

1. 结论

声明：这里给出的测试数据不具有一般性，仅供参考。测试与数据本身特性有很大关系，本文使用InnoDB的redo log作为测试数据。

* 改变ssh加密算法，可以让速度更快；通常，越弱的加密算法，速度越快

* 通常压缩会降低scp速度，但这与数据类型有很大关系，对压缩率非常高的数据启用压缩，可以加速

* 压缩级别对传输效率影响很小

* 用于完整性校验的不同MAC( message authentication code)算法，对性能约有10%-20%的影响。

所以，简单尝试如下，让你的SCP速度double一下：

注：启用压缩使用参数： -o "Compression yes"

2. 测试数据：加密算法和压缩的影响

这里对比了12种ssh中实现的加密算法和是否使用压缩的传输效率，测试文件使用的是InnoDB的1GB*4的日志文件(注意：不同类型的文件测试结果会很不同)，这里纵坐标单位为MB/s，数据分为压缩传输和不压缩传输两组：

原始数据：scp_speed.txt

[......]

Read more