• 1. 概览
• 2. IO thread, SQL thread状态变更
• 3. Master_Log_File，Read_Master_Log_Pos；Relay_Log_File，Relay_Log_Pos；Relay_Master_Log_File，Exec_Master_Log_Pos的具体位置
• 4. 参考资料

1. 概览

  mysql的replication复制可以通过show slave status;
  我们天天都在用，但是对它的理解却不见的很深，
  特别把show slave status的每一项都解析一下
  如下是一个普通的MySQL show slave status的输出：
  admin@localhost : (none) 05:59:24> show slave status\G
  *************************** 1. row ***************************
                 Slave_IO_State: Waiting for master to send event
                    Master_Host: 172.20.164.67
                    Master_User: repl
                    Master_Port: 3306
                  Connect_Retry: 60
                Master_Log_File: mysql-bin.001896
            Read_Master_Log_Pos: 226029100
                 Relay_Log_File: mysql-relay-bin.002014
                  Relay_Log_Pos: 87341525
          Relay_Master_Log_File: mysql-bin.001896
               Slave_IO_Running: Yes
              Slave_SQL_Running: Yes
                Replicate_Do_DB:
            Replicate_Ignore_DB:
             Replicate_Do_Table:
         Replicate_Ignore_Table:
        Replicate_Wild_Do_Table:
    Replicate_Wild_Ignore_Table:
                     Last_Errno: 0
                     Last_Error:
                   Skip_Counter: 0
            Exec_Master_Log_Pos: 226029100
                Relay_Log_Space: 87341723
                Until_Condition: None
                 Until_Log_File:
                  Until_Log_Pos: 0
             Master_SSL_Allowed: No
             Master_SSL_CA_File:
             Master_SSL_CA_Path:
                Master_SSL_Cert:
              Master_SSL_Cipher:
                 Master_SSL_Key:
          Seconds_Behind_Master: 0
  Master_SSL_Verify_Server_Cert: No
                  Last_IO_Errno: 0
                  Last_IO_Error:
                 Last_SQL_Errno: 0
Last_SQL_Error:

做了一个列表，简单注释了一下各个字段的意思，如下：

  这么多信息，有一些是一看就知道是什么意思的字段。
  其他的至少可以分为以下几个专题：

• IO thread, SQL thread状态变更
• Master_Log_File，Read_Master_Log_Pos；Relay_Log_File，Relay_Log_Pos；Relay_Master_Log_File，Exec_Master_Log_Pos的具体位置
• Replicate_Do, Replicate_Ignore 讨论
• mysql ssl连接
• replication文件 master.info, relay.info和连接信息解析
• Seconds_Behind_Master 精确性
• replication until和复制延迟控制
• skip counter忽略event计数和精确性本文只涉及第一和第二个议题

2. IO thread, SQL thread状态变更

1. IO线程状态变更,对应show slave status的Slave_IO_State字段

状态变更图如下：

代码请参考sql/slave.cc的handle_slave_io函数

1. SQL线程状态变更,对应服务器上SQL线程的State字段，通过show processlist查看

状态变更图如下：

代码请参考sql/slave.cc的handle_slave_sql函数

3. Master_Log_File，Read_Master_Log_Pos；Relay_Log_File，Relay_Log_Pos；Relay_Master_Log_File，Exec_Master_Log_Pos的具体位置

1. 定义

• Master_Log_File，Read_Master_Log_Pos 记录了IO thread读到的当前master binlog文件和位置，对应master的binlog文件和位置。
• Relay_Log_File，Relay_Log_Pos记录了SQL thread执行到relay log的那个文件和位置，对应的是slave上的relay log文件和位置。
• Relay_Master_Log_File，Exec_Master_Log_Pos记录的是SQL thread执行到master binlog的文件和位置，对应的master上binlog的文件和位置。

