今天的故事简单有趣，你绝对没有遇到过。当我们把网卡的MTU值从默认的1500，调整为3000/6000/9000后，复制十分诡异，搞得我云里来雾里去的，先记录下：

以下命令可以动态修改MTU值及时生效，和查看状态的一些命令：

shell> ifconfig eth1 mtu 3000 up (永久生效可以增加MTU=XXXX到配置文件ifcfg-ethN中)

shell> ip link list eth1
      » 继续阅读 MTU值的调整导致MySQL复制异常

不久前的一次机房网络故障，再一次对我们在Heartbeat+DRBD+MySQL数据库架构运维水平的一个考验，之前不止一次的测试与线上部署，还有之后大言不惭的关于该架构组件的所谓深入理解，在这一次不经意的意外面前又是“很囧”的收场，慌张呀！这次断网导致H-D-M全线异常，真是千载难逢，都让我们赶上啦lol: 下面就把这次的小幸运小幸福和大家分享下，以下是按照问题处理的先后顺序依次讲述。
      » 继续阅读 Heartbeat+DRBD+MySQL Replication故障处理

日常工作中，对于MySQL主从复制检查，一方面我们要保证复制的整体结构是否正常，另一方面需要检查主从数据是否保持一致。对于前者我们可以通过监控复制线程是否工作正常以及主从延时是否在容忍范围内，对于后者则可以通过分别校验主从表中数据的md5码是否一致，来保证数据一致，可以使用Maatkit工具包中的mk-table-checksum工具去检查。在这里，我只想讨论下关于如何检查主从延时的问题。

判断主从延时，通常有两个方法：1. Seconds_Behind_Master  vs  2. mk-heartbeat，下面具体说下两者在实现功能的差别。
      » 继续阅读 如何监控主从之间的延时:seconds_behind_master OR mk-heartbeat

在实际应用中，可以根据具体的情况灵活地将主/从结构进行变化组合，下面将给大家介绍一些常见的复制架构，万变不离其宗。在进行各种部署之前，我们还需要遵守这么几条规则：

1. 一个从服务器只能有一个主服务器。

2. 一个主服务器可以有多个从服务器。

3. 无论是主服务器还是从服务器，都要确保各自的Server ID唯一。

4. 一个从服务器可以将其从主服务器获得的更新事件，传递给其它的从服务器；同时，这个从服务器也可以成为其他从服务器的主服务器。

（一）Master-MultiSlave

如图1所示。

图1 单Master/多Slave架构

其实，这种架构就是最基础的主从结构的水平扩展，所有的Slave之间没有任何联系，它们都各自独立的与唯一的Master进行连接。这种架构适用于读操作频繁写操作相对比较少的应用。
      » 继续阅读 MySQL Replication中常见的7种复制架构

1、复制进程
MySQL的复制（Replication）是一个异步的复制，从一个MySQL instace（称之为Master）复制到另一个MySQL instance（称之Slave）。实现整个复制操作主要由三个进程完成的，其中两个进程在Slave（Sql进程和IO进程），另外一个进程在 Master（IO进程）上。

要实施复制，首先必须打开Master端的binary log（bin-log）功能，否则无法实现。因为整个复制过程实际上就是Slave从Master端获取该日志然后再在自己身上完全顺序的执行日志中所记录的各种操作。

Master上的bin-log文件的大小可以通过max_binlog_size来设置，默认是1GB，最多不能超过4GB。如果写入的bin-log超过设置的最大值的话，bin-log会被拆分。你需要重新写另外一个新的log。旧的bin-log文件不会自动被删除，你需要定期的清理他们，可以使用命令“PURGE BINARY LOGS”，

详细地命令见http://dev.mysql.com/doc/refman/5.1/en/purge-binary-logs.html

复制的基本过程如下：
1)、Slave上面的IO进程连接上Master，并请求从指定日志文件的指定位置（或者从最开始的日志）之后的日志内容；
2)、Master接收到来自Slave的IO进程的请求后，通过负责复制的IO进程根据请求信息读取制定日志指定位置之后的日志信息，返回给Slave 的IO进程。返回信息中除了日志所包含的信息之外，还包括本次返回的信息已经到Master端的bin-log文件的名称以及bin-log的位置；
3)、Slave的IO进程接收到信息后，将接收到的日志内容依次添加到Slave端的relay-log文件的最末端，并将读取到的Master端的 bin-log的文件名和位置记录到master-info文件中，以便在下一次读取的时候能够清楚的告诉Master“我需要从某个bin-log的哪个位置开始往后的日志内容，请发给我”；
4)、Slave的Sql进程检测到relay-log中新增加了内容后，会马上解析relay-log的内容成为在Master端真实执行时候的那些可执行的内容，并在自身执行。

实际上在老版本的MySQL的复制实现在Slave端并不是两个进程完成的，而是由一个进程完成。但是后来发现这样做存在较大的风险和性能问题，主要如下：

      » 继续阅读 [Shasha系列]MySQL Replication(复制)基本原理

一群海豚在属于自己的海滩上自由的玩耍，尽管只是一个方盒的大小，但是设备一样的齐全，同样可以玩的很开心，这就是我今天要说的——MySQL Sandbox2.0，3.0也将要推出。

MySQL Sandbox是一个非常简单快捷部署MySQL技术的一个工具套件，它可以让你在同一台机器上，更加快速的无干扰的去达到你的最终目的，比如，作为软件测试人员只是要测试软件系统的良好性不需要在mysql的安装上纠缠过多，不需要对MySQL数据库有太多的经验；有的时候我们只是对新版本的一些特性感兴趣，尽可能快速结束安装部署，而是重点地去体验它的一些特性；可以使用sandbox最短时间部署我们需要的数据库应用架构(ReplicationCluster)，以配合我们的现有的应用系统进行性能测试。

MySQL Sandbox 快速，是用秒来衡量的。下面我们就来感受一下sandbox给我们的F1般的速度,你可以在每次安装前使用time命令统计出real/user/sys三项的使用时间。

      » 继续阅读 MySQL大实验场 — 快速体验各版本MySQL