Amazon Aurora 문제 해결

다음 섹션을 바탕으로 Amazon RDS 및 Amazon Aurora의 DB 인스턴스와 관련하여 발생하는 문제를 해결할 수 있습니다.

Amazon RDS API를 사용해 문제를 디버깅하는 방법에 대한 자세한 내용은 Aurora에서 애플리케이션 문제 해결 단원을 참조하세요.

Amazon RDS DB 인스턴스에 연결할 수 없음

DB 인스턴스에 연결할 수 없는 경우 공통적인 원인은 다음과 같습니다.

• 인바운드 규칙 – 로컬 방화벽에서 적용되는 액세스 규칙과 DB 인스턴스에 액세스할 수 있는 권한이 부여된 IP 주소가 일치하지 않을 수 있습니다. 보안 그룹의 인바운드 규칙에 문제가 있을 가능성이 매우 높습니다.

  기본적으로 DB 인스턴스는 액세스를 허용하지 않습니다. 액세스 권한은 VPC와 연결된 보안 그룹을 통해 부여되며, 이는 DB 인스턴스로 들어오고 나가는 트래픽을 허용합니다. 필요한 경우 특정 상황에 대한 인바운드 및 아웃바운드 규칙을 보안 그룹에 추가합니다. IP 주소, IP 주소의 범위 또는 다른 VPC 보안 그룹을 지정할 수 있습니다.

  참고

  새 인바운드 규칙을 추가할 때 원본 의 내 IP를 선택하여 브라우저에서 감지된 IP 주소에서 DB 인스턴스에 액세스하도록 허용할 수 있습니다.

  보안 그룹 설정에 대한 자세한 내용은 보안 그룹을 생성하여 VPC 내의 DB 클러스터에 대한 액세스를 제공합니다. 단원을 참조하십시오.

  참고

  169.254.0.0/16 범위의 IP 주소에서 클라이언트 연결은 허용되지 않습니다. 이는 로컬 링크 주소 지정에 사용되는 APIPA(Automatic Private IP Addressing) 범위입니다.

• 퍼블릭 액세스 가능성 – 클라이언트 애플리케이션을 사용하는 등 VPC 외부에서 DB 인스턴스에 연결하려면 인스턴스에 퍼블릭 IP 주소가 할당되어 있어야 합니다.

  인스턴스에 공개적으로 액세스할 수 있도록 하려면 인스턴스를 수정하고 Public accessibility(퍼블릭 액세스 가능성)에서 예를 선택합니다. 자세한 내용은 VPC에 있는 DB 클러스터를 인터넷에서 숨기기 섹션을 참조하세요.

• 포트 – 로컬 방화벽 제한 때문에 DB 인스턴스를 만들 때 지정한 포트를 사용하여 통신을 주고받을 수 없습니다. 이 경우 네트워크에서 지정한 포트를 인바운드 및 아웃바운드 통신에 사용할 수 있는지 여부를 네트워크 관리자에게 확인하십시오.

• 가용성 – 새로 생성한 DB 인스턴스의 경우 DB 인스턴스를 사용할 준비가 될 때까지 DB 인스턴스의 상태는 creating입니다. 상태가 available로 변경되면 DB 인스턴스에 연결할 수 있습니다. DB 인스턴스의 크기에 따라, 인스턴스를 사용할 수 있을 때까지 최장 20분까지 걸릴 수 있습니다.

