답변:
그렇습니다, 그것은 생산 준비되어 있고 널리 이용됩니다. Heroku 팔로워는 예를 들어 AWS RDS 대기 및 읽기 전용 복제본과 같이 PostgreSQL의 내장 비동기 복제를 기반으로합니다. 스트리밍 복제는 PostgreSQL에서 거의 보편적으로 사용됩니다.
복제 설정은 그다지 좋지 않지만 repmgr 과 같은 도구는 그에 어느 정도 도움이되며 각 주요 릴리스마다 천천히 향상됩니다. pg_basebackup이 스트리밍 복제를 사용하여 시스템의 사본을 가져오고 다른 대기에서 수행하는 기능은 큰 도움이됩니다.
일반적으로 기능은 프로덕션 준비가 될 때까지 PostgreSQL에서 출시되지 않습니다. 버그는 다른 소프트웨어와 마찬가지로 발생하지만 일반적으로 식별 된 직후 수정됩니다. 실제로 새로운 주요 기능에는 .0 릴리스 이후에 버그와 문제가 발견되는 경우가 있지만 수정하는 것이 우선 순위가 높습니다. 버그는 그냥 남아 있지 않습니다.
스트리밍 복제와 관련된 심각한 문제 (동기화 또는 비 동기화)를 알지 못했으며 오랫동안보고 된 내용을 보지 못했습니다. 도입 된 메이저 버전의 .0 릴리즈에서는 Pg의 일반적인 표준보다 안정성이 떨어졌지만, 빠르게 성숙 해졌고 철저히 생산 준비가되었습니다.
(업데이트 : 9.3.4 이전의 새로운 9.3 버전에는 경우에 따라 복제 문제가 발생하는 특정 버그가있었습니다. 9.3 사용자는 즉시 9.3.4로 업데이트해야합니다. 이전 버전은 영향을받지 않습니다.)
내가 언급하고 싶은 유일한주의 사항은 동기식 복제에 대한 사소한 세부 사항입니다. 마스터에 커밋하면 복제가 확인되기를 기다리는 동안 커밋 후에 쿼리를 취소하면 복제되기 전에도 마스터에서 커밋 된 것으로 간주됩니다. 복제본이 응답하기를 기다리는 동안 마스터를 다시 시작하면 동일한 효과가 나타납니다. 실제로 이것은 무의미하지만, 내가 생각할 수있는 유일한 문제에 관한 것입니다.
Pg의 기본 복제는 MySQL과 매우 다릅니다.
MySQL은 논리적 복제를 사용하여 테이블 데이터, 테이블 구조 등에 대한 논리적 변경 사항을 전송하고 복제본은 이러한 변경 사항을 적용합니다.
PostgreSQL의 복제 수준은 9.5 이하이며 이후 버전에서는 논리 복제를 추가 할 수도 있습니다. 테이블에서 변경된 블록을 보냅니다. 더 간단하고 정확하며 복제 서버의 부하를 낮추지 만 더 많은 네트워크 대역폭을 소비하며 아직 복제되지 않은 변경 사항을 유지하려면 마스터에 더 많은 스토리지가 필요합니다. WAL- 아카이브 폴 백과 함께 스트리밍 복제를 사용하도록 구성하는 것이 가장 좋습니다. MySQL보다 구성이 더 복잡합니다. 튜플 변경뿐만 아니라 VACUUM 작업과 같은 하위 수준 변경 사항을 복제하여 복제본의 디스크 상태를 마스터의 상태와 동일하게 유지합니다. 하나의 데이터베이스 만 복제 할 수 없습니다. 전체 시스템을 복제해야하는데, 이는 크고 높은 이탈 및 중요하지 않은 데이터베이스 하나와 작은, 낮은 이탈 및 중요 데이터베이스가있는 경우 실망 스러울 수 있습니다.
대체로, 그것은 당신이하고 싶은 일에 달려 있습니다.
백업, 고 가용성 및 재해 복구에 사용되는 복제본에 대해 PostgreSQL의 복제가 상당히 우수하다고 생각합니다. 특히 시점 복구 (PITR) 와 결합 할 때 그렇습니다 .
반면, 긴 트랜잭션을 실행하는 동안 복제 된 데이터의 응용 프로그램을 지연시킬 필요가 있기 때문에 매우 오래 실행되는 쿼리를 취소하거나 마스터보다 크게 뒤 쳐야하므로 읽기 전용보고 복제본에는 좋지 않습니다. 마스터에 더 많은 디스크 공간을 확보하고 유지하기가 더 어려워집니다.
PostgreSQL에서 논리적 복제 를 활성화 하는 작업이 진행 중이며 , 여기서 디스크 구조가 아닌 테이블 구조, 테이블 내용 등에 대한 논리적 변경 사항이 복제됩니다. Pg의 카탈로그 디자인 및 사용자 정의 모든 지원은이 작업을 매우 복잡한 작업으로 만듭니다. 9.4에 대한 일부 토대가 마련되었지만 9.6 이상 이전에는 전체 논리적 복제를 사용할 수 없습니다.