分类目录归档：FAQ

FAQ: show slave status从那里读的数据

发表于由

这个问题最近有几个学生都问到我: SHOW SLAVE STATUS; 从哪里读数据。原因是发现： show slave status输出和relay_log_info_repository定义为table两个输出不一致。

另外有的人会告诉你把relay_log_info_repository存到表里, sync_relay_log_info就无效了。来吧看手册。

sync_relay_log_info 

对于事务引擎确时走的由Innodb本身保证，也可以说在全Innodb环境中show slave status输出和relay_log_info_repository表内的的内容是一致的。
但对于非事务引擎如果sync_relay_log_info设置成1，很有可能是sync_log_info没设置成1.

结论： show slave status读的数据确时从内存中读出来的。 如果基于Innodb表，两者是一致的。如果基于非事务表，默认配置很有可能是不一致的。如果需要一致可以通过改sync_relay_log_info=1。

 

作者：吴炳锡　来源：http://wubx.net/ 联系方式： wubingxi#163.com 转载请注明作/译者和出处，并且不能用于商业用途，违者必究.

发表在 FAQ

[TIPS]安装数据库提示无法解析机器名处理

发表于由

作者：吴炳锡　来源：http://www.mysqlsupport.cn/ 联系方式： wubingxi#163.com 转载请注明作/译者和出处，并且不能用于商业用途，违者必究.

在做MySQL初始化时，如果机器的名不能进行反解会出现以下错误：

WARNING: The host 'node2' could not be looked up with resolveip.
This probably means that your libc libraries are not 100 % compatible
with this binary MySQL version. The MySQL daemon, mysqld, should work
normally with the exception that host name resolving will not work.
This means that you should use IP addresses instead of hostnames
when specifying MySQL privileges !

#/usr/local/mysql/bin/resolveip node2

/usr/local/mysql/bin/resolveip: Unable to find hostid for ‘node2’: host not found

处理过程如下

1. 查看机器的名

#hostanme

node2

2. 查看/etc/hosts文件

#cat /etc/hosts

127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6

可见/etc/hosts中无相应的机器名

添ip(本机的ip) 到机器的对应到/etc/hosts中:

最终/etc/hosts内容如下：

127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
10.10.60.148 node2

3.使用resolveip确认是否ok

#/usr/local/mysql/bin/resolveip node2

IP address of node2 is 10.10.60.148

4. 在次运行初始化程序

cd /usr/local/mysql
./script/mysql_db_install

Good luck!

TIPS:MySQL 改库名操作

发表于由

作者：吴炳锡　来源：http://www.mysqlsupport.cn/ 联系方式： wubingxi#163.com 转载请注明作/译者和出处，并且不能用于商业用途，违者必究.

MySQL在5.1引入了一个rename database操作，但在MySQL5.1.23后又不支持这个命令。可以说是一个实验性的功能，没有在生产中支持过（mysql-5.1 release在mysql-5.1.30）,那么生产中我们有时为了追求完美需要改一下库名。怎么操作呢？
这里提供一个变通的方法。
1. 创建出新库名：

mysql>create database db_v2;
  1. 生成rename语句，从olddb里迁移,我这里olddb里sbtest;
mysql>select concat("rename table ",table_schema,".",table_name," to db_v2.",table_name,";") into outfile '/tmp/rename_to_db_v2.sql' from information_schema.tables where table_schema='sbtest';

3.执行生成的sql

mysql>source /tmp/rename_to_db_v2.sql

就这么简单可以搞定了。
Good luck!

FAQ:一个表里取不唯一记录取最后一行方法

发表于由

作者：吴炳锡　来源：http://www.mysqlsupport.cn/ 联系方式： wubingxi#gmail.com 转载请注明作/译者和出处，并且不能用于商业用途，违者必究.

如下表：