• 인터넷 게이트웨이 – DB 인스턴스에 공개적으로 액세스할 수 있도록 하려면 DB 서브넷 그룹의 서브넷에 인터넷 게이트웨이가 있어야 합니다.

  서브넷에 인터넷 게이트웨이를 구성하려면

  1. AWS Management Console에 로그인한 후 https://console.aws.amazon.com/rds/에서 Amazon RDS 콘솔을 엽니다.

  2. 탐색 창에서 데이터베이스를 선택한 다음 DB 인스턴스의 이름을 선택합니다.

  3. 연결&보안 탭에서, VPC에서의 VPC ID 값과 서브넷에서의 서브넷 ID 값을 적어둡니다.

  4. https://console.aws.amazon.com/vpc/에서 Amazon VPC 콘솔을 엽니다.

  5. 탐색 창에서 [Internet Gateways]를 선택합니다. VPC에 인터넷 게이트웨이가 연결되어 있는지 확인합니다. 또는 인터넷 게이트웨이 생성을 선택하여 인터넷 게이트웨이를 만듭니다. 인터넷 게이트웨이를 선택한 후 VPC에 연결을 선택하고 지침에 따라 VPC에 연결합니다.

  6. 탐색 창에서 서브넷을 선택한 후 해당 서브넷을 선택합니다.

  7. [라우팅 테이블(Route table)] 탭에서 대상 위치로 0.0.0.0/0 경로가 있으며, VPC의 대상으로 해당 인터넷 게이트웨이가 있는지 확인합니다.

     IPv6 주소를 이용해 인스턴스에 연결하는 경우 인터넷 게이트웨이를 가리키는 모든 IPv6 트래픽(::/0)에 대한 경로가 있는지 확인합니다. 그렇지 않으면 다음을 수행하십시오.

     1. 라우팅 테이블의 ID(rtb-xxxxxxxx)를 선택해 해당 라우팅 테이블로 이동합니다.

     2. 라우팅 탭에서 라우팅 편집을 선택합니다. 라우팅 추가를 선택하고 대상 위치로 0.0.0.0/0을, 대상으로 인터넷 게이트웨이를 사용합니다.

        IPv6의 경우 라우팅 추가를 선택하고 대상 위치로 ::/0을, 대상으로 인터넷 게이트웨이를 사용합니다.

     3. 라우팅 저장을 선택합니다.

     또한 IPv6 엔드포인트에 연결하려는 경우 클라이언트 IPv6 주소 범위가 DB 인스턴스에 연결할 수 있는 권한이 있는지 확인합니다.

  자세한 내용은 VPC에서 DB 클러스터를 사용한 작업 단원을 참조하세요.

DB 인스턴스 연결 테스트

공통 Linux 또는 Microsoft Windows 도구를 사용하여 DB 인스턴스에 대한 연결을 테스트할 수 있습니다.

Linux 또는 Unix 터미널에서 다음을 입력하여 연결을 테스트할 수 있습니다. DB-instance-endpoint를 엔드포인트로 대체하고 port를 DB 인스턴스의 포트로 대체합니다.

nc -zv DB-instance-endpoint port 

예를 들어, 다음은 샘플 명령과 반환 값을 보여 줍니다.

nc -zv postgresql1.c6c8mn7fake0.us-west-2.rds.amazonaws.com 8299

  Connection to postgresql1.c6c8mn7fake0.us-west-2.rds.amazonaws.com 8299 port [tcp/vvr-data] succeeded! 

Windows 사용자는 Telnet을 사용하여 DB 인스턴스에 대한 연결을 테스트할 수 있습니다. Telnet 작업은 연결 테스트 이외의 목적으로는 지원되지 않습니다. 연결에 성공한 경우 이 작업을 수행할 때 아무런 메시지도 반환되지 않습니다. 연결에 실패한 경우 다음과 같은 오류 메시지가 수신됩니다.

C:\>telnet sg-postgresql1.c6c8mntfake0.us-west-2.rds.amazonaws.com 819

  Connecting To sg-postgresql1.c6c8mntfake0.us-west-2.rds.amazonaws.com...Could not open
  connection to the host, on port 819: Connect failed 

Telnet 작업으로 성공 메시지가 반환되면 보안 그룹이 올바로 구성된 것입니다.

참고

Amazon RDS는 ping을 포함하여 ICMP(Internet Control Message Protocol) 트래픽을 수락하지 않습니다.

연결 인증 문제 해결

경우에 따라서는 DB 인스턴스에 연결할 수 있지만 인증 오류가 발생하는 경우가 있습니다. 이러한 경우 DB 인스턴스에 대한 마스터 사용자 암호를 재설정하는 것이 좋습니다. RDS 인스턴스를 수정하여 이 작업을 수행할 수 있습니다.

Amazon RDS 보안 문제

보안 문제를 피하려면 사용자 계정에 마스터 AWS 사용자 이름과 암호를 절대 사용하지 마세요. 모범 사례에 따라 마스터 AWS 계정를 사용하여 사용자를 생성하고 이런 사용자를 DB 사용자 계정에 할당하는 것이 좋습니다. 필요한 경우 마스터 계정을 사용하여 다른 사용자 계정을 만들 수도 있습니다.

