Practical MySQL & MariaDB

MySQL 복제 설명: 설정, GTID, 모니터링 및 문제 해결 가이드

고급 / 기타
目次

1. MySQL 복제란 무엇인가? 개요 및 사용 사례

MySQL 복제는 데이터베이스 복사본을 실시간으로 다른 서버와 동기화하는 기능입니다. 이를 통해 데이터베이스의 중복성과 성능을 향상시킬 수 있습니다. 아래에서는 MySQL 복제를 언제 사용하고 어떻게 동작하는지 자세히 설명합니다.

MySQL 복제 개요

MySQL 복제는 마스터 서버와 하나 이상의 슬레이브 서버를 사용하여 여러 서버에 데이터베이스 내용을 공유합니다. 구체적으로는 마스터 서버의 바이너리 로그에 기록된 데이터 업데이트를 슬레이브 서버가 읽어 적용함으로써 데이터를 동기화합니다. 이를 통해 마스터 서버에 장애가 발생했을 때 슬레이브 서버로 전환하여 서비스 연속성을 유지할 수 있습니다.

MySQL 복제 사용 사례

MySQL 복제는 다음과 같은 시나리오에서 널리 사용됩니다:

  • 고가용성 : 장애 발생 시 슬레이브 서버로 전환함으로써 다운타임을 최소화합니다.
  • 로드 밸런싱 : 읽기 전용 쿼리를 슬레이브 서버에 분산시켜 마스터 서버의 부하를 감소시킵니다.
  • 데이터 보호 및 백업 : 복제가 실시간으로 데이터를 복제하기 때문에 백업 메커니즘으로도 활용될 수 있습니다.

복제 유형

MySQL 복제는 동기화 방식에 따라 다음과 같은 유형을 포함합니다:

  • 비동기 복제 : 마스터가 슬레이브의 확인을 기다리지 않고 진행합니다. 이는 응답 시간을 빠르게 하지만 장애 시 일부 데이터가 슬레이브에 도달하지 않을 수 있습니다.
  • 준동기 복제 : 마스터가 데이터를 슬레이브가 수신했다는 확인을 받은 후에 진행합니다. 비동기 복제보다 신뢰성이 높지만 응답 시간이 약간 느려집니다.

다음 섹션에서는 바이너리 로그와 GTID를 포함한 MySQL 복제의 기본 개념을 설명합니다.

2. MySQL 복제의 기본 개념

MySQL 복제를 이해하려면 복제 과정에서 핵심적인 역할을 하는 바이너리 로그와 GTID(글로벌 트랜잭션 ID)의 역할을 파악하는 것이 중요합니다. 이 요소들은 정확한 데이터 복제의 기반을 형성합니다.

마스터와 슬레이브의 역할

MySQL 복제에서 마스터 서버와 슬레이브 서버는 각각 고유한 역할을 수행합니다. 마스터는 데이터 업데이트를 바이너리 로그에 기록하고 이를 슬레이브에 전송합니다. 슬레이브는 수신한 로그를 적용하여 데이터를 업데이트합니다. 결과적으로 슬레이브는 마스터와 동일한 데이터를 유지합니다.

바이너리 로그와 릴레이 로그

MySQL 복제는 다음 두 가지 로그에 의존합니다:

  1. 바이너리 로그
  • 바이너리 로그는 마스터 서버에서 데이터 업데이트(INSERT, UPDATE, DELETE 등)를 기록합니다. 이를 통해 슬레이브 서버는 마스터와 동일한 데이터 상태를 유지할 수 있습니다.
  1. 릴레이 로그
  • 릴레이 로그는 슬레이브 서버가 마스터로부터 받은 바이너리 로그 이벤트를 저장합니다. 슬레이브의 SQL 스레드는 릴레이 로그를 순차적으로 실행하여 데이터 변경을 적용합니다.

GTID(글로벌 트랜잭션 ID)란?

GTID는 각 트랜잭션에 고유 ID를 부여하는 메커니즘으로, 여러 슬레이브 간 일관성을 유지하는 데 도움을 줍니다. GTID를 사용하면 바이너리 로그 위치를 지정할 필요가 없어집니다. 마스터에서 아직 가져오지 않은 트랜잭션만 자동으로 슬레이브에 적용되어 관리가 크게 단순화됩니다.

