Amazon Aurora 안정성 - Amazon Aurora
스토리지 자동 복구유지 가능한 페이지 캐시예기치 않은 재시작 시 복구

Amazon Aurora 안정성

Aurora는 안정성, 내구성 및 내결함성을 고려하여 설계되었습니다. Aurora DB 클러스터는 Aurora 복제본을 추가하여 다른 가용 영역에 배포하는 등의 방법으로 가용성을 높이도록 설계할 수 있습니다. 그 밖에도 Aurora에는 안정적인 데이터베이스 솔루션을 위한 자동 기능이 몇 가지 포함되어 있습니다.

스토리지 자동 복구

Aurora는 3개의 가용 영역에 여러 개의 복사본을 보관하고 있기 때문에 디스크 결함으로 인한 데이터 손실 가능성이 최소화됩니다. 또한 Aurora는 클러스터 볼륨을 구성하는 디스크 볼륨에서 장애를 자동으로 감지합니다. 예를 들어 디스크 볼륨 세그먼트에 결함이 발생하면 Aurora가 즉시 해당 세그먼트를 복구합니다. Aurora가 디스크 세그먼트를 복구할 때 클러스터 볼륨을 구성하는 다른 볼륨의 데이터를 사용하여 복구된 세그먼트의 데이터가 최신 상태인지 확인합니다. 그 결과, Aurora는 데이터 손실을 방지하고 디스크 장애로부터 복구하기 위해 특정 시점 복구를 수행해야 할 필요성을 줄여줍니다.

유지 가능한 페이지 캐시

Aurora에서는 각 DB 인스턴스의 페이지 캐시가 데이터베이스와 별도의 프로세스로 관리되며, 이를 통해 페이지 캐시가 데이터베이스와 상관없이 유지됩니다. (페이지 캐시는 Aurora MySQL에서는 InnoDB 버퍼 풀, Aurora PostgreSQL에서는 버퍼 캐시라고도 합니다.)

드문 경우이지만 데이터베이스 장애가 발생할 경우, 페이지 캐시는 메모리에 남아 데이터베이스가 재시작될 때 현재 데이터 페이지를 페이지 캐시에 '웜' 상태로 유지합니다. 이렇게 하면 페이지 캐시를 '워밍업'하기 위해 초기 쿼리가 읽기 I/O 작업을 실행할 필요가 없으므로 성능이 향상됩니다.

Aurora MySQL의 경우 재부팅 및 장애 조치 시 페이지 캐시 동작은 다음과 같습니다.

  • 리더 인스턴스를 재부팅하지 않고 라이터 인스턴스를 재부팅할 수 있습니다.

    • 라이터 인스턴스가 재부팅될 때 리더 인스턴스가 재부팅되지 않으면 재부팅되지 않은 리더 인스턴스의 페이지 캐시가 손실되지 않습니다.

    • 라이터 인스턴스가 재부팅될 때 리더 인스턴스가 재부팅되면 재부팅되는 리더 인스턴스의 페이지 캐시가 손실됩니다.

  • 리더 인스턴스가 재부팅되면 라이터 및 리더 인스턴스의 페이지 캐시가 모두 유지됩니다.

  • DB 클러스터가 장애 조치될 때 이 효과는 라이터 인스턴스가 재부팅될 때와 유사합니다. 새 라이터 인스턴스(이전 리더 인스턴스)에서는 페이지 캐시가 유지되지만, 리더 인스턴스(이전 라이터 인스턴스)에서는 페이지 캐시가 유지되지 않습니다.

Aurora PostgreSQL의 경우 클러스터 캐시 관리를 사용하여 장애 조치 후 라이터 인스턴스가 되는 지정된 리더 인스턴스의 페이지 캐시를 보관할 수 있습니다. 자세한 내용은 장애 조치 후 Aurora PostgreSQL용 클러스터 캐시 관리를 통한 신속한 복구 단원을 참조하십시오.

예기치 않은 재시작 시 복구

Aurora는 예기치 않은 재시작에서 거의 즉각적으로 복구하여 바이너리 로그 없이 애플리케이션 데이터를 계속 제공하도록 설계되었습니다. Aurora는 병렬 스레드에서 비동기적으로 복구를 수행하여 데이터베이스가 열리고 예기치 않은 재시작 후 즉시 사용할 수 있도록 합니다.

자세한 내용은 Aurora DB 클러스터의 내결함성 및 데이터베이스 재시작 시간 단축을 위한 최적화 단원을 참조하세요.

다음은 Aurora MySQL에서의 바이너리 로깅 및 예기치 않은 재시작 복구 시 고려 사항입니다.

  • Aurora 바이너리 로깅을 활성화하면 DB 인스턴스로 하여금 강제로 바이너리 로그 복구를 수행하도록 하므로 예기치 않은 재시작 후 복구 시간에 직접적인 영향을 줍니다.

  • 사용되는 이진 로깅 유형은 로깅의 크기와 효율에 영향을 미칩니다. 데이터베이스 활동의 양이 동일하더라도 형식에 따라 이진 로그에서 더 많은 정보가 로깅됩니다. 다음과 같은 binlog_format 파라미터 설정으로 로그 데이터의 양이 달라집니다.

    • ROW – 최대 로그 데이터

    • STATEMENT – 최소 로그 데이터

    • MIXED – 일반적으로 데이터 무결성과 성능의 최상의 조합을 제공하는 적당량의 로그 데이터

    이진 로그 데이터의 양은 복구 시간에 영향을 미칩니다. 이진 로그에 로깅된 데이터가 더 많은 경우, DB 인스턴스는 복구 도중 더 많은 데이터를 처리해야 하므로 복구 시간이 길어집니다.

  • 이진 로깅으로 계산 오버헤드를 줄이고 복구 시간을 개선하기 위해 향상된 binlog를 사용할 수 있습니다. 향상된 binlog는 데이터베이스 복구 시간을 최대 99% 개선합니다. 자세한 내용은 Aurora MySQL에 대해 향상된 binlog 설정 단원을 참조하십시오.

  • Aurora은 DB 클러스터 내에서 데이터를 복제하거나 특정 시점 복원(PITR)을 수행하기 위해 바이너리 로그를 필요로 하지 않습니다.

  • 외부 복제(또는 외부 이진 로그 스트림)에 이진 로그가 필요하지 않은 경우, binlog_format 파라미터를 OFF로 설정하여 이진 로깅을 비활성화하는 것이 좋습니다. 이렇게 하면 복구 시간이 단축됩니다.

Aurora 이진 로깅 및 복제에 대한 자세한 내용은 Amazon Aurora를 사용한 복제 단원을 참조하십시오. 다양한 MySQL 복제 유형의 영향에 대한 자세한 내용은 MySQL 설명서의 Advantages and Disadvantages of Statement-Based and Row-Based Replication을 참조하세요.