사용자 생성에 대한 자세한 정보는 AWS 계정에서 IAM 사용자 생성을 참조하세요. AWS IAM Identity Center에서의 사용자 생성에 대한 자세한 정보는 IAM Identity Center에서 ID 관리 섹션을 참조하십시오.

오류 메시지 "계정 속성을 불러오지 못했습니다. 일부 콘솔 기능이 손상되었을 수 있습니다."

여러 가지 이유로 이 오류가 발생할 수 있습니다. 계정에 권한이 없거나 계정이 제대로 설정되지 않았기 때문일 수 있습니다. 새 계정인 경우 계정이 준비되기까지 충분한 시간이 지나지 않았을 수도 있습니다. 기존 계정인 경우 DB 인스턴스 생성과 같은 특정 작업을 수행하기 위한 액세스 정책에 권한이 없을 수 있습니다. 이 문제를 해결하려면 관리자가 필요한 역할을 해당 계정에 제공해야 합니다. 자세한 내용은 IAM 설명서를 참조하세요.

DB 인스턴스 소유자 암호 재설정

DB 클러스터가 잠긴 잠긴 경우 마스터 사용자로 로그인할 수 있습니다. 그런 다음 다른 관리 사용자 또는 역할에 대한 자격 증명을 재설정할 수 있습니다. 마스터 사용자로 로그인할 수 없는 경우 AWS 계정 소유자가 마스터 사용자 암호를 재설정할 수 있습니다. 재설정해야 할 관리 계정 또는 역할에 대한 자세한 내용은 마스터 사용자 계정 권한 단원을 참조하십시오.

Amazon RDS 콘솔, AWS CLI 명령 modify-db-instance 또는 ModifyDBInstance API 작업을 사용하여 DB 인스턴스 암호를 변경할 수 있습니다. DB 클러스터에 있는 DB 인스턴스를 수정하는 것에 대한 자세한 내용은 DB 클러스터에서 DB 인스턴스 수정 단원을 참조하십시오.

Amazon RDS DB 인스턴스 중단 또는 재부팅

DB 인스턴스가 재부팅되면 DB 인스턴스가 중단될 수 있습니다. 이는 DB 인스턴스가 액세스할 수 없는 상태로 전환되거나 데이터베이스가 다시 시작될 때도 발생할 수 있습니다. DB 인스턴스를 수동으로 재부팅하면 재부팅이 수행될 수 있습니다. DB 인스턴스 설정을 변경하여 이 변경 사항을 적용하기 위해 재부팅해야 할 때 재부팅이 수행될 수 있습니다.

DB 인스턴스 재부팅은 설정을 변경하여 재부팅해야 할 때 또는 수동으로 재부팅할 때 이 발생합니다. 설정을 변경하고 변경 사항을 즉시 적용할 것을 요청하는 경우 재부팅이 수행될 수 있습니다. 또는 DB 인스턴스의 유지 관리 기간 중에 재부팅이 수행될 수 있습니다.

다음 중 한 가지가 발생할 때는 그 즉시 DB 인스턴스가 재부팅됩니다.

• DB 인스턴스에 대한 백업 보존 기간을 0에서 0이 아닌 값으로 변경하거나 0이 아닌 값에서 0으로 변경합니다. 그런 다음 즉시 적용을 true로 설정합니다.

• DB 인스턴스 클래스를 변경하고 즉시 적용이 true로 설정된 경우

유지 관리 기간 중에 다음 중 한 가지가 발생할 때 DB 인스턴스가 재부팅됩니다.

• DB 인스턴스에 대한 백업 보존 기간을 0에서 0이 아닌 값으로 변경하거나 0이 아닌 값에서 0으로 변경하고 즉시 적용이 false로 설정된 경우

• DB 인스턴스 클래스를 변경하고 즉시 적용이 false로 설정된 경우

DB 파라미터 그룹에서 정적 파라미터를 변경하면 해당 변경 사항은 파라미터 그룹과 연결된 DB 인스턴스를 재부팅해야 적용됩니다. 변경 작업을 수행하려면 수동 재부팅이 필요합니다. 유지 관리 기간 중에는 DB 인스턴스가 자동으로 재부팅되지 않습니다.

