MongoDB] 설치 & 권한 설정

CentOS 7에서 MongoDB를 설치하고 권한을 설정하여 권한이 없는 사용자는 조회/등록/수정/삭제 기능을 사용하지 못하게 한다. MongoDB는 3.6 버젼 기준으로 설명한다.

1. 패키지 매니저에 MongoDB 추가

먼저 /etc/yum.repos.d/mongodb-org-3.6.repo 파일을 생성하고 다음 내역을 추가 한다.

[mongodb-org-3.6]
name=MongoDB Repository
baseurl=https://repo.mongodb.org/yum/redhat/$releasever/mongodb-org/3.6/x86_64/
gpgcheck=1
enabled=1
gpgkey=https://www.mongodb.org/static/pgp/server-3.6.asc

2. MongoDB 설치

MongoDB 패키지 설치를 진행 한다.

sudo yum install -y mongodb-org

설치가 완료 되면 mongod 프로세스를 시작한다.

sudo service mongod start

프로세스에 대한 정지 명령어는 다음과 같다.

sudo service mongod stop

만약 MongoDB를 삭제 하려면, mongod 프로세스를 정지 하고 mongodb 패키지를 삭제 한다.

sudo yum erase $(rpm -qa | grep mongodb-org)

설치가 완료 되었으면 설치된 MongoDB로 접속 하여 테스트를 진행 한다.

mongo --host 127.0.0.1:27017

3. MongoDB 사용자 추가

먼저 admin 권한을 설정한다.

use admin
db.createUser(
  {
    user: "myUserAdmin",
    pwd: "abc123",
    roles: [ { role: "userAdminAnyDatabase", db: "admin" } ]
  }
)

MongoDB 서비스를 재시작 하고, 접속시 로그인을 해보자

# 접속시 ID/PW 작성
mongo --port 27017 -u "myUserAdmin" -p "abc123" --authenticationDatabase "admin"

# 접속후 Login
mongo --port 27017
use admin
db.auth("myUserAdmin", "abc123" )

# 계정 추가
use test
db.createUser(
  {
    user: "myTester",
    pwd: "xyz123",
    roles: [ { role: "readWrite", db: "test" },
             { role: "read", db: "reporting" } ]
  }
)

하지만 아직까지는 Login을 하지 않아도 조회/등록등의 기능이 가능하다.

4. MongoDB 권한 설정

/etc/mongod.conf 설정 파일에서 다음 항목을 수정한다.

security:
    authorization: "enabled"

MongoDB 서비스를 재기동 하고 접속 테스트를 한다.

sudo service mongod restart

로그인 이후에 데이터 조회나 등록을 하려고 하면 권한이 없다는 메시지가 표출 된다.

mongo --port 27017

> db.test.insert( {x:1, y:1} )
WriteResult({
	"writeError" : {
		"code" : 13,
		"errmsg" : "not authorized on test to execute command { insert: \"test\", ordered: true, $db: \"test\" }"
	}
})
> db.test.find( {} )
Error: error: {
	"ok" : 0,
	"errmsg" : "not authorized on test to execute command { find: \"test\", filter: {}, $db: \"test\" }",
	"code" : 13,
	"codeName" : "Unauthorized"
}
# 로그인 진행
> db.auth('myTester', 'xyz123')
1
> db.test.find( {} )
{ "_id" : ObjectId("5b0b8c26efefcbe94ba75c29"), "x" : 1, "y" : 1 }
> db.test.insert( {x:1, y:1} )
WriteResult({ "nInserted" : 1 })
> db.test.find( {} )
{ "_id" : ObjectId("5b0b8c26efefcbe94ba75c29"), "x" : 1, "y" : 1 }
{ "_id" : ObjectId("5b0b8d6753b23794e42015e9"), "x" : 1, "y" : 1 }

참고 자료


Posted by lahuman

QRadar SDK를 Ubuntu 16.x에서 사용하기 위한 모듈 교체 작업

