MySQL에서 복제를 설정하는 방법

이 튜토리얼의 이전 버전은 Etel Sverdlov가 작성했습니다.

소개

데이터베이스로 작업할 때 데이터의 여러 복사본을 보유하는 것이 유용할 수 있습니다. 이는 데이터베이스 서버 중 하나가 실패하는 경우 중복성을 제공하고 데이터베이스의 가용성, 확장성 및 전반적인 성능을 향상시킬 수 있습니다. 여러 개별 데이터베이스에서 데이터를 동기화하는 방식을 복제라고 합니다.

MySQL은 관계형 데이터베이스 관리 시스템이며 오늘날 세계에서 가장 널리 사용되는 오픈 소스 관계형 데이터베이스입니다. 여러 복제 기능이 내장되어 있어 데이터의 여러 복사본을 유지할 수 있습니다.

이 자습서에서는 한 서버에서 소스 데이터베이스로 MySQL 인스턴스를 구성한 다음 복제본으로 작동하도록 다른 서버에서 MySQL 인스턴스를 구성하는 방법을 설명합니다. 또한 MySQL이 복제를 처리하는 방법에 대한 개요도 포함합니다.

참고: 역사적으로 이러한 유형의 데이터베이스 복제를 "마스터-슬레이브\ 복제라고 합니다. 2020년 7월에 게시된 블로그 게시물에서 MySQL 팀은 이 용어의 부정적인 기원을 인정하고 데이터베이스 업데이트 노력을 발표했습니다. 보다 포괄적인 언어를 사용하기 위한 프로그램 및 문서.

그러나 이것은 진행 중인 프로세스입니다. MySQL 문서와 프로그램 8 버전의 많은 명령이 대신 복제 토폴로지의 서버를 소스 및 복제본으로 참조하도록 업데이트되었지만 부정적인 용어가 여전히 나타나는 곳이 있습니다. 이 가이드는 가능하면 더 포괄적인 source-replica 용어를 기본값으로 사용하지만 불가피하게 이전 용어가 나오는 경우가 몇 가지 있습니다.

전제 조건

이 가이드를 완료하려면 다음이 필요합니다.

Ubuntu 20.04를 실행하는 두 대의 서버. 둘 다 sudo 권한이 있는 루트가 아닌 관리 사용자와 UFW로 구성된 방화벽이 있어야 합니다. Ubuntu 20.04용 초기 서버 설정 가이드에 따라 두 서버를 모두 설정하세요.
각 서버에 설치된 MySQL. 이 가이드는 기본 Ubuntu 리포지토리에서 사용할 수 있는 최신 버전의 MySQL을 사용하고 있다고 가정합니다. 현재 버전은 8.0.25입니다. 두 서버에 모두 설치하려면 Ubuntu 20.04에 MySQL을 설치하는 방법에 대한 가이드를 따르세요.

이 가이드에 설명된 절차에는 한 서버의 MySQL 설치를 소스 데이터베이스로 지정한 다음 다른 서버의 MySQL 설치를 소스의 복제본으로 구성하는 작업이 포함됩니다. >. 명확하게 하기 위해 원본 데이터베이스의 서버에서 실행해야 하는 모든 명령은 다음과 같이 파란색 배경을 갖습니다.

마찬가지로 복제본 MySQL 인스턴스의 서버에서 실행해야 하는 모든 명령의 배경은 빨간색입니다.

마지막으로 이 자습서에는 기존 데이터베이스의 데이터를 원본에서 복제본으로 마이그레이션하는 방법에 대한 선택적 지침이 포함되어 있습니다. 이 프로세스에는 소스 데이터베이스의 스냅샷을 생성하고 결과 파일을 복제본에 복사하는 작업이 포함됩니다. 이를 위해서는 원본 서버 서버에 SSH 키를 설정한 다음 원본의 공개 키가 복제본에 복사되었는지 확인하는 것이 좋습니다.

MySQL의 복제 이해

