Ubuntu 20.04에 MySQL 그룹 복제 구성하는 방법

소개

MySQL 복제는 하나의 데이터베이스에서 다른 데이터베이스로 데이터와 작업을 안정적으로 반영합니다. 전통적인 복제는 주 서버가 데이터베이스 쓰기 작업을 수락하도록 구성되어 있으며, 보조 서버는 주 서버의 로그에서 작업을 복사하고 적용하는 것으로 이루어집니다. 이러한 보조 서버는 읽기에 사용될 수 있지만 데이터 쓰기를 실행할 수는 없습니다.

그룹 복제는 더 유연하고 내고장성이 있는 복제 메커니즘을 구현하는 방법입니다. 이 과정은 데이터가 올바르게 복사되도록 하는 일부 서버 풀을 설정하는 것을 포함합니다. 주 서버에 문제가 발생하면 멤버 선출이 그룹에서 새로운 주 서버를 선택할 수 있습니다. 이렇게 하면 문제가 발생해도 나머지 노드가 계속 작동할 수 있습니다. 멤버십 협상, 오류 검출 및 메시지 전달은 Paxos 합의 알고리즘을 구현하여 제공됩니다.

이 튜토리얼에서는 Ubuntu 20.04 서버 세트를 사용하여 MySQL 그룹 복제를 설정합니다. MySQL에서 그룹 복제를 배포하려면 최소한 세 개의 MySQL 인스턴스가 필요하며, 최대 구성은 아홉 개입니다. 이 튜토리얼을 진행하면서 그룹을 단일 주 서버 또는 다중 주 서버 복제 그룹으로 설정할 수 있는 옵션이 제공됩니다.

필수 조건

이 안내서를 완료하려면 다음이 필요합니다:

• Ubuntu 20.04에서 실행되는 세 개의 서버입니다. 각각은 sudo 권한이 있는 비 루트 관리 사용자와 UFW로 구성된 방화벽이 있어야 합니다. 각 서버를 설정하기 위해 Ubuntu 20.04의 초기 서버 설정 가이드를 따르십시오.
• 각 서버에 MySQL이 설치되어 있습니다. 이 안내서는 쓰고 있는 최신 버전의 MySQL을 가정하며, 이는 현재 버전 8.0.28입니다. 모든 서버에 이를 설치하려면 각 기계에 대해 Ubuntu 20.04에 MySQL 설치하는 방법 가이드를 따르십시오.

일관된 이해를 돕기 위해, 이 안내서에서는 세 개의 서버를 각각 member1, member2, member3로 지칭할 것입니다. 이 안내서의 예에서, 이러한 멤버들은 다음과 같은 IP 주소를 갖게 될 것입니다:

member1에서 실행해야 하는 모든 명령은 다음과 같이 파란 배경으로 표시됩니다:

member2에서 실행해야 하는 모든 명령은 다음과 같이 빨간 배경으로 표시됩니다:

member3에서 실행해야 하는 모든 명령은 다음과 같이 녹색 배경으로 표시됩니다:

마지막으로, 세 개의 서버 각각에서 실행해야 하는 모든 명령은 표준 배경으로 표시됩니다:

단계 1 — MySQL 그룹 식별을 위한 UUID 생성

MySQL 구성 파일을 열어 그룹 복제 설정을 구성하기 전에, 만들 계획인 MySQL 그룹을 식별하는 데 사용할 UUID를 생성해야 합니다.

member1에서 그룹을 위한 유효한 UUID를 생성하려면 uuidgen 명령을 사용하십시오:

uuidgen

Output
168dcb64-7cce-473a-b338-6501f305e561

받은 값을 복사하세요. 이 값은 곧 서버 풀의 그룹 이름을 구성할 때 참조해야 합니다.

단계 2 — MySQL 구성 파일에서 그룹 복제 설정

이제 MySQL의 구성 파일을 수정할 준비가 되었습니다. 선호하는 텍스트 편집기를 사용하여 각 MySQL 서버의 주 구성 파일을 엽니다. 여기서는 nano를 사용하겠습니다:

sudo nano /etc/mysql/my.cnf

Ubuntu에서 MySQL은 여러 가지 다른 파일이 설치되어 있으며 여러 가지 구성 변경을 정의하는 데 사용할 수 있습니다. 기본적으로 my.cnf 파일은 하위 디렉터리에서 추가 파일을 소스로 사용합니다. !includedir 줄 아래에 자체 구성을 추가해야 합니다. 이를 통해 포함된 파일의 설정을 재정의할 수 있습니다.

