PG 마이그레이션 DDL을 브라우저에서 안전/위험 이진 판정… Cloudflare 출신 개발자의 safe-not-safe 공개

내가 진짜 당한 건 DDL 자체가 아니라 락 대기였음. ADD COLUMN은 순간인데 긴 리드 뒤에 있으면 뒤에 있는 쿼리가 다 쌓여 버려서 lock_timeout이랑 재시도가 여태 어떤 마이그레이션 툴보다 도움이 됐음

맞음. lock_timeout이 피해 줄이는데는 확실히 효과가 큼

나도 비슷한 Go 라이브러리 하나 썼는데 https://onwardpg.solberg.is 임

CI에 붙여서 거기서 잡는 게 제일 좋은데, 실제론 잘 안 돌아가더라

컨셉은 좋은데 랜딩 페이지에서 손이 안 감. Go 라이브러리에 쿠키커터 LLM 스타일 아트웍이랑 'Climb from easy to nightmare →' 같은 카피가 왜 필요한지 모르겠고 실행 예제를 앞에 놔야 함

제작자임. 2019-23년에 Cloudflare Postgres 플랫폼 팀 맡으면서 170개 넘는 제품 팀을 지원했는데 스키마 마이그레이션 리뷰 요청이 계속 들어옴. CI 체크도 넣고 베스트 프랙티스 문서도 많이 냈는데 락(리라이트) 동작을 설명해봤자 대부분은 그냥 되냐 안 되냐만 원해서 pg_savior를 포팅하고 libpg-query-node WASM 파서로 브라우저에서 돌림. 이름은 실리콘밸리 Jian-Yang 핫독 앱에서 따옴

좋은데 프로파일을 나눠서 쓸 수 있나? backwards-compatible, revertable, destructive 같은 단계별로 말이야. 요즘 MS SQL 프로젝트도 하고 있어서 그쪽도 지원되면 좋겠고

계속 발전시킬 거면 커맨드라인 툴로 패키징해서 테스트랑 릴리스에 꽂는 방향이 좋겠음

브라우저에서만 도는 방식이 좋은 게, CI에 가기 전에 로컬에서 먼저 대형 사고를 막을 수 있어서 좋음

규칙 기반 체크는 단순해서 좋지만 완전하진 않음. 안전성이 DDL이 아니라 DB 상태에 달려 있는 경우가 많거든. 컬럼 타입 변경도 원래 타입에 따라 no-op이거나 독점 락 테이블 리라이트로 갈림. 나는 아예 라이브 스키마에 마이그레이션을 introspect해서 Postgres가 직접 알려주게 만든 locksmith를 만들었고, DDL용 EXPLAIN 같은 게 있으면 좋겠음

DDL은 강제로 올바른 락을 먼저 acquire하게 하면 좋겠음. ACCESS SHARE 락을 명시적으로 잡고 ALTER를 하는 식으로. 그러면 내가 감당 못하는 락이 걸릴 때 DB가 먹통 대신 그냥 실패할 테니까

locksmith는 내가 왜 이제 알았냐. DB 상태 얘기 완전 맞음. CREATE UNIQUE INDEX도 중간에 비유니크 키가 끼어들면 실패하는데 스냅샷 검증만으로는 못 막음. CONCURRENTLY로 돌리면 DDL 도중에 키가 들어와서 더 웃음

나는 한 발 더 나가서 마이그레이션 버그는 대부분 DDL이 아니라 앱 동작이랑 마이그레이션이 안 맞아서 터진다고 봄. 예전 직장에서 DB에 기능 표시 테이블을 두고 코드가 자기 요구사항이랑 대조해서 안 맞으면 쓰기를 거부하게 했는데, 노후 앱 서버가 살아나는 케이스도 여기서 걸렸음

데이터 들어간 프로덕션 컬럼 타입 변경은 진짜 최후의 수단임. 나는 아예 해본 적도 없고 반드시 필요한 것도 아니고

백그라운드에서 돌아가는 pg_dump는 어떻게 잡을 건데?

Ruby 쪽에는 strong_migrations도 있음 https://github.com/ankane/strong_migrations 체크 설명이 꽤 간단 명료해서 라이브러리 안 써도 참고서로 좋음

이런 마이그레이션 릴터로는 마음이 안 놓임. 나는 reshape라는 제로다운타임 스키마 마이그레이션 툴을 몇 년째 유지보수 중인데 배포 동안 구·신 스키마를 동시에 지원해서 앱 롤아웃까지 제로다운타임으로 만들고 백필도 처리함

우리는 쓰는 스키마 관리 툴이 additive 변경은 마이그레이션 자체를 없애줘서 편한 편임. 파괴적 마이그레이션은 자동 생성을 거부하고 손으로 쓰게 하는데, 그럴 때 이런 툴이 꽤 쓸모 있음