20.10 Frequently Asked Questions

20.10 Frequently Asked Questions

이 절에서는 자주 묻는 질문에 대한 답변을 제공합니다.

What is the maximum number of MySQL servers in a group?

하나의 group은 최대 9개의 server로 구성될 수 있습니다. 9개의 member가 있는 group에 또 다른 server를 추가하려고 시도하면, join 요청은 거부됩니다. 이 제한은 안정적인 로컬 영역 네트워크 환경에서 group이 신뢰성 있게 동작하는 안전한 경계값으로, 테스트와 벤치마킹을 통해 확인되었습니다.

How are servers in a group connected?

group의 server들은 peer-to-peer TCP 연결을 열어 group 내의 다른 server에 연결합니다. 이러한 연결은 group 내 server 간의 내부 통신과 메시지 전달에만 사용됩니다. 이 주소는 group_replication_local_address 변수로 설정합니다.

What is the group_replication_bootstrap_group option used for?

bootstrap 플래그는 member에게 group을 생성 하고 초기 seed server로 동작하라고 지시합니다. group에 합류하는 두 번째 member는 group을 bootstrap한 member에게 자신이 group에 추가될 수 있도록 설정을 동적으로 변경해 달라고 요청해야 합니다.

member는 두 가지 상황에서 group을 bootstrap해야 합니다. group이 처음 생성될 때, 그리고 전체 group을 종료한 뒤 다시 시작할 때입니다.

How do I set credentials for the distributed recovery process?

group_replication_recovery 채널의 자격 증명으로 사용자 자격 증명을 영구적으로 설정하려면 CHANGE REPLICATION SOURCE TO 문을 사용할 수 있습니다. 또한 Group Replication을 시작할 때마다 START GROUP_REPLICATION 문에서 자격 증명을 지정할 수 있습니다.

CHANGE REPLICATION SOURCE TO로 설정한 사용자 자격 증명은 server의 복제 메타데이터 리포지토리에 평문으로 저장되지만, START GROUP_REPLICATION에서 지정한 사용자 자격 증명은 메모리에만 저장되며, STOP GROUP_REPLICATION 문 실행이나 server 셧다운 시 제거됩니다. 따라서 사용자 자격 증명을 지정하기 위해 START GROUP_REPLICATION을 사용하는 방식은 Group Replication server를 무단 접근으로부터 보호하는 데 도움이 됩니다. 그러나 이 방법은 group_replication_start_on_boot 시스템 변수에 의해 지정되는, Group Replication을 자동으로 시작하는 방식과는 호환되지 않습니다. 자세한 내용은 Section 20.6.3.1, “Secure User Credentials for Distributed Recovery”를 참조하십시오.

Can I scale-out my write-load using Group Replication?

직접적으로는 불가능하지만, MySQL Group Replication은 공유 없음(share-nothing) 전체 복제 솔루션으로, group의 모든 server가 동일한 양의 데이터를 복제합니다. 따라서 group의 한 member가 트랜잭션 커밋 작업의 결과로 스토리지에 N바이트를 기록하는 경우, 그 트랜잭션이 모든 곳에 복제되기 때문에 다른 member에서도 대략 N바이트가 스토리지에 기록됩니다.

그러나 다른 member는 처음에 트랜잭션을 실행했던 원래 member만큼 많은 처리 작업을 수행할 필요가 없으므로, 변경 내용을 더 빠르게 적용합니다. 트랜잭션은 다시 실행할 필요 없이 row 변환을 적용하는 데만 사용되는 형식(row 기반 포맷)으로 복제됩니다.

또한 변경 사항이 row 기반 포맷으로 전파되고 적용되므로, 최적화되고 컴팩트한 형식으로 수신되며, 원래 member와 비교했을 때 필요한 I/O 작업 수가 줄어들 가능성이 있습니다.

정리하면, group 내의 서로 다른 member에 충돌 없는 트랜잭션을 분산시켜 처리량을 스케일아웃할 수 있습니다. 그리고 remote server는 안정적인 스토리지에 읽기-수정-쓰기 변경을 수행하는 데 필요한 변경 사항만을 수신하므로, I/O 작업의 일부를 스케일아웃할 수 있습니다.

Does Group Replication require more network bandwidth and CPU, when compared to simple replication and under the same workload?

server들은 동기화를 위해 지속적으로 서로 상호작용해야 하므로, 어느 정도의 추가 부하가 발생하는 것은 예상됩니다. 얼마나 많은 데이터를 더 필요한지 정량화하기는 어렵습니다. 또한 group의 크기에도 영향을 받습니다(예를 들어, 3개의 server는 9개의 server로 구성된 group보다 대역폭 요구 사항에 덜 부담을 줍니다).

또한 server 동기화 부분과 group 메시징에서 더 복잡한 작업을 수행하므로, 메모리와 CPU 사용량도 더 커집니다.

Can I deploy Group Replication across wide-area networks?

가능하지만, 각 member 간의 네트워크 연결은 반드시(must) 신뢰할 수 있고 적절한 성능을 가져야 합니다. 최적의 성능을 위해서는 지연 시간이 낮고 대역폭이 높은 네트워크 연결이 필요합니다.

