postgresql tag - Voyager of Linux

PostgreSQL

Postgresql 9.x Replication – Streaming Log

10/09/2016

Streaming log replication 은 Postgresql 9.0 부터 도입된 기능이다. 이 기능은 Primary 에서 Standby 서버로 직접 전송함으로서 replication delay 를 줄여준다. 따라서 pg_xlog 파일전송이 필요가 없다. 또 xlog 를 Streaming 으로 받기 위해서 Primary 서버에 REPLICATION 권한의 접속 계정이 필요하다. Replication 권한 사용자 생성. Primary 서버에서 REPLICATION 권한의 사용자를 다음과 같이 생성해준다.

CREATE ROLE repuser WITH REPLICATION PASSWORD '12345' LOGIN

1	CREATE ROLE repuser WITH REPLICATION PASSWORD '12345' LOGIN

그리고 Standby 서버에서 Primary 접속을 위해서 pg_hba.conf 파일을 Standby 서버 접속을 허용해 줍니다.

# The standby server must connect with a user that has replication privileges.
# TYPE  DATABASE        USER            ADDRESS                 METHOD
host       replication           repuser     192.168.96.26/32            md5

# The standby server must connect with a user that has replication privileges.

# TYPE DATABASE USER ADDRESS METHOD

host replication repuser 192.168.96.26/32 md5

중요한 것은 DATABASE 에 반드시 ‘replication’ 이여야 한다. Streaming Replication 을 위한 postgresql.conf […]

PostgreSQL

PostgreSQL Replication – Log Shipping

02/21/2016

PostgreSQL 리플리케이션은 장애를 대비해 가용성을 높이는 최소한의 방법입니다. 현재 버전의 PostgreSQL 다양한 리플리케이션을 지원하는데, 이 문서는 가장 오래되고 기초적인 리플리케이션인 Log Shipping Replication 에 대해서 다룹니다. 이 리플리케이션은 Warm Standby 이라고 합니다. 이에 대한 설명은 PostgreSQL 문서에 다음과 같이 잘 나와 있습니다. 운영 서버에서 만드는 트랜잭션 로그 조각을 정기적으로 대기 서버로 옮기고, 그것을 적용시켜, 운영 서버가 장애로 멈추게 되면, 대기 서버를 운영해서, 가용성을 향상할 수 있다. 이 기능을 warm standby, 또는 log shipping 기능이라고 한다. 이 복제 방식은 먼저, 운영 […]

HowTo, Linux

리눅스 공유 메모리

09/28/2015

리눅스 공유 메모리는 아주 특별하고 중요합니다. 튜닝하는데 있어서 매우 중요한 요소이기 때문입니다. PostgreSQL 를 세팅할때에도 반드시 해줘야 하는 것이기에 정확하게 무엇인지 짚고 넘어가고자 아는 선에 적습니다. 페이지(Page) 가장 먼저 이야기할 것이 바로 페이지(Page) 입니다. 리눅스 시스템은 메모리를 가상으로 만들어 관리합니다. 웃기게도 리눅스 시스템에서 동작하는 프로그램들은 자신들이 시스템의 모든 메모리를 사용할 수 있다, 아니 그보다 더 많은 메모리를 사용할 수 있다라고 착각을 합니다. 이는 리눅스 시스템이 메모리를 가상화해서 프로그램들에게 보여주기 때문입니다. 문제는 리눅스 시스템은 가상화된 메모리들을 페이지(Page)라는 단위로 쪼개서 관리합니다. 특정 […]

Database, PostgreSQL

pg_terminate_backend, pg_cancel_backend

09/24/2015

PostgreSQL 에서 쿼리를 취소시키위한 함수로 pg_terminate_backend, pg_cancel_backend 를 제공 합니다. 공식문서에는 다음과 같이 나와 있습니다. – pg_cancel_backend(pidint) : Cancel a backend’s current query. You can execute this against another backend that has exactly the same role as the user calling the function. In all other cases, you must be a superuser. – pg_terminate_backend(pidint) : Terminate a backend. You can execute this against another backend that has exactly the same role as the user calling the function. In all other cases, […]

Database, PostgreSQL

PostgreSQL 프로세스를 Kill 하면 발생하는 일