Amazon RDS DB 파라미터 변경 사항이 적용 안 됨

경우에 따라 DB 파라미터 그룹에서 파라미터를 변경할 수 있지만 해당 변경 사항이 적용되지 않을 수 있습니다. 이 경우 DB 파라미터 그룹과 연결된 DB 인스턴스를 재부팅해야 할 수 있습니다. 동적 파라미터를 변경하면 해당 변경 사항이 즉시 적용됩니다. 정적 파라미터를 변경하면 해당 변경 사항은 파라미터 그룹과 연결된 DB 인스턴스를 재부팅해야 적용됩니다.

RDS 콘솔을 사용하여 DB 인스턴스를 재부팅할 수 있습니다. 또는 RebootDBInstance API 작업을 명시적으로 호출할 수 있습니다. DB 인스턴스를 다중 AZ 배포로 생성한 경우에는 장애 조치 없이 재부팅할 수 있습니다. 정적 파라미터 변경 후 연결된 DB 인스턴스를 재부팅하도록 하면 잘못된 파라미터 구성이 API 호출에 영향을 주는 위험을 완화할 수 있습니다. 예를 들면 ModifyDBInstance를 호출하여 DB 인스턴스 클래스를 변경하는 경우입니다. 자세한 내용은 DB 파라미터 그룹의 파라미터 수정 단원을 참조하십시오.

Amazon Aurora의 여유 메모리 부족

여유 메모리는 데이터베이스 엔진에서 사용할 수 있는 DB 인스턴스의 총 랜덤 액세스 메모리(RAM)입니다. 이는 여유 운영 체제(OS) 메모리와 사용 가능한 버퍼 및 페이지 캐시 메모리의 합계입니다. 데이터베이스 엔진이 호스트의 메모리 대부분을 사용하지만, OS 프로세스도 일부 RAM을 사용합니다. 현재 데이터베이스 엔진에 할당되거나 OS 프로세스에서 사용하는 메모리는 여유 메모리에 포함되지 않습니다. 데이터베이스 엔진의 메모리가 부족하면 DB 인스턴스는 버퍼링 및 캐싱에 일반적으로 사용되는 임시 공간을 이용하게 됩니다. 앞서 언급했듯이 이 임시 공간은 여유 메모리에 포함됩니다.

Amazon CloudWatch의 FreeableMemory 지표를 사용하여 여유 메모리를 모니터링할 수 있습니다. 자세한 내용은 Amazon Aurora 모니터링 지표 개요 단원을 참조하십시오.

DB 인스턴스에서 사용 가능한 메모리가 계속해서 부족하거나 스왑 공간을 사용하는 경우 더 큰 DB 인스턴스 클래스로 스케일 업하는 것을 고려하세요. 자세한 내용은 Aurora DB 인스턴스 클래스 단원을 참조하십시오.

메모리 설정을 변경할 수도 있습니다. 예를 들어, Aurora MySQL 에서는 innodb_buffer_pool_size 파라미터의 크기를 조정할 수 있습니다. 이 파라미터는 기본적으로 실제 메모리의 75%로 설정됩니다. MySQL 문제 해결 팁을 자세히 알아보려면 Amazon RDS for MySQL 데이터베이스에서 여유 메모리가 부족한 문제를 어떻게 해결할 수 있습니까?를 참조하세요.

Aurora Serverless v2의 경우 FreeableMemory는 Aurora Serverless v2 DB 인스턴스가 최대 용량으로 확장될 때 사용 가능한 미사용 메모리의 양을 나타냅니다. 인스턴스를 비교적 낮은 용량으로 스케일 다운할 수 있지만, 인스턴스가 스케일 업될 수 있기 때문에 계속해서 FreeableMemory에 대해 높은 값을 보고합니다. 이 메모리는 현재 사용할 수 없지만, 필요한 경우 가져올 수 있습니다.

현재 용량이 최대 용량 미만인 모든 Aurora 용량 단위(ACU)에 대해 FreeableMemory가 약 2GiB씩 증가합니다. 따라서 DB 인스턴스가 가능한 한 높게 확장될 때까지 이 지표는 0에 접근하지 않습니다.

