3. 재초기화 · 업그레이드 · 제거

이 장을 마치면: 데이터를 새로 만들거나 되돌리고, 새 버전으로 올리거나 되돌리고, GritDB를 걷어낸다.

• 이 장의 명령은 압축을 푼 설치 파일 디렉토리에서 실행한다. 설치 스크립트가 설치 경로에 없기 때문이다.

3.1 재초기화 (--reinit-data)

재초기화는 데이터를 새로 만든다. 기존 데이터는 지우지 않고 이름을 바꿔 남긴다.

1. 분석계면 먼저 subscription을 치운다(6.4.4의 1~3번). 치우지 않으면 운영 DB 슬롯이 WAL을 계속 붙잡는다.

2. 정지한다.

   ~/gritdb1/bin/gritdb-stop
   

   QuickStart 4.5의 정지 확인을 실행해 출력이 없는지 확인한다. 실행 중에 설치 스크립트를 돌리면 대개 ▶ 2.1에서 멈춘다. 실행 중인 파일은 덮지 못하기 때문이다(Text file busy). 이때는 정지한 뒤 같은 명령을 다시 실행한다. 다른 경로의 PostgreSQL이 이 데이터를 쓰고 있으면 A PostgreSQL instance is running on this data directory (PID: <pid>).로 거부된다.

3. 데이터를 재배치했으면(2.4) 서비스 계정이 실경로의 상위 디렉토리에 쓸 수 있는지 본다. 데이터 볼륨이 mount 지점이면 상위 파일시스템의 여유도 본다(아래 경고).

   test -w "$(dirname "$(readlink -f ~/gritdb1/datafiles)")" && echo OK
   

   • OK가 나오면 정상이다. --pgdata로 재배치했으면 ~/gritdb1/datafiles/pgdata로도 같은 확인을 한다.
   • 그렇지 않으면 root가 그 디렉토리를 서비스 계정에 넘기거나, root로 --user를 주고 재초기화한다(2.3). 이름을 바꾸지 못하면 Rename failed; nothing was lost, rolled back.로 멈추고 데이터는 그대로다.

4. 재초기화한다. 표준 경로가 아니면 처음 설치 때의 --prefix를 같이 준다. root면 --user도, --no-config로 설치했으면 그것도 같이 준다(2.3, 2.6).

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

   두 줄이 같으면 설치한 판이므로 아래 명령을 실행한다. 다르면 실행하지 않는다. 이때는 설치한 판의 설치 파일을 찾거나 다시 반입한다(QuickStart 2.3).

   ./install_gritdb.sh --reinit-data
   

   화면에 Previous data preserved with suffix .old-<일시> 줄이 나오고 ▶ 3.1 단계가 OK인지 확인한다. 첫 줄 [INFO] Upgrading existing 1.x install in place: <설치 경로>는 재초기화에도 나오는 정상 출력이다.

   • ~/pkg/gritdb-*/ 꼴로 들어가지 않는다. 업그레이드(3.5) 뒤에는 압축을 푼 디렉토리가 둘이라 cd가 실패하고, 다음 줄이 지금 디렉토리에서 실행된다.
   • --pgdata로 재배치했으면 기동 전에 같은 --pgdata 값으로 설치 스크립트를 --reinit-data 없이 한 번 더 실행한다. 재초기화가 datafiles/pgdata 링크를 옛 보관본과 함께 옮기기 때문이다. 이때 ▶ 3.1은 SKIP (existing data kept; ...)로 나온다. readlink ~/gritdb1/datafiles/pgdata를 실행해 <pgdata 실경로>가 나오는지 확인한다.

5. 운영자 설정을 다시 넣는다(아래 경고).

6. 기동한 뒤 QuickStart 4.2와 4.3으로 확인한다. 이어서 보안 설정을 다시 한다. 함수 실행 권한은 template1과 postgres부터 거둔다(11.5). 새 datafiles 실경로는 775로 생기므로 chmod 700을 실행한다(11.7). 그다음 데이터베이스, 테이블, 등록을 다시 만들고(6장) 11.10 점검표로 확인한다. 분석계는 처음부터 받는다(6.4.1).

   • 새 데이터의 함수 실행 권한은 설치 기본값이라 모든 계정에 있다(11.5). template1에서 먼저 거두면 그 뒤에 만드는 데이터베이스도 거둔 채로 생긴다.

