“복잡한 Zabbix 운영을 더 효율적으로 만들고 싶다면,
블로그의 핵심 내용을 집대성한 『Zabbix 엔터프라이즈 최적화 핸드북(PDF)』을 확인해보세요.”

https://jikimy.gumroad.com/l/zabbix-master

---

개요

이 글은 앞서 분리한 Tablespace 구조를 기반으로,
Zabbix의 핵심 데이터(history, trends)를 일 단위 / 월 단위 파티션 테이블로 변환하는 과정을 다룬다.

MySQL 8.0부터는 일반 테이블스페이스(General Tablespace) 위에 파티션을 둘 수 없기 때문에,
먼저 file-per-table 구조로 전환한 뒤 파티션을 생성해야 한다.

---

1) 전제 조건

• Ubuntu 22.04
• Zabbix 7.4
• MySQL 8.x
• /data/history, /data/trends 디스크 분리 완료
• 1~2편의 절차(스키마 import 및 Tablespace 이동)까지 완료되어 있을 것

⚠️ 주의:
운영 중인 환경에서는 파티션 적용 시 데이터 I/O가 급격히 발생하므로,
반드시 테스트 환경에서 검증 후 본 적용을 진행해야 한다.

---

2) 일반 테이블스페이스에서 file-per-table로 되돌리기

MySQL 8.0부터는 일반 테이블스페이스를 대상으로 파티션 테이블을 둘 수 없다.
따라서 반드시 각 테이블을 innodb_file_per_table 구조로 변경해야 한다.

mysql> 
ALTER TABLE zabbix.history       TABLESPACE = innodb_file_per_table;

mysql>
ALTER TABLE zabbix.history_uint  TABLESPACE = innodb_file_per_table;

mysql>
ALTER TABLE zabbix.trends        TABLESPACE = innodb_file_per_table;

mysql>
ALTER TABLE zabbix.trends_uint   TABLESPACE = innodb_file_per_table;

---

3) 파티션 생성 전 참고

🔹 history vs trends 구조적 차이

테이블	데이터량	용도	일반 파티션 단위
zabbix.history*	초 단위로 수백만 건 이상	실시간 단기 저장	일 단위 (1~3일 주기)
zabbix.trends*	집계(평균/최대/최소) 데이터	중기~장기 저장	월 단위 (30일 주기)

---

4) Epoch Time 계산 참고 및 파티션
생성시 주의 사항

파티션의 경계값은 UTC 기준 Epoch Time을 사용해야 한다.
이는 타임존 혼동을 방지하고, 크론 스크립트 자동화를 단순화하기 위함이다.

Epoch Time이란?

**Epoch Time(유닉스 타임스탬프)**는
1970년 1월 1일 00:00:00 UTC부터 경과한 **초(second)**를 정수로 표현한 값이다.
이 값은 전 세계 어디서나 타임존 영향을 받지 않는 절대 시간 기준이기 때문에,
서버의 지역시간(예: KST, JST, PST 등)이 달라도 시간 비교나 자동화 스크립트에서 혼란이 없다.

---

🔹 파티션 경계값에 UTC Epoch Time을 사용하는 이유

MySQL 파티션은 DATETIME 또는 TIMESTAMP 컬럼을 기준으로 분리할 수 있는데,
운영 환경마다 서버의 timezone이 다를 수 있으므로
UTC 기준 Epoch Time으로 고정해야
크론 스크립트나 자동화된 파티션 생성 시점이 일정하게 유지된다.

---

✅ 초기 파티션 생성 시 반드시 맞춰야 하는 기준

(이 기준을 어기면 이후 Cron 스크립트가 생성하는 파티션 경계값과 충돌함 → MySQL REORGANIZE 오류 발생)

MySQL 파티셔닝은 시간 경계(VALUES LESS THAN) 가 정확히 맞아야 한다.
초기 파티션을 잘못 만들면, 자동 스크립트가 계산하는 UTC Epoch 값과 일치하지 않아
“파티션이 겹칩니다 / 파티션 경계가 잘못되었습니다” 또는 생뚱맞지만 권한 오류가 발생하는 경우가 있다..

아래 기준을 반드시 지켜 초기 파티션을 만들어야 한다.

---

🔥 HISTORY / HISTORY_UINT — 초기 파티션 생성 규칙 (일 단위)

History 테이블의 파티션은 **“오늘 00:00:00 (UTC)부터 내일 00:00:00 (UTC)까지 하루 단위”**로 끊는다.
즉, 각 파티션은 하루(24h) 를 커버하는 형태다.

---

① 오늘 날짜(UTC) 확인

date -u +%Y-%m-%d

예:

2025-12-07

이 날짜가 그대로 파티션 이름(pYYYYMMDD)으로 사용된다.

---

② 내일(오늘 +1일) 00:00:00 UTC → 파티션 경계 Epoch 계산

파티션의 VALUES LESS THAN() 에 들어가는 값은
다음 날 00:00:00 UTC의 Epoch 으로 한다.

