Amazon RDS 문제 해결 - Amazon Relational Database Service
DB 인스턴스에 연결할 수 없음보안 문제호환되지 않는 네트워크 상태 문제 해결DB 인스턴스 소유자 암호 재설정DB 인스턴스 중단 또는 재부팅파라미터 변경 사항이 적용 안 됨DB 인스턴스 스토리지 부족사용 가능한 DB 인스턴스 부족RDS 여유 메모리 부족 문제MySQL 및 MariaDB 문제백업 보존 기간을 0으로 설정할 수 없음

Amazon RDS 문제 해결

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

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

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 인스턴스를 수정하여 이 작업을 수행할 수 있습니다.

DB 인스턴스 변경에 대한 자세한 내용은 Amazon RDS DB 인스턴스 수정 단원을 참조하십시오.

Amazon RDS 보안 문제

보안 문제를 방지하려면 사용자 계정에 AWS 계정 루트 사용자 이메일 주소와 암호를 사용하지 마세요. 모범 사례에 따라 루트 사용자로 사용자를 생성하고 이런 사용자를 DB 사용자 계정에 할당하는 것이 좋습니다. 필요한 경우 루트 사용자로 다른 사용자 계정을 만들 수도 있습니다.

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

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

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

호환되지 않는 네트워크 상태 문제 해결

호환되지 않는 네트워크 상태란 데이터베이스 수준에서는 데이터베이스에 계속 액세스할 수 있지만 수정하거나 재부팅할 수는 없는 상태를 의미합니다.

원인

DB 인스턴스의 네트워크가 호환되지 않는 상태는 다음 작업 중 하나로 인해 발생할 수 있습니다.

  • DB 인스턴스 클래스 수정

  • 다중 AZ DB 클러스터 배포를 사용하도록 DB 인스턴스 수정

  • 유지 관리 이벤트로 인한 호스트 교체

  • 대체 DB 인스턴스 시작

  • 스냅샷 백업에서 복원

  • 중지된 DB 인스턴스 시작

해결 방법

start-db-instance 명령 사용

네트워크가 호환되지 않는 상태에 있는 데이터베이스를 수정하려면 다음 지침을 따릅니다.

  1. https://console.aws.amazon.com/rds/ 페이지를 열고 탐색 창에서 데이터베이스를 선택합니다.

  2. 호환되지 않는 네트워크 상태에 있는 DB 인스턴스를 선택하고 연결 및 보안 탭에서 DB 인스턴스 식별자, VPC ID, 서브넷 ID를 메모해 둡니다.

  3. AWS CLI를 사용하여 start-db-instance 명령을 실행합니다. 값은 --db-instance-identifier로 지정합니다.

    참고

    데이터베이스가 호환되지 않는 모드일 때 이 명령을 실행하면 가동 중지 시간이 발생할 수 있습니다.

    start-db-instance 명령을 실행해도 RDS for SQL Server DB 인스턴스에서는 이 문제가 해결되지 않습니다.

명령이 성공적으로 실행되면 데이터베이스 상태가 사용 가능으로 변경됩니다.

데이터베이스가 재시작되는 경우 호환되지 않는 네트워크 상태로 이동하기 전에 DB 인스턴스가 인스턴스에서 마지막 작업을 실행했기 때문일 수 있습니다. 이로 인해 인스턴스가 호환되지 않는 네트워크 상태로 돌아갈 수 있습니다.