GTID의 장점

  • 고유 식별 : 각 트랜잭션에 고유 GTID가 할당되어 어떤 트랜잭션이 적용되었는지 명확히 식별할 수 있습니다.
  • 복구 용이 : GTID를 사용할 경우 마스터 또는 슬레이브가 재시작된 후 적용되지 않은 트랜잭션만 다시 처리됩니다.
  • 운영 관리 효율 : 다수의 슬레이브가 있는 대규모 환경에서도 트랜잭션 일관성을 간소화된 관리로 유지할 수 있습니다.

GTID를 사용하려면 gtid_mode=ON 및 enforce_gtid_consistency=ON 설정이 필요합니다. 마스터와 슬레이브 모두에서 이 설정을 구성하면 GTID 기반 복제가 활성화됩니다.

다음 섹션에서는 MySQL 복제를 설정하는 구체적인 단계에 대해 설명합니다.

3. MySQL Replication Setup Procedure

이 섹션에서는 MySQL 복제를 설정하는 데 필요한 단계를 설명합니다. 이러한 단계를 따르면 기본 마스터-슬레이브 구조를 구성하고 실시간 데이터 동기화를 활성화할 수 있습니다.

Configuring the Master Server

먼저, 마스터 서버의 구성 파일(보통 my.cnf 또는 my.ini)을 편집하여 바이너리 로그를 활성화하고 서버 ID를 설정합니다.

  1. Edit the Configuration File
  • [mysqld] 섹션 아래에 다음 설정을 추가하고 고유한 서버 ID(예: 1)를 설정합니다.
    [mysqld]
server-id=1
log-bin=mysql-bin
  • server-id는 각 서버에 대해 고유한 숫자여야 하며, log-bin은 바이너리 로그를 활성화합니다.
  1. Create a Replication User
  • 마스터 서버에 전용 복제 사용자를 생성하고 필요한 권한을 부여합니다.
    CREATE USER 'repl'@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;
  • 이 사용자는 슬레이브 서버가 마스터로부터 데이터를 액세스하는 데 필요합니다.
  1. Check the Master Status
  • 현재 바이너리 로그 파일과 위치(로그 위치)를 확인합니다. 이 정보는 슬레이브 서버를 구성할 때 필요합니다.
    SHOW MASTER STATUS;
  • 이 명령어로 표시되는 File(로그 파일 이름)과 Position은 슬레이브 구성에 사용됩니다.

Configuring the Slave Server

다음으로, 슬레이브 서버의 구성 파일을 편집하고 서버 ID와 마스터 정보를 구성합니다.

  1. Edit the Configuration File
  • 슬레이브 서버에도 고유한 server-id(예: 2)를 설정합니다. 이 값은 마스터의 서버 ID와 달라야 합니다.
    [mysqld]
server-id=2
  • 슬레이브 서버에서 데이터 쓰기를 방지하기 위해 read_only=ON을 설정하는 것도 일반적입니다.
  1. Configure Master Information on the Slave
  • 슬레이브 서버에서 다음 명령어를 실행하여 마스터의 호스트 이름, 사용자, 바이너리 로그 파일 이름 및 위치를 지정합니다.
    CHANGE MASTER TO
    MASTER_HOST='master_host',
    MASTER_USER='repl',
    MASTER_PASSWORD='password',
    MASTER_LOG_FILE='mysql-bin.000001',
    MASTER_LOG_POS=123;
  • MASTER_LOG_FILE과 MASTER_LOG_POS에 대해 마스터에서 이전에 확인한 값을 입력합니다.
  1. Start Replication
  • 복제를 시작하기 위해 슬레이브 서버에서 다음 명령어를 실행합니다.
    START SLAVE;

Verifying Replication Status

마스터와 슬레이브 간의 복제가 올바르게 구성되었는지 확인합니다.

  • Check Master Status
    SHOW MASTER STATUS;
  • Check Slave Status
    SHOW SLAVE STATUS\G;
  • Slave_IO_Running과 Slave_SQL_Running이 모두 Yes로 표시되면 복제가 정상적으로 작동하고 있습니다.

다음 섹션에서는 비동기 복제와 세미-동기 복제 간의 차이점과 GTID를 사용한 설정을 포함한 고급 복제 구성을 설명합니다.

4. Types of Replication and Advanced Usage