이 지표가 0 값에 가까워지면 DB 인스턴스가 최대한 스케일 업된 것입니다. 사용 가능한 메모리 한계에 가까워지고 있음을 나타냅니다. 클러스터에 대한 최대 ACU 설정을 늘리는 것이 좋습니다. 이 지표가 리더 DB 인스턴스에서 0 값에 가까워지는 경우 클러스터에 리더 DB 인스턴스를 추가하는 것이 좋습니다. 이렇게 하면 워크로드의 읽기 전용 부분을 더 많은 DB 인스턴스에 분산하여 각 리더 DB 인스턴스의 메모리 사용량을 줄일 수 있습니다. 자세한 내용은 Aurora Serverless v2에 대한 중요 Amazon CloudWatch 지표 단원을 참조하세요.

Aurora Serverless v1의 경우 더 많은 ACU를 사용하도록 용량 범위를 변경할 수 있습니다. 자세한 내용은 Aurora Serverless v1 DB 클러스터 수정 단원을 참조하십시오.

Amazon Aurora MySQL 메모리 부족 문제

The Aurora MySQL aurora_oom_response 인스턴스 수준 파라미터를 사용하면 DB 인스턴스가 시스템 메모리를 모니터링하고 다양한 명령문 및 연결에서 소비되는 메모리를 예측할 수 있습니다. 시스템 메모리가 부족해지면 시스템은 이 메모리를 해제하려고 시도하는 작업 목록을 수행할 수 있습니다. 메모리 부족(OOM) 문제로 인한 데이터베이스 재시작을 피하려고 시도하는 과정에서 그러한 작업 목록을 수행합니다. 이 인스턴스 수준 파라미터는 메모리가 부족할 때 DB 인스턴스가 수행하는 쉼표로 구분된 작업 문자열을 사용합니다. aurora_oom_response 파라미터는 Aurora MySQL 버전 2 및 3에서 지원됩니다.

다음 값과 그 조합을 aurora_oom_response 파라미터에 사용할 수 있습니다. 문자열을 비워두면 어떠한 작업도 수행하지 않는다는 뜻이며 해당 기능이 사실상 해제되어 데이터베이스가 OOM으로 인해 재시작되기 쉽습니다.

• decline – DB 인스턴스 메모리가 부족해지면 새 쿼리를 거부합니다.

• kill_query – 인스턴스 메모리가 하한값 이상이 될 때까지 메모리 사용량이 많은 순서로 쿼리를 종료합니다. DDL 문이 종료되지 않습니다.

  자세한 내용은 MySQL 설명서의 KILL statement를 참조하세요.

• print - 많은 양의 메모리를 사용하는 쿼리만 인쇄합니다.

• tune – 내부 테이블 캐시를 조정하여 일부 메모리를 시스템으로 돌려줍니다. Aurora MySQL은 메모리가 부족해지면 table_open_cache, table_definition_cache 같은 캐시에 사용하는 메모리를 줄입니다. 그리고 시스템의 메모리가 부족해지지 않게 되면 이러한 캐시에 사용하는 메모리를 정상 수준으로 되돌립니다.

  자세한 내용은 MySQL 설명서의 table_open_cache 및 table_definition_cache를 참조하세요.

3.06 미만의 Aurora MySQL 버전에서 메모리가 4GiB 이하인 DB 인스턴스 클래스의 경우, 인스턴스에 메모리 부족 현상이 발생하면 기본 작업에 print, tune, decline, kill_query 등이 포함됩니다. 메모리가 4GiB보다 큰 DB 인스턴스 클래스의 경우, 파라미터 값은 기본적으로 비어 있습니다(비활성화됨).

Aurora MySQL 버전 3.06 이상에서는 메모리가 4GiB 이하인 DB 인스턴스 클래스의 경우, Aurora MySQL은 메모리를 가장 많이 소비하는 연결도 종료합니다. InnoDB 버퍼 풀은 원래 크기의 최대 70%까지 자동으로 튜닝됩니다. 인스턴스의 메모리 용량이 부족해지면 InnoDB 버퍼 풀이 원래 크기로 복원됩니다. 메모리가 4GiB보다 큰 DB 인스턴스 클래스의 경우, 파라미터 값은 기본적으로 print입니다.