네트워크 대역폭만이 문제인 경우, 필요한 대역폭을 줄이기 위해 Section 20.7.4, “Message Compression” 을 사용할 수 있습니다. 그러나 네트워크가 패킷을 드롭하여 재전송이 발생하고 종단 간 지연 시간이 증가하면, 처리량과 지연 시간 모두에 부정적인 영향을 미칩니다.

주의

어떤 group member 사이든 네트워크 왕복 시간(RTT)이 5초 이상이면, 내장된 장애 감지 메커니즘이 잘못 트리거되어 문제가 발생할 수 있습니다.

Do members automatically rejoin a group in case of temporary connectivity problems?

이는 연결 문제의 원인에 따라 다릅니다. 연결 문제가 일시적이고, 재연결이 장애 감지기가 이를 인지하지 못할 만큼 충분히 빠르게 이뤄지는 경우, server는 group에서 제거되지 않을 수 있습니다. 만약 "긴" 연결 문제가 발생하면, 장애 감지기가 결국 문제를 의심하고 server를 group에서 제거합니다.

member가 group에 남거나 다시 합류할 가능성을 높이기 위해 사용할 수 있는 설정은 두 가지입니다:

• group_replication_member_expel_timeout 은 suspicion(초기 5초간의 감지 기간 이후 발생)의 생성과 member의 추방 사이의 시간을 늘립니다. 최대 1시간의 대기 시간을 설정할 수 있습니다. 기본값은 5초입니다.

• group_replication_autorejoin_tries 는 member가 추방 또는 다수 미접근 타임아웃 이후 group에 다시 join을 시도하도록 합니다. member는 5분 간격으로 지정된 횟수만큼 자동 재조인을 시도합니다. 이 기능은 기본적으로 활성화되어 있으며, member는 세 번의 자동 재조인을 시도합니다.

server가 group에서 추방되고 자동 재조인 시도가 모두 실패한 경우, 다시 join하도록 해야 합니다. 다시 말해, server가 group에서 명시적으로 제거된 후에는 수동으로(또는 스크립트를 사용해 자동으로) 다시 join시켜야 합니다.

When is a member excluded from a group?

member가 조용한(silent) 상태가 되면, 다른 member들은 해당 member를 group 구성에서 제거합니다. 실제로는 member가 크래시 했거나 네트워크 연결이 끊어졌을 때 이런 일이 일어날 수 있습니다.

특정 member에 대해 설정된 타임아웃이 경과하면 장애가 감지되고, 그 조용한 member를 제외한 새로운 구성이 생성됩니다.

What happens when one node is significantly lagging behind?

member를 group에서 자동으로 추방할 시점을 정의하기 위한 정책을 지정하는 방법은 없습니다. 해당 member가 뒤처지는 이유를 찾아서 문제를 해결하거나, member를 group에서 제거해야 합니다. 그렇지 않으면, server가 너무 느려 플로우 컨트롤을 트리거하는 경우 전체 group도 느려지게 됩니다. 플로우 컨트롤은 필요에 따라 설정할 수 있습니다.

Upon suspicion of a problem in the group, is there a special member responsible for triggering a reconfiguration?

아니요, 재구성을 트리거하는 역할을 담당하는 특수한 member는 group에 없습니다.

어떤 member든 문제를 의심할 수 있습니다. 모든 member는 특정 member가 실패했다는 점에 (자동으로) 동의해야 합니다. 한 member가 재구성을 트리거하여 해당 member를 group에서 추방하는 역할을 담당합니다. 어떤 member가 추방 작업을 담당하게 될지는 사용자가 제어하거나 설정할 수 없습니다.

Can I use Group Replication for sharding?

Group Replication은 고가용 복제본 세트를 제공하도록 설계되었습니다. group 내 각 member에는 데이터와 쓰기가 중복 저장됩니다. 단일 시스템이 제공할 수 있는 범위를 넘어 스케일아웃하려면, 여러 Group Replication 세트를 기반으로 하는 오케스트레이션 및 샤딩 프레임워크가 필요하며, 각 복제본 세트는 전체 데이터 세트의 특정 샤드 또는 파티션을 유지 및 관리합니다. 이러한 유형의 설정은 흔히 “샤딩 클러스터(sharded cluster)”라고 불리며, 읽기와 쓰기를 선형적으로, 그리고 제한 없이 스케일아웃할 수 있습니다.

How do I use Group Replication with SELinux?

sestatus -v 명령으로 확인할 수 있는 SELinux가 활성화되어 있다면, Group Replication 통신 포트 사용을 허용해야 합니다. 자세한 내용은 Setting the TCP Port Context for Group Replication 을 참조하십시오.

How do I use Group Replication with iptables?

iptables가 활성화되어 있다면, 머신 간 통신을 위해 Group Replication 포트를 열어야 합니다. 각 머신에서 현재 적용된 규칙을 확인하려면 iptables -L을 실행하십시오. 설정된 포트가 33061이라고 가정하면, 다음 명령을 실행하여 필요한 포트에서 통신을 허용합니다:

iptables -A INPUT -p tcp --dport 33061 -j
ACCEPT.

How do I recover the relay log for a replication channel used by a group member?

Group Replication에서 사용되는 복제 채널은 비동기 소스-레플리카 복제에서 사용되는 복제 채널과 동일하게 동작하며, 릴레이 로그에 의존합니다. relay_log 변수가 변경되거나, 해당 옵션이 설정되지 않은 상태에서 호스트 이름이 변경되면 오류가 발생할 수 있습니다. 이 상황에서의 복구 절차는 Section 19.2.4.1, “The Relay Log” 을 참조하십시오. 또는 Group Replication에 특화된 다른 해결 방법으로, STOP GROUP_REPLICATION 문을 실행한 뒤 START GROUP_REPLICATION 문을 실행하여 인스턴스를 재시작하는 방법이 있습니다. 그러면 Group Replication 플러그인이 group_replication_applier 채널을 다시 생성합니다.

Why does Group Replication use two bind addresses?

Group Replication은 두 개의 바인드 주소를 사용하여, 클라이언트가 member와 통신하는 데 사용하는 SQL 주소와, group member 간 내부 통신에 사용하는 group_replication_local_address 를 분리합니다. 예를 들어, 203.0.113.1과 198.51.100.179 두 개의 네트워크 인터페이스가 할당된 server가 있다고 가정해 보겠습니다. 이 경우, group_replication_local_address=203.0.113.1:33061 으로 설정하여, 내부 group 네트워크 주소로 203.0.113.1:33061을 사용할 수 있습니다. 그런 다음 hostname으로는 198.51.100.179를, port로는 3306을 사용할 수 있습니다.

그러면 클라이언트 SQL 애플리케이션은 198.51.100.179:3306으로 member에 접속하게 됩니다. 이를 통해 서로 다른 네트워크에 서로 다른 규칙을 설정할 수 있습니다. 마찬가지로, 보안을 강화하기 위해 클라이언트 애플리케이션에서 사용하는 네트워크 연결과 내부 group 통신을 분리할 수 있습니다.

How does Group Replication use network addresses and hostnames?

Group Replication은 member 간 네트워크 연결을 사용하므로, 호스트 이름과 포트 설정 방식이 기능에 직접적인 영향을 줍니다. 예를 들어, Group Replication의 분산 복구 프로세스는 server의 호스트 이름과 포트를 사용하여 기존 group member에 대한 연결을 생성합니다. member가 group에 join하면, performance_schema.replication_group_members 에 나열된 네트워크 주소 정보를 사용하여 group 멤버십 정보를 받습니다. 해당 테이블에 나열된 member 중 하나가, group에서 joining member에게 전달해야 할 누락된 데이터의 donor로 선택됩니다.

이는 SQL 네트워크 주소나 group seed 주소처럼 호스트 이름을 사용해 설정하는 값이 있으면, 반드시 정규화된 도메인 이름이어야 하며 group의 각 member가 이를 해석(resolve)할 수 있어야 함을 의미합니다. 이를 보장하는 방법으로는 예를 들어 DNS 사용, 올바르게 설정된 /etc/hosts 파일, 기타 로컬 프로세스 등을 들 수 있습니다. server에서 MEMBER_HOST 값을 설정하려면, group에 join시키기 전에 server에서 --report-host 옵션을 사용하여 지정하십시오.

주의

할당된 값은 그대로 사용되며, skip_name_resolve 시스템 변수의 영향을 받지 않습니다.

server에서 MEMBER_PORT를 설정하려면, report_port 시스템 변수를 사용하여 지정하십시오.

Why did the auto increment setting on the server change?

server에서 Group Replication이 시작되면, auto_increment_increment 값은 group_replication_auto_increment_increment 값으로 변경되며, 기본값은 7입니다. auto_increment_offset 값은 server ID로 변경됩니다. Group Replication이 중지되면 이러한 변경 사항은 원래대로 되돌려집니다. 이러한 설정은 group member에서 쓰기 시 auto-increment 값이 중복되는 것을 방지하여 트랜잭션 롤백이 발생하지 않도록 합니다. Group Replication에서 auto increment 기본값을 7로 설정한 것은 사용 가능한 값의 수와 복제 group의 허용 최대 크기(9개 member) 사이의 균형을 고려한 것입니다.

이러한 변경은 auto_increment_increment와 auto_increment_offset 각각의 값이 기본값(두 경우 모두 1)인 경우에만 이루어지고 되돌려집니다. 값이 이미 기본값에서 변경된 상태라면, Group Replication은 이를 변경하지 않습니다. 또한 Group Replication이 싱글 프라이머리 모드(오직 하나의 server만 쓰기를 수행하는 모드)일 때는 해당 시스템 변수도 변경되지 않습니다.

How do I find the primary?

group이 싱글 프라이머리 모드로 동작 중인 경우, 어떤 member가 primary인지 알아두는 것이 유용할 수 있습니다. Section 20.1.3.1.2, “Finding the Primary” 를 참조하십시오.