INTERNAL: Converted the cmdlog file storage scheme by podongpodong · Pull Request #963 · naver/arcus-memcached

podongpodong · 2026-02-02T09:52:15Z

🔗 Related Issue

https://github.com/jam2in/arcus-works/issues/821

⌨️ What I did

기존의 구현
- 하나의 snapshot, cmdlog 파일을 유지하는 것을 기본으로 동작합니다.
  - snapshot_<time> cmdlog_<time> 형식을 사용합니다.
- log_FILE 구조체의 fd, next_fd, prev_fd를 통해 체크포인트 수행 시 cmdlog 파일을 관리합니다.
- fd에는 현재 cmdlog 파일의 fd를 기록하며 새롭게 생성된 cmdlog 파일은 next_fd에 기록합니다.
- 스냅샷이 완료된 item에 대한 변경 로그는 fd, next_fd 모두 기록하며 완료되지 않은 item에 대한 변경 로그는 fd에만 기록합니다.
- 스냅샷이 완료되면 prev_fd를 fd로 변경하고 fd를 next_fd로 변경합니다.
  - sync 모드의 경우 cmdlog_file_sync()에서 prev_fd에 대한 fsync() 후 close()를 합니다.
  - async 모드의 경우 cmdlog_file_complete_dual_write() 후 바로 prev_fd를 close()합니다.
- 파일의 정리는 chkpt_thread_main에서 주기적으로 실행합니다.
변경한 구현
- 로그 파일의 크기에 따라서 자동으로 체크포인트가 수행되는 chkpt_thread_main()의 동작을 비활성화 시켰습니다.
- dump start snapshot을 통해 실행되는 체크포인트는 do_snapshot_thread_main()으로 수행하도록 로직을 변경했습니다.
- 하나의 snapshot, 최대 크기를 제한한 로그 파일을 큐 형태로 연결하여 관리합니다.
  - snapshot_<time>, snapshot_<time>_<number> 형식을 사용합니다.
    - <number>는 <time>에 해당하는 snapshot 이후로 생성된 몇번 째 로그 파일인지를 나타냅니다.
- 로그 파일을 전역으로 관리하는 log_file_global구조체와 구조체의 필드인 logFILE 구조체를 변형했습니다.
  - prev_fd, fd, next_fd의 관리 방식은 기존의 구현과 동일합니다.
    - fd는 현재 로그를 기록 중인 파일이고 next_fd는 스냅샷이 수행되는 동안 기록되는 로그 파일입니다.
  - 스냅샷 파일이 생성된 경우 fd, next_fd를 교체하는 방식으로 동작합니다.
  - fidx_bgn, fidx_end를 통해 <number>의 시작과 끝을 관리합니다.
    - Producer에서 전부 전송한 파일의 삭제 여부를 판단하는데 사용할 예정입니다.
- 체크포인팅 이후 기존 로그 파일을 생성하는 로직을 변경했습니다.
- Producer 쓰레드를 구현했습니다.
  - snapshot, cmdlog 파일을 읽고 레코드를 kafka로 produce합니다.
  - cmdlog__<fidx_bgn>부터 전부 produce했다면 해당 파일을 삭제합니다.
  - fidx_bgn과 fidx_end를 비교하여 같다면 아직 로그가 기록 중인 파일이기에 삭제하지 않습니다.
- Cosumer 프로세스를 구현했습니다.
  - gcc consumer.c util.c -I./include -o consumer -lrdkafka -lmemcached를 통해서 컴파일 가능합니다.
  - 현재는 key-value, list 컬렉션에 대한 레코드를 소비할 수 있습니다.

namsic · 2026-02-02T12:24:44Z

+        }

        logbuff->fque[logbuff->fend].nflush += spare_length;
+        logger->log(EXTENSION_LOG_INFO, NULL, "[DEBUG] nflush = %d\n", logbuff->fque[logbuff->fend].nflush);


전체적으로 DEBUG 로그를 INFO 레벨로 기록하고 있어서 정리가 필요합니다.

jhpark816

일부 리뷰.

Offline으로 추가 의견을 전달할게요.

podongpodong · 2026-02-06T08:11:13Z

logfile 관리 방식, dump key start\r\n 동작 조건, 스냅샷 쓰레드 동작을 변경해서 반영했습니다.
PR 설명에서 변경된 부분에 대한 설명을 반영 내용에 맞게 수정했습니다.
INFO 레벨로 기록 중인 DEBUG 로그 및 다른 디버그를 위한 출력은 아직 정리하지 못했습니다.

namsic

일부 리뷰

namsic · 2026-02-06T09:42:12Z

+
+#define MAX_FILE_SIZE (4 * 1024) //1024*1024*1024 // 1GB /* unit : byte */
+


외부에서 가져다 사용하기 위한 값이 아니라서 cmdlogfile.c에 두어도 될 것 같은데, 어떤가요?

cmdlogfile.c에 두는 것이 맞다고 생각합니다.

namsic · 2026-02-09T02:57:29Z


    /* start the snapshot thread */
