복제 I/O 스레드가 멈출 때 서버 주소와 binlog 위치를 분리해 확인하는 법

복제 I/O 스레드가 멈출 때 서버 주소와 binlog 위치를 분리해 확인하는 법

I/O 스레드가 멈춘 상태에서는 재시작 횟수보다 마지막 수신 오류 한 줄을 먼저 읽어야 합니다.

이 스레드는 소스 서버에 접속해 binary log 를 받아 relay log 에 기록하는 역할을 하므로, SQL 스레드의 적용 오류와 확인 순서가 다릅니다.

접속 자체가 끊긴 것인지, 접속은 되었지만 요청한 로그 파일을 더 이상 찾을 수 없는 것인지에 따라 조치 방향도 달라집니다.

특히 계정 비밀번호 변경, TLS 인증서 갱신, 방화벽 정책 수정, binlog 보존 기간 축소는 평소 정상인 복제를 갑자기 멈추게 할 수 있습니다.

오류 내용을 남기지 않은 채 시작 명령만 반복하면 원인 로그가 밀려 판단이 늦어질 수 있으므로, 상태값과 시각을 먼저 확보하는 편이 안전합니다.

초기 상태 확인이 필요하면 010-6833-8119 로 현재 오류 문구와 서버 접근 가능 여부를 함께 전달하면 됩니다.

소스 연결과 인증 오류를 먼저 가르는 상태값

가장 먼저 복제 서버에서 SHOW REPLICA STATUS\G를 실행하고 Replica_IO_Running, Last_IO_Error, Source_Host, Source_Log_File를 확인합니다. 재동 STATUS_IO_ERROR처럼 수신 단계의 이상이 보일 때는 SQL 적용 지연을 먼저 손대기보다, I/O 스레드가 소스에 연결을 시도했는지와 어떤 이유로 거절됐는지를 분리해야 합니다.

Replica_IO_Running: No이면서 Last_IO_Error에 연결 거부, 호스트 도달 불가, 인증 실패, TLS 협상 실패 등의 문구가 있다면 우선 연결 정보 흐름을 봐야 합니다. 소스 호스트명이 바뀌었거나 DNS가 다른 주소를 반환하는 경우, 포트가 변경된 경우, 방화벽에서 복제 포트가 막힌 경우도 이 범주에 들어갑니다.

복제 계정은 단순히 존재하는지만 보면 부족합니다. 최근 비밀번호를 교체했는지, 계정의 접속 허용 대상이 변경됐는지, 필요한 복제 권한이 유지되는지 확인해야 합니다. TLS를 강제하는 구성이라면 소스와 복제 서버 양쪽의 인증서 체인, CA 경로, 인증서 만료 시점, 서버 이름 검증 조건까지 함께 비교하는 것이 좋습니다.

사라진 binary log 와 읽기 위치가 맞지 않을 때

연결 자체는 가능해도 소스에 필요한 binary log 가 남아 있지 않으면 I/O 스레드는 이전 위치에서 수신을 이어 갈 수 없습니다. 이때 재동 STATUS_IO_ERROR가 나타났다면 Source_Log_File, Read_Source_Log_Pos 값을 소스 서버의 현재 binlog 목록과 비교해 요청 파일이 실제로 보존돼 있는지부터 확인합니다.

소스에서 SHOW BINARY LOGS;로 파일 목록을 확인했을 때 복제 서버가 요구하는 파일보다 목록의 첫 파일이 더 뒤라면, 필요한 구간은 이미 삭제된 상태일 가능성이 큽니다. binlog 만료 정책, 디스크 부족에 따른 수동 정리, 백업 작업 중 로그 처리 이력도 함께 살펴봐야 합니다.

이 경우 수신 재시작만으로 누락 구간이 되살아나지는 않습니다. 기준 데이터가 신뢰할 수 있는 백업인지, 소스의 현재 데이터로 복제 대상을 다시 맞출지, 서비스 영향 범위를 어디까지 허용할지를 정한 뒤 재동기화 범위를 결정해야 합니다. 파일 이름만 비슷한 다른 binlog 를 임의 지정하거나 위치 값을 추측해 바꾸면 데이터 불일치가 더 커질 수 있습니다.