메모리 부족 문제가 자주 발생하는 경우, performance_schema가 활성화되면 메모리 요약 테이블을 사용하여 메모리 사용량을 모니터링할 수 있습니다.

Amazon Aurora MySQL 복제 문제

일부 MySQL 복제 문제도 Aurora MySQL에 적용됩니다. 이러한 문제를 진단하고 해결할 수 있습니다.

주제

• 읽기 전용 복제본 간 지연 문제 진단 및 해결
• MySQL 읽기 복제 오류 진단 및 해결
• 복제 중지 오류

읽기 전용 복제본 간 지연 문제 진단 및 해결

MySQL 읽기 전용 복제본을 생성하고 읽기 전용 복제본을 사용할 수 있게 된 후 Amazon RDS는 우선 읽기 전용 복제본 생성 작업이 시작된 시간부터 원본 DB 인스턴스에서 변경된 사항을 복제합니다. 이 단계에서 읽기 전용 복제본의 복제 지연 시간은 0보다 큽니다. Amazon RDS  AuroraBinlogReplicaLag 지표를 보고 Amazon CloudWatch에서 이 지연 시간을 모니터링할 수 있습니다.

AuroraBinlogReplicaLag 메트릭은 MySQL Seconds_Behind_Master 명령의 SHOW REPLICA STATUS 필드의 값을 보고합니다. 자세한 내용은 MySQL 설명서의 SHOW REPLICA STATUS 문을 참조하세요.

AuroraBinlogReplicaLag 지표가 0에 도달하면 복제본이 원본 DB 인스턴스를 따라잡은 것입니다. AuroraBinlogReplicaLag 메트릭이 -1을 반환하는 경우에는 복제가 활성 상태가 아닐 수 있습니다. 복제 오류 문제를 해결하는 방법은 MySQL 읽기 복제 오류 진단 및 해결 단원을 참조하십시오. AuroraBinlogReplicaLag 값이 -1인 경우 Seconds_Behind_Master 값을 결정할 수 없거나 이 값이 NULL이라는 의미일 수도 있습니다.

참고

이전 버전의 Aurora MySQL에는 SHOW REPLICA STATUS 대신 SHOW SLAVE STATUS가 사용되었습니다. Aurora MySQL 버전 1 또는 2을 사용하는 경우 SHOW SLAVE STATUS를 사용합니다. Aurora MySQL 버전 3 이상의 경우 SHOW REPLICA STATUS를 사용합니다.

네트워크가 중단된 기간 동안이나 유지 관리 기간 중에 패치가 적용될 때  AuroraBinlogReplicaLag 지표는 -1을 반환합니다. 이 경우에는 네트워크 연결이 복원되거나 유지 관리 기간이 종료되기를 기다린 후  AuroraBinlogReplicaLag 지표를 다시 확인합니다.

MySQL 읽기 전용 복제 기술은 비동기식입니다. 따라서 소스 DB 인스턴스의 BinLogDiskUsage 지표와 읽기 전용 복제본의 AuroraBinlogReplicaLag 지표가 가끔 증가할 수도 있습니다. 예를 들어, 원본 DB 인스턴스에 대량의 쓰기 작업이 병렬로 발생하는 경우를 생각해 보십시오. 동시에 읽기 전용 복제본에 대한 쓰기 작업은 단일 I/O 스레드를 사용하여 직렬화됩니다. 이러한 상황으로 인해 원본 인스턴스와 읽기 전용 복제본 사이에 지연 시간이 발생할 수 있습니다.

읽기 전용 복제본과 MySQL에 대한 자세한 내용은 MySQL 설명서의 복제 구현 세부 정보를 참조하십시오.

다음을 수행하여 원본 DB 인스턴스에 대한 업데이트와 읽기 전용 복제본에 대한 후속 업데이트 사이의 지연 시간을 줄일 수 있습니다.

• 읽기 전용 복제본의 DB 인스턴스 클래스를 원본 DB 인스턴스와 비슷한 스토리지 크기로 설정합니다.

• 원본 DB 인스턴스와 읽기 전용 복제본에 사용되는 DB 파라미터 그룹의 파라미터 설정이 호환되는지 확인합니다. 자세한 정보와 예는 다음 섹션에서 max_allowed_packet 파라미터에 대해 설명한 내용을 참조하십시오.

