MySQL & MariaDB의 세계

MySQL 복제 가이드: 설정, 유형 및 고가용성을 위한 문제 해결

응용 / 기타
目次

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 복제 설정 단계

이 섹션에서는 MySQL 복제를 단계별로 구성하는 방법을 설명합니다. 아래 절차를 따라 하면 기본적인 마스터‑슬레이브 환경을 구축하고 실시간 데이터 동기화를 구현할 수 있습니다.

마스터 서버 설정

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

  1. 설정 파일 편집
  • [mysqld] 섹션에 다음 설정을 추가하고 고유한 서버 ID(예: 1)를 설정하십시오.
    [mysqld]
server-id=1
log-bin=mysql-bin
  • server-id는 서버마다 고유해야 합니다. log-bin은 바이너리 로그를 활성화합니다.
  1. 복제 사용자 생성
  • 마스터 서버에서 복제 사용자를 생성하고 필요한 권한을 부여합니다.
    CREATE USER 'repl'@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;
  • 이 사용자는 슬레이브가 마스터의 데이터를 액세스하는 데 필요합니다.
  1. 마스터 상태 확인
  • 슬레이브 구성에 필요한 현재 바이너리 로그 파일 및 위치를 확인합니다.
    SHOW MASTER STATUS;
  • 표시된 File 및 Position 값은 슬레이브를 구성할 때 사용됩니다.

슬레이브 서버 구성

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

  1. 구성 파일 편집
  • 슬레이브 서버에 고유한 server-id(예: 2)를 할당합니다. 서버 ID는 마스터와 달라야 합니다.
    [mysqld]
server-id=2
  • 슬레이브에서 의도치 않은 쓰기를 방지하기 위해 read_only=ON을 활성화하는 것이 일반적입니다.
  1. 슬레이브에서 마스터 정보 구성
  • 슬레이브 서버에서 다음 명령을 실행하여 마스터 호스트, 사용자, 바이너리 로그 파일 및 로그 위치를 지정합니다.
    CHANGE MASTER TO
    MASTER_HOST='master_host',
    MASTER_USER='repl',
    MASTER_PASSWORD='password',
    MASTER_LOG_FILE='mysql-bin.000001',
    MASTER_LOG_POS=123;
  • 마스터의 SHOW MASTER STATUS 출력에서 얻은 MASTER_LOG_FILE 및 MASTER_LOG_POS 값을 사용합니다.
  1. 복제 시작
  • 슬레이브 서버에서 다음 명령을 실행하여 복제를 시작합니다.
    START SLAVE;

복제 상태 확인

마스터와 슬레이브 간 복제가 올바르게 작동하는지 확인합니다.

  • 마스터 상태 확인
    SHOW MASTER STATUS;
  • 슬레이브 상태 확인
    SHOW SLAVE STATUSG;
  • Slave_IO_Running과 Slave_SQL_Running이 모두 Yes를 표시하면 복제가 정상적으로 실행되고 있습니다.

다음 섹션에서는 비동기 복제와 반동기 복제의 차이점 및 GTID 기반 설정을 포함한 MySQL 복제의 고급 구성 옵션을 살펴보겠습니다.

4. 복제 유형 및 적용 사례

MySQL 복제는 동기화 방식에 따라 두 가지 주요 유형이 있습니다: 비동기 복제와 반동기 복제. 각 유형의 차이점과 사용 시점을 이해하면 성능과 신뢰성을 최적화할 수 있습니다. 이 섹션에서는 복제 설정에서 GTID(전역 트랜잭션 식별자)를 사용하는 장점도 다룹니다.

비동기 복제와 반동기 복제의 차이점

1. 비동기 복제

비동기 복제에서는 트랜잭션이 완료되면 마스터 서버가 슬레이브가 업데이트를 적용할 때까지 기다리지 않고 즉시 클라이언트에 응답합니다. 이는 뛰어난 응답성을 보장하여 로드 밸런싱 시스템에 적합합니다. 그러나 장애가 발생하면 아직 슬레이브에 적용되지 않은 트랜잭션은 손실될 수 있습니다.

2. 반동기 복제

반동기 복제에서는 마스터 서버가 최소 하나의 슬레이브가 데이터를 수신할 때까지 클라이언트에 응답을 지연합니다. 이는 데이터 일관성을 향상시키지만 마스터가 확인을 기다려야 하므로 트랜잭션 응답 시간이 증가합니다. 반동기 복제는 데이터 일관성과 신뢰성이 우선시되는 환경에 이상적입니다.

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 STATUSG;

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

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

복제 문제 해결

복제에서 흔히 발생하는 문제는 연결 오류와 데이터 불일치입니다. 아래는 전형적인 오류 사례와 해결책입니다.

1. 연결 오류

