PostgreSQL/QuickStart/ko

PostgreSQL 간단한 시작 안내서입니다. PostgreSQL을 이머지하고 설정하는 내용을 다룹니다. 이 안내서는 공식 문서와 상호 보완적인 역할을 하지만, 대체 수단은 아닙니다.

PostgreSQL에 대한 약간의 정보
PostgreSQL은 자유 오픈소스 관계 데이터베이스 관리 시스템(RDBMS)입니다. 트랜잭션, 스키메타, 외래 키, 여기서 자주 언급하는 SQL 표준을 좀 더 엄격하게 지원하며, 기본적으로 다른 상용 데이터베이스 등보다 안전합니다.

더 많은 정보는 postgresql.org의 About 페이지를 방문하여 살펴보십시오.

이 글은 무엇을 다루는가
이 안내문에서는 PostgreSQL RDBMS를 젠투 방식으로 설치하는 과정을 안내합니다.

이 글에서 다루는 이빌드는 입니다.

이 글에서는 여러분이 PostgreSQL 최신 안정 버전을 설치함을 가정합니다. 이 글을 쓰는 시점에는 9.3.5가 최신 버전이었습니다. 이 글의 명령을 여러분이 사용하는 버전에 따라 조금씩 바꾸십시오.

이빌드 이야기
포티지에 있는 PostgreSQL 이빌드는 주 버전을 기반으로 슬롯 처리합니다. 따라서 시스템에 PostgreSQL의 각기 다른 메이저 버전이 동시에 돌아갈 수 있게 합니다. 9.0 부터 9.4 까지의 라이브러리 및 서버는 동시에 설치하고 가동할 수 있습니다. 이전 데이터베이스에서 새 데이터베이스로 데이터를 옮겨야 하는 상황이거나, 동일한 머신에 상용 데이터베이스와 시험용 데이터베이스를 운영할 경우 이런 슬롯 방식이 쓸모가 있습니다. 또한 이러한 방식을 통해 데이터베이스에 대한 불완전한 업데이트로 라이브러리 또는 실행 파일을 각각 엎는 일을 막습니다. 이런 관리 방식은 이 안내서에서 설명하는 이전 작업 과정에서 필요합니다.

게다가, 마이너 버전 업데이트를 진행할 때 가져오는 버그 수정 및 보안 수정을 진행할 때 데이터베이스 또는 PostgreSQL 설치 자체 과정이 깨지는 경우에 대해 어떠한 걱정없이 적용할 수 있습니다. 9.3.4를 9.3.5로 업데이트할 때 이전 작업, 재 설정 뿐만 아니라 초기화 작업 없이도 PostgreSQL을 이머지하고 서버를 재시작하는 번거로운 절차 진행에 비해 사용자와 어떤 확인 절차를 거치지 않아도 될 정도로 호환성을 보장합니다.

자세한 정보는 PostgreSQL 버전 정책en 을 읽어보십시오.

이 글에서 다루지 않을 내용은 무엇인가
일부 다루지 않을 내용이 있습니다. 관련 사이트 어딘가에 있을 공식 문서en 는 2000 페이지에 육박합니다. 따라서 이에 대한 자세한 내용은 빠른 시작 안내서에서 뺐습니다. 오직 젠투와 관련된 내용만 다루며 일부 기본 설정 지침을 넣었습니다.

오래된 이빌드
다음 이빌드 중 하나를 설치했다면, 이전의 오래된 PostgreSQL 젠투 설치판을 보유하고 있어 이전 작업을 진행해야합니다. 9.0 이전 버전의, , , 를 이머지하십시오.

따로 나누어놓은, , 이빌드는  이빌드로 단일화했습니다. 분열 상태의 이빌드로부터 단일화 이빌드로 옮겨야 할 요소는 없으며 통합 이빌드를 이머지하시면 됩니다.

이 글에서는 이전 이빌드에서 새 이빌드로 이전하는 방법을 다루지는 않습니다.