MySQL에서 복제는 소스 데이터베이스가 바이너리 로그라고 하는 특수 파일에 하나 이상의 데이터베이스에 보관된 데이터에 대한 모든 변경 사항을 기록하는 것과 관련됩니다. 복제본 인스턴스가 초기화되면 두 개의 스레드 프로세스가 생성됩니다. IO 스레드라고 하는 첫 번째 스레드는 원본 MySQL 인스턴스에 연결하고 바이너리 로그 이벤트를 한 줄씩 읽은 다음 릴레이라고 하는 복제 서버의 로컬 파일에 복사합니다. 로그. SQL 스레드라고 하는 두 번째 스레드는 릴레이 로그에서 이벤트를 읽은 다음 가능한 빨리 복제본 인스턴스에 적용합니다.

최신 버전의 MySQL은 데이터 복제를 위한 두 가지 방법을 지원합니다. 이러한 복제 방법의 차이점은 복제본이 이미 처리한 소스의 데이터베이스 이벤트를 추적하는 방법과 관련이 있습니다.

MySQL은 기존 복제 방법을 이진 로그 파일 위치 기반 복제라고 합니다. 이 방법을 사용하여 MySQL 인스턴스를 복제본으로 전환할 때 바이너리 로그 좌표 세트를 제공해야 합니다. 이는 복제본이 읽어야 하는 소스의 바이너리 로그 파일 이름과 복제본이 자신의 MySQL 인스턴스에 복사해야 하는 첫 번째 데이터베이스 이벤트를 나타내는 해당 파일 내의 특정 위치로 구성됩니다.

레플리카는 소스의 전체 바이너리 로그 사본을 수신하고 올바른 좌표가 없으면 그 안에 기록된 모든 데이터베이스 이벤트를 복제하기 시작하므로 이러한 좌표는 중요합니다. 특정 시점 이후에만 데이터를 복제하거나 원본 데이터의 하위 집합만 복제하려는 경우 문제가 발생할 수 있습니다.

이진 로그 파일 위치 기반 복제는 많은 사용 사례에서 실행 가능하지만 이 방법은 더 복잡한 설정에서 투박해질 수 있습니다. 이로 인해 트랜잭션 기반 복제라고도 하는 MySQL의 최신 기본 복제 방법이 개발되었습니다. 이 방법에는 원본 MySQL 인스턴스가 실행하는 각 트랜잭션(또는 데이터베이스에서 수행하는 격리된 작업)에 대한 전역 트랜잭션 식별자(GTID) 생성이 포함됩니다.

트랜잭션 기반 복제의 메커니즘은 이진 로그 파일 기반 복제와 유사합니다. 소스에서 데이터베이스 트랜잭션이 발생할 때마다 MySQL은 트랜잭션 자체와 함께 이진 로그 파일의 트랜잭션에 대한 GTID를 할당하고 기록합니다. 그런 다음 GTID와 트랜잭션이 처리할 소스의 복제본으로 전송됩니다.

MySQL의 트랜잭션 기반 복제는 기존 복제 방법에 비해 여러 가지 이점이 있습니다. 예를 들어 소스와 해당 복제본 모두 GTID를 보존하기 때문에 소스 또는 복제본이 GTID가 있는 트랜잭션을 만나면 해당 트랜잭션을 건너뛰기 전에 처리했습니다. 이는 소스와 해당 복제본 간의 일관성을 보장하는 데 도움이 됩니다. 또한 트랜잭션 기반 복제 복제본은 처리할 다음 데이터베이스 이벤트의 바이너리 로그 좌표를 알 필요가 없습니다. 즉, 새 복제본을 시작하거나 복제 체인에서 복제본 순서를 변경하는 것이 훨씬 덜 복잡합니다.

이것은 MySQL이 복제를 처리하는 방법에 대한 일반적인 설명일 뿐임을 명심하십시오. MySQL은 자신의 복제 설정을 최적화하기 위해 조정할 수 있는 많은 옵션을 제공합니다. 이 가이드는 바이너리 로그 파일 위치 기반 복제를 설정하는 방법을 설명합니다. 하지만 다른 유형의 복제 환경을 구성하는 데 관심이 있다면 MySQL의 공식 문서를 확인하는 것이 좋습니다.

1단계 - 원본 서버의 방화벽 조정

전제 조건인 초기 서버 설정 가이드를 따랐다고 가정하면 UFW를 사용하여 두 서버 모두에 방화벽을 구성했을 것입니다. 이렇게 하면 두 서버의 보안을 유지하는 데 도움이 되지만 소스의 방화벽이 복제본 MySQL 인스턴스의 모든 연결 시도를 차단합니다.

