직접 만든 소프트웨어, 두 가지 개발 기록 구현 구조와 적용 범위, 확인한 기능과 남은 한계를 함께 기록합니다. MediaMTX 스트리밍 제어 서버Docker Compose 구성과 파일·라이브·멀티캐스트 송출 RTSP CCTV 관제·분석 프로그램관제 그룹, 영역·출입선, 이벤트 이력을 연결하는 구조 PostgreSQL6 PostgreSQL 이전: pg_dump와 AWS DMS 선택, 중단 시간·CDC·검증 기준 전체 복사와 복원에 필요한 쓰기 중단을 감당할 수 있다면 pg_dump·pg_restore를 먼저 검토하고, 복사 중에도 변경을 받아야 한다면 AWS DMS의 CDC를 비교하세요. 결정 기준은 데이터 크기 하나가 아니라 허용 중단 시간, 스키마 범위, 변경률과 되돌림 가능성입니다. DMS를 켠다고 무중단 이전이나 완전한 객체 이전이 자동 보장되지는 않습니다.선택이 어려운 원인: 한 번의 복사와 지속 동기화를 같은 작업으로 보기pg_dump는 실행 시점의 일관된 데이터베이스 덤프를 만들지만 이후 변경을 계속 전달하는 도구는 아닙니다. 덤프 중 쓰기를 허용할 수 있다는 점과, 서비스 전환 때 누락 없이 최신 상태를 만들 수 있다는 점을 구분해야 합니다. 마지막 쓰기를 멈춘 뒤 덤프·전송·복원을 진행하는 단순.. 2026. 10. 17. PostgreSQL statement timeout 해결: 잠금 대기·세션 설정·트랜잭션 범위 점검 canceling statement due to statement timeout은 PostgreSQL이 한 명령의 시간 예산을 넘겨 취소했다는 뜻입니다. 먼저 실제 접속의 설정값과 잠금 대기를 확인하고, 즉시 timeout을 0으로 끄거나 전체 DB 제한을 늘리지 마세요. statement_timeout에는 잠금 대기 시간도 포함될 수 있습니다. 쿼리 자체가 느린지, 다른 트랜잭션을 기다리는지, 앱·프록시에서 먼저 끊겼는지 나눠야 합니다.이 글은 PostgreSQL 16 공식 문서를 기준으로 한 진단입니다. 다른 주 버전은 지원 설정과 동작을 해당 버전 문서에서 확인합니다. 예제는 문서 검토용 SQL이며 운영 DB에 연결하거나 쿼리를 실행한 결과는 아닙니다. 오류 메시지·시각·연결 경로를 보존한 뒤 제한.. 2026. 10. 15. RDS Proxy와 PgBouncer 비교: PostgreSQL 연결 풀 비용·호환성·운영 선택 기준 PostgreSQL 연결 수가 늘어날 때 RDS Proxy를 도입할지, PgBouncer를 직접 운영할지 고민하게 됩니다. AWS의 지원 데이터베이스에 연결하고 프록시 가용성 운영을 맡기려면 RDS Proxy를 검토할 수 있습니다. PostgreSQL 연결 풀을 여러 인프라에서 직접 조정해야 한다면 PgBouncer가 후보입니다. 선택 기준은 연결 수 감소만이 아니라 세션 기능의 호환성, 장애 시 책임, 같은 가용성을 갖추는 총비용입니다.1. 데이터베이스 앞에 풀을 두는 이유와 비교 범위이 글은 PostgreSQL 애플리케이션의 서버 연결 재사용을 비교합니다. 커넥션 풀은 여러 요청이 사용할 연결을 유지하는 장치입니다. 애플리케이션이 가진 클라이언트 연결 수와 데이터베이스가 실제로 유지하는 서버 연결 수.. 2026. 10. 7. PostgreSQL deadlock detected 해결: 40P01·잠금 순서·트랜잭션 재시도 PostgreSQL 로그에 deadlock detected가 나타나면 데이터베이스가 멈춘 것이 아니라 서로의 잠금을 기다리는 트랜잭션 중 하나를 중단해 순환을 끊은 상황입니다. 애플리케이션에는 보통 SQLSTATE 40P01로 전달됩니다. 무작정 max_connections를 올리거나 모든 세션을 종료하기 전에, 어떤 순서로 잠금을 잡았는지와 재시도 범위를 확인하세요. 이 글은 두 세션의 간단한 예와 운영 환경에서 증거를 모으는 방법을 설명합니다.1. 두 트랜잭션이 서로 기다리는 구조테스트 데이터베이스에 accounts(id, balance)라는 테이블과 id 1, 2가 있다고 가정합니다. 세션 A가 1번 행을 수정하고 세션 B가 2번 행을 수정한 뒤, 서로 상대가 잡은 행을 수정하려고 하면 대기 순환이.. 2026. 9. 30. PostgreSQL too many connections 해결: 연결 수 진단·풀 설정·max_connections 점검 그림: 연결 현황을 관찰하고 앱 전체의 풀 예산을 계산한 뒤 누수를 수정·검증하는 흐름입니다. 직접 제작한 개념도입니다.PostgreSQL에서 too many connections 또는 예약된 연결 슬롯 관련 오류가 나오면 새 접속을 받아 줄 여유가 부족할 가능성이 큽니다. 먼저 접속이 어디서 늘어났는지 확인하고, 앱 인스턴스 전체의 풀 크기를 계산하세요. max_connections를 바로 올리면 원인은 남고 메모리·운영 부담만 커질 수 있습니다.1. 오류 발생 위치와 시점을 확인하기앱 로그의 시간·DB 주소·배포 직후 여부를 기록합니다. DB 서버의 슬롯 부족인지, 중간 프록시나 앱 풀의 대기 시간 초과인지 구분해야 합니다. 운영자가 접속할 수 있다면 아래 읽기 전용 쿼리로 설정과 연결 분포를 확인합.. 2026. 9. 27. 관리형 PostgreSQL 선택: 자체 운영·Amazon RDS·Cloud SQL 비교와 비용 체크리스트 그림: 애플리케이션 연결부터 데이터베이스 운영·가용성·복구 시험까지 평가하는 관리형 PostgreSQL 선택 구조입니다. 직접 제작한 개념도입니다.PostgreSQL을 클라우드로 옮길 때 서버 요금만 비교하면 백업 복구, 장애 대응과 업데이트에 드는 일을 놓치기 쉽습니다. 자체 운영은 통제 범위가 넓고, 관리형 서비스는 일부 운영 작업을 서비스 제공자에게 맡길 수 있습니다. Amazon RDS와 Google Cloud SQL을 선택할 때는 기존 클라우드와의 연결, 필요한 확장 기능, 복구 목표와 전체 비용을 같은 조건으로 비교하세요.1. 자체 운영과 관리형 DB의 책임 범위선택장점주의할 점VM·서버 자체 운영OS·설치·확장 구성의 통제 범위가 넓음패치·백업·장애 전환을 직접 운영Amazon RDS for.. 2026. 9. 27. 이전 1 다음
