背景

随着公司站点的发展，用户和访问量日益增加，经常会出现数据库主从出现延迟的情况，例如，用户在点击充值页进行充值时，经常会出现充值不到账的情况，针对这个问题，对数据库进行排查，发现，磁盘IO极不稳定，iowait也很高，%util一直在90左右，这说明产生的I/O请求很多，IO已经满负荷，磁盘IO存在瓶颈。所以需要加一块SSD盘，来提高IO处理速度。

磁盘IO情况检测

可以结合vmstat和iostat来判断IO和cpu的一些情况，例如：

1 2 3 4 5 6 7 8 9

vmstat 1 100 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 3 0 0 144716 133152 3805212 0 0 485 1565 2 2 3 1 90 6 0 1 0 0 140188 133152 3808372 0 0 59940 744 2252 1537 42 2 36 20 0 1 0 0 146236 133152 3803568 0 0 37632 7384 2434 1969 45 2 39 14 0 1 1 0 120212 133152 3830100 0 0 26656 304 1469 1144 18 1 35 46 0 1 0 0 143180 133156 3804948 0 0 48004 804 2292 1577 43 2 41 14 0 0 1 0 158224 133156 3791228 0 0 28796 7988 2514 2212 45 2 37 17 0

r 表示运行队列，即多少个进程分配到了CPU，如果超过CPU核数，就会出现CPU瓶颈了

b 表示阻塞的进程

si 每秒从磁盘读入虚拟内存的大小，大于0，表示物理内存不够用或者内存泄漏

so 表示从磁盘每秒写入虚拟内存的大小，大于0，同上

bi 表示系统上所有的磁盘和其他块设备上每秒读入的总量

bo 表示所有磁盘上每秒写入的总量

in 每秒CPU中断的次数，包括时间中断

us 表示用户进程消耗的CPU时间百分比，us值越高，说明用户进程消耗CPU时间越多，如果长期大于50%，则需要考虑优化程序或者算法

sy 表示系统内核进程消耗的CPU时间百分比，一般来说us+sy应该小于80%，如果大于80%，说明可能存在CPU瓶颈

id 表示CPU处在空间状态的时间百分比

wa 表示IO等待所占用的CPU时间百分比，wa值越高，说明I/O等待越严重，根据经验wa的参考值为20%，如果超过20%，说明I/O等待严重，引起I/O等待的原因可能是磁盘大量随机读写造成的

综上，我们在判断IO问题的时候，参考bi、bo、wa便可以判断IO的情况。

再来看下iostat的使用：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

iostat -x -k 1 100 Linux 3.10.0-693.2.2.el7.x86_64 (xs_88_55) 05/08/2018 _x86_64_ (2 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 3.07 0.00 0.92 5.72 0.00 90.30 Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util vda 0.01 83.24 7.92 199.19 954.62 3104.95 39.20 0.53 2.57 31.62 1.42 0.62 12.84 vdb 0.00 0.07 0.05 0.13 12.04 11.01 256.26 0.01 49.74 19.07 60.37 1.13 0.02 avg-cpu: %user %nice %system %iowait %steal %idle 1.01 0.00 0.51 2.53 0.00 95.96 Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util vda 0.00 4.00 30.00 2.00 124.00 24.00 9.25 0.03 0.78 0.77 1.00 0.09 0.30 vdb 0.00 83.00 8.00 119.00 68.00 828.00 14.11 0.07 0.53 0.62 0.52 0.53 6.70 avg-cpu: %user %nice %system %iowait %steal %idle 1.00 0.00 0.50 2.49 0.00 96.02 Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util vda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 vdb 0.00 61.00 14.00 88.00 152.00 632.00 15.37 0.05 0.46 0.50 0.45 0.46 4.70

%user：应用程序使用CPU的时间占比

%system：内核程序使用CPU的时间占比。

%iowait：CPU花费了多少时间去等待磁盘IO

%util：表示磁盘忙碌情况，一般该值超过80%表示该磁盘可能处于繁忙状态

综上，在看IO时，关注iowait和util来判断IO情况。

数据迁移

1、最好是先进行锁表操作，防止数据被写入，我这里由于使用的atlas，只要停掉该程序，就不会有数据写入。

1	mysql> flush tables with read lock

解锁用：

1	mysql> unlock tables;

2、将MySQL旧的数据目录里的数据拷贝到SSD目录

1 2	cp -a /usr/local/mysql/data/* /mysql_data/data/ chown -R mysql.mysql data

3、配置文件里修改数据目录

1	datadir = /mysql_data/data

4、重启服务

1	/etc/init.d/mysqld restart

5、这里在查看数据库主从状态信息时，遇到问题，IO线程和SQL线程均为NO，需要重新确立主从关系

1 2 3 4 5	1、两边机器执行show master status;来查看binlog日志位置和文件名 2、两边分别执行语句来重新确立主从关系 change master to master_host='A',master_user='xs',master_password='123456',master_log_file='mysql-bin.000001',master_log_pos=222; 3、开启主从 start slave;

这里执行start slave时遇到问题：

1 2	mysql> start slave; ERROR 1872 (HY000): Slave failed to initialize relay log info structure from the repository

查看err日志：

1 2 3 4 5 6 7 8

2018-05-08 03:29:37 15255 [ERROR] /usr/local/mysql/bin/mysqld: File '/mysql_data/data/relay-bin.000472' not found (Errcode: 2 - No such file or directory) 2018-05-08 03:29:37 15255 [ERROR] Failed to open log (file '/mysql_data/data/relay-bin.000472', errno 2) 2018-05-08 03:29:37 15255 [ERROR] Could not open log file 2018-05-08 03:29:37 15255 [ERROR] /usr/local/mysql/bin/mysqld: File '/mysql_data/data/relay-bin.000471' not found (Errcode: 2 - No such file or directory) 2018-05-08 03:29:37 15255 [ERROR] Failed to open log (file '/mysql_data/data/relay-bin.000471', errno 2) 2018-05-08 03:29:37 15255 [ERROR] Could not open log file 2018-05-08 03:29:37 15255 [ERROR] Error reading relay log configuration. 2018-05-08 03:29:37 15255 [ERROR] Failed to initialize the master info structure

找不到relay-bin.000471文件，原因是我们的数据目录指向了新的位置，在mysql库中的slave_relay_log_info表中依然保留之前relay_log的信息，所以导致启动slave报错

解决办法：

1 2 3 4	reset slave; change master to master_host='A',master_user='xs',master_password='123456',master_log_file='mysql-bin.000001',master_log_pos=222; start slave;

如果问题依然出现，则需要看下数据目录中的slave-relay-bin.index 文件，正常是只记录relay-bin文件名，但是如果出现其他文件，例如Failed to initialize the master info structure，则需要我们手动清理下这个文件。

1 2 3 4 5 6 7 8	mysql-bin.index relay-log.info slave-relay-bin.index 将以上三个文件mv走即可，然后重启数据库，随后从库上做如下操作： reset slave; change master to master_host='A',master_user='xs',master_password='123456',master_log_file='mysql-bin.000001',master_log_pos=222; start slave;

问题解决。

mysql迁移数据目录

背景

磁盘IO情况检测

数据迁移