date -u -d '2025-12-08 00:00:00' +%s

출력 예:

1765152000

이 값이 파티션 경계값이다.

---

③ 파티션 이름 규칙 (자동 스크립트와 동일)

• 파티션 이름 = 오늘 날짜
• 경계값 = 내일 00:00 UTC Epoch 값

따라서:

• 파티션 이름: p20251207
• VALUES LESS THAN: 1765152000 (2025-12-08 00:00 UTC)

---

④ 파티션 의미

p20251207 = clock < 2025-12-08 00:00:00 (UTC)

즉,
2025-12-07 하루 전체의 데이터를 포함하는 파티션이 된다.

---

🔥 TRENDS / TRENDS_UINT — 초기 파티션 생성 규칙 (월 단위)

Trends 테이블은 “기준 월 전체 < 다음 달 1일 00:00:00 UTC” 를 경계로 한다.

trend는 초기 수동으로 파티션을 만들 때는 UNIX_TIMESTAMP() 함수를 사용하도록
한다.

① 파티션 이름(pYYYYMM) 규칙

→ 스크립트를 처음 적용하는 시점의 현재 월

예:
2025년 12월에 처음 적용 →

p202512

② VALUES LESS THAN 경계값

→ UNIX_TIMESTAMP(‘다음달 1일 00:00:00 UTC’) 사용

기준 월: 2025-12
다음 달: 2026-01-01 00:00:00 UTC

VALUES LESS THAN (UNIX_TIMESTAMP('2026-01-01 00:00:00'))

이 값이 “2025년 12월의 전체 데이터 구간”을 정의하는 경계가 된다.

절대로 아래 hiisory / trends 관련 초기 수동으로 파티션 생성할 때 그대로 복사.붙여넣기를 하면 안되고. 환경에 맞게 응용 해야만 한다.

5) history / history_uint — 일 단위 파티션 생성

📌 오늘 기준으로 최초 파티션을 만들고,
각자 운영 환경의 날짜에 맞게 경계값(epoch)을 변경해야 한다.

mysql> ALTER TABLE zabbix.history
PARTITION BY RANGE (clock) (
  PARTITION p20251024 VALUES LESS THAN (1761350400) DATA DIRECTORY='/data/history',
  PARTITION pMAX      VALUES LESS THAN (MAXVALUE)   DATA DIRECTORY='/data/history'
);

mysql> ALTER TABLE zabbix.history_uint
PARTITION BY RANGE (clock) (
  PARTITION p20251024 VALUES LESS THAN (1761350400) DATA DIRECTORY='/data/history',
  PARTITION pMAX      VALUES LESS THAN (MAXVALUE)   DATA DIRECTORY='/data/history'
);

---

6) trends / trends_uint — 월 단위 파티션 생성

📌 기준일은 다음달 1일 00:00:00 UTC로 설정.

mysql> ALTER TABLE zabbix.trends
PARTITION BY RANGE (clock)(
  PARTITION p202510 VALUES LESS THAN (UNIX_TIMESTAMP('2025-11-01 00:00:00')) DATA DIRECTORY='/data/trends',
  PARTITION pMAX    VALUES LESS THAN (MAXVALUE)                               DATA DIRECTORY='/data/trends'
);

mysql> ALTER TABLE zabbix.trends_uint
PARTITION BY RANGE (clock)(
  PARTITION p202510 VALUES LESS THAN (UNIX_TIMESTAMP('2025-11-01 00:00:00')) DATA DIRECTORY='/data/trends',
  PARTITION pMAX    VALUES LESS THAN (MAXVALUE)                               DATA DIRECTORY='/data/trends'
);

---

7) 작업 후 점검

• /data/history와 /data/trends 아래에 p20251024.ibd, p202510.ibd 형태의 파티션 파일 생성 확인
• MySQL 로그(/var/log/mysql/error.log)에 파티션 오류 없는지 확인
• 기존 데이터는 자동으로 새 파티션으로 옮겨지지 않으며, 이후 신규 수집 데이터부터 새 파티션에 저장된다.

---

8) 요약

구분	작업	결과
Tablespace → file-per-table 전환	ALTER TABLE ... TABLESPACE = innodb_file_per_table	파티션 생성 가능 상태
history 파티션 생성	일 단위 (UTC epoch)	/data/history에 일별 파티션 생성
trends 파티션 생성	월 단위 (UNIX_TIMESTAMP)	/data/trends에 월별 파티션 생성
데이터 경계 기준	UTC	크론 자동화 시 타임존 혼동 방지

---

9) 다음 편 예고

4편에서는 이 파티션 구조를 자동으로 관리하는 스크립트를 구성한다.
zbx-part-history.sh, zbx-part-trends.sh 두 개의 크론 스크립트를 통해
매일·매월 신규 파티션 자동 생성과 일정 기간 경과 데이터 자동 삭제를 완성한다.

🛠 마지막 수정일: 2025.12.11