분류

카우치베이스 DCP 롤백 및 QA가 이를 테스트하는 방법

소개

 

이 글에서는 DCP 롤백을 예로 들어 CouchBase QA 팀이 CouchBase 제품을 테스트하기 위해 얼마나 많은 노력을 기울이는지 설명하고, 먼저 DCP가 무엇이고 DCP 롤백이 무엇인지에 대한 배경 지식을 알려드리겠습니다.

 

DCP란 무엇인가요?

 

DCP는 복제본이나 뷰와 같은 카우치베이스 노드 간 또는 XDCR이나 FTS와 같은 외부 클라이언트와의 데이터베이스 변경 프로토콜을 의미합니다. 생산자/소비자 모델을 따르며 높은 처리량과 짧은 지연 시간을 제공합니다. 데이터는 vbucket별로 스트리밍됩니다. 다음과 같이 설명됩니다. 여기.

 

특히 시퀀스 번호에 관심이 있습니다. 시퀀스 번호는 v버킷의 돌연변이와 관련된 단조롭게 증가하는 숫자로, 생산자와 소비자를 동기화하는 데 사용됩니다.

 

롤백이란 무엇인가요?

 

아니요, 이러한 롤백은 아닙니다.

카우치베이스 롤백은 클라이언트가 생산자가 가진 것보다 더 큰 시퀀스 번호를 가진 생산자에 연결할 때, 다시 말해 클라이언트가 새로운 변형을 가지고 있지만 이것이 '진실'이 아니므로 새로운 진실에 맞추기 위해 일부 변형을 롤백하거나 실행 취소해야 할 때 발생합니다.

 

이는 흔한 일은 아니지만 실제로 발생하며 데이터 무결성을 위해 올바르게 처리하는 것이 중요합니다.

 

라이브 환경에서는 다음과 같은 시나리오에서 이러한 문제가 발생할 수 있습니다:

 

비행 중 돌연변이가 있는 페일오버(하드 페일오버에서 발생할 수 있음)

  1. 클라이언트가 활성 노드 A에 연결됨
  2. 시퀀스 번호가 100인 돌연변이가 클라이언트에 도착하여 복제 노드 B로 이동 중입니다.
  3. 서열 번호 100의 돌연변이가 노드 B에 도착하기 전에 장애 조치가 발생하면 노드 B에는 서열 번호 90만 있습니다.
  4. 장애 조치를 인식한 클라이언트는 시퀀스 번호 100으로 새로 활성화된 노드 B에 연결합니다.
  5. 시퀀스 번호 90만 있는 노드 B는 클라이언트가 시퀀스 90으로 롤백을 요청하면 응답합니다.
  6. 클라이언트는 서열 번호 91-100에 대한 돌연변이 효과를 취소하고 서열 번호 90의 프로듀서에게 연결을 요청합니다.

 

지속되지 않는 데이터로 인한 충돌

 

  1. 클라이언트가 활성 노드 A에 연결됨
  2. 염기서열 90번까지의 돌연변이가 지속되었습니다.
  3. 시퀀스 번호 100까지의 돌연변이가 클라이언트에 도착했지만 아직 유지되지 않았습니다.
  4. 멤캐시드 충돌 및 재시작, 장애 조치 없음
  5. 클라이언트가 시퀀스 번호 100으로 노드 A에 다시 연결합니다.
  6. 위의 5단계 및 6단계와 유사합니다.

 

DCP 롤백 테스트(및 중단 방법)

 

Couchbase QA 조직은 세 가지 방법으로 롤백을 테스트합니다:

 

프로듀서

 클라이언트가 생산자가 알고 있는 시퀀스 번호보다 큰 시퀀스 번호를 요청하는 경우 생산자는 롤백을 요청합니다. 제작자가 실제로 클라이언트에게 롤백을 요청했는지, 해당 시점부터 일관된 데이터를 반환하는지 확인합니다.

  저희는 맞춤형 DCP 클라이언트를 개발했습니다. 이 클라이언트는 돌연변이를 수행하고 병렬로 DCP 연결을 생성하며 특정 시나리오를 실행합니다. 요청된 시퀀스 번호를 조작하고 압축과 같은 다른 기능 상호 작용을 트리거하고 지속성 상태를 모니터링할 수 있습니다.

 

소비자

롤백 요청을 받으면 클라이언트가 이후 변경 사항을 제대로 실행 취소하고 새 변경 사항을 올바르게 적용하는지 확인합니다.

 

다음 시나리오는 클라이언트가 결정적으로 롤백 요청을 받게 되는 경우입니다:

 

  1. 지속성 중지
  2. 멤캐시드 및 멤캐시드 재시작 종료
  3. DCP 연결은 지속성이 중지되기 전의 시퀀스 번호로 롤백됩니다.

 

테스트 작성자는 위의 시나리오를 사용하여 롤백을 트리거하고 클라이언트가 롤백된 변경 사항을 제대로 실행 취소하는지 확인합니다.

소비자 측에서 발견되는 일반적인 문제는 소비자가 롤백된 돌연변이와 관련된 정보를 보유하는 것과 관련이 있습니다.

 

시스템 테스트

 

보기 및 2i 중에 높은 변이율(활성 v버킷이 복제본보다 앞서게 되는)로 하드 페일오버를 수행합니다. 결과적으로 복제본 vbucket을 활성으로 승격하고 시퀀스 번호를 롤백하는 동안 데이터가 손실될 수 있지만 클러스터는 계속 안정적으로 유지됩니다. 발견된 일반적인 버그는 새로 승격된 복제본의 데이터가 일관되지 않거나 클라이언트가 롤백을 올바르게 처리하지 못하는 경우 등입니다.

 

이 문서 공유하기
받은 편지함에서 카우치베이스 블로그 업데이트 받기
이 필드는 필수 입력 사항입니다.

작성자

게시자 에릭 쿠퍼

Eric Cooper는 Couchbase에서 테스트 자동화 팀을 관리하고 있습니다. 그는 통신, 고가용성 시스템, 클라이언트/서버 애플리케이션 등 30년 이상의 업계 경력을 보유하고 있습니다. 현재 관심 분야는 빅 데이터와 테스트 자동화입니다.

댓글 남기기

카우치베이스 카펠라를 시작할 준비가 되셨나요?

구축 시작

개발자 포털에서 NoSQL을 살펴보고, 리소스를 찾아보고, 튜토리얼을 시작하세요.

카펠라 무료 사용

클릭 몇 번으로 Couchbase를 직접 체험해 보세요. Capella DBaaS는 가장 쉽고 빠르게 시작할 수 있는 방법입니다.

연락하기

카우치베이스 제품에 대해 자세히 알고 싶으신가요? 저희가 도와드리겠습니다.