Loading...
MySQL 9.5 Reference Manual 9.5의 20.6.4 Group Replication IP Address Permissions의 한국어 번역본입니다.
아래의 경우에 피드백에서 신고해주신다면 반영하겠습니다.
감사합니다 :)
XCom 통신 스택이 그룹 통신을 설정하는 데 사용될 때에만
(group_replication_communication_stack=XCOM),
Group Replication 플러그인은
들어오는 Group Communication System 연결을
수락할 수 있는 호스트들의 allowlist를 지정할 수 있게 합니다.
서버 s1에서 allowlist를 지정한 경우,
서버 s2가 그룹 통신에 참여할 목적으로 s1에
연결을 설정할 때, s1은 s2로부터의 연결을
수락하기 전에 먼저 allowlist를 확인합니다.
s2가 allowlist에 있으면 s1은 연결을 수락하고,
그렇지 않으면 s1은 s2의 연결 시도를 거부합니다.
시스템 변수
group_replication_ip_allowlist는
allowlist를 지정하는 데 사용됩니다.
참고
MySQL 통신 스택이 그룹 통신을 설정하는 데
사용되는 경우
(group_replication_communication_stack=MYSQL),
group_replication_ip_allowlist
설정은 무시됩니다.
Section 20.6.1, “Communication Stack for Connection Security Management”를 참조하십시오.
allowlist를 명시적으로 지정하지 않으면, 그룹 통신 엔진(XCom)은
호스트의 활성화된 인터페이스를 자동으로 스캔하고,
각 인터페이스에 대해 구성된 서브넷 마스크와 함께
프라이빗 서브네트워크에 속하는 주소를 식별합니다.
이 주소들과 IPv4 및 IPv6의
localhost IP 주소가
자동 Group Replication allowlist를 생성하는 데 사용됩니다.
따라서 자동 allowlist에는, 적절한 서브넷 마스크가 적용된 후 다음 범위에서 호스트에 대해 발견되는 모든 IP 주소가 포함됩니다:
1IPv4 (as defined in RFC 1918) 210/8 prefix (10.0.0.0 - 10.255.255.255) - Class A 3172.16/12 prefix (172.16.0.0 - 172.31.255.255) - Class B 4192.168/16 prefix (192.168.0.0 - 192.168.255.255) - Class C 5 6IPv6 (as defined in RFC 4193 and RFC 5156) 7fc00:/7 prefix - unique-local addresses 8fe80::/10 prefix - link-local unicast addresses 9 10127.0.0.1 - localhost for IPv4 11::1 - localhost for IPv6
호스트에 대해 자동으로 허용된 주소들을 나타내는 항목이 에러 로그에 추가됩니다.
프라이빗 주소의 자동 allowlist는
프라이빗 네트워크 외부의 서버에서 오는 연결에는 사용할 수 없으므로,
서버가 퍼블릭 IP에 인터페이스를 가지고 있더라도,
기본적으로는 외부 호스트에서 오는 Group Replication 연결을
허용하지 않습니다.
서로 다른 머신에 있는 서버 인스턴스 간의
Group Replication 연결을 위해서는
퍼블릭 IP 주소를 제공하고 이를 명시적인 allowlist로
지정해야 합니다.
allowlist에 어떤 항목이라도 지정하면,
프라이빗 주소와 localhost 주소는
자동으로 추가되지 않으므로,
이들 주소를 사용하는 경우
반드시 명시적으로 지정해야 합니다.
allowlist를 수동으로 지정하려면
group_replication_ip_allowlist
시스템 변수를 사용하십시오.
Group Replication이 실행 중인 동안에도
이 목록을 변경할 수 있습니다.
allowlist에는 각 멤버의
group_replication_local_address
시스템 변수에 지정된 IP 주소 또는 호스트명이
포함되어야 합니다.
이 주소는 MySQL 서버 SQL 프로토콜 호스트와 포트와는 동일하지 않으며,
서버 인스턴스의
bind_address 시스템 변수에
지정되지 않습니다.
어떤 서버 인스턴스의 Group Replication 로컬 주소로 사용된 호스트명이
IPv4 주소와 IPv6 주소 둘 다로 resolve되는 경우,
Group Replication 연결에는 IPv4 주소가 우선적으로 사용됩니다.
디스트리뷰티드 복구 엔드포인트로 지정된 IP 주소와,
디스트리뷰티드 복구에 사용되는 경우
(기본값) 멤버의 표준 SQL 클라이언트 연결용 IP 주소는
allowlist에 추가할 필요가 없습니다.
allowlist는 각 멤버에 대해
group_replication_local_address에
지정된 주소에만 사용됩니다.
join하는 멤버는 디스트리뷰티드 복구를 위한 주소(또는 주소들)를
가져오기 위해, 그룹에 대한 최초 연결이
allowlist에 의해 허용되어야 합니다.
allowlist에서는 다음 항목들을 임의의 조합으로 지정할 수 있습니다:
IPv4 주소(예: 198.51.100.44)
CIDR 표기법을 사용한 IPv4 주소(예:
192.0.2.21/24)
IPv6 주소(예:
2001:db8:85a3:8d3:1319:8a2e:370:7348)
CIDR 표기법을 사용한 IPv6 주소(예:
2001:db8:85a3:8d3::/64)
호스트명(예: example.org)
CIDR 표기법을 사용한 호스트명(예:
www.example.com/24)
호스트명은 IPv4 주소, IPv6 주소 또는 둘 다로 resolve될 수 있습니다. 호스트명이 IPv4와 IPv6 주소 둘 다로 resolve되는 경우, Group Replication 연결에는 항상 IPv4 주소가 사용됩니다. 특정 네트워크 prefix를 가진 IP 주소 블록을 허용하기 위해 CIDR 표기법을 호스트명이나 IP 주소와 함께 사용할 수 있지만, 지정된 서브넷 내의 모든 IP 주소가 여러분의 제어 하에 있는지 반드시 확인하십시오.
참고
어떤 IP 주소에서의 연결 시도가
allowlist에 주소가 없다는 이유로 거부되는 경우,
거부 메시지는 항상 그 IP 주소를 IPv6 형식으로 출력합니다.
이 형식에서 IPv4 주소는
::ffff:가 앞에 붙습니다
(IPv4-mapped IPv6 주소).
IPv4 주소를 allowlist에 지정할 때
이 형식을 사용할 필요는 없으며,
표준 IPv4 형식을 사용하면 됩니다.
allowlist의 각 항목은 쉼표로 구분해야 합니다. 예:
1mysql> SET GLOBAL group_replication_ip_allowlist="192.0.2.21/24,198.51.100.44,203.0.113.0/24,2001:db8:85a3:8d3:1319:8a2e:370:7348,example.org,www.example.com/24";
리플리케이션 그룹에 join하기 위해서는,
서버가 그룹에 join 요청을 보내는
seed 멤버에서 허용되어야 합니다.
일반적으로 이는 리플리케이션 그룹의 부트스트랩 멤버이지만,
그룹에 join하는 서버의 설정에서
group_replication_group_seeds
옵션에 나열된 어떤 서버라도 될 수 있습니다.
그룹의 seed 멤버 중 어느 것이든,
join하는 멤버가 IPv4
group_replication_local_address를
가지고 있을 때 IPv6 주소로,
또는 그 반대로,
group_replication_group_seeds
옵션에 나열되어 있는 경우,
seed 멤버가 제공하는 프로토콜(또는 그 프로토콜에 대한 주소로
resolve되는 호스트명)에 대해
join하는 멤버용 대체 주소를 설정하고 허용해야 합니다.
이는 서버가 리플리케이션 그룹에 join할 때,
IPv4인지 IPv6인지에 관계없이
group_replication_group_seeds
옵션에서 seed 멤버가 광고하는 프로토콜을 사용하여
seed 멤버에 초기 contact를 해야 하기 때문입니다.
join하는 멤버가 적절한 프로토콜에 대한
허용된 주소를 가지고 있지 않으면,
그 연결 시도는 거부됩니다.
IPv4와 IPv6가 혼합된 리플리케이션 그룹 관리에 대한
자세한 내용은
Section 20.5.5, “Support For IPv6 And For Mixed IPv6 And IPv4 Groups”를
참조하십시오.
리플리케이션 그룹이 재구성될 때 (예: 새로운 primary가 선출되거나 멤버가 join 또는 leave할 때), 그룹 멤버들은 서로 간의 연결을 다시 설정합니다. 어떤 그룹 멤버가, 재구성 이후 더 이상 리플리케이션 그룹의 구성원이 아닌 서버들에 의해서만 허용되는 경우, 해당 멤버를 허용하지 않는 나머지 리플리케이션 그룹 서버들에 다시 연결할 수 없습니다. 이러한 상황을 완전히 피하려면, 리플리케이션 그룹의 멤버인 모든 서버에 대해 동일한 allowlist를 지정하십시오.
참고
보안 요구 사항에 따라 서로 다른 그룹 멤버에 서로 다른 allowlist를 구성할 수도 있습니다. 예를 들어, 서로 다른 서브넷을 분리된 상태로 유지하기 위해서입니다.
보안 요구 사항을 충족하기 위해 서로 다른 allowlist를 구성해야 하는 경우, 리플리케이션 그룹에서 원래의 seed 멤버가 없는 상황에서도 서버들이 다시 연결할 수 있는 가능성을 극대화할 수 있도록 allowlist 사이에 충분한 overlap이 있도록 보장하십시오.
호스트명의 경우, name resolution은 다른 서버로부터 연결 요청이 있을 때에만 수행됩니다. resolve될 수 없는 호스트명은 allowlist 검증에서 고려되지 않으며, 경고 메시지가 에러 로그에 기록됩니다. resolve된 호스트명에 대해서는 Forward-confirmed reverse DNS(FCrDNS) 검증이 수행됩니다.
주의
호스트명은 allowlist에서 IP 주소보다 본질적으로 덜 안전합니다. FCrDNS 검증은 높은 수준의 보호를 제공하지만, 특정 유형의 공격에 의해 손상될 수 있습니다. allowlist에는 정말 필요한 경우에만 호스트명을 지정하고, DNS 서버와 같은 name resolution에 사용되는 모든 구성요소가 여러분의 제어 하에 유지되도록 하십시오. 또한, hosts 파일을 사용하여 로컬에서 name resolution을 구현함으로써 외부 구성요소의 사용을 피할 수도 있습니다.
20.6.3 Securing Distributed Recovery Connections
20.7 Group Replication Performance and Troubleshooting