• 옛 데이터는 <datafiles 실경로>.old-<YYYYmmddHHMMSS>로 이름만 바뀐다(표준 경로에서는 ~/gritdb1/datafiles.old-<일시>). --pgdata로 재배치했으면 <pgdata 실경로>.old-<일시>도 생긴다. 되돌리려면 3.2를, 지우려면 3.3을 본다.
• 포트는 이어받는다.
• config/(GritDB 엔진 설정)와 log/는 그대로 남는다.

⚠ 새 데이터에는 운영자가 넣은 설정이 없다

• 이유: pg_hba.conf, postgresql.conf의 블록 밖 줄, ALTER SYSTEM 값은 이름이 바뀐 옛 디렉토리 안에만 남는다. 그대로 기동하면 인증이 설치 기본값인 trust로 돌아간다(11.2).
• 대신: 기동 전에 pg_hba.conf를 옛 파일과 비교해 고친다(11.3). postgresql.conf는 관리 블록 밖의 차이만 새 파일에 옮긴다. 관리 블록은 설치가 다시 썼기 때문이다(5.2). ALTER SYSTEM 값은 옛 postgresql.auto.conf를 보고 기동 뒤 다시 넣는다(5.3). 다시 넣은 값은 5.3의 확인 쿼리로 확인한다. pending_restart가 t면 재기동한다.

OLD=$(ls -d "$(readlink -f ~/gritdb1/datafiles)".old-* | tail -1)
P=$(readlink -f ~/gritdb1/datafiles/pgdata)
OLDP=$(ls -d "$P".old-* 2>/dev/null | tail -1)
OLDP=${OLDP:-$OLD/pgdata}
diff "$OLDP/pg_hba.conf" "$P/pg_hba.conf"
diff "$OLDP/postgresql.conf" "$P/postgresql.conf"
cat "$OLDP/postgresql.auto.conf"

• --pgdata로 재배치했으면 위 명령이 <pgdata 실경로>.old-<일시>/를 고른다. 이때는 4번에서 설치 스크립트를 한 번 더 실행한 뒤에 한다. 옛 보관본 안의 pgdata 링크는 새 데이터를 가리킨다.

• ⚠ 데이터 볼륨이 mount 지점이면 재초기화가 옛 데이터를 상위 파일시스템(예: /)의 <mount 지점>.old-<일시>로 옮긴다. 이때 여유가 없으면 그 파일시스템이 차므로 먼저 df -h <상위 디렉토리>로 여유를 본다.

3.2 이전 데이터 복원

*.old-<일시>를 원래 이름으로 되돌린다. 같은 실경로로 되돌린다(1.5).

1. 정지하고 QuickStart 4.5의 정지 확인을 실행한다.

2. 되돌릴 보관본을 고른다.

   D=$(readlink -f ~/gritdb1/datafiles)
   ls -d "$D".old-*
   

3. 지금 데이터를 이름을 바꿔 남기고, 보관본을 원래 이름으로 되돌린다.

   mv "$D" "$D.cur-$(date +%Y%m%d%H%M%S)"
   mv "$D.old-<일시>" "$D"
   

   • --pgdata로 재배치했으면 <pgdata 실경로>도 같은 방법으로 되돌린다. 이때 같은 <일시>를 쓴다. 보관본의 datafiles.old-<일시>/pgdata 링크는 <pgdata 실경로>를 가리킨다. 그래서 두 곳을 같은 <일시>로 맞춰야 옛 데이터가 이어진다.
   • 데이터 볼륨이 mount 지점이면 디렉토리째가 아니라 안의 내용을 옮긴다. 먼저 지금 내용을 다른 자리로 옮기고, <mount 지점>.old-<일시>/ 안의 것을 <mount 지점>/로 옮긴다. 상위 파일시스템의 여유는 3.1을 본다.

4. 정상 정지 표식이 있으면 이름을 바꿔 둔다. 그러면 다음 기동이 복구 과정을 거친다.

   mv ~/gritdb1/run/grit_admin_clean_shutdown ~/gritdb1/run/grit_admin_clean_shutdown.cur-$(date +%Y%m%d%H%M%S)
   

   파일이 없다는 오류가 나오면 정상이다. 이때는 이 단계를 건너뛴다.