1. 日志文件介绍需要明确这几个值的意思，我们首先需要了解binlog日志文件和relay log日志文件的具体结构。binlog的文件格式可以参考 Mats Kindah和Lars Thalman的binlog API文档。binlog的event可以参考我之前的blog和binlog events 介绍
   • binlog数据文件示例binlog文件和relay log文件都可以用mysqlbinlg工具来打开。下图是一个mysqlbinlog解析普通的binlog文件出来的文本文件：我们这里主要是row方式的binlog。

     注意：binlog的event语句开始位置就是二进制binlog文件的字节偏移位置。而且根据上一个event的end_log_pos可以找到下一个event开始的位置，如上图所示。

• relay log数据文件示例binlog文件和relay log文件都可以用mysqlbinlg工具来打开。下图是一个mysqlbinlog解析普通的relay log文件出来的文本文件：relay log和binlog记录方式基本相同，最大的不同就是end_log_pos记录的是master的binlog文件中event的位置，而不是relay log自己event的位置。如图所示，上一个event的end_log_pos和下一个relay log event开始的位置不一样。

为什么需要这样设置？原因很简单，就是为了方便找到master binlog的位置，在slave上，记录relay log 下一个event的开始偏移意义不大，但是如果记录了master binlog的偏移量，我们就可以在SQL thread中明确我们执行到master的某个binlog的哪个位置了。那么是哪个binlog列。我们找到relay log的最前面。

如图所示，每个relay log开头都有这么一个rotate event，也就是当前master的binlog文件名。引用一下Automated master failover的一页PPT如下。

这里列出了Read_Master_Log_Pos，Relay_Log_Pos，Exec_Master_Log_Pos 的具体位置。

• IO thread 把所有从master读到的binlog记录到本地的binlog中，所以relay log的最后一个event的end log_pos就是Read_Master_Log_Pos
• SQL thread 按照transaction来执行，所以Exec_Master_Log_Pos对应relay log中最后一个事务event的end_log_pos，这个位置对应的是master的binlog的位置。
• Relay_Log_Pos 记录的是SQL thread执行的event在relay log中结束位置，这个才是relay log的偏移量。

4. 参考资料

mysql reference IO 线程状态

mysql reference SQL 线程状态

mysql reference show slave status

binlog events

binlog API

Automated master failover

没有做什么异常处理，利用bc来计算