start-db-instance 명령이 실패하거나 인스턴스가 호환되지 않는 네트워크 상태로 다시 전환되면 RDS 콘솔에서 데이터베이스 페이지를 열고 데이터베이스를 선택합니다. 로그 및 이벤트 섹션으로 이동합니다. 최근 이벤트 섹션에는 다음으로 수행해야 할 추가 해결 단계가 표시됩니다. 메시지는 다음과 같이 분류됩니다.

  • 내부 리소스 확인: 내부 리소스에 문제가 있을 수 있습니다.

  • DNS 확인: VPC 콘솔에서 VPC의 DNS 확인 및 호스트 이름을 확인합니다.

  • ENI 확인: 데이터베이스의 탄력적 네트워크 인터페이스(ENI)가 없을 수 있습니다.

  • 게이트웨이 확인: 공개적으로 사용 가능한 데이터베이스의 인터넷 게이트웨이는 VPC에 연결되어 있지 않습니다.

  • IP 확인: 서브넷에는 무료 IP 주소가 없습니다.

  • 보안 그룹 확인: 데이터베이스와 연결된 보안 그룹이 없거나 보안 그룹이 유효하지 않습니다.

  • 서브넷 확인: DB 서브넷 그룹에 유효한 서브넷이 없거나 서브넷에 문제가 있습니다.

  • VPC 확인: 데이터베이스와 연결된 VPC가 유효하지 않습니다.

특정 시점으로 복원 수행

데이터베이스가 호환되지 않는 네트워크 상태가 되는 경우에 대비하여 백업(스냅샷 또는 논리적)을 보관하는 것이 좋습니다. 백업 소개 섹션을 참조하세요. 자동 백업을 사용 설정한 경우 데이터베이스에 대한 모든 쓰기를 일시적으로 중지하고 시점 복구를 수행할 수 있습니다.

참고

인스턴스가 호환되지 않는 네트워크 상태가 된 후에는 DB 인스턴스에 액세스하여 논리적 백업을 수행하지 못할 수 있습니다.

자동 백업을 사용 설정하지 않았다면 새 DB 인스턴스를 생성하세요. 그런 다음 AWS Database Migration Service(AWS DMS) 또는 백업 및 복원 도구를 사용하여 데이터를 마이그레이션합니다.

이 방법으로도 문제가 해결되지 않으면 AWS Support로 문의하여 추가 지원을 받으세요.

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

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

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

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

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

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

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

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

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

  • 스토리지 유형을 마그네틱(표준)에서 범용(SSD) 또는 프로비저닝된 IOPS(SSD)로 변경하거나 프로비저닝된 IOPS(SSD) 또는 범용(SSD)에서 마그네틱(표준)으로 변경합니다.

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

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

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

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

DB 인스턴스 작업과 Apply Immediately(즉시 적용) 값 설정이 미치는 효과를 보여주는 표를 보려면 Amazon RDS DB 인스턴스 수정 단원을 참조하십시오.

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

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

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

Amazon RDS DB 인스턴스 스토리지 부족

DB 인스턴스에 스토리지 공간이 부족할 경우 DB 인스턴스를 더 이상 사용하지 못할 수 있습니다. CloudWatch에 게시되는 FreeStorageSpace 지표를 계속 모니터링하여 DB 인스턴스에 충분한 스토리지 여유 공간이 있는지 확인해야 합니다.

데이터베이스 인스턴스의 스토리지가 부족하면 상태가 storage-full로 변경됩니다. 예를 들어, 스토리지를 모두 소진한 DB 인스턴스에 대해 DescribeDBInstances API 작업을 호출하면 다음과 같이 출력됩니다.

aws rds describe-db-instances --db-instance-identifier mydbinstance

DBINSTANCE  mydbinstance  2009-12-22T23:06:11.915Z  db.m5.large  mysql8.0  50  sa
storage-full  mydbinstance.clla4j4jgyph.us-east-1.rds.amazonaws.com  3306
us-east-1b  3
	SECGROUP  default  active
	PARAMGRP  default.mysql8.0  in-sync

이 상황에서 벗어나려면 ModifyDBInstance API 작업이나 다음 AWS CLI 명령을 사용하여 인스턴스에 스토리지 공간을 더 추가하십시오.

대상 LinuxmacOS, 또는Unix:

aws rds modify-db-instance \
    --db-instance-identifier mydbinstance \
    --allocated-storage 60 \
    --apply-immediately

