Page Comparison

...

drbdcon /handler_use 1

수동 복구

...

Manually recover

If it detects that both nodes were in the primary role after disconnection of the replication connection, it is determined as a split-brain when reconnecting with the other node, and the replication connection is immediately disconnected. And it leaves the following message in the log:

하나의 노드에서 스플릿 브레인이 감지되면 리소스는 StandAlone 상태가 됩니다. 양 노드가 동시에 스플릿 브레인을 감지했다면 양 노드 모두 StandAlone 상태가 되지만, 한 노드에서 스플릿 브레인을 감지하기 전에 상대 노드가 연결을 먼저 끊게 되면 SB를 감지하지 못한 채 단지 Connecting 상태로 유지합니다.

스플릿 브레인을 복구하기 위해선 스플릿 브레인 자동 복구 구성이 되어 있지 않는 한, 변경사항을 폐기할 노드(victim)를 먼저 선택하고 다음과 같은 절차를 통해 수동으로 복구해야 합니다.

먼저 양 노드에서 다음의 명령을 통해 StandAlone 상태로 만듭니다.

bsradm disconnect <resource>

폐기할 노드(victim)에서 아래 명령을 수행합니다. When a split brain is detected on one node, the resource is in the StandAlone state. If both nodes detect the split brain at the same time, both nodes will be in the StandAlone state, but if the other node first disconnects before detecting the split brain on one node, the SB will not be detected and will remain connecting.

In order to recover the split brain, unless the split brain automatic recovery configuration is configured, you must first select the node to discard the changes and manually recover it using the following procedure.

First, put the StandAlone state on both nodes with the following command.

bsradm disconnect <resource>

Execute the following command on the node(victim) to be discarded.

bsradm secondary <resource>
bsradm connect --discard-my-data <resource>

운영 노드(survivor) 에서 연결합니다. 노드가 이미 Connecting 상태였다면 자동으로 연결되기 때문에 이 단계를 생략할 수 있습니다Connect from the Survivor node. If the node was already in the connecting state, you can skip this step because it will automatically connect.

bsradm connect <resource>

정상적으로 연결되면 victim의 복제 상태는 즉시 SyncTarget으로 변경되고, 노드 간의 데이터 변경점들이 survivor 노드를 기준으로 동기화 됩니다.

재동기화가 완료되면 스플릿 브레인은 해결된 것으로 간주하며, 두 노드는 다시 완전히 일치된 이중화 복제 저장 시스템으로 복구됩니다. 

다중 스플릿 브레인

1:N 복제 환경에선 노드들 간의 스플릿 브레인이 다중으로 발생될 수 있습니다. 

예를 들어 A-B-C 의 1:2 복제 구성의 경우 각 노드의 연결을 단절하고 모든 노드의 리소스를 승격 후 볼륨에 I/O 를 수행합니다. 이 후 각 노드를 강등하여 재 연결하면 각각의 노드간에 스플릿 브레인이 발생됩니다. 이 때 스플릿 브레인은 A-B 노드간, B-C 노드간에 또는 A-C 노드 간의 스플릿 브레인 상황이며 클러스터 내 노드간의 SB가 다중으로 발생된 상황입니다. 이럴 경우 다중 SB의 해결은 노드들 간의 개별 연결 기준으로 다음의 절차에 따라 순차적으로 해결해야 합니다.

• Survival 노드와 Victim 노드를 결정하고 모든 노드에서 disconnect 하여 StandAlone 상태를 만듭니다.

• SB가 발생한 노드간에 SB를 해결합니다.

  • Survival 노드는 drbdsetup connect [resource] [victim node-id] 명령을 통해 Connecting 상태로 진입

  • Victim 노드는 drbdsetup connect [resource] [survival node-id] --discard-my-data 명령을 통해 SB 해결

• SB가 해결되고 나면 연결이 되지 않은 Victim 노드 간의 연결을 복원합니다. drbdsetup connect [resource] [victim node-id]

  • SB 를 해결하여 연결을 복원하는 도중 2차 SB가 발생될 경우도 있습니다. 이럴 경우 위와 동일한 절차로 SB를 해결합니다.

자동 복구

스플릿 브레인이 발생하면 관리자에게는 스플릿 브레인 수동 복구(Manual split brain recovery)가 권장되지만, 경우에 따라서는 그 과정을 자동화하는 것이 좋을 수도 있습니다.