09/22/2015

PostgreSQL 은 프로세스 복제 모델로 동작합니다. 접속을 하면 Postmaster 라 불리는 부모프로세스를 복제해서 접속을 하고 쿼리를 처리하도록 합니다. 그런데 데이터베이스를 운영하다보면 불필요한 쿼리를 없앤다고 운영체제에서 kill 명령어를 이용하는 경우가 있습니다. 결론부터 말하면 절대로 해서는 안되는 일 입니다. 이렇게하게되면 PostgreSQL은 다음과같이 모든 프로세스를 죽이고 서버를 재시작합니다.

2015-09-22 11:01:35 KST [6129-2] LOG:  server process (PID 6345) was terminated by signal 9: Killed
2015-09-22 11:01:35 KST [6129-3] LOG:  terminating any other active server processes
2015-09-22 11:01:35 KST [6135-2] WARNING:  terminating connection because of crash of another server process
2015-09-22 11:01:35 KST [6135-3] DETAIL:  The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
2015-09-22 11:01:35 KST [6135-4] HINT:  In a moment you should be able to reconnect to the database and repeat your command.
2015-09-22 11:01:35 KST [6129-4] LOG:  all server processes terminated; reinitializing
2015-09-22 11:01:35 KST [6536-1] LOG:  database system was interrupted; last known up at 2015-09-22 10:57:06 KST
2015-09-22 11:01:35 KST [6536-2] DEBUG:  checkpoint record is at 0/176D910
2015-09-22 11:01:35 KST [6536-3] DEBUG:  redo record is at 0/176D910; shutdown TRUE
2015-09-22 11:01:35 KST [6536-4] DEBUG:  next transaction ID: 0/725; next OID: 16387
2015-09-22 11:01:35 KST [6536-5] DEBUG:  next MultiXactId: 1; next MultiXactOffset: 0
2015-09-22 11:01:35 KST [6536-6] DEBUG:  oldest unfrozen transaction ID: 711, in database 1
2015-09-22 11:01:35 KST [6536-7] DEBUG:  transaction ID wrap limit is 2147484358, limited by database with OID 1
2015-09-22 11:01:35 KST [6536-8] LOG:  database system was not properly shut down; automatic recovery in progress
2015-09-22 11:01:35 KST [6536-9] DEBUG:  resetting unlogged relations: cleanup 1 init 0
2015-09-22 11:01:35 KST [6536-10] LOG:  record with zero length at 0/176D970
2015-09-22 11:01:35 KST [6536-11] LOG:  redo is not required
2015-09-22 11:01:35 KST [6536-12] DEBUG:  resetting unlogged relations: cleanup 0 init 1
2015-09-22 11:01:35 KST [6536-13] LOG:  checkpoint starting: end-of-recovery immediate
2015-09-22 11:01:35 KST [6536-14] LOG:  checkpoint complete: wrote 0 buffers (0.0%); 0 transaction log file(s) added, 0 removed, 0 recycled; write=0.000 s, sync=0.000 s, total=0.003 s; sync files=0, longest=0.000 s, average=0.000 s
2015-09-22 11:01:35 KST [6540-1] LOG:  autovacuum launcher started
2015-09-22 11:01:35 KST [6129-5] LOG:  database system is ready to accept connections

2015-09-22 11:01:35 KST [6129-2] LOG: server process (PID 6345) was terminated by signal 9: Killed

2015-09-22 11:01:35 KST [6129-3] LOG: terminating any other active server processes

2015-09-22 11:01:35 KST [6135-2] WARNING: terminating connection because of crash of another server process

2015-09-22 11:01:35 KST [6135-3] DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.

2015-09-22 11:01:35 KST [6135-4] HINT: In a moment you should be able to reconnect to the database and repeat your command.

2015-09-22 11:01:35 KST [6129-4] LOG: all server processes terminated; reinitializing

2015-09-22 11:01:35 KST [6536-1] LOG: database system was interrupted; last known up at 2015-09-22 10:57:06 KST

2015-09-22 11:01:35 KST [6536-2] DEBUG: checkpoint record is at 0/176D910

