• 在Percona的5.1.53和5.5.8版本,开始将RT的统计内置到MySQL Server端。Thanks, Percona.

    Percona在提供了tcprstat工具统计RT时间之后,很快就在Percona Server中集成了响应时间统计的功能。这里介绍一下该功能,各位看官如果在犹豫选择Percona Server还是MySQL Community Server,这里给Percona Server加一个筹码。

    “响应时间”(Response time,后面简称RT)在数据库应用中,特别是OLTP的场景,可以说非常重要,不过,MySQL官方版本中一直没有加上这个统计功能。最早,社区开始尝试tcmdump+perl脚本的方式查看RT,后来告警一点用tcpdump+mk-query-digest,再后来Ignacio Nin和Baron Schwartz完成了tcprstat。

    在Percona的5.1.53和5.5.8版本,开始将RT的统计内置到MySQL Server端。

    1. 配置该功能

    这个是功能默认是关闭的,可以通过设置参数query_response_time_stats=1打开这个功能,这是一个动态参数,所以在服务器上可以很方便的打开或者关闭这个功能。可以通过命令SHOW QUERY_RESPONSE_TIME查看响应时间统计。 (more…)

  • 上图先。

    Semi-sync-why

    如果还不了解Semi-sync可以阅读(Manual | 概述

    1. 优点

    当事务返回客户端成功后,则日志一定在至少两台主机上存在。

    MySQL在加载并开启Semi-sync插件后,每一个事务需等待备库接收日志后才返回给客户端。如果做的是小事务,两台主机的延迟又较小,则Semi-sync可以实现在性能很小损失的情况下的零数据丢失。

    2. 缺点

    完成单条事务增加了额外的等待延迟,延迟的大小取决于网络的好坏。

    Semi-sync不是分布式事务,主库会在自己完成事务后,等待备库接收事务日志

    3. 主机Crash时的处理

    (more…)

  • 很早从su27那知道《攻壳机动队》,看了第一部后,就一发不可收拾,开始看第二部,看塔奇科马的日常,然后把几个剧场版和O.V.A也都下载下来看了。

    《攻壳》一共有两部TV版,三部剧场版,两部TV特别篇和一部OVA,还有一个小TV系列《塔奇科马的日常》。看到豆瓣上有一些朋友不知道合适的观看顺序,这篇博客就是把银幕上《攻壳》的放映顺序都理一下,如果对科幻、动漫都感兴趣的人都可以看看。

    historyofgis

    大图

    下面是整个《攻壳》的编年史:

    1989年4月22日,士郎正宗的《攻壳机动队》首次连载于讲谈社青年漫画月刊《Young Magazine海贼版》;每三个月一话,总共12话(参考
    (more…)

  • 从09年12月份MySQL5.5的第一个Release,再到去年12月的第一个GA,MySQL5.5平均一月一个小版本号的速度在默默更新。该版本最重要的特性目前仍是Semi-sync Replication,之前做了一个概述,这里将继续介绍如何安装、配置Semi-sync,后续还将继续介绍其性能和一些基本的代码实现。

    1. Semi-sync Repication的历史

    Semi-sync最早是由Google实现的一个补丁,代码主要由Mark Callaghan、Wei Li(@Google)等人贡献。Google原本是将需求提给Hekki的,但是后来等不及就自己实现了……。(现在Mark Callaghan已跳到Facebook,除了Google,他曾经还在Informix、Oracle工作过)

    在5.5之后由MySQL Replication Team按照Plugin的方式将代码移植过来,并将Semi-sync独立成MySQL的一个插件,主要代码移植者是Zhenxing He(参考)。

    2. 安装、配置Semi-sync Replication

    在两台主机上安装好MySQL5.5,编译好的插件在目录CMAKE_INSTALL_PREFIX/lib/plugin下(默认是/usr/local/mysql/lib/plugin)。例如这里编译是指定CMAKE_INSTALL_PREFIX为/home/mysql/mysql,则有:

    $pwd
    /home/mysql/mysql/lib/plugin
    $ls -a semisync_*
    semisync_master.so semisync_slave.so

    在主库初次启动时,执行如下语句加载semisync_master插件:

    mysql> INSTALL PLUGIN rpl_semi_sync_master SONAME ‘semisync_master.so’;

    备库上则加载semisync_slave插件:

    mysql> INSTALL PLUGIN rpl_semi_sync_slave SONAME ‘semisync_slave.so’;

    (more…)

  • 之前写过一篇Linux下编译安装MySQL,但是在5.5版本之后MySQL自动化建构工具从GUN Autotools换成了跨平台的Cmake系统,编译和配置和原来有些不同,这里做一个简单的小结。

    1. 安装CMake

    Cmake是跨平台的工具,如果之前就尝试过在Windows上编译MySQL的同学,就应该还记得CMake。

    我的环境是不自带CMake(环境:RHEL5.4,YUM仓库里面没有CMake),所以需要自己安装。安装过程简单、顺利,没有遇到任何依赖问题……:)

    $tar zxf cmake-2.6.4.tar.gz
    $cd cmake-2.6.4
    $./bootstrap
    $make
    $sudo make install

    CMake下载安装参考

    2. CMake编译MySQL 5.5
    tar zxf mysql-5.5.11.tar.g
    cd mysql-5.5.11
    CFLAGS=”-O3″ CXX=gcc
    CXXFLAGS=”-O3 -felide-constructors -fno-exceptions -fno-rtti”
    cmake . -LH|more //CMake下查看MySQL的编译配置
    cmake . -DCMAKE_INSTALL_PREFIX=/home/mysql/mysql -DEXTRA_CHARSETS=all
    make -j 8 //8核并行编译
    make install

    其中”ccmake . -D……”也可直接使用”cmake .”,这样会进入一个简单文本GUI界面进行MySQL编译参数配置;

    另外,原来的AutoTools和现在CMake配置参数的变化,在MySQL Forge的Autotools to CMake Transition Guide中可以查阅详细的对比说明。
    (more…)

  • 偶尔我们需要这样做。

    在一台主机上如果复制多个主库,可以很简单:在备库主机上启动多个MySQL实例(mysqld_muilt),每个实例使用一个端口,复制多台主库就可以了。但是如果希望复制过来的数据都在同一个实例中,事情就复杂了。

    1. 问题以及开源社区的尝试

    需求:多个主库都复制到一个备库,复制过来的数据都在一个实例中,这样实现对应用层的透明。目前,MySQL本身不提供这样的功能(考虑过,但一直未实现)。

    1.1 开源社区也有很多方案和想法,例如Tungsten replicator:可以支持异构数据复制,JAVA实现,数据量较大时,性能较差,而且MySQL版本更新较快,而该软件支持较慢;

    1.2 再如P.Linux的尝试:通过拉取多个主库上的Binlog在单个备库上应用的方式,对MySQL没有入侵,实现也较为简单。

    1.3 High Performance MySQL还可以通过多级复制的方式实现:例如有主库DB1、DB2,都需要复制到S1上,则先配置D2复制D1的全部数据,然后再从S1上复制D2的全部数据就可以了。整理需要注意D2上的log-slave-update需要打开,为了减少D2的压力,DB上复制过来的表可以全部使用Blackhole引擎

    1.4 另外,还有一些欠成熟的Patch实现。

    2. MySQL Federated引擎的“软链接”特性

    Federated引擎可以在本地数据库中创建一个远端数据表的“软链接”。这样,访问远端数据表就如同访问本地数据表。(这里远端可以是不同主机上的不同实例)

    se-federated-structure

    3. 使用Federated数据表实现多主一备

    例如,主库DB1,DB2,都需要复制到S1上,这里DB1,DB2,S1分别在主机H1,H2,H3上。首先,在主机H3(S1所在的主机)上其另外起两个MySQL实例S2、S3,分别复制主库DB1和DB2,然后在实例S1上建立多个Federated表关联S2、S3中的数据表(相当于在S1中建立到S2、S3的软连接)。

    Federated-Muilt-master

    这时应用,连接到S1,就可以同时透明的访问到DB1、DB2中的实时数据表了。

    4. 一些说明

    4.1 上面描述的方法,也可以直接在S1上建立到DB1、DB2各个表的软连接,但是为了最大程度的减少对主库的影响,最好如上多配一层备库。

    4.2 最简单的可以直接在备库上配置多个实例,让应用连接多个实例就好了,无需上面这么复制的配置。

    参考文献:

    1. MySQL Manual: The FEDERATED Storage Engine

    2. Post of MySQL Forums : Multiple masters to single slave

    3. 通过tungsten replicator实现mysql多主一从的备份架构

    4. Is it possible to do N-master => 1-slave replication with MySQL

    5. MySQL Multi-Master – Single-Slave – Replication