bsr은 스플릿 브레인을 자동 복구할 수 있는 몇 가지 알고리즘을 제공합니다.

• Younger Primary 노드의 수정분 폐기: 네트워크 연결이 다시 복구 되고 스플릿 브레인이 감지되면, 최근 Primary 역할로 전환한 노드의 수정분을 폐기합니다.

• Older Primary 노드의 수정분 폐기: 네트워크 연결이 다시 복구 되고 스플릿 브레인이 감지되면, 처음 Primary 역할을 가졌던 노드의 수정분을 폐기합니다.

• 수정 내용이 적은 Primary 데이터 폐기 - 양쪽 노드에서 수정 내용이 더 적은 쪽 노드를 확인하여 그 노드의 내용을 폐기합니다.

• 데이터 변경 사항이 없는 호스트로 복구 - 스플릿 브레인 동안 데이터의 수정 이력이 없는 노드가 있다면 해당 노드로 복구시키고 스플릿 브레인 해결을 선언합니다. 하지만 이것은 아주 드문 경우입니다. 양쪽 노드에서 리소스 볼륨을 파일시스템에 마운트(심지어 읽기전용)만 하더라도 볼륨 내용은 수정사항이 발생하기 쉬우며, 그 후에는 이 방식으로 자동 복구될 가능성은 없다고 봐야 합니다.

자동 스플릿 브레인 복구를 사용할 지 여부는 대체로 응용프로그램에 따라 달라집니다. 예를 들어 bsr에서 데이터베이스를 호스팅하는 경우를 생각해보면 사용자 인터페이스와 연관된 데이터 베이스를 사용하는 웹 응용프로그램에서는 폐기 해야할 변경사항이 거의 없어서 자동 복구가 괜찮은 수단이 될 수 있지만 반대로 금융 데이터 처럼 그 어떠한 데이터라도 함부로 폐기가 힘든 성격을 가지고 있는 환경에서는 사람이 직접 수동 복구를 해야 할 것입니다. 자동 스플릿 브레인 복구를 활성화하기 전에 응용프로그램의 요구사항을 신중하게 고려해야 합니다.

자동 복구 정책

자동 split-brain 복구 정책을 구성하기 위해서는 bsr이 제공하는 몇 가지 구성 옵션을 이해해야 합니다. bsr은 SB 감지 시 Primary로 있었던 노드의 수에 따라 복구 정책을 구분하고, 이에 대한 자동 복구 정책은 리소스의 <net> 섹션에 다음과 같은 키워드를 사용하여 구성합니다.

after-sb-0pri. SB가 발생된 시점에, 어떤 노드도 Primary 역할에 있지 않은 상황으로 복구 방법은 다음과 같습니다. 

• disconnect : 자동으로 복구하지 않습니다. 구성된 SB 핸들러 스크립트가 있다면 이를 호출하고, disconnected 모드를 지속합니다.

• discard-younger-primary : 마지막으로 Primary 역할을 했다고 추정되는 노드에서 수정사항을 취소하고 되돌립니다. younger primary를 판단할 수 없다면 discard-zero-changes, discard-least-changes 순서로 동작하게 됩니다. 

• discard-least-changes : 최소의 변경 사항이 발생한 노드에서 수정사항을 취소하고 되돌립니다.

• discard-zero-changes : 변경 사항이 발생하지 않은 노드가 있다면, 다른 노드의 변경 사항을 적용합니다.

after-sb-1pri. SB가 발생된 시점에, 하나의 노드가 Primary 역할에 있는 상황으로 복구 방법은 다음과 같습니다. 

...

disconnect : 자동으로 복구하지 않습니다. 구성된 SB 핸들러 스크립트가 있다면 이를 호출하고, disconnected 모드를 지속합니다.

...

Upon successful connection, the replication status of the victim is immediately changed to SyncTarget, and data changes between nodes are synchronized based on the survivor node.

When resynchronization is complete, the split brain is considered resolved, and the two nodes are restored back to the fully matched redundant replication system.

Multiple split-brain

In a 1: N replication environment, multiple split brains can occur between nodes.

