# 범인 검거와 진범 (실체 규명 기록서)

작성일: 2026-01-03 05:29:44 (Asia/Seoul)

---

## 0. 목적 (왜 이 문서가 필요한가)

이번 이슈의 핵심은 “데몬이 죽었는지 살았는지”가 아니라,
**DB에 실제로 쓰기(INSERT/UPDATE)를 수행하는 ‘진범 세션’을 ‘증거로’ 특정**하는 것이다.

이 문서는 다음을 위해 보관한다.

- 다음에도 같은 현상이 생겼을 때, **똑같은 방법으로 ‘즉시’ 잡기**
- 추측/감정/혼동 없이, **증거(프로세스리스트) 기반으로 판단**
- “유령 데몬”처럼 보이던 현상의 **실체를 완전히 규명**

---

## 1. 사건 개요 (현상)

- 어드민 화면에서 데이터가 계속 쌓이는 것이 육안으로 확실
- `SHOW FULL PROCESSLIST`를 여러 번 찍어도 대부분은 아무것도 안 보임
- 그래서 “죽었다/살았다” 혼동이 반복됨
- 그런데 실제로는 **쿼리가 매우 짧게 실행되고 바로 COMMIT**되는 구조라
  한두 번 찍으면 포착이 어렵다.

---

## 2. 최종 결론 (진범 규명)

### ✅ 진범은 다음 형태로 확인됨

- DB: `upbit_data`
- 테이블: `daemon_upbit_Ticker`
- 세션(User): **`pmaadmin`**
- Host: `localhost`
- Command: `Query`
- State: `Commit` / `Updating status`
- Info: `INSERT INTO daemon_upbit_Ticker (...) VALUES (...) ON DUPLICATE KEY UPDATE ...`

즉,

> “유령 데몬”이 아니라  
> **`pmaadmin@localhost` 계정으로 DB에 붙어 INSERT를 수행하는 실행 주체**가 존재했다.

---

## 3. 결정적 증거 (현장에서 잡힌 화면 조건)

### 3-1. 평소에 보이던 것 (오해를 만든 화면)

대부분은 아래만 보였다.

- `event_scheduler` (Daemon, Waiting on empty queue)
- `pmaadmin` (Sleep)
- `root` (SHOW FULL PROCESSLIST 실행 중)

이 상태만 보면 “없다”고 착각하기 쉽다.

---

### 3-2. 진범이 잡힌 순간 (핵심)

연속으로 찍다가 어느 순간 아래가 **딱** 나타났다.

- `pmaadmin`이 `Sleep`가 아니라 **`Query`**
- `Info`에 `INSERT INTO daemon_upbit_Ticker`가 **실제 값과 함께 출력**
- `State`가 `Commit` 또는 `Updating status`

이게 “실체 규명”의 결정적 증거다.

---

## 4. 왜 평소엔 안 보였나 (핵심 원인)

이 진범은:

- INSERT/UPDATE를 **아주 짧게 실행**
- 바로 COMMIT
- 다시 Sleep 또는 연결 종료

즉,

> `SHOW FULL PROCESSLIST`를 “한두 번”으로는 거의 안 잡힌다.  
> **연속으로 여러 번 찍어야** 포착된다.

---

## 5. 재현 가능한 ‘검거 절차’ (다음에도 그대로 하면 잡힌다)

### Step 1) 대상 DB 진입

```sql
USE upbit_data;
```

### Step 2) 연속 캡처 (가장 중요)

아래를 **1~2초 간격으로 10~20회 반복**한다.

```sql
SHOW FULL PROCESSLIST;
```

### Step 3) 잡히는 조건

다음이 보이면 **진범**이다.

- `User` = `pmaadmin`
- `Command` = `Query`
- `Info`에 `daemon_upbit_Ticker` 관련 `INSERT/UPDATE`
- `State`에 `Commit` / `Updating status`

### Step 4) 즉시 사살 (원하면)

잡힌 `Id`로:

```sql
KILL <Id>;
```

※ 단, “다시 살아나는” 경우는 별도의 **명령자(재생성 주체)**가 있다는 뜻이므로,
사살 후 재발하면 명령자까지 끊어야 한다.

---

## 6. 이 사건이 남긴 운영 결론 (절대 잊지 말 것)

1) **EVENT Scheduler는 범인이 아니다**
- 이벤트가 비어있다면 DB 자체가 반복 명령을 치는 구조가 아니다.

2) “죽였는데 다시 살아난다”의 진짜 뜻
- 같은 PID가 부활하는 게 아니라,
  **같은 명령자가 새 프로세스를 다시 만든다**는 뜻이다.

3) **DB_MAX는 감지기, KILL은 사살**
- DB_MAX로 “살아 있음”은 감지 가능하지만,
  DB_MAX 자체로 멈추게 할 수는 없다.

4) 이 사건의 ‘진범’은 증거로 특정됨
- `pmaadmin@localhost`가 `daemon_upbit_Ticker`에
  INSERT를 수행하는 순간이 포착되었으므로,
  “추측”이 아니라 “검거”다.

---

## 7. 파일명 의미

이 문서는 “메모”가 아니라 “증거 기록”이다.
다음에도 혼동하지 않기 위해,
**‘범인 검거와 진범’**이라는 이름으로 저장한다.

---

끝.