기술 · 실용 가이드
pg_dump “server version mismatch”? client 경로와 restore target부터 증명하세요
server가 정상이어도 shell, GUI, wrapper, container가 오래된 pg_dump를 실행할 수 있습니다. 실제 binary와 endpoint를 기록하고 compatible client를 고른 뒤 restore test로 backup을 승인하세요.
server가 정상이어도 shell, GUI, wrapper, container가 오래된 pg_dump를 실행할 수 있습니다. 실제 binary와 endpoint를 기록하고 compatible client를 고른 뒤 restore test로 backup을 승인하세요.
pg_dump는 지원되는 이전 server를 dump할 수 있지만 자신보다 새 major server는 거부합니다. shell version 확인은 GUI, CI, wrapper, container가 같은 executable을 쓴다는 증거가 아닙니다.
1. 실패 caller와 정확한 binary를 기록하세요
wrapper, GUI profile, container image, CI step와 stderr, exit, command -v, configured/resolved path, ownership, pg_dump --version을 저장합니다.
같은 execution context에서 확인합니다. shell은 18을 찾지만 service나 image는 17을 호출할 수 있습니다.
2. server endpoint와 major를 증명하세요
secret을 노출하지 않고 host, port, database, user를 기록합니다. PGHOST, PGPORT, service file을 확인하고 server_version과 server_version_num을 조회합니다.
local package나 socket 이름으로 remote server major를 추정하지 않습니다.
3. production 변경 없이 compatible client를 선택하세요
source server보다 낮지 않고 지원 범위인 pg_dump를 사용합니다. wrapper를 explicit packaged binary 또는 pinned client image로 지정하고 server files나 generic symlink를 맹목적으로 바꾸지 않습니다.
client 변경은 database upgrade가 아닙니다. 새 command, connection, output이 증명될 때까지 old runner를 보존합니다.
4. dump contract와 output을 보존하세요
plain, custom, directory format을 의도적으로 선택하고 stderr warning과 zero exit를 저장합니다. roles/tablespaces가 필요하면 pg_dumpall도 포함합니다.
archive는 pg_restore --list, plain SQL은 header를 확인하고 psql -X와 ON_ERROR_STOP으로 restore합니다.
5. 승인 전에 isolated restore를 수행하세요
intended target major의 isolated server에 restore하고 empty database와 globals를 준비하며 모든 error를 기록합니다.
schemas, extensions, ownership, row counts, constraints와 안전한 application check가 통과해야 backup을 승인합니다.