Windows의 경우:

aws rds modify-db-instance ^
    --db-instance-identifier mydbinstance ^
    --allocated-storage 60 ^
    --apply-immediately
DBINSTANCE  mydbinstance  2009-12-22T23:06:11.915Z  db.m5.large  mysql8.0  50  sa
storage-full  mydbinstance.clla4j4jgyph.us-east-1.rds.amazonaws.com  3306
us-east-1b  3  60
	SECGROUP  default  active
	PARAMGRP  default.mysql8.0  in-sync

이제 DB 인스턴스를 설명할 때 DB 인스턴스의 상태가 modifying으로 변경되어 스토리지가 확장되고 있는 중임을 알 수 있습니다.

aws rds describe-db-instances --db-instance-identifier mydbinstance 
DBINSTANCE  mydbinstance  2009-12-22T23:06:11.915Z  db.m5.large  mysql8.0  50  sa
modifying  mydbinstance.clla4j4jgyph.us-east-1.rds.amazonaws.com
3306  us-east-1b  3  60
	SECGROUP  default  active
	PARAMGRP  default.mysql8.0  in-sync

스토리지 확장이 완료되면 DB 인스턴스 상태가 available로 변경됩니다.

aws rds describe-db-instances --db-instance-identifier mydbinstance 
DBINSTANCE  mydbinstance  2009-12-22T23:06:11.915Z  db.m5.large  mysql8.0  60  sa
available  mydbinstance.clla4j4jgyph.us-east-1.rds.amazonaws.com  3306
us-east-1b  3
	SECGROUP  default  active
	PARAMGRP  default.mysql8.0  in-sync

DescribeEvents 작업을 사용하면 스토리지 공간이 소진될 때 알림을 받을 수 있습니다. 예를 들어, 이 시나리오에서 이러한 작업 후에 DescribeEvents 호출을 실행하면 다음과 같이 출력됩니다.

aws rds describe-events --source-type db-instance --source-identifier mydbinstance 
2009-12-22T23:44:14.374Z  mydbinstance  Allocated storage has been exhausted db-instance
2009-12-23T00:14:02.737Z  mydbinstance  Applying modification to allocated storage db-instance
2009-12-23T00:31:54.764Z  mydbinstance  Finished applying modification to allocated storage

Amazon RDS 사용 가능한 DB 인스턴스 부족

DB 인스턴스를 생성, 시작 또는 수정하려고 시도하면 InsufficientDBInstanceCapacity 오류가 반환될 수 있습니다. DB 스냅샷에서 DB 인스턴스를 복원하려고 시도할 때도 오류가 반환될 수 있습니다. 이 오류가 반환되는 일반적인 원인은 특정 DB 인스턴스 클래스를 요청된 가용 영역에서 사용할 수 없기 때문입니다. 문제 해결을 위해 다음 중 하나를 시도할 수 있습니다.

  • 다른 DB 인스턴스 클래스에서 요청을 재시도합니다.

  • 다른 가용 영역에서 요청을 재시도합니다.

  • 명시적인 가용 영역을 지정하지 않고 요청을 재시도합니다.

Amazon EC2에서 인스턴스 용량 문제를 해결하는 방법은 Amazon Elastic Compute Cloud 사용 설명서의 불충분한 인스턴스 용량을 참조하십시오.

DB 인스턴스 수정에 대한 자세한 내용은 Amazon RDS DB 인스턴스 수정 단원을 참조하세요.

Amazon RDS의 여유 메모리 부족

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

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

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

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

MySQL 및 MariaDB 문제

MySQL 및 MariaDB DB 인스턴스의 문제를 진단하고 수정할 수 있습니다.

최대 MySQL 및 MariaDB 연결 수