USE 플래그
관련 USE 플래그 정보:
 * doc: 온라인 문서는 시스템에 있습니다
 * pg_legacytimestamp: 고정밀도 64비트 정수형 대신 이전 소수점 방식 타임 스탬프를 사용합니다. 오래된 방식을 활용하는 이전 설치판을 보유하지 않는 한, 이USE 플래그는 비활성화해두십시오. 'pg_legacytimestamp' USE 플래그 설정을 뒤집어놓을 경우 어떤 데이터베이스에 대해 타임스탬프를 활용할 수 있게 제대로 복구해야 할 때 덤프를 떠 놓고 복구해야합니다. 두가지 방식은 서로 호환되지 않습니다.
 * readline: 이 플래그를 활성화하는게 좋을지도 모릅니다. 비활성화하면 psql의 명령행 편집 및 기록 기능이 없어집니다.
 * selinux: SELinux 프로파일을 활용할 때만 활성화할 수 있습니다.
 * uuid: 128비트 임의 유일 식별자를 만드는 기능을 지원할 떄 넣으십시오. 데이터베이스를 한데 합쳐서 내용이 꼬이는 일을 현저하게 낮출 때 유용합니다.

이머지 시작
,, 꾸러미 일부 또는 전체가 위에서 언급한 꾸러미를 막는다는 알림을 띄울 수 있습니다. 이 꾸러미는 관리하지 않는 꾸러미이며, 오래됐습니다. 이 상황을 처리하려면 이전 이빌드에서 새로운 이빌드로 이전하는 내용을 담는 부분을 참고하십시오.

데이터베이스 클러스터 초기화 준비
꾸러미 이머지가 끝나면, 를 편집할겁니다. 서버 기본값에 영향을 주는 세 줄이 있고 데이터 베이스 클러스가 들어있는 디렉터리를 삭제하지 않거나 다시 초기화하지 않으면 바꿀 수 없습니다.

PGDATA는 설정 파일 위치를 정의합니다. DATA_DIR은 데이터베이스 클러스터 및 관련 파일을 만들 위치를 정의합니다. PG_INITDB_OPTS는 조심스럽게 설정해야 할 추가 옵션이 들어갑니다. 추가 옵션은 그럴만한 기본 값이...크흠...다 이유가 있기 때문에 필요하지 않습니다.

다음 예제에서 PGDATA에서는 설정 파일이 위치에 있음을 언급합니다. DATA_DIR에서는 데이터베이스 클러스터를 기본적으로 위치에 설치해야 함을 나타냅니다. 기본 위치를 바꾸려면 경로의 버전을 유지하는게 아주 좋습니다. PG_INITDB_OPTS는 기본 로캘을 en_US.UTF-8로 설정했음을 나타냅니다. 미국 영어의 순서 및 형식을 맞추며 UTF-8 문자 인코딩을 사용한다는 의미입니다.

--locale= 대신 중복 우선적용할 수 있는 여섯가지 로캘 옵션이 있습니다. 다음 테이블은 해당 옵션을 보여주는데, 옵션을 사용하는 경우 다음과 같은 형식이 됩니다:.

따라서 기본 언어를 영어로 하고 메시지는 스웨덴어로 이야기한다면 PG_INITDB_OPTS를 다음과 같이 설정하시면됩니다:

서버에서 지원하는 언어 및 문자 인코딩의 전체 목록은 문서에서 찾을 수 있지만 시스템에서도 해당 언어와 문자 인코딩을 지원해야합니다. 출력과 문서의 인코딩을 비교하십시오.

데이터베이스를 만들 때 로캘과 인코딩 섹션의 내용을 바꿀 수 있습니다. 데이터베이스를 이미 만들고 나서 데이터베이스의 로캘을 바꾸려면 데이터베이스를 날리고 다시 시작해야합니다.

이 명령은 PGDATA와 DATA_DIR에 데이터베이스 클러스터와 관련 서버 파일을 만듭니다.

설정 파일이 있는 곳
Sample configuration files can be found in (or whatever version), see the trouble shooting section for the script.

처음에 집중하던 파일 및  파일 대신에  PGDATA 디렉터리의 파일을 살펴볼 차례입니다.

postgresql.conf
주 설정 파일입니다. listen_addresses는 파일 중간에서 찾아볼 관심이 가는 부분입니다. 이 변수에서는 PostgreSQL연결을 받아들일 주소를 정의합니다. 기본적으로 localhost와 유닉스 소켓만 바인딩합니다. listen_addresses 값을 바꾸는 걸로 원격 연결을 활성화하기엔 충분하지 않습니다. 이 내용은 다음 부분에서 다룹니다. 공식 문서를 보시면 존재하는 모든 설정 값을 이해하기 쉽게 철저히 설명합니다.

