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