☰

정전 후 MySQL 복제 문제

tag-icon • tag-icon mysql replication disaster-recovery mysql-replication
정전 후 MySQL 복제 문제

데이터 센터에서 정전이 발생한 후 슬레이브 MySQL 데이터베이스가 어려움을 겪고 있습니다.

이것은 슬레이브 중 하나의 로그에 있습니다.

100118 10:05:56 [Note] Slave I/O thread: connected to master 'repl@db1:3306',  replication started in log 'bin-log.004712' at position 724207814
100118 10:05:56 [ERROR] Error reading packet from server: Client requested master to start replication from impossible position ( server_errno=1236)
100118 10:05:56 [ERROR] Got fatal error 1236: 'Client requested master to start replication from impossible position' from master when reading data from binary log
100118 10:05:56 [Note] Slave I/O thread exiting, read up to log 'bin-log.004712', position 724207814

콘솔에는 좀 더 자세한 내용이 표시됩니다.

mysql> show slave status \G;
*************************** 1. row ***************************
             Slave_IO_State:
                Master_Host: db1
                Master_User: repl
                Master_Port: 3306
              Connect_Retry: 10
            Master_Log_File: bin-log.004712
        Read_Master_Log_Pos: 724207814
             Relay_Log_File: mysqld-relay-bin.000105
              Relay_Log_Pos: 98
      Relay_Master_Log_File: bin-log.004712
           Slave_IO_Running: No
          Slave_SQL_Running: Yes
            Replicate_Do_DB: mmplive1,mmpjcr,fui
        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: 724207814
            Relay_Log_Space: 98
            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
1 row in set (0.00 sec)

ERROR:
No query specified

마스터의 bin 로그를 살펴보면 다음과 같습니다.

-rw-rw---- 1 mysql mysql  724200412 Jan 18 09:22 bin-log.004712
-rw-rw---- 1 mysql mysql       1904 Jan 18 09:27 bin-log.index
-rw-rw---- 1 mysql mysql    5046830 Jan 18 11:22 slow-log
-rw-rw---- 1 mysql mysql  198249613 Jan 18 11:24 bin-log.004713
  1. 슬레이브 상태는 Exec_Master_Log_Pos 및 Read_Master_Log_Pos가 모두 724207814이고 바이너리 로그 bin-log.004712임을 나타냅니다. 이 값은 바이너리 로그 파일의 바이트 위치인 것으로 알고 있습니다.
  2. 해당 bin-log.004712 파일은 724200412바이트에 불과하므로 슬레이브는 파일(ext3 fs, RAID-10, RHEL5에 있음)에 실제로 유지된 것보다 7402바이트 더 많은 작업을 수행했다고 생각합니다. 따라서 불가능한 로그 위치 등에 대한 오류 메시지가 나타납니다.

노예를 고치는 가장 좋은 방법은 무엇입니까?

내가 고려하고 있는 옵션:

  1. 다음 bin-log 파일(bin-log.004713)에서 각 슬레이브가 위치 0을 가리키도록 설정하고 놓아두지만 이것이 얼마나 안전한지 또는 얼마나 많은 데이터가 손실될 수 있는지 잘 모르겠습니다.
  2. 대신 전체 백업 및 복원을 수행해야 합니까(InnoDB 테이블의 테이블 잠금으로 인해 관련 가동 중지 시간이 예상됨)? 가능하다면 그런 일은 피하고 싶습니다.

업데이트:

또 다른 옵션을 놓쳤습니다. 각 슬레이브 실행 위치를 약간 뒤로 지정하여 bin-log.004712에서 이미 처리한 명령을 복제하려고 시도하는 것입니다.

답변1

나는 첫 번째 옵션으로 갔다.

이는 슬레이브가 기본 키와 충돌하는 삽입을 시도하기 시작한 지점까지 작동했습니다. 앞서 언급했듯이 슬레이브는 마스터 bin-log가 지속한 것보다 더 많은 작업을 수행했습니다. 내가 예상하지 못한 한 가지 측면은 마스터에 없는 데이터가 슬레이브에 포함되어 있다는 것입니다. 즉, 슬레이브는 마스터가 정전되기 전에 일부 트랜잭션을 지속했습니다.없었다지속되었습니다.

내 경우에는 이러한 거래가 결제와 관련되거나 유사하지 않았기 때문에 슬레이브에서 데이터를 삭제하기로 결정했습니다(이로 인해 발생했지만 마스터에는 존재하지 않았던 일부 데이터가 손실됨). 그런 다음 복제가 다시 실행되도록 했습니다. . 이것은 노예들을 완전히 최신 상태로 만들었습니다. 데이터가 더 중요했다면 수동으로 데이터를 랭글링하고 참조 무결성이 손상되지 않았는지 확인하기 위한 약간의 여유 공간을 제공하기에 충분한 자동 증가 오프셋이 있습니다. 다행히도 이 경우에는 그렇게 할 필요가 없었습니다.

이러한 곤경에 처한 (수동) 마스터-마스터 구성의 머신에 대해 비슷한 접근 방식을 선택했습니다. 패시브 마스터-마스터란 모든 쓰기가 진행되는 액티브 마스터(serverA)와 가동 중지 시간 없이 스키마 업데이트를 수행할 수 있는 패시브 마스터(serverB)가 있음을 의미합니다. 활성 마스터(serverA)의 데이터가 실제 값으로 선택되었습니다. 이는 중요하지 않은 것으로 간주되는 몇 가지 지속 트랜잭션이 손실되었음을 의미한다는 것을 알고 있음에도 불구하고입니다.

  • 슬레이브의 로그 파일과 위치를 변경했습니다.

    CHANGE MASTER MASTER_LOG_FILE='bin-log.004713', MASTER_LOG_POS=0; -- on serverB

  • 다른 슬레이브와 마찬가지로 기본 키 제약 조건 위반으로 실패할 때까지 패시브 마스터(serverB)에서 슬레이브 복제를 다시 시작했습니다.

     START SLAVE; -- on serverB

  • 패시브 마스터(serverB)에서 액티브 마스터(serverA)로의 슬레이브 복제를 중지했습니다.

    STOP SLAVE; -- on serverA

  • serverA의 마스터에 존재하지 않았던 슬레이브(serverB)의 행을 삭제합니다.

    DELETE FROM SOME_TABLE WHERE ID IN (???,????); -- on serverB
SHOW MASTER STATUS\G; -- get the new master log position on serverB

  • 활성 마스터(serverA) 슬레이브 실행 위치를 이동하여 수동 마스터(serverB)에서 해당 삭제를 건너뜁니다.

    CHANGE MASTER TO MASTER_LOG_POS=???; --on serverA; use the value just obtained from serverB

  • 활성 마스터(serverA)와 수동 마스터 모두에서 복제를 다시 시작합니다.

    START SLAVE; -- on both machines. serverA does nothing and serverB starts catching up.

답변2

슬레이브가 마스터의 정확한 복제본이라는 것이 얼마나 중요한지에 달려 있습니다. 첫 번째 옵션은 어느 정도 작동하지만 슬레이브는 마스터의 정보가 누락될 수 있습니다. 데이터가 일시적이기 때문에 이를 감당할 수 있다면 그렇게 하십시오. 슬레이브가 적절한 복제본인 것이 중요하다면 두 번째 옵션이 아마도 유일한 선택일 것입니다. 불행하게도 MySQL 복제는 어떤 종류의 예상치 못한 중단에도 친절하게 대처하지 않습니다. 저는 이러한 종류의 문제가 복제 아키텍처에서 원하는 것보다 훨씬 더 빈번하다는 것을 발견했습니다.

관련 정보