-    ss->running = true;
+    //ss->running = true;


여기 제거하는 이유는 무엇인가요?

do_snapshot_thread_main()을 통해 실행되는 함수 중 do_snapshot_direct() 함수에서 수행하기 때문입니다.

namsic · 2026-02-09T03:05:05Z

+bool cmdlog_file_deletable() {
+    bool ret;
+    pthread_mutex_lock(&log_file_gl.file_access_lock);
+    ret = log_buff_gl.fidx_bgn < log_file_gl.fidx_end;
+    pthread_mutex_unlock(&log_file_gl.file_access_lock);
+    return ret;
+}


아래 확인해 주세요.

engines/default/cmdlogfile.c:64:6: error: no previous prototype for 'cmdlog_file_deletable' [-Werror=missing-prototypes] 64 | bool cmdlog_file_deletable() { | ^~~~~~~~~~~~~~~~~~~~~ engines/default/cmdlogfile.c: In function 'cmdlog_file_deletable': engines/default/cmdlogfile.c:67:11: error: 'log_buff_gl' undeclared (first use in this function) 67 | ret = log_buff_gl.fidx_bgn < log_file_gl.fidx_end; | ^~~~~~~~~~~

cmdlog_file_deletable()의 프로토타입을 cmdlogfile.h에 작성하여 다시 올렸습니다.

jhpark816 · 2026-02-11T02:33:02Z

@podongpodong
리뷰 사항을 반영해 주세요.

podongpodong · 2026-02-11T05:24:49Z

Producer thread, Consumer Process까지 구현했습니다.
- gcc consumer.c util.c -I./include -o consumer -lrdkafka -lmemcached을 통해 consumer를 컴파일 할 수 있습니다.
consumer는 현재 key-value와 list 형태를 소비할 수 있으며 set, map, btree는 추가하고 있습니다.
캐시 서버 시작 시 cmdlog 파일을 통해 복구할 때 Pending된 레코드의 처리가 원활하도록 수정했습니다.
- Pending으로 처리하는 레코드
  - 로그 파일에 LOG_OPERATION_BEGIN, LOG_OPERATION_END 사이에 기록되는 레코드입니다.
  - set에서 get-delete 또는 map/btree에서 여러 개의 레코드를 하나의 delete 명령어로 삭제할 기록되는 레코드는 LOG_OPERATION_BEGIN, LOG_OPERATION_END 사이에 기록됩니다.
  - 복구 시 원자성을 맞추기 위함입니다.

jhpark816

일부 리뷰

podongpodong · 2026-02-12T01:37:16Z

코멘트 내용 반영하여 수정했습니다.

jhpark816 · 2026-02-12T03:26:11Z

+        else if (memcmp(modestr, "snapshot", 8) == 0) {
+            CHECK_NTOKENS_EQ(ntokens, 4);
+            filepath = NULL;
+        }


@podongpodong
질문이 있습니다.
snapshot 수행 시에 filepath 지정 여부를 검토해 볼 수 있는 데,
어떤 방식이 현재의 snapshot 수행에 더 적합한가요?

filepath 지장하는 방식

filepath 지정하지 않는 방식

현재 코드에서는 filepath를 지정하는 방식이 적합하다고 생각합니다.

dump start snapshot을 통해 실행되는 chkpt_snapshot()의 동작 흐름에서 snapshot_<time>, cmdlog_<time>_<number> 형식의 파일 생성을 하고 있습니다.

현재 producer는 스냅샷 파일이 config 파일에 설정한 data_path 경로에 snapshot_의 형식으로 저장된다는 전제로 동작하고 있습니다.

filepath를 지정해서 snapshot을 하는 경우 produce를 위해서 경로 제약, 파일 형식 제약이 별도로 필요해집니다.

@podongpodong @namsic
persistence 관련된 data_path와 logs_path는 persistence 기능에서 사용해야 합니다.
persistence 기능이 동작하는 상태에서 데이터 동기화를 CDC 작업을 수행할 수 있으므로,
CDC를 위한 snapshot과 log file들은 별도로 지정하는 것이 좋겠습니다.

jhpark816 · 2026-02-12T03:46:46Z

            if (ret != ENGINE_SUCCESS) {
                dumper->running = false;
            }
+            dumper->running = false;


@podongpodong
dumper->running = false 설정하는 이유는 무엇인가요?

dump start snapshot에 동작을 수정하면서 콜백으로 설정한 item_dumper_done가 수행되지 않기 때문에 chkpt_snapshot_start이후 쓰레드를 종료하기 위함입니다.

namsic · 2026-02-12T05:55:47Z

+    char *modestr = NULL;
+    char *filepath = NULL;


이런 변경도 미리 넣어야 하지 않는지?

이러한 수정은 없어도 됩니다.

namsic · 2026-02-12T05:56:48Z

 {
    log_FILE *logfile = &log_file_gl.log_file;
    int fd, ret = 0;
-


#964 에서 함께 수정하거나, 기존 구현 유지하는 것이 좋겠습니다.
빈 line으로 구분하는 기존 구현이 나아 보입니다.

상단의 /* fsync curr fd */ 주석 제거는 로직 변경과 관련 있어서 제거한 것인가요?

기존 구현 유지하겠습니다.

/* fsync curr fd */ 주석은 코드 변경 중에 잘못 제거되었습니다.

namsic · 2026-02-12T08:05:13Z

naver:kafka-poc를 현재 naver:develop과 동기화했습니다.
최신 commit 뒤에 PR commit 위치할 수 있도록 하고, 충돌 해결하여 다시 push 바랍니다.
최신화 방법으로 여러 가지가 있으니 직접 찾아 보기 바랍니다. 한 가지 예시로 git pull --rebase가 있습니다.

podongpodong · 2026-02-12T09:14:51Z

Consumer에서 발생하던 병목 현상을 개선했습니다.

병목 원인의 확인은 아래의 명령어를 통해서 확인했습니다.

docker ps에서 CONTAINER ID를 확인합니다.
docker exec -it <kafka_contatiner> bash -lc 'cd /opt/kafka/bin && watch -n 3 "./kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group test-g"'

podongpodong · 2026-02-23T08:40:42Z

Persistence와 CDC 분리한 상태로 테스트 했고 produce하면서 주기적으로 checkpoint 동작하는 것을 확인했습니다.

chkpt_snapshot_init_for_cdc()함수를 추가했습니다.

cmdlog의 경우 recovery 과정에서 스냅샷과 로그파일이 존재하지 않는 경우 생성합니다.
cdclog의 경우 recovery를 수행하는 기능이 필요하지 않다고 생각했고 스냅샷, 로그 파일이 존재하지 않는 경우 발생하는 오류를 방지하기 위해서 해당 함수를 추가하여 초기 스냅샷을 수행했습니다.

namsic self-requested a review February 2, 2026 10:32

namsic mentioned this pull request Feb 2, 2026

New kafka que namsic/arcus-memcached#2

Closed

namsic reviewed Feb 2, 2026

View reviewed changes

jhpark816 reviewed Feb 4, 2026

View reviewed changes

Comment thread memcached.c Outdated

Comment thread engines/default/items.c Outdated

Comment thread engines/default/cmdlogfile.h Outdated

podongpodong force-pushed the new-kafka-que branch from 4ff229a to 4724d85 Compare February 5, 2026 04:46

jhpark816 reviewed Feb 5, 2026

View reviewed changes

Comment thread memcached.c Outdated

podongpodong force-pushed the new-kafka-que branch 2 times, most recently from 296d0e8 to 87e2429 Compare February 6, 2026 08:00

namsic reviewed Feb 9, 2026

View reviewed changes

jhpark816 reviewed Feb 11, 2026

View reviewed changes

Comment thread engines/default/cmdlogbuf.c Outdated

Comment thread memcached.c Outdated

Comment thread consumer.c Outdated

Comment thread engines/default/checkpoint.h Outdated

podongpodong force-pushed the new-kafka-que branch from 443acab to 33677a7 Compare February 12, 2026 01:51

jhpark816 reviewed Feb 12, 2026

View reviewed changes

Comment thread engines/default/checkpoint.c

namsic reviewed Feb 12, 2026

View reviewed changes

podongpodong force-pushed the new-kafka-que branch from 90d6529 to e83258c Compare February 12, 2026 06:44

podongpodong force-pushed the new-kafka-que branch from e83258c to 00b3dfd Compare February 12, 2026 09:04

podongpodong force-pushed the new-kafka-que branch 3 times, most recently from a7ef48c to 464ab55 Compare February 23, 2026 08:31

podongpodong force-pushed the new-kafka-que branch from 464ab55 to edbc6e4 Compare February 24, 2026 01:11

INTERNAL: Fix exptime calculation in the consumer

202e916

podongpodong force-pushed the new-kafka-que branch from edbc6e4 to 202e916 Compare February 24, 2026 03:29

jhpark816 requested a review from ing-eoking February 25, 2026 05:31

namsic merged commit 202e916 into naver:kafka-poc Feb 27, 2026


		#define MAX_FILE_SIZE (4 * 1024) //102410241024 // 1GB /* unit : byte */

Conversation

podongpodong commented Feb 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🔗 Related Issue

⌨️ What I did

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

jhpark816 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

podongpodong commented Feb 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

namsic left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jhpark816 commented Feb 11, 2026

Uh oh!

podongpodong commented Feb 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jhpark816 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

podongpodong commented Feb 12, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

namsic Feb 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

namsic commented Feb 12, 2026

Uh oh!

podongpodong commented Feb 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

podongpodong commented Feb 23, 2026

Uh oh!

Reviewers

Assignees

Labels

podongpodong commented Feb 2, 2026 •

edited

Loading

podongpodong commented Feb 6, 2026 •

edited

Loading

podongpodong commented Feb 11, 2026 •

edited

Loading

namsic Feb 12, 2026 •

edited

Loading

podongpodong commented Feb 12, 2026 •

edited

Loading