문서번호 : 11-490533
Document Information
•
최초 작성일 : 2022.08.04
•
최종 수정일 : 2023.09.20
•
이 문서는 아래 버전을 기준으로 작성되었습니다.
◦
SinglestoreDB : 7.8
Goal
USD 에서 retention 기간이 초과한 후에, snapshot LSN을 기준으로 정리되는 파일들과 현상에 대해 알아보자.
Findings
•
bottomless_gc_retention_period_minutes 변수를 설정하여, PITR을 수행할 수 있는 시간(분)을 지정 할 수 있다. 기본적으로 1440 분(1일)이다.
SET GLOBAL bottomless_gc_retention_period_minutes = 1440;
SQL
복사
•
garabage collector는 snapshot 생성 시점에 가장 old한 LSN 보다 이전 object 중, retention이 경과된 object를 정리한다.
•
snapshot 생성 이후, 약 2 분 이내의 시간이 소요된다.
•
아래는 reference 파티션에서, 가장 오래된 snapshot LSN 0x4d이하의 object 삭제될 때의 tracelog와 상태이다 .
Thread 115071: GCDeadlines: 'test': Performing GC pass at compute Id 12450059879136698575:1000, term 541, LSN 0x4d.
Bash
복사
adbdcdab
└─ 12450059879136698575_1000
└─ ref
├─ 12450059879136698575_1000
│ ├─ logs
│ │ └─ 00000000000000000541
│ │ └─ 00000000
│ │ └─ 00
│ │ └─ 00
│ │ ├─ log_v1_0x004d_0x0056_541_541_0x0_0_x_73402418_x_x
│ │ ├─ log_v1_0x0056_0x005e_541_541_0x0_0_x_73402467_x_x
│ │ ├─ log_v1_0x005e_0x0065_541_541_0x0_0_x_73402469_x_x
│ │ ├─ log_v1_0x0065_0x006c_541_541_0x0_0_x_73402898_x_x
│ │ ├─ log_v1_0x006c_0x0075_541_541_0x0_0_x_73403469_x_x
│ │ └─ log_v1_0x0075_0x0081_541_541_0x0_0_x_73403488_x_x
│ └─ snapshots
│ └─ 00000000000000000541
│ └─ 00000000
│ └─ 00
│ └─ 00
│ ├─ snapshot_v1_0_541_0x4d
│ ├─ snapshot_v1_0_541_0x75
│ └─ snapshot_v1_0_541_0x81
├─ datetime_to_version
│ └─ 2022-08-22_12450059879136698575_1000
├─ log_cleaned_up_lsns
│ └─ 0x4d
├─ milestone_lsns
│ └─ 0x1fffffffffffffff__first_milestone
└─ milestones
└─ _first_milestone
Bash
복사
•
retention이 초과되더라도, snapshot 이 추가 생성되지 않는다면, retention이 초과된 object들이 정리되지 않아 남아있을 수 있다.
◦
기본적으로, partition 단위로 snapshot 이 개별 기록되고, retention 경과에 따른 정리는 가장 늦게 snapshot이 발생하는 partition 기준으로 동작한다.
◦
reference partition의 경우, 매우 장시간 snapshot이 발생하지 않을 경우가 높기 때문에, clean-up 이 안되는 것처럼 보일 수 있다.
◦
그러므로 8.1 버전 이상의 경우, retention을 명시적으로 설정할 경우, 최소 해당 주기 간격으로 snapshot 명령 실행을 권장한다.
•
old version의 object를 적게 유지하려면, snapshot_trigger_size, snapshots_to_keep 변수를 조정하거나, snapshot을 명시적으로 생성해주면 된다.
SET GLOBAL snapshot_trigger_size = 2147483648;
SET GLOBAL snapshots_to_keep = 2;
SQL
복사
SNAPSHOT DATABASE [데이터베이스 이름];
SQL
복사
•
milestone은 mv_milestones에서 확인이 가능하다.
•
MILESTONE_TIME 컬럼이 NULL이 아닌 경우에는 명시적으로 생성한 milestone 이고,
NULL인 경우에는 데이터베이스 초기 생성 및 detach 등으로 자동적으로 생성된 milestone이다.
◦
명시적으로 생성한 milestone은 retention 기간이 지난 후, 조회 되지 않는다.
◦
자동적으로 생성되는 milestone은 retention 기간이 지나도, 조회 되는 경우가 있다.
이는, expired object가 아직 정리되지 않은 경우 발생한다.
◦
명시적으로 생성한 milestone은 reference 파티션에서만 생성된다.
◦
자동적으로 생성되는 milestone은 각 파티션에 object를 생성한다.
SELECT MILESTONE_NAME,MILESTONE_TIME,DATABASE_NAME
FROM information_schema.mv_milestones;
SQL
복사
+----------------------------+----------------------------+---------------+
| MILESTONE_NAME | MILESTONE_TIME | DATABASE_NAME |
+----------------------------+----------------------------+---------------+
| 2022-08-11 14_40_45.414638 | NULL | bottomless_db |
| 2022-08-11 15:00:00 | 2022-08-11 15:02:12.447939 | bottomless_db |
+----------------------------+----------------------------+---------------+
SQL
복사
•
Timeline 또는 milestone이 retention기간을 초과해서 garbage collector에 의해 정리되는 경우, 또는 가용한 시간 범위를 벗어나 database를 attah 시도하는 경우, 아래와 같은 error 메시지 중 하나가 나타난다.
ERROR 2522 UNKNOWN_ERR_CODE: Database `bottomless_db` doesn't have a valid range of versions for attach.
Bash
복사
ERROR 2661 UNKNOWN_ERR_CODE: PITR too close to end of retention period, data was concurrently garbage collected. Please try again with a later timestamp or version.
Bash
복사
ERROR 2470 UNKNOWN_ERR_CODE: 'bottomless_db': Failed to copy file 'acbababb/17081492068111822546_495/ref/17081492068111822546_511/snapshots/00000000000000001870/00000000/00/00/snapshot_v1_0_1870_0x54' because NoSuchKey: The specified key does not exist. (404)
Bash
복사
References
History
일자 | 작성자 | 비고 |
2022.08.04 | wee | 최초 작성 |
2022.08.17 | wee | 전체 내용 수정 |
2022.12.19 | jnshin | 적용 대상 product 수정 |
2023.09.20 | wee | retention 내용 수정 및 추가 |
