Stable

...

Sync

1:N 복제는 N 노드간 복제를 위한 연결을 모두 성립하기 때문에 노드의 개수가 증가하면 할 수록 네트워크 토폴로지적으로 더욱 더 복잡한 메쉬 네트워크 구성형태를 갖습니다. 이와 같이 복잡한 구성 환경에서는 어떤 기준이 없이 운영될 경우 노드 간 복제와 동기화의 방향이 일관성 없이 무작위로 형성되어 데이터 정합성이 일치하지 않는 문제가 야기 될 수 있습니다.

이번 장에서는 이러한 메쉬 네트워크 복제 환경에서 필요한 일관성 있는 bsr의 동기화 정책에 대해 설명하겠습니다.

다음의 그림은 노드 간의 복제와 동기화의 방향이 같거나 다른 경우를 표현합니다.

...

복제와 동기화의 방향이 같으면 문제될 것이 없습니다. 다른 경우가 문제 입니다. 복제 소스 노드와 동기화 소스노드가 다르고 이를 하나의 타깃 노드에서 수신한다면 노드 간 데이터 정합성이 훼손될 수 있습니다. Primary 로 부터 수신하는 복제 데이터는 항상 최신 데이터 이지만 다른 Secondary 동기화 소스로 부터 수신한 데이터 블럭은 예전 데이터일 수 있습니다. 만약 서로 다른 소스로 부터 수신한 데이터가 겹치는 블럭 영역에 걸쳐있다면 일부는 최신이지만 일부는 예전 데이터로 기록될 수 있어서 이런 경우 문제가 발생합니다.

우리는 이 문제를 노드들 간의 복제와 동기화의 방향이 일치되도록 능동적으로 중재하여 메쉬 네트워크에서의 정합성을 보장하도록 구현 하였습니다. 이러한 동기화 정책을 설명하기에 앞서 관련된 몇 가지 배경이 되는 개념에 대해 이해가 필요합니다.

• 안정(Stable) 노드는 Primary 노드 또는 Primary 노드와 연결되지 않은 SyncTarget이 아닌 Secondary 노드 입니다.

• 불안정(Unstable) 노드는 primary 노드와 연결된 노드, 싱크타겟인 Secondary 노드 입니다. 자신의 데이터가 계속 변경됩니다.

• 권한(Authoritative) 노드는 자신을 Unstable 노드로 만든 상대노드이며 Authoritative 노드는 동시에 안정(Stable) 노드 입니다.

...

이와 같은 개념 하에 다음과 같은 동기화 정책이 동작합니다.

• 안정 노드는 SyncSource 가 될 수 있으며, 불안정 노드는 SyncSource가 될 수 없습니다.

• SyncSource 노드가 불안정 노드가 되면 진행 중이던 동기화가 중단됩니다. 상황에 따라 불안정 노드가 다시 안정노드 상태로 전환되면 중지 되었던 동기화가 재개 됩니다.

• 한 노드가 Primary 가 되면 중단되었던 동기화가 Primary 노드를 SyncSource 로 하여 재개 됩니다. 여기서 동기화는 이전에 중단됬던 블럭 이후 부터 이어서 동기화 합니다.

아래의 그림을 통해 위 과정을 도식화 하였습니다.

...

이와 같이 동기화와 복제의 방향을 일치시키는 정책을 Stable 동기화 정책으로 명명하였습니다.

재조정 동기화(reconciliation resync)

...

bsr은 이 상황에서 Secondary 노드들 간에 가장 최신의 데이터를 보유하고 있는 노드를 정하고 이를 기준으로 동기화하여 두 노드간의 데이터 정합성을 일치 시킵니다. 이를 재조정 동기화라고 합니다.

이렇게 두 노드의 데이터를 맞춰두어야 나중에 Crash 되었던 Primary 노드가 재 기동하여 클러스터에 합류하든 하지 않든 모든 운영상황에서 노드 간 데이터 정합성을 보장할 수 있게 됩니다replication establishes all connections for replication between N nodes, so as the number of nodes increases, the network topology has a more complicated mesh network configuration. In such a complicated configuration environment, when operating without any standards, the direction of replication and synchronization between nodes is randomly formed inconsistently, which can cause data inconsistency.

This chapter describes the consistent bsr synchronization policy required in such a mesh network replication environment.

The following figure represents the case where the direction of replication and synchronization between nodes is the same or different.

...

If the direction of replication and synchronization is the same, there is nothing wrong with it. a different case is the problem. Assuming that the replication source node and the synchronization source node are different, if the replication and synchronization data are received as one target node, data integrity between the nodes may be broken. Replication data received from the primary is always up-to-date, but data blocks received from other secondary synchronization sources may be out-of-date. If data received from different sources is in the overlapping block area, some are up-to-date, but some may be recorded as old data, which causes problems.

We implemented this problem to ensure consistency in the mesh network by actively mediating the direction of replication and synchronization between nodes. Before explaining these synchronization policies, you need to understand some of the concepts behind them.

• Stable node is a Primary node or a Secondary node, not a SyncTarget that is not connected to the Primary node.

• Unstable node is a node connected to the primary node and a secondary node that is a SyncTarget. Unstable means that it may be constantly data changing.

• Authoritative node is a relative node that made itself an Unstable node, and the Authoritative node is a Stable node at the same time.

...

The following synchronization policy works under this concept.

• A stable node can be a SyncSource, and an unstable node cannot be a SyncSource.

• When the SyncSource node becomes an unstable node, the synchronization in progress is stopped. Depending on the situation, when the unstable node is switched back to the stable node state, the stopped synchronization is resumed.

• When one node becomes Primary, the interrupted synchronization is resumed with the Primary node as the SyncSource. Here, synchronization starts from the block where it was interrupted before.

The above process is illustrated in the figure below.

...

As such, the policy that matches the direction of synchronization and replication is called the Stable synchronization policy.

reconciliation resync

For example, if the Primary node is performing real-time replication to 2 Secondary nodes and the Primary is crashed and only 2 Secondary nodes are left, the two Secondary nodes cannot be guaranteed to be completely the same data. This is a natural result, since each node operates independently. However, it is not appropriate to operate with the two remaining nodes UpToDate without any action. At least, the data should be matched to each other through synchronization between the two nodes.

In this situation, bsr determines the node that has the most recent data between the secondary nodes and synchronizes it based on this to match the data consistency between the two nodes. This is called reconciliation resynchronization.

The data of the two nodes must be matched, whether the primary node that was crashed later restarts to join the cluster or not. In all operational situations, it is possible to guarantee data consistency between nodes in the cluster.

...