Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Primary 노드 장애의 경우 AL 을 통한 특별한 메커니즘으로 블록 디바이스의 정합성을 맞추게 됩니다. 이와 관련한 자세한 설명은 액티비티 로그를 참고하세요.

영구적 장애

영구적이거나 복구가 불가능한 장애가 발생한 경우, 다음 단계를 수행해야 합니다.

...

  • 기본 시스템과 응용 프로그램을 설치합니다.

  • bsr을 설치하고, 동작하고 있는 노드의 /etc/bsr.d/ 아래에 있는 파일들과 /etc/bsr.conf를 복사합니다.

  • 리소스 재구성 에 맞게 재 구성하고, 리소스를 기동하고 초기 동기화를 시작합니다.

...

after-sb-2pri. SB가 발견된 시점에 양 노드에서 Primary 역할에 있는 상황으로, 복구 방법은 disconnect 를 통한 수동 복구만 사용할 수 있습니다.

구성 파일 작성 예시는 다음과 같습니다.

Code Block
resource <resource> {
    handlers {
        split-brain "C:/Tools/script/split-brain.bat";
        ...
    }
    net {
        after-sb-0pri discard-zero-changes;
        after-sb-1pri discard-secondary;
        ...
    }
    ...
}
Info

SB 핸들러의 배치 파일 구성에서 사용하는 파일들은 절대 경로로 기술되어야 합니다.

호환성

타사 제품 또는 모듈과의 호환성 문제에 대해 설명합니다. 호환성 문제는 대부분 다른 프로그램 또는 모듈의 동작이 bsr 의 운영을 방해하는 현상으로 나타납니다.

볼륨 참조

bsr 은 리소스 동작 중에 내부적으로 볼륨에 대한 참조회수를 유지합니다. 만약 down 시점에 볼륨에 대한 참조회수가 0이 아니라면 다음과 같은 유형의 오류 로그가 출력되며 down 은 실패 합니다.

Info

DRBD volume(r0) Secondary failed (error=0: State change failed: (-12) Device is held open by someone

이 문제를 해결하려면 볼륨을 참조하는 프로세스 또는 모듈을 파악하여 해당 모듈의 동작을 중단 시켜서 볼륨에 대한 참조회수를 감소시키는 조치가 필요합니다.

예를 들어, Ubuntu 20.04 이상에서 multipath-tools(0.8.3)는 다음의 예외조치를 통해 bsr 볼륨에 대한 참조가 발생하지 않도록 해야 합니다.

Code Block
blacklist {
        devnode "^(sd)[a-z]"
        devnode "^(bsr)[0-9]"
        }