function calc_sum()
{
    if [ $# -lt 1 ]; then
        echo 0
        return 0
    fi

    local __SUM_STR="scale=2;"
    local __VAR_COUNT=$#
    for i in `seq 1 $#`; do
        __SUM_STR="$__SUM_STR \$$i +"
    done

    #### cut the last  +
    __SUM_STR=${__SUM_STR%+*}

    #### cal the sum
    eval echo "\"$__SUM_STR\"" | bc
}

1. 首先为参数设置中的对应符号，函数设置

1. 在my.cnf中可以设置的参数如下

     # innodb plugin
     innodb_read_io_threads=1
     innodb_write_io_threads=4
     innodb_io_capacity=10000
     innodb_file_format=barracuda
     innodb_file_format_check=ON
     innodb_strict_mode=1
   

   innodb_adaptive_flushing=false

     # percona
     innodb_page_size=8k
     innodb_extra_rsegments=8
     innodb_use_purge_thread=4
     innodb_stats_update_need_lock=0
     innodb_fast_checksum=1
     log_slow_verbosity=full
     userstat_running=1
     enable_query_response_time_stats=1
     # percona For SSD
     #innodb_adaptive_checkpoint=3
     innodb_flush_neighbor_pages=0
   

附录1 MySQL 5.1.20 Beta包含的事件类型

下面列举了各种MySQL的事件类型（代码拷贝自MySQL 5.1.20的源代码）：

enum Log_event_type

{

/*

Every time you update this enum (when you add a type), you have to

fix Format_description_log_event::Format_description_log_event().

*/

UNKNOWN_EVENT= 0,

START_EVENT_V3= 1,

QUERY_EVENT= 2,

STOP_EVENT= 3,

ROTATE_EVENT= 4,

INTVAR_EVENT= 5,

LOAD_EVENT= 6,

SLAVE_EVENT= 7,

CREATE_FILE_EVENT= 8,

APPEND_BLOCK_EVENT= 9,

EXEC_LOAD_EVENT= 10,

DELETE_FILE_EVENT= 11,

/*

NEW_LOAD_EVENT is like LOAD_EVENT except that it has a longer

sql_ex, allowing multibyte TERMINATED BY etc; both types share the

same class (Load_log_event)

*/

NEW_LOAD_EVENT= 12,

RAND_EVENT= 13,

USER_VAR_EVENT= 14,

FORMAT_DESCRIPTION_EVENT= 15,

XID_EVENT= 16,

BEGIN_LOAD_QUERY_EVENT= 17,

EXECUTE_LOAD_QUERY_EVENT= 18,

TABLE_MAP_EVENT = 19,

/*

These event numbers were used for 5.1.0 to 5.1.15 and are

therefore obsolete.

*/

PRE_GA_WRITE_ROWS_EVENT = 20,

PRE_GA_UPDATE_ROWS_EVENT = 21,

PRE_GA_DELETE_ROWS_EVENT = 22,

/*

These event numbers are used from 5.1.16 and forward

*/

WRITE_ROWS_EVENT = 23,

UPDATE_ROWS_EVENT = 24,

DELETE_ROWS_EVENT = 25,

/*

Something out of the ordinary happened on the master

*/

INCIDENT_EVENT= 26,

/*

Add new events here – right above this comment!

Existing events (except ENUM_END_EVENT) should never change their numbers

*/

ENUM_END_EVENT /* end marker */

};

附录2 MySQL 5.1.20 Beta各事件的附加事件头长度

下面列举了MySQL 5.1.20 Beta各事件的附加事件头长度（拷贝自MySQL源代码）：

/* event-specific post-header sizes */

// where 3.23, 4.x and 5.0 agree

#define QUERY_HEADER_MINIMAL_LEN (4 + 4 + 1 + 2)

// where 5.0 differs: 2 for len of N-bytes vars.

#define QUERY_HEADER_LEN (QUERY_HEADER_MINIMAL_LEN + 2)

#define LOAD_HEADER_LEN (4 + 4 + 4 + 1 +1 + 4)

#define START_V3_HEADER_LEN (2 + ST_SERVER_VER_LEN + 4)

#define ROTATE_HEADER_LEN 8 // this is FROZEN (the Rotate post-header is frozen)

#define CREATE_FILE_HEADER_LEN 4

#define APPEND_BLOCK_HEADER_LEN 4

#define EXEC_LOAD_HEADER_LEN 4

#define DELETE_FILE_HEADER_LEN 4

#define FORMAT_DESCRIPTION_HEADER_LEN (START_V3_HEADER_LEN+1+LOG_EVENT_TYPES)

#define ROWS_HEADER_LEN 8

#define TABLE_MAP_HEADER_LEN 8

#define EXECUTE_LOAD_QUERY_EXTRA_HEADER_LEN (4 + 4 + 4 + 1)

#define EXECUTE_LOAD_QUERY_HEADER_LEN (QUERY_HEADER_LEN + EXECUTE_LOAD_QUERY_EXTRA_HEADER_LEN)

#define INCIDENT_HEADER_LEN 2

post_header_len[START_EVENT_V3-1]= START_V3_HEADER_LEN;

post_header_len[QUERY_EVENT-1]= QUERY_HEADER_LEN;

post_header_len[ROTATE_EVENT-1]= ROTATE_HEADER_LEN;

post_header_len[LOAD_EVENT-1]= LOAD_HEADER_LEN;

post_header_len[CREATE_FILE_EVENT-1]= CREATE_FILE_HEADER_LEN;

post_header_len[APPEND_BLOCK_EVENT-1]= APPEND_BLOCK_HEADER_LEN;

post_header_len[EXEC_LOAD_EVENT-1]= EXEC_LOAD_HEADER_LEN;

post_header_len[DELETE_FILE_EVENT-1]= DELETE_FILE_HEADER_LEN;

post_header_len[NEW_LOAD_EVENT-1]= post_header_len[LOAD_EVENT-1];

post_header_len[FORMAT_DESCRIPTION_EVENT-1]= FORMAT_DESCRIPTION_HEADER_LEN;

post_header_len[TABLE_MAP_EVENT-1]= TABLE_MAP_HEADER_LEN;

post_header_len[WRITE_ROWS_EVENT-1]= ROWS_HEADER_LEN;

post_header_len[UPDATE_ROWS_EVENT-1]= ROWS_HEADER_LEN;

post_header_len[DELETE_ROWS_EVENT-1]= ROWS_HEADER_LEN;

/*

We here have the possibility to simulate a master of before we changed

the table map id to be stored in 6 bytes: when it was stored in 4

bytes (=> post_header_len was 6). This is used to test backward

compatibility.

This code can be removed after a few months (today is Dec 21st 2005),

when we know that the 4-byte masters are not deployed anymore (check

with Tomas Ulin first!), and the accompanying test (rpl_row_4_bytes)

too.

*/

DBUG_EXECUTE_IF(“old_row_based_repl_4_byte_map_id_master”,

post_header_len[TABLE_MAP_EVENT-1]=

post_header_len[WRITE_ROWS_EVENT-1]=

post_header_len[UPDATE_ROWS_EVENT-1]=

post_header_len[DELETE_ROWS_EVENT-1]= 6;);

post_header_len[BEGIN_LOAD_QUERY_EVENT-1]= post_header_len[APPEND_BLOCK_EVENT-1];

post_header_len[EXECUTE_LOAD_QUERY_EVENT-1]= EXECUTE_LOAD_QUERY_HEADER_LEN;

post_header_len[INCIDENT_EVENT-1]= INCIDENT_HEADER_LEN;

附录3 MySQL 5.1.20 Beta中各列在内部存储时可能的各种数据类型

enum enum_field_types

{

MYSQL_TYPE_DECIMAL = 0,

MYSQL_TYPE_TINY = 1,

MYSQL_TYPE_SHORT = 2,

MYSQL_TYPE_LONG = 3,

MYSQL_TYPE_FLOAT = 4,

MYSQL_TYPE_DOUBLE = 5,

MYSQL_TYPE_NULL = 6,

MYSQL_TYPE_TIMESTAMP = 7, // 4 from_unixtime(0x)

MYSQL_TYPE_LONGLONG = 8,

MYSQL_TYPE_INT24 = 9, //field_medium

MYSQL_TYPE_DATE = 10,

MYSQL_TYPE_TIME = 11,

MYSQL_TYPE_DATETIME = 12,

MYSQL_TYPE_YEAR = 13,

MYSQL_TYPE_NEWDATE = 14,

MYSQL_TYPE_VARCHAR = 15, //field_varstring

MYSQL_TYPE_BIT = 16,

MYSQL_TYPE_NEWDECIMAL = 246,

MYSQL_TYPE_ENUM = 247,

MYSQL_TYPE_SET = 248,

MYSQL_TYPE_TINY_BLOB = 249,

MYSQL_TYPE_MEDIUM_BLOB = 250,

MYSQL_TYPE_LONG_BLOB = 251,

MYSQL_TYPE_BLOB = 252,

MYSQL_TYPE_VAR_STRING = 253,

MYSQL_TYPE_STRING = 254,

MYSQL_TYPE_GEOMETRY = 255,

};

附录4 MySQL 5.1.20 Beta中各ROW_EVENT的m_flags包含的标志位

在MySQL 5.1.20 Beta中，各ROW_EVENT都含有m_flags标志位集合。可能的标志如下：

相关代码如下：

/*

These definitions allow you to combine the flags into an

appropriate flag set using the normal bitwise operators. The

implicit conversion from an enum-constant to an integer is

accepted by the compiler, which is then used to set the real set

of flags.

*/

enum enum_flag

{

/* Last event of a statement */

STMT_END_F = (1U << 0),

/* Value of the OPTION_NO_FOREIGN_KEY_CHECKS flag in thd->options */

NO_FOREIGN_KEY_CHECKS_F = (1U << 1),

/* Value of the OPTION_RELAXED_UNIQUE_CHECKS flag in thd->options */

RELAXED_UNIQUE_CHECKS_F = (1U << 2)

};

typedef uint16 flag_set;

/* Special constants representing sets of flags */

enum

{

RLE_NO_FLAGS = 0U

};

]]> http://hatemysql.com/2011/10/29/mysql%e4%ba%8b%e4%bb%b6%e7%b1%bb%e5%9e%8b%e5%92%8c%e6%96%87%e4%bb%b6%e5%a4%b4%e9%95%bf%e5%ba%a6/feed/ 0 http://hatemysql.com/2011/10/29/mysql-replication%e6%95%b0%e6%8d%ae%e5%a4%8d%e5%88%b6%e6%a0%bc%e5%bc%8f/ http://hatemysql.com/2011/10/29/mysql-replication%e6%95%b0%e6%8d%ae%e5%a4%8d%e5%88%b6%e6%a0%bc%e5%bc%8f/#comments Sat, 29 Oct 2011 02:00:15 +0000 pickup.lichun http://hatemysql.com/?p=191