MySQL 복제에는 데이터 동기화 방법에 기반한 두 가지 주요 유형이 있습니다: asynchronous replication과 semi-synchronous replication. 그 특성을 이해하고 사용 사례에 따라 선택함으로써 시스템 성능과 신뢰성을 모두 향상시킬 수 있습니다. 이 섹션에서는 복제 구성에 GTID (Global Transaction Identifier)를 사용하는 이점도 설명합니다.

Differences Between Asynchronous and Semi-Synchronous Replication

1. Asynchronous Replication

비동기 복제에서 마스터 서버는 트랜잭션을 완료한 직후 클라이언트에게 응답을 반환합니다. 즉, 슬레이브 서버로의 동기화가 지연되는 동안에도 마스터는 새로운 요청 처리를 계속할 수 있습니다. 이는 우수한 응답 성능을 제공하며 로드 분산에 중점을 둔 시스템에 적합합니다. 그러나 장애 발생 시 슬레이브 서버에 아직 적용되지 않은 데이터가 손실될 위험이 있습니다.

2. Semi-Synchronous Replication

In semi-synchronous replication, the master server returns a response to the client only after confirming that data transfer to the slave server has completed. This improves data consistency, but because it waits for the slave, transaction response times may increase. Semi-synchronous replication is well suited for systems that require high data consistency or environments where data reliability is the top priority.

반동기 복제에서는 마스터 서버가 슬레이브 서버로의 데이터 전송이 완료되었음을 확인한 후에만 클라이언트에 응답을 반환합니다. 이는 데이터 일관성을 향상시키지만, 슬레이브를 기다리기 때문에 트랜잭션 응답 시간이 증가할 수 있습니다. 반동기 복제는 높은 데이터 일관성이 필요하거나 데이터 신뢰성이 최우선인 환경에 적합합니다.

GTID를 이용한 복제

GTID(전역 트랜잭션 식별자)는 각 트랜잭션에 고유한 ID를 부여하고 마스터와 슬레이브 간의 트랜잭션 일관성을 유지합니다. GTID를 활성화하면 기존의 바이너리 로그 위치 기반 복제에 비해 복제 관리를 더 쉽게 할 수 있습니다.

GTID의 장점

  • 데이터 일관성 향상 : GTID를 사용하면 슬레이브가 아직 적용되지 않은 트랜잭션을 자동으로 식별할 수 있어 일관성을 유지하기가 더 쉬워집니다.
  • 복제 관리 간소화 : GTID는 장애 조치, 마스터/슬레이브 전환 및 복구 작업의 효율성을 높입니다. 바이너리 로그 위치를 지정할 필요가 없어 작업이 간단해집니다.

GTID 복제 구성

GTID를 사용하려면 마스터와 슬레이브 모두의 설정 파일에 다음 옵션을 추가하고 활성화해야 합니다.

마스터 서버 구성

[mysqld]
server-id=1
log-bin=mysql-bin
gtid_mode=ON
enforce_gtid_consistency=ON

슬레이브 서버 구성

[mysqld]
server-id=2
gtid_mode=ON
enforce_gtid_consistency=ON
read_only=ON

GTID가 활성화된 환경에서는 슬레이브에서 CHANGE MASTER TO 명령을 사용해 마스터 정보를 설정하기만 하면 GTID를 통해 복제가 자동으로 수행됩니다.

다음 섹션에서는 MySQL 복제의 유지 관리 방법과 운영 관리에 필요한 주요 모니터링 포인트를 설명합니다.

5. 복제 유지 관리 및 모니터링

MySQL 복제를 올바르게 운영하려면 정기적인 유지 관리와 모니터링이 필수입니다. 이 섹션에서는 복제가 정상적으로 동작하는지 확인하는 명령과 일반적인 오류를 처리하는 방법을 설명합니다.

복제 상태 확인 방법

다음 명령을 사용하여 마스터와 슬레이브 간의 동기화 상태를 확인합니다.

마스터 상태 확인

SHOW MASTER STATUS 명령을 사용하면 마스터 서버의 복제 상태를 확인할 수 있습니다. 이 명령은 현재 바이너리 로그 파일 이름과 위치를 표시하여 슬레이브에 전달되어야 할 최신 업데이트를 확인할 수 있게 해줍니다.

SHOW MASTER STATUS;