For example, in the 1:2 replication configuration of A-B-C, each node is disconnected, all resources are promoted, and I/O is performed on the volume. After this, if you demote each node and reconnect, a split brain occurs between each node. At this time, the split brain is a multiple split-brain situation between A-B nodes, between B-C nodes, or between A-C nodes, and multiple SBs occur between nodes in a cluster. In this case, the resolution of multiple SBs should be solved sequentially according to the following procedure based on the individual connection between nodes.

• Determine Survival node and Victim node and disconnect from all nodes to create StandAlone state.

• The SB is resolved between the nodes where the SB occurred.

  • Survival node enters the Connecting state through the command “drbdsetup connect [resource] [victim node-id]

  • Victim node resolves SB through the command drbdsetup connect [resource] [survival node-id] --discard-my-data

• After SB is resolved, restore the connection between the unconnected Victim nodes. drbdsetup connect [resource] [victim node-id]

  • In some cases, a secondary SB may occur again while resolving the SB to restore the connection. In this case, solve the SB by the same procedure as above.

Auto Recover

When a split brain occurs, manual split brain recovery is recommended for administrators, but in some cases it may be a good to automate the process.

bsr provides several algorithms to automatically repair split brain.

• Discarding revisions of the Younger Primary node: When a network connection is restored and a split brain is detected, the revisions of the node that has recently switched to the Primary role are discarded.

• Older Primary Node Revocation: When the network connection is restored again and the split brain is detected, the revision of the node that had the primary primary role is discarded.

• Discard Primary Data with Less Modifications-Both nodes see which node has the less modification and discard the contents of that node.

• Recover to host with no data changes-If a node has no history of data modification during split brain, recover to that node and declare split brain resolution. But this is a very rare case. Even if the resource volume is mounted (even read-only) on the file system on both nodes, the contents of the volume are apt to be modified, and there is no possibility of automatic recovery after this.

Whether to use automatic split brain recovery is largely application-specific. For example, if you're hosting a database on bsr, auto-recovery can be a decent means for web applications that use a database associated with the user interface, with few changes to discard, but vice versa. In an environment in which it is difficult to dispose of it, a manual repair will be required by a person. Before enabling automatic split brain recovery, you should carefully consider your application's requirements.

Automatic recovery policy

To configure the automatic split-brain recovery policy, you need to understand some of the configuration options that bsr provides. bsr classifies recovery policies according to the number of nodes that were primary when SB is detected, and the automatic recovery policy is configured using the following keyword in the <net> section of the resource.

after-sb-0pri. When SB occurs, no node is in the primary role, and the recovery method is as follows.

• disconnect : It does not recover automatically. If there is a configured SB handler script, it is called, and it remains in disconnected mode.

• discard-younger-primary : Undo and revert the modifications on the node that was assumed to have played the most recent primary role. If the younger primary cannot be determined, it will work in the order of discard-zero-changes, discard-least-changes.

• discard-least-changes : Amendments are canceled and reverted to the node with the smallest change.

• discard-zero-changes : If there are nodes that have not changed, the changes from other nodes are applied.

after-sb-1pri. When SB occurs, the recovery method is as follows when one node is in the primary role.

• disconnect : It does not recover automatically. If there is a configured SB handler script, it is called, and it remains in disconnected mode.

• consensus : If SB victim can be selected, it will be resolved automatically. Otherwise, it works like disconnect.

• call-pri-lost-after-sb : SB victim이 선택될 수 있다면, victim 노드에서 pri If the SB victim can be selected, the victim node calls the pri-lost-after-sb 핸들러를 호출합니다. 이 핸들러는 <handlers> 섹션에 구성되어야 하고, 클러스터에서 노드가 강제로 제거됩니다handler. This handler must be configured in the <handlers> section, and the node is forcibly removed from the cluster.

• discard-secondary : 현재 Secondary 역할에 있는 노드를 SB victim으로 만듭니다Make the node currently in the Secondary role a victim of SB.

after-sb-2pri. SB가 발견된 시점에 양 노드에서 Primary 역할에 있는 상황으로, 복구 방법은 disconnect 를 통한 수동 복구만 사용할 수 있습니다.구성 파일 작성 예시는 다음과 같습니다 This is the situation where both nodes are in the Primary role at the time the SB is discovered. The recovery method can only use manual recovery through disconnect.

The following is an example of a configuration file with SB auto recovery.

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