MySQL 5.1的新特性
MySQL在版本5.1中增加了很多新特性，其中的row based replication是mmrd要求必须满足的条件。目前为止，也许是出于谨慎或者稳定性的目的，MySQL 5.1虽然已经出到版本5.1.26了，仍然是Release Candidate Development Release，不能用于生产环境。不过SUN和MySQL公司还是声称将于近期推出可供生产环境使用的Release版本。下面我们列出主要的MySQL的主要新特性并进行简单介绍。

Partitioning分区
数据库分区是一种物理数据库设计技术，虽然分区技术可以实现很多效果，但其主要目的是为了在特定的SQL操作中减少数据读写的总量以缩减响应时间。分区主要有两种形式：（这里一定要注意行和列的概念（row是行，column是列））
水平分区（Horizontal Partitioning）：这种形式分区是对表的行进行分区，通过这样的方式不同分组里面的物理列分割的数据集得以组合，从而进行个体分割（单分区）或集体分割（1个或多个分区）。所有在表中定义的列在每个数据集中都能找到，所以表的特性依然得以保持。举个简单例子：一个包含十年发票记录的表可以被分区为十个不同的分区，每个分区包含的是其中一年的记录。
垂直分区（Vertical Partitioning）：这种分区方式一般来说是通过对表的垂直划分来减少目标表的宽度，使某些特定的列被划分到特定的分区，每个分区都包含了其中的列所对应的行。举个简单例子：一个包含了大text和BLOB列的表，这些text和BLOB列又不经常被访问，这时候就要把这些不经常使用的text和BLOB了划分到另一个分区，在保证它们数据相关性的同时还能提高访问速度。
在数据库供应商开始在他们的数据库引擎中建立分区（主要是水平分区）时，DBA和建模者必须设计好表的物理分区结构，不要保存冗余的数据（不同表中同时都包含父表中的数据）或相互联结成一个逻辑父对象（通常是视图）。这种做法会使水平分区的大部分功能失效，有时候也会对垂直分区产生影响。
分区带来的好处有很多，这里列出两点：
性能的提升（Increased performance）：在扫描操作中，如果MySQL的优化器知道哪个分区中才包含特定查询中需要的数据，它就能直接去扫描那些分区的数据，而不用浪费很多时间扫描不需要的地方 了。需要举个例子，百万行的表划分为10个分区，每个分区就包含十万行数据，那么查询分区需要的时间仅仅是全表扫描的十分之一了，很明显的对比。同时对十万行的表建立索引的速度也会比百万行的快得多得多。如果你能把这些分区建立在不同的磁盘上，这时候的I/O读写速度就提升很多了。
对数据管理的简化（Simplified data management）：分区技术可以让DBA对数据的管理能力提升。通过优良的分区，DBA可以简化特定数据操作的执行方式。例如：DBA在对某些分区的内容进行删除的同时能保证余下的分区的数据完整性(这是跟对表的数据删除这种大动作做比较的)。
此外分区是由MySQL系统直接管理的，DBA不需要手工的去划分和维护。