먼저 QRadar SDK를 받아야 한다.

설치는 간단하게 압축을 해제 하고 install.sh 을 실행하면된다.

설치 하고 나서 이후 의존성 문제로 qradar_app_creator 명령어를 실행하면 오류가 발생한다.

Python 버젼은 2.7.9 이상이라고 되어 있지만 기본적으로 2.7.15가 설치 되어 있다. 상위 버젼이면 호환성에 문제가 없을 것이라 생각했지만, 모듈 오류가 많이 발생하므로 2.7.9를 설치하자

Python 설치에 필요한 모듈을 함께 설치 한다.

sudo apt-get install python-pip python-dev
sudo apt-get install build-essential
sudo apt-get install libreadline-gplv2-dev libncursesw5-dev libssl-dev libsqlite3-dev tk-dev libgdbm-dev libc6-dev libbz2-dev

wget https://www.python.org/ftp/python/2.7.9/Python-2.7.9.tgz
tar -xvf Python-2.7.9.tgz
cd Python-2.7.9/
 ./configure --enable-unicode=ucs4  # 추후 pycrypto 모듈 관련 오류 발생을 예방하기 위해 --enable-unicode=ucs4  처리를 한다.
make
sudo make install
sudo shutdown now -r

qradar_app_creator 명령어를 입력하면 몇개의 모듈이 해당 시스템을 지원하지 않는다는 메시지를 확인 할수 있다.

관련해서 pip download 를 이용해 해당 모듈을 수동으로 교체 한다.

pip download cffi==1.11.5
sudo cp cffi-1.11.5-cp27-cp27mu-manylinux1_x86_64.whl /usr/local/etc/QRadarAppSDK/src_packages/

pip download cryptography==1.8.1
sudo cp cryptography-1.8.1.tar.gz /usr/local/etc/QRadarAppSDK/src_packages/

pip download pycrypto==2.6.1
sudo cp pycrypto-2.6.1.tar.gz /usr/local/etc/QRadarAppSDK/src_packages/

# 더 있을 경우 pip download를 이용해서 받아 /usr/local/etc/QRadarAppSDK/src_packages/로 옮긴다.

마지막으로 실행 스크립트에서 교체된 모듈의 이름을 변경한다.

sudo vi /usr/local/bin/qradar_app_creator

# 모듈 명을 바뀐 파일로 변경하면 된다.
"|cffi-1.11.5-cp27-cp27mu-manylinux1_x86_64.whl|cffi-1.11.5-cp27-cp27mu-manylinux1_x86_64.whl|cffi-1.11.5-cp27-cp27mu-manylinux1_x86_64.whl|cffi-1.11.5-cp27-cp27mu-manylinux1_x86_64.whl|workspace"

모듈 교체는 어려운 작업은 아니지만, 하나한 확인해야 하므로 손이 많이 간다.

참고 주소


Posted by lahuman

Elastic Search 하나의 서버에서 여러 노드 구동시 설정

Elastic Search(이하 ES)에서 노드의 메모리는 서버의 메모리의 반(half)을 할당하는 것이 좋다고 한다.

다만 서버의 메모리가 큰 경우(128GB 이상) 32GB만 할당한 노드를 2개를 띄우는 것을 추천 한다.1,2

이때 일반적으로 ES를 여러개를 설치 하는 것이 아니라 설정 파일만 교체 하여 서버를 기동 하는 방식을 사용 한다. ** 설정 파일만 변경하는 것도 있는데 이는 동작 하지 않는다.**

# ES_PATH_CONF 설정으로 elasticsearch.yml 파일이 있는 위치를 설정 한다.
ES_PATH_CONF=/path/to/my/config ./bin/elasticsearch

참고 자료


Posted by lahuman

Elasticdump를 이용한 데이터 백업과 리스토어