5. 기동하고 8.5로 확인한다.

• 분석계에서는 복원한 데이터 시점 뒤의 운영 DB 변경이 다시 오지 않는다. 그래서 복원 뒤 8.6으로 다시 받는다(8.4 경고).
• .cur-<일시>는 확인이 끝난 뒤 지운다. 이때 3.3의 안전 삭제와 같은 규정을 따른다.

3.3 이전 데이터 정리 (--purge-old)

• 지우는 것: <datafiles 실경로>.old-*, <pgdata 실경로>.old-*(--pgdata 재배치), run/grit_admin_clean_shutdown.old-*
• 지우지 않는 것: .cur-*(3.2), .failed-*(3.7), .before_restore_*(8.4). 이 셋은 확인이 끝나면 직접 지운다.
• 확인 질문 없이 지운다. 같은 실행에 --reinit-data가 있으면 재초기화보다 먼저 지운다.
• --purge-old만 주어도 설치 스크립트는 같은 판을 제자리에 다시 설치한다. 그래서 GritDB를 정지하고, 설치한 판과 같은 설치 파일의 압축을 푼 디렉토리에서 실행한다. 이때 처음 설치 때의 옵션(--prefix, --no-config, root의 --user)을 같이 준다.

⚠ --purge-old는 확인 없이 지우고 되돌릴 수 없다

• 이유: 옛 보관본은 재초기화를 되돌리는 유일한 자료다(3.2).
• 대신: 먼저 아래 목록을 보고, 남길 것은 백업한 뒤(8.2) 실행한다.

1. 지울 것을 본다.

   D=$(readlink -f ~/gritdb1/datafiles)
   P=$(readlink -f ~/gritdb1/datafiles/pgdata)
   ls -d "$D".old-* "$P".old-* ~/gritdb1/run/grit_admin_clean_shutdown.old-* 2>/dev/null
   

2. 정지한 뒤 설치한 판의 압축을 푼 디렉토리에서 지운다. 3.1의 4번처럼 판을 먼저 견준다.

   cd <설치한 판의 압축을 푼 디렉토리>
   ./install_gritdb.sh --purge-old
   

   1번 명령을 다시 실행해 출력이 없는지 확인한다. 화면에는 지운 것마다 [INFO] Purging <경로>가 나오고, ▶ 3.1은 SKIP (existing data kept; ...)로 나온다. 데이터는 그대로다.

   • --pgdata로 재배치하지 않았으면 옛 pgdata는 $D.old-* 안에 있다. 이때 $P.old-*는 따로 생기지 않는다.

• --reinit-data --purge-old를 함께 주면 옛 보관본을 지운 뒤 지금 데이터를 새 보관본으로 남긴다. 그래서 보관본이 하나만 남는다. ⚠ 확인 없이 지운다.
• --purge-old는 일반 삭제다. 금융권 등에서 안전 삭제가 필요하면 위 대상을 기관 규정의 도구(shred 등)로 지운다.

3.4 업그레이드 전 점검

• QuickStart 2.3의 gritdb-* 꼴이 두 판을 함께 잡으면 새 판이 풀리지 않고 옛 판을 검수한다. 그래서 2번에서 옛 판 파일을 옮긴다. 원복(3.7)은 3.4의 사본으로 하므로 옛 설치 파일을 쓰지 않는다.
• 분석계면 8번 정지부터 3.5의 6번 기동까지 걸릴 시간이 4.7의 “멈춰 둘 수 있는 시간” 안인지 먼저 본다. 넘으면 업그레이드 뒤 처음부터 다시 받는다(8.6). 이때는 그 시간까지 작업 시간으로 잡는다. ④의 복사 시간은 8.2를 본다.

① 등록 테이블, 행 수, 조회 함수(①~④는 $UB가 있는 같은 셸에서 한다)

UB=<백업 자리>/gritdb_before_upgrade_$(date +%Y%m%d_%H%M%S)
mkdir -p "$UB"
~/gritdb1/bin/psql -p 5432 -d <db> -Atc "SELECT schema_name, table_name FROM get_gritsurfer_tables() ORDER BY 1, 2" > "$UB/tables_<db>.txt"
~/gritdb1/bin/psql -p 5432 -d <db> -Atc "SELECT count(*), sum(<숫자 열>) FROM <s>.<t>" > "$UB/count_<s>.<t>.txt"
~/gritdb1/bin/psql -p 5432 -d <db> -c '\df get_gritsurfer_*' > "$UB/functions_<db>.txt"

