2. 설치 상세

이 장을 마치면: 표준 경로가 아닌 설치(다른 경로, 데이터 볼륨 분리, 다른 포트, root 설치)를 한다.

2.1 설치 옵션 전체

• 설치 스크립트(install_gritdb.sh)는 설치 경로로 복사되지 않는다. 재초기화, 정리, 업그레이드는 압축을 푼 디렉토리에서 실행하므로 설치한 판의 설치 파일을 다음 판 설치 전까지 보관한다(QuickStart 3.4).
• 설치 스크립트는 입력을 묻지 않는다(2.8).

종료 코드:

같이 쓰는 옵션 예(압축을 푼 디렉토리에서):

2.2 다른 경로 · 짧은 경로

• 설치 경로는 --prefix <경로>로 준다. 절대 경로로 주고, 길이는 80자 이하로 한다. 길이 제한은 감독 프로세스 소켓 경로의 OS 한도 때문이다. 경로가 더 길면 GDB-INSTALL-005를 본다.

  echo -n '<경로>' | wc -c
  

  출력이 80 이하면 정상이다.

• 표준 경로가 아니면 이 문서의 ~/gritdb1을 그 경로로 바꿔 읽는다(0장 표기 규칙).

홈 디렉토리 경로 자체가 길면 root가 짧은 경로를 만들어 서비스 계정에 넘기고, 서비스 계정으로 설치한다.

root:

mkdir -p /opt/gritdb1
chown gritdb: /opt/gritdb1

gritdb:

cd ~/pkg/gritdb-*/
./install_gritdb.sh --prefix /opt/gritdb1

• QuickStart 3.2와 3.3으로 확인한다. 이때 명령의 경로만 /opt/gritdb1로 바꾼다.

⚠ 설치한 뒤 설치 경로와 데이터 경로를 옮기거나 이름을 바꾸지 않는다

• 이유: datafiles/의 실경로가 바뀌면 cold file을 잃는다(1.5). cold file은 GritDB 엔진이 분석 조회용으로 열 단위로 저장한 파일이다. 설치 경로가 바뀌면 인스턴스 ID도 바뀐다(2.9). 인스턴스 ID는 설치 경로로 정해지는 값이고, 공유 메모리와 잠금 이름에 쓴다.
• 대신: 다른 경로가 필요하면 새 경로에 새로 설치하고 데이터를 다시 넣는다. 분석계는 다시 받기로 넣는다(8.6). 한 데이터베이스는 8.3의 순서(스키마 → 등록 → 데이터)로 넣는다. 백업과 복구도 같은 실경로로 한다(8.4).

2.3 root 로 설치 (/opt 등)

• 서비스 계정이 쓸 수 없는 자리에 root가 직접 설치할 때 이 방법을 쓴다(2.2의 방법을 쓸 수 없을 때).
• root가 경로를 만들고 소유권을 서비스 계정에 넘기므로 --prefix와 --user를 함께 준다. --prefix를 빼면 root의 홈(/root/gritdb1)에 설치된다.

root(서비스 계정은 QuickStart 2.1대로 미리 만든다):

cd <압축을 푼 디렉토리>
./install_gritdb.sh --prefix /opt/gritdb1 --user gritdb

• stat -L -c '%U %n' /opt/gritdb1 /opt/gritdb1/datafiles/pgdata를 실행해 두 줄 모두 gritdb로 시작하는지 확인한다.
• root로 설치하면 설치 경로가 755로 생긴다. 그래서 서비스 계정이 chmod 700 /opt/gritdb1을 실행한다(11.7). stat -c '%a %U %n' /opt/gritdb1을 실행해 700 gritdb가 나오는지 확인한다.
• 재설치, 업그레이드, 재초기화도 root로 하면 같은 --prefix와 --user를 준다.
  • --user가 없으면 데이터 디렉토리를 새로 만드는 단계가 거부된다(GDB-INSTALL-001).
  • 데이터 디렉토리를 새로 만들지 않는 업그레이드는 --user 없이도 끝나지만, 새 파일의 소유자를 서비스 계정으로 맞추지 않는다.
• 기동과 정지는 서비스 계정으로만 한다.

su - gritdb
/opt/gritdb1/bin/gritdb-start

⚠ root로 기동하지 않는다

• 이유: PostgreSQL은 root로 실행되지 않는다(서버 계정). 그래서 기동이 실패한다. 이때 run/과 log/에 root 소유 파일이 남아 서비스 계정의 기동과 정지를 막을 수 있다.
• 대신: su - gritdb 뒤 기동한다. 서버 부팅 때 기동은 4.6의 User=gritdb로 한다. root로 띄웠으면 4.5로 상태를 보고 find /opt/gritdb1 -user root로 남은 파일을 확인한다.