두번째로 관심을 가질 부준은 기록 대상 위치입니다. 기본적으로 모든 기록은 DATA_DIR 디렉터리의 파일입니다. 파일의 전체 하위 섹션은 기록을 어떻게 무엇을 어디에 저장할지 설정하는 많은 항목을 다룹니다. 하위 섹션에는 ERROR REPORTING AND LOGGING 이라고 표시했습니다.

listen_addresses 및 기록 옵션 외에도 에 있는 나머지 기본 값은 그대로 둘 이유가 충분히 타당합니다.

pg_hba.conf
파일에는 데이터베이스에 누가 연결할 수 있고 연결을 처리할 때 어떤 인증 방식을 활용할 지 나타냅니다. 다시 말해, 문서 상에 이런 설정과 의미에 대해 좀 정확하게 설명하고 있지만, 여기에 몇가지 내용을 분명하게 다루겠습니다.

전에 언급한 바와 같이 서버를 안전하게 처리해놓는게 기본값입니다. 이런식이죠. 기본적으로 postgres 로그인에 대한 데이터베이스 규칙만 있을 뿐입니다. 그리고 postgres 시스템 사용자 및 시스템 그룹에서 소유한  유닉스 소켓을 통해, 또는 localhost 주소를 통해 데이터베이스로의 연결을 초기화할 뿐입니다. 이제 이런 식의 일부를 살펴보지요. 시스템의 어떤 사용자든 localhost로 데이터베이스에 연결할 수 있습니다. 게다가 postgres 데이터베이스 최고 사용자로 말이죠.

trust 방식은 암호 없이 어떤 사용자에게든 그 자신의 정체로 로그온할 수 있게 하는 방법입니다. 이 항목이 지정하는 내용은 주어진 데이터베이스 사용자(시스템 사용자 아님)가 주어진 위치에서 연결을 시도했을 때, 암호없이 주어진 데이터베이스에 대한 모든 연결을 신뢰한다는 암묵적 의미입니다. 시스템의 어떤 사용자에게 어떤 사용자든 때때로 localhost 로 로그온 할 수 있게합니다. 위험하지 않은 것처럼 보이지만 대부분 어떤 환경에서든 중대한 보안 위험성을 지닙니다.

여러분이 대부분 활용할 방식은 password와 md5입니다(허나 md5는 해독 가능하므로 대한민국 법상 허용하지 않는 암호화 방식입니다. 역자 주). 암호 방식은 연결을 시작할 때 암호가 필요함을 지정할 뿐이며 암호는 분명하게 보냅니다. 이 방식은 유닉스 소켓 또는 localhost로 연결하는 방식으로, 어떤 정보든 장비 밖으로 나가지 않을 경우 바람직합니다. md5 방식은 암호랑 비슷하지만 md5 해시를 활용하여 암호를 보호합니다. 이 방식은 네트워크를 거쳐 언제든 암호를 보내려 할 때 사용합니다.

여기서, 이 작자는 파일은 주석을 포함한 네 줄 중에 마지막 두 줄에 주목하겠습니다. PostgreSQL은 여러분이 어떤 지원방식을 원하든지간에 IPv6를 자체적으로 지원합니다 게다가 IPv4 주소는 자동으로 IPv6에 연동합니다. 즉, 127.0.0.1는 ::FFFF:127.0.0.1로 연동하고, 이 주소는 순수한 IPv6 주소로 ::FFFF:7F00:0001이 됩니다.

호스트 이름을 IP 주소에 연동하는 방법에 오해의 소지가 있어보입니다. 파일을 살펴보도록 하겠습니다.

위 예제에서 IPv4 및 IPv6 IP 주소를 localhost에 물렸음을 볼 수 있습니다. 에서 이 파일을 참조하면, 처음 일치하는 부분을 찾아서 주소로 사용합니다. 이 경우 127.0.0.1입니다. PostgreSQL에서 이 부분을 해석할 때 IPv6 형식 ::ffff:127.0.0.1 주소도 마찬가지로 일치합니다. 그러나 IPv6 주소가 먼저 나타나면 은 ::1에만 물리는데 ::1 은 ::ffff:127.0.0.1 주소와는 다릅니다. 따라서 접근 허용 주소가 ::1이 아니면 에서 연결을 수립할 수 없습니다. 게다가 커널에서 IPv6 프로토콜을 지원해야합니다.

