加入收藏 | 设为首页 | 会员中心 | 我要投稿 温州站长网 (https://www.52wenzhou.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 站长学院 > MySql教程 > 正文

使用reset master命令清空日志的示例分析

发布时间:2021-12-26 11:33:09 所属栏目:MySql教程 来源:互联网
导读:这篇文章给大家分享的是有关使用reset master命令清空日志的示例分析的内容。小编觉得挺实用的,因此分享给大家做个参考,一起跟随小编过来看看吧。 今天看见主库binlog日志非常大,于是使用reset master命令清空日志 mysql reset master; Query OK, 0 rows a
这篇文章给大家分享的是有关使用reset master命令清空日志的示例分析的内容。小编觉得挺实用的,因此分享给大家做个参考,一起跟随小编过来看看吧。
 
今天看见主库binlog日志非常大,于是使用reset master命令清空日志
 
mysql> reset master;
 
Query OK, 0 rows affected (1 min 59.87 sec)
 
结果从库就报错了
 
mysql> show slave statusG;
 
*************************** 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 statusG;
 
*************************** 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是一个非常危险的动作
 
感谢各位的阅读!

(编辑:温州站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    热点阅读