RDS for MySQL 또는 RDS for MariaDB DB 인스턴스에 허용되는 최대 연결 수는 DB 인스턴스 클래스에 사용 가능한 메모리의 양에 따라 결정됩니다. 사용 가능한 메모리가 많은 DB 인스턴스 클래스는 가능한 연결 수가 더 많아집니다. DB 인스턴스 클래스에 대한 자세한 내용은 DB 인스턴스 클래스 단원을 참조하십시오.

DB 인스턴스의 연결 제한은 기본적으로 DB 인스턴스 클래스의 최대값으로 설정됩니다. 동시 연결 수를 허용된 최대 연결 수까지 임의의 값으로 제한할 수 있습니다. DB 인스턴스의 파라미터 그룹에서 max_connections 파라미터를 사용합니다. 자세한 내용은 최대 데이터베이스 연결 수 및 Amazon RDS의 파라미터 그룹 단원을 참조하십시오.

다음 쿼리를 실행하여 MySQL 또는 MariaDB DB 인스턴스에 허용되는 최대 연결 수를 검색할 수 있습니다.

SELECT @@max_connections;

다음 쿼리를 실행하여 MySQL 또는 MariaDB DB 인스턴스에 대한 활성 연결 수를 검색할 수 있습니다.

SHOW STATUS WHERE `variable_name` = 'Threads_connected';

메모리 제한에 대한 호환되지 않는 파라미터 상태 진단 및 해결

다음 조건이 충족되는 경우 MariaDB 또는 MySQL DB 인스턴스가 메모리 제한에 대해 파라미터 호환 장애 상태가 될 수 있습니다.

  • DB 인스턴스 상태가 사용 가능일 때 DB 인스턴스가 한 시간에 세 번 이상 또는 하루에 다섯 번 이상 다시 시작됩니다.

  • 유지 관리 작업 또는 모니터링 프로세스에서 DB 인스턴스를 다시 시작할 수 없기 때문에 DB 인스턴스를 다시 시작하려는 시도가 실패합니다.

  • DB 인스턴스의 잠재적인 메모리 사용량이 DB 인스턴스 클래스에 할당된 메모리의 1.2배를 초과합니다.

DB 인스턴스가 1시간에 세 번째로 다시 시작되거나 하루에 다섯 번째로 다시 시작되면 메모리 사용량 검사를 수행합니다. 이 검사에서는 DB 인스턴스의 잠재적인 메모리 사용량을 계산합니다. 이 계산에서 반환되는 값은 다음 값의 합계입니다.

  • 값 1 – 다음 파라미터의 합계입니다.

    • innodb_additional_mem_pool_size

    • innodb_buffer_pool_size

      innodb_buffer_pool_size의 값을 수정할 수 있습니다. 그러나 값이 입력한 내용과 항상 일치하지는 않습니다. 여러 가지 이유로 이 불일치가 발생합니다. 첫째, DB 인스턴스가 마이크로 DB 인스턴스인 경우 기본값을 무시하고 256MB로 설정됩니다. 자세한 내용은 innodb_buffer_pool_size 재정의 단원을 참조하십시오.

      둘째, 호스트 관리자, 엔진, 운영 체제, 커널을 위해 DB 인스턴스에 500MB의 메모리가 예약됩니다.

      마지막으로, 단위로 나누어 innodb_buffer_pool_size가 최적화됩니다. 호스트 관리자는 해당 단위 중 가장 가까운 배수로 반올림합니다. 단위는 innodb_buffer_pool_chunk_size와 innodb_buffer_pool_instances를 곱하여 계산합니다. 자세한 내용은 MySQL 설명서의 Configuring InnoDB Buffer Pool Size를 참조하세요.

      innodb_buffer_pool_instances의 기본값은 innodb_buffer_pool_size가 1GB 미만인 경우를 제외하고 8입니다. innodb_buffer_pool_size가 1GB 미만인 경우 innodb_buffer_pool_instances의 기본값은 1입니다. innodb_buffer_pool_chunk_size의 기본값은 128MB입니다.

    • innodb_log_buffer_size

    • key_buffer_size

    • query_cache_size(MySQL 버전 5.7만 해당)

    • tmp_table_size

  • 값 2 – max_connections 파라미터에 다음 파라미터의 합을 곱한 값입니다.

    • binlog_cache_size

    • join_buffer_size

    • read_buffer_size

    • read_rnd_buffer_size

    • sort_buffer_size

    • thread_stack

  • 값 3 – performance_schema 파라미터가 활성화된 경우 max_connections 파라미터에 429498을 곱합니다.

    performance_schema 파라미터가 비활성화된 경우 이 값은 0입니다.

