[CBRD-26983] Replicate the shutdown serial write-back and reject stale _db_serial images on an active node

[hgryoo]

http://jira.cubrid.org/browse/CBRD-26983

Purpose

#7720 은 serial 캐시 블록을 버리기 전에 미발급 구간을 _db_serial 에 되돌려 적고, 서버 셧다운에서도 같은 일을 한다. QA 의 ha_repl 에서 sql/_13_issues/_23_1h/cases/cbrd_24544.sql 이 구문별 카탈로그 비교에 실패했다. master 재시작 뒤 a_tbl_ai_a 의 current_val 이 master 는 70001, slave 는 1330001 이었다.

• 셧다운 write-back 은 xboot_shutdown_server 에서 빌려 쓴 system worker 트랜잭션으로 돈다. log_does_allow_replication () (src/transaction/log_comm.c) 은 active worker 트랜잭션이 아니면 거짓이라, serial_update_serial_object 가 flush mark 도 복제 기록도 남기지 않았다. master 만 값을 낮추고 standby 는 블록 끝을 유지했다.
• decache 의 write-back 은 DDL 자신의 트랜잭션에서 쓰기 잠금 전에 돌아 flush mark 가 붙은 system operation 을 지난다. DDL 이 롤백되어도 복제되므로 영향이 없다.
• 셧다운 write-back 을 복제되게 하자 두 번째 문제가 드러났다. active 노드에 cubrid heartbeat stop 을 걸면 약 2초 뒤 standby 가 승격되는데, 종료 중인 노드는 그때 아직 flush 를 쓰지 않았다. 이미지는 이미 active 가 되어 값을 발급한 노드에 도착하고, 적용하면 current_val 이 2730001 에서 70001 로 내려간다. 다음 INSERT 는 이미 발급된 1400001 보다 낮은 140001 을 받았고, 그대로 두면 1400001 이 두 번 나온다.

그래서 함께 넣어야 하는 두 변경이다. 복제되는 트랜잭션 위의 셧다운 write-back, 그리고 active 노드는 복제된 _db_serial 이미지로 current_val 을 뒤로 돌리지 않는다는 수신 규칙.

Implementation

src/connection/server_support.c

• css_init 의 셧다운 순서에서 요청 워커, vacuum, load 세션이 멈춘 뒤, log writer 를 멈추기 전에 새 serial_flush_cache_pool_replicated 를 부른다. 이 시점에는 값을 발급하는 주체가 없고 log writer 는 아직 기록을 보낼 수 있다.

src/query/serial.c, src/query/serial.h

• serial_flush_cache_pool_replicated 는 dblink 2PC 데몬처럼 일반 트랜잭션을 할당받아 (logtb_assign_tran_index, xtran_server_commit, logtb_free_tran_index) 그 위에서 serial_flush_cache_pool 을 돈다. 각 쓰기는 NEXT_VALUE 가 값을 올릴 때와 같은 경로인 serial_update_serial_object 의 flush mark 가 붙은 system operation 을 지나고, applier 는 그 operation 의 끝에서 적용한다.
• serial_repl_image_is_stale 은 applier 가 가져온 _db_serial 이미지를 이 노드에 적용하지 말아야 하는지 판정한다. active 또는 to-be-standby 노드에서 serial 의 진행 방향과 반대로 current_val 을 움직이는 이미지는 적용하지 않는다. standby 는 모든 이미지를 적용한다. cyclic serial 은 방향이 없어 active 노드에서는 행을 건드리지 않는다. 두 레코드 중 하나라도 읽지 못하면 이전처럼 적용한다. 건너뛴 이미지는 새 알림 ER_HA_REPL_SERIAL_IMAGE_SKIPPED 로 서버 로그에 남긴다. serial 이름, 이 노드의 current_val, 이미지의 값을 적고, er_stack_push / er_stack_pop 으로 감싸 applier 의 오류 영역은 그대로 둔다. 기본 error_log_level 에서 기록되므로 두 노드의 값이 다른 이유가 운영 로그에 남는다.
• serial_flush_cache_pool_replicated 는 캐시에 엔트리가 없으면 트랜잭션을 할당하지 않는다. 트랜잭션 테이블이 꽉 찬 종료에서 쓸 것도 없이 ER_TM_TOO_MANY_CLIENTS 를 남기지 않기 위해서다.