2.4 데이터 볼륨 재배치

--datafiles /data/gritdb/datafiles    --pgdata /data/gritdb/pgdata

~/gritdb1/                            ~/gritdb1/
└── datafiles → /data/gritdb/datafiles └── datafiles/
    ├── pgdata/                           ├── pgdata → /data/gritdb/pgdata
    ├── checkpoint/                       ├── checkpoint/
    ├── queue/                            ├── queue/
    ├── buffer_spill/                     ├── buffer_spill/
    └── cold_file/                        └── cold_file/

서비스 계정이 <경로>를 만들 수 있어야 하고, <경로>의 상위 디렉토리에도 쓸 수 있어야 한다. 재초기화, 복원, 원복이 그 상위 디렉토리 안에서 이름을 바꾼다(3.1, 3.2, 3.7). mount 지점은 보통 root 소유다. 그래서 root가 그 아래에 서비스 계정 디렉토리를 만들어 넘기고, <경로>는 그 안에 둔다.

root(데이터 볼륨을 mount한 뒤):

mkdir -p /data/gritdb
chown gritdb: /data/gritdb
chmod 700 /data/gritdb

gritdb:

cd ~/pkg/gritdb-*/
./install_gritdb.sh --datafiles /data/gritdb/datafiles

• 설치가 Install complete.로 끝나고 아래 확인 줄이 맞으면 정상이다.
• 상위 디렉토리에 쓸 수 있는지는 test -w "$(dirname "$(readlink -f ~/gritdb1/datafiles)")" && echo OK를 실행해 확인한다. OK가 나오면 정상이다.
• 서비스 계정이 <경로>를 만들 수 없으면 설치가 ▶ 2.1 뒤에 멈춘다. mkdir: cannot create directory … Permission denied 다음 줄에 [ERROR] Relocation target …이나 Cannot resolve … path가 나온다. 이때는 위 root 단계를 한 뒤 같은 명령을 다시 실행한다. --pgdata도 같다.
• <경로>로는 아직 없는 경로나 빈 디렉토리를 준다. ls -A <경로>를 실행해 출력이 없는지 확인한다. 옛 데이터(pgdata/postgresql.conf)가 있으면 설치 스크립트가 묻지 않고 그 데이터를 그대로 쓴다. 이때는 설치 화면에 ▶ 3.1 … SKIP (existing data kept; ...) 줄이 나온다. 다른 설치본이 쓰는 경로를 주지 않는다(2.9).
• 처음 설치할 때 준다. 이미 설치한 경로에 주면 거부된다. 거부 문구는 <설치 경로>/datafiles already exists as a real directory; move it aside first or drop the relocation flag.이다. 이때 설치 파일 복사(▶ 2.1)는 이미 끝났으므로 재배치 옵션을 빼고 같은 설치 파일로 다시 실행해 설치를 마친다.
• 대상 경로가 설치 경로를 품으면(예: 설치 경로의 상위 디렉토리) 거부된다.
• mount 지점 자체가 아니라 그 아래 디렉토리를 준다(1.5). PostgreSQL도 파일 시스템 mount 지점에서 같은 것을 권한다.
• readlink ~/gritdb1/datafiles를 실행해 준 경로(실경로)가 나오는지 확인한다. df -h ~/gritdb1/datafiles/를 실행해 데이터 볼륨이 나오는지 확인한다.

⚠ 재설치나 업그레이드 때 재배치 값을 바꾸지 않는다

• 이유: 다른 --datafiles나 --pgdata 값을 주면 심링크가 새 자리로 바뀐다. --datafiles를 바꾸면 새 빈 데이터로 시작하게 될 수 있다. --pgdata를 바꾸면 옛 데이터와 새 PostgreSQL 데이터가 섞여 기동하지 못할 수 있다.
• 대신: 재설치나 업그레이드 때는 재배치 옵션을 빼거나 처음과 같은 값을 준다. 빼면 처음에 만든 심링크를 그대로 쓴다.

2.5 포트 변경

포트의 단일 원천은 postgresql.conf 관리 블록의 port 줄이다. 바꾸는 방법은 설치 스크립트를 --pgport로 다시 실행하는 것 하나다.

1. 새 포트가 비어 있는지 본다. 설치 스크립트는 포트 충돌을 검사하지 않는다.

   ss -ltn | grep -w <새 포트>
   

   출력이 없으면 포트가 비어 있다.