elasticsearch의 데이터를 다른 곳으로 이관 하는 작업을 해야 한다. 
이때 사용 가능한 프로그램이 elasticdump 이다. 
elasticdump는 현재 3.3.1 버젼으로 Elasticsearch 5.x 버젼을 지원하고 있다. 
지금 사용하는 elasticsearch 버젼이 2.x여서 해당 버젼을 지원하는 elsticdump 2.4.2를 설치 해야 한다.

설치

설치는 가이드에 나온 것과 같이 npm 을 설치 하고 elasticdump 모듈을 설치 해야 한다.

# npm은 설치 되어 있다고 가정 한다.
npm install elasticdump

# git 에서 코드 download
git clone https://github.com/taskrabbit/elasticsearch-dump.git
cd elasticsearch-dump
# v2.4.2 으로 변경
git checkout tags/v2.4.2
# 버전 확인
./bin/elasticdump --version
2.4.2

데이터 백업

백업되는 데이터 타입은 크게 3가지로 나누어 진다.

  • analyzer
  • mapping
  • data

기본적으로 데이터를 넣기 위해서는 최소한의 데이터 맵핑이 있어야 한다. 

elasticdump 는 Elasticsearch to Ealsticsearch 를 지원하며, File 로 저장 리스토어도 가능하다.

# Copy an index from production to staging with analyzer and mapping:
elasticdump \
  --input=http://production.es.com:9200/my_index \
  --output=http://staging.es.com:9200/my_index \
  --type=analyzer
elasticdump \
  --input=http://production.es.com:9200/my_index \
  --output=http://staging.es.com:9200/my_index \
  --type=mapping
elasticdump \
  --input=http://production.es.com:9200/my_index \
  --output=http://staging.es.com:9200/my_index \
  --type=data

# Backup index data to a file:
elasticdump \
  --input=http://production.es.com:9200/my_index \
  --output=/data/my_index_mapping.json \
  --type=mapping
elasticdump \
  --input=http://production.es.com:9200/my_index \
  --output=/data/my_index.json \
  --type=data

# Backup and index to a gzip using stdout:
elasticdump \
  --input=http://production.es.com:9200/my_index \
  --output=$ \
  | gzip > /data/my_index.json.gz

# Backup the results of a query to a file
elasticdump \
  --input=http://production.es.com:9200/my_index \
  --output=query.json \
  --searchBody '{"query":{"term":{"username": "admin"}}}'

# Copy a single shard data:
elasticdump \
  --input=http://es.com:9200/api \
  --output=http://es.com:9200/api2 \
  --params='{"preference" : "_shards:0"}'

searchBody를 이용하면 원하는 목록 가져올 수 있다.

2017.12.07 테스트 결과 추가

원본데이터를 파일로 저장

1. 원본 데이터 매핑 저장

./elasticdump \
--input=http://10.10.10.202:9200 \
--input-index=elastic_data/elastic_data \
--output=elastic_data_mapping.json \
--type=mapping

2. 원본 데이터 백업

sample로 searchBody를 이용하여 1분 동안의 데이터만 가져오도록 함

./elasticdump \
--input=http://10.10.10.202:9200 \
--input-index=elastic_data/elastic_data \
--output=elastic_data.json \
--type=data \
--searchBody '{
  "query":{
      "range":{
      "log_dttm":{
          "gte":"2017-11-01T00:00:00",
            "lte":"2017-11-01T00:00:59"
        }
        }
    }
}'

파일로 저장된 데이터를 서버에 저장

1. 인덱스 추가 & 데이터 형식 저장

./elasticdump \
--input=elastic_data_mapping.json \
--output=http://10.10.10.180:9201/elastic_data \
--type=mapping

2. 데이터 import 처리

이미 등록된 데이터를 다시 등록 할 경우 _version 의 값이 +1 처리 된다.

./elasticdump \
--input=elastic_data.json \
--output=http://10.10.10.180:9201/elastic_data \
--type=data

참고자료


Posted by lahuman