Row-based replication
MySQL5.1以前的replication都是statement replication，它把在master端提交的语句记录到binlog并传播到它的各个salve服务器，slave服务器读取并翻译提交对应的statement语句。从5.1.5开始，MySQL就支持另一种复制手段：row-based replication。这种复制方式不同于statement replication，它在binlog中记录的是修改更新语句对MySQL数据表行数据的影响，实际上记录的是表结构信息和具体的各行数据信息。在5.1.8中还推出了两种方式的组合mixed形式的复制并做为MySQL 5.1的缺省复制模式。它默认采用statement replication，而只有在特别的情况下才采用row-based replication。
行复制的引入能够避免一些master和slave环境不同引起的问题的出现，所有的字段和对应的值都被复制到slave段，从而保持slave和master数据的一致性。

Plugin API.
MySQL5.1提供了一套灵活的plugin api，它可以在不重启服务器的基础上实时地装载和卸载各种不同的组件。这些plugin API可以包括（不限于）：全文检索，存储引擎和服务器扩展等方面。例如：plugin full-text parsers就允许用户在索引文本上添加他们自己的输入过滤器，从而可以在PDF或者其他文件类型的文本上实现全文检索的目的。pre-parser full-text plugin将从文本中分析和抽取出具体的信息并传给MySQL本身的全文检索模块。