src/base/error_code.h, msg/en_US.utf8/cubrid.msg, msg/ko_KR.utf8/cubrid.msg

• ER_HA_REPL_SERIAL_IMAGE_SKIPPED 와 그 메시지를 추가한다. 기존 ER_HA_GENERIC_ERROR 는 기본 call_stack_dump_activation_list 에 들어 있어 쓸 때마다 콜스택이 덤프되므로 재사용하지 않는다.

src/transaction/locator_sr.c

• xlocator_repl_force 는 locator_update_force 앞에서 serial_repl_image_is_stale 로 판정해, stale 이면 행을 건드리지 않은 채 그 객체를 적용된 것으로 처리한다.

src/transaction/boot_sr.c

• xboot_shutdown_server 의 write-back pass 는 SA_MODE 전용이 되고 빌려 쓰던 system worker 도 없어진다. SERVER_MODE 밖에서는 lock_get_object_lock () 이 X_LOCK 을 돌려 serial_update_serial_object 가 system operation 을 열지 않는다.

Verification

디버그 빌드, Docker 2노드 HA (ha_mode=on, ha_copy_sync_mode=sync:sync), QA 시나리오 그대로. CREATE TABLE a_tbl (a INT AUTO_INCREMENT (1, 70000), b INT), auto_increment_cache_size = 20, 2건 INSERT (id 1, 70001, 두 노드 블록 끝 1330001), cubrid heartbeat stop 으로 정상 종료. 두 순서를 다섯 번 실행했고 (#7720 브랜치에서 셋, 이 브랜치에서 둘, 뒤의 하나는 develop 머지 후) 값이 모두 같다.

값은 두 가지 재개 지점에서 나온다. 마지막 발급값 70001 에서 재개하면 다음 id 는 140001 이고 새 블록 끝은 1470001 이다. 블록 끝 1330001 에서 재개하면 다음 id 는 1400001 이고 새 블록 끝은 2730001 이다. 표의 세 열은 develop, 첫 커밋만 넣은 상태, 두 커밋을 넣은 이 PR 이다.

순서	노드	develop (#7720)	셧다운 flush 복제만	이 PR
standby 먼저 정지, active 정지, 둘 재시작	active	70001, 다음 id 140001	같음	같음
	standby	1330001	70001	70001
standby 가 살아 있는 채 active 정지, standby 승격 (1330001 에서 1400001 발급, 2730001 예약), 옛 master 의 남은 로그가 승격 뒤 도착	승격 노드	남은 로그에 write-back 이 없어 2730001 유지, 다음 id 1470001	이미지가 적용되어 70001 로 내려감, 다음 id 140001 (이미 발급된 1400001 보다 낮다)	이미지를 거부해 2730001 유지 (건너뜀 로그), 다음 id 1470001

• standby 의 값은 applier 가 따라잡은 뒤의 것이다. 재시작 직후를 찍으면 아직 이전 값이 보일 수 있다. 다섯 번째 실행에서 실제로 그랬고, 폴링에서 1330001 다음에 write-back 의 70001, 그다음 새 블록 끝 1470001 이 로그 순서대로 들어오는 것을 확인했다.
• 두 번째 순서에서 이 PR 의 숫자는 develop 과 같다. 승격이 write-back 보다 먼저이므로 gap 은 오늘과 같이 남고, 수신 규칙이 하는 일은 첫 커밋만으로는 생기는 역행을 막는 것이다.
• 단일 노드, cubrid server stop 뒤 재시작: id 1, 70001, 140001. 마지막 정지 뒤 current_val 140001.
• standalone, csql -S 로 2건 발급 후 종료: 다음 csql -S 가 current_val 70001 을 읽고 (이전에는 블록 끝) 140001 을 발급한다. xboot_shutdown_server 의 SA_MODE pass 이며 system worker 를 빌리지 않는다.
• 모든 실행에서 서버 로그에 assert, abort, FATAL 없음.
• 리뷰 반영 세 커밋 뒤 같은 두 순서를 다시 실행했다. 값은 같고, 승격 노드의 서버 로그에 거부 알림이 한 줄 남는다 (HA repl info: ... current_val 2730001, image 70001). 옛 master 의 로그에는 없다. 단일 노드와 standalone 도 같다.

Remarks

• 수신 규칙은 active 노드의 뒤로 가는 갱신에만 적용된다. standby 의 카탈로그는 여전히 master 의 행을 그대로 따르고, ha_repl 이 비교하는 것은 그것이다.
• 수신 규칙은 이 PR 의 write-back 에만 걸리는 것이 아니다. 옛 master 가 남긴 이미지가 승격 노드의 예약보다 낮은 블록 끝인 경우도 이제 적용되지 않는다. 이전에는 적용되어 같은 역행이 가능했다.
• 비정상 종료 뒤의 failover 는 이전처럼 블록 끝 너머에서 재개한다. 복제할 write-back 이 없다. 정상 종료 직후 heartbeat stop 이 바로 승격하는 경우도 위의 이유로 같다. standby 인 채로 write-back 을 적용한 노드는 마지막 발급값에서 재개한다.
• standalone 프로세스 (csql -S, loaddb) 의 serial 쓰기는 전후 모두 복제되지 않는다. SA_MODE 에서 log_does_allow_replication () 은 거짓이다.
• cyclic serial, 감소 serial, to-be-standby 상태의 분기는 코드 판독으로만 확인했다. release 빌드는 CI 에 맡긴다.
• boot_sr.c 의 정리는 분리 가능하다. 서버의 pass 가 css_init 으로 옮겨져 그 자리에서는 쓸 것이 없어졌기 때문에 함께 넣었다.
• 테스트케이스 변경 없음. QA 의 cbrd_24544.sql ha_repl 실행이 재현이며, 이 브랜치에서 재실행을 요청한다.
• TC 게이트, CI, QA 재실행이 끝날 때까지 draft.

[github-actions]

❌ TC Merge Gate — Merge Blocked

One or more TC PRs are still open. Please merge or close them before merging this PR.

TC Repositories & Branches:

• ❌ cubrid-testcases: TC PR tc/pr-7877 is open (draft) — must be merged or closed first
• ❌ cubrid-testcases-private-ex: TC PR tc/pr-7877 is open (draft) — must be merged or closed first

Steps to unblock:

1. Merge or close all TC PRs listed above.
2. Re-run this check: Actions tab → TC Merge Gate → Re-run failed jobs

[github-actions]

🧪 TC Test Environment Ready

CircleCI Testing:

• CircleCI will automatically test using the branches below.

TC Repositories & Branches:

• cubrid-testcases Draft PR (Branch: tc/pr-7877)
• cubrid-testcases-private-ex Draft PR (Branch: tc/pr-7877)

Next Steps:

1. Wait for CircleCI tests to complete
2. If CircleCI tests failed, please check the test results and fix the issues.
3. When ready to merge this PR, please merge the TC PR first, then merge this PR.

[hgryoo]

/run all

[hgryoo]

/run all

[hgryoo]

/run all

[hgryoo]

/run all

[greptile-apps]

해제된 heap page의 PEEK 레코드 사용과 committed serial 정의의 전체 skip 가능성이 있어 현재 상태로는 병합하기 안전하지 않습니다.

_{Reviews (1) · Last reviewed commit: "Merge branch 'develop' into CBRD-26983-h..."}

[hgryoo]

/run all

[hgryoo]

/rerun 34451435296

[hgryoo]

/run rerun 34451435296

[hgryoo]

/run rerun 34470317942

[hgryoo]

/run all