mysql@localhost mysql]$ mysqldump --single-transaction -A -uroot -proot123 --master-data=2 > /u01/backup/testbk.sql
Warning: Using a password on the command line interface can be insecure.
Error: Couldn't read status information for table slave_master_info ()
mysqldump: Couldn't execute 'show create table `slave_master_info`': Table 'mysql.slave_master_info' doesn't exist (1146)

错误提示有innodb_index_stats,innodb_table_stats,slave_master_info,slave_relay_log_info,slave_worker_info等几个
使用select语句进行查询时，也会提示这些表不存在

最终解决方法是：删除错误的表后重建

1.查询不可使用的表
show create table mysql.innodb_index_stats;
show create table mysql.innodb_table_stats;
show create table mysql.slave_master_info;
show create table mysql.slave_relay_log_info;
show create table mysql.slave_worker_info;

2.删除上述5张表或有错误的表
drop table mysql.innodb_index_stats;
drop table mysql.innodb_table_stats;
drop table mysql.slave_master_info;
drop table mysql.slave_relay_log_info;
drop table mysql.slave_worker_info;

3.进入data/mysql相应文件夹找到关于5张表的数据文件（.frm,.ibd)并删除
rm -rf innodb_index_stats.*
rm -rf innodb_table_stats.*
rm -rf slave_master_info.*
rm -rf slave_relay_log_info.*
rm -rf slave_worker_info.*

4. 查找表结构
去找$MYSQL_HOME/share/mysql_system_tables.sql，分别search到每一表的建表语句，然后重建设；

继续阅读 →

发表在 db | 标签为 MySQL, mysqldump | 已关闭评论

mysql innodb_table_stats does not exist

发表于2017年8月9日由kaisin

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表。看下是否还有错误。

这个错误到此解决了。

继续阅读 →

发表在 db | 标签为 MySQL | 已关闭评论

Mysql Replicate Relay log read failure

发表于2017年8月9日由kaisin

一、描述

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等，默认使用当前已经设置好的）

mysql>stop slave;

mysql>change master to master_log_file='dd-bin.002540' , master_log_pos=950583017;

mysql>start slave;

四、验证结果

再次查看，错误已经解决，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

继续阅读 →

发表在 db | 标签为 MySQL | 已关闭评论

MySQL大数据场景的优化和运维之道

发表于2016年7月14日由kaisin

前言

MySQL数据库大家应该都很熟悉，而且随着前几年的阿里的去IOE，MySQL逐渐引起更多人的重视。

MySQL历史

1979年，Monty Widenius写了最初的版本，96年发布1.0
1995-2000年，MySQL AB成立，引入BDB
2000年4月，集成MyISAM和replication
2001年，Heikki Tuuri向MySQL建议集成InnoDB
2003发布5.0，提供了视图、存储过程等功能
2008年，MySQL AB被Sun收购，09年推出5.1
2009年4月，Oracle收购Sun，2010年12月推出5.5
2013年2月推出5.6 GA，5.7开发中

MySQL的优点

使用简单
开源免费
扩展性“好”，在一定阶段扩展性好
社区活跃
性能可以满足互联网存储和性能需求，离不开硬件支持

上面这几个因素也是大多数公司选择考虑MySQL的原因。不过MySQL本身存在的问题和限制也很多，有些问题点也经常被其他数据库吐槽或鄙视

MySQL存在的问题

优化器对复杂SQL支持不好
对SQL标准支持不好
大规模集群方案不成熟，主要指中间件
ID生成器，全局自增ID
异步逻辑复制，数据安全性问题
Online DDL
HA方案不完善
备份和恢复方案还是比较复杂，需要依赖外部组件
展现给用户信息过少，排查问题困难
众多分支，让人难以选择

看
到了刚才讲的MySQL的优势和劣势，可以看到MySQL面临的问题还是远大于它...

继续阅读 →

发表在 db | 标签为 MySQL | 已关闭评论

MySQL数据库命名规范及约定

发表于2015年12月10日由kaisin

一、【操作规范】
1. 如无备注，则表中的第一个id字段一定是主键且为自动增长；
2. 如无备注，则数值类型的字段请使用UNSIGNED属性；
3. 如无备注，排序字段order_id在程序中默认使用降序排列；
4. 如无备注，所有字段都设置NOT NULL，并设置默认值；
5. 如无备注，所有的布尔值字段，如is_hot、is_deleted，都必须设置一个默认值，并设为0；
6. 所有的数字类型字段，都必须设置一个默认值，并设为0；
7. 针对varchar类型字段的程序处理，请验证用户输入，不要超出其预设的长度；
8. 建表时将数据字典中的字段中文名和属性备注写入数据表的备注...

