MariaDB 강좌 / 이벤트 스케줄러로 정기 작업 실행하고 결과 확인하기

MariaDB 이벤트 스케줄러는 정해진 시각이나 간격에 SQL을 실행하는 서버 기능입니다. 이벤트 정의가 존재하는 것, 스케줄러가 켜진 것, 작업이 성공한 것은 서로 다르므로 예약 정보와 실제 결과 테이블을 함께 확인해야 합니다.

이벤트가 적합한 작업과 사전 조건

이벤트는 데이터베이스 안에서 끝나는 집계 갱신이나 짧은 정리 작업에 사용할 수 있습니다. 외부 API, 파일 전송, 여러 시스템에 걸친 재시도·알림이 필요하다면 애플리케이션 작업 큐나 운영 스케줄러가 더 적합할 수 있습니다. 이 글은 삭제 작업 대신 실행 흔적 한 행을 남기는 일회성 이벤트로 동작을 확인합니다.

전용 appops_lab에서 CREATE TABLE, INSERT와 EVENT 권한이 필요합니다. 이벤트는 DEFINER 계정의 권한으로 실행되며 로그인 중인 클라이언트 연결이 작업을 대신 수행하는 것이 아닙니다. 정의자 계정과 권한을 바꾸면 이후 실행에도 영향을 줄 수 있습니다. MariaDB 이벤트 개요를 함께 확인하세요.

현재 스케줄러와 시간대 확인하기

SELECT @@GLOBAL.event_scheduler, @@GLOBAL.time_zone, @@SESSION.time_zone;

event_scheduler가 ON이어야 예약이 실행됩니다. OFF는 정의를 저장할 수 있어도 실행되지 않는 상태입니다. DISABLED는 일반적인 실행 중 ON 전환으로 해결되지 않으므로 시작 설정과 DBA 정책을 확인해야 합니다. 공유 서버에서는 다른 이벤트까지 활성화될 수 있으므로 학습자가 임의로 전역 설정을 바꾸지 않습니다.

새로 만든 전용 실습 서버에서만 관리자가 필요에 따라 SET GLOBAL event_scheduler = ON;을 실행합니다. 테스트 전 원래 값을 기록하고, 테스트 종료 시에는 자신의 이벤트를 먼저 중지합니다. 서버 전체를 OFF로 되돌리는 작업은 다른 이벤트에 미치는 영향을 확인한 관리자의 판단이 필요합니다.

일정의 해석을 일정하게 하려고 아래 생성문은 세션 시간대를 +00:00으로 설정합니다. 이 변경 전 값을 기록하고 작업 후 원래 세션 시간대로 복구하세요. 클라이언트 PC 시계와 서버 시간대가 다를 수 있으므로 화면의 현지 시각만 보고 실행 실패라고 판단하지 않습니다.

결과 테이블과 비활성 이벤트 만들기

CREATE DATABASE IF NOT EXISTS appops_lab
  CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
USE appops_lab;
CREATE TABLE event_runs (
  run_id BIGINT NOT NULL AUTO_INCREMENT PRIMARY KEY,
  ran_at DATETIME(6) NOT NULL,
  run_label VARCHAR(40) NOT NULL
) ENGINE=InnoDB;

SET @event_saved_time_zone = @@SESSION.time_zone;
SET SESSION time_zone = '+00:00';
CREATE EVENT appops_lab.record_run
  ON SCHEDULE AT CURRENT_TIMESTAMP + INTERVAL 10 SECOND
  ON COMPLETION PRESERVE
  DISABLE
  DO INSERT INTO appops_lab.event_runs (ran_at, run_label) VALUES (UTC_TIMESTAMP(6), 'scheduled-check');

처음에는 DISABLE로 생성하여 검토 전에 실행되지 않게 합니다. ON COMPLETION PRESERVE는 일회성 일정이 끝난 뒤에도 이벤트 정의를 남기는 옵션이며, 작업 데이터의 보존 정책이나 재실행 보장은 아닙니다. CREATE EVENT 구문에는 일정과 완료 처리의 차이가 설명되어 있습니다.

SELECT @@GLOBAL.event_scheduler;
SELECT EVENT_NAME, STATUS, TIME_ZONE, EXECUTE_AT, LAST_EXECUTED
FROM information_schema.EVENTS
WHERE EVENT_SCHEMA = 'appops_lab' AND EVENT_NAME = 'record_run';
SELECT run_id, ran_at, run_label FROM appops_lab.event_runs ORDER BY run_id;