시작하려면 새로운 섹션을 시작하고 [mysqld] 헤더를 포함한 다음 다음 예제에서 강조된 대로 그룹 복제를 활성화하는 데 필요한 설정을 추가하세요. 이러한 설정은 공식 MySQL 문서에 기술된 그룹 복제에 필요한 최소 설정에서 수정되었음을 유의하십시오. loose- 접두사는 MySQL이 인식하지 못하는 옵션을 우아하고 오류 없이 처리할 수 있도록 합니다. 이러한 설정 중 일부를 곧 채워넣고 사용자 정의해야 합니다:

. . .
!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mysql.conf.d/

[mysqld]

# General replication settings
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
gtid_mode = ON
enforce_gtid_consistency = ON
master_info_repository = TABLE
relay_log_info_repository = TABLE
binlog_checksum = NONE
log_slave_updates = ON
log_bin = binlog
binlog_format = ROW
transaction_write_set_extraction = XXHASH64
loose-group_replication_bootstrap_group = OFF
loose-group_replication_start_on_boot = OFF
loose-group_replication_ssl_mode = REQUIRED
loose-group_replication_recovery_use_ssl = 1

# Shared replication group configuration
loose-group_replication_group_name = ""
loose-group_replication_ip_whitelist = ""
loose-group_replication_group_seeds = ""

# Single or Multi-primary mode? Uncomment these two lines
# for multi-primary mode, where any host can accept writes
#loose-group_replication_single_primary_mode = OFF
#loose-group_replication_enforce_update_everywhere_checks = ON

# Host specific replication configuration
server_id = 
bind-address = ""
report_host = ""
loose-group_replication_local_address = ""

이러한 구성 옵션을 더 명확하게 설명하기 위해 다음과 같이 하위 섹션으로 나누었습니다. 이 섹션 중 일부는 복제 그룹을 배포하는 방법에 대한 선택 사항을 제공하거나 사용자 고유의 구성에 특정 세부 정보를 입력해야 하므로 주의 깊게 읽어주십시오.

기본 그룹 복제 설정

첫 번째 섹션에는 수정이 필요하지 않은 그룹 복제에 필요한 일반 설정이 포함되어 있습니다:

. . .
# 일반 복제 설정
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
gtid_mode = ON
enforce_gtid_consistency = ON
master_info_repository = TABLE
relay_log_info_repository = TABLE
binlog_checksum = NONE
log_slave_updates = ON
log_bin = binlog
binlog_format = ROW
transaction_write_set_extraction = XXHASH64
loose-group_replication_bootstrap_group = OFF
loose-group_replication_start_on_boot = OFF
loose-group_replication_ssl_mode = REQUIRED
loose-group_replication_recovery_use_ssl = 1
. . .

MySQL에서 그룹 복제를 위한 특정 요구 사항 중 하나는 데이터가 InnoDB 저장 엔진에 저장되어야 한다는 것입니다. MySQL 문서에서는 이 섹션의 첫 번째 주석 처리되지 않은 줄과 같이 오류를 유발할 수 있는 다른 저장 엔진의 사용을 명시적으로 비활성화하는 것을 권장합니다.

나머지 설정은 전역 트랜잭션 ID를 활성화하고, 그룹 복제에 필요한 이진 로깅을 구성하며, 그룹에 대한 SSL을 구성합니다. 이 구성은 복구 및 부트스트래핑을 돕는 몇 가지 항목을 설정합니다. 이 섹션에서는 아무 것도 수정할 필요가 없으며, 서버의 모든 세 개에서 동일해야 하므로 추가한 후에는 이동할 수 있습니다.

공유된 그룹 복제 설정

두 번째 섹션은 그룹의 공유 설정을 설정합니다. 이 설정을 한 번 사용자 정의한 다음 각 노드에서 동일한 설정을 사용해야 합니다. 구체적으로 이전 단계에서 생성한 그룹의 UUID, 허가된 그룹 구성원 목록 및 그룹에 가입할 때 초기 데이터를 얻기 위해 연락할 시드 구성원을 추가해야 합니다.

loose-group_replication_group_name을 이전에 uuidgen 명령어로 생성한 UUID 값으로 설정하십시오. UUID를 빈 이중 인용부호 사이에 넣는지 확인하십시오.

다음으로, loose-group_replication_ip_whitelist를 모든 MySQL 서버 IP 주소 목록으로 설정하십시오. 각 주소는 쉼표로 구분되어야 합니다. loose-group_replication_group_seeds 설정은 화이트리스트와 거의 동일하지만 각 멤버 뒤에 지정된 그룹 복제 포트를 추가해야 합니다. 이 가이드의 목적을 위해 권장하는 그룹 복제 포트인 33061을 사용하십시오:

. . .
# 공유 복제 그룹 구성
loose-group_replication_group_name = "168dcb64-7cce-473a-b338-6501f305e561"
loose-group_replication_ip_whitelist = "203.0.113.1,203.0.113.2,203.0.113.3"
loose-group_replication_group_seeds = ""203.0.113.1:33061,203.0.113.2:33061,203.0.113.3:33061"
. . .

이 섹션은 각각의 MySQL 서버에서 동일해야 하므로 각각을 주의 깊게 복사하십시오.

단일 기본 또는 다중 기본 선택

다음으로, 단일 기본 또는 다중 기본 그룹을 구성할지 결정해야 합니다. 단일 기본 구성에서는 MySQL이 쓰기 작업을 처리할 단일 기본 서버(거의 항상 첫 번째 그룹 멤버)를 지정합니다. 다중 기본 그룹에서는 그룹 멤버 중 아무나 쓰기 작업을 수행할 수 있습니다.

원하는 경우 다중 기본 그룹을 구성하려면 loose-group_replication_single_primary_mode 및 loose-group_replication_enforce_update_everywhere_checks 지시문의 주석 처리를 해제하십시오. 이렇게 하면 다중 기본 그룹이 설정됩니다. 단일 기본 그룹의 경우 이 두 줄의 주석 처리를 그대로 두세요:

. . .
# 단일 또는 다중 기본 모드? 다음 두 줄의 주석 처리를 해제하면
# 모든 호스트가 쓰기를 수락하는 다중 기본 모드가 설정됩니다
#loose-group_replication_single_primary_mode = OFF
#loose-group_replication_enforce_update_everywhere_checks = ON
. . .

이 설정은 MySQL 서버 각각에서 동일해야 합니다.

이 설정은 나중에 변경할 수 있지만 변경한 후에는 각 MySQL 그룹 멤버를 다시 시작해야 합니다. 새 구성으로 전환하려면 그룹의 각 MySQL 인스턴스를 중지하고 새 설정으로 각 멤버를 시작한 다음 그룹 복제를 다시 부트스트랩해야 합니다. 이로 인해 데이터에는 영향이 없지만 짧은 다운타임이 필요합니다.

호스트별 구성 설정

네 번째 섹션에는 각 서버마다 다른 설정이 포함됩니다:

• 서버 ID
• 바인딩할 주소
• 다른 멤버에게 보고할 주소
• 로컬 복제 주소 및 수신 포트

server_id 지시문은 고유한 숫자로 설정되어야합니다. 첫 번째 멤버의 경우 이를 1로 설정하고 추가 호스트마다 숫자를 증가시킵니다. bind-address와 report_host를 해당 서버의 IP 주소로 설정하여 MySQL 인스턴스가 외부 연결을 수신하고 다른 호스트에게 주소를 올바르게 보고합니다. loose-group_replication_local_address도 현재 서버의 IP 주소로 설정되어야하며 그룹 복제 포트 (33061)가 IP 주소에 추가되어야합니다. 구성의 이 부분에 대한 예는 다음과 같습니다.

예를 들어, 여기 멤버1의 구성 일부를 사용하는 방법입니다. 샘플 IP 주소를 사용합니다.

. . .
# 호스트별 복제 구성
server_id = 1
bind-address = "203.0.113.1"
report_host = "203.0.113.1"
loose-group_replication_local_address = "203.0.113.1:33061"

MySQL 서버마다이 프로세스를 완료하십시오. 여기 멤버2의 구성입니다:

. . .
# 호스트별 복제 구성
server_id = 2
bind-address = "203.0.113.2"
report_host = "203.0.113.2"
loose-group_replication_local_address = "203.0.113.2:33061"

그리고 여기 멤버3의 구성입니다:

. . .
# 호스트별 복제 구성
server_id = 3
bind-address = "203.0.113.3"
report_host = "203.0.113.3"
loose-group_replication_local_address = "203.0.113.3:33061"

편집 중인 구성의 서버의 IP 주소를 각 하이라이트된 IP 주소로 업데이트하는지 확인하십시오.

작업을 마치면 각 호스트에서 공유된 복제 설정이 동일한지 확인하고 호스트별 설정이 각각의 호스트에 맞게 사용자 정의되었는지 확인하십시오. 완료되면 각 호스트에서 파일을 저장하고 닫습니다. 파일을 편집하기 위해 nano를 사용한 경우 CTRL + X, Y를 누른 다음 ENTER를 눌러 작업을 수행할 수 있습니다.

