System Compleat.

postgresql 이야기.

Techs
postgresql -  http://www.postgresql.org

오픈소스 진영의 막강한 RDBMS.

항상 막강한 말이 붙는 소프트 웨어를 웹질을 하면서 많이 만나게 된다.
회사를 옮기고 생소하게 접했던 pgsql.

약 일년여간 다루어 오면서 느낀건 정말 손 많이 가는 데이터베이스라는거다.
회사 사용목적의 특성상 스키마를 잘근잘근 쪼개서 보통 900여개, 많으면 1800여개 까지 만들어대는데
한개의 DB에 특정 tablespace 지정없이 이런식으로 개념없이 계속 스키마를 생성하다 보면
디렉토리 하나에 파일이 70만개.

일단 파일시스템 성능에도 문제가 있고..  data 디렉토리를 왕창 압축해서 한 파일에 몰아 넣는건 별 문제가
되진 않지만 이걸 다시 풀어 버리는데는.... 끔찍했다.

실례로 16시간동안 압축이 해제 되는걸 보고만 있어야 했다는.  주말이었다.

실제 서비스 하는 서버의 사정상 각 스키마별로 tablespace를 재지정 한다는건 개발팀이나 시스템에서도
난색을 표하는( 한차례 schema별 덤프를 받아야 했는데 이건 이틀짜리다 ) 일이어서 결국
파일 시스템 레벨에서 해결을 하기로 했다.

답은...

tune2fs /dev/sdxN -O dir_index

일단 data디렉토리를 백업, archive를 압축 해 두고 나서 파일 제대로 있는지 꼭 확인 한 후에
위의 옵션을 ext3 에 추가 해 주고
시스템을 리붓 하던가 아니면 언마운트 하고 fsck 를 돌려버린다.

아, 물론 새로운 디스크에 해당 옵션을 걸고 미러링을 하는것이 더 안정성 높은 좋은 방법이다.

물론 한 디렉토리 안에 무지막지한 파일 갯수의 문제는 남아있게 되지만...
뭐, 어쩌겠는가  디비 구조 변경 당장 못하겠다는데..

사용중 하나의 스키마에만 문제가 발생해도 복구할때는 전체 압축파일을 다 풀어버려야 한다.
이건 정말 고역이어서..  WAL 백업 프로세스에 들어가게 되면.. dir_index 가 걸려있지 않은 상황에서는
해당 wal 백업과 online 백업 전체를 옮겨서 준비가 된 서버에서 작업을 해주어야 하는..
dir_index 도 좋지만 보다 좋은 성능을 내는건... 훗훗
보시라.

일단 메모리가 32기가 정도 되는 서버를 준비해서
data 디렉토리 사이즈만큼 크기를 할당하고 ( dd if=/dev/zero of=/dev/ram0 bs=1k count=니맘대로 )
파일 시스템을 생성 ( mkreiserfs -f /dev/ram0 ) 하고
loopback으로 마운트 한 다음에 ( mount -t reiserfs -o loop  /dev/ram0  니맘대로 )
여기다가 online 백업을 풀어버리는거다.

12기가의 파일 50만개 정도를 8분에 풀어버렸다. ( 듀얼코어 옵테론 270 X 4 , sata 디스크 )
여기서 덤프는 그다지 빠르진 않지만, 기타 다른 seq scan 이나 sort 등  tmp table 생성이 요구되는
여러가지 작업에서 db 성능은 매우 비약적으로 향상된다.

하지만 돈 많이 든다는거...


또 하나의 문제가 있는데.

어디, 스키마를 만들어 내기만 하는게 아니다.
지우기도 하지 않는가?

여기서 MVCC 의 문제가 발생해 버린다.

postgresql 의 pg_catalog 하위 테이블중 pg_class 및 관련 attribute 등의 해당 db system catalog 들에
문제가 발생한다.  일례로 pg_class 테이블 및 인덱스 파일 사이즈가 1기가가 넘어버리는 사태가 발생하기도
했지만... 
역시 디비 구조 변경은 당분간 불가 합니다 라는 말이므로 어쩌겠는가...
data 디렉토리 크기는 날이 갈 수록 커지지.. 스키마 추가, 삭제의 반복.. 그리고 각 스키마 별로 들어있는
엉망 구조의 게시판 테이블 구조...

vacuumdb -az, reindex -S  등을 열심히 돌려주었다.  가끔 대규모 drop 이나 대규모 insert 가 발생한 경우엔
vacuumdb -azf .

백업에 대해 문제가 발생할 소지도 있어서 참 난감 했다.
vacuum 전 백업, vacuum -avz 로 로그를 뽑아 내어 행여나 잘못된 테이블이나 인덱스때문에 vacuum 이 죽어버
리게 되면..

아무튼... 이런 저런 문제 끝에 지금은 여러가지 절차적, 구조적 수정을 감행하여 실제 서비스에 큰 무리 없도록
하고 있긴 하지만...  언제 터질지 모르는 폭탄같아 좀 무섭긴 하다.