MySQL迁移文件的小问题

2024-07-24 12:34:48

字体：大中小

来源：转载

供稿：网友

　　线上有一台服务器上，里面有一个mysql数据库服务，其实库也很小，就几个G，一直以来是保留了多天的备份集，但是因为业务的关系，这个库其实只有一些基本的数据查询，但奇怪的是没有从库，一直以来是每天都会备份，保留了近一周的备份集，这种情况也倒相安无事。不过不巧的是这台服务器上还部署有Oracle数据库，空间要大很多，随着业务的增长，这个数据量就上去了，结果空间的使用是越来越紧俏。保留一周的备份集，空间是越来越紧张。所以在一台Oracle的备库机器上使用gtid创建了一个mysql从库。这种情况基本可以满足之前的需求，所以也就不需要每天做一个全备了。
　　    这种情况持续了没多少时间，有一天就收到了如下的报警。
　　ZABBIX-监控系统:
　　------------------------------------
　　报警内容: Free disk space is less than 20% on volume /
　　------------------------------------
　　报警级别: PROBLEM
　　------------------------------------
　　监控项目: Free disk space on / (percentage)：1.94 %
　　------------------------------------
　　报警时间:2016.02.23-11:01:07
　　好家伙，这个分区竟然是直接使用了根目录的空间，所以空间更是紧张了。
　　这个时候就需要调整数据的目录地址了。想想也就是调整datadir的地址即可。
　　首先是调整数据的目录地址，修改/etc/my.cnf,然后停库，因为空间的问题，最后没有剩余空间了，结果从库的应用直接hang住了，所以直接停库的时候等了一些时间。
　　# /etc/init.d/mysql stop
　　Shutting down MySQL (Percona Server)....................... SUCCESS!
　　启库的时候报了下面的错误。
　　# /etc/init.d/mysql start
　　Starting MySQL (Percona Server)..... ERROR! The server quit without updating PID file (/U01/app/mysql_3306/mysql.pid).
　　经过一番排查，发现原来是文件的目录权限的问题。
　　修复之后继续启动，还是同样的报错。
　　一时没有思路，就测试了一下，把文件目录改回了原来的路径，修改/etc/my.cnf里面的路径，再次启库，这个时候从库开始接受应用日志，过期的binlog都做了一些删除。和追库追平之后，再次停库就很快了。
　　# /etc/init.d/mysql stop
　　Shutting down MySQL (Percona Server)... SUCCESS!
　　但是迁移文件之后，修改/etc/my.cnf之后再次启库就还是同样的问题了。
　　[root@shadoop app]# /etc/init.d/mysql start
　　Starting MySQL (Percona Server)..... ERROR! The server quit without updating PID file (/U01/app/mysql_3306/mysql.pid).
　　查看error.log发现了下面的这一段内容，和之前一样，不过有了新的发现。
　　160223 11:59:38 mysqld_safe mysqld from pid file /U01/app/mysql_3306/mysql.pid ended
　　160223 11:59:56 mysqld_safe Starting mysqld daemon with databases from /U01/app/mysql_3306
　　2016-02-23 11:59:56 21600 [Note] Plugin 'FEDERATED' is disabled.
　　2016-02-23 11:59:56 21600 [Note] InnoDB: The InnoDB memory heap is disabled
　　2016-02-23 11:59:56 21600 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
　　2016-02-23 11:59:56 21600 [Note] InnoDB: Compressed tables use zlib 1.2.3
　　2016-02-23 11:59:56 21600 [Note] InnoDB: Using Linux native AIO
　　2016-02-23 11:59:56 21600 [Note] InnoDB: Using CPU crc32 instructions
　　2016-02-23 11:59:56 21600 [Note] InnoDB: Initializing buffer pool, size = 4.0G
　　2016-02-23 11:59:57 21600 [Note] InnoDB: Completed initialization of buffer pool
　　2016-02-23 11:59:57 21600 [Note] InnoDB: Highest supported file format is Barracuda.
　　2016-02-23 11:59:57 21600 [Note] InnoDB: 128 rollback segment(s) are active.
　　2016-02-23 11:59:57 21600 [Note] InnoDB: Waiting for purge to start
　　2016-02-23 11:59:57 21600 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.14-rel62.0 started; log sequence number 278581
　　8494
　　2016-02-23 11:59:57 7ffa261f0700 InnoDB: Loading buffer pool(s) from .//ib_buffer_pool
　　^G/usr/sbin/mysqld: File '/home/mysql_3306/mysql-bin.000006' not found (Errcode: 2 - No such file or directory)
　　2016-02-23 11:59:57 21600 [ERROR] Failed to open log (file '/home/mysql_3306/mysql-bin.000006', errno 2)
　　2016-02-23 11:59:57 21600 [ERROR] Could not open log file
　　2016-02-23 11:59:57 21600 [ERROR] Can't init tc log
　　2016-02-23 11:59:57 21600 [ERROR] Aborting
　　就是mysql会尝试去找一个binlog /home/mysql_3306/mysql-bin.000006
　　这部分的信息在哪里呢。
　　# less relay-index.index
　　/home/mysql_3306/mysql-relay.000008
　　/home/mysql_3306/mysql-relay.000009
　　/U01/app/mysql_3306/mysql-relay.000010
　　/U01/app/mysql_3306/mysql-relay.000011
　　带着新鲜劲，手工修改了一下这个文件，看看能不能生效。
　　修改为：
　　# vi relay-index.index
　　/U01/app/mysql_3306/mysql-relay.000008
　　/U01/app/mysql_3306/mysql-relay.000009
　　/U01/app/mysql_3306/mysql-relay.000010
　　/U01/app/mysql_3306/mysql-relay.000011
　　然后尝试change master让它基于最新的时间点重新同步。
　　> change master to master_host='10.127.0.xx',master_port =3306,master_user='repl',master_password='slaveuser',master_auto_position=1;
　　Query OK, 0 rows affected, 2 warnings (0.00 sec)
　　启动slave的时候就报了下面的错误。
　　> start slave;
　　ERROR 1872 (HY000): Slave failed to initialize relay log info structure from the repository
　　重启之后，继续尝试start slave,发现错误依旧。
　　这个时候的方法只有reset slave了。
　　> start slave;
　　ERROR 1872 (HY000): Slave failed to initialize relay log info structure from the repository
　　> reset slave;
　　Query OK, 0 rows affected (0.00 sec)
　　> change master to master_host='10.127.0.xx',master_port =3306,master_user='repl',master_password='slaveuser',master_auto_position=1;
　　Query OK, 0 rows affected, 2 warnings (0.04 sec)
　　> start slave;
　　Query OK, 0 rows affected (0.01 sec)
　　再次查看slave已经和主库的日志追平了。
　　> show slave status/G
　　***************************
　　 Replicate_Ignore_Server_Ids:
　　             Master_Server_Id: 200
　　                  Master_UUID: 170281bc-1957-11e4-ad6e-842b2b4841e9
　　             Master_Info_File: /U01/app/mysql_3306/master.info
　　                    SQL_Delay: 0
　　          SQL_Remaining_Delay: NULL
　　      Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
　　           Master_Retry_Count: 86400
　　reset slave会使得slave忘记主从复制关系的位置信息。该语句会删除master.info文件和relay-log.info 文件以及所有的relay log 文件并重新启用一个新的relaylog文件。
　　使用reset slave之前必须使用stop slave 命令将复制进程停止，所有的relay log将被删除不管他们是否被SQL thread进程完全应用。
　　不过如果延迟不大，这些都不是事。毕竟这个问题解决了总比隔三差五收到报警手工处理要好很多。

（编辑：武林网）

上一篇：mysqlbinlog相关简介

下一篇：mysqldump原理分析