2. 정지한다. 설치 스크립트는 GritDB가 실행 중인지 검사하지 않는다.

   ~/gritdb1/bin/gritdb-stop
   

   QuickStart 4.5의 정지 확인을 실행해 출력이 없는지 확인한다.

3. 설치한 판과 같은 설치 파일의 압축을 푼 디렉토리에서 다시 실행한다. 처음 설치 때 준 옵션(--prefix, --no-config, root의 --user)을 같이 준다.

   • 실행 전에 관리 블록 표식 두 줄을 QuickStart GDB-INSTALL-004의 판별대로 확인한다. grep -n 'gritdb managed' ~/gritdb1/datafiles/pgdata/postgresql.conf를 실행해 # >>> gritdb managed begin과 # <<< gritdb managed end가 한 번씩 나오면 정상이다.

   cd <설치한 판의 압축을 푼 디렉토리>
   jq -r .product_version manifest.json ~/gritdb1/share/gritdb/manifest.json
   

   두 줄이 같으면 설치한 판이므로 실행한다(3.1의 4번과 같다).

   ./install_gritdb.sh --pgport <새 포트>
   

   • [INFO] Upgrading existing 1.x install in place: <설치 경로>는 같은 자리에 같은 판을 다시 깐다는 뜻이며 정상이다.
   • ▶ 3.1 단계는 SKIP (existing data kept; ...)로 나오고, 설치 확인에는 pg port = <새 포트>가 나온다.
   • 관리 블록을 다시 써서 파일 끝에 붙인다. 그래서 블록 안 값은 설치 기본값으로 돌아가고, 블록 밖에 직접 쓴 같은 설정은 블록 값에 덮인다. ALTER SYSTEM 값은 남는다(5.2와 5.3).

4. 기동하고 확인한다.

   ~/gritdb1/bin/gritdb-start
   ~/gritdb1/bin/pg_isready -p <새 포트> -d postgres
   

   • pg_isready는 접속을 받는지만 본다.

   • 기동 화면의 PG port: 줄이 새 포트이고 pg_isready가 accepting connections를 내면 정상이다.

• 바꾼 뒤에는 모든 접속 명령의 -p를 새 포트로 바꾼다. 응용 프로그램, CDC와 ETL 도구, 리포트와 BI 도구의 접속 설정과 방화벽(1.6)도 새 포트로 바꾼다.
• ALTER SYSTEM SET port를 쓰지 않는다. GritDB 명령이 보는 포트와 PostgreSQL이 실제로 쓰는 포트가 달라진다.

2.6 튜닝 블록 생략 (--no-config)

• --no-config는 관리 블록에 필수 블록과 포트만 쓰고 튜닝 블록(5.2)은 쓰지 않는다.

• 재설치, 업그레이드, 재초기화마다 다시 준다. 빼면 튜닝 블록이 다시 들어간다.

• 튜닝 블록이 없으면 그 8개 설정(메모리 값 셋 포함)은 PostgreSQL 기본값으로 돈다. 예를 들어 max_wal_size는 1GB다. 이때는 첫 기동 뒤 같은 설정을 ALTER SYSTEM으로 넣고 다시 기동한다(5.3과 5.4). 테이블 등록과 적재는 다시 기동한 뒤 한다.

• 재설치 전 관리 블록 표식 확인은 2.5의 3번에 있다.

• 튜닝 블록의 설정을 모두 직접 관리할 때 쓴다. 몇 개만 바꾸려면 블록을 두고 ALTER SYSTEM으로 덮는다. ALTER SYSTEM 값이 블록보다 먼저다.

• 작은 서버도 튜닝 블록을 둔다. shared_buffers 등 메모리 값 셋은 설치 스크립트가 서버 메모리로 정한다(5.5).

• 관리 블록을 보고 튜닝 블록(5.2)의 줄이 없는지 확인한다.

  sed -n '/^# >>> gritdb managed begin/,/^# <<< gritdb managed end/p' ~/gritdb1/datafiles/pgdata/postgresql.conf
  

2.7 설치 로그 읽기

• 설치 로그는 ~/gritdb1/log/install_gritdb_<일시>.log에 있다. 실행할 때마다 새 파일이다.
• 로그에는 단계 줄([<시각>] 1.1 …부터 [<시각>] 5.1 …까지, 화면에서는 ▶ 1.1부터 ▶ 5.1까지)과 단계마다 실행한 명령의 출력이 담긴다.
• 단계 밖의 [INFO], [WARN], [ERROR] 줄은 화면에만 나온다. 예를 들면 업그레이드, 재배치, 재초기화 알림과 시작 전 거부다. 설치 경로를 정하기 전에 거부되면 로그 파일이 생기지 않으므로 화면 출력도 남긴다.