VirtualBox 특정 포트를 HOST IP로 접근하기

VirtualBox의 가상머신을 이용한 특정 서비스(SSH, DB, WEB, ETC)를 외부에 OPEN 하기 위한 가장 간단한 방법이다.

우선 가상머신에 대한 설치 & 설정은 본 글에서는 제외 한다.

서버 네트워크 설정 변경

  1. 가상 머신의 설정 정보를 클릭 한다.
[그림 1] 가상 머신 설정 정보 확인
  1. 네트워크의 어댑터 1의 타입을 NAT로 변경 한다.

  2. 고급 설정을 눌러 포트 포워딩(P) 버튼을 클릭 한다.

[그림 2] 네트워크 > 어댑터 1 설정
  1. 포트 포워딩 규칙을 설정한다.
[그림 3] 포트 포워딩 규칙 설정
  • 호스트 IP는 다음 CMD 명령어를 통해 확인 할 수 있다.
  $> ipconfig
  • 게스트 IP는 가상머신에서 다음 명령어를 이용하여 알수 있다.
  $> ifconfig
[그림 3] 포트 포워딩 규칙 설정
  1. 접속이 안된다면 확인 사항
  • 우선 가상 머신의 IPTABLE 에 설정을 확인 해야 한다. 다음 명령어는 간단하게 방화벽을 내리는 명령어다.
 $> service iptables stop

아주 간단하지만 유용하다.



Posted by lahuman

MyISMA VS InnoDB

1. MyISMA

MyISMA 의 특징은 non-transactional-safe(트랜잭션 기능 제공 안 함)와 데이터 모델 디자인이 단순하다는 것이다.

장점

  • 단순한 디자인으로 인해 따라서 Select 작업 속도가 빠르고 많은 읽기 작업에 적합하다.
  • Full-text 인덱싱이 가능하여 검색하고 하는 내용에 대한 복합 검색도 가능하다.
  • 테이블 단위로 물리 파일이 존재하여 백업 & 복구가 쉽다.
    1. .frm - 테이블 정의 파일
    2. .MYD - 테이블 데이터 파일
    3. .MYI - 테이블 인덱스 파일

단점

  • Table-Level Lock 사용으로 쓰기 작업이 느리고 다음과 같은 문제가 있다.
    1. SELECT (진행 중), Update(대기 중) 일 경우에 해당 테이블에 대한 SELECT 작업도 함께 LOCK이 걸린다.
  • 데이터 무결성이 보장되지 않는다.
  • 트랜젝션 기능 제공 안 한다.

2. InnoDB

InnoDB는 트랜잭션 기능을 제공하고 Row-level locking, 외래 키 지원, 장애 복구 등의 다양한 기능을 지원한다.

장점

  • Row-level Lock 사용으로 변경 작업이 빠르고 해당 ROW를 제외한 동시 처리가 가능하다.
  • 데이터 무결성 보장한다.
  • 제약조건, 외래 키 생성, 동시성 제어 등 가능하다.

단점

  • Full-text 인덱싱 불가능하다.
  • MyISAM에 비해 시스템 자원을 많이 사용한다.

참조


Posted by lahuman

TOMCAT 설정을 알아보자

TOMCAT은 JAVA WAS(Web Application Server)에서 가장 많이 사용되고 있다.1 

많이 사용되는 이유는 OpenSource(무료)며, 많은 Committers의 참여로 주기적인 패치가 이루어지고 쉬운 설치 JAVA 언어와의 좋은 궁합 등이 있다.

Tomcat을 운영에서 사용하기 위하여 몇 가지 설정 변경이 필요하다.

Tomcat Logging

Tomcat Logger는 JULI(Java Logging Implimentation)이라는 자체 구현체를 제공한다.
기본적으로 Apache Commons Logging 기반으로 구현되어 있고(java.util.logging 사용) extra 패키지를 통해 Log4j, logback 등으로 변경이 가능하다.