Event scheduler
事件调度器是在 MySQL 5.1中新增的另一个特色功能，可以作为定时任务调度器，取代部分原先只能用操作系统任务调度器才能完成的定时功能。例如，Linux中的crontab只能精确到每分钟执行一次，而MySQL的事件调度器则可以实现每秒钟执行一个任务，这在一些对实时性要求较高的环境下就非常实用了。
事件调度器是定时触发执行的，在这个角度上也可以称作是”临时的触发器”。触发器只是针对某个表产生的事件执行一些语句，而事件调度器则是在某一个 (间隔)时间执行一些语句。事件是由一个特定的线程来管理的，也就是所谓的”事件调度器”。启用事件调度器后，拥有 SUPER 权限的账户执行SHOW PROCESSLIST就可以看到这个线程了。通过设定全局变量event_scheduler 的值即可动态的控制事件调度器是否启用。

Server log tables
在版本5.1之前，MySQL的general query log和slow query log都是写在日志文件中的。5.1中就灵活多了。日志记录可以写在日志文件中，也可以写在mysql数据库中的表general_log和slow_log中。如果开启了logging的功能，用户可以选择它们其中的一个或者全都记录对应的日志信息。可以通过控制选项–log-output来决定日志信息的记录方式。

Upgrade program
mysql_upgrade工具可以检查所有现有数据表来查看它是否与现有的MySQL服务器的版本兼容，并且在必要的时候修复它们。在每一次MySQL升级时，都应该使用该工具来检查一下。

MySQL Cluster replication
Replication现在可以支持MySQL cluster之间的复制机制了，并且，现在也支持在MySQL cluster和非cluster之间的复制。