정상적인 초기 상태에서는 이벤트 정의가 한 개이고 STATUS가 DISABLED이며 결과 테이블은 비어 있습니다. 스케줄러를 켜지 않아도 이 정의 확인은 가능하므로, 먼저 이름과 스키마, 시간대를 점검합니다.

일정을 다시 잡아 활성화하고 실제 결과 대조하기

생성 과정에서 10초가 이미 지났을 수 있으므로 활성화하면서 미래의 실행 시각을 다시 지정합니다. 원고를 읽은 시간이나 연결을 준비한 시간 때문에 오래된 일회성 예약을 재사용하지 않도록 한 것입니다.

ALTER EVENT appops_lab.record_run
  ON SCHEDULE AT CURRENT_TIMESTAMP + INTERVAL 10 SECOND
  ENABLE;

약 10초가 지난 뒤 위의 확인 SQL을 다시 실행합니다. 스케줄러는 정밀 실시간 타이머가 아니므로 정각 일치나 아주 짧은 지연만으로 실패를 판정하지 않습니다. 결과 테이블에는 scheduled-check가 한 건 생기고, LAST_EXECUTED가 채워지며 보존된 일회성 이벤트는 완료 후 DISABLED가 됩니다.

LAST_EXECUTED는 실행 시도 시각을 판단하는 자료이며 업무 작업 전체가 성공했다는 증거로 단독 사용하지 않습니다. 이 예제에서는 실제로 삽입된 행을 함께 대조합니다. 별도 연결에서 실행되므로 현재 클라이언트의 영향 행 수만으로 예약 실행을 판단해서도 안 됩니다.

반복 일정에는 중복·겹침·실패 처리를 설계하기

일회성 실습을 마친 뒤 반복 일정으로 비교하려면 다음처럼 시작·종료 시각을 제한합니다. 실습 종료 후 계속 실행되는 무기한 이벤트를 남기지 않습니다.

ALTER EVENT appops_lab.record_run
  ON SCHEDULE EVERY 1 MINUTE
  STARTS CURRENT_TIMESTAMP + INTERVAL 1 MINUTE
  ENDS CURRENT_TIMESTAMP + INTERVAL 3 MINUTE
  ENABLE;

반복 실행되는 본문은 실행당 한 행을 추가합니다. 실제 집계 작업에는 대상 기간의 고유 키와 재실행 규칙이 필요합니다. 같은 기간을 다시 처리해도 합계를 두 번 더하지 않도록 원자료로부터 결과를 재계산하거나 멱등성을 설계해야 합니다. 이전 작업이 다음 예약까지 끝나지 않으면 실행이 겹칠 가능성도 검토하세요.

이벤트 제한 사항은 실행 시각·동시 실행 순서를 엄격하게 보장하지 않는다는 점과 매번 별도 연결을 사용한다는 점을 설명합니다. 복제본이나 장애 전환 후보 서버에서도 같은 작업이 중복 실행되지 않도록 어떤 서버가 작업을 담당하는지 정해야 합니다.

중지·오류 확인·정리 순서

ALTER EVENT appops_lab.record_run DISABLE;
SHOW CREATE EVENT appops_lab.record_run;

1. 일정을 비활성화하고 해당 작업이 더 이상 실행되지 않는지 확인합니다. 이미 시작된 실행이 즉시 취소된다는 뜻은 아니므로 진행 중 작업도 확인합니다.
2. 스케줄러 값, 이벤트 STATUS, DEFINER 권한, TIME_ZONE과 실행 시각을 점검합니다. LAST_EXECUTED가 있는데 결과가 없다면 서버 오류 로그와 본문 SQL의 실패 조건을 확인합니다.
3. 전용 실습 결과를 더 보관할 필요가 없을 때 이벤트를 먼저 삭제하고 테이블을 정리합니다.

DROP EVENT appops_lab.record_run;
DROP TABLE appops_lab.event_runs;

SET SESSION time_zone = @event_saved_time_zone;

원래 세션 시간대도 복구합니다. 반복 작업이 실패했을 때는 이벤트를 계속 켠 채 SQL을 바꾸기보다 중지 후 원인과 재처리 범위를 확인해야 누락과 중복을 구분할 수 있습니다.