기본 설정은 $CATALINA_BASE/conf/logging.properties 파일을 로딩하여 적용한다.

Logging 종류

  • JAVA Logging API : Application당 로깅 설정을 제어하기 위해 java.util.logging 기반의 구현체 JULI 사용 - localhost.yyyy-MM-dd.log 형식의 파일명을 가짐
  • Servlets logging API : javax.servlet.ServletContext.log(…)를 통해 메시지를 때 사용 - manager.yyyy-MM.dd.log 형식의 파일명을 가짐
  • Console : tomcat 운영시 출력되는 STDERR/STDOUT - catalina.out 형식의 파일명을 가짐
  • Access Logging : AccessLogValve 또는 ExtendedAccessLogValve에서 생성되는 로그 - access_log.yyyy-MM-dd.txt 형식의 파일명을 가짐

Sessing

HTTP 세션을 생성 관리해주는 sessiong manager로 Context안에 설정이 안 되어 있는 경우 자동으로 기본 설정값에 의해 생성된다.(기본값 : org.apache.catalina.session.StandardManager)

<Manager classname="org.apache.catalina.session.StandardManager" />

Session Manager 종류

  • StandardMnager : 기본 설정. 한 개의 instance를 사용하는 경우만 적용 가능 - org.apache.catalina.session.StandardManager
  • PersistentManager : 디스크 또는 DB에 세션을 Persist. 세션 스와핑과 장애 대처(fault tolerance) - org.apache.catalina.session.PersistenManager
  • DeltaManager : All-to-All 방식 Session Replication 기능 구현 - org.apache.catalina.session.DeltaManager
  • BackupManager : Primary-Secondary Sessiont Replication 기능을 구현 - org.apache.catalina.session.BackupManager 2

Tomcat Clustering

Tomcat Clustering을 위해서는 $CATALINA_BASE/conf/server.xml의 또는 에 다음과 같은 설정을 한다.

<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster" />

아래는 설정 샘플3이다.

<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
                channelSendOptions="8">
  <Manager className="org.apache.catalina.ha.session.DeltaManager"
          expireSessionsOnShutdown="false"
          notifyListenersOnReplication="true"/>

   <!-- 멀티캐스트 포트(45564) 필요에 따라 변경 -->
 <Channel className="org.apache.catalina.tribes.group.GroupChannel">
   <Membership className="org.apache.catalina.tribes.membership.McastService"
               address="228.0.0.4"
               port="45564"
               frequency="500"
               dropTime="3000"/>
   <!-- replication 메시지 수신 포트는 4000 - 4100 사이 -->
   <Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver"
             address="auto"
             port="4000"
             autoBind="100"
             selectorTimeout="5000"
             maxThreads="6"/>

   <Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
     <Transport className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
   </Sender>
   <Interceptor className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
   <Interceptor className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
 </Channel>

 <Valve className="org.apache.catalina.ha.tcp.ReplicationValve"
        filter=""/>
 <Valve className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>

 <!-- war 를 하나에 반영하면 클러스터에 자동으로 배포되는 FarmWarDeployer 기능시에만 필요
 <Deployer className="org.apache.catalina.ha.deploy.FarmWarDeployer"
           tempDir="/tmp/war-temp/"
           deployDir="/tmp/war-deploy/"
           watchDir="/tmp/war-listen/"
           watchEnabled="false"/>
   -->

 <ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"/>
</Cluster>

session Cluster

  • DeltaManager : Small cluster
  • BackupManager : Large cluster

참고자료

  1. Enterprise 환경에서 Tomcat 운영하기
  2. 2017년기준 JAVA 어플리케이션 서버 사용율
  3. Tomcat8 기준 세션 설정
  4. Tcomat 세션 클러스터링 설정


Posted by lahuman

Cloudera설치 중 다음과 같은 메시지를 만났다.

