SNR#4636 과거 날짜의 로그를 수집하면 Cold 저장소로 이동한 날짜의 인덱스가 Hot 저장소에 다시 만들어지는 문제 해결

Cold 저장소를 사용하는 환경에서 과거 날짜의 로그가 들어오면, 이미 Cold 저장소로 롤오버된 날짜라도 Cold 데이터 전체를 읽어 그 날짜의 인덱스를 Hot 저장소에 다시 만들던 문제를 해결했습니다.

이 문제로 다음과 같은 영향이 있었습니다.

Cold 데이터 전체를 읽느라 디스크 입출력과 CPU 사용량이 늘었고, Hot 저장소에 불필요한 인덱스가 쌓였습니다.
검색할 때 병합된 Cold 저장소의 인덱스 대신 Hot 저장소에 다시 만든 인덱스를 사용했습니다.
이중화 구성에서는 과거 날짜의 로그가 들어올 때마다 테이블 복제 연결을 다시 맺는 재페어링이 일어났습니다. 또한 해당 날짜를 재동기화하면 스탠바이 노드가 공유 Cold 경로에 쓰려다 실패해 동기화가 복구되지 않았습니다.

이제 과거 날짜의 로그를 수집해도 데이터가 Hot 저장소에 있는 날짜만 인덱스를 만들고, 복제할 때 스탠바이 노드는 Cold 저장소에 쓰지 않습니다. Cold 저장소를 사용하지 않는 환경은 동작이 달라지지 않으며 조치할 사항도 없습니다.

이미 만들어진 인덱스 정리

업그레이드 전에 이 문제로 Hot 저장소에 다시 만들어진 인덱스는 자동으로 지워지지 않습니다. 정리하기 전에 해당 날짜의 데이터가 보존 기간에 따라 삭제되면 Cold 저장소의 인덱스가 데이터 없이 남을 수 있습니다. 따라서 Cold 저장소를 사용하는 환경이라면 업그레이드한 직후 로그프레소 셸에서 다음 명령으로 정리하세요.

logpresso._purgeStaleHotIndex4636 [테이블 필터] [dry|ask|all]

정리 대상은 Hot 저장소에 인덱스가 있고, 같은 날짜의 인덱스가 하위 저장소에도 있으며, 데이터는 Hot 저장소에 없는 파티션입니다. 이 명령은 Hot 저장소의 인덱스만 지웁니다.
테이블 필터에는 테이블 이름이나 와일드카드 패턴을 쓰며, 여러 개는 공백 없이 쉼표로 구분합니다(예: wobs_*,sys_*). 모든 테이블을 대상으로 하려면 *를 지정합니다. 실행 방식을 지정할 때는 테이블 필터를 생략할 수 없습니다.
실행 방식은 다음 중 하나입니다.
- dry(기본값): 정리 대상 파티션의 목록과 크기만 출력합니다.
- ask: 파티션마다 삭제 여부(y/n)를 묻습니다.
- all: YES를 한 번 입력받은 뒤 일괄 삭제합니다.

# 모든 테이블의 정리 대상 확인
logpresso._purgeStaleHotIndex4636 * dry

# 모든 테이블의 정리 대상 일괄 삭제
logpresso._purgeStaleHotIndex4636 * all

이중화 구성에서는 스탠바이 노드에서 먼저 실행한 뒤 액티브 노드에서 실행하세요. 정리가 끝나면 양쪽 노드에서 다음을 확인합니다.

logpresso._purgeStaleHotIndex4636 * dry의 결과가 0 partition(s)인지 확인합니다. 정리 대상이 남아 있으면 해당 노드에서 다시 실행하세요.
서버 로그에 stale hot index scan skipped가 남지 않았는지 확인합니다. 이 로그가 경고(WARN)로 남았다면 목록 조회에 실패한 것이므로 원인을 해결한 뒤 다시 실행하고, 정보(INFO)로 남았다면 사용 중인 파티션을 건너뛴 것이므로 해당 노드에서 다시 실행하세요.