블로그 이미지
OSSW(Open Source System SoftWare

calendar

    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    

Notice

1. PostgreSQL 논리적 디코딩 소개

http://postgresql.kr/docs/current/logicaldecoding.html


9.4 버전에서 새로 등장한 개념으로,

트랜잭션 로그를 출력 플러그인을 이용해서 사용자 정의 형태로 변환하는 기능을 말합니다.


기존 복제가 트랜잭션 처리에서 먼저 기록한(write-ahead) 내용을 다른 서버로 그대로 보내서 그것을 재실행하는 방식의 스트리밍 복제였다면, 논리적 디코딩을 이용하면 논리적 개념으로 데이터베이스 복제가 가능해 집니다.  이 말은 대상 데이터베이스가 똑 같은 OS에, 똑 같은 버전의 PostgreSQL 서버여야 할 필요가 없으며, 심지어 MySQL이나 기타 다른 데이터베이스, 더 나아가 굳이 데이터베이스가 아니어도 복제가 가능하다는 것을 의미합니다. 트랜잭션 로그를 분석해서 원하는 출력 양식으로 바꿀 수 있는 출력 플러그인만 있다면 말이지요.


2. 논리적 디코딩 출력 플러그인들

  • test_decoding
    배포판에 포함된 테스트 용도, SQL이나, pg_recvlogical 명령으로 확인 가능합니다.
  • decoder_raw
    https://github.com/michaelpq/pg_plugins/tree/master/decoder_raw
    트랜잭션 로그를 만들었던 DML로 출력
  • pglogical
    https://2ndquadrant.com/en/resources/pglogical/
    트리거 기반 테이블 단위 복제 솔루션인 slony를 대체할 테이블 단위 복제 솔루션, 멀티 마스터 기능은 아니고, 마스터에서 배포하고 슬레이브에서 구독하는 방식으로 단방향 복제 솔루션입니다.
  • decoding_json
    https://github.com/leptonix/decoding-json
    트랜잭션 로그를 분석해서 그 내용을 json 양식으로 만듭니다. 자료를 뽑을 때는 pg_recvlogical 명령을 사용해서 확인해 볼 수 있습니다.

 

3. 개념

논리적 디코딩 기능을 이용 하는 절차는 다음 순서로 진행합니다.

  1. 원본 서버의 환경 설정값을 확인합니다.
    replication 권한이 있는 사용자가 있어야 하고, (슈퍼유저와 분리하는 것이 안전합니다, - 대신에 아래 pglogical 용이라면, 이 사용자에게 pglogical 관련 객체들 사용할 수 있는 권한도 부여해야합니다. 테스트 용도로라면, 그냥 postgres 슈퍼 유저를 사용하세요)
    CREATE ROLE replicatest REPLICATION LOGIN;

    pg_hba.conf 파일에서 해당 사용자가 스트리밍 복제를 할 수 있도록 설정하고,
    host replication replicatest 192.168.0.10/32 trust

    postgresql.conf 파일에서 wal_level 값은 logical, max_replication_slots 값은 0 보다 크게, max_wal_senders 값도 0보다 크게 지정하고,

    필요하다면 변경한 설정값을 반영하기 위해서 서버 재실행합니다.

    (pglogical 기능 테스트라면 복제 내용을 재 실행할 대기서버 쪽에도, max_replaction_slots 값이 0 이상이어야 하더군요)

  2. 원본 서버 (배포 서버)에서 pg_create_logical_replication_slot() 함수를 이용해서 논리 복제 슬롯을 만듭니다.

    여기서 기억해야 할 것은 이 슬롯이 만들어지는 순간부터 트랜잭션 로그가 논리 복제 기능을 사용하는 응용프로그램(또는 다른 서버)에서 다 빼내가기 전까지 트랜잭션 로그를 지우지 않는다는 것입니다.
    사용하지 않는 복제 슬롯을 만들어두면, 결국 pg_xlog 쪽 WAL 파일 재활용을 하지 않게 되고, 결국 해당 디렉터리 가용 공간이 없어지게 되어 서비스 장애까지 이어질 수 있습니다. 주의해야 합니다.

    논리적 복제 슬롯을 만들 때, 매개변수로 출력 플러그인을 지정합니다.
    SELECT
    pg_create_logical_replication_slot('슬롯이름', '출력플러그인이름', '플러그인에서사용하는옵션이름', '옵션값')
    형태로 SQL 구문으로 지정할 수 있고,
    pg_recvlogical 명령같이 논리적 복제를 구현하는 응용프로그램측에서 스트리밍 복제 프로토콜을 이용 해당 슬롯을 만들 수도 있습니다.

  3. 논리 디코딩을 이용하는 응용프로그램(또는 서버)에서 원본 서버에서 발생한 DML에 대한 트랜잭션 로그를 사용합니다. 사용은 두 가지가 있는데, 하나는 그 로그를 꺼내오는 경우(get)고, 다른 하나는 그냥 두고 가져다 쓰는 경우(peek)입니다.

    응용프로그램이 트랜잭션 로그 디코딩을 요구하면, 출력 플러그인이 해당 복제 슬롯 정보를 확인하고, 해석해야할 트랜잭션 로그를 WAL 파일에서 찾아서 그것을 해당 플러그인 출력 양식에 맞춰 응용프로그램 쪽으로 보냅니다. 이때, get 방식으로 요청하면, 복제 슬롯 상태값에서 lsn(로그 시퀀스 번호)을 증가합니다.

  4. 원본 데이터베이스 서버가 기억하는 복제 슬롯 정보는 마지막 꺼내간 lsn 번호입니다. 즉, 그것을 사용하는 응용프로그램에서 그 자료가 제대로 쓰였는지는 전혀 모릅니다. 또한 이 상태는 checkpoint 작업으로 디스크에 영구 보관됩니다. checkpoint 전 서버 비정상 종료가 있었다면, 서버가 다시 시작되고, 다시 해당 슬롯을 사용하는 응용프로그램 트랜잭션 로그를 달라고 요청하면 이전에 이미 받았던 자료가 올 수도 있습니다.  즉 논리적 복제 슬롯을 이용하는 응용 프로그램이나, 서버는 반드시 이 부분의 중복 처리에 대한 정책을 세워야 합니다.

  5. 해당 복제 슬롯의 상황은 pg_replication_slots 뷰에서 이 슬롯을 스트리밍 리플리케이션 프로토콜로 사용한다면, pg_stat_replication 뷰에서 그 상황을 볼 수 있습니다.


4. pglogical

2ndQuadrant 사에서 만든 PostgreSQL 확장 모듈입니다.

이 글은 https://2ndquadrant.com/en/resources/pglogical/pglogical-installation-instructions/ 페이지 기준으로 몇가지 작업을 하면서 정리한 것입니다.


이 확장 모듈은 트리거 기반 복제 솔루션인 slony 의 대안으로 개발되었습니다.  왜냐하면, slony가 나온 뒤 PostgreSQL 서버는 background worker, logical decoding 등 많은 기능이 추가되어 이 기능들을 잘 쓰면 테이블 단위 복제가 가능할 것이다는 생각이 들었기 때문입니다.


기본 개념은 운영 서버에서 배포하고, 슬레이브 서버에서 구독하는 방식입니다. 이 배포와 구독은 pglogical 모듈을 설치하고, 재실행하면 생기는 background worker 프로세스가 관리하고, 내용 전달은 pglogical_output 이라는 모듈에서 제공하는 논리적 디코딩 출력 플러그인을 사용해서 스트리밍 복제 프로토콜을 이용합니다.


즉, 배포와 구독 서버간 스트리밍 복제가 가능하도록 설정이 먼저 되어 있어야 합니다. 물론 이전의 스트리밍 복제 대기 서버를 구축하는 것 처럼 pg_basebackup을 이용해서 운영서버 전체를 백업하고 재구축할 필요는 없습니다. 그저 깡통 데이터베이스에 필요한 테이블만 있으면 됩니다.


 

작업 방법은 다음과 같습니다.


  1. 제일 먼저 할 작업은 운영 서버는 배포 역할을 할 수 있도록, 대기 서버는 구독 역할을 할 수 있도록 스트리밍 복제 환경을 만들어야 합니다. 자세한 설명은 윗 페이지 참조

  2. pglogical 이라는 확장 모듈을 설치합니다.
    github (https://github.com/2ndQuadrant/pglogical) 에서 소스를 받아서 직접 컴파일을 하거나, 위 홈페이지에서 해당 패키지를 설치하거나, 자기 환경에 맞게 설치합니다.

  3. psql 창에서 CREATE EXTENSION pglogical; CREATE EXTESION pglogical_output; 두 모듈을 설치합니다.

  4. 각 서버(노드)는 pglogical 모듈을 이용해서 논리적 복제를 사용하겠다는 정보로, 제일 먼저 각 노드별 노드 등록을 합니다. pglogical.create_node() 함수 이용. 이 작업은 각각의 노드에서 해야 합니다. 즉, 접속 dsn 값은 자기 자신의 서버로 접속하는 정보를 입력합니다.

  5. 배포 서버 쪽에서는 배포할 세트를 만들고, 그 세트 안에 배포할 객체들을 등록합니다. 현재는 테이블과 시퀀스입니다. pglogical.create_replication_set(), pglogical.replication_set_add_sequence(), pglogical.replication_set_add_table() 함수를 이용합니다.  확장 모듈을 설치하면, 기본으로 사용할 수 있도록 default 라는 세트가 이미 등록되어 있기 때문에, 특별한 경우가 아니면, 그냥 default 세트에 원하는 객체들을 포함시기는 작업 (repliaction_set_add_*) 만 하면 됩니다.

  6. 구독 서버는 위에서 작업한 자신의 노드 등록과 함께, 구독 등록도 해야 합니다. pglogical.create_subscription() 함수 이용. 이 때 기억해야 할 것은 논리적 스트리밍 복제 슬롯이 만들어지는 시점 - 트랜잭션 로그를 보내는 시작 lsn 값이 지정되는 시점 - 은 구독 서버가 구독 작업을 시작하는 시점이라는 점입니다. 즉, 구독 이후부터 발생한 변경 사항이 구독 서버에 적용 될 것이라는 점입니다.
    (해당 테이블을 아에 그대로 복제하겠다면, pglogical.alter_subscription_resynchronize_table() 함수를 이용합니다.)

    또 하나 기억해야 할 것은 구독 시작 이후 그 구독 서버를 더 이상 사용하지 않아  서버가 중지된 상태여도, 명시적으로 구독 중지(pglogical.drop_subscription() 함수 이용) 처리를 하지 않았다면, 구독 신청으로 만들어진 논리적 복제 슬롯은 삭제 되지 않는다는 점입니다. 이 말은 해당 슬롯의 마지막 lsn 뒤 부터는 모든 트랜잭션 로그를 보관하겠다는 것을 의미합니다. 결국 pg_xlog 쪽 가용 공간이 점점 줄어 나중에는 서버 장애로까지 발전할 수도 있다는 것입니다.


4.1 pglogical 한계

논리적 복제를 이용하기 때문에, 논리적 복제 한계가 그대로 있습니다. 자세한 이야기는 이 글 맨 앞에 언급한 사용 설명서를 참조하세요.


CREATE EXTENSION 명령이 데이터베이스 단위로 이루워짐으로 결국 이 복제 작업도 데이터베이스 단위일 수 밖에 없으며, 여러 데이터베이스를 여러 객체를 복제하는 상황이라면, 그 만큼의 스트리밍 복제 환경이 구축되어야 합니다.


또한 복제 작업은 background worker 프로세스로 진행 됨으로 슈퍼 유저 권한으로 작업이 진행된다는 점입니다. 슈퍼 유저 권한을 부여하고 싶지 않다면, pglogical 스키마 안에 있는 모든 객체를 사용할 수 있는 권한을 스트리밍 복제 작업하는 계정에게 부여해야 합니다. 


그 외 여러 한계점들에 대해서는 2ndQuadrant 사 홈페이지를 참조하세요.


5. 마치며

이상으로 논리적 복제와 그것을 이용하는 pglogical 확장 모듈을 이용한 테이블 단위 복제에 대해서 살펴봤습니다.  실무 환경에서 이 복제 정책을 도입 할 때는 꽤 많은 다양한 예외 상황을 고려해야 합니다.  구독 서버에서 해당 자료가 변경 된 경우와, 그 테이블이 복잡한 관계성을 유지하고 있는 경우(트리거, 참조키, 상속)에서 자료 동기화 유연성을 어떻게 확보할지, 그리고, 구독 서버의 장애시 배포 서버의 트랜잭션 로그 관리 등 꼼꼼하게 여러
상황을 따져봐야 할 것입니다.


하지만, 좀 더 유연하게 생각하면, 파티션 테이블을 만들고, 하위 테이블 들에 대해서 서로 이 pglogical로 묶으면 부하 분산용 다중 마스터 환경도 구현 가능할 듯합니다. 참신한 아이디어만 있다면, 충분히 유용하게 사용될 수 있는 모듈임에는 분명한 듯합니다.


- posted by 김상기


posted by 김상기 ioseph

0. PostgreSQL 20주년

올해로 PostgreSQL이 세상에 나온 지 스물 돌이 되었습니다.

마이클 스턴브래커 어르신의 postgres 프로젝트까지 거슬러가면 이보다 훨씬 더 오래되었겠지만, PostgreSQL이라는 이름이 등장한 지는 올해로 20년이 되었네요.

이 기념으로 PostgreSQL 커뮤니티에서는 위와 같이 포스터도 만들면서 자축하고 있습니다. 또한 올 해로 열 번째 열린 PostgreSQL 개발자 사용자 회의가 캐나다 오타와에서 열렸고, 제가 다니고 있는 회사 지원으로 이번에 같이 일하고 있는 동료와 함께 저도 참석하게 되었습니다.

이 글은 올 해 열린 PGCon 행사 참관 후기입니다.


1. PGCon 소개

PGCon (http://pgcon.org) 행사는 PostgreSQL 개발자, 사용자가 일 년에 한 번 모이는 PostgreSQL 최대 행사입니다. 참석하는 사람들은 대부분 PostgreSQL 커뮤니티 메일링 리스트에서 꾸준히 활동하는 사람들로 매번 메일로만 의견을 주고 받던 사람들이 한 자리에 모여 여러 주제로 발표도 하고, 토의도 하고, 같이 술을 마시며 놀기도 하는 행사입니다.

주로 다루는 내용은 크게 세 부분으로 구분되는데,

하나는 PostgreSQL 차기 버전에 대한 토의 - 일반적인 새 기능 발표회 같은 분위기가 아니라 서로 의견을 주고 받으며 서로의 부족한 부분을 채워나가는 자리입니다. 여기서 발표되는 새 기능들은 대부분 차기 버전에 수용되기는 하지만 막상 구현된 모습은 이 발표 때의 모습과는 사뭇 다른 경우가 제법 있었습니다.

다른 하나는 각 기업들, 각 지역 커뮤니티들의 사례 발표들로 구성됩니다. 대부분의 발표는 PostgreSQL 엔진에 촛점이 맞춰져 글로벌 개발자 그룹도 자리를 함께 하면서 자신들이 만든 프로그램이 어떻게 쓰이고, 어떤 점이 미흡하고, 어떻게 개선해 나갈 것인가를 살펴봅니다.

또 다른 하나는 PostgreSQL을 사용하는데 필요한 부가 솔루션, PostgreSQL을 이용한 솔루션을 소개합니다. 그 또한 오픈 소스로 되어 있는 것이 대부분이고, 자기 회사의, 또는 자신들의 오픈 소스 프로젝트를 자랑하는 자리입니다.


2. 오타와 여행

우리나라에서 캐나다 오타와까지는 비행기로 한 번에 가는 교통편이 없어, 토론토를 거쳐 국내선으로 갈아타고 갔습니다. 인천에서 토론토까지 14시간, 국내선 갈아타는 시간 3시간, 토론토에서 오타와까지 1시간, 오토와 공항에서 숙소까지 1시간, 이동하는데만 거의 20시간이 걸렸습니다.

관광을 위해서는 박물관과 미술관 관람을 제외하면 하루면 충분히 다 둘러 볼 수 있는 자그마한 도시였습니다.

랜드마크인 캐나다 국회의사당과 그 옆에 흐르는 운하와 그 강변으로 있는 박물관과 미술관 그리고 앞에 있는 대성당, 그리고, 캠퍼스 담장이 없는 오토와 대학 - 첫날 회의 참석 등록을 하러 가는 길에 잠깐만 짬 내면 다 둘러 볼 수 있는, 한 국가의 수도라기 보다는 어느 한적한 마을을 들린 듯했습니다.

그리고 매일 식사를 책임졌던 바이워드 시장 - 재래시장이라고 소개는 하고 있으나, 식당과 상점들로 가득한 그냥 한 구역이였습니다.

다음은 행사장 건물 앞에서 찍은 사진입니다.



3. PGCon 2016 내용

http://pgcon.org/2016

총 5일에 걸친 긴 일정이었는데, 앞 이틀은 사용법 강좌를 다루고, 이틀은 각 주제들에 대한 발표와 질의응답 형태의 회의, 마지막 날은 사용자들이 모두 모여 그 자리에서 여러 주제들을 발의하고 토론하는 형태로 진행되었습니다.

참여자들 대부분이 글로벌 개발 그룹 구성원이거나, 각국 컨트리뷰터, PostgreSQL 전문 기술 지원 업체 엔지니어들이었기 때문에, 발표 중간 중간 질문과 답변이 오고 가고 자기 의견을 주장하기도 하고, 전세계 사람들이 모였으니, 의사소통이 안되는 부분은 그 자리에 참석한 다른 분이 대신 통역해 주기도 하는 참 역동적인 모임이었습니다.

참석한 발표들의 간단 요약


3.1. PostgreSQL 확장성 소개

http://www.pgcon.org/2016/schedule/attachments/424_PGCon-PostgreSQL-Extensibility.pdf

제가 생각해도 PostgreSQL 이야기의 키노트로 딱 맞는 주제였습니다.

PostgreSQL은 관계형 데이터베이스 관리 시스템이기도 하지만, 내가 꿈꾸는 어떤 데이터베이스를 만들고자 할 때 그 데이터베이스를 만들 수 있는 하나의 개발 도구로 사용할 수 있는 아주 훌륭한 도구임을 소개하고 있습니다.

그래프 데이터베이스를 PostgreSQL 기반으로 만들고 있는 국내 업체인 비트나인도 한 예가 될 것입니다.


3.2. 얀덱스 메일 전환 성공기

http://www.pgcon.org/2016/schedule/attachments/426_2016.05.19%20Yandex.Mail%20success%20story.pdf

러시아 포탈 업체의 메일 서비스 (https://mail.yandex.com/)를 오라클에서 PostgreSQL로 전환했던 엔지니어 삽질기를 소개했습니다. 중간 중간 실패한 이야기들과 지금의 모습으로 결정하고 사용자들이 전혀 눈치 못 채게 자료를 옮겨가는 전략 등, 다양한 마이그레이션 전략을 소개했습니다.

초당 25만 tps 성능을 유지하는 방법, 300TB의 거대 용량을 전환하는 전략 등 DB 입장에서도 놀랍지만, 전체 설계 입장에서도 살펴볼 것이 많은 발표였습니다. 

이 발표에서 가장 인상 깊었던, 누구나 공감할 수 밖에 없었던 순간


3.3. ERROR: snapshot too old

http://www.pgcon.org/2016/schedule/attachments/420_snapshot-too-old.odp

오라클에서 봤던 그 오류 메시지 도입에 대한 이야기였습니다.

이 오류가 필요했던 이유, 설정 방법, 대응 방법 등을 소개하고 있습니다.

기업 친화적인 Postgres Advanced Server를 판매하고 있는 EnterpriseDB사의 발표였습니다.

이번 발표 세션들 가운데, 성능 이슈 관련, 기업 운영 환경 입장에서의 개선 이슈들은 대부분 이 EnterpriseDB사가 맡았습니다. 하나의 실험 정신 투철한 데이터베이스가 기업에서 사용되고, 그 범위가 넓어지고, 이 회사의 매출이 증가하고 그것이 다시 오픈소스 발전에 기여할 수 있도록 하겠다는 흔히 말하는 오픈 소스 에코 시스템의 좋은 사례 같습니다.


3.4. B-Tree 이야기

http://www.pgcon.org/2016/schedule/attachments/423_Btree

러시아 대표 PostgreSQL 기술지원 업체인 Postgres Professional, https://postgrespro.ru/ 의 엔지니어가 설명한 PostgreSQL 색인 이야기입니다.

특별한 이야기는 없지만, PostgreSQL을 처음 접하는 이들에게는 딱 알맞는 내용으로 구성되어있습니다.

물론 국내 문서도 찾아보면 이 보다 더 자세히 소개한 문서들이 많지만, 잠깐 소개합니다.


3.5. 쿠바에서의 PostgreSQL

http://www.pgcon.org/2016/schedule/attachments/398_PgConf2016_Cuba.pdf

개인적으로는 가장 인상 깊었던 발표였습니다.

쿠바 PostgreSQL 사용자 그룹이 어떻게 만들어졌고, 어떤 활동을 해 왔고, 현재 이런 모습이다는 식을 낯선 스페인어 억양의 영어 발표여서, 읽을 수 있는 것은 윗 링크의 발표 화면들과 발표자의 표정과 몸짓 뿐.

가장 크게는 쿠바의 독특한 정치적 성향 때문이기도 하겠지만, 그 보다 산학 협력 환경, 커뮤니티를 유지하고, 자료를 발표하고, 그런 활동들로 기업 내에서도 저변 확대되어 가는 이야기를 들으면서 국내 PostgreSQL 활성화 방안에 대한 부분도 같이 고민해 볼 수 있었던 시간이었습니다.


3.6. 단순 쿼리의 속도 향상

http://www.pgcon.org/2016/schedule/attachments/400_RunSimpleQueryFaster.pdf

EDB사 엔지니어가 쿼리 실행기를 해킹해서 얻은 성능 향상에 대한 발표였습니다.

요지는 현 쿼리 실행기가 단순 쿼리에 대해서는 많이 느리니, 단순 쿼리로 판단되면, 실행기 내부 작업을 단순하게 처리하도록 작업 내역을 분기하자는 것입니다.

커뮤니티 메인 코드에 반영 될 가능성은 별로 없어 보였지만, 자신들의 해킹이 기업 환경에서는 이렇게 쓸모 있다는 식의 발표를 아주 정량적으로 자료를 수집하고, 논리적으로 기존 개발 그룹에 설득하는 작업이었습니다.

한편으로 보면, 오픈 소스 공동 개발에서 꼭 필요한 활동입니다.


3.7. 반짝 이야기들

열 명이 넘는 발표자들이 각 5분 정도 짧게 제 각각의 이야기를 발표하는 시간도 있었습니다.

pgAdmin4 열심히 만들고 있다. PGCon.Asia 를 싱가포르에서 진행되었다. TPC-H 벤치마킹의 필요성 방법, ....

이 중에 꽤 재미났던 발표는

http://www.pgcon.org/2016/schedule/attachments/408_LightningTalkSergeRielau.pdf

DB의 하드웨어 스펙은 어느 정도면 적당한가에 대한 한 사례 발표였습니다.


3.8. PostgreSQL 보다 빠르게

http://www.pgcon.org/2016/schedule/attachments/399_postgresql-96-scalability-perf-improvements.pdf

이 발표도 EDB 엔지니어가 했습니다.

이번에는 data page 크기에 대한 고려, 트랜잭션 로그 쓰기에서 잠금 문제 등 엔진 해킹을 통한 성능 개선 사례 발표였습니다.


3.9. Atomic 프로젝트 안에서의 PostgreSQL

컨테이너 자동화 프로젝트인 atomic 프로젝트 참여자가 atomic으로 PostgreSQL을 사용하면, 고가용성이 얼마나 손쉽고, 좋아지는가에 대한 소개였습니다.

http://jberkus.github.io/love_failover/

엉청나게 많은 오픈 소스 프로젝트를 소개했습니다.

여기서 배우는 것. 이젠 잘 만들어 쓰는 것보다 잘 가져다 쓸 놈이 어디 있고, 그 놈은 이런 장단점이 있어 이런 조합으로 구성하는 것이 제일 낫다는 것을 빨리 아는 것이 중요하다는 것.


3.10. PoWA

이번에는 프랑스 대표 PostgreSQL 기술지원 업체인 dalibo 의 자사 PostgreSQL 모니터링 도구인 PoWA 소개였습니다.

모니터링 도구가 필요하다면, 이것으로 구축해 보는 것도 좋을 것 같습니다. 이 도구의 특징은 실시간으로 해당 데이터베이스의 필요한 인덱스를 추천해 준다는 점입니다.


3.11. NTT 빌링 시스템 마이그레이션 이야기

http://www.pgcon.org/2016/schedule/attachments/422_A%20Challenge%20of%20Huge%20Billing%20System%20Migration_20160520.pdf

일본 통신사인 NTT의 빌링 시스템 차세대 전환 이야기인데, 놀라운 사실은 이런 통신 기업 기간계 시스템에서 조차 차근하게 준비해서 PostgreSQL로 운영하게 되었다는 점이었습니다. 이 안에는 당연히 pg_hint 같은 쿼리 실행 최적화기를 마음대로 건드리는 NTT 자체 기술력이 바탕이 되었기 때문이기도 합니다.

이 발표의 핵심도 PGCon 이라는 독특한 회의에 촛점을 맞춰, '왜 PostgreSQL 개발 그룹은 pg_hint 같이 쿼리 힌트를 거부하는가?' 라는 아주 저돌적인 질문이었습니다.  기업 환경에서는 쿼리 힌트 기능은 필요악이기 때문에, PostgreSQL에서도 당연히 쿼리 힌트가 지원되길 바란다는 내용이었습니다.


3.12. 데이터베이스 벤치마킹

http://www.pgcon.org/2016/schedule/attachments/413_Benchmarking%20Databases%202016.pdf

데이터베이스 벤치마킹의 작위성에 대한 이야기였습니다. IT 업계에 오래 있었던 분들은 대부분 납득 가는, 어떻게 수치가 임의적으로 해석되고, 그것이 어떻게 포장 되는가에 대한 엔지니어 입장에서의 발표였습니다. 그 어떤 벤치마크 수치도 객관적이다고 말하기는 힘들겠지만, 일단 벤치마킹을 하려는 이들이 갖춰야할 객관성을 살펴 볼 수 있습니다.


3.13. 사용자 언컨퍼런스

https://wiki.postgresql.org/wiki/Pgcon2016userunconference

PGCon 행사의 꽃인 토론 마당

늘 wiki 페이지로 올 해는 이런 이야기가 있었구나는 식의 글만 보다가 직접 참여하게 되었지만, 언어의 장벽을 넘기는 힘들었습니다. 일상 회화나 겨우 할 수 있는 상황에서 기술 이야기를 넘어 제반 토론에 참여하고 의견을 내고 할 형편이 못 되어 참 아쉬웠습니다. 역시나 이 부분은 윗 링크가 정리되는 대로 다시 한 번 읽어 보는 것으로 만족해야겠습니다.

이 토론 마당의 첫 주제는 PostgreSQL이 제 오랜 기간 동안 사용되었고, 이제 기업들도 그 개발에 참여하고, 사업가, 개발자, 사용자들간의 이해득실을 따지게 되고, 여러 사회적, 정치적, 도덕적 상황들이 초창기 그저 멋진 데이터베이스를 만들어 쓰겠다는 순수함(?)을 많이 훼손되고 있는 마당에 이제는 이런 문제를 어떻게 하면 민주적으로 풀어낼 것인가를 그네들끼리 열심히 토론하고 있었습니다.

그저 일반론적인 이야기로는 건전한 대안 있는 비판은 언제나 생기 넘치는 조직으로 유지하는데 꼭 필요하다는 것 정도. 그리고 다양성을 인정하고, 합의는 민주적이여야 한다는 교과서 이야기입니다.

이 사진은 언컨퍼런스 시작하면서 각 주제 선정 작업 결과였습니다.

한 사람씩 이야기를 나눴으면 좋겠다는 주제를 이야기하고 같이 참여하겠다는 사람들을 조사하고 그 자리에서 시간과 장소를 결정하는 형식이었습니다.


4. 마무리

오픈 소스 전체에서 PostgreSQL은 정말 작은 한 소프트웨어일 뿐인데, 이렇게 많은 이들이 한 자리에 모여 며칠씩 서로 이야기를 나누며 어떤 이는 자기 경험을 나누고, 어떤 이는 열심히 공부하고, 서로 토론하는 모습이 참 인상적이였습니다.

물론 기업의 매출 증대를 위해 이해 관계자들은 이번 자리에서도 아주 전략적으로 접근하기도 했겠지요. 하지만, 비영리 단체가 기업과의 묘한 관계 유지 하면서 매년 이렇게 행사를 계속 유지하고 있는 것이 놀랍기도 했습니다.

끝나는 시간 열린 경매 시간도 참 인상 깊었습니다. 비영리 단체의 자금 조달 방법.

한 편의 긴 '그들만의 리그'라는 다큐멘터리 영화를 본 듯합니다.


5. 보너스

오타와 운하에서 바라본 캐나타 문명 박물관과 가티노시 야경 - 이 사진 찍어 보여 달라는 팀원의 부탁에 자다가 찍으러 감.


Posted by 김상기


posted by 김상기 ioseph

1. pgcrypto 확장 모듈 설치

데이터베이스 관리자 권한으로 해당 데이터베이스에 접속해서,

CREATE EXTENSION pgcrypto

쿼리문을 실행


기본적으로 해당 확장 모듈에 포함된 함수들은 public 스키마에 만들어짐


2. 기본 사용법

postgres=# \dx+ pgcrypto "pgcrypto" 확장 기능 안에 포함된 객체들 객체 설명 ------------------------------------------------------- function armor(bytea) function armor(bytea,text[],text[]) function crypt(text,text) function dearmor(text) function decrypt(bytea,bytea,text) function decrypt_iv(bytea,bytea,bytea,text) function digest(bytea,text) function digest(text,text) function encrypt(bytea,bytea,text) function encrypt_iv(bytea,bytea,bytea,text) function gen_random_bytes(integer) function gen_random_uuid() function gen_salt(text) function gen_salt(text,integer) function hmac(bytea,bytea,text) function hmac(text,text,text) function pgp_armor_headers(text) ... (36개 행)

함수 설명

armor, dearmor, pgp_*() 함수는 openpgp 구현 관계 쪽으로 오라클 DBMS_CRYPTO 하고 상관 없음, 여기서는 설명 생략

crypt, digest, hmac : 사용자 비밀번호 문자열 뭉개는 함수 (역함수 없음)

encrypt, encrypt_iv, decrypt, decrypt_iv : 단일키 기반 자료 암호화, 복호화

gen_salt : 임의의 salt 만드는 함수

gen_random_* : 부가 함수.


pgp (개인 메시지(email) 서명 및 암복호화에 대한 한 방법) 기반 비대칭 암복화까지를 고려하지 않는다면, 

평문 뭉개는 기능(digest, hmac)과 단일키 기반 암복호화 크게 두가지로 나뉨


2.1 사용자 비밀번호 뭉개기

postgres=# select digest('mypass', 'sha256');
                               digest                               
--------------------------------------------------------------------
 \xea71c25a7a602246b4c39824b855678894a96f43bb9b71319c39700a1e045222
(1개 행)

기업마다 보안정책이 달라서 이 암호문 뭉개기 작업에 대한 정책에서 임의의 저장된 key가 있어야 하는 경우는 hmac() 함수를 사용함.

한편 뭉개진 문자열 안에 그 키(이때는 소금이라 함)를 포함시키는 전통적인 crypt() 함수는 gen_salt() 함수와 함께 사용함,

gen_salt() 에서 만드는 salt 형태에 따라 뭉개는 방식을 달리함

postgres=# select crypt('mypass',gen_salt('bf'));
                            crypt                             
--------------------------------------------------------------
 $2a$06$dRBVXc2WpqOZQZj4tmAZzur0tQ2owGnI74BKoaaNuu8uboNsaa6tW
(1개 행)


그럼 사용자가 입력한 비밀번호가 맞는지 확인하려면?

당연히 입력한 문자열을 똑같은 방식, 똑같은 키(소금)으로 뭉개서 그 뭉개진 결과가 같으면 같다라고 판단 함


팀: 즉, 그 누구도 DB에 저장된 자료를 복호화해서는 안되는 자료는 이 방식으로 뭉개야 함

비밀번호는 새로 발급 되어야 하지, 예전 비밀번호를 찾아주는 서비스를 제공하면 안됨


2.2 자료 암호화 복호화

postgres=# select encrypt('안녕하세요','내키', 'aes');
              encrypt               
------------------------------------
 \x7e1dba6095d28477fb6d30e45569f780
(1개 행)
postgres=# select decrypt(decode('7e1dba6095d28477fb6d30e45569f780','hex'), '내키', 'aes');
             decrypt              
----------------------------------
 \xec9588eb8595ed9598ec84b8ec9a94
(1개 행)
postgres=# select convert_from(decrypt(decode('7e1dba6095d28477fb6d30e45569f780','hex'), '내키', 'aes'), 'utf-8');
 convert_from 
--------------
 안녕하세요
(1개 행)

중요한 부분은 decrypt() 함수 반환자료형이 bytea 형이라는 점

그래서, 그 원본 값이 문자열이었다면, convert_from() 함수로 적당한 문자열 인코딩으로 변환해 주어야 함

encrypt_iv() 함수는 암호화 과정에서 사용할 초기화 문자열을 임의로 지정할 수 있도록 하는 것임


2.3 그 외

http://postgresql.kr/docs/current/pgcrypto.html (pgcrypto 모듈 한글 설명서)


3. 오라클 DBMS_CRYPTO 패키지를 이용한 함수 마이그레이션

3.1 비밀번호 뭉개기

Oracle: dbms_crypto.hash()

PostgreSQL: digest(), 알고리즘은 oracle에서 썼던 숫자값을 적당한 문자열로 바꿔줌 (des, md4, md5, sha1...)


3.2. 단순 암복호화

오라클 dbms_crypto.encrypt(), decrypt() 함수도 PostgreSQL의 bytea 형과 같은 raw 형을 입력 자료형으로 받기 때문에, cast() 함수를 이용해서 적당한 형 변환을 해 주어야 함

Oracle: utl_raw.cast_to_raw('01234567890123456789012345678901') 또는 UTL_I18N.STRING_TO_RAW() 형태의 raw 변환 함수는

PostgreSQL: cast('01234567890123456789012345678901' as bytea)

형태로 바꾸고,

Oracle: DBMS_CRYPTO.DES_CBC_PKCS5 형태로 오는 type 인자값

PostgreSQL: encrypt, decrypt 함수의 알고리즘 인자에 '알고리즘-모드/pad:패딩' 형태로 지정함, 윗 예제라면, 'des-cbc/pad:pkcs' 가 됨


3.3 키가 외부에 있어, utl_file 패키지를 사용한 경우

일반적으로 oracle에서는 utl_file 패키지를 이용해서 directory 객체를 만들고, 그 안에 있는 특정 파일을 읽을 수 있도록 제공하지만,

PostgreSQL에서는 $PGDATA 디렉토리 안에 있는 파일만 읽을 수 있음.

즉, 해당 키 파일은 $PGDATA 디렉토리 안으로 옮겨와야 함

파일 읽는 함수는

Oracle:

utl_file.fopen('directory', 'keyfile', 'rb');

utl_file.get_raw(fh, key_str, 32 );

utl_file.fclose();

PostgreSQL: pg_read_binary_file('keyfile',0,32); (한 줄!)


4. 기존 응용 프로그램 코드 변경을 최소화 하는 법

해당 함수의 입출력 자료형을 최대한 맞추며, (convert_from, encode, decode 함수를 이용)

oracle 패키지 형태로 만들었다면, PostgreSQL에서는 스키마를 만들고, 그 안에 함수로 등록하면,

응용 프로그램 코드 변경을 최소화 할 수 있음

(물론 프로시져로 만들어, exec, call 형태로 호출하는 경우라면, select 구문으로 부득이 변경해야겠지만)


5. 샘플 코드 전체

CREATE SCHEMA mycrypto;
CREATE OR REPLACE FUNCTION mycrypto.encrypt(p_plain character varying)
 RETURNS character varying
 LANGUAGE plpgsql
AS $function$
declare
vkey bytea;
begin
vkey := pg_read_binary_file('keyfile',0,16);
return upper(encode(encrypt_iv(cast(p_plain as bytea), vkey, cast('0123456789012345' as bytea),'aes'),'hex'));
end;
$function$;

CREATE OR REPLACE FUNCTION mycrypto.decrypt(p_encrypt character varying)
 RETURNS character varying
 LANGUAGE plpgsql
AS $function$
declare
vkey bytea;
begin
vkey := pg_read_binary_file('keyfile',0,16);
return convert_from(decrypt_iv(decode(p_encrypt , 'hex'), vkey, cast('0123456789012345' as bytea),'aes'),'utf-8');
end;
$function$;

사용예:

postgres=# select mycrypto.encrypt('무궁화꽃이피었습니다');
                             encrypt                              
------------------------------------------------------------------
 1D6337A6A1EF052D66AB80C04DBD402E5DC78E5F14FCECA963CACB9EE6A2CD5F
(1개 행)
postgres=# select mycrypto.decrypt('1D6337A6A1EF052D66AB80C04DBD402E5DC78E5F14FCECA963CACB9EE6A2CD5F');
       decrypt        
----------------------
 무궁화꽃이피었습니다
(1개 행)

Posted by 김상기



posted by 김상기 ioseph

ᇂ1. 데이터베이스 성능이란

일반적으로 tps 초당 트랜잭션 수로 이야기함

문제는 트랜잭션의 정의가 모호함


2. PostgreSQL & pgbench

pgbench 는 기본적으로 tpc-b type 트랜잭션을 제공함

tpc-b type은 클라이언트 - 서버 환경의 구시대 유물이 되었음


3. 아직도 pgbench 가 중요한 이유

그럼에도 불구하고, 데이터베이스 서버가 운영되고 있는 호스트의 하드웨어 사양과

postgresql.conf 설정을 최적의 상태로 만들어 갈 지표를 찾는데, 이주 편한 도구 임


4. 작업 방법

최대 288 클라이언트까지 테스트할 계획임으로

pgbench -i -s 500 으로  자료를 초기화함

pgbench -T 600 -c 클라이언트수 -j 쓰레드수

형태로 클라이언트수와 쓰레드수를 동일하게 해서

해당 호스트의 core 수의 배수로 600초 (5분) 동안 부하를 주고 그 결과를 수집함


for i in `seq 8 8 288`

do

pgbench -T 600 -c $i -j $i > $i.result

done

grep '.....' *.result


5. gnuplot으로 차트 만들기

set title 'pgbench -T 600'

set grid

set terminal png size 640, 480

set output 'pgbench.png'

set xlabel 'clients' x,y

set ylabel 'tps' x,y

plot 'pgbench.result' with lines title '9.5', 'pgbench.result' using 1:3 with lines title '9.4', 'pgbench.result' using 1:4 with lines title '9.5'



6. 차트 읽기

해당 검사에서 최대 성능을 냈던 구간은 모든 버전에서 56-72 구간임

즉, 8 core 환경에서 코어 당 8배 정도의 클라이언트를 수용할 때 최적의 성능을 냄을 알 수 있음(tpc-b 타입 트랜잭션인 경우)


7. 그 외 빠진 이야기

해당 작업은 반드시 OS 모니터링도 함께 진행되어야 함

CPU, 메모리, 디스크I/O, 네트워크 I/O도 함께 봐야 함


8. 마무리

전체적으로 PostgreSQL 버전별 tps 값은 9.5가 제일 낮았음.

병목 구간에서는 일정하게 각 버전별로 성능 차이가 있음

해당 차트로 짤 수 있는 전략

해당 DB 서버로는 최대 100 이하의 클라이언트가 동시에 사용할 수 있도록 하는 것이 최적임

(검사 장비의 하드웨어 사양은 8core, 16G Mem, 10G iscsi HDD)


posted by 김상기

posted by 김상기 ioseph
2015.01.20 21:50 2. DBMS이야기/03. MongoDB

MongoDB는?

MongoDB의 고성능(high performance), 고 가용성(High Availability) 및

자동 스케일링을 제공하는 오픈 소스 문서 데이터베이스입니다.


Document Database

MongoDB에있는 레코드는 필드(Field) 및 값(Value)의 쌍으로 이루어지는 데이터 구조 문서(Document)입니다.

MongoDB의 문서는 JSON 객체와 유사하며, 필드의 값은 다른 문서들, 배열(Array)들 및

문서들의 배열(Array)을 포함 할 수 있습니다.


문서(Document 방식)를 사용하는 장점은 :

- 문서(RDBMS의 Object)는 다수의 프로그래밍 언어로 기본 데이터 타입에 대응합니다.

- 문서와 배열은 복잡한 조인이 포함될 필요를 줄일 수 있습니다.

- 동적 스키마는 자연스러운 다형성을 지원합니다.

  (다형성 : 작성코드를 수정하지 않고 다양한 자료형의 객체를 처리하도록 하는 기법)


주요 특징

고성능

MongoDB의 고성능 데이터 지속성을 부분적으로 제공합니다.

- 임베디드 데이터 모델에 대해 지원하여, 데이터베이스 시스템에 I/O 작업을 줄일 수 있습니다.

- 인덱스는 빠른 쿼리를 지원하고 내장된 문서와 배열에서 키(Key)를 포함 할 수 있습니다.


고 가용성 

고 가용성을 제공하기 위해, MongoDB의 복제셋(Replica Sets)라는 복제 기능을 제공합니다.

- 자동 페일 오버. (Fail-Over)

- 데이터의 불필요한 중복 방지


복제셋(Replica Set)는 중복 방지를 제공하고 데이터 가용성을 증가시키며,

동일한 데이터 집합을 유지하는 MongoDB의 서버 그룹입니다.


자동 스케일링

MongoDB의는의 한 부분으로 수평 확장성을 제공하는 핵심 기능을 제공합니다.

- 자동 샤딩은 시스템의 클러스터 사이의 데이터를 배포합니다.

- 복제셋은 짧은 대기 시간과 높은 처리량 배포를 위해 최종 일관성(eventually-consistent) 읽기를 제공 할 수 있습니다.



출처 : mongo-db                                                                  (Post by 진준호. 2015.01.20)

'2. DBMS이야기 > 03. MongoDB' 카테고리의 다른 글

1. MongoDB 소개  (0) 2015.01.20
0. NoSQL 이란  (0) 2014.11.23
posted by DB,MW,OS OSSW(Open Source System SoftWare
2014.12.28 22:36 2. DBMS이야기/04. CUBRID

안녕하세요~!

12월의 마지막 주말은 잘 보내셨나요~?


올해의 마지막 세션은 큐브리드 DB 체크에 대해 알아봐요~


1. DB 일관성 확인하기

cubrid checkdb 유틸리티를 사용하면 인덱스와 다른 데이터 구조를 확인하기 위해 데이터와 로그 볼륨의 내부적인 물리적 일치를 확인할 수 있어요. 만일 cubrid checkdb 유틸리티의 실행 결과가 불일치로 나온다면 --repair 옵션으로 자동 수정을 시도해봐야해요


cubrid checkdb [options] database_name [table_name1 table_name2 ...]

table_name1 table_name2 에는 일관성을 확인하거나 복구하려는 테이블 이름을 나열할 수 있어요

-S, --SA-mode

서버 프로세스를 구동하지 않고 데이터베이스에 접근하는 독립 모드(standalone)로 작업하기 위해 지정되며, 인수는 없다. -S 옵션을 지정하지 않으면, 시스템은 클라이언트/서버 모드로 인식한다.

cubrid checkdb -S demodb
-C, --CS-mode

서버 프로세스와 클라이언트 프로세스를 각각 구동하여 데이터베이스에 접근하는 클라이언트/서버 모드로 작업하기 위한 옵션이며, 인수는 없다. -C 옵션을 지정하지 않더라도 시스템은 기본적으로 클라이언트/서버 모드로 인식한다.

cubrid checkdb -C demodb
-r, --repair

데이터베이스의 일관성에 문제가 발견되었을 때 복구를 수행한다.

cubrid checkdb -r demodb

인덱스의 이전 링크(previous link)에 오류가 있는지를 검사한다.

$ cubrid checkdb --check-prev-link demodb

인덱스의 이전 링크(previous link)에 오류가 있으면 복구한다.

$ cubrid checkdb --repair-prev-link demodb
-i, --input-class-file=FILE

-i FILE 옵션을 지정하거나, 데이터베이스 이름 뒤에 테이블의 이름을 나열하여 일관성 확인 또는 복구 대상을 한정할 수 있다. 두 가지 방법을 같이 사용할 수도 있으며, 대상을 지정하지 않으면 전체 데이터베이스를 대상으로 일관성을 확인하거나 복구를 수행한다. 특정 대상이 지정되지 않으면 전체 데이터베이스가 일관성 확인 또는 복구의 대상이 된다.

cubrid checkdb demodb tbl1 tbl2
cubrid checkdb -r demodb tbl1 tbl2
cubrid checkdb -r -i table_list.txt demodb tbl1 tbl2

-i 옵션으로 지정하는 테이블 목록 파일은 공백, 탭, 줄바꿈, 쉼표로 테이블 이름을 구분한다. 다음은 테이블 목록 파일의 예로, t1부터 t10까지를 모두 일관성 확인 또는 복구를 위한 테이블로 인식한다.

t1 t2 t3,t4 t5
t6, t7 t8   t9

     t10


2. DB 내부 정보 확인하기


cubrid diagdb 유틸리티가 제공하는 정보들은 현재 데이터베이스의 상태를 진단하거나 문제를 파악할 수 있어요.

cubrid diagdb [option] database_name
-d, --dump-type=TYPE

데이터베이스의 전체 파일에 대한 기록 상태를 출력할 때 출력 범위를 지정한다. 생략하면 기본값인 -1이 지정된다.

cubrid diagdb -d 1 demodb

-d 옵션에 적용되는 타입은 모두 9가지로, 그 종류는 다음과 같다.

타입설명
-1전체 데이터베이스 정보를 출력한다.
1파일 테이블 정보를 출력한다.
2파일 용량 정보를 출력한다.
3힙 용량 정보를 출력한다.
4인덱스 용량 정보를 출력한다.
5클래스 이름 정보를 출력한다.
6디스크 비트맵 정보를 출력한다.
7카탈로그 정보를 출력한다.
8로그 정보를 출력한다.
9힙(heap) 정보를 출력한다.


3. 서버/클라이언트에서 사용하는 파라미터 출력하기

cubrid paramdump [options] database_name
-o, --output-file=FILE

데이터베이스의 서버/클라이언트 프로세스에서 사용하는 파라미터 정보를 지정된 파일에 저장하는 옵션이며, 파일은 현재 디렉터리에 생성된다. -o 옵션이 지정되지 않으면 메시지는 콘솔 화면에 출력한다.

cubrid paramdump -o db_output demodb
-b, --both

데이터베이스의 서버/클라이언트 프로세스에서 사용하는 파라미터 정보를 콘솔 화면에 출력하는 옵션이며, -b 옵션을 사용하지 않으면 서버 프로세스의 파라미터 정보만 출력한다.

cubrid paramdump -b demodb
-S, --SA-mode

독립 모드에서 서버 프로세스의 파라미터 정보를 출력한다.

cubrid paramdump -S demodb
-C, --CS-mode

클라이언트-서버 모드에서 서버 프로세스의 파라미터 정보를 출력한다.

cubrid paramdump -C demodb


2015년 청양의 해 새해 많이 받으세요~!


출처 : 큐브리드 메뉴얼                                                                    (By. 진준호 2014.12.28)


'2. DBMS이야기 > 04. CUBRID' 카테고리의 다른 글

08. CUBRID DB 체크하기  (0) 2014.12.28
07. CUBRID 복구하기  (0) 2014.12.10
06. CUBRID 사용자, Database 파일, 백업  (0) 2014.11.11
05. CUBRID 기동과 정지  (0) 2014.10.20
04. CUBRID 시스템 카탈로그 & SQL  (0) 2014.10.05
04. CUBRID의 카탈로그와 테이블  (0) 2014.09.26
posted by DB,MW,OS OSSW(Open Source System SoftWare
2014.12.10 23:17 2. DBMS이야기/04. CUBRID

안녕하세요~

벌써 2014년 마지막 달이네요, 추운 날씨에 감기 안 걸리셨죠?

이번 화에는 복구에 대해 알아보겠습니다


CUBRID 환경에서 수행된 백업 작업에 의해 생성된 백업 파일, 활성 로그 및 보관 로그를 이용하여 특정 시점의 데이터베이스로 복구하는 작업으로, 진행하려면 cubrid restoredb 유틸리티 또는 CUBRID 매니저를 사용합니다.


 cubrid  restoredb  [options]  database_name


어떠한 옵션도 지정되지 않은 경우 기본적으로 마지막 커밋 시점까지 데이터베이스가 복구됩니다.

만약, 마지막 커밋 시점까지 복구하기 위해 필요한 활성 로그/보관 로그 파일이 없다면 마지막 백업 시점까지만 부분 복구됩니다.


옵션

입력값

설명 

기본값 

 -l

복구레벨 

복구 레벨 지정 (0,1,2)

 -d

복구시점 

복구 시점 지정 형식) 일-월-년:시:분:초

예) 10-12-2014:17:00:00

또는 backuptime : 마지막 백업 시점

가장 최근 시점 

 -B

파일경로 

복구할 백업 볼륨이 존재하는 디렉토리나 장치명 지정 

초기 로그 볼륨 위치 

 -p

 

archive 로그가 없을 경우 무시하고 수행 

 

 -u

 

데이터베이스 위치 파일내에 지정된 경로로 데이터

베이스와 로그 볼륨을 복구 (dataase.txt) 

 

 -list

 

백업을 수행하지 않고 백업 볼륨 목록을 출력 

 


-p 옵션이 지정되지 않은 경우, 사용자에게 옵션을 선택하라는 요청 메시지는 다음과 같이 나옵니다.

***********************************************************
Log Archive /home/cubrid/test/log/demodb_lgar002
 is needed to continue normal execution.
   Type
   -  0 to quit.
   -  1 to continue without present archive. (Partial recovery)
   -  2 to continue after the archive is mounted/loaded.
   -  3 to continue after changing location/name of archive.
***********************************************************
  • 옵션 0: 복구 작업을 더 이상 진행하지 않을 경우, 0을 입력한다.
  • 옵션 1: 로그 파일 없이 부분 복구를 진행하려면, 1을 입력한다.
  • 옵션 2: 복구 작업을 진행하기 위해 관리자는 현재 장치에 보관 로그를 위치시킨 후 2를 입력한다.
  • 옵션 3: 복구 작업을 계속하기 위해 관리자는 로그 위치를 변경한 후 3을 입력한다.


다음은 -list 옵션을 이용해서 볼륨 목록을 출력했을 경우입니다.

*** BACKUP HEADER INFORMATION ***
Database Name: /local1/testing/demodb
 DB Creation Time: Mon Oct 1 17:27:40 2008
         Pagesize: 4096
Backup Level: 1 (INCREMENTAL LEVEL 1)
        Start_lsa: 513|3688
         Last_lsa: 513|3688
Backup Time: Mon Oct 1 17:32:50 2008
 Backup Unit Num: 0
Release: 8.1.0
     Disk Version: 8
Backup Pagesize: 4096
Zip Method: 0 (NONE)
        Zip Level: 0 (NONE)
Previous Backup level: 0 Time: Mon Oct 1 17:31:40 2008
(start_lsa was -1|-1)
Database Volume name: /local1/testing/demodb_vinf
     Volume Identifier: -5, Size: 308 bytes (1 pages)
Database Volume name: /local1/testing/demodb
     Volume Identifier: 0, Size: 2048000 bytes (500 pages)
Database Volume name: /local1/testing/demodb_lginf
     Volume Identifier: -4, Size: 165 bytes (1 pages)
Database Volume name: /local1/testing/demodb_bkvinf
     Volume Identifier: -3, Size: 132 bytes (1 pages)

-list 옵션을 이용하여 출력된 백업 정보를 확인하면, 백업 파일이 백업 수준 1로 생성되었고, 이전 백업 수준 0의 전체 백업이 수행된 시점을 확인할 수 있다. 따라서, 예시된 데이터베이스의 복구를 위해서는 백업 수준 0인 백업 파일과 백업 수준 1인 백업 파일이 준비되어야 합니다.



복구할 때에는 고려해야 할 사항들이 있습니다.

  • 백업 파일 준비
    • 백업 파일 및 로그 파일이 저장된 디렉터리를 확인해야 합니다.
    • 증분 백업으로 대상 데이터베이스가 백업된 경우, 각 백업 수준에 따른 백업 파일이 존재하는지를 확인합니다.
    • 백업이 수행된 CUBRID 데이터베이스의 버전과 복구가 이루어질 CUBRID 데이터베이스 버전이 동일한지를 확인한다.
  • 복구 방식 결정
    • 부분 복구할지, 전체 복구할지 결정합니다.
    • 증분 백업 파일을 이용한 복구인지를 확인합니다.
    • 사용 가능한 복구 도구 및 복구 장비를 준비합니다.
  • 복구 시점 판단
    • 데이터베이스 서버가 종료된 시점을 확인합니다.
    • 장애 발생 전에 이루어진 마지막 백업 시점을 확인합니다.
    • 장애 발생 전에 이루어진 마지막 커밋 시점을 확인합니다.

모두 준비되셨으면, 복구 시~작~!

따듯한 하루 되세요~^^


출처 : 큐브리드 메뉴얼                                              By. 진준호 (2014.12.10)

'2. DBMS이야기 > 04. CUBRID' 카테고리의 다른 글

08. CUBRID DB 체크하기  (0) 2014.12.28
07. CUBRID 복구하기  (0) 2014.12.10
06. CUBRID 사용자, Database 파일, 백업  (0) 2014.11.11
05. CUBRID 기동과 정지  (0) 2014.10.20
04. CUBRID 시스템 카탈로그 & SQL  (0) 2014.10.05
04. CUBRID의 카탈로그와 테이블  (0) 2014.09.26
posted by DB,MW,OS OSSW(Open Source System SoftWare

Postgresql의 처리순서도에 대해 알아보도록 하겠습니다.

 

 

 

 

SQL을 입력하고 나면, Parser 라는 곳에서 postgresql에 맞는 언어와 문법인지 확인

(참조하는 테이블의 권한 여부 및 오타, 문법 등을 확인)

문법 확인 후, 특별한 문제가 없으면 SQL을 어떻게 실행지 계획을 세우게 됨

계획 세우는 곳이 Planner 이다.

(사전에 정리된 통계정보를 가지고 어떻게 실행하는 것이 최고의 실행인지를 계획하는 곳)

일반 개발자들이 무시하는 곳이기도 하지만, 일반 개발자는 Parser만 되면 OK 라고 한다.

계획을 세우고 나면, 데이터 저장소로 부터 데이터를 가지고 옴

물론 메모리에 있는 경우에는 메모리로 부터 가지고 오게 된다.

메모리의 예를 들어보면 똑같은 SQL을 처음 시작할 때와 2번째 실행할 때의 처리시간이 다른 것을 알 수가 있다. (2번째 SQL을 수행하면 메모리에 이미 적재된 데이터를 가지고 오기 때문에 처음 수행할 때보다 빠른 것이다.)

Executor을 하고 나면 그 이후에 결과 값을 화면에 뿌려주게 된다.

 

SQL 처리 순서도는 DB가 성능이 떨어졌을 때 어디를 봐야 하는가를 알아보기 위함이기 때문에 중요하다.

 

posted by. 신기철 (11.27)

posted by DB,MW,OS OSSW(Open Source System SoftWare
2014.11.28 11:19 2. DBMS이야기/02. MySQL


MySQL 5.6 파티션 삭제시 Exchange Partition 기능 활용 방안




로그성 데이터를 파티션 테이블로 보관하는 경우가 많은데, 보관주기가 지난 파티션을 drop 하는 경우에 MySQL 에서는 전체 파티션에 테이블 락이 걸리는 문제가 있다. 

물론 파티션의 물리적인 파일과 내부 메타 데이터 갱신 정도만 발생하기에 테이블 락 유지 시간이 길지는 않지만, 서비스 성격에 따라 문제가 되는 경우도 있다.

 

MySQL 5.6 버전부터는 파티션 Exchange 기능이 지원되는데, 이 기능을 사용하면 테이블 락으로 인한 영향을 최소화하면서 파티션 삭제를 할 수 있다.

테스트를 위해 하루에 3200만건(테이블스페이스 파일 사이즈 10GB) 정도 데이터가 저장되는 생성되는 일자별 파티션 테이블을 생성해 보았다.


mysql> show create table ptest\G

*************************** 1. row ***************************

       Table: ptest

Create Table: CREATE TABLE `ptest` (

  `id` int(11) NOT NULL AUTO_INCREMENT,

  `regdt` date NOT NULL DEFAULT '0000-00-00',

  `pad` char(255) DEFAULT NULL,

  PRIMARY KEY (`id`,`regdt`)

) ENGINE=InnoDB AUTO_INCREMENT=167108865 DEFAULT CHARSET=utf8

/*!50100 PARTITION BY RANGE ( to_days (regdt) )

(PARTITION p20140420 VALUES LESS THAN (735709) ENGINE = InnoDB,

 PARTITION p20140421 VALUES LESS THAN (735710) ENGINE = InnoDB,

 PARTITION p20140422 VALUES LESS THAN (735711) ENGINE = InnoDB,

 PARTITION p20140423 VALUES LESS THAN (735712) ENGINE = InnoDB,

 PARTITION pMAXVALUE VALUES LESS THAN MAXVALUE ENGINE = InnoDB) */

1 row in set (0.00 sec)

 

mysql> select TABLE_NAME, PARTITION_NAME, TABLE_ROWS from information_schema.PARTITIONS where TABLE_NAME='ptest';      

+------------+----------------+------------+

| TABLE_NAME | PARTITION_NAME | TABLE_ROWS |

+------------+----------------+------------+

| ptest      | p20140420      |   32934515 |

| ptest      | p20140421      |   32939678 |

| ptest      | p20140422      |   32935000 |

| ptest      | p20140423      |   32935471 |

| ptest      | pMAXVALUE      |          0 |

+------------+----------------+------------+

5 rows in set (0.01 sec)

 



MySQL 데이터 디렉토리에서 파일을 조회해 보면  파티션별로 10GB 정도의 테이블 스페이스가 생성된 것을 확인할  있다.

-rw-rw---- 1 seuis398 seuis398 9.9G 2014-04-25 22:03 ptest#P#p20140420.ibd

-rw-rw---- 1 seuis398 seuis398 9.9G 2014-04-25 22:08 ptest#P#p20140421.ibd

-rw-rw---- 1 seuis398 seuis398 9.9G 2014-04-25 22:34 ptest#P#p20140422.ibd

-rw-rw---- 1 seuis398 seuis398 9.9G 2014-04-25 22:39 ptest#P#p20140423.ibd

-rw-rw---- 1 seuis398 seuis398  96K 2014-04-25 22:39 ptest#P#pMAXVALUE.ibd

 



이 상태에서, 파티션 DROP 방식으로 2014-04-20일의 파티션을 삭제했을 때, 해당 파티션의 테이블 스페이스(10GB) 삭제 작업과 테이블의 메타 정보 갱신에 대략 0.6초 정도 소요되는 것을 확인할 수 있었다. 

10GB 정도의 파일을 삭제하는 작업은 ext4 파일 시스템에서는 크게 문제가 되지 않는 작업이라 다행이 0.6초만에 처리가 되긴 했지만, 만약 ext3 파일 시스템을 사용하고 있었거나 월별 파티셔닝 등으로 파티션의 사이즈가 더 컸다면 파티션 삭제에 소요되는 시간은 더 늘어나게 되고, 이때는 락으로 인한 문제가 발생하게 된다.

mysql> alter table ptest drop partition p20140420;

Query OK, 0 rows affected (0.59 sec)

Records: 0  Duplicates: 0  Warnings: 0 

 



MySQL 5.6 버전에서는 파티션 Exchange 기능을 사용해서 락으로 인한 영향을 최소화하는 것이 가능하다.

// 테스트 테이블의 파티션 1개와 동일한 구조의 테이블을 생성

mysql> create table empty_ptest like ptest; 

Query OK, 0 rows affected (0.07 sec) 

 

mysql> alter table empty_ptest remove partitioning;   

Query OK, 0 rows affected (0.17 sec)

Records: 0  Duplicates: 0  Warnings: 0

 

// 위에서 생성한 빈 테이블과 삭제한 파티션(20140421)을 Exchange

// 잠시 테이블 락이 걸리겠지만 물리적인 파일 삭제가 발생하지 않으므로 파티션 사이즈에 관계없이 소요시간이 매우 짧다. 

mysql> alter table ptest exchange partition p20140421 with table empty_ptest;   

Query OK, 0 rows affected (0.04 sec)

 

mysql>  select TABLE_NAME, PARTITION_NAME, TABLE_ROWS from information_schema.PARTITIONS where TABLE_NAME='ptest';

+------------+----------------+------------+

| TABLE_NAME | PARTITION_NAME | TABLE_ROWS |

+------------+----------------+------------+

| ptest      | p20140421      |          0 |

| ptest      | p20140422      |   32209112 |

| ptest      | p20140423      |   32184620 |

| ptest      | pMAXVALUE      |          0 |

+------------+----------------+------------+

4 rows in set (0.00 sec)

 

// 불필요한 데이터 일괄 삭제

// 파티션은 이미 빈 껍데기만 남은 상태이므로 삭제 작업이 매우 빠르다.

mysql> alter table ptest drop partition p20140421;

Query OK, 0 rows affected (0.00 sec)

Records: 0  Duplicates: 0  Warnings: 0

 

mysql> drop table empty_ptest;

Query OK, 0 rows affected (0.58 sec) 

 



Posted By 김득은






자료출처   :   http://seuis398.blog.me/70039224614    


posted by DB,MW,OS OSSW(Open Source System SoftWare
2014.11.28 11:00 2. DBMS이야기/02. MySQL

MySQL 5.6 Parallel Replication (slave_parallel_workers)



MySQL Replication 구조는 Master에서 아무리 많은 쿼리를 처리하더라도 Slave가 Master의 처리량을 따라갈 수 없는 근본적인 문제를 가지고 있다.

이는 Master에서는 다량의 세션에서 동시에 쿼리를 수행하지만 Slave는 항상 Single Thread로 복제를 처리하기 때문인데, MySQL 5.6 버전에서는 이런 부분들을 조금 완화할 수 있는 parallel slave 기능이 도입되었다.

 

MySQL 5.6의 parallel slave는 database 단위로 별도의 worker thread가 생성되고, 기존 복제 처리를 하던 SQL Thread가 작업 관리 역할을 하면서 각 worker thread에게 작업을 할당해 주는 방식으로 처리된다.







mysql> set global slave_parallel_workers=4;


mysql> stop slave ; start slave;

...

mysql> show processlist;

+----+-------------+------+------+---------+------+-----------------------------------------------------------------------------+------------------+

| Id | User        | Host | db   | Command | Time | State                                                                       | Info             |

+----+-------------+------+------+---------+------+-----------------------------------------------------------------------------+------------------+

| 31 | system user |      | NULL | Connect | 6500 | Waiting for master to send event                                            | NULL             |

| 32 | system user |      | NULL | Connect | 5548 | Slave has read all relay log; waiting for the slave I/O thread to update it | NULL             |

| 33 | system user |      | NULL | Connect | 5592 | Waiting for an event from Coordinator                                       | NULL             |

| 34 | system user |      | NULL | Connect | 5592 | Waiting for an event from Coordinator                                       | NULL             |

| 35 | system user |      | NULL | Connect | 5594 | Waiting for an event from Coordinator                                       | NULL             |

| 36 | system user |      | NULL | Connect | 5587 | Waiting for an event from Coordinator                                       | NULL             |

+----+-------------+------+------+---------+------+-----------------------------------------------------------------------------+------------------+

 

mysql> show processlist;

+----+-------------+------+---------+---------+------+--------------------------------------------------+------------------------------------------------------------------------------------------------------+

| Id | User        | Host | db      | Command | Time | State                                            | Info                                                                                                 |

+----+-------------+------+---------+---------+------+--------------------------------------------------+------------------------------------------------------------------------------------------------------+

| 31 | system user |      | NULL    | Connect |  831 | Waiting for master to send event                 | NULL                                                                                                 |

| 32 | system user |      | NULL    | Connect |    0 | Waiting for Slave Workers to free pending events | NULL                                                                                                 |

| 33 | system user |      | sbtest1 | Connect |   31 | update                                           | INSERT INTO sbtest10(k, c, pad) VALUES (0,' ','qqqqqqqqqqwwwwwwwwwweeeeeeeeeerrrrrrrrrrtttttttttt'), |

| 34 | system user |      | sbtest4 | Connect |   30 | update                                           | INSERT INTO sbtest4(k, c, pad) VALUES (0,' ','qqqqqqqqqqwwwwwwwwwweeeeeeeeeerrrrrrrrrrtttttttttt'),( |

| 35 | system user |      | sbtest3 | Connect |   32 | update                                           | INSERT INTO sbtest4(k, c, pad) VALUES (0,' ','qqqqqqqqqqwwwwwwwwwweeeeeeeeeerrrrrrrrrrtttttttttt'),( |

| 36 | system user |      | sbtest2 | Connect |   32 | update                                           | INSERT INTO sbtest4(k, c, pad) VALUES (0,' ','qqqqqqqqqqwwwwwwwwwweeeeeeeeeerrrrrrrrrrtttttttttt'),( |

+----+-------------+------+---------+---------+------+--------------------------------------------------+------------------------------------------------------------------------------------------------------+ 





실제 어느 정도의 효과가 있는지 아래와 같은 시나리오로 테스트를 해보았다.

▶ sysbench로 테스트 database를 8개 생성 (sbtest1~8)

 sysbench oltp 테스트 부하를 sbtest1~8에 동시에 인입 =>  Master db 기준으로 초당 40,000~45,000 정도의 쿼리가 처리됨

▶ Slave db에서 slave_parallel_workers 파라미터를  0(기존방식), 2, 4, 8로 증가하면서 복제 처리량 측정 

 

테스트 결과 병렬 처리를 하지 않았을 때에 비해서 database 개수만큼 병렬 처리를 했을 때 거의 6배 정도의 복제 처리량이 증가하는 것을 확인할 수 있었다.

물론 부하모델에 따라서 수치는 차이가 나겠고, Master에 비해서는 여전히 느리게 복제가 반영되겠지만, 충분히 메리트 있는 기능으로 보인다.









다만 5.6 버전 기준으로 이 기능을 사용하기 위해서는 몇가지 유의해야 될 부분들이 있다.

(1) 당연한 얘기겠지만 database 단위로 worker thread가 생성되기 때문에, database가 1개인 경우에는 이득이 없다.

(2) worker thread는 트랜잭션을 고려하지 않고 반영을 하기 때문에 각 database가 독립적인 구조가 아니라 트랜잭션으로 묶여서 사용되는 환경에서는 Master-Slave 간 데이터 정합성을 보장할 수 없다.

(3) database 단위로 복제를 처리하지만, 한쪽 database에서 지연이 발생하면 전체 database에도 복제 지연이 발생하게 된다.  

     즉, 병렬 처리의 효과를 극대화하기 위해서는 각 database에 인입되는 부하가 균일해야 하며, 짧은 쿼리들 위주이어야 한다.

     (SQL Thread가 특정 worker thread에게 작업 할당을 해야 되는데, 해당 thread가 이전 작업을 완료하지 못했으면 SQL Thread는 대기)

(4) 5.6.16 버전까지는 특정 상황에서 parallel slave 기능을 사용했을 때 memory leak이 발생할 수 있다. (5.6.17에서 패치됨)

     http://bugs.mysql.com/bug.php?id=71197





※ 특정 database에 lock을 걸어서 의도적으로 복제 적용하지 못하도록 처리했을 때의 나머지 worker thread가 대기하는 상태


mysql> lock table sbtest1.sbtest write;


Query OK, 0 rows affected (0.00 sec)

 

mysql> show processlist;

+----+-------------+-----------------+---------+---------+------+--------------------------------------------------+------------------------------------------------------------------------------------------------------+

| Id | User        | Host            | db      | Command | Time | State                                            | Info                                                                                                 |

+----+-------------+-----------------+---------+---------+------+--------------------------------------------------+------------------------------------------------------------------------------------------------------+

| 31 | system user |                 | NULL    | Connect |  853 | Waiting for master to send event                 | NULL                                                                                                 |

| 32 | system user |                 | NULL    | Connect |    0 | Waiting for Slave Workers to free pending events | NULL                                                                                                 |

| 33 | system user |                 | sbtest1 | Connect |   37 | Waiting for table metadata lock                  | INSERT INTO sbtest(k, c, pad) VALUES (0,' ','qqqqqqqqqqwwwwwwwwwweeeeeeeeeerrrrrrrrrrtttttttttt'),(0 |

| 34 | system user |                 | NULL    | Connect |   32 | Waiting for an event from Coordinator            | NULL                                                                                                 |

| 35 | system user |                 | NULL    | Connect |   32 | Waiting for an event from Coordinator            | NULL                                                                                                 |

| 36 | system user |                 | NULL    | Connect |   32 | Waiting for an event from Coordinator            | NULL                                                                                                 |

+----+-------------+-----------------+---------+---------+------+--------------------------------------------------+------------------------------------

 




Posted By 김득은






자료 출처  :  http://seuis398.blog.me/70039224614



posted by DB,MW,OS OSSW(Open Source System SoftWare
2014.11.27 22:30 2. DBMS이야기/02. MySQL

 

 

 

MySQL filesort 알고리즘

 

 

ORDER BY/GROUP BY 처리에 인덱스를 사용하지 못하는 경우, MySQL은 Filesort 알고리즘을 통해 데이터를 정렬한다.
Filesort 알고리즘을 사용하게 되면 쿼리 실행플랜 Extra 필드에 Using filesort 구문이 나오게 되며, 이런 경우 대체로 쿼리 처리 비용이 증가하게 된다.

Filesort 동작 방식과 Filesort와 관련된 Variable, Status 항목을 정리해 보면 아래와 같다.

 

 

 

 

 

(1) 데이터 Block에 대한 Scan 및 WHERE Filter 처리후 조건에 맞는 row를 Sort Buffer에 저장
     정렬 조건 컬럼 값과 데이터 포지션 정보를 Buffer에 저장하며, Clustered Index 구조를 사용하는 InnoDB의 경우 PK값이 Buffer에 함께 저장됨

     (sort_buffer_size 환경 변수로 지정)

(2) Sort Buffer가 가득차면, Quick Sort 처리하여 결과를 별도의 임시 파일에 저장하며, 위 과정을 조건에 부합하는 모든 row를 다 읽을때까지 반복
      (임시 파일은 실제 물리적인 파일이 아님)

(3) 생성된 임시 파일들을 Merge
      Merge 횟수는 sort_merge_pass 상태 변수에 카운트 돠며, sort_buffer_size가 작은 경우, sort_merge_pass 상태 변수 값이 커짐

(4) Merge 완료된 결과는, 정렬 조건 순서대로 데이터 포지션 정보를 가지고 있음
      결과 파일 순서대로 데이터 Block을 읽는 경우 많은 Random I/O를 유발되므로, 
      별도의 버퍼(read_rnd_buffer 환경 변수)에서 결과 파일의 위치 정보를 정렬하여 Random I/O를 Sequential I/O로 유도

이 Filesort 알고리즘은 데이터 Block에 대한 Access가 중복으로 발생한다는 단점이 있다.
이 문제를 해결하기 위해 MySQL 4.1 이후부터는 개선된 Filesort 알고리즘을 추가로 사용한다.
Sort Buffer에서 정렬 수행시 데이터 포지션 뿐만 아니라, SELECT 쿼리가 요청한 컬럼의 내용도 같이 처리를 하는 것이다.
Sort Merge가 완료되면 추가적인 데이터 Access 없이 Result Set을 생성할 수 있다.

일반적인 경우에는 개선된 Filesort 알고리즘이 더 빠르지만,
추가 처리되는 컬럼의 크기가 길면, Sort Buffer의 활용도가 떨어지고 Sort Merge의 부담이 발생하여 오히려 기존 Filesort 알고리즘에 비해 더 느려지게 된다.
그래서 아래 조건을 만족하는 경우에만 개선된 Filesort 알고리즘이 사용되고, 그렇지 않으면 원래 Filesort 알고리즘이 그대로 사용된다.
  - SELECT 쿼리가 요청한 컬럼이 TEXT / BLOB이 아닐 것
  - SELECT 쿼리가 요청한 컬럼의 사이즈 합이 max_length_for_sort_data 환경 변수 값 이하 (기본값 1KB)

[결론]
가급적 Filesort를 피하는 것이 좋으나, 불가피하게 Filesort를 해야 하는 경우 불필요하게 SELECT 하는 컬럼을 줄이거나 불필요한 BLOB/TEXT 사용을 자제하면 성능 향상을 얻을 수 있다.

[유의사항]
sort_buffer_size가 불필요하게 큰 경우에는 오히려 성능 저하 발생 (default 값을 사용해도 무방)

 

 

 

Posted by  김득은

 

자료 출처 : http://seuis398.blog.me/70039224614

 

 

 

posted by DB,MW,OS OSSW(Open Source System SoftWare

훨씬 간편해진 Postgres 백업과 복구 (Postgres Backup and Recovery Just Got a Whole Lot Easier)

2014 10 20Jason Davis (October 20th, 2014 by Jason Davis)

Postgres  최근  년간 새로운 툴을 발전시켜왔다다행스럽게도만약  글을 읽는 당신이 Postgres  업무를 하고 있는 DBA 시스템 관리자라면 당신의 업무환경은 훨씬 간편해질 것이다. EnterpriseDB (EDB)  최근  주간 일본의 K.K Ashisuto  같은 고객들과 파트너사와 작업하며 우리의 새로운 EDB 백업과 복구  (BART)  대해 많은 비용을 써왔고우리가 이번 주에 백업복구 툴의 첫번째 버전을 출시하게  점을 기쁘게 생각한다, EDB BART  엄청나게 간편해져  동안 시간을 잡아먹는 절차들을 개선시켰다. EDB BART  PostgreSQL  EDB’s Postgres Plus Advanced Server  커뮤니티 모두에게 지원을 하고 있다.

EDB BART  시스템 전반적인 카탈로그와 명령어 인터페이스를 제공하여 백업과 복구를  관리할  있도록 도와준다. pg_basebackup  통한 온라인 물리적인 백업은 다운타임을 줄여주며,복구를 하는 동안 다른 경로에 있는 테이블스페이스를 지원하고자동복구는 디스크 스토리지 사용을 줄여주며 파일들이 유효하도록 보증한다.


 이상의 인크리멘탈 백업은 없다 (No More Incremental Backup)

트랜잭션 로그 아카이빙의 결합(wal_level=archive)으로, DBA들은 가장 최근의 베이스 백업 시점으로부터 “ 포워드”  가능하게 된다사용자들은 인크리멘탈 백업에 대해 궁금할   있다.사이즈에서  GB보다 작은 데이터베이스를 위해, Postgres point-in-time-recovery (PITR)  가능하게 하였다.

EDB 데이터베이스 개발자이자 PostgreSQL  기여자인 Kevin Grittner 씨는 중요성에 대해 설명할 기회를 가졌다그가 “만약 당신이 WAL 아카이빙하고 archive_timeout = 1h  설정하고 있다면당신은 시간단위로 인크리멘탈 백업을  수도 있고 다른 방법도 있으며 모든 복구 옵션을 가지고 있는 것이다기본적으로대부분의 사람들이 BART라는 툴을 통해  복구 포인트마다 트랜잭션 단위를 저장해야  공간을 절약해주는 셈이다.


 멀리 내다보자 (Looking Ahead)

일본의 파트너사 중에 하나인 K.K. Ashisuto   “EDB BART  매우 복잡한 프로세스를 간편화했고마켓에서 차별화된 점들을 발전시켜왔습니다 툴은 local 데이터베이스와 거의 동일한 속도로 remote 환경에서도 백업이 쉽게 됩니다.” 라고 언급하였다.

2,500 명이 넘는 고객들을 통해 EDB Postgres 이용자들에게  포지셔닝 되어있고그들의 요구에 대해 깊은 통찰력을 가질  있게 되었다이런 상호작용은 우리 제품의 로드맵에 영향을 미치게 되고 정기적으로 사용자의 요구에 이득을 가져올  있는 새로 나올 버전에 대해  혁신을 불러올  있게 된다.


EDB 툴에 대한  많은 정보를 원하신다면visit our site (우리 사이트를 방문하시거나contact us (직접 연락 부탁 드립니다) - EnterpriseDB  제품관리 선임, Jason Davis


출처 : http://blogs.enterprisedb.com/2014/10/20/postgres-backup-and-recovery-just-got-a-whole-lot-easier/


Post by. 김지선(2014.11.26)

posted by DB,MW,OS OSSW(Open Source System SoftWare