【问题标题】:mysql slave replication failedmysql 从属复制失败
【发布时间】:2013-04-29 15:44:52
【问题描述】:

我有一种情况,dns 服务器获取其主服务器的记录,并且所有记录都从主服务器复制到从服务器,并且从服务器用于解析。 mysql 服务器升级后复制中断。 mysql 服务器停止并且日志文件的名称和日志位置更改,直到恢复 mysql。现在我知道如果我更改日志位置和日志文件名,复制将开始,但我会错过很多更新并且我不想要。我应该怎么做才能重新启动主从复制而不会丢失主服务器上的任何更新。每一次更新都很重要。以下是从属状态的一些信息。

 Slave_IO_Running: No
 Slave_SQL_Running: Yes

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'

谢谢

【问题讨论】:

    标签: mysql debian replication recovery


    【解决方案1】:

    给定的答案对我不起作用。实际上,应该从其他地方复制应该获取并设置为 master_log_file 的正确文件。为您提供对我有用的说明:

    Slave Server: stop slave;
    
    
    In Master Server: flush logs
    
    
    In Master Server: show master status; — take note of the master log file and master log position (on my end is 'peer-bin.000264' and pos=120)
    
    Slave Server : CHANGE MASTER TO MASTER_LOG_FILE=’peer-bin.000264′, MASTER_LOG_POS=120;
    
    
    Slave Server: start slave;
    

    【讨论】:

    • 如果您关注的帖子建议显式命名 'master-mysql-bin' 如果这与 STOP SLAVE; CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.003202', MASTER_LOG_POS=577991837; START SLAVE; 不匹配,则会导致此错误
    【解决方案2】:

    您可能会有一个惊喜,但这里是:

    运行SHOW SLAVE STATUS\G。举个例子,假设你得到了这个:

                 Slave_IO_State: Waiting for master to send event
                    Master_Host: 10.64.68.253
                    Master_User: replusername
                    Master_Port: 3306
                  Connect_Retry: 60
                Master_Log_File: mysql-bin.003202
            Read_Master_Log_Pos: 577991837
                 Relay_Log_File: relay-bin.010449
                  Relay_Log_Pos: 306229695
          Relay_Master_Log_File: mysql-bin.003202
               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: 577991837
                Relay_Log_Space: 306229695
                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
    

    您从显示中选择以下内容:

    • Relay_Master_Log_File (mysql-bin.003202)
    • Exec_Master_Log_Pos (577991837)

    原因如下:Relay_Master_Log_FileExec_Master_Log_Pos 表示来自 Master 的 binlog 条目,它到达 Slave 并成功执行。只需从那里取货。

    您只需运行以下代码:Exec_Master_Log_Pos

    STOP SLAVE;
    CHANGE MASTER TO
    MASTER_LOG_FILE='mysql-bin.003202',
    MASTER_LOG_POS=577991837;
    START SLAVE;
    

    试试看!!!

    警告

    如果 Relay_Master_Log_File 不再存在于 Master 上,您可能需要进行一些损坏控制。鉴于前面提到的SHOW SLAVE STATUS\G,您可能需要跳到Master上的下一个二进制日志如下:

    STOP SLAVE;
    CHANGE MASTER TO
    MASTER_LOG_FILE='mysql-bin.003203',
    MASTER_LOG_POS=4;
    START SLAVE;
    

    如果复制赶上,您并没有走出困境。您可能需要下载 Percona Toolkit 并运行 pt-table-checksumpt-table-sync 来修复 Slave 上丢失的数据。

    如果复制没有启动,您将不得不执行尽职调查并重新加载从站。

    希望如果复制符合原始建议,您可能不必在此警告中执行任何操作。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2018-05-23
      • 2022-12-31
      • 1970-01-01
      • 1970-01-01
      • 2018-06-12
      相关资源
      最近更新 更多