각 서버의 MySQL 구성 파일에는 이제 MySQL 그룹 복제를 부트스트랩하는 데 필요한 지시문이 포함되어 있습니다. MySQL 인스턴스에 새로운 설정을 적용하려면 다음 명령을 사용하여 각 서버의 서비스를 다시 시작하십시오:

sudo systemctl restart mysql

이제 새로운 설정을 적용했으므로 각 서버의 방화벽 규칙을 업데이트하여 원격 액세스를 활성화 할 수 있습니다.

단계 3 — 각 서버의 UFW 규칙 업데이트

전제 조건을 따른다고 가정하면 초기 서버 설정 가이드에 따라 설치한 각 서버에 방화벽을 설정하고 OpenSSH UFW 프로필에 대한 액세스를 활성화했을 것입니다. 현재 이 방화벽은 각 서버의 authorized_keys 파일과 일치하는 키를 제시하는 ssh 연결을 제외하고 서버의 모든 포트로의 연결을 차단하는 중요한 보안 조치입니다.

MySQL 구성 파일에서 서비스를 기본 포트 3306에서 외부 연결을 수신하도록 구성했습니다. 또한 복제 조정을위한 포트로 33061을 정의했습니다.

각 회원 서버에는 그룹 내의 다른 회원들이 서로 통신할 수 있도록 이러한 두 포트에 대한 액세스를 열어야합니다. member1에서 member2로 이러한 포트에 대한 액세스를 열려면 다음 ufw 명령을 member1에서 실행하십시오:

sudo ufw allow from member2_server_ip to any port 3306
sudo ufw allow from member2_server_ip to any port 33061

member2_server_ip를 실제 member2 서버의 IP 주소로 변경하십시오. 그런 다음, member3에 대한 동일한 포트를 열려면 다음 명령을 실행하십시오:

sudo ufw allow from member3_server_ip to any port 3306
sudo ufw allow from member3_server_ip to any port 33061

다음으로, 다른 두 서버에 대한 방화벽 규칙을 업데이트하십시오. 각각 member2에서 다음 명령을 실행하고, 각각 member1 및 member3의 IP 주소를 변경하십시오:

sudo ufw allow from member1_server_ip to any port 3306
sudo ufw allow from member1_server_ip to any port 33061
sudo ufw allow from member3_server_ip to any port 3306
sudo ufw allow from member3_server_ip to any port 33061

마지막으로, member3에서 다음 두 명령을 실행하십시오. 다시 한 번 각 서버의 올바른 IP 주소를 입력하십시오:

sudo ufw allow from member1_server_ip to any port 3306
sudo ufw allow from member1_server_ip to any port 33061
sudo ufw allow from member2_server_ip to any port 3306
sudo ufw allow from member2_server_ip to any port 33061

이러한 UFW 규칙을 추가한 후에는 각각의 세 MySQL 인스턴스가 다른 두 서버의 MySQL에 사용되는 포트에 대한 액세스를 허용합니다.

MySQL 포트에 액세스 할 수 있게 되면 복제 사용자를 만들고 그룹 복제 플러그인을 활성화 할 수 있습니다.

단계 4 — 복제 사용자 구성 및 그룹 복제 플러그인 활성화

복제 그룹에서 다른 서버와 연결을 설정하려면 각 MySQL 인스턴스에 전용 복제 사용자가 있어야합니다.

각 MySQL 서버에 대해 관리자 사용자로 MySQL 인스턴스에 로그인하여 대화형 세션을 시작하십시오:

sudo mysql

각 서버마다 고유한 복제 사용자가 있기 때문에 생성 프로세스 중에 이진 로그를 끄어야합니다. 그렇지 않으면 복제가 시작되면 그룹이 주 서버에서 다른 서버로 복제 사용자를 전파하려고 시도하여 이미 존재하는 복제 사용자와 충돌을 일으킬 수 있습니다. 다음 명령을 MySQL 프롬프트에서 각 서버에서 실행하십시오:

SET SQL_LOG_BIN=0;

이제 복제 사용자를 만들기 위해 CREATE USER 문을 실행할 수 있습니다. 다음 명령을 실행하여 이름이 repl인 사용자를 만듭니다. 이 명령은 복제 사용자가 SSL을 사용하여 연결해야 함을 지정합니다. 또한이 복제 사용자를 만들 때 안전한 비밀번호를 password 자리 표시자 대신 사용하십시오:

CREATE USER 'repl'@'%' IDENTIFIED BY 'password' REQUIRE SSL;

다음으로, 새 사용자에게 서버에서 복제 권한을 부여하십시오:

GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';

그런 다음 변경 사항을 적용하려면 권한을 플러시하십시오:

FLUSH PRIVILEGES;

이후 정상 작업을 재개하려면 이진 로깅을 다시 활성화하십시오:

SET SQL_LOG_BIN=1;

다음으로, group_replication_recovery 채널을 새 복제 사용자 및 해당 암호를 사용하도록 설정하십시오. 각 서버는 이러한 자격 증명을 사용하여 그룹에 인증됩니다:

CHANGE REPLICATION SOURCE TO SOURCE_USER='repl', SOURCE_PASSWORD='password' FOR CHANNEL 'group_replication_recovery';

CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='password' FOR CHANNEL 'group_replication_recovery';

복제 사용자를 설정한 후에 group_replication 플러그인을 활성화할 수 있습니다. 그룹을 초기화하려면 다음 명령을 실행합니다.

INSTALL PLUGIN group_replication SONAME 'group_replication.so';

다음 명령을 실행하여 플러그인이 활성화되었는지 확인합니다.

SHOW PLUGINS;

플러그인은 가장 최근에 추가된 플러그인이므로 목록 아래에 나타납니다.

Output
+----------------------------+----------+--------------------+----------------------+---------+
| Name                       | Status   | Type               | Library              | License |
+----------------------------+----------+--------------------+----------------------+---------+
|                            |          |                    |                      |         |
| . . .                      | . . .    | . . .              | . . .                | . . .   |
|                            |          |                    |                      |         |
| group_replication          | ACTIVE   | GROUP REPLICATION  | group_replication.so | GPL     |
+----------------------------+----------+--------------------+----------------------+---------+
45 rows in set (0.00 sec)

이 출력은 플러그인이 로드되었고 현재 활성화되어 있는 것을 확인합니다. 다음 단계로 진행하기 전에, 이 섹션의 각 명령을 각 MySQL 인스턴스에서 실행했는지 확인하세요.

단계 5 — 그룹 복제 시작

이제 각 MySQL 서버에 복제 사용자가 구성되어 있고 그룹 복제 플러그인이 활성화되었으므로 그룹을 시작할 수 있습니다.

첫 번째 노드 부트스트래핑

그룹을 시작하려면 다음 단계를 그룹의 단일 구성원에서 완료하세요. 데모를 위해이 안내서는 멤버1에서 이러한 단계를 완료합니다.

그룹 멤버는 초기 가입 시 기존 멤버에게 복제 데이터, 최신 멤버 목록 및 기타 정보를 의존합니다. 이로 인해 초기 그룹 멤버를 시작할 때 이 정보를 다른 멤버에서 기대하지 않도록 약간 다른 절차를 사용해야 합니다.

설정된 경우 group_replication_bootstrap_group 변수는 멤버에게 동료로부터 정보를 받지 않아야 하며 대신 새 그룹을 설정하고 자신을 주요 멤버로 선출해야 함을 알려줍니다. 다음 명령을 사용하여이 변수를 켤 수 있습니다.

SET GLOBAL group_replication_bootstrap_group=ON;

그런 다음 초기 그룹 멤버에 대해 복제를 시작할 수 있습니다.

START GROUP_REPLICATION;

이후에는 group_replication_bootstrap_group 변수를 OFF로 설정할 수 있습니다. 이는 기존 그룹 멤버가 없는 경우에만 적절한 상황입니다.

SET GLOBAL group_replication_bootstrap_group=OFF;

그룹은이 서버가 유일한 멤버로 시작됩니다. performance_schema 데이터베이스의 replication_group_members 테이블 내 항목을 확인하여 이를 확인할 수 있습니다.

SELECT * FROM performance_schema.replication_group_members;

이 쿼리는 현재 호스트를 나타내는 단일 행을 반환합니다.

Output
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST   | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1  |        3306 | ONLINE       | PRIMARY     | 8.0.28         | XCom                       |
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
1 row in set (0.00 sec)

MEMBER_STATE의 ONLINE 값은 이 노드가 그룹 내에서 완전히 작동 중임을 나타냅니다.

다음으로 테스트 데이터베이스 및 샘플 데이터가 포함된 테이블을 생성합니다. 이 그룹에 더 많은 멤버가 추가되면 이 데이터가 자동으로 복제됩니다.

playground이라는 샘플 데이터베이스를 만들어 시작하십시오.