따라서 계산에서 반환되는 값은 다음과 같습니다.

Value 1 + Value 2 + Value 3

이 값이 DB 인스턴스에 사용되는 DB 인스턴스 클래스에 할당된 메모리의 1.2배를 초과하면 DB 인스턴스가 파라미터 호환 장애 상태가 됩니다. DB 인스턴스 클래스에 할당된 메모리에 대한 자세한 내용은 에 대한 DB 인스턴스 클래스의 하드웨어 사양을 참조하십시오.

이 계산에서는 max_connections 파라미터의 값에 여러 파라미터의 합을 곱합니다. max_connections 파라미터가 큰 값으로 설정되어 있는 경우, 검사에서 DB 인스턴스의 잠재적인 메모리 사용량의 값이 지나치게 높게 반환될 수 있습니다. 이 경우 max_connections 파라미터의 값을 낮추는 것이 좋습니다.

이 문제를 해결하려면 다음 단계를 수행합니다.

  1. DB 인스턴스와 연결된 DB 파라미터 그룹의 메모리 파라미터를 조정합니다. 잠재적인 메모리 사용량이 DB 인스턴스 클래스에 할당된 메모리의 1.2배보다 낮도록 조정합니다.

    파라미터 설정에 대한 자세한 내용은 Amazon RDS에서 DB 파라미터 그룹의 파라미터 수정을 참조하세요.

  2. DB 인스턴스를 다시 시작합니다.

    파라미터 설정에 대한 자세한 내용은 이전에 중지된 Amazon RDS DB 인스턴스 시작을 참조하세요.

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

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

ReplicaLag 지표는 MariaDB 또는 MySQL Seconds_Behind_Master 명령의 SHOW REPLICA STATUS 필드 값을 보고합니다. 자세한 내용은 MySQL 설명서의 SHOW REPLICA STATUS 문을 참조하세요.

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

참고

이전 버전의 MariaDB 및 MySQL에는 SHOW SLAVE STATUS 대신 SHOW REPLICA STATUS가 사용되었습니다. 10.5 이전 MariaDB 버전 또는 8.0.23 이전 MySQL 버전을 사용하는 경우 SHOW SLAVE STATUS를 사용합니다.

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

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

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

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

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

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

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

  • MySQL 또는 MariaDB용 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 또는 MariaDB 읽기 복제 오류 진단 및 해결

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

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

  • 읽기 전용 복제본에 대한 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 설명서의 이진 로깅에서 안전한 문과 안전하지 않은 문 결정을 참조하십시오.

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

  • 논리적 오류가 발생했는데 이 오류를 건너뛰어도 안전할 경우에는 RDS for MySQL에 대한 현재 복제 오류 건너뛰기에 설명되어 있는 단계를 따르십시오. MySQL 또는 MariaDB DB 인스턴스에서는 mysql_rds_skip_repl_error 프로시저를 포함한 버전이 실행 중이어야 합니다. 자세한 내용은 mysql.rds_skip_repl_error 섹션을 참조하세요.

  • 이진 로그(binlog) 위치 문제가 발생하는 경우 mysql_rds_next_master_log 명령으로 복제본 재생 위치를 변경할 수 있습니다. 복제본 재생 위치를 변경하려면 MySQL 또는 MariaDB DB 인스턴스에서 mysql_rds_next_master_log 명령을 지원하는 버전이 실행 중이어야 합니다. 버전 정보는 mysql.rds_next_master_log를 참조하십시오.

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

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

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

