Tmax OpenSQL Documentation

PostgresSQL Version 은 Major version과 Minor version으로 구성됩니다.

예를 들어, 11.14 version 은 Major version이 11 , Minor version 14 로 구성됩니다.

PostgreSQL 은 동일한 Major version을 가진 Minor version과 호환됩니다.

예를 들어, 10.1 version 은 10.0 및 10.6 버전과 호환됩니다.

호환되는 버전 간에 업데이트 하려면 서버가 다운된 상태에서 실행 파일을 교체하고 서버를 다시 시작하면 됩니다.

데이터 디렉토리는 변경되지 않은 상태로 유지됩니다.

메이저 버전의 경우 내부 데이터 저장 형식이 변경될 수 있으므로 업그레이드가 복잡합니다.

PostgreSQL 를 배우고 실습에 사용할 수 있는 샘플 데이터베이스 생성 방법을 알아보겠습니다.

DVD rental 데이터베이스는 DVD 대여점의 비즈니스 프로세스를 나타냅니다.

아래와 같은 오브젝트를 포함하고 있습니다.

아래 zip 파일을 통해 PostgreSQL DVD rental Database 를 다운로드 할 수 있습니다.

다운로드 받은 파일을 서버로 옮긴 후 아래와 같이 수행하여 적용합니다.

PostgreSQL 은 하나의 데이터베이스 클러스터를 운영하기 위한 여러 프로세스로 구성되어 있습니다. PostgreSQL 프로세스의 기능 및 아키텍쳐에 대한 자세한 내용은 저희 블로그의 “PostgreSQL의 프로세스와 메모리 아키텍처” 게시글을 참고해 주세요. postgres 프로세스는 데이터베이스 클러스터를 운영하기 위해 여러 역할을 수행하지만 모든 백엔드 프로세스, 백그라운드 프로세스를 관리하는 역할도 수행합니다. 백엔드 프로세스, 백그라운드 프로세스가 비정상적으로 종료되었을 때 postgres 프로세스가 이를 인지하고 적절한 처리와 함께 해당 프로세스를 재생성합니다. 이번 장에서는 postgres 프로세스가 자식 프로세스를 어떻게 관리하는지 자세히 알아보도록 하겠습니다. postmaster라는 용어도 많이 사용되지만 PostgreSQL 공식 문서에서 postgres 프로세스라는 용어를 사용하므로 본 글에서는 postgres 프로세스라고 표기하도록 하겠습니다.

PostgreSQL을 구성하고 있는 모든 백엔드, 백그라운드 프로세스는 postgres를 fork 하여 생성됩니다. 다음 명령어를 통하여 직접 확인해 보도록 하겠습니다.

백엔드 및 백그라운드 프로세스의 PPID(parent process ID) 는 모두 24로 postgres를 부모 프로세스로 가지는 것을 확인할 수 있습니다. 그렇다면 postgres 프로세스는 어떻게 자식 프로세스의 상태를 확인하고 있을까요?

postgres 프로세스 내에는 ServerLoop라는 이벤트 루프 함수가 존재합니다. ServerLoop 함수는 이벤트가 발생할 때까지 대기하고, 이벤트가 발생하면 해당 이벤트를 처리하고 다시 대기합니다. ServerLoop 함수 내부에는 postgres 프로세스가 수행하는 여러 동작이 구현되어있습니다. client connection 요청에 대한 처리, 새로운 자식 프로세스를 fork 하는 동작 등 다양한 작업을 수행합니다. 하지만 ServerLoop 에서 처리해야 하는 중요한 기능 중 하나는 fork 된 모든 자식 프로세스에 대한 상태를 확인 하고 이상이 있을 경우 이를 처리하는 것 입니다.

위의 소스코드는 postmaster.c 내의 ServerLoop 함수의 일부입니다. CheckpointerPID, BgWriterPID, WalWriterPID 등은 각각 백그라운드 프로세스의 PID(process ID)를 나타내는 정적 변수입니다. 이 프로세스 들은 모두 postgres 의 자식 프로세스입니다. postgres 프로세스는 ServerLoop 함수 내에서 지속적으로 PID를 확인하여 자식 프로세스의 유무를 확인하며 자식 프로세스가 존재하지 않을 때 이를 다시 시작하도록 하는 동작을 수행합니다.

PostgreSQL의 경우 테이블 오브젝트(table object) 마다 최소 한 개의 파일을 생성하기 때문에 Oracle이나 Tibero에 비해 상대적으로 많은 수의 파일 디스크립터(file descriptor, 이후 FD)를 사용할 수 있습니다. 이는 OS나 커널 설정에 따라 “Too many open files” 에러가 발생할 수 있기 때문에 PostgreSQL에서는 가상 파일 디스크립터(virtual file descriptor, 이후 VFD) 모듈을 통해 FD에 대한 관리를 하고 있습니다.

