Databases for PostgreSQL에 대한 고가용성 및 재해 복구 이해
고가용성서비스 또는 작업 부하가 장애를 견디고 사전 정의된 서비스 수준에 따라 처리 기능을 계속 제공할 수 있는 능력. 서비스의 경우, 가용성은 서비스 수준 협약에 정의되어 있습니다. 가용성에는 유지보수, 고장, 재해 등 계획된 이벤트와 계획되지 않은 이벤트가 모두 포함됩니다. (HA)은 예기치 않은 장애가 발생하더라도 서비스가 계속 작동하고 액세스할 수 있는 기능입니다. 재해 복구는서비스 중단과 같은 드물지만 심각한 사고와 광범위한 장애로부터 복구할 수 있는 서비스 또는 작업량 능력. 여기에는 전체 지역에 영향을 미치는 물리적 재해, 데이터베이스 손상, 또는 작업 부하에 기여하는 서비스의 손실이 포함됩니다. 그 영향은 고가용성 설계가 처리할 수 있는 능력을 초과합니다. 서비스 인스턴스를 작동 상태로 복구하는 프로세스입니다.
Databases for PostgreSQL 는 표준 요금제로 정의된 서비스 수준 목표(SLO)를 충족하는 지역 서비스입니다. 자세한 내용은 서비스 수준 계약(SLA) 을 참조하세요. 사용 가능한 IBM Cloud 지역 및 데이터 센터에 대한 자세한 내용은 site.data.keyword.databases-for-postgresql, 위치별 서비스 및 인프라 가용성을 참조하세요.
고가용성 아키텍처
Databases for PostgreSQL 는 인프라 유지보수, 업그레이드 및 일부 장애로부터 데이터베이스와 데이터를 보호하는 복제, 장애 복구 및 고가용성 기능을 제공합니다. 배포에는 리더와 복제본이라는 두 개의 데이터 멤버가 있는 클러스터가 포함되어 있습니다. 복제본은 비동기 복제를 사용하여 최신 상태로 유지됩니다. 분산 합의 메커니즘은 클러스터 상태를 유지하고 장애 조치를 처리하는 데 사용됩니다. 리더에 연결할 수 없게 되면 클러스터는 장애 조치를 시작하고 복제본이 리더로 승격되며 새 복제본이 복제본으로 클러스터에 다시 합류합니다. 리더와 복제본은 항상 MZR의 다른 구역에 위치합니다. 복제본이 실패하면 새 복제본이 만들어집니다. 영역 장애로 인해 구성원이 실패하는 경우, 살아남은 영역에 새 복제본이 생성됩니다.
클러스터에 PostgreSQL 멤버를 추가하여 지역 내 중복성을 높이거나 지역 간 장애 조치 또는 읽기 오프로딩을 위한 읽기 전용 복제본을 프로비저닝하여 고가용성을 더욱 확장할 수 있습니다.
복제 기술에 대한 PostgreSQL 문서를 검토하여 기본적으로 배포되는 비동기 복제 전략과 관련된 제약 조건 및 절충점을 이해하세요.
리더에서 서버 충돌이 발생하는 등 데이터베이스가 심각하게 불안정해지는 시나리오에서는 Databases for PostgreSQL 에서 장애 조치를 시도합니다. 이 자동 장애 조치 기능은 리더에서 복제본까지 데이터 지연이 16MB( PostgreSQL 데이터 오버헤드가 더 많은 경우 몇 행의 데이터)로 제한되며 지연 임계값을 초과하면 수행되지 않습니다. 16MB의 데이터 손실 가능성이 애플리케이션에 견딜 수 없는 수준이라면 아래의 동기식 복제를 참조하세요.
프로그래밍 방식으로 클러스터에 액세스하는 워크로드는 가용성을 유지하기 위해 클라이언트 가용성 재시도 로직을 따라야 합니다.
이 서비스는 때때로 정상 작동 시 제어된 장애 조치를 수행합니다. 이러한 장애 복구는 데이터 손실이 없는 이벤트이지만 활성 연결이 초기화됩니다. 다시 연결이 실패할 수 있는 최대 15초의 기간이 있습니다. 운영 환경의 예기치 않은 이벤트로 인해 계획되지 않은 장애가 발생할 수 있습니다. 최대 45초까지 소요될 수 있지만 일반적으로 30초 미만입니다. 예를 들어 서비스 유지보수는 제어된 장애 조치를 트리거합니다.
고가용성 기능
Databases for PostgreSQL 는 다음과 같은 고가용성 기능을 지원합니다:
| 기능 | 설명 | 고려사항 |
|---|---|---|
| 자동 페일오버 | 모든 클러스터에 표준으로 적용되며 영역 또는 단일 구성원 장애에 대해 복원력 제공 | |
| 구성원 수 | 최소 - 2명. 기본값은 표준 두 멤버 배포입니다. 2명으로 구성된 클러스터는 단일 인스턴스 또는 영역 장애(지연 임계값까지 데이터 손실)가 발생하면 자동으로 복구됩니다. 새 복제본에 대한 데이터 동기화 중에 클러스터가 두 번째 장애에 노출되어 데이터 손실이 발생합니다. 3명의 멤버( PostgreSQL 멤버 추가 참조)는 동일한 장애 기간 동안 두 명의 멤버가 장애가 발생해도 복원력이 있습니다 | 동기식 복제에 필요한 구성원 3명 |
| 동기 복제 | 데이터 쓰기 경로에 원격 멤버 동기화를 추가하여 RPO를 개선합니다. 아래의 동기식 복제를 참조하세요. | 성능 영향 및 비용. |
| 읽기 전용 복제본 | 읽기 전용 복제본은 원격 지역에서 로컬 액세스를 제공하여 잠재적인 네트워크 지연 시간이나 연결 문제에 대한 가용성을 개선할 수 있습니다. | 모든 쓰기 요청은 읽기 복제본과 연결된 읽기-쓰기 클러스터로만 전달되어야 합니다 |
동기식 복제 Databases for PostgreSQL
기본적으로 스트리밍 복제는 비동기식입니다. 리더가 충돌하면 커밋된 일부 트랜잭션이 복제본에 동기화되지 않아 데이터 손실이 발생할 수 있습니다. Cloud Databases 동기식 복제는 실질적인 데이터 손실을 최소화하지만, 트랜잭션의 모든 변경 사항이 복제본에 동기화되었는지 확인할 수 있는 기능을 제공합니다. 이렇게 하면 클러스터 전체에서 일관성이 보장됩니다. 이러한 일관성은 success 를 사용하여
연결 클라이언트로 돌아가기 전에 쓰기가 보조에 쓰여지는지 확인하는 데서 비롯됩니다. 동기식 복제와 관련된 변수에 대해서는 synchronous_commit 구성 변경 페이지를 참조하세요.
동기 복제는 복제본 가용성을 기본 쓰기 경로로 가져옵니다. 쓰기를 승인할 복제본이 없는 경우 복제본을 사용할 수 있을 때까지 중단됩니다. 두 멤버 배치에서는 동기 복제가 지원되지 않으므로 이 조작이 안정적으로 작동하려면 세 개 이상의 멤버가 필요합니다. 동기식 복제를 사용하려면 먼저 멤버를 최소 3명으로 수평 확장해야 합니다. PostgreSQL 회원 추가하기를 참조하세요.
가능성은 낮지만 두 개 이상의 복제본을 동시에 사용할 수 없게 될 수도 있습니다. 이 경우, 복제본이 다시 온라인 상태가 될 때까지 기본 데이터베이스가 쓰기를 완료할 수 없으므로 사실상 데이터베이스에 대한 모든 쓰기 트래픽이 차단됩니다. 동기식 복제를 사용하기로 결정한 경우, 데이터 내구성 향상에 따른 상대적인 비용과 이점을 잠재적인 가용성 문제와 비교하여 비교 검토하세요.
동기식 복제를 구성하면 쓰기 대기 시간을 크게 늘리고 전체 처리량을 줄일 수 있습니다. 최적의 성능을 위해 최고 수준의 데이터 내구성이 필요한 특정 데이터베이스 또는 워크로드에만 동기식 복제를 사용하는 것이 좋습니다.
재해 복구 아키텍처
재해 복구를 위한 일반적인 전략은 아래의 Restore 데이터베이스와 같은 새 데이터베이스를 만드는 것입니다. 새 데이터베이스의 콘텐츠는 재해 이전에 생성된 원본 데이터베이스의 백업일 수 있습니다. 프로덕션 데이터베이스를 사용할 수 있는 경우 특정 시점 기능을 사용하여 새 데이터베이스를 만들 수 있습니다.
재해 복구 기능
Databases for PostgreSQL 는 다음과 같은 재해 복구 기능을 지원합니다:
| 기능 | 설명 | 고려사항 |
|---|---|---|
| 백업 복원 | 이전에 만든 백업에서 데이터베이스를 만듭니다( Cloud Databases 백업 관리하기를 참조하세요). | 복원된 데이터베이스에 대한 새 연결 문자열은 워크로드 전체에서 참조해야 합니다. |
| 특정 시점 복원 | 특정 시점 복구를 사용하여 라이브 프로덕션에서 데이터베이스 만들기 | 이는 활성 데이터베이스를 사용할 수 있고 RPO(재해)가 지원되는 기간 내에 해당하는 경우에만 가능합니다. 프로덕션 클러스터를 사용할 수 없는 경우에는 유용하지 않습니다. 복원된 데이터베이스에 대한 새 연결 문자열은 워크로드 전체에서 참조해야 합니다. |
| 읽기 복제본 홍보 | 동일 또는 원격 지역의 재해에 대비할 때 읽기 전용 복제본을 만드세요. 재해로부터 복구할 수 있도록 읽기 전용 복제본을 승격하세요. | 이전에 생성한 읽기 복제본을 사용할 수 있어야 합니다. 복원된 데이터베이스에 대한 새 연결 문자열은 워크로드 전체에서 참조해야 합니다. |
재해 복구 계획
재해 복구 단계는 정기적으로 연습해야 합니다. 계획을 수립할 때 다음과 같은 실패 시나리오와 해결 방법을 고려하세요.
| 실패 | 분석 |
|---|---|
| 하드웨어 장애(단일 지점) | IBM 는 영역 내 단일 하드웨어 장애 지점으로부터 복원력을 갖춘 데이터베이스를 제공하며, 별도의 구성이 필요하지 않습니다. |
| 구역 장애 | 자동 장애 조치(#postgresql-고가용성). 데이터베이스 멤버는 영역 간에 분산되어 있습니다. 세 명의 멤버를 구성하면 여러 영역 장애에 대한 복원력을 추가로 확보할 수 있습니다.
동기식 복제는 성능을 희생하는 대신 RPO를 줄입니다. |
| 데이터 손상 | 백업 복원. 프로덕션 또는 소스 데이터에 복원된 데이터베이스를 사용하여 복원된 데이터베이스의 손상을 수정합니다.
특정 시점 복원. 프로덕션 또는 소스 데이터에 복원된 데이터베이스를 사용하여 복원된 데이터베이스의 손상을 수정합니다. |
| 지역별 실패 | 백업 복원. 프로덕션 환경에서 복원된 데이터베이스를 사용하세요.
읽기 복제본을 홍보합니다. 읽기 전용 복제본을 읽기/쓰기 데이터베이스로 승격합니다. 프로덕션 환경에서 복원된 데이터베이스 사용 |
애플리케이션 레벨의 고가용성
네트워크 및 클라우드 서비스를 통해 통신하는 애플리케이션은 일시적 연결 실패의 영향을 받습니다. 사용자 배치 또는 IBM Cloud에 대한 연결에서 일시적인 끊김으로 인한 오류가 발생하는 경우 연결을 재시도하도록 애플리케이션을 디자인하려고 합니다.
Databases for PostgreSQL 은 관리형 서비스이므로 정기적인 업데이트와 데이터베이스 유지보수는 정상적인 운영의 일부로 이루어집니다. 이로 인해 가끔 짧은 간격으로 데이터베이스를 사용할 수 없게 될 수 있습니다. 또한 이로 인해 데이터베이스가 정상적인 장애 복구, 재시도 및 다시 연결을 트리거할 수도 있습니다. 데이터베이스가 복제본인 멤버와 리더인 멤버를 판별하는 데 약간의 시간이 걸리기 때문에 잠시 연결이 중단될 수도 있습니다. 일반적으로 장애 복구에는 30초 미만이 걸립니다.
데이터베이스에 대한 일시적 중단을 처리하고 실패한 데이터베이스 명령에 대한 오류 처리를 구현하고 일시적 중단으로부터 복구하기 위한 재시도 논리를 구현하도록 애플리케이션을 디자인해야 합니다.
몇 분 동안 데이터베이스를 사용할 수 없거나 연결이 중단되는 일은 예상되지 않습니다. 연결이 되지 않는 시간이 1분 이상 지속되는 경우 자세한 내용을 포함한 지원 케이스를 열어 조사할 수 있도록 하세요.
연결 한계
Databases for PostgreSQL에서는 PostgreSQL 데이터베이스에 대한 최대 연결 수를 115로 설정합니다. 데이터베이스의 상태와 무결성을 유지하기 위해 수퍼유저의 경우 15개의 연결이 예비되어 있으며, 사용자 및 사용자 애플리케이션의 경우 100개의 연결이 사용 가능합니다. 연결 제한에 도달한 후 새 연결을 시작하려고 시도하면 오류가 발생합니다. 배포에 연결이 폭주하는 것을 방지하려면 연결 풀링을 사용하거나 배포를 확장하고 연결 제한을 늘리세요. 자세한 내용은 PostgreSQL 연결 관리 페이지를 참조하세요.
HA 및 DR에 대한 책임
다음 정보는 HA 및 DR 계획을 수립하고 지속적으로 실천하는 데 도움이 될 수 있습니다.
백업에서 데이터베이스를 복원하거나 특정 시점 복원을 사용하는 경우 새 연결 문자열로 새 데이터베이스가 만들어집니다. 새 연결 문자열을 사용하려면 기존 워크로드와 프로세스를 조정해야 합니다. 읽기 복제본을 클러스터로 승격하는 것도 비슷한 영향을 미치지만, 워크로드의 기존 읽기 전용 부분에는 영향을 미치지 않습니다.
복구된 데이터베이스에는 재해 데이터베이스와 동일한 고객 생성 종속성이 필요할 수도 있으므로 이러한 서비스 및 기타 서비스가 복구된 지역에 존재하는지 확인하세요:
- IBM® Key Protect for IBM Cloud®
- Hyper Protect Crypto Services
데이터베이스를 삭제하면 관련 백업도 삭제된다는 점을 기억하세요. 그러나 삭제된 데이터베이스는 제한된 기간 내에 복구할 수 있습니다. 데이터베이스 복구 절차에 대한 구체적인 내용은 설명서를 참조하세요.
IBM Cloud 에서 백업을 복사할 수 없으므로 추가 백업을 위해 데이터베이스별 도구를 사용하는 것이 좋습니다. 악의적인 데이터베이스 삭제에 이어 데이터베이스 복구가 필요할 수 있습니다. 데이터베이스에 대한 IAM 액세스를 주의 깊게 관리하면 이 문제에 대한 노출을 줄일 수 있습니다.
각 기능과 관련된 다음 체크리스트는 계획을 세우고 실천하는 데 도움이 될 수 있습니다.
- 백업 복원
- RPO 요구 사항을 충족하기 위해 원하는 주기로 백업을 사용할 수 있는지 확인합니다. Cloud Databases 백업 문서 백업 빈도를 관리합니다. IBM Cloud® Code Engine 사용하는 스크립트를 고려해 보세요. 데이터베이스의 중요도와 크기가 허락한다면 주기적 타이머(cron)이벤트 생성자와 협력하여 RPO를 개선하기 위해 추가 주문형 백업을 생성합니다. 그러나 PostgreSQL's PITR 기능을 고려할 때 추가 백업의 필요성을 신중하게 평가하세요.
- 데이터베이스 복원 지역에는 몇 가지 제한 사항이 있습니다. Cloud Databases 백업 관리하기를 읽고 복원 목표를 달성할 수 있는지 확인하세요.
- 백업의 보존 기간이 요구 사항을 충족하는지 확인합니다.
- 정기적으로 테스트 복원을 예약하여 실제 복원 시간이 정의된 RTO를 충족하는지 확인합니다. 데이터베이스 크기는 복원 시간에 큰 영향을 미친다는 점을 기억하세요. 대규모 데이터베이스를 관리하기 쉬운 작은 단위로 나누고 사용하지 않는 데이터를 삭제하는 등 복원 시간을 최소화하는 전략을 고려해 보세요.
- Key Protect 서비스를 확인합니다.
- 특정 시점 복원
- 앞서 설명한 절차를 확인합니다.
- 원하는 백업이 창에 있는지 확인합니다.
- 읽기 복제본 홍보
- 복구 영역에 읽기 복제본이 있는지 확인합니다.
- 프로모션 프로세스 연습 - 원하는 지역에 임시 읽기 복제본을 만듭니다. 임시 복제본을 읽기/쓰기로 승격하고 프로덕션에 거의 영향을 주지 않으면서 일부 테스트를 수행할 수 있습니다.
Databases for PostgreSQL 사용에 대한 고객과 IBM Cloud 간의 책임 소유권에 대해 자세히 알아보려면 Cloud Databases 에 대한 책임 공유를 참조하세요.
최신 정보 받기: IBM 알림
고객 워크로드에 영향을 미치는 업데이트는 IBM Cloud 알림을 통해 전달됩니다. 이 서비스와 관련된 계획된 유지 관리, 공지 사항 및 릴리스 노트에 대한 최신 정보를 확인하려면 모니터링 알림 및 상태 페이지를 참조하세요. 또한 버전 정책 페이지에서 지원 종료 버전 및 날짜에 대한 최신 업데이트를 정기적으로 확인하시기 바랍니다.