이진 로깅이 활성화된 상태에서 트리거를 생성하려면 SUPER 권한 필요

RDS for MySQL 또는 RDS for MariaDB DB 인스턴스에서 트리거 생성을 시도할 때 다음 오류가 발생할 수 있습니다.

"You do not have the SUPER privilege and binary logging is enabled"

이진 로깅이 활성화된 상태에서 트리거를 사용하려면 RDS for MySQL 및 RDS for MariaDB DB 인스턴스로 제한된 SUPER 권한이 필요합니다. log_bin_trust_function_creators 파라미터를 true로 설정하면 SUPER 권한 없이 이진 로깅이 활성화된 상태에서 트리거를 생성할 수 있습니다. log_bin_trust_function_creators를 true로 설정하려면 새 DB 파라미터 그룹을 생성하거나 기존 DB 파라미터 그룹을 수정해야 합니다.

이진 로깅이 활성화된 상태에서 RDS for MySQL 또는 RDS for MariaDB DB 인스턴스에서 트리거를 생성할 수 있도록 새 DB 파라미터 그룹을 생성할 수 있습니다. 그러기 위해서는 다음 CLI 명령을 사용합니다. 기존 파라미터 그룹을 수정하려면 2단계부터 시작합니다.

CLI를 사용하여 이진 로깅이 활성화된 상태에서 트리거를 허용하는 새 파라미터 그룹을 생성하려면

  1. 새 파라미터 그룹을 생성해야 합니다.

    대상 LinuxmacOS, 또는Unix:

    aws rds create-db-parameter-group \
    --db-parameter-group-name allow-triggers \
    --db-parameter-group-family mysql8.0 \
    --description "parameter group allowing triggers"

    Windows의 경우:

    aws rds create-db-parameter-group ^
    --db-parameter-group-name allow-triggers ^
    --db-parameter-group-family mysql8.0 ^
    --description "parameter group allowing triggers"

  2. DB 파라미터 그룹이 트리거를 허용하도록 수정합니다.

    대상 LinuxmacOS, 또는Unix:

    aws rds modify-db-parameter-group \
    --db-parameter-group-name allow-triggers \
    --parameters "ParameterName=log_bin_trust_function_creators, ParameterValue=true, ApplyMethod=pending-reboot"

    Windows의 경우:

    aws rds modify-db-parameter-group ^
    --db-parameter-group-name allow-triggers ^
    --parameters "ParameterName=log_bin_trust_function_creators, ParameterValue=true, ApplyMethod=pending-reboot"

  3. DB 인스턴스가 새 DB 파라미터 그룹을 사용하도록 수정합니다.

    대상 LinuxmacOS, 또는Unix:

    aws rds modify-db-instance \
    --db-instance-identifier mydbinstance \
    --db-parameter-group-name allow-triggers \
    --apply-immediately

    Windows의 경우:

    aws rds modify-db-instance ^
    --db-instance-identifier mydbinstance ^
    --db-parameter-group-name allow-triggers ^
    --apply-immediately

  4. 변경 사항을 적용하려면 DB 인스턴스를 수동으로 재부팅합니다.

    aws rds reboot-db-instance --db-instance-identifier mydbinstance

특정 시점으로 복원 오류 진단 및 해결

임시 테이블을 포함한 DB 인스턴스 복원

MySQL 또는 MariaDB DB 인스턴스의 특정 시점으로 복원(PITR)을 시도할 때 다음 오류가 발생할 수 있습니다.

Database instance could not be restored because there has been incompatible database activity for restore
functionality. Common examples of incompatible activity include using temporary tables, in-memory tables,
or using MyISAM tables. In this case, use of Temporary table was detected.