• 쿼리 캐시를 비활성화합니다. 자주 수정되는 테이블의 경우, 쿼리 캐시를 사용하면 캐시가 자주 잠기고 새로 고쳐지기 때문에 복제 지연이 늘어날 수 있습니다. 이럴 경우 쿼리 캐시를 비활성화하면 복제 지연이 줄어드는 효과를 볼 수도 있습니다. DB 인스턴스에 대한 DB 파라미터 그룹에서 query_cache_type parameter를 0으로 설정하여 쿼리 캐시를 비활성화할 수 있습니다. 쿼리 캐시에 대한 자세한 정보는 쿼리 캐시 구성을 참조하십시오.

• MySQL용 InnoDB의 읽기 전용 복제본에서 버퍼 풀을 워밍합니다. 예를 들어, 자주 업데이트되는 작은 테이블 집합이 있고 InnoDB 또는 XtraDB 테이블 스키마를 사용하고 있다고 가정해 보십시오. 이 경우 읽기 전용 복제본에 해당 테이블을 덤프합니다. 그러면 데이터베이스 엔진이 디스크에서 해당 테이블의 행을 전체적으로 검사한 다음 버퍼 풀에 캐시합니다. 이 방법을 사용하면 복제본 지연 시간을 줄일 수 있습니다. 다음은 그 한 예입니다.

  대상 LinuxmacOS, 또는Unix:

  PROMPT> mysqldump \
      -h <endpoint> \
      --port=<port> \
      -u=<username> \
      -p <password> \
      database_name table1 table2 > /dev/null 

  Windows의 경우:

  PROMPT> mysqldump ^
      -h <endpoint> ^
      --port=<port> ^
      -u=<username> ^
      -p <password> ^
      database_name table1 table2 > /dev/null 

MySQL 읽기 복제 오류 진단 및 해결

Amazon RDS는 읽기 전용 복제본의 복제 상태를 모니터링합니다. RDS는 어떤 이유로든 복제가 중지되는 경우 읽기 전용 복제본 인스턴스의 복제 상태 필드를 Error로 업데이트합니다. 복제 오류 필드를 확인하여 MySQL 엔진에서 발생한 관련 오류의 세부 정보를 검토할 수 있습니다. RDS-EVENT-0045, RDS-EVENT-0046 및 RDS-EVENT-0057을 포함하여 읽기 전용 복제본의 상태를 나타내는 이벤트도 생성됩니다. 이벤트와 이벤트 구독에 대한 자세한 내용은 Amazon RDS 이벤트 알림 작업 단원을 참조하십시오. MySQL 오류 메시지가 반환되는 경우 MySQL 오류 메시지 설명서에 있는 오류를 확인하세요.

복제 오류의 원인이 되는 공통적인 상황은 다음과 같습니다.

• 읽기 전용 복제본에 대한 max_allowed_packet 파라미터의 값은 원본 DB 인스턴스에 대한 max_allowed_packet 파라미터보다 작습니다.

  max_allowed_packet 파라미터는 DB 파라미터 그룹에서 설정할 수 있는 사용자 지정 파라미터입니다. max_allowed_packet 파라미터는 데이터베이스에서 실행할 수 있는 데이터 조작 언어(DML)의 최대 크기를 지정하는 데 사용됩니다. 경우에 따라서는 원본 DB 인스턴스의 max_allowed_packet 값이 읽기 전용 복제본에 대한 max_allowed_packet 값보다 클 수도 있습니다. 이러한 경우 복제 프로세스에서 오류가 발생하여 복제가 중지될 수도 있습니다. 가장 흔한 오류는 packet bigger than 'max_allowed_packet' bytes입니다. 원본 및 읽기 전용 복제본이 동일한 max_allowed_packet 파라미터 값을 가진 DB 파라미터 그룹을 사용하도록 하여 이 오류를 해결할 수 있습니다.

• 읽기 전용 복제본의 테이블에 쓰기 작업 중일 때. 읽기 전용 복제본에서 인덱스를 생성할 경우 read_only 파라미터를 0으로 설정하여 인덱스를 생성해야 합니다. 읽기 전용 복제본에 있는 테이블에 데이터를 쓰면 복제가 중단될 수 있습니다.

