전환
전환은 데이터 손실 없이 기본-대기 방향을 변경합니다. 현재 기본 클러스터에 계속 연결할 수 있거나 유지 관리를 위해 트래픽을 이동해야 할 때 이 기능을 사용하세요.
이 가이드에서는 현재 토폴로지를 가정합니다:
cluster-a (primary) -> cluster-b (standby)
전환 후 토폴로지는 다음과 같습니다:
cluster-b (primary) -> cluster-a (standby)
전환 사용 시기
전환 사용 시기
- 현재 기본 토폴로지에서 유지 관리를 수행하는 경우.
- 프라이머리는 부분적으로 성능이 저하되었지만 여전히 요청에 응답할 수 있습니다.
- RPO = 0이 필요하며 데이터 손실을 허용할 수 없습니다.
기본 계정을 완전히 사용할 수 없는 경우에는 전환을 사용하지 마세요. 이 경우 장애 조치를 사용하세요.
시작하기 전에
시작하기 전에 다음 사항을 확인하세요:
- 두 클러스터 모두 연결할 수 있습니다.
- CDC 복제가 정상입니다.
- CDC 지연이 복구 시간 목표에 비해 충분히 낮습니다.
- 역할 변경 중에 애플리케이션 쓰기를 일시 중지하거나 다시 시도할 수 있습니다.
- 새 토폴로지 구성을 준비했습니다.
전환 시 데이터 손실은 없지만 작업 시간은 복제해야 할 데이터의 양에 따라 달라집니다.
새 토폴로지 구축
cluster-b 이 소스가 되고 cluster-a 이 대상이 되는 전체 교체 구성을 만듭니다.
# If you followed Set Up CDC Replication, cluster A is the original source cluster,
# and cluster B is the original target cluster.
cluster_a_id = source_cluster_id
cluster_a_addr = source_cluster_addr
cluster_a_client_addr = source_client_addr
cluster_a_token = source_cluster_token
cluster_a_pchannels = source_cluster_pchannels
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
switchover_config = {
"clusters": [
{
"cluster_id": cluster_a_id,
"connection_param": {
"uri": cluster_a_addr,
"token": cluster_a_token,
},
"pchannels": cluster_a_pchannels,
},
{
"cluster_id": cluster_b_id,
"connection_param": {
"uri": cluster_b_addr,
"token": cluster_b_token,
},
"pchannels": cluster_b_pchannels,
},
],
"cross_cluster_topology": [
{
"source_cluster_id": cluster_b_id,
"target_cluster_id": cluster_a_id,
}
],
}
새 토폴로지 적용
두 클러스터에 동일한 구성을 적용합니다. 요청을 먼저 현재 프라이머리로 보낸 다음 대기 상태로 보냅니다. 나중에 다시 전환하는 경우 cluster-b 이 현재 기본값이므로 순서를 반대로 합니다.
from pymilvus import MilvusClient
client_a = MilvusClient(uri=cluster_a_client_addr, token=cluster_a_token)
client_b = MilvusClient(uri=cluster_b_client_addr, token=cluster_b_token)
try:
client_a.update_replicate_configuration(**switchover_config)
client_b.update_replicate_configuration(**switchover_config)
finally:
client_a.close()
client_b.close()
이전 프라이머리는 대기 상태로 강등되고 새 쓰기를 거부합니다. 이전 대기 상태는 남은 복제된 데이터를 기다렸다가 스스로를 프라이머리로 승격시킨 다음 쓰기를 수락합니다.
일시적인 네트워크 또는 서비스 오류로 인해 요청이 실패하면 동일한 구성으로 다시 시도하세요.
애플리케이션 트래픽 리디렉션
cluster-b 이 기본이 된 후
- 쓰기 트래픽을
cluster-b으로 리디렉션합니다. cluster-b에서 읽기 및 쓰기가 성공하는지 확인합니다.cluster-a에서 더 이상 애플리케이션 쓰기가 수신되지 않는지 확인합니다.cluster-b에서cluster-a으로의 복제를 계속 모니터링합니다.
결과 확인
cluster-b 이 새 기본 계정으로 사용 중이고 데이터가 일관되게 유지되는지 확인합니다. 일반적인 확인 사항은 다음과 같습니다:
- 중요한 컬렉션의 행 수를 비교합니다.
- 두 클러스터에서 알려진 기본 키를 쿼리합니다.
- 새 기본 및 이전 대기에서 대표 검색을 실행합니다.
cluster-b에 작은 쓰기를 실행하고cluster-a에 복제되었는지 확인합니다.
다시 전환하기
나중에 다시 전환하려면 원래 토폴로지를 다시 적용합니다:
cluster-a -> cluster-b
동일한 전환 플로우를 사용합니다. 다시 전환하기 전에 현재 프라이머리에 연결할 수 있고 복제가 정상인지 확인하세요.
FAQ
전환하면 데이터가 손실되나요?
아니요. 전환은 대기 상태가 기본 상태가 되기 전에 나머지 데이터가 복제될 때까지 기다립니다.
애플리케이션 쓰기를 중지해야 하나요?
역할 변경 중에는 쓰기를 일시 중지하거나 쓰기를 다시 시도할 수 있도록 설정해야 합니다. 강등된 후 이전 프라이머리로 전송된 쓰기는 거부됩니다.
전환이 예상보다 오래 걸리는 이유는 무엇인가요?
가장 일반적인 이유는 CDC 지연 때문입니다. 새 기본값은 남은 데이터를 수신해야 RPO = 0으로 안전하게 인계할 수 있습니다.
실패한 전환 요청을 다시 시도할 수 있나요?
예. 동일한 대상 토폴로지로 다시 시도하세요.
이전 기본값은 어떻게 되나요?
이전 프라이머리는 대기 상태가 됩니다. 더 이상 애플리케이션 쓰기를 받을 수 없습니다.