출력에는 일반적으로 다음 필드가 포함됩니다:

  • File : 마스터가 생성한 현재 바이너리 로그 파일 이름
  • Position : 바이너리 로그 내 현재 위치
  • Binlog_Do_DB 및 Binlog_Ignore_DB : 복제에 포함되거나 제외된 데이터베이스

슬레이브 상태 확인

SHOW SLAVE STATUS 명령을 사용하면 슬레이브 서버의 복제 상태를 확인할 수 있습니다. 결과에는 슬레이브가 정상적으로 작동하고 있는지 판단하는 데 필요한 정보가 포함됩니다.

SHOW SLAVE STATUS\G;

주요 필드에는 다음이 포함됩니다:

  • Slave_IO_Running 및 Slave_SQL_Running : 두 값이 모두 Yes이면 슬레이브가 정상적으로 실행 중입니다.
  • Seconds_Behind_Master : 슬레이브가 마스터보다 얼마나 뒤처져 있는지를 초 단위로 나타냅니다. 이상적으로 이 값은 0이어야 합니다.

복제 문제 해결

복제 운영 중 흔히 발생하는 문제로는 연결 오류와 데이터 불일치가 있습니다. 아래는 전형적인 오류 사례와 해결 방법을 소개합니다.

1. 연결 오류

Slave_IO_Running이 No이면 슬레이브가 마스터에 연결할 수 없다는 의미입니다. 다음을 시도해 보세요:

  • 마스터 호스트명 또는 IP 주소 확인 : 마스터 주소가 올바른지 확인합니다.
  • 방화벽 설정 확인 : 필요한 포트(보통 3306)가 열려 있는지 확인합니다.

2. 데이터 불일치

If Last_Error에 오류 메시지가 포함되어 있으면 마스터와 슬레이브 사이에 데이터 불일치가 발생했을 수 있습니다. 이런 경우 슬레이브를 중지하고 복제를 재시작하기 전에 수정 작업을 적용하십시오.

STOP SLAVE;
# Restart after applying fixes
START SLAVE;

3. 복제 지연 감소

복제 지연은 슬레이브 하드웨어 제한이나 네트워크 문제로 인해 발생할 수 있습니다. 필요하다면 슬레이브 서버 구성을 업그레이드하여 성능을 향상시킬 수 있습니다.

다음 섹션에서는 복제 문제를 보다 자세히 살펴보고 추가적인 해결책을 제공합니다.

6. 일반적인 문제와 해결책

MySQL 복제 작업 중에는 다양한 문제가 발생할 수 있습니다. 이 섹션에서는 일반적인 문제와 해결 방법을 설명합니다. 문제를 조기에 감지하고 올바른 수정을 적용하면 안정적인 시스템 운영을 유지하는 데 도움이 됩니다.

1. Slave_IO_Running이 중지된 경우

증상: SHOW SLAVE STATUS 출력에서 Slave_IO_Running이 No로 표시되면 슬레이브가 마스터에 연결할 수 없습니다.

원인 및 해결책:

  • 네트워크 문제: 네트워크 연결에 문제가 있으면 슬레이브가 마스터에 접근할 수 없습니다. 방화벽 설정을 확인하고 마스터에 도달할 수 있는지 확인하십시오.
  • 잘못된 마스터 호스트명 또는 IP 주소: CHANGE MASTER TO에 지정된 호스트명이나 IP 주소가 올바른지 확인하십시오.
  • 사용자 권한 문제: 마스터의 복제 사용자가 충분한 권한을 가지고 있지 않으면 연결이 실패합니다. GRANT REPLICATION SLAVE를 사용하여 올바른 권한이 부여되었는지 확인하십시오.

2. 슬레이브의 데이터 불일치

증상: 마스터와 슬레이브 간 데이터가 일치하지 않으면 슬레이브가 불일치 상태에 빠질 수 있습니다.

원인 및 해결책:

  • 수동 데이터 수정: 슬레이브를 중지하고 문제 트랜잭션을 수동으로 수정한 뒤 복제를 재시작합니다. STOP SLAVE; # 필요시 데이터 수정 START SLAVE;
  • 재동기화: 불일치가 대규모인 경우 마스터에서 전체 백업을 받아 슬레이브를 재동기화합니다.

3. 복제 지연

