initdb와 pg_dump 통해서 Postgres DB 통채로 Migrate 하는법 (Feat. Docker)

도커에 대한 기본 이해가 필요하기 때문에 관련 배경지식이 부족한 경우 아래 포스팅을 참고하길 바란다.

https://samori.tistory.com/88

도커 & 쿠버네티스 이해하기

 

준비물:

1. 최신 Postgres 이미지

https://hub.docker.com/_/postgres

postgres - Official Image | Docker Hub

2. 도커 설치, 컴포즈 설치

 

3. 데이터베이스를 통채로 backup,export,dump한 스크립트

 

3.1 pgAdmin4 기준

 

통채로 백업

 

개별 데이터베이스 백업

 

포맷은 커스텀, tar, Plain 등이 있는데

Plain으로 해서 sql 스크립트로 따는 것을 추천한다.

 

3.2 datagrip 과 같은 일반 db툴

 

 

 

여기서 point는 pg_dumpall을 선택해야 role이라든지, tablespaces라든지 같이 스크립트에 넣을 수 있다.

그리고 pg_dumpall을 하게되면 output에서 파일 외에 아무것도 안넣어야 한다.

--format이라든지, 어떤 체크박스라든지 모두 해제하고

--file에 관련된 것만 적어줘야한다.

 

이후 나의 경우 tablespaces는 도커 컨테이너 안에 만들어줘야 했기에

스크립트 파일을 열어 테이블스페이스를 만들어줄 경로를 맞게 수정해줘야 했다.

이따가 docker compose 파일 설명할 때 다시 하겠다.

 

4. Tablespaces 를 CREATE 하기 전 사전작업을 해줄 커스텀 shell 파일

#!/bin/bash

# 테이블스페이스를 만들 경로 생성
mkdir -p /var/lib/postgresql/tablespaces/테이블스페이스명1
mkdir -p /var/lib/postgresql/tablespaces/테이블스페이스명2
...
...
...

# 테이블스페이스를 만들기 전에 권한 부여
cd /var/lib/postgresql/tablespaces
chown postgres: 테이블스페이스명1
chown postgres: 테이블스페이스명2
...
...
...

 

shell 파일을 만드는 이유는 스크립트에서는 도커 컨테이너 내부에 들어가서

리눅스 os가 관리하는 공간에 루트로 경로를 만들고 권하는 부여하지 못하기 때문이다.

이를 위해 커스텀 shell 파일을 만들고 이를 도커파일에 initdb로 넣을 것이다.

initdb.d 는 도커 명령어로 해당 이미지가 처음으로 init 될 때 실행되는 명령어이다.

 

5. Dockerfile (이미지를 만들어줄 친구)

# 포스트그레 디비 이미지와 그 버전
FROM postgres:latest

# 쉘파일을 이미지에 복붙
COPY 커스텀쉘파일명.sh /docker-entrypoint-initdb.d/커스텀쉘파일명.sh

# 쉘파일에 권한 부여
RUN chmod +x /docker-entrypoint-initdb.d/커스텀쉘파일명.sh

# 데이터베이스 export/dump한 스크립트 이미지에 복붙
COPY pg_dump.sql /docker-entrypoint-initdb.d/스크립트.sql

# 포트포워딩할 포트번호
EXPOSE 포트번호

 

위 내용으로 빌드를 하게 되면 도커 이미지가 생성된다.

하지만 컴포즈를 사용 할 것이기 때문에 이미지를 빌드하는 번거로움을 컴포즈에 접목시켜 덜 것이다.

 

6. 컴포즈 파일 (이미지를 만들고 실행시켜줄 친구)

services:
  postgres:
    build: .
    image: 빌드할이미지명
    ports:
      - "포트:포트" 
    volumes:
      - 볼륨마운트명:/var/lib/postgresql/data
    environment:
      POSTGRES_PASSWORD: 비번

volumes:
  볼륨마운트명:

 

이제 위와 같이 설정을 해두면

도커파일이 해당 경로에 있을 경우 자동으로 빌드를 하게 되고 지정해둔 image 이름으로 빌드가 될 것이다.

포트는 저렇게 포워딩 될 것이고

볼륨은 설정한 볼륨마운트명에 맞춰 도커 내부에 생기게 되고 이렇게 생긴 볼륨은

우측의 도커 내부/ 컨테이너 내부 경로와 동기화된다.

이를 사용하기 위해서 마지막에 volumes:를 지정해줘야 한다.

환경에서의 비번은 기본 포스트그레 비번을 설정해주는 것이다.

 

7. 실행

 

이제 컴포즈 파일만 실행시켜주면 된다. 백그라운드/데몬으로 구동하고 싶으면 마지막에 -d 태그를 달아주면 된다.

docker compose -f ./docker-compose.yml up

 

이렇게 되면 가장먼저 빌드가 일어날 것이고

빌드가 일어나면서 도커파일에 설정해둔 명령어들이 순차적으로 일어날 것이고

순차적으로 커스텀쉘파일과 스크립트가 구동이 될텐데 이때 커스텀쉘파일이 컨테이너 내부 경로

/var/lib/postgresql/tablespaces

 

에 경로와 권한을 줬기 때문에 이 경로로 스크립트의 테이블스페이스 CREATE 명령어를 맞춰야 하는 것이다.

예컨데 아래 처럼 되어 있다면

CREATE TABLESPACE 테이블스페이스명1 OWNER 오너 LOCATION E'C:\\docker\\pgdata\\테이블스페이스명1';

 

LOCATION을 바꾸면 되는 것이다.

CREATE TABLESPACE 테이블스페이스명1 OWNER 오너 LOCATION '/var/lib/postgresql/tablespaces/테이블스페이스명1';

 

이렇게 하면 해당 스크립트가 돌 때 해당 경로를 찾을 것이고 테이블스페이스라는 데이터를 넣을 것이다.

 

그렇다면 의문...

기본 경로인 /var/lib/postgresql에 

tablespaces라는 폴더를 추가해주고 거기에 테이블스페이스 경로를 만들고? 테이블스페이스를 만든 것 까진 좋다.

그러면 왜 컴포즈에서는 볼륨 마운트를 애먼 data로 해주었는가?

그것은 마운트 작업이 persist 작업이기 때문이다.

데이터베이스는 데이터를 persist 해야하는데 이 data가 개별적인 도커 컨테이너 환경속에서

내려지고 올려질 때마다 휘발되어지면 안되지 않겠는가?

 

이러한 이유로 영구적으로 저장할 수 있는 마운트를 하는 것이고

바인드 마운트, 볼륨 마운트 중 볼륨 마운트로 도커 내부에 저장한 것 뿐이다.

반면 테이블 스페이스의 경우 그 자체로 데이터만큼의 중요도가 없기 때문에 굳이 볼륨 마운트를 해주지 않았고

컨테이너를 날리고 다시 실행한다 해도 커스텀쉘파일과 스크립트에 재생성하는 명령어가 있기 때문에 걱정하지 않아도 되는 것이다.