Cloudera 설치 중 몇몇 모듈에 대하여 403 오류가 발생하여 해당 로그를 따라가 보니 다음과 같은 경고가 있었다.

2017-10-30 16:51:51,833 WARN 1258521080@scm-web-0:com.cloudera.server.web.cmf.csrf.CsrfRefererInterceptor: Rejecting request originating from xx.xx.xx.xx for http://xx.xx.xx.xx:xxxx/cmf/express
2017-10-30 16:56:58,834 WARN 1258521080@scm-web-0:com.cloudera.server.web.cmf.csrf.CsrfRefererInterceptor: Rejecting request originating from xx.xx.xx.xx for http://xx.xx.xx.xx:xxxx/cmf/add-hos

이는 csrf에서 거절 한것으로 Spring security 3.1 이하 버전은 Interceptor를 구현하여 사용하였다.

따라서 클라우데라 설치 디렉터리에서 다음을 찾아서 수정하면 쉽게 처리된다.

cd /usr/share/cmf/webapp/WEB-INF/spring
vim vim mvc-config.xml
# 32 LINE
<!--   <bean class="com.cloudera.server.web.cmf.csrf.CsrfRefererInterceptor" /> -->

이후 서비스를 재기동하면 문제없이 동작한다.

참조 URL

Posted by lahuman

단어 빈도수 계산기

아시는 분의 요청으로 제작한 단어 빈도수 계산기 입니다.

주요 사항

  • JAVA 1.8 이상 필요
  • JAVA FX로 GUI 구현


Posted by lahuman

PostgreSQL 내장 기능을 이용한 복제 스탠바이 서버 구축

사전 지식

WAL-Write Ahead Log

  • 마스터 서버에서 발생하는 모든 작업 로그 생성
  • 생성된 로그를 슬레이브 서버로 전달
  • 슬레이브 서버에서 받은 로그의 복원(재실행)

위와 같은 동작으로 마스터 서버와 같은 스키마/데이터를 가지는 복제 서버를 생성한다. 이 마스터 서버의 로그를 WAL 이라고 하며, 로그 위치는 $PG_SQL/data/pg_xlog 에 쌓인다.

WAL 전달 방식

  • Log-Shipping 방식 : pg_xlog 안의 WAL 파일 자체를 슬레이브 서버로 전달(File Copy)
  • Streaming 방식 : WAL 파일 저장 여부와 관계 없이 로그의 내용을 슬레이브 서버로 전달(Streaming)

Log-Shipping

마스터 서버에서 저장된 WAL 파일의 크기를 지정된 사이즈 많큼 채워야 슬레이브 서버로 전송, 채워지는 시간동안 마스터/슬레이브 서버의 데이터가 어긋남
마스터 서버의 장애 발생시, WAL 파일을 다 채우지 못하여 전달되지 않을경우 데이터의 유실 있음

Streaming

Streaming 방식은 PostgreSQL 9.0 이상에서 사용이 가능하다.

두 서버 간의 네트워크 문제가 없다는 가정하에, 거의 실시간으로 동작(1초 미만의 작은 지연 발생 가능)
슬레이브 서버의 긴 장애가 발생하여 문제가 생길 경우, 유실된 데이터 복구 방법은 슬레이브 서버를 처음부터 다시 구축 해야한다.
따라서 Streaming 방식을 사용하더라도, 이와 같은 문제를 피하기 위해서 Log-Shipping 방식을 적용해 놓는 것이 좋다.

Streaming Replication 적용

PostgreSQL 설치는 기존에 작성된 게시글 참조

마스터와 슬레이브 2대의 서버가 존재 하는 상테에서 진행 된다.
실행 계정은 설치 할때 생성한 postgres 이다.

복제 전용 유저 생성

Streaming 방식 적용을 위해 슬레이브 서버에서 마스터 서버에 접근할 Replication 전용 유저를 생성한다.

마스터 서버 설정

# CREATE ROLE repluser WITH REPLICATION PASSWORD '' LOGIN;