GTID를 사용하는 환경은 자동 위치 지정이 가능한 경우가 있지만, 그것 역시 소스에 필요한 트랜잭션이 존재한다는 전제가 있어야 합니다. GTID 미사용 구성은 파일명과 좌표를 수동으로 다뤄야 하므로, 마지막 정상 시점의 백업과 소스의 일관된 좌표를 확인하지 않은 상태에서 변경하면 안 됩니다.

수신 재개 전에 남겨야 할 오류 증거

복제 상태 출력은 오류가 난 직후 확보하는 것이 가장 좋습니다. SHOW REPLICA STATUS\G 결과 전체와 MySQL 오류 로그의 시각을 저장하고, 같은 시간대 소스 서버 로그에서 접속 거부·계정 인증·TLS·binlog 정리 관련 기록을 대조합니다. 한쪽 로그만 보면 네트워크 장애처럼 보이는 문제가 실제로는 계정 정책 변경일 수 있습니다.

확인할 값은 Last_IO_Error만이 아닙니다. Source_Host, Source_Port, Source_User, Source_Log_File, Read_Source_Log_Pos, Retrieved_Gtid_Set, Executed_Gtid_Set을 함께 남겨야 연결 실패와 로그 위치 단절을 구분할 수 있습니다. 버전에 따라 항목 이름이 다를 수 있으므로 사용 중인 MySQL 또는 MariaDB 버전도 기록해 두는 편이 좋습니다.

특히 오류 화면이 사라진 뒤에 기억으로 파일명이나 좌표를 입력하는 방식은 위험합니다. 상태 출력 원본, 오류가 시작된 시각, 변경 작업 이력을 묶어 두면 연결 설정을 고칠지 복제를 재구성할지 판단 근거가 분명해집니다.

서초구 일정이 필요한 장비 점검

서버 콘솔에 접근할 수 없거나 방화벽·스위치·인증서 저장 위치를 현장에서만 확인할 수 있는 경우에는 방문 일정을 조율합니다. 다만 상태 출력과 오류 화면, 소스 접속 가능 여부가 준비돼 있으면 원격으로도 연결 문제인지 로그 보존 문제인지 초기 분류가 가능합니다.

재구성 전에 전달하면 좋은 정보

점검 또는 복제 재구성을 결정하기 전에는 I/O 스레드가 멈춘 정확한 시각, 마지막 오류 문구, 소스와 복제 서버의 제품 버전, 최근 계정·인증서·방화벽 변경 여부를 정리해 두면 됩니다. 여기에 binlog 보존 설정과 현재 남아 있는 가장 오래된 로그 파일을 더하면 삭제 구간 여부를 빠르게 판단할 수 있습니다.

GTID 사용 여부도 중요합니다. 자동 위치 지정 구성이더라도 누락된 트랜잭션을 소스가 제공할 수 있는지 확인해야 하며, 수동 좌표 방식이라면 신뢰 가능한 기준 백업과 일치하는 파일·위치를 확보해야 합니다. 원인을 구분한 뒤에만 연결 재개 또는 복제 재구성을 결정하는 것이 안전합니다.

상태 출력 검토와 조치 방향 확인은 동네형컴퓨터 010-6833-8119 또는 https://udns.kr/에서 문의할 수 있습니다.

자주 묻는 질문

복제 상태에서 I/O 스레드만 No 로 표시되면 어떤 구간을 뜻하나요?

소스 서버에서 binary log 를 받아 오는 수신 구간의 문제를 뜻합니다. SQL 스레드가 relay log 내용을 적용하는 과정과는 분리해서 봐야 하며, 우선 연결·인증·TLS·binlog 파일 존재 여부를 확인합니다.

소스 서버의 binary log 가 삭제된 경우 기존 위치에서 수신을 다시 시작할 수 있나요?

필요한 파일이 소스에 남아 있지 않다면 기존 파일과 위치에서는 이어 받을 수 없습니다. 신뢰 가능한 백업 또는 소스의 현재 데이터 기준으로 복제 대상을 다시 맞추는 재동기화 범위를 검토해야 합니다.

복제 계정이나 TLS 설정 문제는 원격 상태 확인만으로 어느 정도 판별할 수 있나요?

Last_IO_Error, 오류 로그, 소스 측 접속 기록이 있으면 상당 부분 구분할 수 있습니다. 다만 방화벽 장비 정책, 인증서 파일 경로, 콘솔 권한처럼 서버 내부 또는 네트워크 장비 확인이 필요한 항목은 추가 접근이 필요할 수 있습니다.