20.6.1 Communication Stack for Connection Security Management

20.6.1 Connection Security Management를 위한 Communication Stack

MySQL 9.5 Group Replication은 다음 두 방법 중 하나로 멤버 간 그룹 communication connection을 보안할 수 있습니다:

• TLS/SSL 및 들어오는 Group Communication System (GCS) connection을 위한 allowlist 사용을 포함하여, 자체 구현한 보안 프로토콜을 사용하는 방법

• Group Replication의 구현 대신 MySQL Server 고유의 connection 보안을 사용하는 방법. MySQL 프로토콜을 사용하면, allowlist 대신 그룹에 대한 액세스를 부여(또는 취소)하기 위해 표준 사용자 인증 방법을 사용할 수 있고, 서버 프로토콜의 최신 기능이 릴리스 시점마다 항상 사용 가능합니다.

선택은 system variable group_replication_communication_stack을 XCOM으로 설정하여 Group Replication의 자체 구현을 사용하게 하거나(이는 기본 선택입니다), MYSQL로 설정하여 MySQL Server의 connection 보안을 사용하게 함으로써 이루어집니다.

replication group이 MySQL communication stack을 사용하려면 다음과 같은 추가 구성이 필요합니다. 특히 그룹에 대해 XCom communication stack에서 MySQL communication stack으로 전환할 때, 이 요구 사항들이 모두 충족되는지 확인하는 것이 중요합니다.

MySQL Communication Stack을 위한 Group Replication 요구 사항

• 각 group member에 대해 group_replication_local_address system variable로 설정된 네트워크 주소는, 서버에 대해 bind_address system variable에 의해 지정된, MySQL Server가 리슨 중인 IP 주소 및 포트 중 하나로 설정되어야 합니다. 각 member에 대한 IP 주소와 포트의 조합은 group 내에서 고유해야 합니다. 또한 각 group member에 대해 group_replication_group_seeds system variable이 모든 group member의 모든 로컬 주소를 포함하도록 설정할 것을 권장합니다.

• MySQL communication stack은 네트워크 네임스페이스를 지원하지만, XCom communication stack은 이를 지원하지 않습니다. Group Replication 로컬 주소가 group member용으로 (group_replication_local_address) 네트워크 네임스페이스와 함께 사용되는 경우, 각 group member에 대해 CHANGE REPLICATION SOURCE TO statement를 사용하여 이를 설정해야 합니다. 또한 각 group member에 대한 report_host 서버 system variable은 네임스페이스를 보고하도록 설정되어야 합니다. 분산 복구(distributed recovery) 중 주소 해석과 관련된 문제를 방지하려면 모든 group member가 동일한 네임스페이스를 사용해야 합니다.

• group_replication_ssl_mode system variable은 group communication에 필요한 설정으로 지정되어야 합니다. 이 system variable은 group communication에 대해 TLS/SSL을 활성화 또는 비활성화할지 여부를 제어합니다. MySQL communication stack이 사용되는 경우, TLS/SSL 구성은 Group Replication의 분산 복구 설정에서 가져옵니다. 이 설정은 잠재적인 충돌을 방지하기 위해 모든 group member에서 동일해야 합니다.

• require_secure_transport 서버 system variable 값은 잠재적인 충돌을 방지하기 위해 모든 group member에서 동일해야 합니다. group_replication_ssl_mode가 REQUIRED, VERIFY_CA, 또는 VERIFY_IDENTITY로 설정된 경우 require_secure_transport=ON을 사용하십시오. group_replication_ssl_mode가 DISABLED로 설정된 경우에는 require_secure_transport=OFF를 사용하십시오.

• group communication에 대해 TLS/SSL이 활성화된 경우, Group Replication의 분산 복구 보안을 위한 설정은 아직 설정되지 않았다면 구성해야 하고, 이미 설정된 경우에는 유효성을 검증해야 합니다. MySQL communication stack은 member 간 분산 복구 connection뿐만 아니라 일반적인 group communication에서의 TLS/SSL 구성에도 이러한 설정을 사용합니다. group_replication_recovery_use_ssl 및 기타 group_replication_recovery_* system variable에 대해서는 Section 20.6.3.2, “Secure Socket Layer (SSL) Connections for Distributed Recovery”에 설명되어 있습니다.