MySQL Cluster disk data storage
在MySQL 5.1.6版本以前，NDBCLUSTER存储引擎只能在内存中使用。之后，cluster的数据就可以存储在磁盘上了（不包括索引数据）。这使得MySQL cluster对内存的依赖减少了。
Improved backups for MySQL Cluster
在老版本的MySQL cluster中，cluster数据备份过程中单个节点的错误将导致整个备份过程的失败。但是新版本中不会出现这个问题。

MySQL Cluster NDB 6.x
在MySQL Cluster NDB 6.x中改进了很多并且还增加了一些新的特性。

Backup of tablespaces
mysqldump现在支持导出tablespaces的选项。可以使用-Y或者–all-tablespaces来启用该功能。

Improvements to INFORMATION_SCHEMA
相比5.0，5.1版本的MySQL在它的元数据数据库information_schema中提供了更多的信息。在这个数据库中新的数据表包括：FILES, EVENTS, PARTITIONS, PROCESSLIST, ENGINES, and PLUGINS.

XML functions with XPath support
在MySQL 5.1中，可以利用ExtractValue()返回匹配XPath串中XML片段的内容。也可以使用UpdateXML()来用一个XML片段元素来替换XPath串中的某一段XML片段元素，并返回替换后的串。

Load emulator
mysqlslap工具用来模拟客户端压力并报告每一步的时间消耗。它模拟很多个client连接MySQL server的情况。

这两个工具都是用于控制和管理网卡bonding的工具，非常方便。
ifenslave可以创建bond device；可以将网口attach进bond device；可以将网口提出bond device;可以将bond的目前active网口切换到另外一个活动的网口上。
cat /proc/net/bonding/bond0
可以查看bond0目前的网口

比如
ifenslave -d bond0 eth2
会将eth2从bond0中踢出去。
ifenslave bond0 eth2
会将eth2加入bond0
而我需要的功能：
ifenslave -c bond0 eth2
会将bond0的活动网口切换到eth2上。

而solaris的平台上，if_mpadm也有类似的功能
if_mpadm -d interface_name
用于撤销(detach or off-line )这个网口，这样另外一个网口就会接管这个bond0
if_mpadm -r interface_name
将(Reattach or undo)恢复这块网口的状态。
在solaris上可以用ifconfig -a查看网口和bond的信息

may your successs

第一次犯的错误是因为
flashcache_load mysql_data_cache /dev/fioa /dev/sdc1
前/dev/sdc1已经mount起来了。flashcache_load无法在已经mount的文件系统上再做cache。
解决的办法：
umount /dev/sdc1
然后按照正确的方法load起来。
正确的做法是对/dev/sdc分区，建立xfs(或者其他ext4，ext3)文件系统，然后利用flashcache_load将ssd设备和文件系统映射起来。
这样就会出现/dev/mapper/mysql_data_cache，将他用xfs(ext3，ext4)的方式mount起来。

第二次犯的错误是：
flashcache还在用，/dev/mapper/mysql_data_cache已经mount好了，把fusion-io的内核模块给卸载掉了。
这个时候flashcache_load会报错，/dev/mapper/mysql_data_cache也没有了，flashcache_create显示：
#flashcache_create mysql_data_cache /dev/fioa /dev/sdc1
cachedev mysql_data_cache, ssd_devname /dev/fioa, disk_devname /dev/sdc1
block_size 8, cache_size 0
flashcache_create: Valid Flashcache already exists on /dev/fioa
flashcache_create: Use flashcache_destroy first and then create again /dev/fioa
dmsetup显示：
#dmsetup table
mysql_data_cache:
解决方案：
dmsetup remove mysql_data_cache
flashcache_load mysql_data_cache /dev/fioa /dev/sdc1
mount -o defaults,rw,noatime,nodiratime,noikeep,nobarrier,allocsize=512M,attr2,largeio,inode64,swalloc /dev/mapper/mysql_data_cache /data2
使用最基本的dmsetup remove来清理mysql_data_cache，然后就可以flashcache_load了。
正常情况下，你最好先flashcache_destroy，然后再来操作fusion io，跟你建立的顺序相反

may your success

may your success