따라서 IP 주소를 에 적절하게 순서에 따라 적어놓은 내용이 아닌  과  에 따라 IP 주소를 적는게 좋으며 어떤 IP 주소를 허용하고 어떤 서버에 연결할 지 의심가게 하는 부분은 제거합니다.

시작합시다!
이제 PostgreSQL을 시작하고 postgres 데이터베이스 최고 사용자의 암호를 설정하십시오.

'trust'를 'host'(유닉스 도메인 소켓 'local' 이 아님) 연결의 'password'로 바꾸십시오.

이제 데이터베이스를 시작하십시오:

서버의 연결을 열고 암호를 설정하십시오:

로컬 연결의 'trust'를 'password'로 바꾸십시오:

이제 데이터베이스 설정을 다시 불러오십시오:

마지막으로, 진행한대로 동작한다면, PostgreSQL을 부팅할 때 시작하도록 하십시오:

여기서 공식 PostgreSQL 지침서의 내용으로 계속 진행할 수 있습니다. 지침서는 역할, 데이터베이스, 스키메타, 쓸만한 재미거리를 고안하는 방식으로 안내해드립니다.

이전 작업이 필요할 때
이전 작업을 수정해야 하는 이유는 두가지가 있습니다. PostgreSQL 9.0.2가 아닌 8.4.7에서 9.0.3으로 메이저 버전 단위로 옮겨가는 경우를 예로 들거나 오래된 소숫점 방식 타임스탬프를 64비트 정수형 타임스탬프 형식으로 옮겨가는 경우를 예로 들어보겠습니다.

9.0 이후 버전 이전 작업
최근 8.4 이상 버전 빌드의 이전 버전으로 업그레이드할 경우, 이전 과정을 진행하기 전에 이 안내서 앞부분을 따라가십시오.

pg_upgrade는 9.0 이상에서 도입한 새 유틸리티이며, 이전 과정을 과감하게 하기보단 단순화했습니다.

허나, 를 사용할 때 두가지 단점이 있습니다. 우선 데이터가 들어간 다른 디렉터리에 있는 설정 파일을 지원하지 않습니다. 이 문제는 심볼릭 링크로 해결할 수 있습니다. 다른 단점 하나는 8.3 이상의 데이터베이스에서만 이전할 수 있습니다. 이전 데이터베이스를 사용중이었다면 9.0 이전 배포판으로 이전하는 방식을 따라야합니다.

우선 (위에 설명한대로)데이터베이스 클러스터를 초기화했는지 확인하십시오. 초기화가 끝났으면 이전 작업을 진행할 목적 서버와 대상 서버를 멈추십시오:

사용중인 버전을 확인하고, 현재 사용중인 버전을 선택하십시오:

모든 데이터베이스의 로컬 연결 신뢰 대상 데이터베이스 사용자를 'postgres'로 바꾸십시오:

다음 과정을 진행하기 전에 의 권한을 바꿔야합니다.

여러분이 할 일이 있다면 해당 작업을  에 알려 작업을 진행하십시오.

그리고 이제 끝낼 차례입니다:

9.0 이전 버전 이전작업: 새 이빌드 활용
새 이빌드에서는 이전 버전과는 달리 좀 더 진보된(고급) 슬롯 방식을 채택하고 있기에, 가동 중지 시간은 시간 단위에서 분 단위로 좀 더 최소화되겠습니다.

다음 예제에서는 기본 위치와 포트 설정을 사용하며, 8.3 버전에서 8.4 버전으로 데이터를 이전한다고 가정하겠습니다. 기본 설정과 다르다면 설정에 따라 바꾸십시오.

여기까지 끝내지 못했다면 이전 작업을 진행하기 전 설치 절차를 따르십시오. 컴파일 작업은 데이터베이스 서버의 성능 발휘를 방해하겠지만, 계속할 수 있습니다.