继续阅读 →

发表在 db | 标签为 MySQL | 已关闭评论

MySql ibdata1文件

发表于2015年4月3日由kaisin

MySql innodb如果是共享表空间，ibdata1文件越来越大，达到了30多个G，对一些没用的表进行清空：
truncate table xxx;
然后optimize table xxx; 没有效果
因为对共享表空间不起作用。
mysql ibdata1存放数据，索引等，是MYSQL的最主要的数据。
如果不把数据分开存放的话，这个文件的大小很容易就上了G，甚至几十G。对于某些应用来说，并不是太合适。因此要把此文件缩小。
无法自动收缩，必须数据导出，删除ibdata1，然后数据导入，比较麻烦，因此需要改为每个表单独的文件。
解决方法：数据文件单独存放(共享表空间如何改为每个表独立的表空间文件)。
步骤如... 继续阅读 →

发表在 db | 标签为 MySQL | 已关闭评论

mysql sort

发表于2014年2月15日由kaisin

按IN顺序排序

select * from table_name where doc_id IN ('1dba', 'c20a', '907b')

mysql返回的结果集的排序是按照入库顺序给出的，若希望按照doc_id列表的先后顺序进行排序，

select * from table_name where doc_id IN ('1dba', 'c20a', '907b') order by FIND_IN_SET('1dba', 'c20a', '907b')

ORDER BY + 字段 + 排序方式

使用前：
SELECT `goods_...

继续阅读 →

发表在 db | 标签为 MySQL | 已关闭评论

mysql 误删除ibdata1之后如何恢复

发表于2013年8月15日由kaisin

删除了在线服务器中mysql innodb相关的数据文件ibdata1以及日志文件 ib_logfile*，
应该怎样恢复呢？

观察网站，发现一切都很正常，数据的读取与写入操作都完全正常。
这是怎么个情况？

其实，mysqld在运行状态中，会保持这些文件为打开状态，
即使把它们删除了，它们仍旧存在于文件系统中，mysqld仍然可以对其进行读写。

root@localhost:/var/lib/mysql# ls -la /proc/14101/fd/| grep -e ibdata -e ib_
lrwx------ 1 root  root  64 Aug  7 23:29 3 ...

继续阅读 →

发表在 db | 标签为 MySQL | 已关闭评论

mysql MM

发表于2013年8月1日由kaisin

MySQL支持单向、异步复制，复制过程中一个服务器充当主服务器，而一个或多个其它服务器充当从服务器。主服务器将更新写入二进制日志文件，并维护日志文件的一个索引以跟踪日志循环。当一个从服务器连接到主服务器时，它通知主服务器从服务器在日志中读取的最后一次成功更新的位置。从服务器接收从那时起发生的任何更新，然后封锁并等待主服务器通知下一次更新。

配置主主同步的操作步骤：
MySQL-A 10.17.1.11
MySQL-B 10.17.1.12
1. 分别在两台机器授权账户：grant replication... 继续阅读 →

发表在 db | 标签为 MySQL | 已关闭评论

mysql user grant

发表于2013年7月31日由kaisin

登录MYSQL：

　　@>mysql -u root -p

　　@>密码

用户授权

　　 grant 权限 on 数据库.* to 用户名@登录主机 identified by "密码";　

　　mysql>flush privileges;//刷新系统权限表

授权示例：

授权 test 用户 test 表所有权限(密码1234)

　　 mysql>grant all privileges on test.* to test@localhost ide...

继续阅读 →

发表在 db | 标签为 MySQL | 已关闭评论

标签归档：MySQL

SAS vs SSD对比测试MySQL 性能

centos 6.x yum mysql 5.7

MySQL 全文索引(fulltext index)

MySQL FullText

mysqldump

mysqldump error

mysql innodb_table_stats does not exist

Mysql Replicate Relay log read failure

MySQL大数据场景的优化和运维之道

前言

MySQL历史

MySQL的优点

MySQL存在的问题

MySQL数据库命名规范及约定

MySql ibdata1文件

mysql sort

mysql 误删除ibdata1之后如何恢复

mysql MM

mysql user grant

其他操作

分类

近期文章

归档

链接

分类

近期文章

归档

其他操作

链接