이를 변경하려면 소스의 방화벽을 통해 복제본에서 연결을 허용하는 UFW 규칙을 포함해야 합니다. 원본 서버에서 다음과 같은 명령을 실행하여 이 작업을 수행할 수 있습니다.

이 특정 명령은 replica_server_ip로 표시되는 레플리카 서버의 IP 주소에서 시작된 모든 연결을 MySQL의 기본 포트 번호인 3306으로 허용합니다.

sudo ufw allow from replica_server_ip to any port 3306

replica_server_ip를 복제본 서버의 실제 IP 주소로 바꾸십시오. 규칙이 성공적으로 추가되면 다음 출력이 표시됩니다.

OutputRule added

그런 다음 복제본 서버가 들어오는 연결을 수신하지 않고 소스 MySQL 서버로 나가는 연결이 UFW에 의해 차단되지 않기 때문에 복제본의 방화벽 규칙을 변경할 필요가 없습니다. 복제를 활성화하기 위해 원본 MySQL 인스턴스의 구성 업데이트로 이동할 수 있습니다.

2단계 - 원본 데이터베이스 구성

원본 MySQL 데이터베이스에서 데이터 복제를 시작하려면 해당 구성을 몇 가지 변경해야 합니다.

Ubuntu 20.04에서 기본 MySQL 서버 구성 파일의 이름은 mysqld.cnf이며 /etc/mysql/mysql.conf.d/ 디렉토리에서 찾을 수 있습니다. 원하는 텍스트 편집기를 사용하여 원본 서버에서 이 파일을 엽니다. 여기서는 nano를 사용합니다.

sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

파일 내에서 bind-address 지시문을 찾습니다. 기본적으로 다음과 같이 표시됩니다.

. . .
bind-address            = 127.0.0.1
. . .

127.0.0.1은 localhost를 나타내는 IPv4 루프백 주소이며 이것을 bind-address 지시문의 값으로 설정하면 MySQL은 localhost 주소의 연결만 수신 대기합니다. 즉, 이 MySQL 인스턴스는 설치된 서버에서 시작된 연결만 수락할 수 있습니다.

다른 MySQL 인스턴스를 이 인스턴스의 복제본으로 전환하고 있으므로 복제본은 원본 설치에 기록되는 모든 새 데이터를 읽을 수 있어야 합니다. 이를 허용하려면 복제본이 도달할 수 있는 IP 주소(예: 원본 서버의 퍼블릭 IP 주소)에서 연결을 수신하도록 원본 MySQL 인스턴스를 구성해야 합니다.

127.0.0.1을 원본 서버의 IP 주소로 바꿉니다. 이렇게 하면 bind-address 지시문이 source_server_ip 자리에 자신의 서버 IP 주소를 사용하여 다음과 같이 표시됩니다.

. . .
bind-address            = source_server_ip
. . .

다음으로 MySQL이 복제 설정에서 서버를 구별하기 위해 내부적으로 사용하는 식별자를 정의하는 server-id 지시문을 찾습니다. 복제 환경의 모든 서버(소스 및 복제본 포함)에는 고유한 server-id 값이 있어야 합니다. 이 지시문은 기본적으로 주석 처리되며 다음과 같습니다.

. . .
# server-id             = 1
. . .