CREATE DATABASE playground;

다음 명령을 사용하여 playground 데이터베이스 내에 equipment이라는 예제 테이블을 생성합니다:

CREATE TABLE playground.equipment ( 
id INT NOT NULL AUTO_INCREMENT,
type VARCHAR(50),
quant INT,
color VARCHAR(25),
PRIMARY KEY(id)
);

이 테이블은 다음 네 개의 열을 포함합니다:

• id: 이 열은 자동으로 증가하는 정수 값을 포함하며, 테이블에 샘플 데이터를로드 할 때이 열에 대한 값을 지정할 필요가 없음을 의미합니다
• type: 이 열은 행이 나타내는 놀이터 장비의 유형을 설명하는 문자열 값을 포함합니다
• quant: 이 열은 주어진 유형의 놀이터 장비 수량을 나타내는 정수 값을 포함합니다
• color: 이 열은 주어진 장비의 색상을 지정하는 문자열 값을 보유합니다

또한, id 열이 이 테이블의 기본 키로 지정되었음을 유의하십시오. MySQL에서 그룹에 복제되는 모든 테이블은 테이블의 기본 키로 지정된 열을 가져야합니다.

마지막으로, 다음 명령을 실행하여 테이블에 데이터 한 행을 삽입합니다:

INSERT INTO playground.equipment (type, quant, color) VALUES ("slide", 2, "blue");

데이터가 올바르게 입력되었는지 확인하기 위해 테이블을 쿼리합니다:

SELECT * FROM playground.equipment;

Output
+----+-------+-------+-------+
| id | type  | quant | color |
+----+-------+-------+-------+
|  1 | slide |     2 | blue  |
+----+-------+-------+-------+
1 row in set (0.00 sec)

이 서버가 그룹의 구성원이고 쓰기 기능이 있음을 확인한 후, 다른 서버가 그룹에 참여할 수 있습니다.

나머지 노드 시작

다음으로, member2에서 그룹 복제를 시작하십시오. 이미 활성 멤버가 있으므로 그룹을 부트스트랩할 필요가 없으며이 멤버는 즉시 참여할 수 있습니다:

START GROUP_REPLICATION;

member3에서도 동일한 방식으로 그룹 복제를 시작하십시오:

START GROUP_REPLICATION;

세 서버 중 하나에서 멤버십 목록을 다시 확인하십시오. 이번에는 출력에 세 개의 서버가 나열됩니다:

SELECT * FROM performance_schema.replication_group_members;

Output
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST   | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1  |        3306 | ONLINE       | PRIMARY     | 8.0.28         | XCom                       |
| group_replication_applier | 1ae4b211-1b01-11e7-9d89-ceb93e1d5494 | 203.0.113.2  |        3306 | ONLINE       | SECONDARY   | 8.0.28         | XCom                       |
| group_replication_applier | 157b597a-1b01-11e7-9d83-566a6de6dfef | 203.0.113.3  |        3306 | ONLINE       | SECONDARY   | 8.0.28         | XCom                       |
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
3 rows in set (0.00 sec)

모든 멤버는 MEMBER_STATE 값이 ONLINE이어야 합니다. 새로운 그룹의 경우 노드 중 어느 것이 몇 초 이상 RECOVERING으로 나열되어 있는 경우 일반적으로 오류가 발생했거나 무언가가 잘못 구성되었음을 나타냅니다. 추가 정보를 얻으려면 /var/log/mysql/error.log에있는 로그를 확인하십시오:

다음으로, 새로운 멤버에 테스트 데이터베이스 정보가 복제되었는지 확인하십시오:

SELECT * FROM playground.equipment;

Output
+----+-------+-------+-------+
| id | type  | quant | color |
+----+-------+-------+-------+
|  1 | slide |     2 | blue  |
+----+-------+-------+-------+
1 row in set (0.01 sec)

새 멤버에서 데이터를 사용할 수 있다면 그룹 복제가 올바르게 작동하는 것입니다.

단계 6 — 새 그룹 멤버의 쓰기 기능 테스트

다음으로, 새 복제 그룹 멤버에서 데이터베이스에 쓰기를 시도할 수 있습니다. 이것이 성공하는지 여부는 단일 주요 또는 다중 주요 그룹을 구성하는지 여부에 따라 달라집니다.

단일 주 프라이머리 환경에서 쓰기 테스트

단일 주 그룹에서는 비 주 프라이머리 서버에서의 모든 쓰기 작업이 일관성 문제로 인해 거부될 것으로 예상됩니다. 복제 그룹의 모든 구성원에서 다음 쿼리를 실행하여 언제든지 현재 주 프라이머리를 찾을 수 있습니다:

SHOW STATUS LIKE '%primary%';

Output
+----------------------------------+--------------------------------------+
| Variable_name                    | Value                                |
+----------------------------------+--------------------------------------+
| group_replication_primary_member | 13324ab7-1b01-11e7-9dd1-22b78adaa992 |
+----------------------------------+--------------------------------------+
1 row in set (0.01 sec)

쿼리의 값은 그룹 멤버 목록을 쿼리하여 호스트에 일치시킬 수 있는 MEMBER_ID입니다. 이전과 같이 그룹 구성원 목록을 쿼리하여 호스트를 확인할 수 있습니다:

SELECT * FROM performance_schema.replication_group_members;

Output
+---------------------------+--------------------------------------+--------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST  | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1  |        3306 | ONLINE       |
| group_replication_applier | 1ae4b211-1b01-11e7-9d89-ceb93e1d5494 | 203.0.113.2  |        3306 | ONLINE       |
| group_replication_applier | 157b597a-1b01-11e7-9d83-566a6de6dfef | 203.0.113.3  |        3306 | ONLINE       |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
3 rows in set (0.01 sec)

이 예시 출력에서 나타나듯이 203.0.113.1의 호스트 — member1 — 현재 주 서버입니다. 다른 구성원에서 데이터베이스로 쓰기를 시도하면 작업이 실패합니다:

INSERT INTO playground.equipment (type, quant, color) VALUES ("swing", 10, "yellow");

Output
ERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement

이는 현재 단일 쓰기 가능한 주 프라이머리로 구성된 그룹이기 때문에 예상되는 동작입니다. 주 서버에 문제가 발생하고 그룹을 나가면, 그룹은 자동으로 새 구성원을 주로 선출하고 쓰기를 허용합니다.

다중 주 프라이머리 환경에서 쓰기 테스트

다중 주 지향으로 구성된 그룹의 경우, 모든 구성원이 데이터베이스에 쓰기를 커밋할 수 있어야 합니다.

그룹이 다중 주(primary) 모드에서 작동하는지 확인하려면 group_replication_primary_member 변수의 값을 다시 확인할 수 있습니다:

SHOW STATUS LIKE '%primary%';

Output
+----------------------------------+-------+
| Variable_name                    | Value |
+----------------------------------+-------+
| group_replication_primary_member |       |
+----------------------------------+-------+
1 row in set (0.02 sec)

변수가 비어 있으면 지정된 주(primary) 호스트가 없으며 어떤 멤버든 쓰기를 수락할 수 있음을 의미합니다.

멤버2에서 equipment 테이블에 데이터를 쓰는 시도를 통해 이를 테스트합니다:

INSERT INTO playground.equipment (type, quant, color) VALUES ("swing", 10, "yellow");

Output
Query OK, 1 row affected (0.00 sec)

멤버2에서 오류 없이 쓰기 작업을 완료했습니다.

멤버3에서 새 항목이 추가되었는지 확인하기 위해 다음 쿼리를 실행합니다:

SELECT * FROM playground.equipment;

Output
+----+-------+-------+--------+
| id | type  | quant | color  |
+----+-------+-------+--------+
|  1 | slide |     2 | blue   |
|  2 | swing |    10 | yellow |
+----+-------+-------+--------+
2 rows in set (0.00 sec)

이는 멤버2의 쓰기가 성공적으로 복제되었음을 확인합니다.

이제 멤버3에서 다음 INSERT 문을 실행하여 쓰기 기능을 테스트합니다:

INSERT INTO playground.equipment (type, quant, color) VALUES ("seesaw", 3, "green");

Output
Query OK, 1 row affected (0.02 sec)

멤버1에서는 두 새 멤버의 쓰기 작업이 다시 복제되었는지 확인합니다:

SELECT * FROM playground.equipment;

Output
+----+--------+-------+--------+
| id | type   | quant | color  |
+----+--------+-------+--------+
|  1 | slide  |     2 | blue   |
|  2 | swing  |    10 | yellow |
|  3 | seesaw |     3 | green  |
+----+--------+-------+--------+
3 rows in set (0.01 sec)

이는 복제가 각 방향으로 작동하고 각 멤버가 쓰기 작업을 수행할 수 있는지 확인합니다.

단계 7 — 그룹 다시 가동

