이 절에서는 PostgreSQL 릴리스의 데이터베이스 데이터를 새로운 것으로 업그레이드하는 방법을 다룬다.
현재 PostgreSQL 버전 번호는 메이저 버전과 마이너 버전 번호로 구성된다. 예를 들어 10.1 이라면 10이 메이저 버전이고, 1이 마이너 버전이다. 마이너 버전 1 이라 함은 10 버전 가운데 첫번째 패치 버전을 의미한다. PostgreSQL 10.0 버전부터 이렇게 하기로 했으며, 그 이전 버전에서는 메이저 버전이 앞 부분 두 영역이다. 예를 들어, 9.5.3 이라면, 메이저 버전이 9.5 이며, 3이 마이너 버전이며, 9.5 버전 가운데 세번째 패치 버전임을 뜻한다.
메이저 버전은 그대로이고, 마이너 버전만 바뀌는 경우는 내부 저장 형식이 바뀌지 않는 경우이다. 즉, 10.1 버전이나, 10.6 버전은 호환되며, 9.5.3과는 호환되지 않는다. 9.5.3은 9.5.0, 9.5.1, 9.5.6 버전과 호환된다. 호환되는 버전간의 업그레이드는 자료 구조가 바뀌지 않기 때문에, 단순하게, 서버를 중지하고, 실행 파일을 바꾸기만 하면 된다. — 쉽다.
PostgreSQL의 메이저 릴리스의 경우, 내부 데이터 스토리지 형식이 변경되므로 업그레이드가 복잡하다. 데이터를 새로운 메이저 버전으로 옮기는 전형적인 방법은 느릴 수 있지만 데이터베이스를 덤프하고 다시 불러오는 것이다. 더 빠른 방법은 pg_upgrade이다. 복제 방법도 아래에 언급된 바와 같이 사용 가능하다. (If you are using a pre-packaged version of PostgreSQL, it may provide scripts to assist with major version upgrades. Consult the package-level documentation for details.)
일반적으로 새 메이저 버전에서도 사용자 가시(user-visible) 비호환성이 도입되므로 어플리케이션 프로그래밍 변경이 요구되곤 한다. 모든 사용자 가시(user-visible) 변경은 릴리스 노트(부록 E)에 나와 있다. "마이그레이션" 절을 특히 주의 깊게 보아야 한다. Though you can upgrade from one major version to another without upgrading to intervening versions, you should read the major release notes of all intervening versions.
세심한 사용자라면 새 버전으로 완전히 넘어가기 전에 클라이언트 어플리케이션을 새 버전에서 테스트해보고 싶을 것이다. 그러므로, 이전 버전과 새 버전의 동시 설치를 설정하는 것이 좋은 아이디어이다. PostgreSQL 메이저 업그레이드를 테스트할 때 다음과 같이 변경 가능성이 있는 카테고리를 고려해야 한다.
서버를 모니터링 및 관리하기 위해 관리자가 사용할 수 있는 기능이 메이저 릴리스에서 주로 변경 및 개선된다.
일반적으로 새 SQL 명령이 여기에 포함되고, 특별한 언급이 릴리스 노트에 없으면 동작하지 않는 변경은 없다.
릴리스 노트에 특별한 언급이 없으면, libpq 같은 전형적인 라이브러리만 새로운 기능을 추가한다.
시스템 카탈로그 변경은 보통 데이터베이스 관리 도구에만 영향을 미친다.
이것은 C 프로그래밍 언어로 작성된 백엔드 함수 API의 변경과 관련이 있다. 해당 변경은 서버 내 백엔드 함수를 참조하는 코드에 영향을 미친다.
업그레이드 방법 중 하나는 PostgreSQL의 메이저 버전에서 데이터를 덤프하고 다른 버전에서 다시 불러오는 것이다. 이렇게 하려면 pg_dumpall 같은 논리적 백업 툴을 사용해야 한다. 파일 시스템 레벨 백업 방법은 작동되지 않는다. (호환되지 않는 PostgreSQL 버전으로는 데이터 디렉터리를 사용하지 못하도록 하는 검사가 존재하며,그래서 데이터 디렉터리에서 잘못된 서버 버전을 시작하려는 시도가 있더라도 큰 위험은 방지된다.)
이 프로그램에서 개선 기능의 장점을 활용하려면 새 버전의 PostgreSQL에서 pg_dump 및 pg_dumpall 프로그램을 사용하는 것이 바람직하다. 덤프 프로그램의 현재 릴리스는 과거의 모든 서버 버전부터 7.0까지의 데이터를 읽을 수 있다.
이 지침은 기존 설치가 /usr/local/pgsql 디렉터리이고, 데이터 영역이 /usr/local/pgsql/data인 것으로 간주한다. 사용자 경로에 맞게 적절한 대체가 필요하다.
백업 시 데이터베이스가 업데이트 중이 아닌지 확인해야 한다. 이것이 백업의 무결성에는 영향을 미치지 않지만 변경된 데이터는 당연히 포함되지 않는다. 필요 시 /usr/local/pgsql/data/pg_hba.conf 파일(또는 동등한 파일)에서 권한을 편집하여 사용자 본인을 제외한 모든 사람의 액세스를 불허해야 한다. 액세스 제어에 대한 자세한 내용은 20장을 참조 바란다.
pg_dumpall > outputfile
백업을 하기 위해 현재 실행 중인 버전에서 pg_dumpall 명령을 선택할 수 있다. 자세한 내용은 25.1.2절을 참조 바란다. 최고의 결과를 내려면 버그 수정 기능이 있고 이전 버전보다 개선된 PostgreSQL 9.4.1에서 pg_dumpall 명령의 사용을 시도해야 한다. 새 버전을 아직 설치하지 않았기 때문에 이 권고가 이상해 보일 수 있지만 새 버전을 이전 버전과 병행 설치할 생각이면 이것을 따르는 것이 좋다. 이런 경우 설치를 정상적으로 완료하고 데이터는 나중에 전송할 수 있다. 이렇게 하면 다운타임도 줄어든다.
이전 서버 셧다운:
pg_ctl stop
부팅 시에 PostgreSQL이 시작되는 시스템에서 같은 작업을 수행하는 파일이 있을 수 있다. 예를 들면, Red Hat Linux 시스템에서도 이러한 동작을 찾아볼 수 있다.
/etc/rc.d/init.d/PostgreSQL stop
서버 시작 및 중단에 대한 내용은 18장을 참조 바란다.
백업으로부터 복구하는 경우 버전이 명시된 것이 아니라면 이전 설치 디렉터리의 이름을 변경하거나 디렉터리를 삭제해야 한다. 문제가 발생해서 되돌아 가야 할 때를 대비해서 디렉터리를 삭제하는 것보다는 이름을 변경하는 것이 낫다. 디렉터리는 디스크 공간을 상당량 차지한다는 사실을 잊으면 안 된다. 디렉터리 이름을 변경하려면 다음과 같은 명령을 사용한다.
mv /usr/local/pgsql /usr/local/pgsql.old
(디렉터리를 단일 유닛으로 이동하여 관련 경로가 바뀌지 않게 해야 한다.)
PostgreSQL 새 버전은 16.4절에 요약된 대로 설치한다.
필요 시 데이터베이스 클러스터를 새로 생성한다. 특수한 데이터베이스 사용자 계정(업그레이드 중 이미 보유하고 있는)으로 로그인한 상태에서 이 명령을 실행해야 한다는 것을 잊으면 안 된다.
/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
이전 pg_hba.conf 및 모든 postgresql.conf 수정 내용을 복원한다.
특수 데이터베이스 사용자 계정을 사용하여 데이터베이스 서버를 다시 시작한다.
/usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data
마지막으로 다음 명령으로 데이터를 복원한다.
/usr/local/pgsql/bin/psql -d postgres -f outputfile
이때 새 psql을 사용한다.
새 서버를 다른 디렉터리에 설치하고 이전 및 새 서버를 서로 다른 포트에서 병렬 실행하면 다운타임을 최소화할 수 있다. 그런 다음, 사용자는 데이터를 전송하기 위해 다음과 같은 명령어를 사용할 수 있다.
pg_dumpall -p 5432 | psql -d postgres -p 5433
이 명령으로 데이터가 전송된다.
pg_upgrade 모듈은 메이저 PostgreSQL 버전에서 다른 버전으로 현재 위치에 마이그레이션되는 설치를 허용한다. 특별히 --link 모드를 사용하면 수 분 이내에 업그레이드가 가능하다. 이것은 위의 pg_dumpall과 유사한 단계가 필요하다(예: 서버 시작/중지, initdb 실행). pg_upgrade문서에는 필수 단계가 간략하게 나와 있다.
It is also possible to use logical replication methods to create a standby server with the updated version of PostgreSQL. This is possible because logical replication supports 스탠바이는 동일한 컴퓨터 또는 다른 컴퓨터에 있는 것일 수 있다. 일단 마스터 서버(PostgreSQL의 이전 버전 실행 중)와 동기화되면, 마스터 서버를 전환하고 마스터 서버를 스탠바이한 상태에서 이전 데이터베이스 인스턴스를 셧다운할 수 있다. 따라서 이러한 전환 방식에 의하면, 업그레이드 다운타임이 수 초에 불과하게 된다.
This method of upgrading can be performed using the built-in logical replication facilities as well as using external logical replication systems such as pglogical, Slony, Londiste, and Bucardo.