2015-09-22 11:01:35 KST [6536-3] DEBUG: redo record is at 0/176D910; shutdown TRUE

2015-09-22 11:01:35 KST [6536-4] DEBUG: next transaction ID: 0/725; next OID: 16387

2015-09-22 11:01:35 KST [6536-5] DEBUG: next MultiXactId: 1; next MultiXactOffset: 0

2015-09-22 11:01:35 KST [6536-6] DEBUG: oldest unfrozen transaction ID: 711, in database 1

2015-09-22 11:01:35 KST [6536-7] DEBUG: transaction ID wrap limit is 2147484358, limited by database with OID 1

2015-09-22 11:01:35 KST [6536-8] LOG: database system was not properly shut down; automatic recovery in progress

2015-09-22 11:01:35 KST [6536-9] DEBUG: resetting unlogged relations: cleanup 1 init 0

2015-09-22 11:01:35 KST [6536-10] LOG: record with zero length at 0/176D970

2015-09-22 11:01:35 KST [6536-11] LOG: redo is not required

2015-09-22 11:01:35 KST [6536-12] DEBUG: resetting unlogged relations: cleanup 0 init 1

2015-09-22 11:01:35 KST [6536-13] LOG: checkpoint starting: end-of-recovery immediate

2015-09-22 11:01:35 KST [6536-14] LOG: checkpoint complete: wrote 0 buffers (0.0%); 0 transaction log file(s) added, 0 removed, 0 recycled; write=0.000 s, sync=0.000 s, total=0.003 s; sync files=0, longest=0.000 s, average=0.000 s

2015-09-22 11:01:35 KST [6540-1] LOG: autovacuum launcher started

2015-09-22 11:01:35 KST [6129-5] LOG: database system is ready to accept connections

클라이언트와 접속중인 프로세스라서 kill -9를 해도 상관이 없다고 하겠지만 전혀 그렇지 않습니다. 위의 경우에는 데이터가 아무것도 없어서 금방 재시작이 되었지만 아주 바쁜 서버의 경우에, 다시 말해서 트랜잭션이 많은 서버에서는 재시작하는데도 상당히 오랜시간이 걸릴 수 […]

Database, PostgreSQL

읽기전용 PostgreSQL 튜닝.

08/29/2015

이 문서는 읽기전용 PostgreSQL 서버를 대상으로 하는 튜닝 경험에 대해서 정리한 것입니다. 환경 테스트된 서버 환경은 다음과 같습니다. CPU: Inter(R) Xeon(R) CPU E5606@2.13GHz * 2 RAM: 32GB HDD: SAS 450GB OS: Linux PostgreSQL: 9.2 이 서버는 하루에 한번 덤프된 PosgreSQL 데이터를 전송받아서 Restore 하고 읽기전용, 그러니까 SELECT 쿼리만 사용 합니다. Linux 튜닝 리눅스 튜닝에 핵심은 공유메모리, 최대 열수 있는 파일수, 메모리관련 커널 파라메터들 입니다. 이는 최대 물리 메모리에 영향을 받습니다. 공유메모리 리눅스의 최대 공유메모리는 다음과 같은 계산으로 세팅이 가능합니다. 단, […]

Database, PostgreSQL

튜플(Tuple) 과 백쿰(VACUUM)

07/12/2015

PostgreSQL 은 다른 데이터베이스 시스템은 테이블(Table)에 데이터를 레코드(Record) 혹은 로우(Row)라고 한다. 그런데, PostgreSQL 에서는 튜플(Tuple)이라는 것이 존재합니다. 이 튜플은 PostgreSQL 에서 매우 중요한 요소 입니다. 이에 대해서 간략하게 알아 보도록 하겠습니다. 통계정보 확보. 먼저 이 튜플을 알기 위해서는 PostgreSQL 이 제공하는 통계정보를 알아 볼 필요가 있다. 이 통계정보에는 로우 갯수와 튜플 갯수등을 볼 수 있고 로우에 변화에 따라서 이들이 어떻게 변하는지를 추적할 수 있으며 이를 토대로 튜플이 과연 무엇인지를 알 수 있게 된다. 샘플 테이블을 만들자.

