읽기 가용성을 포함하여 Aurora 클러스터 재부팅 - Amazon Aurora

읽기 가용성을 포함하여 Aurora 클러스터 재부팅

읽기 가용성 기능을 사용하면 기본 또는 보조 DB 클러스터의 리더 인스턴스를 재부팅하지 않고도 Aurora 클러스터의 라이터 인스턴스를 재부팅할 수 있습니다. 이렇게 하면 라이터 인스턴스를 재부팅하는 동안 읽기 작업에 대한 클러스터의 고가용성을 유지하는 데 도움이 됩니다. 나중에 편리한 일정에 따라 리더 인스턴스를 재부팅할 수 있습니다. 예를 들어 프로덕션 클러스터에서는 프라이머리 인스턴스의 재부팅이 완료된 후에만 리더 인스턴스를 한 번에 하나씩 재부팅할 수 있습니다. 재부팅하는 각 DB 인스턴스에 대해 Aurora 클러스터 내의 DB 인스턴스 재부팅의 절차를 따릅니다.

기본 DB 클러스터의 읽기 가용성 기능은 Aurora MySQL 버전 2.10 이상에서 사용할 수 있습니다. 보조 DB 클러스터의 읽기 가용성은 Aurora MySQL 버전 3.06 이상에서 사용할 수 있습니다.

이 함수는 다음 Aurora PostgreSQL 버전에서 기본적으로 사용할 수 있습니다.

  • 15.2 이상의 15 버전

  • 14.7 이상의 14 버전

  • 13.10 이상의 13 버전

  • 12.14 이상의 12 버전

Aurora PostgreSQL의 읽기 가용성 기능에 대한 자세한 내용은 Aurora 복제본의 읽기 가용성 향상 섹션을 참조하세요.

이 기능이 출시되기 전에는 기본 인스턴스를 재부팅하면 각 리더 인스턴스가 동시에 재부팅되었습니다. Aurora 클러스터에서 이전 버전을 실행 중인 경우 읽기 가용성을 포함하지 않고 Aurora 클러스터 재부팅의 재부팅 절차를 대신 사용합니다.

참고

Aurora MySQL 버전 3.06 미만의 Aurora 글로벌 데이터베이스의 경우 읽기 가용성이 포함된 Aurora DB 클러스터의 재부팅 동작에 대한 변경 사항이 다릅니다. Aurora 글로벌 데이터베이스의 프라이머리 클러스터에 대한 라이터 인스턴스를 재부팅하는 경우 프라이머리 클러스터의 리더 프로그램 인스턴스는 사용할 수 있는 상태로 유지됩니다. 그러나 세컨더리 클러스터의 DB 인스턴스는 동시에 재부팅됩니다.

향상된 읽기 가용성 기능의 제한된 버전은 Aurora PostgreSQL 버전 12.16, 13.12, 14.9, 15.4 이상용 Aurora 글로벌 데이터베이스에서 지원됩니다.

클러스터 파라미터 그룹을 변경한 후에는 클러스터를 자주 재부팅하게 됩니다. 파라미터를 변경하려면 Amazon Aurora의 파라미터 그룹의 절차를 따릅니다. 클러스터 파라미터에 변경 사항을 적용하기 위해 Aurora 클러스터에서 라이터 DB 인스턴스를 재부팅한다고 가정해 보겠습니다. 리더 DB 인스턴스의 일부 또는 전부에는 이전 파라미터 설정이 계속해서 사용될 수 있습니다. 그러나 다른 파라미터 설정이 클러스터의 데이터 무결성에 영향을 미치지는 않습니다. 데이터 파일 구성에 영향을 주는 클러스터 파라미터는 라이터 DB 인스턴스에만 사용됩니다.

예를 들어, Aurora MySQL 인스턴스에서 리더 인스턴스 전에 라이터 인스턴스의 binlog_format 및 innodb_purge_threads와 같은 클러스터 파라미터를 업데이트할 수 있습니다. 라이터 인스턴스만 바이너리 로그를 작성하고 실행 취소 레코드를 제거합니다. 쿼리에서 SQL 문 또는 쿼리 출력을 해석하는 방식을 변경하는 파라미터의 경우 리더 인스턴스를 즉시 재부팅해야 할 수 있습니다. 이렇게 해야 쿼리 중에 예기치 않은 애플리케이션 동작을 방지할 수 있습니다. 예를 들어 lower_case_table_names 파라미터를 변경하고 라이터 인스턴스를 재부팅한다고 가정합시다. 이 경우 리더 인스턴스가 모두 재부팅될 때까지 새로 생성한 테이블에 액세스하지 못할 수 있습니다.

모든 Aurora MySQL 클러스터 파라미터 목록은 클러스터 수준 파라미터 섹션을 참조하세요.

모든 Aurora PostgreSQL 클러스터 파라미터 목록은 Aurora PostgreSQL 클러스터 수준 파라미터 섹션을 참조하세요.

작은 정보

클러스터에서 처리량이 높은 워크로드를 처리 중인 경우 Aurora MySQL은 라이터 인스턴스와 함께 일부 리더 인스턴스를 재부팅할 수 있습니다.

재부팅 횟수의 감소는 장애 조치 작업 중에도 적용됩니다. Aurora MySQL은 장애 조치 중에 라이터 DB 인스턴스와 장애 조치 대상만 재시작합니다. 클러스터의 다른 리더 DB 인스턴스는 리더 엔드포인트에 대한 연결을 통해 쿼리를 처리하는 데 계속해서 사용할 수 있습니다. 따라서 클러스터에 리더 DB 인스턴스를 2개 이상 보유하여 장애 조치 중에 가용성을 개선할 수 있습니다.