• 첫 두 줄은 한 번만 실행한다. 셋째와 다섯째 줄은 데이터베이스마다, 넷째 줄은 표본 테이블마다 실행한다. 표본은 7.10의 1번 기준을 따르고, 파일 이름은 8.2의 2번과 같다.
• <백업 자리>는 데이터 볼륨이 아닌 디스크다. ④의 사본도 이 자리에 둔다. 업그레이드 뒤 대조(3.5의 8번)와 원복(3.7)이 이 파일을 쓴다.

② 운영자 설정

~/gritdb1/bin/psql -p 5432 -d postgres -Atc "SELECT name, setting, source, sourcefile FROM pg_settings WHERE source NOT IN ('default', 'override') ORDER BY 1;" > "$UB/settings_before.txt"

• 튜닝 블록 값은 새 판의 기본값으로 다시 써진다. 메모리 값 셋은 그때의 서버 메모리로 다시 계산한다(5.5). ALTER SYSTEM 값은 남는다(5.2와 5.3). 열의 뜻은 pg_settings에 있다.
• sourcefile은 값이 온 파일이다. postgresql.conf면 튜닝 블록이나 블록 밖 줄에서, postgresql.auto.conf면 ALTER SYSTEM에서 온 값이다. 업그레이드 뒤 견준다(3.5의 7번).

③ GritDB 엔진 설정 키 — 새 판에 더해진 키를 찾는다. 설치 스크립트는 기존 설정 파일을 덮지 않는다. 키가 하나라도 없으면 GritDB가 기동하지 않는다(5.6).

cd <새로 압축을 푼 디렉토리>
for f in etc/templates/grit_*.config; do
  diff <(grep -oE '^[a-z0-9_.]+' "$f" | sort -u) <(grep -oE '^[a-z0-9_.]+' ~/gritdb1/config/"$(basename "$f")" | sort -u)
done

• 출력이 없으면 키가 같다.
• <로 시작하는 줄은 새 판에 더해진 키다. 업그레이드 뒤 그 파일에 새 판 템플릿의 줄을 더한다(3.5의 5번).

④ 백업 — 8번 정지 뒤 설치 경로 전체를 복사한다($UB가 있는 ①과 같은 셸). 원복(3.7)은 이 사본으로 한다.

readlink -f ~/gritdb1/datafiles ~/gritdb1/datafiles/pgdata > "$UB/realpaths.txt"
tar --sparse -cf "$UB/gritdb1.tar" -C ~ gritdb1 ; echo "gritdb1.tar = $?"

• ls -ld ~/gritdb1/datafiles ~/gritdb1/datafiles/pgdata의 첫 글자가 l이면 심링크다. 심링크는 tar가 링크만 담으므로 그 실경로를 따로 담는다.
• datafiles가 심링크면(--datafiles, 2.4) tar --sparse -cf "$UB/datafiles.tar" -C "$(readlink -f ~/gritdb1/datafiles)" . ; echo "datafiles.tar = $?"를 실행한다.
• datafiles/pgdata가 심링크면(--pgdata, 2.4) tar --sparse -cf "$UB/pgdata.tar" -C "$(readlink -f ~/gritdb1/datafiles/pgdata)" . ; echo "pgdata.tar = $?"를 실행한다.
• 모든 줄이 = 0이면 정상이다. 0이 아니면 그 사본으로 원복할 수 없으므로 고쳐서 다시 한다.
• -z로 압축하지 않는다. CPU 하나로 압축하므로 멈춰 있는 시간이 는다. 시간과 공간은 8.2를 본다.

3.5 패치 · minor 업그레이드

• 패치는 같은 판(1.1)의 새 설치 파일이다. minor 업그레이드에서는 같은 major 안에서 판이 오른다. 둘 다 같은 설치 경로에 제자리로 설치한다.
• 데이터, 포트, config/, postgresql.conf의 블록 밖 줄, ALTER SYSTEM 값은 유지된다. 블록 밖 줄 가운데 블록과 같은 설정은 블록 값에 덮인다(2.5).
• 설치 파일(bin/, lib/, share/ …)과 관리 블록은 다시 써진다. 관리 블록의 튜닝 값은 새 기본값이 된다.

