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 이전 버전의, , , 를 이머지하십시오.

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

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

이머지 시작
You may receive a notice regarding that any of the above packages are blocked by any or all of the following packages:, , or. These packages are not maintained and obsoleted. Refer to the section on migration from the previous ebuilds to the new ones to know how to handle this situation.

데이터베이스 클러스터 초기화 준비
Once the packages have finished emerging, you may want to edit. There are three lines that effect the defaults of the server and cannot be changed later without deleting the directory that contains the database cluster and reinitializing.

PGDATA defines where to place the configuration files. DATA_DIR defines where to create the database cluster and related files. PG_INITDB_OPTS may contain any extra options you would care to set. The extra options are not required as the reasonable defaults are, ahem, reasonable.

In the following example, PGDATA states that the configuration files are to be located in. DATA_DIR states that the database cluster should be installed to, which is the default. If you decide to stray from the default, bear in mind that it is a very good idea to keep the major version in the path. PG_INITDB_OPTS states that the default locale should be en_US.UTF-8. That is, U.S. English ordering and formatting, and UTF-8 character encoding.

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

So, if you would like the default to be English, but you want messages in, say, Swedish, then your PG_INITDB_OPTS would look like so:

A complete list of language and character encodings supported by the server can be found in the documentation, but your system must also support the respective languages and character encodings. Compare the output of  to the encodings in the documentation.

You can change your locale and encoding selections at database creation time. In order to change the locale for a database after you have created it, you must drop the database and start over again.

This will create the database cluster and store all the related server files into PGDATA and DATA_DIR.

설정 파일이 있는 곳
This time the focus is upon the files in the PGDATA directory,, instead with primary focus on the  and  files.

postgresql.conf
This is the main configuration file. The line that you may find of immediate interest is listen_addresses. This variable defines to which addresses PostgreSQL will bind. By default, only localhost and the Unix socket are bound. Changing listen_addresses is not enough to enable remote connections. That will be covered in the next section. The official documentation is fairly easy to understand and is exhaustive on all the settings available. It would behoove you to read that in addition to what is covered here as some things may change.

Of secondary interest is the logging destination. By default, everything is logged to in the DATA_DIR directory. There is an entire subsection of that covers a slew of options for how, what and where to log. The subsection is marked: ERROR REPORTING AND LOGGING.

Other than listen_addresses and the logging options, the rest of the defaults in are reasonable enough to get you going.

pg_hba.conf
The file states who is allowed to connect to the database server and which authentication method must be used to establish the connection. Again, the documentation is quite exhaustive on the settings and what they all mean, but a few things are covered here for clarification.

As has been mentioned before, by default the server is secure. Kind of. There is only one database role that is available for log in by default: postgres. And, the only way to initiate a connection to the database is through the Unix socket, which is owned by the postgres system user and system group, or via localhost. Now for the "kind of" bit: Any user on the system can make a connection to the database through the localhost. Even as the postgres database superuser.

The trust method is what allows any user to log on as any user without a password. It specifies just what it implies: Trust all connections for the given type to the given database from the given database user (but not the system user) from the given location without a password. This is what allows any user on the system to log on as any user through the localhost connection from the get go. This is not as dangerous as it seems, but does pose a serious security risk in most circumstances.

The two methods you will most likely use are: password and md5. The password method only specifies that a password is required to start the connection and the password is sent "in-the-clear". This method is fine when such information will never leave the machine, such as connecting via the Unix socket or localhost. The md5 method is like password, but protects the password by using an md5 hash. This is what you want to use whenever the password is going to traverse a network.

At this point, this author would like to bring your attention to the last two lines, four lines including comments, of the file. PostgreSQL has native support for IPv6 regardless of your desires for such support. Additionally, IPv4 addresses are automatically mapped to IPv6 addresses, i.e., 127.0.0.1 will be mapped to ::FFFF:127.0.0.1 and as "pure" IPv6 ::FFFF:7F00:0001.

There seems to be some misunderstanding, though, as to how host names are mapped to IP addresses. Let us take a look at the file.

From the example above you can see that both an IPv4 and an IPv6 IP address are mapped to localhost. When  refers to this file, it will grab the first match and use that as the address; in this case 127.0.0.1. When PostgreSQL parses this, it will match the IPv6 formatted address as well, e.g. ::ffff:127.0.0.1. If, however, the IPv6 address appears first, then  will map to ::1 alone; ::1 is not the same as ::ffff:127.0.0.1. As such, if you do not have ::1 as a permitted means of access,  will not be able to establish a connection. Furthermore, your kernel needs to support the IPv6 protocol.

So, it is better to specify IP addresses alone to  and in  rather than to rely on  to be ordered properly, and it removes any doubt as to which IP addresses are allowed or to which server you will connect.

시작합시다!
Now start PostgreSQL and set the password for the database superuser postgres.

Change 'trust' to 'password' for the 'host' (not the 'local', Unix domain socket) connections.

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

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

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

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

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

At this point you are ready to continue on with the official PostgreSQL Tutorial. The tutorial will guide you through creating roles, databases, schemata and all that fun and useful stuff.

이전 작업이 필요할 때
There are only two reasons you would need to perform a migration: When moving from one major version to another, e.g., from PostgreSQL 8.4.7 to 9.0.3, but not from 9.0.2 to 9.0.3; or when switching from the deprecated floating-point timestamp format to the new 64-bit integer timestamp format.

9.0 이후 버전 이전 작업
When upgrading from a previous version of the recent ebuilds, which is any version after 8.4, follow the beginning of this guide before proceeding with this migration.

pg_upgrade, a new utility that comes along with 9.0 and later, simplifies the migration process rather drastically.

However, there are two caveats with using. Firstly, it does not support configuration files being in a different directory than where the data is stored. This can be resolved by using symbolic links. Lastly, you can only use it to migrate from a database from 8.3 or newer. If you have an older database you will need to follow the instructions to migrate from pre-9.0 deployments.

First ensure that the new database cluster is initialized (as described above). Then stop the servers you're going to migrate from and to:

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

모든 데이터베이스의 로컬 연결 신뢰 대상 데이터베이스 사용자를 '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
시작시 서비스를 시작하도록 강제하려면:

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

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

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