이전 작업을 시작하기 전에 몇가지 파일을 고쳐야합니다. 설정 파일의 PGPORT 값을 6543으로 고치십시오(이전에 설치한 PostgreSQL에서 사용하는 포트와는 다른 아무 포트 값이든 부여하십시오).

다음 파일을 편집하여 데이터베이스 최고 관리자 postgres가 유닉스 소켓을 통해 데이터베이스 클러스터에 접근할 수 있게 하십시오.

다음 명령은 안전하게 진행해야 합니다. 문서를 읽어 확인하십시오.

잊지 말고 필요한 다른 설정 파일도 복사하십시오.

이전 클러스터에서 새 클러스터로 데이터 파이핑을 시작하십시오.

PGPORT를 5432로 되돌리십시오.

사용자에게 한번 더 접근을 허용하십시오.

원하는 만큼 모든 부분이 계획에 따라 진행됐으며, 이전 서버와 비트 단위별로 정확히 동일한 데이터가 들어있는 서버로 성공적으로 업데이트했습니다.

9.0 이전 버전 이전작업: 오래된 이빌드 활용
서버를 내린 시간에 어떤 계획을 진행해야 할 수도 있습니다. 이전 이빌드는 새 이빌드로 동시에 설치할 수 없습니다. 때문에 몇시간 동안은 그냥 서버를 내려야 하는구나 라고 보시면 됩니다. 아마 주말이나 그쯤 되겠죠.

시작하기 전에 서버로의 접근을 막아서 외부에서 어떤 변경도 하지 못하게 해야 합니다. 및, 그리고 여러분이 손을 대어 중요하다고 생각하는 다른 설정 파일을 백업하시는게 좋습니다.

이 글에서 자세하게 다루는 서버 설치 및 설정을 따르십시오.

아마도 이들 꾸러미로 빌드한 일부 꾸러미가 깨질지 모르겠지만 를 설치했다면  명령을 실행하여 깨진 것 같은 꾸러미를 다시 이머지할 수 있습니다.

pgAdmin III
pgAdmin III 는 PostgreSQL을 관리하는 그래픽 인터페이스 유틸리티입니다.

서버에 편성 기능이 빠져 있음
이 문제는 어떤 버전을 사용하느냐에 따라 해결 방법이 다르지만 쉽습니다. 답을 찾는게 어려울 뿐입니다. 가져와야 할 필요한 파일은 저장소 드라이브에 이미 있는 파일입니다. 이 문제를 해결하려면, 보유하고 있는 버전에 따라 다음 명령 중 하나를 실행하시면 됩니다.

PostgreSQL 9.0 이전 버전:

PostgreSQL 9.1 이후 버전:

과 에 설정 파일 빠짐
디렉터리에 설정 파일을 이동해볼 수 있는데, 다음에서 x 대신 postgresql 버전 번호를 넣으시면 됩니다:

파일이 빠져있다면 초기화해야합니다.

우선 postgres 사용자로 전환하십시오:

postgres 사용자로 명령을 실행하여 데이터 디렉터리를 지정하십시오:

이 명령은 설정 파일을 만들며 이 섹션의 첫 명령에서 보신바와 같이 에 복사합니다.

"ERROR: timezone directory stack overflow" 또는 "FATAL: too many private dirs demanded" 오류 발생
심볼릭 링크 루프 때문에 일어나는 문제입니다. 문제를 해결하려면 다음 명령을 입력하십시오:

시간대 정보를 업데이트 하면 심볼릭 링크를 다시 만드므로 심볼릭 링크를 다시 제거해야합니다.

Systemd
시작시 서비스를 시작하도록 강제하려면:

서비스를 즉시 시작하려면:

디렉터리가 올바른 위치에 있는지 확인하라는 오류가 나타나는 경우가 있습니다. 디렉터리가 없다면 다음 명령으로 만드십시오:

설정 파일 권한을 확인하십시오:

Service file and changes to it
Systemd service files (postgresql-@SLOT@-.service) can be found in /lib/systemd/system/:

example config change:

This will override the setting appearing in /lib/systemd/system/postgresql-@SLOT@.service.

(source: postgresql-10.service file)

RemoveIPC
PostgreSQL recommends in wiki.postgresql.org/wiki/Systemd to change the RemoveIPC setting to no in /etc/systemd/logind.conf:

(source: wiki.postgresql.org/wiki/Systemd)