저는 자체 호스팅 데이터베이스 인스턴스 (예 : Linux의 MySQL 또는 PostgreSQL, 베어 메탈 또는 AWS 자체)에서 Amazon RDS로 일부 데이터베이스를 이동하는 것을 고려해 왔지만, 일단 모든 것이 어떻게 작동하는지는 분명하지 않습니다. 데이터베이스를 만들었고 유지 보수를 시작할 시간입니다.Amazon RDS 데이터베이스 인스턴스는 어떻게 프로비저닝됩니까?
예를 들어 데이터베이스에 사용될 인스턴스 유형을 선택해야합니다. 이는 모든 것이 얼마나 반응이 좋을지를 의미하며 다중 AZ 배포를위한 옵션이 있음을 의미합니다. 내가 실제로 구성하고있는 인스턴스 유형을 몇 가지 지우십시오. 아마도 다중 AZ 배포에는 적어도 두 개의 인스턴스가 필요합니다.
장애 조치에 대한 옵션이 있습니다. 이로 인해 인스턴스에 문제가있는 경우 서비스에 의존 할 수 있다고 믿지만, 자동 업그레이드를위한 유지 관리 기간을 선택하는 섹션도 있습니다. 나는 혼란 스럽다. 예를 들어 2 인스턴스 MySQL 설치, 한 인스턴스를 업그레이드 한 다음 다른 중단 시간을 피하려면 다른 인스턴스를 업그레이드하십시오. RDS가 어떻게 작동합니까?
RDS는 자동 "부 버전 업그레이드"(예, 제발)에 대한 지원을 알리고 있지만 OS 업그레이드에 대해서는 언급하지 않습니다. 아마도 db 엔진은 Amazon Linux 또는 이와 비슷한 형태로 실행되며 패키지에 대한 업데이트가 주기적으로 필요합니다. 모든 것이 자동으로 수행 되나요? 아니면 수동으로 업그레이드를 수행해야합니까?
RDS와 같은 것을 사용하는 요점은 서비스가 더 이상 걱정할 필요가 없다는 것입니다. 패키지 유지 관리, 업그레이드, 장애 조치 또는 예기치 않은 중단 시간을 다루지 않아도됩니다. 물론, 충분히 지불). 그러나 RDS 인스턴스의 모든 옵션을 통해 모든 것을 직접 실행하는 것보다 RDS가 제공하는 이점에 회의적입니다.
AWS RDS에 대한 경험이있는 사람이라면 누구나 유지 보수, 업그레이드 및 장애 복구 경험에 대해 의견을 개진 할 수 있습니까?
mutli-az 인스턴스가있는 경우 유지 보수 기간 중에 하나의 인스턴스를 업그레이드 한 다음 장애 조치 한 다음 다른 인스턴스를 업그레이드합니다. 그러나 장애 조치 (failover) 중에 응용 프로그램은 새로운 데이터베이스 연결을 열 수없는 일시적인 기간이 아마도 60 초가 될 수 있으므로 가장 편리한 시간에 예약하는 것이 여전히 중요합니다. –
OS 유지 관리에 관해서는 OS에 대한 가시성이 전혀 없습니다. SSH 액세스 권한이 없습니다. OS는 전적으로 뒤에서 관리됩니다. DB 서버가 중단되어야하는 OS 유지 보수 태스크는 지정한 유지 보수 창에서 발생합니다. RDS를 사용할 때 스스로 수행해야하는 많은 유지 관리 작업을 확실히 제거합니다. –
@MarkB 왜 장애 조치 지연입니까? 응용 프로그램에서 장애 극복이 발생할 수 있음을 인식하면 단일 연결에 대한 시간 만 소요되고 대체 호스트로 전환하기위한 장애 조치가 실패하지 않아야합니까? –