Slave_IO_Running이 No이면 슬레이브가 마스터에 연결할 수 없습니다. 가능한 해결책은 다음과 같습니다:

  • 마스터 호스트/IP 확인 : 올바른 주소가 설정되어 있는지 확인합니다.
  • 방화벽 설정 : 포트 3306이 열려 있고 접근 가능한지 확인합니다.

2. 데이터 불일치

Last_Error에 오류가 표시되면 마스터와 슬레이브의 데이터가 일치하지 않을 수 있습니다. 해결 방법:

STOP SLAVE;
# Fix the data manually
START SLAVE;

심각한 불일치의 경우, 마스터에서 전체 백업을 복원하여 재동기화합니다.

3. 복제 지연

복제 지연은 슬레이브의 하드웨어 제한이나 네트워크 문제 때문에 발생할 수 있습니다. 하드웨어 업그레이드 또는 쿼리 최적화를 통해 성능을 향상시킬 수 있습니다.

다음 섹션에서는 일반적인 복제 문제와 상세한 해결책을 설명합니다.

6. 일반 복제 문제 및 해결책

MySQL 복제 중 다양한 문제가 발생할 수 있습니다. 이 섹션에서는 흔히 발생하는 문제와 해결 방법을 자세히 설명합니다.

1. Slave_IO_Running이 중지됨

문제: Slave_IO_Running이 No이면 슬레이브가 마스터에 연결할 수 없습니다.

원인 및 해결책:

  • 네트워크 문제 : 방화벽 및 마스터와의 연결을 확인합니다.
  • 잘못된 마스터 호스트/IP : CHANGE MASTER TO 구성을 확인합니다.
  • 사용자 권한 : 복제 사용자가 GRANT REPLICATION SLAVE 로 올바른 권한을 가지고 있는지 확인합니다.

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

문제: 마스터와 슬레이브 간 데이터가 다릅니다.

원인 및 해결책:

  • 수동 수정 : 슬레이브를 중지하고, 불일치 데이터를 수정한 뒤 복제를 다시 시작합니다. STOP SLAVE; # Fix data START SLAVE;
  • 전체 재동기화 : 심각한 불일치의 경우, 마스터에서 백업을 다시 가져옵니다.

3. 복제 지연

문제: Seconds_Behind_Master가 0보다 커서 슬레이브가 뒤처져 있음을 의미합니다.

Causes and Solutions:

  • Hardware Limitations : 슬레이브 서버의 사양을 업그레이드하십시오.
  • Query Optimization : 인덱스와 쿼리를 개선하여 슬레이브의 처리 시간을 줄이십시오.

4. Replication User Privilege Errors

Issue: Last_Error에 나타나는 오류는 권한이 충분하지 않음을 나타냅니다.

Solution:

  • Grant Correct Privileges : 적절한 복제 권한을 보장하십시오. GRANT REPLICATION SLAVE ON *.* TO 'repl'@'slave_ip'; FLUSH PRIVILEGES;

5. Binary Log Growth

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

Solution:

  • Log Rotation : expire_logs_days를 사용하여 오래된 로그를 자동으로 삭제합니다. SET GLOBAL expire_logs_days = 7; # 7일보다 오래된 로그 삭제

By understanding and preparing for these common problems, administrators can maintain stable replication operations.

7. Conclusion

MySQL Replication은 데이터 일관성과 시스템 신뢰성을 보장하는 필수 기능입니다. 이 문서에서는 복제의 기본, 설정 절차, 모니터링 및 문제 해결을 다루었습니다. 아래는 주요 포인트 요약입니다.

Key Takeaways

  1. Choose the Right Replication Type
  • 비동기 복제는 속도와 부하 분산을 제공하고, 반동기 복제는 더 높은 신뢰성을 제공합니다. 시스템 요구 사항에 따라 선택하십시오.
  1. Leverage GTID
  • GTID는 바이너리 로그 위치를 지정할 필요 없이 복제를 단순화하여 대규모 또는 중요한 환경에 유용합니다.
  1. Monitor Status Regularly
  • SHOW MASTER STATUS와 SHOW SLAVE STATUS를 자주 사용하여 이상을 조기에 감지하고 위험을 최소화하십시오.
  1. Master Troubleshooting Skills
  • 연결 오류, 불일치, 지연 등 복제와 관련된 문제를 처리하는 방법에 익숙해지십시오.
  1. Manage Binary Logs
  • expire_logs_days를 설정하고 로그를 정기적으로 회전시켜 디스크 사용 문제를 방지하십시오.

MySQL Replication은 초기 설정뿐만 아니라 지속적인 모니터링과 유지 관리가 필요합니다. 상태를 정기적으로 확인하고 필요에 따라 구성을 조정함으로써 고신뢰성 데이터베이스 시스템을 구축하고 유지할 수 있습니다.

이 가이드가 MySQL 복제를 효과적으로 이해하고 구현하는 데 도움이 되길 바라며, 원활하고 안정적인 운영을 보장합니다.