• group이 MySQL communication stack을 사용하는 경우 Group Replication allowlist는 사용되지 않으므로 group_replication_ip_allowlist system variable은 무시되며 설정할 필요가 없습니다.

• Group Replication이 분산 복구에 사용하는 replication 사용자 계정은 CHANGE REPLICATION SOURCE TO statement를 사용하여 구성되며, Group Replication connection을 설정할 때 MySQL communication stack이 인증을 위해 이를 사용합니다. 이 사용자 계정은 모든 group member에서 동일하며, 다음 권한을 부여받아야 합니다:

  • GROUP_REPLICATION_STREAM. 이 권한은 사용자 계정이 MySQL communication stack을 사용하여 Group Replication을 위한 connection을 설정할 수 있도록 하는 데 필요합니다.

  • CONNECTION_ADMIN. 이 권한은 관련된 서버 중 하나가 오프라인 모드로 전환되더라도 Group Replication connection이 종료되지 않도록 하는 데 필요합니다. 이 권한 없이 MySQL communication stack이 사용되는 경우, 오프라인 모드로 전환된 member는 group에서 추방됩니다.

이러한 권한은 모든 replication 사용자 계정이 가져야 하는 REPLICATION SLAVE 및 BACKUP_ADMIN 권한에 추가되는 것입니다(참조: Section 20.2.1.3, “User Credentials For Distributed Recovery”). 새 권한을 추가할 때는, 각 group member에서 GRANT statement를 실행하기 전에 SET SQL_LOG_BIN=0을 실행하고, 그 이후에는 SET SQL_LOG_BIN=1을 실행하여, 로컬 트랜잭션이 Group Replication 재시작에 영향을 주지 않도록 바이너리 로깅을 건너뛰도록 해야 합니다.

group_replication_communication_stack은 사실상 group 전체에 대한 configuration 설정이며, 설정은 모든 group member에서 동일해야 합니다. 그러나 이 설정은 Group Replication의 group-wide configuration 설정에 대한 자체 검사에 의해 강제되지는 않습니다. group의 나머지 member와 다른 값을 가진 member는 communication 프로토콜이 호환되지 않기 때문에 다른 member와 전혀 통신할 수 없으며, 그 결과 자신의 configuration 설정에 대한 정보를 교환할 수 없습니다.

이는 system variable의 값은 Group Replication이 실행 중일 때 변경할 수 있고, group member에서 Group Replication을 재시작한 후에 효력이 발생하지만, 설정이 모든 member에서 변경될 때까지 해당 member는 여전히 group에 재참여할 수 없다는 의미입니다. 따라서 모든 member에서 Group Replication을 중지한 뒤, group을 다시 시작할 수 있도록 모든 member에서 system variable의 값을 변경해야 합니다. 모든 member가 중지되어 있기 때문에, 값 변경이 효력을 발휘하려면 group_replication_bootstrap_group=ON으로 설정된 서버에 의한 group 전체 재부팅(bootstrap)이 필요합니다. 이때 group member가 중지된 동안 필요한 다른 설정 변경도 함께 수행할 수 있습니다.

실행 중인 group의 경우, XCom communication stack에서 MySQL communication stack으로, 또는 MySQL communication stack에서 XCom communication stack으로 group을 마이그레이션하기 위해 group_replication_communication_stack의 값과 기타 필요한 설정을 변경하려면 다음 절차를 따르십시오:

1. 각 group member에서 STOP GROUP_REPLICATION statement를 사용하여 Group Replication을 중지합니다. 새 primary 선출을 트리거하고 그 완료를 기다려야 하는 상황을 방지하려면 primary member를 마지막에 중지합니다.

2. 각 group member에서 group_replication_communication_stack system variable을 새로운 communication stack인 MYSQL 또는 XCOM으로 적절히 설정합니다. 이는 MySQL Server configuration 파일(일반적으로 Linux 및 Unix 시스템에서는 my.cnf, Windows 시스템에서는 my.ini라는 이름)을 편집하거나, SET statement를 사용하여 수행할 수 있습니다. 예를 들면 다음과 같습니다:

1SET PERSIST group_replication_communication_stack="MYSQL";

3. replication group을 XCom communication stack(기본값)에서 MySQL communication stack으로 마이그레이션하는 경우, 각 group member에서 위의 목록에 설명된 대로 필요한 system variable을 적절한 설정으로 구성 또는 재구성합니다. 예를 들어 group_replication_local_address system variable은 MySQL Server가 리슨 중인 IP 주소 및 포트 중 하나로 설정해야 합니다. 또한 CHANGE REPLICATION SOURCE TO statement를 사용하여 필요한 모든 네트워크 네임스페이스를 구성합니다.

4. replication group을 XCom communication stack(기본값)에서 MySQL communication stack으로 마이그레이션하는 경우, 각 group member에서 GRANT statement를 실행하여 replication 사용자 계정에 GROUP_REPLICATION_STREAM 및 CONNECTION_ADMIN 권한을 부여합니다. Group Replication이 중지되었을 때 적용되는 read-only 상태에서 group member를 해제해야 합니다. 또한 각 group member에서 GRANT statement를 실행하기 전에 SET SQL_LOG_BIN=0을 실행하고 그 이후에 SET SQL_LOG_BIN=1을 실행하여, 로컬 트랜잭션이 Group Replication 재시작에 영향을 주지 않도록 바이너리 로깅을 건너뛰도록 합니다. 예를 들면 다음과 같습니다:

1SET GLOBAL SUPER_READ_ONLY=OFF;
2SET SQL_LOG_BIN=0;
3GRANT GROUP_REPLICATION_STREAM ON *.* TO rpl_user@'%';
4GRANT CONNECTION_ADMIN ON *.* TO rpl_user@'%';
5SET SQL_LOG_BIN=1;

5. replication group을 MySQL communication stack에서 다시 XCom communication stack으로 마이그레이션하는 경우, 각 group member에서 위의 요구 사항 목록에 있는 system variable을 XCom communication stack에 적합한 설정으로 재구성합니다. Section 20.9, “Group Replication Variables”에는 XCom communication stack에 대한 기본값과 요구 사항과 함께 system variable이 나열되어 있습니다.

참고

• XCom communication stack은 네트워크 네임스페이스를 지원하지 않으므로, Group Replication 로컬 주소 (group_replication_local_address system variable)는 이를 사용할 수 없습니다. CHANGE REPLICATION SOURCE TO statement를 실행하여 이를 해제하십시오.

• XCom communication stack으로 되돌릴 때, group_replication_recovery_use_ssl 및 기타 group_replication_recovery_* system variable로 지정된 설정은 group communication 보안을 위해 사용되지 않습니다. 대신, Group Replication system variable group_replication_ssl_mode가 group communication connection에 대해 SSL 사용을 활성화하고 connection의 보안 모드를 지정하는 데 사용되며, 나머지 구성은 서버의 SSL 구성에서 가져옵니다. 자세한 내용은 Section 20.6.2, “Securing Group Communication Connections with Secure Socket Layer (SSL)”를 참조하십시오.

6. group을 재시작하려면 Section 20.5.2, “Restarting a Group”에 설명된 절차를 따르십시오. 여기에는 트랜잭션이 실행되고 인증된 group을 안전하게 bootstrap하는 방법이 설명되어 있습니다. 모든 member를 종료해야 하므로, communication stack을 변경하려면 group_replication_bootstrap_group=ON으로 설정된 서버에 의한 bootstrap이 필요합니다.

7. 이제 member는 새로운 communication stack을 사용하여 서로 연결됩니다. group_replication_communication_stack이 이전 communication stack으로 설정(또는 XCom의 경우 기본값)된 서버는 더 이상 group에 참여할 수 없습니다. Group Replication은 참여 시도를 인지하지 못하므로, 참여 member를 error message와 함께 검사하고 거부하지 않는다는 점이 중요합니다. 대신, 이전 communication stack이 새로운 stack에 연결을 시도하다가 포기할 때 참여 시도는 조용히 실패합니다.