페일오버
장애 조치는 원래 주 클러스터를 완전히 사용할 수 없을 때 대기 클러스터를 독립형 주 클러스터로 승격시킵니다. 이 작업은 가용성을 우선시하는 작업이며 장애 전에 복제되지 않은 데이터가 손실될 수 있습니다.
이 가이드에서는 원래 토폴로지가 그대로 유지된다고 가정합니다:
cluster-a (primary) -> cluster-b (standby)
장애 조치 후에는 cluster-b 이 독립 실행형 기본값이 됩니다:
cluster-b (primary)
장애 조치 사용 시기
장애 조치는 다음과 같은 경우에만 사용하세요:
- 원래 기본값이 요청에 응답할 수 없는 경우.
- 허용 가능한 시간 내에 기본 계정을 복구할 수 없는 경우.
- 쓰기 가용성을 복원하는 것이 이전 기본값을 기다리는 것보다 더 중요합니다.
기본값에 여전히 연결할 수 있는 경우에는 대신 전환을 사용하세요. 전환을 사용하면 데이터 손실을 방지할 수 있습니다.
데이터 손실 위험
장애 조치는 원래 기본값을 기다리지 않습니다. 이전 기본 계정에 기록되었지만 아직 대기 계정에 복제되지 않은 모든 데이터가 손실될 수 있습니다.
데이터 손실 가능성은 기본 데이터를 사용할 수 없게 된 시점의 CDC 지연에 따라 결정됩니다.
장애 조치를 실행하기 전에 장단점을 이해하세요:
| 목표 | 전환 | 장애 조치 |
|---|---|---|
| 프라이머리에 연결할 수 없는 동안 쓰기 복원 | 아니요 | 예 |
| 데이터 손실 방지 | 예 | 보장되지 않음 |
| 이전 기본값이 응답해야 함 | 예 | 아니요 |
시작하기 전에
다음 사항을 확인합니다:
- 원래 기본 계정을 사용할 수 없습니다.
- 기본 복구를 기다리지 않기로 결정했습니다.
- 애플리케이션 트래픽을 대기 상태로 리디렉션할 수 있습니다.
- 트래픽 자동화는 복구되는 경우 이전 기본값으로 쓰기를 다시 보내지 않습니다.
- 대기 클러스터 ID, 주소, 토큰 및 p채널이 있습니다.
가장 중요한 안전 요구 사항은 두뇌 분할을 방지하는 것입니다. 장애 조치 후에는 승격된 대기만 애플리케이션 쓰기를 수락해야 합니다.
장애 조치 구성 빌드
대기 클러스터만 포함하고 복제 토폴로지를 포함하지 않는 구성을 빌드합니다. force_promote=True 을 설정합니다.
# If you followed Set Up CDC Replication, cluster B is the original target cluster.
cluster_b_id = target_cluster_id
cluster_b_addr = target_cluster_addr
cluster_b_client_addr = target_client_addr
cluster_b_token = target_cluster_token
cluster_b_pchannels = target_cluster_pchannels
failover_config = {
"clusters": [
{
"cluster_id": cluster_b_id,
"connection_param": {
"uri": cluster_b_addr,
"token": cluster_b_token,
},
"pchannels": cluster_b_pchannels,
}
],
"cross_cluster_topology": [],
"force_promote": True,
}
스탠바이 승격
대기 클러스터로 요청을 보냅니다.
from pymilvus import MilvusClient
client_b = MilvusClient(uri=cluster_b_client_addr, token=cluster_b_token)
try:
client_b.update_replicate_configuration(**failover_config)
finally:
client_b.close()
요청이 성공하면 cluster-b 이 독립 실행형 프라이머리가 되어 쓰기를 수락할 수 있습니다.
애플리케이션 트래픽 리디렉션
승격 후:
- 쓰기 트래픽을
cluster-b로 리디렉션합니다. - 쓰기 엔드포인트, 로드 밸런서, DNS 레코드 및 자동화에서
cluster-a을 제거합니다. cluster-b이 쓰기를 허용하는지 확인합니다.cluster-a을 폐기하거나 명시적으로 재구축할 때까지 격리된 상태로 유지하세요.
쓰기 확인 예시:
client_b = MilvusClient(uri=cluster_b_client_addr, token=cluster_b_token)
try:
client_b.insert(
collection_name="test_collection",
data=[{"id": 1, "vector": [0.1] * 128}],
)
finally:
client_b.close()
배포에 맞게 컬렉션 이름 및 스키마 필드를 조정합니다.
결과 확인
승격된 클러스터를 직접 확인합니다:
cluster-b에 쓰기가 성공했습니다.- 읽기는 예상 데이터를 반환합니다.
- 애플리케이션 구성 요소가
cluster-a에 쓰지 않습니다.
이전 프라이머리 처리
장애 조치 후 cluster-a 을 오래된 것으로 처리합니다. 다시 연결할 수 있게 되면 애플리케이션 쓰기를 보내지 마세요. cluster-b 에 복제되지 않은 데이터가 포함될 수 있으며, 장애 조치 후 cluster-b 에 이미 새 쓰기가 포함되어 있을 수 있습니다.
cluster-a 을 이전 토폴로지에 자동으로 다시 연결하지 마세요. 이전 기본 토폴로지를 다시 도입하는 것은 별도의 복구 작업으로 신중하게 계획해야 합니다.
데이터 손실 최소화하기
장애 조치로 인한 데이터 손실 위험을 모두 제거할 수는 없지만 줄일 수는 있습니다:
- CDC 지연을 지속적으로 모니터링하세요.
- 기본 쓰기 속도를 처리할 수 있도록 대기 클러스터를 프로비저닝된 상태로 유지하세요.
- 클러스터 간 네트워크 지연과 패킷 손실을 낮게 유지하세요.
- 애플리케이션 쓰기를 무력화하세요.
- 장애 조치 후 성공 여부가 불확실한 쓰기를 다시 시도합니다.
- 프라이머리가 여전히 응답할 수 있을 때마다 전환을 선호합니다.
FAQ
장애 조치 시 항상 데이터가 손실되나요?
아니요, 손실될 수 있습니다. 프라이머리가 실패하기 전에 모든 쓰기가 이미 복제되었다면 데이터는 손실되지 않습니다. CDC 지연이 존재했다면 지연된 데이터는 손실될 수 있습니다.
장애 복구는 얼마나 걸리나요?
일반적으로 대기 상태의 클러스터 상태와 컨트롤 플레인 가용성에 따라 몇 초 내에 완료됩니다.
프라이머리에서 페일오버를 실행할 수 있나요?
아니요. 장애 조치는 대기 클러스터를 위한 것입니다. 현재 기본 클러스터를 사용할 수 있는 경우 전환을 사용하세요.
이전 프라이머리가 자동으로 다시 참여할 수 있나요?
아니요. 장애 조치 후 이전 주체는 오래된 것으로 처리되어 폐기되거나 재구축되어야 복제에 다시 참여할 수 있습니다.
두뇌 분할을 방지하려면 어떻게 해야 하나요?
승격된 클러스터만 쓰기를 받도록 합니다. 모든 쓰기 경로에서 이전 프라이머리를 제거해야 트래픽을 복구하고 수락할 수 있습니다.