방금 생성한 계정의 접근 권한을 설정하기 위해 $PG_SQL/data/pg_hba.conf 파일에 다음을 추가 한다.
원본 문서에서는 md5로 되어 있으나 단순하게 trust로 변경

host    replication     repluser     192.168.0.0/32      trust

복제를 위한 $PG_SQL/data/postgresql.conf 설정 변경

listen_addresses = '*'  # 인증/권한 관리는 pg_hba.conf 파일에서 진행
wal_level = hot_standby  # 대기 서버에 읽기전용 작업 가능
max_wal_senders = 2  # WAL 파일을 전송할 수 있는 최대 서버 수
wal_keep_segments = 32  # 마스터 서버 디렉토리에 보관할 최근 WAL 파일의 수

서버 기동 명령어 

# 기동
$PG_SQL/bin/pg_ctl -D $PG_SQL/data -l logfile start

# 재시작
$PG_SQL/bin/pg_ctl -D $PG_SQL/data -l logfile restart

# 종료
$PG_SQL/bin/pg_ctl -D $PG_SQL/data -l logfile stop

슬레이브 서버 설정

  1. 마스터 서버 basebackup

pg_basebackup 명령어를 이용하여 최초 백업을 진행 한다.
이 명령은 마스터 서버의 $PG_SQL/data 디렉토리를 통째로 슬레이브 서버의 $PG_SQL/data 디렉토리로 복제/복원 하는 명령이다.
이 명령을 실행하기 전에 슬레이브서버에 $PG_SQL/data는 비어 있어야 한다.

$PG_SQL/bin/pg_basebackup -h $MASTER_IP -D $PG_SQL/data -U repluser -v -P --xlog-method=stream
  1. 설정 변경

$PG_SQL/data/postgresql.conf 설정 변경

listen_addresses = '*'  # 인증/권한 관리는 pg_hba.conf 파일에서 진행
hot_standby = on  # 대기 서버에 읽기전용 작업 가능

$PG_SQL/data/recovery.conf 파일을 추가 하고 다음의 내용을 작성한다.

standby_mode = on
primary_conninfo = 'host=MASTER_IP port=5432 user=repluser password=password'
trigger_file = '/path/of/triggerfile' # failover시 마스터 승격을 위한 트리거 파일

primary_conninfo 옵션 정보로 마스터 서버에 접속해 실시간 WAL 파일을 전달 받는다. 

슬레이브 서버를 마스터 서버로 전환하는 방법은 두가지가 있는데, pg_ctl promote 명령어를 이용하는 방법과 recovery.conf파일의 trigger_file 옵션을 이용하는 방법이다.
단순하게 해당 경로에 파일이 생성되었을 때,(touch 등으로) 스텐바이 서버가 새로운 마스터로 승격된다.
슬레이브 서버를 마스터로 변경할때는 기존 마스터가 확실히가 다운된 상태인지 확인 해야 한다.

서버 기동 명령어 

# -p PORT
# -D 데이터파일 위치
# & 백그라운드 실행
$PG_SQL/postmaster -p 5433 -D $PG_SQL/data &

Failback

기본적으로 Failback을 위한 특별한 기능이 제공되지 않는다. 따라서 다음과 같은 단계를 거쳐야 한다.

  1. 마스터 서버 장애가 복구 되면 이 서버를 슬레이브 서버로 구축
  2. 새 마스터 서버(기존 슬레이브)를 강제로 다운
  3. 새로 구축된 슬레이브(구 마스터)를 마스터 서버로 승격
  4. 슬레이브 서버 재 구축

이외의 방법은 PostgreSQL Wiki-Replication, Clustering, and Connection Pooling에서 볼 수 있다.

참고 자료

PostgreSQL Replication 구축하기 
PostgreSQL Replication – Log Shipping
Postgresql 9.x Replication – Streaming Log

Posted by lahuman