主库reset master清理binlog日志到主从复制错误

今天看见主库binlog日志非常大,于是使用reset master命令清空日志
mysql> reset master;
Query OK, 0 rows affected (1 min 59.87 sec)

结果从库就报错了
mysql> show slave status\G;
*************************** 1. row ***************************
               Slave_IO_State:
                  Master_Host: 192.168.129.150
                  Master_User: replicat
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000312
          Read_Master_Log_Pos: 2029035
               Relay_Log_File: mysql-relay-bin.000945
                Relay_Log_Pos: 2020198
        Relay_Master_Log_File: mysql-bin.000312
             Slave_IO_Running: No
            Slave_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 1
          Exec_Master_Log_Pos: 2029035
              Relay_Log_Space: 2029418
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File:
           Master_SSL_CA_Path:
              Master_SSL_Cert:
            Master_SSL_Cipher:
               Master_SSL_Key:
        Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 1236
                Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 2
                  Master_UUID: 124deecd-401b-11e6-b4e1-40f2e9de1e12
             Master_Info_File: /data/DB/mysql/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
                  Master_Bind:
      Last_IO_Error_Timestamp: 160808 11:08:49
     Last_SQL_Error_Timestamp:
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set:
            Executed_Gtid_Set:
                Auto_Position: 0
1 row in set (0.00 sec)

再看下主库日志,已经重新开始了,不再是mysql-bin.000312
mysql> show master status;
+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000001 |   216484 |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

解决方法,重新设置slave进程
mysql> stop slave;
Query OK, 0 rows affected (0.01 sec)

mysql> change master to master_host='192.168.129.150',
    -> master_user='replicat',
    -> master_password='passw',
    -> master_log_file='mysql-bin.000001',
    -> master_log_pos=120;
Query OK, 0 rows affected, 2 warnings (0.05 sec)

mysql> start slave;
Query OK, 0 rows affected (0.02 sec)

mysql> show slave status\G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.129.150
                  Master_User: replicat
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000001
          Read_Master_Log_Pos: 310425
               Relay_Log_File: mysql-relay-bin.000002
                Relay_Log_Pos: 310588
        Relay_Master_Log_File: mysql-bin.000001
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 310425
              Relay_Log_Space: 310761
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File:
           Master_SSL_CA_Path:
              Master_SSL_Cert:
            Master_SSL_Cipher:
               Master_SSL_Key:
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 2
                  Master_UUID: 124deecd-401b-11e6-b4e1-40f2e9de1e12
             Master_Info_File: /data/DB/mysql/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
                  Master_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp:
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set:
            Executed_Gtid_Set:
                Auto_Position: 0
1 row in set (0.00 sec)

问题虽然解决了,但是从报错记录来看         
Read_Master_Log_Pos: 2029035
Relay_Log_Pos: 2020198
中间已经有一部分数据没有同步到从库,但因为这个数据库的OLAP系统,从业务了解没有大碍,所以不用担心数据不一致的情况,所以主库执行reset matser是一个非常危险的动作

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/29989552/viewspace-2125302/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/29989552/viewspace-2125302/

