MySQL 서버는 MGR 클러스터에 새로 가입하거나 다시 가입할 때마다 클러스터의 다양한 트랜잭션을 따라잡아 이 노드의 데이터가 클러스터의 최신 데이터와 동기화되도록 해야 합니다. 새로 추가된 노드가 클러스터 내의 데이터를 따라잡거나 클러스터에 다시 합류하는 노드가 클러스터를 떠난 시점과 현재 사이의 트랜잭션 데이터의 차이를 따라잡는 과정을 분산 복구라고 합니다.
클러스터 가입을 신청한 노드는 먼저 groupreplicationapplier 채널에서 릴레이 로그를 확인하여 클러스터에서 아직 동기화되지 않은 노드의 트랜잭션 데이터를 확인합니다. 클러스터에 다시 합류하는 노드인 경우 해당 노드는 클러스터를 떠난 이후 재생되지 않은 트랜잭션 데이터와 클러스터의 최신 데이터를 먼저 찾습니다. 클러스터에 새로 추가된 노드의 경우 전체 데이터 복구를 부팅 노드에서 직접 수행할 수 있습니다.
이후 새로 추가된 노드는 상태 이전을 위해 클러스터 내 기존 온라인 노드(부트 노드)와 연결을 설정합니다. 새로 추가된 노드는 클러스터에 합류하기 전이나 클러스터의 부팅 노드에서 클러스터를 떠난 후에 동기화되지 않은 데이터를 동기화합니다. 이러한 다양한 트랜잭션은 클러스터의 부팅 노드에서 제공됩니다. 다음으로 새로 추가된 노드는 클러스터의 부트스트랩 노드에서 동기화된 미적용 트랜잭션을 적용합니다. 이때, 클러스터 가입을 신청한 노드는 상태 이전 과정에서 새로운 트랜잭션이 쓴 데이터를 클러스터에 적용하게 된다. (이때, 클러스터 내 새로운 것들에 의해 쓰여진 데이터는 임시로 캐시 큐에 저장되며, 디스크에는 쓰여지지 않습니다.) 이 과정이 끝나면 새로 추가된 노드들의 데이터는 비교 가능한 수준이 됩니다. 전체 클러스터 상태의 데이터로 노드가 온라인 상태로 설정됩니다.
참고: 클러스터에 가입하는 새 노드는 이전에 이 클러스터에 있었는지 여부에 관계없이 먼저 온라인 노드를 무작위로 선택하여 노드와 클러스터 간의 다양한 트랜잭션을 동기화합니다.
그룹 복제는 다음 방법을 사용하여 분산 복구 중 상태 전송을 구현합니다.
복제 플러그인의 기능을 사용하여 MySQL 8.0.17부터 지원되는 원격 복제 작업을 수행합니다. 이 방법을 사용하려면 부팅 노드와 새로 가입한 노드에 복제 플러그인이 미리 설치되어 있어야 합니다. 그룹 복제는 필요한 복제 플러그인 설정을 자동으로 구성하고 원격 복제 작업을 관리합니다.
부트 노드의 바이너리 로그에서 데이터를 복사하고 새로 가입한 노드에 이러한 트랜잭션을 적용합니다. 이 방법을 사용하려면 부트 노드와 조인 노드 사이에 설정된 groupreplicationrecovery라는 표준 비동기 복제 채널이 필요합니다.
참여 노드에서 STARTGROUP_REPLICATION을 실행한 후 그룹 복제는 상태 전송을 위해 위 방법 중 가장 적합한 조합을 자동으로 선택합니다. 이를 위해 그룹 복제는 클러스터의 기존 노드가 부팅 노드로 사용하기에 적합한지, 가입 노드가 부팅 노드에서 필요한 트랜잭션 수, 트랜잭션의 바이너리 로그 파일에 더 이상 존재하지 않는지 여부를 확인합니다. 클러스터의 모든 노드. 조인 노드와 부트 노드 사이에 트랜잭션 간격이 크거나 필요한 트랜잭션 중 일부가 부트 노드의 바이너리 로그 파일에 없는 경우 그룹 복제는 원격 복제 작업을 통해 분산 복구를 시작합니다. 큰 트랜잭션 간격이 없거나 복제 플러그인이 설치되지 않은 경우 그룹 복제는 부트 노드의 바이너리 로그에서 직접 상태를 전송합니다.
원격 복제 작업 중에 참여하는 노드의 기존 데이터가 삭제되고 부팅 노드 데이터의 복사본으로 대체됩니다. 원격 복제 작업이 완료되고 새로 가입된 노드가 다시 시작되면 부트 노드 바이너리 로그의 상태 전송을 통해 원격 복제 작업 중에 클러스터에서 쓴 증분 데이터를 계속 가져옵니다.
부트 노드의 바이너리 로그에서 상태를 전송하는 동안 새로 가입한 노드는 부팅 노드의 바이너리 로그에서 필요한 트랜잭션을 복사하여 적용하고 새로 가입한 노드가 클러스터에 가입했음을 바이너리 로그에 기록할 때까지 수신된 트랜잭션을 적용합니다. (참여 노드가 클러스터에 성공적으로 합류하면 해당 뷰 변경 이벤트가 바이너리 로그에 기록됩니다.) 이 과정에서 합류 노드는 클러스터에 적용되는 새로운 트랜잭션 데이터를 버퍼링합니다. 바이너리 로그의 상태 전송이 완료된 후 새로 합류하는 노드는 버퍼링된 트랜잭션을 적용합니다.
참여 노드가 클러스터에 대한 모든 트랜잭션을 포함하여 최신 상태가 되면 해당 노드는 온라인으로 설정되고 일반 노드로 클러스터에 조인할 수 있으며 분산 복구가 완료됩니다.
ps: 바이너리 로그의 상태 전송은 그룹 복제를 사용한 분산 복구의 기본 메커니즘이며 복제 그룹의 부팅 노드와 조인 노드가 복제를 지원하도록 설정되지 않은 경우입니다. 바이너리 로그로부터의 상태 전송은 클래식 비동기식 복제를 기반으로 하기 때문에 클러스터에 참여하는 MySQL 서버에 클러스터에 대한 데이터가 전혀 없거나 데이터가 아주 오래된 백업에서 가져온 경우 복구하는 데 오랜 시간이 걸릴 수 있습니다. . 최신 데이터. 따라서 이 경우 MySQL 서버를 클러스터에 추가하기 전에 이미 클러스터에 있는 노드의 최신 스냅샷을 전송하여 클러스터의 데이터로 설정하는 것이 좋습니다. 이는 분산 복구에 필요한 시간을 최소화하고 더 적은 수의 바이너리 로그 파일을 유지하고 전송해야 하는 부트 노드에 대한 영향을 줄입니다.
분산 복구 중 상태 전달을 위해 합류 노드가 기존 노드의 부트스트랩 노드에 연결될 때 합류 노드는 클라이언트 역할을 하고, 부트스트랩 노드는 서버 역할을 합니다. 이 연결을 통해 부트 노드의 바이너리 로그에서 상태 전송이 발생하면(비동기 복제 채널 GroupReplicationRecovery 사용) 결합 노드는 복제본 역할을 하고 부트 노드는 소스 역할을 합니다. 이 연결을 통해 원격 복제 작업을 수행하면 새로 추가된 노드는 전체 데이터 수신자 역할을 하고 부트 노드는 전체 데이터 공급자 역할을 합니다. 그룹 복제 컨텍스트 외부의 역할에 적용되는 구성 설정은 그룹 복제 관련 구성 설정 또는 동작에 의해 재정의되지 않는 한 그룹 복제에도 적용됩니다.
분산 복구를 위해 기존 노드에서 새로 가입한 노드에 제공하는 연결은 그룹 복제가 클러스터 내 노드 간 통신에 사용하는 연결과 다릅니다.
그룹 통신 엔진은 그룹 복제(XCom, Paxos 변종)에 사용되며, 원격 XCom 인스턴스 간의 TCP 통신에 사용되는 연결은 groupreplicationlocal_address 시스템 변수에 의해 지정됩니다. 이 연결은 클러스터 내 온라인 노드 간의 TCP/IP 메시징에 사용됩니다. 로컬 인스턴스와의 통신은 메모리 내 공유 전송 채널을 통해 이루어집니다.
분산 복구의 경우 MySQL8.0.20까지 클러스터 내의 노드는 MySQL 서버의 호스트 이름 및 포트 시스템 변수에 지정된 대로 조인 노드에 대한 표준 SQL 클라이언트 연결을 제공했습니다. report_port 시스템 변수가 대체 포트 번호를 지정하는 경우 해당 포트 번호가 대신 사용됩니다.
MySQL 8.0.21부터 그룹 구성원은 분산 복구 끝점의 대체 목록을 참여 구성원의 개인 클라이언트 연결로 사용할 수 있으므로 구성원의 일반 클라이언트 사용자와 독립적인 연결을 사용하여 분산 복구를 제어할 수 있습니다. 이 목록은 groupReplicationAdvertiseRecoveryEndpoints 시스템 변수를 사용하여 지정할 수 있으며, 구성원은 그룹에 가입할 때 분산 복구 끝점 목록을 그룹으로 전송합니다. 기본값은 구성원이 이전 버전과 동일한 표준 SQL 클라이언트 연결을 계속 제공하는 것입니다.
PS:
조인 노드가 MySQLServer의 시스템 변수에 정의된 호스트 이름을 사용하여 다른 노드를 올바르게 식별할 수 없는 경우 분산 복구가 실패할 수 있습니다. MySQL을 실행하는 운영 체제에는 DNS 또는 로컬 설정을 사용하여 올바르게 구성된 고유 호스트 이름이 있는 것이 좋습니다. SQL 클라이언트 연결을 위해 서버에서 사용하는 호스트 이름은 "performanceschema" 라이브러리 아래에 있는 ReplicationgroupMembers 테이블의 Memberhost 열에서 확인할 수 있습니다. 여러 그룹 구성원이 운영 체제에서 설정한 기본 호스트 이름을 외부화하는 경우 참여하는 노드가 이를 올바른 주소로 확인하지 못하고 분산 복구를 위해 연결할 수 없게 될 가능성이 있습니다. 이 경우 MySQL 서버의 report_host 시스템 변수를 사용하여 각 서버에서 외부화하는 고유한 호스트 이름을 구성할 수 있습니다.
분산 복구를 위한 연결을 설정하기 위해 노드에 가입하는 단계는 다음과 같습니다.
노드가 클러스터에 가입하면 groupreplicationgroupseeds 시스템 변수 목록에 포함된 시드 노드 중 하나를 사용하여 연결합니다. 해당 목록에 지정된 groupreplicationlocaladdress를 사용합니다. 시드 노드는 클러스터 데이터의 하위 집합일 수 있습니다.
이 연결을 통해 시드 노드는 그룹 복제의 멤버십 서비스를 사용하여 가입 노드에 클러스터 내 모든 온라인 노드 목록을 뷰 형태로 제공합니다. 멤버쉽 정보에는 분산 복구를 위해 각 멤버가 제공하는 분산 복구 끝점 또는 표준 SQL 클라이언트 연결에 대한 세부 정보가 포함됩니다.
Join 노드는 분산 복구를 위한 부팅 노드로 이 목록에서 적합한 온라인 노드를 선택합니다.
Join 노드는 부팅 노드의 분산 복구 끝점을 사용하여 부팅 노드에 연결을 시도하고 지정된 순서대로 각 노드에 차례로 연결을 시도합니다. 목록 끝점에서. 부트 노드가 엔드포인트를 제공하지 않는 경우 참여 노드는 부트 노드의 표준 SQL 클라이언트 연결을 사용하여 연결을 시도합니다. 연결에 대한 SSL 요구 사항은 groupreplicationrecoveryssl* 옵션에 의해 지정됩니다.
참여 노드가 지정된 부트스트랩 노드에 연결할 수 없는 경우 다른 적합한 부트스트랩 노드와의 연결을 다시 시도합니다. 참여 노드가 연결을 설정하지 않고 엔드포인트의 브로드캐스트 목록을 모두 소모하는 경우 부트 노드의 표준 SQL 클라이언트 연결로 대체되지 않고 대신 다른 부트 노드로 전환하여 연결 재설정을 시도합니다.
참여 노드가 부트 노드와 분산 복구 연결을 설정하면 해당 연결을 상태 전송에 사용합니다. 참여 노드의 로그에는 사용된 연결의 호스트와 포트가 표시됩니다. 원격 복제 작업을 사용하는 경우 작업이 끝날 때 조인 노드가 다시 시작되면 새 부팅 노드와 연결을 설정하고 부팅 노드의 바이너리 로그에서 상태 전송을 수행합니다. 이는 원격 복제 작업에 사용되는 부팅 노드와 다른 연결이거나 부팅 노드와 동일한 연결일 수 있습니다. 그럼에도 불구하고 분산 복구는 동일한 방식으로 부트 노드에 대한 연결을 설정합니다.
groupreplicationadvertiserecoveryendpoints 시스템 변수는 분산 복구 끝점에서 제공하는 IP 주소 역할을 하며 MySQL Server에 대해 구성할 필요가 없습니다(즉, adminaddress 시스템에서 지정할 필요가 없습니다). 변수 또는 바인드 주소 시스템 변수 목록).
MySQL Server의 분산 복구 목적으로 제공되는 포트를 구성합니다. 이 포트는 port, reportport 또는 adminport 시스템 변수로 지정해야 합니다. TCP/IP 연결은 이 포트에서 수신되어야 합니다. adminport가 지정된 경우 분산 복구에 사용되는 복제 사용자가 연결하려면 SERVICECONNECTIONADMIN 권한이 필요합니다. adminport를 선택하면 일반 MySQL 클라이언트 연결과 별도로 분산 복구 연결이 유지됩니다.
Join 노드는 목록에 지정된 순서대로 각 엔드포인트를 차례로 시도합니다. groupreplicationadvertiserecoveryendpoints가 엔드포인트 목록 대신 DEFAULT로 설정된 경우 표준 SQL 클라이언트 연결이 제공됩니다. 표준 SQL 클라이언트 연결은 분산 복구 끝점 목록에 자동으로 포함되지 않으며 연결 없이 부트 노드의 끝점 목록이 소진되는 경우 백업으로 사용되지 않습니다. 표준 SQL 클라이언트 연결을 여러 분산 복구 끝점 중 하나로 제공하려면 이를 groupreplicationadvertiseadvertiserecovery_endpoints에서 지정한 목록에 명시적으로 포함해야 합니다. 최후의 수단으로 연결하기 위해 이것을 마지막에 넣을 수 있습니다.
그룹 구성원의 분산 복구 엔드포인트(또는 엔드포인트가 제공되지 않은 경우 표준 SQL 클라이언트 연결)를 groupreplicationipallowlist(MySQL 8.0.22부터) 또는 groupreplicationipwhitelist 시스템 변수로 지정된 그룹 복제 허용 목록에 추가할 필요가 없습니다. 권한 목록은 각 노드에 대해 groupreplicationlocal_address로 지정된 주소에만 적용됩니다. 분산 복구를 위해 하나 이상의 주소를 검색하려면 참여 노드에 허용 목록에서 허용하는 클러스터에 대한 초기 연결이 있어야 합니다.
시스템 변수를 설정하고 STARTGROUP_REPLICATION 문을 실행하면 나열된 분산 복구 엔드포인트가 확인됩니다. 목록을 올바르게 구문 분석할 수 없거나 서비스가 목록을 수신하지 않아 호스트에서 끝점에 도달할 수 없는 경우 그룹 복제는 오류를 기록하고 시작되지 않습니다.
MySQL 8.0.18에는 부트 노드 바이너리 로그의 상태 전송 방법을 사용하여 분산 복구를 위한 압축을 구성하는 옵션이 있습니다. 압축은 네트워크 대역폭이 제한되어 있고 리더 노드가 합류 노드에 많은 트랜잭션을 전송해야 하는 상황에서 분산 복구에 도움이 될 수 있습니다. groupreplicationrecoverycompression 알고리즘 및 groupreplicationrecoveryzstdcompression_level 시스템 변수는 부트 노드의 바이너리 로그에서 상태 전송을 수행할 때 사용되는 허용되는 압축 알고리즘 및 zstd 압축 수준을 구성합니다.
이러한 압축 설정은 원격 복제 작업에는 적용되지 않습니다. 분산 복구에 원격 복제 작업을 사용하는 경우 복제 플러그인의 cloneenablecompression 설정이 적용됩니다.
분산 복구에는 그룹 복제가 직접 노드 간 복제 채널을 설정할 수 있도록 올바른 권한이 있는 복제 사용자가 필요합니다. 복제 사용자에게도 올바른 권한이 있어야 합니다. 복제 사용자가 원격 복제 작업에서 복제 사용자 역할도 하는 경우, 복제 사용자는 복제 역할을 하려면 부트 노드에서 원격 복제 관련 권한(BACKUP_ADMIN 권한)도 가지고 있어야 합니다. 원격 복제 작업을 위해 사용자를 복제합니다. 또한 클러스터 내의 모든 노드에서 분산 복구를 위해 동일한 복제 사용자를 사용해야 합니다.
분산 복구에 사용되는 SSL은 일반 그룹 통신에 사용되는 SSL과 별도로 구성되며, 이는 서버의 SSL 설정 및 groupreplicationssl_mode 시스템 변수에 의해 결정됩니다. 분산 복구 연결의 경우 전용 그룹 복제 분산 복구 SSL 시스템 변수를 사용하여 특히 분산 복구를 위한 인증서 및 키 사용을 구성할 수 있습니다.
기본적으로 SSL은 분산 복구 연결에 사용되지 않습니다. groupreplicationrecoveryusessl=ON을 설정하여 활성화한 다음 그룹 복제 분산 복구 SSL 시스템 변수를 구성하고 복제 사용자가 SSL을 사용하도록 설정합니다.
SSL을 사용하도록 분산 복구를 구성하면 그룹 복제는 이 설정을 원격 복제 작업 및 부트 노드 바이너리 로그의 상태 전송에 적용합니다. 그룹 복제는 해당 그룹 복제 분산 복구 옵션(groupreplicationrecoverysslca, groupreplicationrecoverysslcert 및 groupreplicationrecoverysslkey)의 설정과 일치하도록 복제 SSL 옵션(clonesslca, clonesslcert 및 clonesslkey)을 자동으로 구성합니다.
분산 복구에 SSL을 사용하지 않고(groupreplicationrecoveryusessl이 OFF로 설정됨) 그룹 복제를 위한 복제 사용자 계정이 cachingsha2password 플러그인(MySQL 8.0의 기본값) 또는 sha256password 플러그인을 사용하여 인증되는 경우 RSA 키 쌍이 사용됩니다. 교환. 이 경우, groupreplicationrecoverypublickeypath 시스템 변수를 사용하여 RSA 공개 키 파일을 지정하거나, groupreplicationrecoverygetpublic_key 시스템 변수를 사용하여 공개 키를 요청하십시오. 그렇지 않으면 오류 보고로 인해 배포된 응답 전체가 실패하게 됩니다.
MySQLServer용 복제 플러그인은 MySQL8.0.17부터 사용할 수 있습니다. 클러스터의 분산 복구를 위해 원격 복제 작업을 사용하려면 이 기능을 지원하도록 기존 노드와 조인 노드를 사전 프로비저닝해야 합니다. 클러스터에서 이 기능을 사용하지 않으려면 이를 설정하지 마십시오. 이 경우 그룹 복제는 바이너리 로그의 상태 전송만 사용합니다.
복제 플러그인을 사용하려면 하나 이상의 기존 클러스터 노드와 가입 노드가 원격 복제 작업을 지원하도록 사전 설정되어 있어야 합니다. 최소한 부팅 및 조인 노드에 복제 플러그인을 설치해야 하며, 분산 복구를 위해 복제 사용자에게 BACKUPADMIN 권한을 부여해야 하며, groupreplicationclonethreshold 시스템 변수를 적절한 수준으로 설정해야 합니다. (기본적으로 GTID 시퀀스에서 허용하는 최대값인데, 이는 조이너 노드가 요청한 트랜잭션이 그룹의 어느 멤버에도 존재하지 않는 한 일반적인 상황에서는 항상 바이너리 로그 기반의 상태 전송이 선호된다는 의미입니다. 이때, 복제 기능이 비활성화된 경우 시스템 변수에 어떤 값을 설정하더라도 복제를 통한 분산 복구가 실행됩니다. 예를 들어 새로 초기화된 서버가 그룹 가입을 신청하는 경우. 복제 기능을 사용하지 않으려면 설치하지 마세요.) 부트 노드의 최대 가용성을 보장하려면 현재 및 미래의 모든 클러스터 노드가 원격 복제 작업을 지원하도록 설정하는 것이 좋습니다. 따라서 나중에 서버가 클러스터에 합류할 때 원격 복제 작업을 사용하여 클러스터의 최신 데이터를 빠르게 따라잡을 수 있습니다.
원격 복제 작업은 부팅 노드에서 조인 노드로 데이터를 전송하기 전에 조인 노드에서 사용자가 생성한 테이블스페이스와 데이터를 삭제합니다. 작업이 도중에 예기치 않게 종료되면 합류하는 노드에 데이터가 일부만 남거나 전혀 남지 않을 수 있습니다. 이 문제는 그룹 복제가 자동으로 수행하는 원격 복제 작업을 다시 수행하여 해결할 수 있습니다.
주로 원격 복제 시 DATADIRECTORY 하위 옵션을 사용하여 데이터 저장 경로를 지정한 경우에 해당됩니다. 해당 경로를 지정하면 지정된 디렉터리에 데이터가 저장됩니다. 즉, 복제 후 데이터는 저장되지 않습니다. 복제가 수행되는 인스턴스와 관련되어 수동으로 시작해야 하는 경우 인스턴스를 시작하고 복제 데이터가 저장되는 디렉터리에 datadir을 지정하면 MGR 플러그인이 자동으로 원격 복제 작업을 수행할 수 있습니다. (복제 작업 시 DATA DIRECTORY 하위 옵션이 지정되지 않았는지 확인해야 합니다. 이 경우 원격 복제 데이터를 덮어쓰게 됩니다. 원격 복제된 서버의 데이터를 조작합니다. 원격 복제 작업이 완료된 후 원격 복제된 서버는 복제된 데이터를 기반으로 자동으로 다시 시작됩니다). 또한 복제 플러그인을 그룹 복제와 함께 사용하여 그룹 복제의 관리 및 유지 관리를 더욱 자동화하지만 복제 플러그인을 클러스터에서 실행할 필요는 없습니다(그러나 MGR 플러그인은 설치해야 합니다.)
그룹 복제의 경우 분산 복구용 복제 플러그인을 사용할 때 다음 사항과 차이점에 주의해야 합니다.
기존 클러스터 노드와 합류 노드에는 복제 플러그인이 설치 및 활성화되었습니다.
부트 노드와 조인 노드는 동일한 운영 체제에서 실행되어야 하며 동일한 MySQL Server 버전을 가지고 있어야 합니다(복제 플러그인을 지원하려면 MySQL 8.0.17 이상이어야 함). 따라서 구성원이 다른 버전의 MySQL을 실행하는 클러스터에서는 복제가 작동하지 않습니다.
부트 노드와 조인 노드에는 "그룹 복제" 플러그인이 설치 및 활성화되어 있어야 하며, 부트 노드에서 활성화된 다른 모든 플러그인(예: 키링 플러그인)도 조인 노드에서 활성화되어야 합니다.
SSL(groupreplicationrecoveryusessl=ON)을 사용하도록 분산 복구가 구성된 경우 그룹 복제는 이 설정을 원격 복제 작업에 적용합니다. 그룹 복제는 해당 그룹 복제 분산 복구 옵션(groupreplicationrecoverysslca, groupreplicationrecoverysslcert 및 groupreplicationrecoverysslkey)의 설정과 일치하도록 복제 SSL 옵션(clonesslca, clonesslcert 및 clonesslkey)의 설정을 자동으로 구성합니다.
클러스터에 가입하기 위해 가입 노드의 clonevaliddonor_list 시스템 변수에 유효한 부팅 노드 목록을 설정할 필요가 없습니다. 그룹 복제는 MGR이 기존 클러스터 노드에서 부팅 노드를 자동으로 선택한 후 자동으로 이 설정을 구성합니다. 원격 복제 작업에서는 클러스터 멤버 간 내부 통신을 위한 주소와 포트가 아닌 서버의 SQL 프로토콜 호스트 이름과 포트를 사용합니다.
복제 플러그인에는 원격 복제 작업의 네트워크 로드 및 성능 영향을 관리하기 위한 다양한 시스템 변수가 있습니다. 이러한 설정은 그룹 복제로 구성되지 않으므로 이를 검토하여 필요한 경우 설정하거나, 분산 복구를 위해 원격 복제 작업을 사용할 때 복제 플러그인의 cloneenablecompression 설정이 적용됩니다. 대신 기존에 구성된 그룹 복제 압축 설정에 영향을 미칩니다.
조인된 노드에서 원격 복제 작업을 호출하기 위해 그룹 복제는 이미 CLONE_ADMIN 권한이 있는 내부 mysql.session 사용자를 사용하므로 특별한 설정이 필요하지 않습니다.
원격 복제 작업을 위한 부팅 노드의 복제 사용자로서 그룹 복제는 분산 복구를 위해 설정된 복제 사용자를 사용합니다. 따라서 이 복제 사용자에게는 모든 복제 가능 클러스터 노드에 대한 BACKUP_ADMIN 권한이 부여되어야 합니다. 그룹 복제를 위한 노드를 구성할 때 조인 노드가 있는 경우 조인 노드가 클러스터에 조인한 후 다른 조인 노드에 대한 부팅 노드 역할을 할 수 있으므로 해당 노드의 복제 사용자에게도 이 권한을 부여해야 합니다. 각 클러스터 노드의 분산 복구에는 동일한 복제 사용자가 사용됩니다. 기존 노드의 복제 사용자에게 이 권한을 부여하려면 바이너리 로깅이 비활성화된 각 클러스터 노드 또는 바이너리 로깅이 활성화된 클러스터의 기본 노드에서 이 명령문을 개별적으로 실행합니다.
GRANT BACKUP_ADMIN ON *.* TO *rpl_user*@'%';
STARTGROUPREPLICATION을 사용하기 전에 CHANGE MASTER TO를 사용하여 사용자 자격 증명을 제공한 서버에서 복제 사용자 자격 증명을 지정한 경우 원격 복제 작업을 수행하기 전에 복제 메타데이터 저장소에서 사용자 자격 증명을 삭제해야 합니다. 또한 참여하는 구성원에 groupreplicationstartonboot=OFF가 설정되어 있는지 확인하세요. 사용자 자격 증명이 설정 해제되지 않으면 원격 복제 작업 중에 참여하는 구성원에게 전송됩니다. 그러면 원래 구성원이나 복제된 구성원에 저장된 자격 증명을 사용하여 GroupReplicationRecovery 채널이 실수로 시작될 수 있습니다. 서버가 시작될 때(원격 복제 작업 이후 포함) 자동으로 그룹 복제를 시작하면 저장된 사용자 자격 증명이 사용되며, START GROUPREPLICATION 명령에 지정되지 않은 경우 분산 복구 자격 증명도 사용됩니다.
복제를 지원하도록 그룹 구성원을 설정한 후, groupreplicationclonethreshold 시스템 변수는 분산 복구에서 원격 복제 작업을 사용할 트랜잭션 수로 표시되는 임계값을 지정합니다. 부트스트랩 노드와 조인 노드 간의 트랜잭션 수가 이 수보다 큰 경우, 기술적으로 가능한 경우 원격 복제 작업을 사용하여 상태를 조인 노드로 전송합니다. 그룹 복제는 기존 그룹 구성원의 gtidexecuted 세트를 기반으로 임계값이 초과되었는지 여부를 계산합니다. 트랜잭션 격차가 클 때 원격 복제 작업을 사용하면 클러스터의 데이터를 미리 서버에 수동으로 전송할 필요 없이 새 구성원을 클러스터에 추가할 수 있으며 지연 노드가 데이터를 보다 효율적으로 따라잡을 수도 있습니다.
groupreplicationclone_threshold 그룹 복제 시스템 변수의 기본 설정은 매우 높으므로(GTID에서 허용되는 최대 트랜잭션 시퀀스 수), 바이너리 로그에서 상태를 전송할 수 있을 때마다 복제를 효과적으로 비활성화합니다. 상태 전송에 더 적합한 원격 복제 작업을 선택하기 위해 그룹 복제를 활성화하려면 복제를 위한 트랜잭션 간격으로 사용해야 하는 트랜잭션 수를 지정하는 시스템 변수를 설정합니다.
PS:
활성 클러스터에서 groupreplicationclone_threshold에 대해 더 낮은 설정을 사용하지 마십시오. 원격 복제 작업이 진행되는 동안 클러스터에서 임계값 이상의 트랜잭션이 발생하는 경우 참여하는 구성원은 다시 시작한 후 원격 복제 작업을 다시 트리거하고 무기한 계속할 수 있습니다. 이를 방지하려면 원격 복제 작업이 수행되는 기간 동안 클러스터에서 발생할 것으로 예상되는 트랜잭션 수보다 큰 신뢰할 수 있는 숫자로 임계값을 설정해야 합니다.
부트 노드의 바이너리 로그에서 상태 이전을 할 수 없는 경우 그룹 복제는 당시 임계값에 관계없이 원격 복제 작업을 수행하려고 시도합니다. 예를 들어 구성원 가입에 필요한 트랜잭션이 모든 노드의 바이너리 로그에 있기 때문입니다. 기존 그룹 구성원 없음을 사용할 수 있습니다. 그룹 복제는 기존 그룹 구성원의 gtidpurged 세트를 기반으로 이를 식별합니다. 멤버의 바이너리 로그 파일에서 필요한 트랜잭션을 사용할 수 없는 경우 groupreplicationclonethreshold 시스템 변수를 사용하여 복제를 비활성화할 수 없습니다. 이 경우 복제는 데이터를 조인 노드에 수동으로 전송하는 유일한 옵션이기 때문입니다.
클러스터 노드를 설정하고 복제를 위해 노드를 결합한 후 그룹 복제는 원격 복제 작업을 관리합니다. 원격 복제 작업은 데이터 크기에 따라 완료하는 데 다소 시간이 걸립니다.
performancechema.cloneprogress 테이블은 전체 복제 작업의 각 단계와 해당 단계 정보를 기록합니다. 각 단계는 레코드 행을 생성합니다(이 테이블은 하나의 복제 작업의 프로세스 정보만 기록한다는 점에 유의하세요. 수행되면 마지막 정보가 덮어쓰여집니다)
select * from clone_progress; +------+-----------+-----------+---------------------------- +----------------------------+---------+------------+-------- ----+------------+------------+---------------+ | ID | STAGE | STATE | BEGIN_TIME | END_TIME | THREADS | ESTIMATE | DATA | NETWORK | DATA_SPEED | NETWORK_SPEED | +------+-----------+-----------+---------------------------- +----------------------------+---------+------------+------- -----+------------+------------+---------------+ | 1 | DROP DATA | Completed | 2019-10-08 16:46:58.757964 | 2019-10-08 16:46:59.128436 | 1 | 0 | 0 | 0 | 0 | 0 | | 1 | FILE COPY | Completed | 2019-10-08 16:46:59.128766 | 2019-10-08 16:47:16.857536 | 8 | 8429731840 | 8429731840 | 8430190882 | 0 | 0 | | 1 | PAGE COPY | Completed | 2019-10-08 16:47:16.857737 | 2019-10-08 16:47:17.159531 | 8 | 0 | 0 | 785 | 0 | 0 | | 1 | REDO COPY | Completed | 2019-10-08 16:47:17.159748 | 2019-10-08 16:47:17.460516 | 8 | 2560 | 2560 | 3717 | 0 | 0 | | 1 | FILE SYNC | Completed | 2019-10-08 16:47:17.460788 | 2019-10-08 16:47:20.926184 | 8 | 0 | 0 | 0 | 0 | 0 | | 1 | RESTART | Completed | 2019-10-08 16:47:20.926184 |
| 1 | RESTART | Completed | 2019-10-08 16:47:20.926184 | 2019-10-08 16:47:28.623732 | 0 | 0 | 0 | 0 | 0 | 0 | | 1 | RECOVERY | Completed | 2019-10-08 16:47:28.623732 | 2019-10-08 16:47:34.898453 | 0 | 0 | 0 | 0 | 0 | 0 | +------+-----------+-----------+---------------------------- +----------------------------+---------+------------+------- -----+------------+------------+---------------+ 7 rows in set (0.00 sec) select * from clone_status\G *************************** 1. row *************************** ID: 1 PID: 0 STATE: Completed BEGIN_TIME: 2019-10-08 16:46:58.758 END_TIME: 2019-10-08 16:47:34.898 SOURCE: 10.10.30.162:3306 DESTINATION: LOCAL INSTANCE ERROR_NO: 0 ERROR_MESSAGE: BINLOG_FILE: mysql-bin.000022 BINLOG_POSITION: 222104704 GTID_EXECUTED: 320675e6-de7b-11e9-b3a9-5254002a54f2:1-4, aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-2771494 1 row in set (0.01 sec)
PS:
상태 전송이 완료된 후 그룹 복제는 조인 노드를 다시 시작하여 프로세스를 완료합니다. 예를 들어 복제 사용자 자격 증명이 START GROUPREPLICATION 문에 지정되었기 때문에 조인 노드에 groupreplicationstartonboot=OFF가 설정된 경우 다시 시작한 후 START GROUPREPLICATION을 수동으로 다시 게시해야 합니다. groupreplicationstartonboot=ON이고 그룹 복제를 시작하는 데 필요한 기타 설정이 구성 파일에 설정되어 있거나 SET PERSIST 문을 사용하는 경우 프로세스는 개입 없이 온라인으로 조인 노드를 자동으로 계속합니다.
원격 복제 작업은 부팅 노드의 데이터 디렉터리에 있는 다양한 데이터 파일을 조인 노드에 복제합니다(테이블에는 일부 구성 정보 및 사용자 데이터 등이 포함될 수 있음). 그러나 구성 파일에 저장된 그룹 복제 구성원 설정(예: 그룹 복제 로컬 주소 구성 등)은 복제되지 않으며 가입 노드에서 변경 사항도 적용되지 않습니다. 즉, 그룹 복제와 관련된 구성은 직접 구성해야 하며 클러스터의 기존 구성원과 충돌할 수 없습니다. 원격 복제 작업은 데이터 파일 복제만 담당하고 구성 정보는 복제하지 않습니다(물론 일부 구성 정보가 있는 경우). 테이블에 저장되며, 복제 작업의 경우 데이터로도 복제됩니다.
如果远程克隆过程花费很长时间，则在MySQL 8.0.22之前的发行版中，在该时间段内为该集群累积的一组认证信息可能会变得太大而无法传输给加入成员。在这种情况下，加入成员会记录一条错误消息，并且不会加入该集群。从MySQL 8.0.22开始，组复制以不同的方式管理应用事务的垃圾收集过程，以避免发生这种情况。在早期版本中，如果确实看到此错误，则在远程克隆操作完成之后，请等待两分钟，以允许进行一轮垃圾收集，以减小集群的认证信息的大小。然后在加入成员上发出以下声明，以使其停止尝试应用先前的认证信息集：
RESET SLAVE FORCHANNEL group_replication_recovery; RESET REPLICA FOR CHANNEL group_replication_recovery;（从8.0.22开始）
引导节点中用于组复制专用通道groupreplicationrecovery的用户凭证（复制用户和密码），在克隆操作完成之后，会被新成员使用，所以，该用户和密码及其权限必须在新成员中也有效。因此，所有组成员才能够使用相同的复制用户和密码通过远程克隆操作接收状态传输进行分布式恢复。但是，组复制会保留与使用SSL相关的组复制通道设置，这些设置对单个成员来说可以是惟一的（即，每个组成员使用不同的复制用户和密码）。如果使用了PRIVILEGECHECKSUSER帐户来帮助保护复制应用线程（从MySQL8.0.18开始，可以创建一个具有特定权限的用户账号，然后将其指定为PRIVILEGECHECKSUSER帐户，这样可以防止将未经授权或意外将具有特权的账号用于组复制通道），则在克隆操作完成之后新加入成员不会使用该用户帐户作为组复制通道的用户。此时必须为组复制通道手工指定合适的复制用户。
如果引导节点用于groupreplicationrecovery复制通道的复制用户凭据已使用CHANGE MASTER TO语句存储在复制元数据存储库中，则在克隆后将它们转移到加入成员并由其使用，并且它们在此处必须有效。因此，使用存储的凭据，所有通过远程克隆操作接收状态转移的组成员都会自动接收复制用户和密码，进行分布式恢复。如果在START GROUPREPLICATION语句上指定了复制用户凭据，则这些凭据将用于启动远程克隆操作，但是在克隆后它们不会传输到加入节点并由其使用。如果不希望将凭据转移到新的server上并记录在那里，确保在进行远程克隆操作之前取消设置它们，并使用START GROUPREPLICATION代替提供它们。
ps:如果已使用PRIVILEGECHECKSUSER帐户来帮助保护复制应用程序，则从MySQL 8.0.19开始，会将PRIVILEGECHECKSUSER帐户以及来自引导节点的相关设置克隆出来。如果将加入节点设置为在启动时启动组复制，它将自动使用该帐户在相应的复制通道上进行权限检查。（在MySQL 8.0.18中，由于许多限制，建议不要将PRIVILEGECHECKSUSER帐户用于组复制通道。）
组复制启动并管理用于分布式恢复的克隆操作。设置为支持克隆的组成员也可以参与用户手动启动的克隆操作。例如，可能希望通过从组成员作为引导节点来进行克隆来创建新的MySQL实例，但是不希望新的服务器实例立即加入或可能永远不会加入该集群。
在所有支持克隆的发行版中，可以手动启动涉及停止了组复制的组成员的克隆操作。由于克隆要求引导节点和接收数据的节点上的克隆插件必须匹配，因此即使不希望该实例加入集群，也必须在另一个实例上安装并激活组复制插件。可以通过发出以下语句来安装插件：
INSTALL PLUGIN group_replication SONAME'group_replication.so';
在MySQL 8.0.20之前的发行版中，如果操作涉及正在运行“组复制”的组成员，则无法手动启动克隆操作。从MySQL8.0.20开始，只要克隆操作不会删除和替换接收者上的数据，就可以执行此操作。因此，如果正在运行组复制，则用于启动克隆操作的语句必须包含DATA DIRECTORY子句。
위 내용은 MySQL 분산 복구 인스턴스 분석의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