• MyISAM과 같은 비트랜잭션 스토리지 엔진 사용. 읽기 전용 복제본에는 트랜잭션 스토리지 엔진이 필요합니다. 복제는 MySQL 또는 MariaDB용 InnoDB에 대해서만 지원됩니다.

  다음 명령으로 MyISAM 테이블을 InnoDB로 변환할 수 있습니다.

  alter table <schema>.<table_name> engine=innodb;

• SYSDATE()와 같이 안전하지 않은 비결정적 쿼리를 사용하는 경우. 자세한 내용은 MySQL 설명서의 이진 로깅에서 안전한 문과 안전하지 않은 문 결정을 참조하십시오.

다음 단계를 통해 복제 오류를 해결할 수 있습니다.

• 논리적 오류가 발생하고 이 오류를 건너뛰어도 안전할 경우 현재 복제 오류 건너뛰기​에 설명된 단계를 따르십시오. Aurora MySQL DB 인스턴스에서는 mysql_rds_skip_repl_error 프로시저를 포함한 버전이 실행 중이어야 합니다. 자세한 내용은 mysql_rds_skip_repl_error 단원을 참조하세요.

• 이진 로그(binlog) 위치 문제가 발생하는 경우 복제본 재생 위치를 변경할 수 있습니다. 그러려면 Aurora MySQL 버전 1 및 2에서는 mysql.rds_next_master_log 명령을 사용합니다. Aurora MySQL 버전 3 이상에서는 mysql.rds_next_source_log 명령을 사용합니다. Aurora MySQL DB 인스턴스에서 복제본 재생 위치를 변경하려면 이 명령을 지원하는 버전을 실행해야 합니다. 버전 정보는 mysql_rds_next_master_log를 참조하세요.

• 높은 DML 부하 때문에 일시적인 성능 문제가 발생할 경우 읽기 전용 복제본의 DB 파라미터 그룹에서 innodb_flush_log_at_trx_commit 파라미터를 2로 설정할 수 있습니다. 그러면 일시적으로 원자성, 일관성, 격리성 및 내구성(ACID)이 감소하지만 읽기 전용 복제본이 변화를 따라잡는 데 도움이 될 수 있습니다.

• 읽기 전용 복제본을 삭제하고 동일한 DB 인스턴스 식별자를 사용하여 인스턴스를 생성할 수 있습니다. 이렇게 하면 엔드포인트는 이전 읽기 전용 복제본의 엔드포인트와 동일하게 유지됩니다.

복제 오류가 해결되면 Replication State가 replicating으로 변경됩니다. 자세한 내용은 MySQL 읽기 전용 복제본의 문제 해결을 참조하십시오.

복제 중지 오류

mysql.rds_skip_repl_error 명령을 호출할 때 복제본이 중단되었거나 사용 중지되었다는 오류 메시지가 표시될 수 있습니다.

이 오류 메시지는 복제가 중지되었고 재시작할 수 없기 때문에 표시됩니다.

많은 수의 오류를 건너뛰어야 하는 경우, 복제 지연이 이진 로그 파일의 기본 보관 기간 이상으로 늘어날 수 있습니다. 이 경우, 이진 로그 파일이 복제본에서 재실행되기 전에 지워지기 때문에 치명적 오류가 발생할 수 있습니다. 이 제거는 복제를 중지시키며, 복제 오류를 건너뛰기 위해 더 이상 mysql.rds_skip_repl_error 명령을 호출할 수 없습니다.

이 문제는 복제 원본에서 이진 로그 파일이 보관되는 시간을 늘림으로써 완화할 수 있습니다. binlog 보관 시간을 늘린 후에 복제를 재시작하고 필요에 따라 mysql.rds_skip_repl_error 명령을 호출할 수 있습니다.

binlog 보관 시간을 설정하려면 mysql_rds_set_configuration 프로시저를 사용합니다. 'binlog 보관 시간' 구성 파라미터와 DB 클러스터에 binlog 파일을 보관할 시간(최대 2160시간(90일))을 함께 지정합니다. Aurora MySQL의 기본값은 24(1일)입니다. 다음 예제에서는 binlog 파일의 보관 기간을 48시간으로 설정합니다.

CALL mysql.rds_set_configuration('binlog retention hours', 48);