컨테이너에서만 타임아웃 난 MySQL SSH 터널 추적기
호스트에서는 응답하던 SSH DB 터널이 복제 컨테이너에서만 시간 초과될 때 연결을 구간별로 확인한 기록입니다.
태그
이 주제로 남긴 기록 24편
호스트에서는 응답하던 SSH DB 터널이 복제 컨테이너에서만 시간 초과될 때 연결을 구간별로 확인한 기록입니다.
5초간 MySQL 복제를 끊어 쓰기 차단의 효과를 비교하고, 운영에서는 저장을 유지하기로 한 이유를 정리했습니다.
MySQL 통합 테스트의 데이터와 접속 경로를 실행마다 분리하고, DB가 종료된 뒤 데이터 폴더를 정리하는 절차를 설명합니다.
얼쑤의 MySQL 통합 테스트 174개 중 53개가 실패한 기록을 바탕으로, Spring이 캐시한 컨텍스트의 연결 풀이 어떻게 DB 한도에 닿는지 살펴봅니다.
얼쑤에서 같은 녹음으로 분석을 재시도하고, 시도 번호와 마감 조건으로 늦은 결과가 새 시도를 덮지 않게 한 과정을 소개합니다.
Flyway를 앱 교체 직전에 실행하도록 배포를 바꾸고, 이전 앱이 새 스키마에서도 동작하도록 적용 범위와 실패 처리를 정한 과정입니다.
후보 JAR의 SQL을 Flyway 이력과 대조하면서 줄바꿈, BOM, 후행 공백을 구별하는 CRC32 검사를 운영 이력으로 검증했습니다.
완료 표시가 겹쳐도 첫 시각을 유지하도록 MySQL의 중복 키 분기와 저장 뒤 재조회를 설계했습니다.
R2의 일괄 만료를 서버 정리 작업으로 옮기고, 조건부 갱신으로 저장 요청과 파일 삭제의 순서를 정한 과정입니다.
연습 기록을 저장하는 동안 삭제가 기다리는지, 고정 지연 대신 MySQL이 보고한 행 잠금 대기로 확인했습니다.
가입 테스트가 남긴 회원이 기본 악기를 참조했습니다. 그 상태를 한 행으로 재현하고, 악기 행을 삭제하던 픽스처를 같은 ID의 값을 갱신하는 방식으로 바꿨습니다.
MySQL 조회에서 보이는 물음표가 저장된 값인지, 결과를 내보내는 연결에서 생긴 것인지 나눠 봅니다.
연습 통계 API에서 날짜 파싱을 통과한 극단값이 500을 내는 이유와, 입력 범위를 검사해 400으로 돌려준 과정을 정리했습니다.
한국 시간 자정의 양쪽에 있는 연습 기록을 구분하고, 회원 50명과 연습 구간 2만 건을 넣은 MySQL에서 인덱스가 선택되는지 확인했습니다.
저장 도중 실패한 변경은 DB에서 되돌아가고, 커밋에 실패한 업로드에서는 분석을 시작하지 않는지 각각 검사했습니다.
같은 기록을 계속 대기열에 남길 수 있던 두 가지 500을 찾아 401과 400으로 구분하고, 임시 MySQL에서 저장 결과를 확인했습니다.
녹음 업로드 만료 UPDATE가 실제로 바꾸는 행과 InnoDB가 찾아가는 범위가 어떻게 다른지 검토한 사례입니다.
연습 세션을 만드는 요청을 네 스레드에서 같은 키로 보냈습니다. 응답 네 건의 세션 ID가 같고 MySQL에는 한 행만 남도록 만든 과정을 정리했습니다.
같은 세션에 동시에 녹음을 올려도 DB가 접수한 원본이 남도록, 요청별 객체 키와 조건부 갱신을 조합해 검증했습니다.
SQL의 UNKNOWN을 만나 부분적으로 비어 있는 녹음 정보가 저장됐습니다. DB 제약과 파일 검사에서 각각 허용 범위를 정했습니다.
성장 화면에서 첫 연주와 최근 연주를 비교할 때 악보 버전, 채점 모델, BPM과 단위를 맞춘 이유입니다.
테스트 데이터가 두 조건에 동시에 걸리면 그중 하나가 빠져도 결과가 같습니다. 성취도 조회의 SQL 조건을 각각 검사하도록 데이터를 바꾼 과정입니다.
DB 전체 조회 권한을 회수하고 회원 테이블의 필요한 열 9개만 허용했습니다. 운영 Grafana의 패널 쿼리와 보호된 열의 접근 거부를 함께 확인했습니다.
작업 트리를 바꾸지 않는 병합 검사와, 실제 병합 뒤 스키마 제약까지 확인하는 DB 테스트를 구분했습니다.