testdb2=> CREATE TABLE tuple_test (
id NUMERIC NOT NULL,
rand_num NUMERIC NOT NULL,
birth DATE,
CONSTRAINT id_pk PRIMARY KEY (id)
);

testdb2=> CREATE TABLE tuple_test (

id NUMERIC NOT NULL,

rand_num NUMERIC NOT NULL,

birth DATE,

CONSTRAINT id_pk PRIMARY KEY (id)

);

그리고 샘플 데이터를 […]

Database, PostgreSQL

Better VACCUM FULL For PostgreSQL 9.0

07/12/2015

원문:https://wiki.postgresql.org/wiki/What’s_new_in_PostgreSQL_9.0#Better_VACUUM_FULL 지금까지 VACUUM FULL 은 매우 느렸다. 이 구문(Statement)는 테이블로부터 빈공간을 확보하고 그것의 크기(Size)를 줄였지만 VACUUM 은 만족할만큼 빠르게 동작하지 않았다. 이것이 느린 이유는 동작 방법에 문제가 있었기 때문이다. 레코드를 그들의 소스블럭으로부터 테이블에 시작점에 가까운 블럭으로 하나하나씩 읽어서 옮겼었다. 그리고 테이블에 끝이 빈공간이면 그 부분을 지웠다. 전략적으로 이러한 방법은 매우 비효율적(Inefficient) 이다. 레코드를 하나하나씩 옮기는 것은 랜덤 I/O를 발생시킨다. 게다가, 인덱스(Index)를 재구성하는 동안에 그것을 유지하고, 더 많은 비용이 들어가는, 인덱스는 파편화된다. 이럴바에는 VACUUM FULL이 다 끝나고 나서 재인덱스(reindex)를 하는 것이 […]

Database, PostgreSQL

외부에서 Postgresql 접속할 수 있도록 설정하기

07/12/2015

Postgresql 설치를 하게되면 외부에서 접속을 기본적으로 할 수 없게 되어 있다. 호스트 기반 인증 파일인 pg_hba.conf 파일만 고친다고 되지 않는다. 외부에서 접속하는 서버의 IP를 192.168.0.18 이라고 가정한다. pg_hba.conf 파일 Postgresql 은 Host Based Authorization 기반으로 외부 접속을 제어 한다. 이는 pg_hba.conf 파일을 다음과 같이 편집함으로써 가능하다.

host    all             all             192.168.0.18/32           md5

1	host all all 192.168.0.18/32 md5

위 설정은 모든 데이터베이스에 대해서 모든 사용자에 대해서 192.168.0.18 에서 접속을 허용한다는 내용이다. postgresql.conf 파일 이 파일도 반드시 설정을 바꿔줘야 외부에서 접속을 할 수 있다. 바꿔야 할 설정은 다음과 같다.

listen_addresses = '*'                  # what IP address(es) to listen on;

1	listen_addresses = '*' # what IP address(es) to listen on;

이걸하지 않하면, […]

Database, PostgreSQL

PostgreSQL 과 문자셋

07/12/2015

PostgreSQL 도 문자셋에 관해서 많은 옵션들을 제공한다. 그런데, 대부분은 이에 대해서 잘 모르는 듯해서 여기서 정리해 본다. PostgreSQL 에서 문자셋 지정을 처음 하는 부분은 바로 설치를 마친후에 initdb 명령어를 사용하면서 부터다 대충 다음과 같이 사용한다.

su -l postgres -c "/usr/local/pgsql9.1/bin/initdb -E UTF8 --locale=ko_KR.UTF-8 --pgdata='$PGDATA' "

1	su -l postgres -c "/usr/local/pgsql9.1/bin/initdb -E UTF8 --locale=ko_KR.UTF-8 --pgdata='$PGDATA' "

문제는 저러한 문제셋 설정이 과연 향후 PostgreSQL 을 사용하는데 있어 어떤 영향을 주는가 하는 것이다. 먼저 PostgreSQL 은 ISO C 와 POSIX 등의 언어표현에 관해 지원 한다. Locale 보통 initdb –locale=ko_KR.UTF-8 로 사용되어지는 것으로 운영체제에 종속적이다. 운영체제에서 지원하는 locale 만 사용할 수 있는데, 리눅스의 […]