1. 3.4 점검을 끝낸다.

2. GritDB가 정지했는지 확인한다(QuickStart 4.5). 실행 중이면 3.1의 2번을 본다.

3. 새로 압축을 푼 디렉토리에서 설치한다. 처음 설치 때의 --prefix, --no-config, root의 --user를 같이 준다. 재배치 옵션은 빼거나 같은 값을 준다(2.4).

   cd <새로 압축을 푼 디렉토리>
   ./install_gritdb.sh
   

   • 화면에는 Upgrading existing 1.x install in place: <설치 경로>가 나오고, ▶ 3.1 단계는 SKIP (existing data kept; ...)로 나온다. 마지막 줄은 Install complete.다.

4. 설치를 확인한다.

   jq -r .product_version ~/gritdb1/share/gritdb/manifest.json
   

   새 판 번호가 나오면 정상이다.

5. 3.4의 ③에서 찾은 새 키를 ~/gritdb1/config/의 그 파일에 더한다(5.6).

6. 기동한 뒤 QuickStart 4.2와 4.3으로 확인한다.

7. 운영자 설정을 견준다. $UB는 3.4의 백업 자리다. 셸이 바뀌었으면 UB=<그 자리>로 다시 정한다.

   ~/gritdb1/bin/psql -p 5432 -d postgres -Atc "SELECT name, setting, source, sourcefile FROM pg_settings WHERE source NOT IN ('default', 'override') ORDER BY 1;" > "$UB/settings_after.txt"
   diff "$UB/settings_before.txt" "$UB/settings_after.txt"
   

   • 다른 줄은 새 판이 바꾼 값이다(튜닝 블록에서는 새 기본값). 그대로 둘지 정한다.
   • 튜닝 블록에서 바꿔 쓰던 값이면 ALTER SYSTEM으로 다시 정한다(5.3). 재기동이 필요한 값은 5.4를 본다.

8. 8.5의 2~5번으로 대조한다. 이때 <백업 자리>/<백업 이름>은 $UB로 바꿔 읽는다.

9. 데이터베이스마다 조회 함수를 확인한다. 확장 SQL은 제자리에서 갱신되지 않으므로 함수 서명이 새 판과 다를 수 있다.

   ~/gritdb1/bin/psql -p 5432 -d <db> -c '\df get_gritsurfer_*'
   

   • 서명이 새 판의 A.3과 같으면 정상이다.
   • 다르면 그 함수를 쓰지 않고 지원 문의(0장)를 한다.
   • ALTER EXTENSION gritsurfer UPDATE로는 바뀌지 않는다. \dx gritsurfer의 판 번호는 판이 올라도 같다. 그러므로 이 명령은 실행하지 않는다.

10. 8번과 9번이 맞으면 응용 프로그램, 리포트, BI 도구, CDC, ETL 도구를 다시 연다. 원복(3.7)을 할지는 그 전에 정한다. 다시 연 뒤에 들어온 쓰기는 원복하면 사라지기 때문이다.

3.6 major 업그레이드 (예: 1.x → 2.x)

• major가 바뀌는 판은 새 경로에 설치한다. 기본 경로는 ~/gritdb<major>다(예: ~/gritdb2). 같은 경로에 설치하면 Prefix <경로> holds major version <n>; this dist is major <m>.로 거부된다. 옛 설치본은 그대로 남는다.
• 새 경로 설치는 QuickStart 3장을 본다. 다른 포트로 설치한다(--pgport, 2.1, 2.9). 한 서버에 두 판을 두면 메모리를 넘겨 쓴다(2.9). 그래서 두 판은 옮기는 동안만 둔다.
• 분석계면 새 경로에 새 판을 설치하고 운영 DB에서 다시 받는다(6.4.1과 8.6). 이때는 데이터를 옮길 필요가 없다. 그동안 운영 DB에 슬롯이 하나 더 생긴다(6.4.3). 다 받은 뒤 옛 판의 subscription을 치운다(6.4.4).
• 한 데이터베이스 구성이면 새 판에 스키마 → 등록 → 데이터 순서로 옮긴다(8.3). PostgreSQL의 pg_upgrade는 쓰지 않는다(A.1). 그 판의 Admin 3장을 보고 지원 문의(0장)를 한다.

