사고 - 이것에 대한 정의가 필요합니다.

물리적인 충격에 의한 하드디스크가 손상 되는 것을 의미하지는 않습니다.

이런 사고라면,

어떠한 RDBMS도 그것을 복구하는 방법은 존재하지 않을테니까요.

여기서 사고라함은,

갑작스런 정전, OS의 프로세스 생성 루틴의 말썽으로 프로세스 무한 생성되고 있어 부득이 모든 프로세스를 죽여야할 경우,

아니면, 특정 버그 프로그램에 의해 cpu 오버클럭(?) 현상으로 cpu 가동이 중지 되었을 경우.

이런 경우들을 예로 합니다.

이때, 사용하고 있는 PostgreSQL 서버로 보내지는 모든 sql 문이 트랜잭션을 사용하지 않는 sql 구문이라면, "어떠한 경우라도 데이터 손상은 일어나지 않습니다" 물론 이때, update, insert, delete 같은 데이터조작 명령이 실행중에 있었다면, 이것은 실행되지 않은 상태로 복구가 되겠지요.

이 복구는 서버차원에서 자동으로 이루워집니다.

문제는 트랜잭션인데,

이것에 대한 처리는 7.1 버전부터 Write-ahead log (WAL)라는 기술을 구현해서 처리해 보려고 노력중입니다.

Postgresql hacker 메일링을 참고하면(제가 읽은 데까지만, 요즘은 어떤지는 모르겠습니다) 7.1.2 버전때부터는 이 기술에 대한 문제점 제기가 없었습니다. 이제 이 기술도 안정화에 접어들었다고 봐도 괜찮을 듯.

이 WAL 이라는 놈이 무엇을 하는 놈인고 하면,

DB 데이터 조작에 대한 모든 로그를 남겨두었다면, 앞에서 말한 사고가 발생되면 그 로그를 바탕으로 그 사고가 발생되기 바로 이전 상태로 복구할 수 있는데까지 최대한 복구하는 기능입니다.

물론 이 기능도 또한 dba 입장에서 따로 처리해야하는 것은 없습니다. 서버가 알아서 복구할 것이니까요.

이때 복구 정도는 트랜잭션 상태까지도 복구가 가능합니다.

개인적인 생각과 PostgreSQL 개발자들의 생각 또한 비슷하겠지만,

앞으로의 PostgreSQL 의 데이터 복구는 아마 오라클의 redo 로그 형태로 갈 것 같습니다. 이 기능의 초기 모습이 아마 WAL 기술이 아닐까 싶습니다.

심지어 사용자가 실수로 데이터를 조작하고 commit 되어버린 상태일지라도, redo 로그를 이용해서 이전 상태로 복구할 수 있는 기능까지 제공하지 않을까 싶네요. (별로 먼 훗날의 이야기가 되지는 않을 듯)

결론적으로 (지극히 개인적인 결론입니다)

PostgreSQL의 데이터 안정성은 현재 7.1.3 버전에서는 충분히 기업안에서 사용되어도 안정한 상태입니다.

기업안에서 사용되어도 괜찮다는 것은 데이터의 안정성만을 고려한 것입니다.

기업안에서 사용되려면, 대용량처리와 속도, 그리고 유지보수에 대한 관리비용까지 고려해야할 것같습니다.

기업내에 PostgreSQL 관리를 마음대로 할 수 있는 사람이 DBA를 맡는다면, 유지보수에 대한 문제는 해결하겠지만,

Oracle같이 대용량의 처리는 아직까지는 문제가 있습니다.

가장 근복적인 문제가 바로 tablespace 라는 개념이 없다는 것인데,

이것 또한 조만간에 해결이 나겠지요. 현재 디렉토리 구조의 데이터 저장 방식으로는 대용량 처리에 문제가 있거든요.