PITR은 DB 인스턴스를 특정 시점으로 복원하기 위해 MySQL 또는 MariaDB의 백업 스냅샷과 이진 로그(binlog)에 모두 의존합니다. binlog에서는 임시 테이블 정보를 신뢰할 수 없어 PITR 오류가 발생할 수 있습니다. MySQL 또는 MariaDB DB 인스턴스에서 임시 테이블을 사용하면 백업을 더 자주 수행하여 PITR 오류 발생 가능성을 줄일 수 있습니다. PITR 오류는 임시 테이블 생성과 다음 백업 스냅샷 생성 사이의 시간에 발생할 가능성이 가장 높습니다.

인 메모리 테이블을 포함한 DB 인스턴스 복원

인 메모리 테이블이 있는 데이터베이스를 복원할 때 문제가 발생할 수 있습니다. 인 메모리 테이블은 다시 시작하는 동안 제거됩니다. 따라서 재부팅 후 인 메모리 테이블이 비어 있을 수 있습니다. 인 메모리 테이블을 사용할 때는 다시 시작할 경우에 대비하여 빈 테이블을 처리하기 위한 솔루션을 설계하는 것이 좋습니다. 복제된 DB 인스턴스와 함께 인 메모리 테이블을 사용하는 경우 재시작 후 읽기 전용 복제본을 재생성해야 할 수 있습니다. 읽기 전용 복제본이 재부팅되고 비어 있는 인 메모리 테이블에서 데이터를 복구할 수 없는 경우 이 작업이 필요할 수 있습니다.

백업과 PITR에 대한 자세한 정보는 백업 소개 및 Amazon RDS에서 DB 인스턴스를 지정된 시간으로 복원 단원을 참조하십시오.

복제 중지 오류

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

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

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

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

binlog 보관 시간을 설정하려면 mysql.rds_set_configuration 프로시저를 따르십시오. 'binlog 보관 시간' 구성 파라미터와 DB 클러스터에 binlog 파일을 보관할 시간(최대 720시간(30일))을 함께 지정합니다. 다음 예제에서는 binlog 파일의 보관 기간을 48시간으로 설정합니다.

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

읽기 전용 복제본 만들기 실패 또는 치명적 오류 1236으로 복제 중단

MySQL 또는 MariaDB의 DB 인스턴스에 대한 기본 파라미터 값을 변경한 후 다음과 같은 문제가 발생할 수 있습니다.

  • DB 인스턴스의 읽기 전용 복제본을 생성할 수 없습니다.

  • fatal error 1236로 인해 복제가 실패합니다.

MySQL 및 MariaDB DB 인스턴스에 대한 일부 기본 파라미터 값은 데이터베이스가 ACID를 준수하고 읽기 전용 복제본이 충돌 시 안전한지 확인하는 데 도움이 됩니다. 커밋되기 전에 이진 로그에 트랜잭션을 기록하여 각 커밋이 완전히 동기화되도록 하여 이를 수행합니다. 성능 향상을 위해 이러한 파라미터를 기본값에서 다른 값으로 변경하면 이진 로그에 기록되지 않은 트랜잭션의 경우 복제에 실패할 수 있습니다.

이 문제를 해결하려면 다음 파라미터 값을 설정하십시오.

  • sync_binlog = 1

  • innodb_support_xa = 1

  • innodb_flush_log_at_trx_commit = 1

백업 보존 기간을 0으로 설정할 수 없음

몇 가지 이유로 백업 보존 기간을 0으로 설정해야 할 수 있습니다. 예를 들어 보존 기간을 0으로 설정하면 자동 백업을 즉시 비활성화할 수 있습니다.

경우에 따라 값을 0으로 설정하고 보존 기간이 1에서 35 사이여야 한다는 메시지가 표시될 수 있습니다. 이러한 경우 인스턴스에 대해 읽기 전용 복제본을 설정하지 않았는지 확인합니다. 읽기 전용 복제본에는 읽기 전용 복제본 로그를 관리하기 위한 백업이 필요하므로 보존 기간을 0으로 설정할 수 없습니다.