PostgreSQL에서 FD를 효율적으로 관리하기 위해 VFD 모듈에서는 획득한 FD를 캐싱(caching)하고, 프로세스마다 동시에 얻을 수 있는 FD의 수를 제한하고 있습니다. 만약 요청된 파일의 수가 제한된 수를 넘을 경우 VFS 내부에서는 LRU(least recently used) 방식을 사용해 기존에 캐싱되었던 FD를 정리하고 새로운 FD를 획득합니다. 때문에 다른 모듈에서는 VFD 모듈 인터페이스를 통해 파일을 열고, 닫아야 합니다.

PostgreSQL은 하나의 프로세스에서 동시에 열 수 있는 파일의 최대 수를 max_files_per_process 파라미터를 통해 설정할 수 있습니다. 기본값은 1000이며, 64부터 INT_MAX(2147483647)까지 설정할 수 있습니다. 이 파라미터를 수정한 값을 적용하려면 PostgreSQL 서버를 재시작해야 합니다.

max_file_per_process를 64로 설정하고 PSQL로 접속한 백엔드 프로세스(backend process)가 최대로 획득한 FD의 수를 모니터링해 보겠습니다.

PostgreSQL은 확장성이 좋은 오픈소스 데이터베이스로 잘 알려져 있습니다. 그런 명성을 이루는 데에는 PostgreSQL의 기능을 유연하게 확장할 수 있도록 Extension Framework가 제공되기 때문입니다. Extension을 이용한 기능 확장은 PostgreSQL의 다양한 데이터 타입 및 함수 지원을 가능하게 하고 더 나아가 내부 기능에 대한 개선도 가능하게 합니다. PostgreSQL의 Extension Framework로 확장할 수 있는 모듈은 아래와 같습니다.

Extension의 또 다른 중요한 특징 중 하나는 Extension이 PostgreSQL 인스턴스에 동적으로 로딩 된다는 점입니다. 즉, PostgreSQL에서는 Extension을 사용하면 DB 인스턴스를 다시 기동할 필요 없이 새로운 기능을 추가할 수 있다는 뜻입니다. 이 글에서는 어떻게 PostgreSQL의 Extension Framework가 Extension의 동적 로딩을 가능하게 하는지 알아보도록 하겠습니다.

PostgreSQL의 Extension Framework는 크게 세 개의 레이어로 나뉘어져 있습니다.

동기식 스트리밍 리플리케이션(Synchronous streaming replication)은 PostgreSQL 9.1 버전부터 구현되었습니다. 단일 마스터 다중 슬레이브(single-master-multi-slaves) 타입의 리플리케이션이라고도 불리며 여기서 마스터(Master)는 프라이머리(Primary)를 뜻하며, 슬레이브(Slave)는 스탠바이(Standby)를 뜻합니다.

이 리플리케이션 기능은 로그 전달(Log shipping)을 기반으로 합니다. 프라이머리는 WAL 데이터(WAL data)를 지속적으로 스탠바이로 전송하고, 각 스탠바이들은 받은 즉시 WAL 데이터를 리플레이합니다.

이 장에서는 스트리밍 리플리케이션의 동작에 대해 다음과 같은 주제를 다룹니다.

PostgreSQL 9.0 버전에서 비동기식 리플리케이션(Asynchronous replication)이 구현되었지만 PostgreSQL 9.1 버전의 동기식 리플리케이션으로 대체되었습니다.

스트리밍 리플리케이션을 위해서 세 개의 프로세스가 동작합니다. walsender는 프라이머리 서버에서 WAL 데이터를 스탠바이 서버로 보냅니다. 스탠바이 서버의 walreceiver와 startup 프로세스는 WAL 데이터를 전송 받아서 리플레이합니다. walsender와 walreceiver는 단일 TCP 연결로 통신합니다.

이 섹션에서는 위에서 설명한 세 프로세스가 어떻게 시작하고 연결을 맺는지를 확인하기 위해 스트리밍 리플리케이션의 시작 절차를 살펴보겠습니다.

Contrib Extension 에서 PostgreSQL의 기능을 보조하는 Extension을 모아서 정리해봤습니다.

adminpack은 pgadmin 및 기타 관리도구가 서버 로그 파일의 원격 관리와 같은 추가 기능을 제공하는 데 사용할 수 있는 다양한 지원 기능을 제공합니다.

슈퍼유저에게만 기능 사용이 허용되지만, grant로 다른 사용자에게 허용될 수 있습니다.

pgpool-II은 PostgreSQL tool이며 많은 기능을 제공하며 많이 쓰이는 툴 중 하나 입니다. 양이 방대하여 파트를 나누어서 업로드 하려고 합니다.

pgpool-II은 아래와 같은 다양한 기능을 제공합니다.