19.4.9 Switching Sources and Replicas with Asynchronous Connection Failover

19.4.9 Switching Sources and Replicas with Asynchronous Connection Failover

19.4.9.1 Asynchronous Connection Failover for Sources 19.4.9.2 Asynchronous Connection Failover for Replicas

asynchronous connection failover 메커니즘을 사용하여, replica 에서 source 로의 기존 연결이 실패한 후에 새로운 source 로의 비동기식(source-to-replica) 복제 연결을 자동으로 설정할 수 있습니다. asynchronous connection failover 메커니즘은 데이터를 공유하는 여러 MySQL 서버 또는 서버 그룹과 replica 를 동기화 상태로 유지하는 데 사용할 수 있습니다. 잠재적인 source 서버의 목록은 replica 에 저장되며, 연결 실패가 발생하면, 당신이 설정한 가중 우선순위에 기반하여 목록에서 새로운 source 가 선택됩니다.

asynchronous connection failover 메커니즘은 또한 Group Replication 토폴로지를 지원하는데, 이는 그룹 멤버십의 변경을 자동으로 모니터링하고 primary 서버와 secondary 서버를 구분함으로써 이루어집니다. source 목록에 그룹 멤버를 추가하고 그것을 관리되는 그룹(managed group)의 일부로 정의하면, asynchronous connection failover 메커니즘은 멤버십 변경에 맞추어 source 목록을 갱신하며, 그룹 멤버가 조인 또는 리브할 때 이를 자동으로 추가 및 제거합니다.

majority 에 속하는 온라인 그룹 멤버만이 연결 및 상태 획득을 위해 사용됩니다. 관리되는 그룹의 마지막 남은 멤버는 그룹을 떠나더라도 구성(configuration)을 유지하기 위해 자동으로 제거되지 않습니다. 그러나 더 이상 필요하지 않은 관리되는 그룹은 수동으로 삭제할 수 있습니다.

asynchronous connection failover 메커니즘은 또한 관리되는 복제 그룹(managed replication group)의 일부인 replica 가, 현재 수신자(receiver, 그룹의 primary)가 실패한 경우 송신자(sender)에 자동으로 다시 연결할 수 있게 해줍니다. 이 기능은 single-primary 모드로 구성된 Group Replication 에서 동작하며, 여기서 그룹의 primary 는 이 메커니즘을 사용하는 복제 채널을 가진 replica 입니다.

이 기능은 일부 멤버가 일시적으로 사용 불가능하더라도, sender 그룹과 receiver 그룹이 서로 동기화 상태를 유지하도록 설계되었습니다. 또한 관리되는 그룹의 일부가 아닌 하나 이상의 sender 와 receiver 그룹을 동기화합니다. 복제 그룹의 일부가 아닌 replica 는 이 기능을 사용할 수 없습니다.

asynchronous connection failover 메커니즘을 사용하기 위한 요구 사항은 다음과 같습니다:

• GTID 가 source 와 replica 에서 사용 중이어야 합니다 ( gtid_mode=ON), 그리고 CHANGE REPLICATION SOURCE TO 문장의 SOURCE_AUTO_POSITION 옵션이 replica 에서 활성화되어야 하며, 이를 통해 source 와의 연결에 GTID 자동 포지셔닝이 사용됩니다.

• 동일한 복제 사용자 계정과 비밀번호가 채널의 source 목록에 있는 모든 source 서버에 존재해야 합니다. 이 계정은 각 source 로의 연결에 사용됩니다. 서로 다른 채널에 대해 서로 다른 계정을 설정할 수 있습니다.

• 복제 사용자 계정에 Performance Schema 테이블에 대한 SELECT 권한이 부여되어야 합니다. 예를 들어 GRANT SELECT ON performance_schema.* TO 'repl_user'; 를 실행하여 부여할 수 있습니다.

• 복제 사용자 계정과 비밀번호는 복제를 시작하는 데 사용되는 문장에서 지정할 수 없습니다. 이는 대체 source 로의 연결을 위한 자동 재시작 시에 필요하기 때문입니다. 해당 값들은 replica 에서 CHANGE REPLICATION SOURCE TO 문장을 사용하여 채널에 대해 설정해야 하며, 복제 메타데이터 리포지토리에 기록되어야 합니다.

• asynchronous connection failover 메커니즘이 사용 중인 채널이 Group Replication single-primary 모드 그룹의 primary 에 있는 경우, replica 간의 asynchronous connection failover 도 기본적으로 활성화됩니다. 이 상황에서는 복제 채널과 해당 채널의 복제 사용자 계정 및 비밀번호가 복제 그룹 내의 모든 secondary 서버와 새로 조인하는 모든 멤버에 대해 설정되어야 합니다. 새로운 서버가 MySQL 의 클론 기능을 사용하여 프로비저닝되는 경우, 이 모든 작업은 자동으로 이루어집니다.

중요

이 상황에서 replica 간의 asynchronous connection failover 가 발생하지 않도록 하려면, group_replication_disable_member_action 함수를 사용하여 그룹에 대해 멤버 액션 mysql_start_failover_channels_if_primary 를 비활성화하여 이 기능을 비활성화하십시오. 기능이 비활성화된 경우에는 secondary 그룹 멤버에 복제 채널을 설정할 필요가 없지만, primary 가 오프라인 상태가 되거나 오류 상태에 들어가면 해당 채널에 대한 복제는 중지됩니다.

MySQL InnoDB ClusterSet 은 primary InnoDB Cluster 를 다른 데이터 센터와 같은 대체 위치에 있는 하나 이상의 복제본과 연결함으로써 InnoDB Cluster 배포에 대한 재해 내성을 제공합니다. 복제, 장애 조치(failover) 및 재해 복구를 위한 새로운 멀티 그룹 배포의 설정을 단순화하기 위해 이 솔루션을 대신 사용하는 것을 고려하십시오. 기존 Group Replication 배포를 InnoDB Cluster 로 채택(adopt)할 수 있습니다.

InnoDB ClusterSet 과 InnoDB Cluster 는 복제 그룹을 설정, 관리, 모니터링, 복구 및 수리하는 절차를 추상화하고 단순화하도록 설계되었습니다. InnoDB ClusterSet 은 전용 ClusterSet 복제 채널을 사용하여 primary 클러스터에서 replica 클러스터로의 복제를 자동으로 관리합니다. primary 클러스터가 정상적으로 동작하지 않을 경우, 관리자 명령을 사용하여 그룹 간의 제어된 스위치오버(switchover) 또는 긴급 장애 조치(failover)를 트리거할 수 있습니다. 서버와 그룹은 초기 설정 이후 수요가 변경될 때 InnoDB ClusterSet 배포에 쉽게 추가되거나 제거될 수 있습니다. 자세한 내용은 MySQL InnoDB ClusterSet을 참조하십시오.