INTERNAL: Refactoring updateReplConnections.

[brido4125]

🔗 Related Issue

https://github.com/jam2in/arcus-works/issues/620#issuecomment-2505369614

⌨️ What I did

기존 로직의 경우 findChangedGroups을 통해
해시링의 형상과 zk로부터의 형상을 먼저 비교합니다.
그 후에 변경이 있는 Group에 대해서만 루프를 돌며 update를 수행합니다.

변경된 로직은 해시링의 형상(old)을 순회를 돌며
해당 해시링 기준, zk로부터의 형상(new)을 곧바로 비교하면서
update를 수행합니다.

리뷰를 위해 이슈 관련 히스토리도 아래에 정리합니다.

1. findChangedGroups가 알고보니, M / S 정보를 비교해서 변경을 감지하는것을 발견
2. 1번 문제는 특정 상황에서 switchover가 원복하는 문제가 그대로 남아 있음
3. 2번 상황 해결을 위해 masterCandidate를 사용하는 방안 사용
4. 3번 상황의 엣지 케이스 발견 및 해결

결론적으로 기존의 findChangedGroups가 가진 문제는 해결된 상태에서의 PR인점을 참고해주세요.

추가적으로 아래 코멘트 사항에서 언급된 경우도 처리합니다.
#874 (comment)

기존에는 for 루프 내에서 group 별로 처리하는 경우를
for 루프 앞단에서 일괄적으로 이전 delayed switchover를 처리하도록 변경했습니다.

[jhpark816]

@uhm0311 아직 draft 상태입니다.

[oliviarla]

질문이 있습니다.

변경된 MemcachedConnection 파일의 416~419 line에 아래 내용이 존재하는데요, 이전과 형상이 동일한 그룹일 경우에만 switchoverMemcachedReplGroup 메서드를 호출하고 나머지 경우에는 remove만 해주어야 하지 않나요?

      if (oldGroup.isDelayedSwitchover()) {
        delayedSwitchoverGroups.remove(oldGroup);
        switchoverMemcachedReplGroup(oldGroup, true);
      }

[brido4125]

@oliviarla
다른분들도 이해할 수 있게 좀 풀어서 설명할게요
혹시 이해안가시면 말씀해주세요

• 1차 Zk 이벤트 발생 후, 해당 SwitchOver는 Delayed Switchover로 판별됨
• 2차 Zk 이벤트가 발생되는 시점의 형상은 기존 형상을 따르고 있음

	1번 노드	2번 노드	3번 노드	4번 노드
기존 형상	M	S1	S2
1차 ZK 이벤트(Delayed Switchover)	S1	M	S2
2차 ZK 이벤트 1️⃣	S1	M	S2
2차 ZK 이벤트 2️⃣	M	S1	S2
2차 ZK 이벤트 3️⃣	M	S1		S2

• 2차 ZK 이벤트 1️⃣ : 앞선 이벤트와 동일한 형상의 이벤트
  • SW, remove 둘 다 진행
  • 다른 그룹의 변경에 의해 이벤트가 발생한 경우
• 2차 ZK 이벤트 2️⃣ : 앞선 이벤트와 다른 형상이고 기존 형상과 동일한 이벤트
  • SW, remove 둘 다 진행 -> 최신 형상이 반영되지 않은 문제 발생 (기존형상과 동일할 경우 continue 문으로 처리하기 때문)
• 2차 ZK 이벤트 3️⃣ : 앞선 이벤트와 다른 형상이고 기존 형상과도 다른 이벤트
  • SW, remove 둘 다 진행할 필요 X
  • 변경이 생긴 그룹으로 취급되어 로직에 의해 최신 형상으로 반영해야함

참고로 기존 구현은 2번 케이스가 아예 진행되지 않습니다.
(changedGroup을 먼저 계산해버리기 때문)

아마 2번 케이스에 대한 코멘트를 남겨주신것 같은데 맞나요?

[oliviarla]

@brido4125
delayed switchover로 등록된 복제 그룹(1차 zk 이벤트)에서 이전과 형상이 달라졌다(2차 zk 이벤트)는 것은 delayed switchover 등록했던 상태가 아니므로, 항상 switchoverReplGroup 메서드를 호출할 경우 잘못된 role을 가질 수 있지 않는지에 대한 의문이 들었습니다.

생각해보니 이전 zk 형상과 새로운 zk 형상이 달라진 것을 두 케이스로 나누어 아래와 같이 처리할 수 있을 것 같습니다. 적합한지 검토 부탁드려요.

• master ↔ slave 역할이 바뀌었다면 switchoverReplGroup 호출하지 않고 다시 delayed switchover로 등록한다.
• slave 노드 혹은 그룹에만 변경 발생(제거/장비 이동 등) 시에는 새로운 zk 형상을 기반으로 switchover 진행한다.

[oliviarla]

리뷰 완료.

415 line은 이미 상위에서 handleDelayedSwitchover 호출하므로 제거해도 될것 같습니다.

[jhpark816]

리뷰 완료

[jhpark816]

코드는 간단해 보이지만, 최적화가 된 것인지는 의문입니다.

두 개의 set이 같은 지를 비교하기 위해서는 아래 형태의 fore 문을 수행하기 때문입니다.
for 문을 이용한 비교가 한번 더 수행될 수 있어 오히려 최적화의 반대 효과를 낼 것 같습니다.

       bool same = true;
       for (ArcusReplNodeAddress newSlaveAddr : newSlaveAddrs) {
          if (!oldSlaveAddrs.contains(newSlaveAddr)) {
            same = false; break;
          }
       }
       for (ArcusReplNodeAddress oldSlaveAddr : oldSlaveAddrs) {
          if (!newSlaveAddrs.contains(oldSlaveAddr)) {
            same = false; break;
          }
       }
       return same;

[brido4125]

오히려 제거하는게 나을 것 같네요