cd <실행할 판의 압축을 푼 디렉토리>
./install_gritdb.sh <옵션> 2>&1 | tee ~/install_console_$(date +%Y%m%d_%H%M%S).log
echo "exit=${PIPESTATUS[0]}"

• 설치 확인(CHECK) 판독은 QuickStart 3.2에 있다.

2.8 무인 설치

• 설치 스크립트는 입력을 묻지 않는다. --purge-old도 묻지 않고 지운다(3.3).
• root로 돌리면 --user를 준다(2.3).
• 판정할 때 종료 코드만 보지 않는다. 설치 확인 출력의 FAIL 줄과 Install complete. 줄을 함께 본다.

cd <압축을 푼 디렉토리>
./install_gritdb.sh <옵션> > ~/install_console.log 2>&1
rc=$?
if [ "$rc" -eq 0 ] && grep -q 'Install complete' ~/install_console.log && ! grep -q 'missing!' ~/install_console.log; then
  echo "INSTALL OK"
else
  echo "INSTALL FAILED (rc=$rc)"
fi

• INSTALL OK가 나오면 정상이다.
• INSTALL FAILED가 나오면 ~/install_console.log를 2.7대로 읽는다.

2.9 한 서버에 설치본 여러 개

• 인스턴스 ID는 <설치 경로>/bin/grit_instance_id <설치 경로>로 확인한다.

• ⚠ 설치본마다 GritDB 엔진이 물리 메모리 비율로 메모리를 잡는다(1.3). 설치본이 둘이면 메모리를 넘겨 쓰므로 시험과 검증 서버에서만 쓴다.

• 프로세스 이름은 설치본이 달라도 같다. 그래서 QuickStart 4.5의 정지 확인(pgrep)은 모든 설치본의 프로세스를 보여 준다. 설치본은 실행 파일 경로로 가른다.

for p in $(pgrep -u gritdb -x 'GritAdmin|GritSurfer|GritCatalog|postgres'); do
  echo "$p $(readlink /proc/$p/exe)"
done

• 출력에는 PID와 실행 파일 경로(<설치 경로>/bin/…)가 나온다. 경로 안의 설치 경로로 설치본을 가른다.
• 공유 메모리를 정리할 때는 그 설치본의 인스턴스 ID로 끝나는 것만 지운다. QuickStart GDB-SHUTDOWN-001의 ~/gritdb1을 그 설치 경로로 바꾼다.
• 상태는 설치본마다 4.5로 확인한다. PID 파일과 잠금은 설치 경로마다 따로다.

2.10 설치 뒤 할 일

1. OS 설정을 다시 확인한다(1.4). RemoveIPC(1.4 ⑤)는 첫 기동 전에 끝낸다.
2. 기동하고 정상인지 본다(QuickStart 4.1~4.3). TMPDIR을 정했으면 QuickStart 4.1에서 1.4 ④ 꼴로 준다. 3번과 6번은 떠 있는 서버에 접속해서 한다.
3. 인증을 바꾼다(11.3). 설치 기본값은 trust이므로 이 서버의 어느 OS 사용자든 비밀번호 없이 superuser로 붙는다. 다른 사용자가 로그인하는 서버면 첫 기동 전에 11.3의 2번을 하고, 기동 바로 뒤 다른 일보다 먼저 다른 번호를 한다(QuickStart 3.4).
4. 파일과 디렉토리 권한을 좁힌다(11.7). 설치 경로와 재배치 실경로는 700으로 맞춘다. root로 설치했으면(2.3) 설치 경로가 755로 생긴다.
5. 원격 접속이 필요하면 연다(11.4).
6. 설정을 맞춘다(5장: 작은 서버, 시간대).
7. 서버 부팅 때 기동을 정한다(4.6).
8. 백업 계획을 세우고 첫 복구 시험을 한다(8장).
9. 운영 시작 전 점검을 한다(7.7).

문제가 생기면

• QuickStart 7장의 GDB-INSTALL 계열과 TroubleShooting을 본다.

더 알아보기

• 재초기화와 업그레이드는 3장, 설정은 5장을 본다.
• PostgreSQL 17 문서: 데이터베이스 클러스터 만들기, 서버 계정, 접속 설정, trust 인증