CREATE TABLE `t1` (
`userid` int(11) DEFAULT NULL,
`atime` datetime DEFAULT NULL,
KEY `idx_userid` (`userid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8；

数据如下：

MySQL> select * from t1;
+--------+---------------------+
| userid | atime |
+--------+---------------------+
| 1 | 2013-08-12 11:05:25 |
| 2 | 2013-08-12 11:05:29 |
| 3 | 2013-08-12 11:05:32 |
| 5 | 2013-08-12 11:05:34 |
| 1 | 2013-08-12 11:05:40 |
| 2 | 2013-08-12 11:05:43 |
| 3 | 2013-08-12 11:05:48 |
| 5 | 2013-08-12 11:06:03 |
+--------+---------------------+
8 rows in set (0.00 sec)

其中userid不唯一，要求取表中每个userid对应的时间离现在最近的一条记录．初看到一个这条件一般都会想到借用临时表及添加主建借助于join操作之类的．
给一个简方法：

MySQL> select userid,substring_index(group_concat(atime order by atime desc),",",1) as atime from t1 group by userid;
+--------+---------------------+
| userid | atime |
+--------+---------------------+
| 1 | 2013-08-12 11:05:40 |
| 2 | 2013-08-12 11:05:43 |
| 3 | 2013-08-12 11:05:48 |
| 5 | 2013-08-12 11:06:03 |
+--------+---------------------+
4 rows in set (0.03 sec)

Good luck!

发表在 FAQ

从库无业务延迟严重排查

发表于由

作者：吴炳锡　来源：http://www.mysqlsupport.cn/ 联系方式： wubingxi#gmail.com 转载请注明作/译者和出处，并且不能用于商业用途，违者必究.

今天给一个客户巡检的情况下发从库没有业务的情况mysqld的cpu的一个core占用100%.查主库慢查询也没有关于写的SQL.
可以说是典的单进程复制把一个cpu占满造成的．知道原因了，就好分析了．
分析一下binlog中写的什么，看看有什么地方可以优化或是加速的．利用工具：pasrebinlog
利用show slave status\G; 查当前同步的到节点，然后对日值进行解析．

git clone https://github.com/wubx/mysql-binlog-statistic.git
cd mysql-binlog-statistic/bin/
parsebinlog /u1/mysql/logs/mysql-bin.000806

...
====================================
Table xx_db.xxtable:
Type DELETE opt： 101246
Type INSERT opt： 103265
================================
...

以最大的数排序看，　定位到:　xx_db.xxtable，对于一个日值中能删除10几万，写入10几万．是不是这个表写入比较慢了呢．
在从库上查看innodb的相关情况：

MySQL> show engine innodb status\G;
...
---TRANSACTION 1C0C2DFDF, ACTIVE 3 sec fetching rows
mysql tables in use 1, locked 1
3361 lock struct(s), heap size 407992, 477888 row lock(s), undo log entries 42
MySQL thread id 43, OS thread handle 0x7fc1800c4700, query id 1908504 Reading event from the relay log
TABLE LOCK table xx_db.xxtable trx id 1C0C2DFDF lock mode IX
RECORD LOCKS space id 1002 page no 1975 n bits 1120 index `AK_movieid` of table xx_db.xxtable trx id 1C0C2DFDF lock_mode X locks rec but not gap
RECORD LOCKS space id 1002 page no 6965 n bits 264 index `GEN_CLUST_INDEX` of table xx_db.xxtable trx id 1C0C2DFDF lock_mode X locks rec but not gap
RECORD LOCKS space id 1002 page no 6967 n bits 256 index `GEN_CLUST_INDEX` of table xx_db.xxtable trx id 1C0C2DFDF lock_mode X locks rec but not gap
RECORD LOCKS space id 1002 page no 6973 n bits 264 index `GEN_CLUST_INDEX` of table xx_db.xxtable trx id 1C0C2DFDF lock_mode X locks rec but not gap
RECORD LOCKS space id 1002 page no 6982 n bits 256 index `GEN_CLUST_INDEX` of table xx_db.xxtable trx id 1C0C2DFDF lock_mode X locks rec but not gap
RECORD LOCKS space id 1002 page no 6983 n bits 256 index `GEN_CLUST_INDEX` of table xx_db.xxtable trx id 1C0C2DFDF lock_mode X locks rec but not gap
RECORD LOCKS space id 1002 page no 6987 n bits 256 index `GEN_CLUST_INDEX` of table xx_db.xxtable trx id 1C0C2DFDF lock_mode X locks rec but not gap
RECORD LOCKS space id 1002 page no 6999 n bits 256 index `GEN_CLUST_INDEX` of table xx_db.xxtable trx id 1C0C2DFDF lock_mode X locks rec but not gap
RECORD LOCKS space id 1002 page no 7000 n bits 256 index `GEN_CLUST_INDEX` of table xx_db.xxtable trx id 1C0C2DFDF lock_mode X locks rec but not gap
TOO MANY LOCKS PRINTED FOR THIS TRX: SUPPRESSING FURTHER PRINTS
----------------------------
END OF INNODB MONITOR OUTPUT

...

从Innodb 的monitor output 中也可看到 xx_db.xxtable 这表已经是表级表了，造成并发比较低，而且有大量的：　GEN_CLUST_INDEX　而且属于一个事务．　　GEN_CLUST_INDEX表示没有主建，内部产生一个主建，对于内部产生的主建很很容易造成page拆分的操作．

问题到这里基本上可以得到解决问题的方法了：
给xx_db.xxtable 添加一个主建即可．这里后是给xx_db.xxtable 添加了一个无业务意义的id　int　自增主建．这样立马可以看到mysqld占用的cpu单核降到了3％左右，　同时后续同步一切正常，观查一天没出现同步延迟的问题．

MySQL使用为什么要分库分表

发表于由

作者：吴炳锡　来源：http://www.mysqlsupport.cn/ 联系方式： wubingxi#gmail.com 转载请注明作/译者和出处，并且不能用于商业用途，违者必究.

可以用说用到MySQL的地方,只要数据量一大, 马上就会遇到一个问题,要分库分表.
这里引用一个问题为什么要分库分表呢?MySQL处理不了大的表吗?
其实是可以处理的大表的.我所经历的项目中单表物理上文件大小在80G多,单表记录数在5亿以上,而且这个表
属于一个非常核用的表:朋友关系表.

但这种方式可以说不是一个最佳方式. 因为面临文件系统如Ext3文件系统对大于大文件处理上也有许多问题.
这个层面可以用xfs文件系统进行替换.但MySQL单表太大后有一个问题是不好解决: 表结构调整相关的操作基
本不在可能.所以大项在使用中都会面监着分库分表的应用.

从Innodb本身来讲数据文件的Btree上只有两个锁, 叶子节点锁和子节点锁,可以想而知道,当发生页拆分或是添加
新叶时都会造成表里不能写入数据.
所以分库分表还就是一个比较好的选择了.

那么分库分表多少合适呢?
经测试在单表1000万条记录一下,写入读取性能是比较好的. 这样在留点buffer,那么单表全是数据字型的保持在
800万条记录以下, 有字符型的单表保持在500万以下.

如果按 100库100表来规划,如用户业务:
500万*100*100 = 50000000万 = 5000亿记录.

心里有一个数了,按业务做规划还是比较容易的.

发表在 FAQ

FAQ:为什么binlog大小会大于max_binlog_size

发表于由

作者：吴炳锡　来源：http://www.mysqlsupport.cn/ 联系方式： wubingxi#gmail.com 转载请注明作/译者和出处，并且不能用于商业用途，违者必究.

CASE:
mysql的IO处理上有抖动，　从日值上观查binlog最大的有(512M)大于max_binlog_size(128M)

原因：
当mysql在处理大事务时，不会进行binlog切换，所有的日值还是会写到一个数据文件里．
如：　bulk insert之类的操作
解决办法：
拆分大事务．　或是把大事务处理放到业务低峰期，避免大事务对业务的冲击.

特别提示：　

看到这种现象可以通过分析binlog查到是什么操作，　可以通过业务的方面考虑一下怎么规避．