증상: SHOW SLAVE STATUS 출력에서 Seconds_Behind_Master가 0이 아니면 슬레이브가 마스터보다 뒤처져 있습니다. 이상적으로 이 값은 0에 가깝게 유지되어야 합니다.

원인 및 해결책:

  • 슬레이브 하드웨어 제한: 슬레이브 서버의 자원이 부족하면 따라가지 못할 수 있습니다. 하드웨어 업그레이드가 효과적일 수 있습니다.
  • 쿼리 최적화: 마스터에서 전달된 쿼리가 슬레이브에서 실행되는 데 오래 걸리면 복제 지연이 발생합니다. 인덱스를 추가하고 쿼리를 최적화하면 처리 시간을 줄일 수 있습니다.

4. 복제 사용자 권한 오류

증상: Last_Error에 권한 관련 메시지가 표시되면 슬레이브가 마스터에 연결할 충분한 권한이 없을 수 있습니다.

원인 및 해결책:

  • 사용자 권한 재구성: 마스터에 적절한 권한을 가진 사용자가 존재하는지 확인하고, 필요하면 재구성하십시오. GRANT REPLICATION SLAVE ON *.* TO 'repl'@'slave_ip_address'; FLUSH PRIVILEGES;

5. 바이너리 로그 증가

증상: 마스터의 바이너리 로그가 과도하게 증가하여 디스크 공간을 차지할 수 있습니다.

원인 및 해결책:

  • 바이너리 로그 순환: 과도한 로그 증가를 방지하기 위해 바이너리 로그를 정기적으로 삭제하거나 보관하십시오. expire_logs_days를 설정하면 지정된 기간보다 오래된 로그를 자동으로 제거할 수 있습니다. SET GLOBAL expire_logs_days = 7; # 7일보다 오래된 로그 삭제

이러한 일반적인 MySQL 복제 문제와 해결책을 이해하면 보다 원활한 운영 관리를 보장할 수 있습니다. 다음 섹션에서는 복제 관리의 핵심 포인트를 요약합니다.

7. 결론

MySQL 복제는 데이터 일관성 및 시스템 신뢰성을 향상시키는 중요한 기능입니다. 이 문서에서는 MySQL 복제의 기본 개념부터 설정 절차, 모니터링 방법, 문제 해결 방법까지 모두 다루었습니다. 아래는 효과적인 복제 관리를 위한 핵심 요점 요약입니다.

주요 내용

  1. 올바른 복제 유형 선택
  • 비동기 복제는 응답 속도가 빠르고 부하 분산에 이상적입니다. 그러나 신뢰성이 우선이라면 반동기 복제가 더 적합합니다. 시스템 요구 사항에 따라 선택하십시오.
  1. GTID의 효과적인 활용
  • GTID는 바이너리 로그 위치를 지정할 필요를 없애고 원활한 트랜잭션 관리를 가능하게 합니다. 특히 다수의 슬레이브가 있거나 장애 조치가 중요한 환경에서 유용합니다.
  1. 정기적인 상태 모니터링
  • SHOW MASTER STATUS와 SHOW SLAVE STATUS를 사용하여 마스터와 슬레이브 서버의 운영 상태를 정기적으로 모니터링하십시오. 이상 징후를 감지하면 즉시 조치를 취해 데이터 불일치나 지연과 같은 위험을 최소화할 수 있습니다.
  1. 기본 문제 해결 능력 습득
  • 일반적인 복제 문제에는 슬레이브 연결 오류, 데이터 불일치, 지연 등이 있습니다. 각 문제에 대한 기본 해결책을 이해하면 운영이 보다 원활해집니다.
  1. 바이너리 로그 관리
  • 바이너리 로그는 상당한 디스크 공간을 차지할 수 있으므로 expire_logs_days를 설정해 자동 정리를 수행하고 정기적인 유지 보수를 권장합니다.

MySQL 복제는 일회성 설정 작업이 아닙니다. 지속적인 모니터링과 적절한 유지 보수가 필수입니다. 시스템 상태를 정기적으로 검토하고 필요에 따라 구성을 조정함으로써 고신뢰성 데이터베이스 시스템을 구축하고 유지할 수 있습니다.

이 가이드가 MySQL 복제를 보다 잘 이해하고 구현하는 데 도움이 되길 바랍니다. 원활하고 안정적인 복제 운영을 기원합니다.