月归档：2017年08月

InnoDB: Error: table `mysql`.`innodb_table_stats` does not exist in the InnoDB internal

这个原因很明显 ，是mysql库的innodb_table_stats表损坏了。

再点击 mysql的innodb_index_stats 表，同样损坏。

解决方法：

损坏了，当然就是删除重补回来。

1，删除表，进入mysql库，把innodb前缀的表文件删除。

[root@AY140311174146476cc0Z mysql]# pwd
/usr/local/mysql/data/mysql
[root@AY140311174146476cc0Z mysql]# rm -f innodb_*

2，重新执行sql文件语句。当然语句来自安装包。

具体路径，如5.6为例：mysql-5.6.19/scripts/mysql_system_tables.sql

语句贴出来吧

CREATE TABLE IF NOT EXISTS innodb_index_stats (
    database_name           VARCHAR(64) NOT NULL,
    table_name          VARCHAR(64) NOT NULL,
    index_name          VARCHAR(64) NOT NULL,
    last_update         TIMESTAMP NOT NULL NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    /* there are at least:
    stat_name='size'
    stat_name='n_leaf_pages'
    stat_name='n_diff_pfx%' */
    stat_name           VARCHAR(64) NOT NULL,
    stat_value          BIGINT UNSIGNED NOT NULL,
    sample_size         BIGINT UNSIGNED,
    stat_description        VARCHAR(1024) NOT NULL,
    PRIMARY KEY (database_name, table_name, index_name, stat_name)
) ENGINE=INNODB DEFAULT CHARSET=utf8 COLLATE=utf8_bin STATS_PERSISTENT=0
 
 
 
CREATE TABLE IF NOT EXISTS innodb_table_stats (
    database_name           VARCHAR(64) NOT NULL,
    table_name          VARCHAR(64) NOT NULL,
    last_update         TIMESTAMP NOT NULL NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    n_rows              BIGINT UNSIGNED NOT NULL,
    clustered_index_size        BIGINT UNSIGNED NOT NULL,
    sum_of_other_index_sizes    BIGINT UNSIGNED NOT NULL,
    PRIMARY KEY (database_name, table_name)
) ENGINE=INNODB DEFAULT CHARSET=utf8 COLLATE=utf8_bin STATS_PERSISTENT=0

然后，再查询相关的innodb表。看下是否还有错误 。

这个错误到此解决了。

继续阅读 →

一、描述

Mysql主从复制模式中，slave上报错 “relay log read failure”，导致主从同步停止。

mysql> show slave status\G
...
Master_Log_File: dd-bin.002542
Relay_Master_Log_File: dd-bin.002540
Exec_Master_Log_Pos: 950583017
Last_Error: Relay log read failure:...
...

二、分析

      报错信息为从库“无法读取relay log 里的条目”，可能原因为master库的binglog错误，或slave库的中继日志错误。或者为网络问题及bug原因。

      一般是由于网络故障或slave库压力过大，导致relay-log格式错误造成的。找到当前已经同步的时间点，重新设置主从同步，就会产生新的中继日志，恢复正常。

三、问题处理

从"show  slave  status\G"的输出中，找到如下信息：

Relay_Master_Log_File: dd-bin.002540     //slave库已读取的master的binlog

Exec_Master_Log_Pos: 950583017           //在slave上已经执行的position位置点

    停掉slave，以slave已经读取的binlog文件，和已经执行的position为起点，重新设置同步。会产生新的中继日志，问题解决。

（不需要指定host，user，password等，默认使用当前已经设置好的）

四、验证结果

再次查看，错误已经解决，slave 开始追 master 的日志

mysql>show  slave status\G

Exec_Master_Log_Pos: 225927489        //slave上已经执行的position已经变化

Seconds_Behind_Master: 58527            //slave  落后主库的时间，单位秒

过几秒钟，再次查看。离与master同步更近了

mysql>show  slave status\G

Exec_Master_Log_Pos: 307469867

Seconds_Behind_Master: 29570

继续阅读 →