<think>嗯,用户想了解如何清理MySQL的binlog日志,包括删除过期binlog的配置方法。首先,我需要回忆一下关于MySQL binlog的相关知识。记得binlog是二进制日志,用于记录数据库的更改操作,主从复制和恢复数据时会用到。但长时间不清理的话,会占用大量磁盘空间,所以用户需要清理方法。 根据系统级指令里的引用,用户提供了几个引用来源,我需要结合这些内容来组织回答。首先,手动清理的方法,比如使用PURGE命令。比如引用[1]提到用purge binary logs to和purge binary logs before来删除指定文件或时间点之前的日志,这点很重要,因为直接删除文件可能导致不一致,所以必须用purge命令。另外,引用[4]提到了RESET MASTER命令,可以清空所有binlog,但要注意这会删除所有日志,适用于初始化场景,可能不适用于用户的情况,但需要提及。 然后是自动清理的配置。引用[1]和[2]都提到了expire_logs_days这个变量,在MySQL5和8中的设置方式不同吗?记得在MySQL8中,可能改成了binlog_expire_logs_seconds,但引用[2]说可以通过expire_logs_days设置,可能需要确认版本差异。比如,在MySQL5中,设置全局变量expire_logs_days=7,然后flush logs触发清理,同时修改my.cnf永久生效。而MySQL8可能支持两种参数,但用户引用里提到的是expire_logs_days,所以可能需要说明不同版本的配置方法。 另外,引用[3]提到MySQL重启时会检查并清理过期的日志,所以自动清理是否在修改参数后立即生效?可能需要执行flush logs或者等待日志切换。例如,设置全局变量后,执行flush logs让系统生成新的binlog文件,并触发清理旧文件。 还需要注意用户可能混淆了不同版本的处理方式,比如MySQL8默认使用binlog_expire_logs_seconds,而expire_logs_days可能已被弃用,但根据引用[2]的内容,用户可能还在使用expire_logs_days,所以需要分版本说明。例如,在回答中区分MySQL5和8的不同配置方法,或者在MySQL8中两种参数并存时的优先级问题。 另外,引用[4]提到的RESET MASTER命令,会删除所有binlog并重置索引文件,适用于需要完全清空的场景,但用户可能需要的是定期清理而不是全部删除,所以需要提醒谨慎使用该命令。 操作步骤方面,可能需要先检查当前binlog状态,使用show binary logs或show variables like '%log_bin%'; 确定日志位置和设置。然后根据需求选择手动或自动清理。手动用PURGE,自动设置过期时间。配置自动清理时需要修改my.cnf并重启服务,或者动态设置全局变量。 还需要注意事项,比如不要直接删除文件,避免索引不一致;主从复制环境中要考虑从库是否已经读取了binlog,避免数据不一致;自动清理的时间设置要根据存储需求调整。 总结回答结构:先介绍手动清理方法(PURGE命令),然后自动清理配置(expire_logs_days和binlog_expire_logs_seconds),不同版本的处理,操作命令示例,注意事项。最后生成相关问题。 现在需要检查是否有遗漏点,比如是否提到了版本差异,是否正确引用了来源。比如引用[1]提到在MySQL5中使用expire_logs_days,而引用[2]是MySQL8,但同样使用该变量,可能用户的信息中MySQL8仍支持该参数,或者需要说明两种参数的优先级。比如在MySQL8中,如果同时设置了expire_logs_days和binlog_expire_logs_seconds,后者优先级更高,需要用户注意。 最后,生成的回答需要符合中文,结构清晰,分步骤说明,正确引用标记。</think>### 如何清理MySQL的binlog日志 清理MySQL的binlog日志可以通过**手动清理**和**自动清理**两种方式实现,具体步骤如下: --- #### **一、手动清理** 1. **使用`PURGE`命令** - 删除指定文件之前的所有binlog: ```sql PURGE BINARY LOGS TO 'mysql-bin.009560'; -- 保留mysql-bin.009560及之后的日志 ``` - 删除指定时间之前的所有binlog: ```sql PURGE BINARY LOGS BEFORE '2023-08-01 00:00:00'; -- 清理2023年8月1日前的日志 ``` *注意:切勿直接通过`rm`命令删除文件,否则会导致`binlog.index`与实际文件不匹配[^1]。* 2. **重置所有binlog(慎用)** 使用`RESET MASTER`会删除所有binlog并重置索引文件,适用于初始化场景: ```sql RESET MASTER; -- 清空所有binlog日志[^4] ``` --- #### **二、自动清理** 通过配置**日志过期时间**实现自动清理: 1. **临时生效(无需重启)** ```sql SET GLOBAL expire_logs_days = 7; -- 设置保留7天的日志[^1] FLUSH LOGS; -- 触发日志轮换并清理过期文件 ``` 2. **永久生效(需修改配置文件)** - 编辑MySQL配置文件`my.cnf`(或`my.ini`): ```ini [mysqld] expire_logs_days = 7 -- MySQL 5.x版本 binlog_expire_logs_seconds = 604800 -- MySQL 8.x版本(7天=604800秒) ``` - 重启MySQL服务使配置生效: ```bash systemctl restart mysql ``` *注意:MySQL 8.0默认使用`binlog_expire_logs_seconds`,若同时配置,此参数优先级高于`expire_logs_days`[^2][^3]。* --- #### **三、操作验证** 1. 查看当前binlog状态: ```sql SHOW BINARY LOGS; -- 列出所有binlog文件 SHOW VARIABLES LIKE '%log_bin%'; -- 检查日志路径及配置 ``` 2. 确认过期时间是否生效: ```sql SHOW VARIABLES LIKE 'expire_logs_days'; SHOW VARIABLES LIKE 'binlog_expire_logs_seconds'; ``` --- #### **注意事项** 1. **主从复制环境**:确保从库已读取需清理binlog,否则可能导致复制中断。 2. **磁盘空间监控**:定期检查binlog占用情况,避免突发写操作导致磁盘满载。 3. **备份策略**:清理前建议备份重要binlog,以防数据恢复需要。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值