3.7 원복

업그레이드가 실패하면 3.4의 사본으로 되돌린다.

⚠ 원복하면 3.4의 백업 때로 돌아간다

• 이유: 사본을 통째로 되돌린다. 한 데이터베이스 구성에서는 사본을 만든 뒤에 들어온 쓰기(3.5의 10번에서 응용을 다시 연 뒤)가 사라진다.
• 대신: 응용을 다시 연 뒤라면 원복하기 전에 지원 문의(0장)를 한다. 분석계는 아래 5번(다시 받기)을 따른다.

1. 정지하고 QuickStart 4.5의 정지 확인을 실행한다.

2. 지금 설치 경로의 이름을 바꿔 남긴다. 실경로를 먼저 구한다. 이름을 바꾼 뒤에는 링크로 찾을 수 없기 때문이다.

   D=$(readlink -f ~/gritdb1/datafiles)
   P=$(readlink -f ~/gritdb1/datafiles/pgdata)
   T=$(date +%Y%m%d%H%M%S)
   mv ~/gritdb1 ~/gritdb1.failed-$T
   

   • printf '%s\n' "$D" "$P" | diff - "$UB/realpaths.txt"를 실행해 출력이 없는지 확인한다. $UB는 3.4의 백업 자리다.
   • datafiles가 심링크였으면 $D도 남긴다. 이때는 mv "$D" "$D.failed-$T", mkdir "$D", chmod 700 "$D"를 차례로 실행한다. mount 지점이면 안의 내용을 옮긴다(3.2).
   • datafiles/pgdata가 심링크였으면 $P도 같은 방법으로 남긴다.

3. 3.4의 사본을 같은 실경로로 되돌린다.

   tar -xf "$UB/gritdb1.tar" -C ~
   

   • datafiles가 심링크였으면 tar -xf "$UB/datafiles.tar" -C "$D"를 실행한다.
   • datafiles/pgdata가 심링크였으면 tar -xf "$UB/pgdata.tar" -C "$P"를 실행한다.
   • readlink -f ~/gritdb1/datafiles ~/gritdb1/datafiles/pgdata | diff - "$UB/realpaths.txt"를 실행해 출력이 없는지 확인한다.

4. 기동한 뒤 jq -r .product_version ~/gritdb1/share/gritdb/manifest.json을 실행해 옛 판 번호가 나오는지 본다. 그다음 8.5로 확인한다. 이때 <백업 자리>/<백업 이름>은 $UB로 바꿔 읽는다.

5. 분석계는 새 판으로 한 번이라도 기동했으면(3.5의 6번) 8.6으로 다시 받는다. 기동하면 subscription이 운영 DB 슬롯에서 바로 받기 시작하고, 운영 DB 슬롯은 뒤로 가지 않는다(8.4 경고).

• 옛 판 설치 파일을 같은 경로에 다시 설치하지 않는다. 제자리 설치는 새 판에만 있는 파일을 남겨 두 판의 파일이 섞인다. 대신 사본을 통째로 되돌린다.

⚠ 낮은 버전 설치 파일로 덮어쓰는 다운그레이드는 지원하지 않는다

• 이유: 설치 스크립트는 판 번호를 비교하지 않아 막지 않는다. 덮어쓰면 두 판의 파일이 섞인다.
• 대신: 3.4의 사본으로 되돌린다(위 절차).

3.8 제거 · 파기

⚠ 제거는 되돌릴 수 없다

• 이유: 설치 경로와 데이터 볼륨을 지우면 데이터, 설정, 로그가 모두 사라진다.
• 대신: 데이터를 남길지 먼저 정한다. 남기려면 정지 후 백업(8.2)을 끝낸 뒤 지운다.

1. 분석계면 먼저 subscription을 치운다(6.4.4). 운영 DB에 슬롯을 남기지 않는다.

2. 정지하고 QuickStart 4.5의 정지 확인을 실행한다.

3. 데이터를 남기려면 백업한다(8.2).

