728x90
반응형
DB 운영이나 IDC → AWS 마이그레이션을 하다 보면 꼭 한 번은 마주치는 옵션이 있다. 바로 explicit_defaults_for_timestamp다. 평소엔 잘 안 보이다가, dump/restore나 스키마 비교 단계에서 갑자기 에러를 만들곤 한다.
오늘은 이 옵션이 정확히 무엇인지, 왜 중요한지, 그리고 실무에서 어떤 문제를 일으키는지까지 한 번에 정리해보자.
explicit_defaults_for_timestamp란?
explicit_defaults_for_timestamp는 TIMESTAMP 컬럼의 기본값을 “명시적으로 작성해야 하는지”를 결정하는 MySQL 서버 옵션이다.
한 줄 요약하면:
TIMESTAMP 컬럼에 DEFAULT 값을 직접 써야 하느냐,
아니면 MySQL이 자동으로 넣어주느냐를 정하는 스위치
현재 MySQL은 Oracle Corporation 에서 관리하고 있으며, 최신 버전 기준으로는 이 옵션이 기본 ON이다.
ON / OFF 차이 한눈에 보기
설정값동작 방식
| ON (1) | DEFAULT / ON UPDATE 를 반드시 명시해야 함 |
| OFF (0) | 아무것도 안 써도 자동으로 CURRENT_TIMESTAMP 적용 |
ON 일 때 (요즘 기본값 – 권장)
explicit_defaults_for_timestamp = ON이 상태에서는:
created_at TIMESTAMP이렇게만 쓰면 ❌ 에러 또는 NULL.
반드시 아래처럼 명시적으로 작성해야 한다.
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP특징
- 자동 시간 삽입 ❌
- DEFAULT 직접 선언 ⭕
- DATETIME 과 동일한 동작
- 스키마가 명확해짐
- ORM / 마이그레이션 안정적
👉 MySQL 5.6.6 이후 + MySQL 8.x 에서는 기본 ON
OFF 일 때 (레거시 방식)
explicit_defaults_for_timestamp = OFF이 경우:
created_at TIMESTAMP이렇게만 써도:
- DEFAULT CURRENT_TIMESTAMP 자동 적용
- UPDATE 시 시간 자동 변경
즉, 눈에 보이지 않는 암묵적 동작이 들어간다.
예전 시스템에서는 편했지만, 지금 기준에서는 예측 불가능한 스키마가 된다.
운영 환경에서 왜 문제가 되나?
실무에서는 보통 이런 흐름에서 터진다.
✔ IDC → AWS DB 마이그레이션
✔ mysqldump / restore
✔ 신규 클러스터(MySQL 8) 생성
기존 DB는 OFF 기준 스키마인데,
신규 DB는 ON 기본값이면:
- ❌ TIMESTAMP default 오류
- ❌ INSERT 실패
- ❌ 테이블 생성 실패
- ❌ schema mismatch
이런 문제가 연쇄적으로 발생한다.
특히 dump 파일 안에 DEFAULT 정의가 없는 TIMESTAMP 컬럼이 있으면 거의 100% 걸린다.
현재 설정 확인 방법
SHOW VARIABLES LIKE 'explicit_defaults_for_timestamp';운영 기준 추천 패턴
1. 옵션은 ON 유지
2. 모든 TIMESTAMP 컬럼을 명시적으로 작성
예:
created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP이렇게 하면:
- 환경 바뀌어도 동일 동작
- dump/restore 안전
- AWS Aurora / RDS에서도 문제 없음
정리
explicit_defaults_for_timestamp는 작은 옵션 같지만,
- 마이그레이션 안정성
- 스키마 일관성
- 장애 예방
전부에 영향을 준다.
운영 환경에서는 반드시 ON + 명시적 DEFAULT 작성을 표준으로 가져가는 게 좋다.
728x90
반응형