그룹이 부트스트랩되면 개별 회원은 기본 서버를 선택하는 데 충분한 회원이 있다면 가입하고 나가더라도 가용성에 영향을 주지 않습니다. 그러나 특정 구성 변경(예: 단일 및 다중 기본 환경 간 전환)이 이루어지거나 그룹의 모든 회원이 나가면 초기에 수행한 것과 같은 방식으로 그룹을 다시 부트스트랩해야 할 수 있습니다.

회원1에서 group_replication_bootstrap_group 변수를 ON으로 설정합니다:

SET GLOBAL GROUP_REPLICATION_BOOTSTRAP_GROUP=ON;

그런 다음 그룹을 초기화합니다:

START GROUP_REPLICATION;

이후에 group_replication_bootstrap_group 변수를 다시 OFF로 설정할 수 있습니다:

SET GLOBAL GROUP_REPLICATION_BOOTSTRAP_GROUP=OFF;

첫 번째 회원이 그룹을 시작한 후 다른 회원도 가입할 수 있습니다:

START GROUP_REPLICATION;

추가 회원에 대해서도 이 과정을 따르십시오:

START GROUP_REPLICATION;

모든 회원이 가용한 상태로 그룹이 온라인 상태여야 합니다:

SELECT * FROM performance_schema.replication_group_members;

Output
+---------------------------+--------------------------------------+--------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST  | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1  |        3306 | ONLINE       |
| group_replication_applier | 1ae4b211-1b01-11e7-9d89-ceb93e1d5494 | 203.0.113.2  |        3306 | ONLINE       |
| group_replication_applier | 157b597a-1b01-11e7-9d83-566a6de6dfef | 203.0.113.3  |        3306 | ONLINE       |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
3 rows in set (0.01 sec)

필요할 때마다 그룹을 다시 시작하는 데 이 과정을 사용할 수 있습니다.

단계 8 — MySQL 시작 시 그룹에 자동으로 가입하기

현재 설정에서 회원 서버가 다시 부팅되면 시작 시 자동으로 그룹에 다시 가입되지 않습니다. 회원이 자동으로 그룹에 다시 가입되길 원한다면 구성 파일을 약간 수정할 수 있습니다.

이 단계에 개요된 설정은 부팅할 때 회원이 자동으로 가입되길 원할 때 도움이 됩니다. 그러나 몇 가지 주의할 사항이 있습니다. 첫째, 이 설정은 MySQL 인스턴스 자체가 시작될 때만 영향을 미칩니다. 회원이 시간 초과 문제로 인해 그룹에서 제거되지만 MySQL 인스턴스가 온라인 상태인 경우 회원이 자동으로 다시 가입하지 않습니다.

둘째, 그룹을 처음 부트스트래핑할 때이 설정을 활성화하는 것은 해로울 수 있습니다. 가입할 기존 그룹이 없는 경우, MySQL 프로세스가 시작되는 데 오랜 시간이 걸릴 것입니다. 왜냐하면 초기화하려면 기타 존재하지 않는 회원에 연락을 시도할 것이기 때문입니다. 장시간의 타임아웃 후에야 포기하고 정상적으로 시작할 것입니다. 이후에는 위에 개요된 절차를 사용하여 그룹을 부트스트랩해야 합니다.

위의 주의 사항을 염두에 두고 MySQL이 시작될 때 노드를 그룹에 자동으로 가입하도록 구성하려면 주 MySQL 구성 파일을 엽니다:

sudo nano /etc/mysql/my.cnf

내부에서 loose-group_replication_start_on_boot 변수를 찾고 ON으로 설정합니다:

[mysqld]
. . .
loose-group_replication_start_on_boot = ON
. . .

작업을 마치면 파일을 저장하고 닫으십시오. 다음으로 MySQL 인스턴스가 시작될 때 회원은 자동으로 그룹에 가입을 시도해야 합니다.

결론

이 튜토리얼을 완료함으로써, Ubuntu 20.04 서버 3대 사이에 MySQL 그룹 복제를 구성하는 방법을 배웠습니다. 단일 주 서버 설정의 경우, 멤버는 필요할 때 자동으로 쓰기 가능한 주 서버를 선출합니다. 다중 주 서버 그룹의 경우, 모든 멤버가 쓰기와 업데이트를 수행할 수 있습니다. 그룹 복제는 멤버가 자유롭게 참여하거나 나갈 수 있는 유연한 복제 토폴로지를 제공하면서 동시에 데이터 일관성과 메시지 순서에 대한 보장을 제공합니다. MySQL 그룹 복제는 구성이 조금 더 복잡할 수 있지만 전통적인 복제에서는 불가능한 기능을 제공합니다.