4. 지울 자리를 적는다. 설치 경로를 지우기 전에 인스턴스 ID와 실경로를 구한다.

   ~/gritdb1/bin/grit_instance_id ~/gritdb1
   readlink -f ~/gritdb1/datafiles
   readlink -f ~/gritdb1/datafiles/pgdata
   cat /proc/sys/kernel/core_pattern
   

   • 둘째 줄과 셋째 줄은 datafiles와 pgdata의 실경로다. 재배치하지 않았으면 셋째 줄은 <둘째 줄>/pgdata이므로 따로 지울 것이 없다.

5. QuickStart GDB-SHUTDOWN-001의 조치로 공유 메모리 잔여를 지운다. 4번의 인스턴스 ID로 끝나는 것만 지운다.

6. 설치 경로, 재배치한 자리, 보관본(.old-* 등)을 지운다.

   rm -rf ~/gritdb1 ~/gritdb1.failed-*
   

   • 재배치한 자리에서는 4번의 두 실경로와 그 옆의 .old-*(3.1), .cur-*(3.2), .failed-*(3.7), .before_restore_*(8.4)를 모두 지운다. rm -rf ~/gritdb1은 심링크만 지우고, 심링크가 가리키는 데이터는 남긴다.
   • 실경로가 mount 지점이면(mountpoint -q <실경로> && echo mount) rm -rf는 안의 내용만 지우고 Device or resource busy로 끝난다. 이때는 root가 umount <실경로>를 실행하고, /etc/fstab의 그 줄을 지우고, 빈 디렉토리를 rmdir로 지운다. mount 지점은 3.1과 3.2를 본다.
   • 설치 경로의 상위 디렉토리가 root 것이면(/opt 등, 2.2와 2.3) 서비스 계정이 실행한 rm -rf는 안의 내용만 지우고 Permission denied로 끝난다. 이때는 root가 rmdir <설치 경로>로 빈 디렉토리를 지운다.
   • 압축을 푼 설치 파일(~/pkg)도 지운다.

7. 그 밖의 자리를 정리한다. core 파일(4번에서 구한 core_pattern 자리), 기동 셸 TMPDIR의 __tkidx_spill_*.tmp(1.4), 서버 부팅 때 기동 파일(4.6), /etc/security/limits.conf의 줄(1.4), 방화벽 규칙(1.6), /etc/logrotate.d/gritdb(9.4)를 지운다. /etc/systemd/logind.conf.d/gritdb.conf(1.4 ⑤)는 같은 서버에 이 설정이 필요한 다른 서비스가 없을 때만 지운다. 이 파일을 지운 뒤에는 systemctl restart systemd-logind를 실행한다. /etc 아래는 root가 정리한다.

8. 확인한다. ls -d ~/gritdb1*를 실행해 없다는 오류가 나오는지 본다. 이 꼴은 3.7에서 생긴 .failed-*도 잡는다. ls -d <datafiles 실경로>* <pgdata 실경로>* 2>/dev/null(4번 값)과 ls /dev/shm | grep "_<인스턴스 ID>$"를 실행해 출력이 없는지 본다.

9. root로 userdel -r gritdb를 실행해 서비스 계정을 정리한다. 홈 디렉토리도 함께 지워진다.

• 금융권 등 파기 규정이 있으면 위 대상을 일반 삭제(rm)로 지우지 않는다. 이때는 기관 규정의 안전 삭제 도구(shred 등)나 볼륨 단위 파기로 지운다. 로그, core, datafiles/query_text_archive.jsonl에는 SQL 원문과 데이터 값이 있다(11.1).
• 설치 경로 밖의 사본은 백업(8.2, <백업 자리>/gritdb_*)과 업그레이드 사본(3.4, <백업 자리>/gritdb_before_upgrade_*)이다. 이 사본을 남길지 정한다. 남기지 않으면 같은 규정으로 지운다.
• 9번의 userdel -r도 일반 삭제다. 그래서 파기 규정이면 9번 전에 홈 안의 사본을 같은 도구로 지운다. 대상: ~/.pgpass, ~/.psql_history(11.7), ~/gritdb_support_*(9.7, QuickStart 7.4), ~/gritdb_baseline_*(7.7), 옮기고 남은 덤프, <t>.csv(8.3)

문제가 생기면

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

더 알아보기

• 백업과 복구는 8장을 본다.
• PostgreSQL 17 문서: pg_hba.conf, ALTER SYSTEM, ALTER EXTENSION, pg_upgrade