고가용성은 Azure Database for MySQL의 주요 기능으로, 가동 중지 시간을 최소화하고 계획된 유지 관리 또는 예기치 않은 중단 중에도 애플리케이션에 계속 액세스할 수 있도록 설계되었습니다. 이 문서에서는 Azure에서 MySQL 워크로드에 대한 정보에 입각한 의사 결정을 내리는 데 도움이 되는 HA(고가용성) 옵션, 청구, 장애 조치 프로세스, 성능 영향 및 모범 사례에 대한 일반적인 질문을 다룹니다.
로컬 중복 및 영역 중복 HA 지원 유연한 서버에 대한 SLA는 무엇인가요?
Azure Database for MySQL 유연한 서버에 대한 SLA 정보는 Azure Database for MySQL용 SLA에서 찾을 수 있습니다.
고가용성(HA) 서버에 대한 요금은 어떻게 청구하나요?
HA에서 사용하도록 설정된 서버에는 주 복제본과 보조 복제본이 있습니다. 보조 복제본은 동일한 영역 또는 영역 중복에 있을 수 있습니다. 주 복제본과 보조 복제본 모두에 대해 프로비전된 컴퓨팅 및 스토리지에 대한 요금이 청구됩니다. 예를 들어 4개의 컴퓨팅 vCore와 512GB의 프로비전된 스토리지가 있는 주 복제본이 있는 경우 보조 복제본에는 4개의 vCore와 512GB의 프로비전된 스토리지가 있습니다.
영역 중복 HA 서버는 8개의 vCore 및 1,024GB의 스토리지에 대해 요금이 청구됩니다. 백업 스토리지 볼륨에 따라 백업 스토리지에 대한 요금이 청구될 수도 있습니다.
읽기 또는 쓰기 작업에 대기 복제본을 사용할 수 있나요?
대기 서버는 읽기 또는 쓰기 작업에 사용할 수 없습니다. 빠른 장애 조치(failover)를 사용하도록 설정하는 수동 대기입니다.
장애 조치(failover)가 발생할 때 데이터가 손실되나요?
주 서버를 사용할 수 없는 경우에도 ZRS의 로그에 액세스할 수 있습니다. 이 가용성은 데이터 손실이 없도록 하는 데 도움이 됩니다. 대기 복제본이 활성화되고 이진 로그가 적용되면 주 서버의 역할을 합니다.
장애 조치(failover) 후 조치를 취해야 하나요?
장애 조치(failover)는 클라이언트 애플리케이션에서 완전히 투명합니다. 어떤 조치도 취할 필요가 없습니다. 애플리케이션은 연결에 재시도 논리만 사용해야 합니다.
대기 복제본에 대한 특정 영역을 선택하지 않으면 어떻게 되나요? 나중에 영역을 변경할 수 있나요?
영역을 선택하지 않으면 영역이 임의로 선택됩니다. 주 서버에 사용되는 서버입니다. 나중에 영역을 변경하려면 고가용성 창에서 고가용성을사용 안 함으로 설정한 다음 영역 중복으로 다시 설정하고 영역을 선택할 수 있습니다.
주 복제본과 대기 복제본 간의 복제가 동기적입니까?
주 모드와 대기 간의 복제는 MySQL의 반동기 모드 와 유사합니다. 트랜잭션이 커밋되면 반드시 대기에 커밋되지는 않습니다. 그러나 주 복제본을 사용할 수 없는 경우 대기는 주 데이터베이스의 모든 데이터 변경 내용을 복제하여 데이터 손실이 없도록 합니다.
계획되지 않은 모든 오류에 대해 대기 복제본에 대한 장애 조치(failover)가 있나요?
데이터베이스 충돌 또는 노드 오류가 발생하면 유연한 서버 VM이 동일한 노드에서 다시 시작됩니다. 동시에 자동 장애 조치(failover)가 트리거됩니다. 장애 조치(failover)가 완료되기 전에 유연한 서버 VM 다시 시작이 성공하면 장애 조치(failover) 작업이 취소됩니다. 주 복제본으로 사용할 서버의 결정은 먼저 완료되는 프로세스에 따라 달라집니다.
HA를 사용할 때 성능에 영향을 주나요?
영역 중복 HA의 경우 가용성 영역에서 읽기 워크로드에 대한 주요 성능 영향은 없지만 쓰기 쿼리 대기 시간이 최대 40% 감소할 수 있습니다. 쓰기 대기 시간의 증가는 가용성 영역 전체에서 동기 복제로 인해 발생합니다. 쓰기 대기 시간 영향은 동일한 영역 HA에 비해 영역 중복 HA에서 두 번입니다. 로컬 중복 HA의 경우 주 복제본과 대기 복제본이 동일한 영역에 있으므로 복제 대기 시간이 짧으므로 동기 쓰기 대기 시간이 낮습니다.
요약하자면, 쓰기 대기 시간이 가용성에 비해 더 중요한 경우 로컬 중복 HA를 선택할 수 있지만, 쓰기 대기 시간 감소로 데이터의 가용성 및 복원력이 더 중요한 경우 영역 중복 HA를 선택해야 합니다. HA 설정에서 대기 시간 감소의 정확한 영향을 측정하려면 워크로드에 대한 성능 테스트를 수행하여 정보에 입각한 결정을 내리는 것이 좋습니다.
HA 서버의 유지 관리는 어떻게 수행되나요?
컴퓨팅 및 부 버전 업그레이드의 크기 조정과 같은 계획된 이벤트는 먼저 원래 대기 인스턴스에서 수행된 다음 계획된 장애 조치(failover) 작업을 트리거한 다음 원래 주 인스턴스에서 작동합니다. 유연한 서버와 마찬가지로 HA 서버의 예약된 유지 관리 기간을 설정할 수 있습니다. 가동 중지 시간은 HA를 사용하지 않도록 설정한 경우 Azure Database for MySQL 유연한 서버 인스턴스의 가동 중지 시간과 동일합니다.
HA 서버의 PITR(지정 시간 복원)을 수행할 수 있나요?
HA 사용 Azure Database for MySQL 유연한 서버 인스턴스에 대한 PITR 을 HA를 사용하지 않도록 설정한 새 Azure Database for MySQL 유연한 서버 인스턴스로 수행할 수 있습니다. 원본 서버가 영역 중복 HA를 사용하여 만든 경우 나중에 복원된 서버에서 영역 중복 HA 또는 로컬 중복 HA를 사용하도록 설정할 수 있습니다. 원본 서버가 로컬 중복 HA를 사용하여 만든 경우 복원된 서버에서 로컬 중복 HA만 사용하도록 설정할 수 있습니다.
서버를 만든 후 서버에서 HA를 사용하도록 설정할 수 있나요?
서버를 만드는 동안 영역 중복 HA를 사용하도록 설정해야 합니다. 서버를 만든 후 로컬 중복 HA를 사용하도록 설정할 수 있지만 계속하기 전에 서버 매개 변수 enforce_gtid_consistency 및 gtid_mode 설정해야 합니다 ON .
서버를 만든 후 서버에 대해 HA를 사용하지 않도록 설정할 수 있나요?
서버에서 HA를 만든 후 사용하지 않도록 설정할 수 있습니다. 청구는 즉시 중지됩니다.
가동 중지 시간을 완화하려면 어떻게 해야 하나요?
HA를 사용하지 않는 경우에도 애플리케이션의 가동 중지 시간을 완화할 수 있어야 합니다. 예약된 패치, 부 버전 업그레이드 또는 컴퓨팅 크기 조정과 같은 고객이 시작한 작업과 같은 서비스 가동 중지 시간은 예약된 유지 관리 기간 동안 수행할 수 있습니다. Azure에서 시작한 유지 관리 작업에 대한 애플리케이션 영향을 완화하기 위해 요일 및 시간에 예약하여 애플리케이션에 미치는 영향을 최소화할 수 있습니다.
HA 사용 서버에 읽기 복제본을 사용할 수 있나요?
예, 읽기 복제본은 HA 서버에 대해 지원됩니다.
HA 서버에 대해 데이터 인 복제를 사용할 수 있나요?
HA(고가용성) 사용 서버에 대한 데이터 인 복제 지원은 GTID 기반 복제를 통해서만 사용할 수 있습니다.
GTID를 사용한 복제 저장 프로시저는 이름으로 mysql.az_replication_with_gtid모든 HA 사용 서버에서 사용할 수 있습니다.
가동 중지 시간을 줄이기 위해 서버를 다시 시작하는 동안 또는 확장 또는 축소하는 동안 대기 서버로 장애 조치(failover)할 수 있나요?
현재 Azure Database for MySQL 유연한 서버는 계획된 장애 조치(Failover)를 활용하여 스케일 업/다운을 비롯한 HA 작업을 최적화하고 가동 중지 시간을 줄이는 데 도움이 되는 계획된 유지 관리를 사용하고 있습니다.
이러한 작업이 시작되면 먼저 원래 대기 인스턴스에서 작동한 다음 계획된 장애 조치(failover) 작업을 트리거한 다음 원래 주 인스턴스에서 작동합니다.
서버의 가용성 모드(영역 중복 HA/로컬 중복)를 변경할 수 있나요**
영역 중복 HA 모드를 사용하도록 설정된 서버를 만드는 경우 영역 중복 HA에서 로컬 중복으로, 그 반대로 변경할 수 있습니다.
가용성 모드를 변경하려면 고가용성 창에서 고가용성을사용 안 함으로 설정한 다음 다시 영역 중복 또는 로컬 중복으로 설정하고 고가용성 모드를 선택할 수 있습니다.