파운드 기호(#)를 제거하여 이 행의 주석 처리를 제거하십시오. 이 지시문의 값으로 숫자를 선택할 수 있지만 숫자는 고유해야 하며 복제 그룹의 다른 server-id와 일치할 수 없습니다. 간단하게 하기 위해 다음 예제에서는 이 값을 기본값인 1로 둡니다.

. . .
server-id               = 1
. . .

server-id 줄 아래에서 log_bin 지시문을 찾습니다. 이는 MySQL 바이너리 로그 파일의 기본 이름과 위치를 정의합니다.

이 지시문을 주석 처리하면 기본적으로 이진 로깅이 비활성화됩니다. 레플리카 서버는 소스의 바이너리 로그 파일을 읽어야 소스의 데이터를 복제하는 시기와 방법을 알 수 있으므로 소스에서 바이너리 로깅을 활성화하려면 이 행의 주석을 제거하십시오. 이렇게 하면 다음과 같이 표시됩니다.

. . .
log_bin                       = /var/log/mysql/mysql-bin.log
. . .

마지막으로 파일 맨 아래로 스크롤하여 주석 처리된 binlog_do_db 지시문을 찾습니다.

. . .
# binlog_do_db          = include_database_name

파운드 기호를 제거하여 이 줄의 주석을 제거하고 include_database_name을 복제하려는 데이터베이스의 이름으로 바꿉니다. 이 예는 db라는 데이터베이스를 가리키는 binlog_do_db 지시문을 보여주지만 소스에 복제하려는 기존 데이터베이스가 있는 경우 db 대신 해당 이름을 사용하십시오.

. . .
binlog_do_db          = db

참고: 둘 이상의 데이터베이스를 복제하려는 경우 추가하려는 모든 데이터베이스에 대해 다른 binlog_do_db 지시문을 추가할 수 있습니다. 이 자습서는 단일 데이터베이스만 복제하는 것으로 계속 진행되지만 더 복제하려는 경우 다음과 같이 표시될 수 있습니다.

. . .
binlog_do_db          = db
binlog_do_db          = db_1
binlog_do_db          = db_2

또는 각각에 대해 binlog_ignore_db 지시문을 추가하여 MySQL이 복제하지 않아야 하는 데이터베이스를 지정할 수 있습니다.

. . .
binlog_ignore_db          = db_to_ignore

변경한 후 파일을 저장하고 닫습니다. nano를 사용하여 파일을 편집한 경우 CTRL + X, Y를 누른 다음 ENTER를 눌러 편집하십시오. .

그런 다음 다음 명령을 실행하여 MySQL 서비스를 다시 시작합니다.

sudo systemctl restart mysql

이를 통해 이 MySQL 인스턴스는 다른 MySQL 서버가 복제할 소스 데이터베이스로 작동할 준비가 되었습니다. 그러나 복제본을 구성하기 전에 복제 토폴로지가 올바르게 작동하도록 소스에서 수행해야 하는 몇 가지 추가 단계가 있습니다. 첫 번째는 복제 프로세스와 관련된 모든 작업을 수행할 전용 MySQL 사용자를 생성하는 것입니다.

3단계 - 복제 사용자 생성

MySQL 복제 환경의 각 복제본은 사용자 이름과 비밀번호를 사용하여 소스 데이터베이스에 연결됩니다. 복제본은 원본 데이터베이스에 존재하고 적절한 권한이 있는 모든 MySQL 사용자 프로필을 사용하여 연결할 수 있지만 이 자습서에서는 이 목적을 위한 전용 사용자를 생성하는 방법을 간략하게 설명합니다.

MySQL 셸을 열어 시작합니다.

sudo mysql

참고: 암호를 사용하여 인증하는 전용 MySQL 사용자를 구성한 경우 대신 다음과 같은 명령을 사용하여 MySQL에 연결할 수 있습니다.

mysql -u sammy -p

sammy를 전용 사용자 이름으로 바꾸고 메시지가 표시되면 이 사용자의 암호를 입력합니다.

복제본 서버에서 수행해야 하는 몇 가지 작업을 포함하여 이 가이드 전체의 일부 작업에는 고급 권한이 필요합니다. 이 때문에 이전 sudo mysql 명령으로 접속할 수 있는 것처럼 관리 사용자로 접속하는 것이 더 편리할 수 있습니다. 하지만 이 가이드 전체에서 권한이 낮은 MySQL 사용자를 사용하려면 최소한 CREATE USER, RELOAD, REPLICATION CLIENT 권한을 부여받아야 합니다. , REPLICATION SLAVE 및 REPLICATION_SLAVE_ADMIN 권한.

프롬프트에서 새 MySQL 사용자를 만듭니다. 다음 예제에서는 replica_user라는 사용자를 생성하지만 원하는 이름을 지정할 수 있습니다. replica_server_ip를 레플리카 서버의 공용 IP 주소로 변경하고 password를 사용자의 강력한 비밀번호로 변경하십시오. 고르는:

CREATE USER 'replica_user'@'replica_server_ip' IDENTIFIED WITH mysql_native_password BY 'password';

이 명령은 replica_user가 mysql_native_password 인증 플러그인을 사용하도록 지정합니다. 대신 MySQL의 기본 인증 메커니즘인 caching_sha2_password를 사용할 수 있지만 이렇게 하려면 소스와 복제본 사이에 암호화된 연결을 설정해야 합니다. 이러한 종류의 설정은 프로덕션 환경에 최적이지만 암호화된 연결 구성은 이 자습서의 범위를 벗어납니다. MySQL 설명서에는 설정하려는 경우 암호화된 연결을 사용하는 복제 환경을 구성하는 방법에 대한 지침이 포함되어 있습니다.

새 사용자를 생성한 후 적절한 권한을 부여합니다. 최소한 MySQL 복제 사용자에게는 REPLICATION SLAVE 권한이 있어야 합니다.

GRANT REPLICATION SLAVE ON *.* TO 'replica_user'@'replica_server_ip';

그런 다음 FLUSH PRIVILEGES 명령을 실행하는 것이 좋습니다. 이렇게 하면 앞의 CREATE USER 및 GRANT 문의 결과로 서버가 캐시한 모든 메모리가 해제됩니다.

FLUSH PRIVILEGES;

이것으로 소스 MySQL 인스턴스에서 복제 사용자 설정을 완료했습니다. 그러나 MySQL 셸을 종료하지 마십시오. 소스 데이터베이스의 이진 로그 파일에 대한 몇 가지 중요한 정보를 얻기 위해 다음 단계에서 사용할 것이므로 지금은 열어 두십시오.

4단계 - 소스에서 바이너리 로그 좌표 검색

MySQL의 복제 이해 섹션에서 MySQL은 소스의 바이너리 로그 파일에서 데이터베이스 이벤트를 한 줄씩 복사하고 복제본에서 각 이벤트를 구현하여 복제를 구현한다는 점을 상기하십시오. MySQL의 바이너리 로그 파일 위치 기반 복제를 사용하는 경우 원본 바이너리 로그 파일의 이름과 해당 파일 내의 특정 위치를 자세히 설명하는 일련의 좌표를 복제본에 제공해야 합니다. 그런 다음 복제본은 이 좌표를 사용하여 데이터베이스 이벤트 복사를 시작해야 하는 로그 파일의 지점을 결정하고 이미 처리한 이벤트를 추적합니다.

이 단계에서는 로그 파일의 최신 지점에서 데이터 복제를 시작하도록 복제본을 설정하기 위해 소스 인스턴스의 현재 바이너리 로그 좌표를 얻는 방법을 설명합니다. 문제가 발생할 수 있는 좌표를 검색하는 동안 사용자가 데이터를 변경하지 않도록 하려면 좌표를 얻을 때 클라이언트가 데이터를 읽거나 쓰지 못하도록 데이터베이스를 잠가야 합니다. 곧 모든 것이 잠금 해제되지만 이 절차를 수행하면 데이터베이스가 어느 정도 다운타임을 겪게 됩니다.

이전 단계의 끝에서 소스 서버의 MySQL 셸을 열어 두어야 합니다. 프롬프트에서 소스 인스턴스의 모든 데이터베이스에서 열려 있는 테이블을 모두 닫고 잠그는 다음 명령을 실행합니다.

FLUSH TABLES WITH READ LOCK;

그런 다음 소스의 바이너리 로그 파일에 대한 현재 상태 정보를 반환하는 다음 작업을 실행합니다.

SHOW MASTER STATUS;

출력에 이 예와 유사한 테이블이 표시됩니다.

Output+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000001 |      899 | db           |                  |                   |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

이것은 복제본이 데이터베이스 이벤트 복사를 시작할 위치입니다. 나중에 복제를 시작할 때 필요하므로 File 이름과 Position 값을 기록합니다.

이 정보를 얻은 직후 수행할 작업은 원본 데이터베이스에 복제본으로 마이그레이션하려는 기존 데이터가 있는지 여부에 따라 다릅니다. 다음 두 하위 섹션 중 상황에 가장 적합한 항목으로 이동하십시오.

소스에 마이그레이션할 기존 데이터가 없는 경우

원본 MySQL 인스턴스가 새로 설치되었거나 복제본으로 마이그레이션하려는 기존 데이터가 없는 경우 이 시점에서 테이블 잠금을 해제할 수 있습니다.

UNLOCK TABLES;

아직 수행하지 않은 경우 MySQL 셸이 열려 있는 동안 복제하도록 선택한 데이터베이스를 생성할 수 있습니다. 2단계에 제공된 예에 따라 다음 작업은 db라는 데이터베이스를 생성합니다.

CREATE DATABASE db;

OutputQuery OK, 1 row affected (0.01 sec)

그런 다음 MySQL 셸을 닫습니다.

exit

그 후에 다음 단계로 넘어갈 수 있습니다.

소스에 마이그레이션할 기존 데이터가 있는 경우

원본 MySQL 인스턴스에 복제본으로 마이그레이션하려는 데이터가 있는 경우 mysqldump 유틸리티를 사용하여 데이터베이스의 스냅샷을 생성하면 됩니다. 그러나 데이터베이스는 현재 잠겨 있어야 합니다. 동일한 창에서 새로운 변경 사항을 적용하면 데이터베이스가 자동으로 잠금 해제됩니다. 마찬가지로 클라이언트를 종료하면 테이블이 자동으로 잠금 해제됩니다.

테이블을 잠금 해제하면 클라이언트가 데이터베이스의 데이터를 다시 변경할 수 있기 때문에 문제가 발생할 수 있습니다. 이로 인해 데이터 스냅샷과 방금 검색한 바이너리 로그 좌표가 일치하지 않을 수 있습니다.

이러한 이유로 MySQL을 잠금 해제하지 않고 데이터베이스 스냅샷을 생성할 수 있도록 로컬 컴퓨터에서 새 터미널 창이나 탭을 열어야 합니다.

새 터미널 창 또는 탭에서 원본 MySQL 인스턴스를 호스팅하는 서버에 대한 또 다른 SSH 세션을 엽니다.

ssh sammy@source_server_ip

그런 다음 새 탭이나 창에서 mysqldump를 사용하여 데이터베이스를 내보냅니다. 다음 예에서는 db라는 데이터베이스에서 db.sql이라는 덤프 파일을 생성하지만 대신 자신의 데이터베이스 이름을 포함해야 합니다. 또한 MySQL 셸이 아닌 bash 셸에서 이 명령을 실행해야 합니다.

sudo mysqldump -u root db > db.sql

그런 다음 이 터미널 창이나 탭을 닫고 MySQL 셸이 열려 있는 첫 번째 창으로 돌아갈 수 있습니다. MySQL 프롬프트에서 데이터베이스를 잠금 해제하여 다시 쓰기 가능하게 만듭니다.

UNLOCK TABLES;

그런 다음 MySQL 셸을 종료할 수 있습니다.

exit

이제 스냅샷 파일을 복제 서버로 보낼 수 있습니다. 소스 서버에서 SSH 키를 구성하고 복제본의 authorized_keys 파일에 소스의 공개 키를 추가했다고 가정하면 다음과 같이 scp 명령을 사용하여 안전하게 수행할 수 있습니다.

scp db.sql sammy@replica_server_ip:/tmp/

sammy를 복제본 서버에서 만든 관리 Ubuntu 사용자 프로필의 이름으로 바꾸고 replica_server_ip 를 바꾸십시오. 를 복제 서버의 IP 주소로 바꿉니다. 또한 이 명령은 복제본 서버의 /tmp/ 디렉토리에 스냅샷을 배치합니다.

스냅샷을 레플리카 서버로 보낸 후 SSH를 통해 다음과 같이 합니다.

ssh sammy@replica_server_ip

그런 다음 MySQL 셸을 엽니다.

sudo mysql

프롬프트에서 원본에서 복제할 새 데이터베이스를 만듭니다.

CREATE DATABASE db;

테이블을 만들거나 샘플 데이터로 이 데이터베이스를 로드할 필요가 없습니다. 방금 생성한 스냅샷을 사용하여 데이터베이스를 가져올 때 모두 처리됩니다. 대신 MySQL 셸을 종료합니다.

exit

그런 다음 데이터베이스 스냅샷을 가져옵니다.

sudo mysql db < /tmp/db.sql

이제 복제본에 소스 데이터베이스의 모든 기존 데이터가 있습니다. 이 가이드의 마지막 단계를 완료하여 원본 데이터베이스에서 변경된 새 변경 사항을 복제하기 시작하도록 복제 서버를 구성할 수 있습니다.

5단계 - 복제 데이터베이스 구성

남은 일은 소스를 변경한 것과 유사하게 복제본의 구성을 변경하는 것입니다. 이번에는 복제본 서버에서 MySQL 구성 파일인 mysqld.cnf를 엽니다.

sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

앞에서 언급했듯이 복제 설정의 각 MySQL 인스턴스에는 고유한 server-id 값이 있어야 합니다. 복제본의 server-id 지시문을 찾아 주석을 제거하고 소스와 다른 한 양의 정수로 값을 변경합니다.

server-id               = 2

그런 다음 log_bin 및 binlog_do_db 값을 업데이트하여 소스 시스템의 구성 파일에서 설정한 값과 일치하도록 합니다.

. . .
log_bin                 = /var/log/mysql/mysql-bin.log
. . .
binlog_do_db            = db
. . .

마지막으로 복제본의 릴레이 로그 파일 위치를 정의하는 relay-log 지시문을 추가합니다. 구성 파일 끝에 다음 줄을 포함합니다.

. . .
relay-log               = /var/log/mysql/mysql-relay-bin.log

변경한 후 파일을 저장하고 닫습니다. 그런 다음 복제본에서 MySQL을 다시 시작하여 새 구성을 구현합니다.

sudo systemctl restart mysql

mysql 서비스를 다시 시작하면 마침내 소스 데이터베이스에서 데이터 복제를 시작할 준비가 된 것입니다.

6단계 - 복제 시작 및 테스트

이제 두 MySQL 인스턴스 모두 복제를 허용하도록 완전히 구성되었습니다. 소스에서 데이터 복제를 시작하려면 복제 서버에서 MySQL 셸을 엽니다.

sudo mysql

프롬프트에서 동시에 여러 MySQL 복제 설정을 구성하는 다음 작업을 실행합니다. 이 명령을 실행한 후 이 인스턴스에서 복제를 활성화하면 SOURCE_USER 및 SOURCE_PASSWORD< 다음의 사용자 이름과 비밀번호를 사용하여 SOURCE_HOST 다음의 IP 주소에 연결을 시도합니다. /코드>, 각각. 또한 SOURCE_LOG_FILE 뒤에 이름이 있는 바이너리 로그 파일을 찾고 SOURCE_LOG_POS 뒤의 위치부터 읽기 시작합니다.

source_server_ip를 원본 서버의 IP 주소로 바꿔야 합니다. 마찬가지로 replica_user 및 password는 2단계에서 생성한 복제 사용자와 일치해야 합니다. 및 mysql-bin.000001 및 899는 3단계에서 얻은 바이너리 로그 좌표를 반영해야 합니다.

모든 관련 정보를 보다 쉽게 대체할 수 있도록 복제본 서버에서 실행하기 전에 텍스트 편집기에 이 명령을 입력할 수 있습니다.

CHANGE REPLICATION SOURCE TO
SOURCE_HOST='source_server_ip',
SOURCE_USER='replica_user',
SOURCE_PASSWORD='password',
SOURCE_LOG_FILE='mysql-bin.000001',
SOURCE_LOG_POS=899;

그런 다음 복제본 서버를 활성화합니다.

START REPLICA;

모든 세부 정보를 올바르게 입력한 경우 이 인스턴스는 소스의 db 데이터베이스에 대한 모든 변경 사항을 복제하기 시작합니다.

다음 작업을 실행하여 복제본의 현재 상태에 대한 세부 정보를 볼 수 있습니다. 이 명령의 \\G 한정자는 텍스트를 더 읽기 쉽게 재정렬합니다.

SHOW REPLICA STATUS\G;

이 명령은 문제 해결에 도움이 될 수 있는 많은 정보를 반환합니다.

Output*************************** 1. row ***************************
             Replica_IO_State: Waiting for master to send event
                  Source_Host: 138.197.3.190
                  Source_User: replica_user
                  Source_Port: 3306
                Connect_Retry: 60
              Source_Log_File: mysql-bin.000001
          Read_Source_Log_Pos: 1273
               Relay_Log_File: mysql-relay-bin.000003
                Relay_Log_Pos: 729
        Relay_Source_Log_File: mysql-bin.000001
. . .

참고: 복제본에 연결 문제가 있거나 복제가 예기치 않게 중지된 경우 소스의 바이너리 로그 파일에 있는 이벤트로 인해 복제가 차단되었을 수 있습니다. 이러한 경우 SET GLOBAL SQL_SLAVE_SKIP_COUNTER 명령을 실행하여 이전 명령에서 정의한 바이너리 로그 파일 위치 다음에 오는 특정 수의 이벤트를 건너뛸 수 있습니다. 이 예에서는 첫 번째 이벤트만 건너뜁니다.

SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;

그런 다음 복제본을 다시 시작해야 합니다.

START REPLICA;

또한 복제를 중지해야 하는 경우 복제본 인스턴스에서 다음 작업을 실행하여 중지할 수 있습니다.

STOP REPLICA;

이제 복제본이 소스에서 데이터를 복제하고 있습니다. 원본 데이터베이스에 대한 모든 변경 사항은 복제본 MySQL 인스턴스에 반영됩니다. 소스 데이터베이스에 샘플 테이블을 생성하고 성공적으로 복제되는지 확인하여 이를 테스트할 수 있습니다.

원본 시스템에서 MySQL 셸을 열어 시작합니다.

sudo mysql

복제하기로 선택한 데이터베이스를 선택합니다.

USE db;

그런 다음 해당 데이터베이스 내에 테이블을 만듭니다. 다음 SQL 작업은 example_column이라는 열 하나가 있는 example_table이라는 테이블을 생성합니다.

CREATE TABLE example_table (
example_column varchar(30)
);

OutputQuery OK, 0 rows affected (0.03 sec)

원하는 경우 이 테이블에 몇 가지 샘플 데이터를 추가할 수도 있습니다.

INSERT INTO example_table VALUES
('This is the first row'),
('This is the second row'),
('This is the third row');

OutputQuery OK, 3 rows affected (0.03 sec)
Records: 3  Duplicates: 0  Warnings: 0

테이블을 만들고 선택적으로 일부 샘플 데이터를 추가한 후 복제 서버의 MySQL 셸로 돌아가서 복제된 데이터베이스를 선택합니다.

USE db;

그런 다음 SHOW TABLES 문을 실행하여 선택한 데이터베이스 내의 모든 테이블을 나열합니다.

SHOW TABLES;

복제가 올바르게 작동하는 경우 이 명령의 출력에 나열된 소스에 방금 추가한 테이블이 표시됩니다.

Output+---------------+
| Tables_in_db  |
+---------------+
| example_table |
+---------------+
1 row in set (0.00 sec)

또한 소스의 테이블에 일부 샘플 데이터를 추가한 경우 다음과 같은 쿼리로 해당 데이터도 복제되었는지 확인할 수 있습니다.

SELECT * FROM example_table;

SQL에서 별표(*)는 "모든 열\을 줄여서 나타냅니다. 따라서 이 쿼리는 기본적으로 MySQL에 example_table의 모든 열을 반환하도록 지시합니다. 복제가 예상대로 작동하는 경우 이 작업은 해당 데이터를 출력으로 반환합니다.

Output+------------------------+
| example_column         |
+------------------------+
| This is the first row  |
| This is the second row |
| This is the third row  |
+------------------------+
3 rows in set (0.00 sec)

이러한 작업 중 하나가 원본에 추가한 예제 테이블 또는 데이터를 반환하지 못하는 경우 복제 구성에 오류가 있는 것일 수 있습니다. 이러한 경우 SHOW REPLICA STATUS\\G 작업을 실행하여 문제의 원인을 찾을 수 있습니다. 또한 복제 문제를 해결하는 방법에 대한 제안 사항은 복제 문제 해결에 대한 MySQL 설명서를 참조할 수 있습니다.

`결론`

이 자습서를 완료하면 하나의 소스와 하나의 복제본으로 MySQL의 바이너리 로그 파일 위치 기반 복제 방법을 사용하는 MySQL 복제 환경을 설정하게 됩니다. 하지만 이 가이드에 설명된 절차는 MySQL에서 복제를 구성하는 한 가지 방법일 뿐이라는 점을 명심하십시오. MySQL은 필요에 따라 최적화된 복제 환경을 만드는 데 사용할 수 있는 다양한 복제 옵션을 제공합니다. MySQL의 내장 복제 기능을 확장하는 데 사용할 수 있는 Galera Cluster와 같은 여러 타사 도구도 있습니다.

MySQL의 특정 복제 기능에 대해 추가 질문이 있는 경우 MySQL 관련 콘텐츠의 전체 라이브러리를 확인하는 것이 좋습니다.