메뉴
Amazon Relational Database Service
사용 설명서 (API Version 2014-10-31)

문제 해결

다음 섹션은 Amazon RDS 관련 문제를 해결하는 데 도움이 될 수 있습니다.

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

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

  • 로컬 방화벽에서 적용되는 액세스 규칙과 인스턴스의 보안 그룹에 있는 DB 인스턴스에 액세스하기 위한 권한을 부여한 수신 IP 주소가 동기화되어 있지 않습니다. 보안 그룹의 수신 규칙에 문제가 있을 가능성이 매우 높습니다. 기본적으로 DB 인스턴스는 액세스를 허용하지 않습니다. 액세스 권한은 보안 그룹을 통해 부여됩니다. 액세스 권한을 부여하려면 상황에 맞는 구체적인 수신 및 송신 규칙으로 자체적인 보안 그룹을 만들어야 합니다. 보안 그룹 설정에 대한 자세한 정보는 보안 그룹을 생성하여 VPC 내부의 DB 인스턴스에 대한 액세스를 제공을(를) 참조하십시오.

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

  • DB 인스턴스가 여전히 생성 중이므로 아직 사용할 수는 없습니다. DB 인스턴스의 크기에 따라, 인스턴스를 사용할 수 있을 때까지 최장 20분까지 걸릴 수 있습니다.

Amazon RDS DB 인스턴스 연결 테스트

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

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

Copy
$nc -zv <DB-instance-endpoint> <port>

예를 들어 다음은 샘플 명령과 반환 값을 나타낸 것입니다.

Copy
$nc -zv postgresql1.c6c8mn7tsdgv0.us-west-2.rds.amazonaws.com 8299 Connection to postgresql1.c6c8mn7tsdgv0.us-west-2.rds.amazonaws.com 8299 port [tcp/vvr-data] succeeded!

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

Copy
C:\>telnet sg-postgresql1.c6c8mntzhgv0.us-west-2.rds.amazonaws.com 819 Connecting To sg-postgresql1.c6c8mntzhgv0.us-west-2.rds.amazonaws.com...Could not open connection to the host, on port 819: Connect failed

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

연결 인증 문제 해결

DB 인스턴스에 연결할 수 있지만 인증 오류가 발생하는 경우 DB 인스턴스에 대한 마스터 사용자 암호를 재설정하고 싶을 수도 있을 것입니다. RDS 인스턴스를 수정하여 재설정할 수 있으며, 자세한 정보는 다음 항목 중 하나을(를) 참조하십시오.

Amazon RDS 보안 문제

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

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

이 오류가 발생하는 이유는 몇 가지가 있습니다. 계정에 권한이 누락되었거나 계정 설정이 올바르지 않을 수 있습니다. 새 계정인 경우 계정이 준비되기까지 충분한 시간이 지나지 않았을 수도 있습니다. 기존 계정이라면 DB 인스턴스 생성과 같은 특정 작업을 수행하기 위한 액세스 정책에 권한이 없을 수 있습니다. 이 문제를 해결하려면 IAM 관리자가 필요한 역할을 해당 계정에 제공해야 합니다. 자세한 정보는 IAM 설명서을(를) 참조하십시오.

DB 인스턴스 소유작 역할 암호 재설정

마스터 암호를 재설정하여 DB 인스턴스에 할당된 권한을 재설정할 수 있습니다. 예를 들어 SQL Server 데이터베이스의 db_owner 역할의 암호를 분실했을 경우 DB 인스턴스 마스터 암호를 수정하여 db_owner 역할 암호를 재설정할 수 있습니다. DB 인스턴스 암호를 변경하면 DB 인스턴스에 다시 액세스할 수 있고, 수정된 db_owner 암호를 사용하여 데이터베이스에 액세스할 수 있으며, 실수로 취소되었을 수 있는 db_owner 역할에 대한 권한을 복원할 수 있습니다. DB 인스턴스 암호는 Amazon RDS 콘솔, AWS CLI 명령인 modify-db-instance 또는 ModifyDBInstance 작업을 사용하여 변경할 수 있습니다. SQL Server DB 인스턴스 변경에 대한 자세한 내용은 Microsoft SQL Server 데이터베이스 엔진 기반 DB 인스턴스의 수정을(를) 참조하십시오.

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

DB 인스턴스가 재부팅될 때, DB 인스턴스가 DB 인스턴스에 대한 액세스를 차단하는 상태에 놓여 있을 때, 그리고 데이터베이스가 다시 시작될 때 DB 인스턴스 중단이 발생할 수 있습니다. DB 인스턴스를 수동으로 재부팅할 때 또는 DB 인스턴스 설정을 변경하고 이 변경 사항을 적용하기 위해 재부팅해야 할 때 재부팅이 이루어질 수 있습니다.  

DB 인스턴스에 대한 설정을 수정할 때 [Apply Immediately] 설정을 사용하여 변경 사항을 적용할 시점을 결정할 수 있습니다. DB 인스턴스 작업과 [Apply Immediately] 값의 설정이 미치는 효과를 보여주는 표를 보려면 Amazon RDS DB 인스턴스 수정 및 Apply Immediately 파라미터 사용을(를) 참조하십시오.  

변경 사항을 적용하려면 재부팅해야 하는 설정을 변경할 때 또는 수동으로 재부팅할 때만 DB 인스턴스가 재부팅됩니다. 설정을 변경하고 변경 사항을 즉시 적용할 것을 요청하는 경우에 재부팅이 수행되거나, DB 인스턴스의 유지 관리 기간 중에 재부팅이 수행될 수 있습니다.

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

  • DB 인스턴스에 대한 백업 보존 기간을 0에서 0이 아닌 값으로 변경하거나 0이 아닌 값에서 0으로 변경하고 [Apply Immediately]를 [true]로 설정할 때

  • DB 인스턴스 클래스를 변경하고 [Apply Immediately]가 [true]로 설정되어 있을 때

  • 스토리지 유형을 [Magnetic (Standard)]에서 [General Purpose (SSD)] 또는 [Provisioned IOPS (SSD)]로 변경하거나 [Provisioned IOPS (SSD)] 또는 [General Purpose (SSD)]에서 [Magnetic (Standard)]으로 변경합니다. 또는 standard에서 PIOPS로 변경합니다.

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

  • DB 인스턴스에 대한 백업 보존 기간을 0에서 0이 아닌 값으로 변경하거나 0이 아닌 값에서 0으로 변경하고 [Apply Immediately]가 [false]로 설정되어 있을 때

  • DB 인스턴스 클래스를 변경하고 [Apply Immediately]가 [false]로 설정되어 있을 때

DB 파라미터 그룹에서 정적 파라미터를 변경할 때, 파라미터 그룹과 연결된 DB 인스턴스를 재부팅해야 변경 사항이 적용됩니다. 변경하려면 수동으로 재부팅해야 합니다. 유지 관리 기간 중에는 DB 인스턴스가 자동으로 재부팅되지 않기 때문입니다.

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

DB 파라미터 그룹에서 파라미터를 변경하지만 변경 사항이 적용되지는 않을 경우 DB 파라미터 그룹과 연결된 DB 인스턴스를 재부팅해야 할 것입니다. 동적 파라미터를 변경할 때는 변경 사항이 즉시 적용되며, 정적 파라미터를 변경할 때는 파라미터 그룹과 연결된 DB 인스턴스를 재부팅해야 변경 사항이 적용됩니다.

RDS 콘솔을 사용하거나 RebootDbInstance API 작업을 명시적으로 호출하여 DB 인스턴스를 재부팅할 수 있습니다(DB 인스턴스가 Multi-AZ deployment에 있는 경우 장애 조치 없음). 정적 파라미터 변경 후 연결된 DB 인스턴스를 재부팅해야 변경 사항이 적용되도록 함으로써, DB 인스턴스 클래스를 변경하거나 스토리지를 확장하기 위해 ModifyDBInstance를 호출하는 것과 같이, API 호출에 영향을 주는 파라미터 구성 오류의 위험을 완화할 수 있습니다. 자세한 내용은 DB 파라미터 그룹의 파라미터 수정을(를) 참조하십시오.

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

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

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

Copy
aws rds describe-db-instances --db-instance-identifier mydbinstance DBINSTANCE mydbinstance 2009-12-22T23:06:11.915Z db.m3.large mysql5.6 50 sa storage-full mydbinstance.clla4j4jgyph.us-east-1.rds.amazonaws.com 3306 us-east-1b 3 SECGROUP default active PARAMGRP default.mysql5.6 in-sync

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

Linux, OS X, Unix의 경우:

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

Windows의 경우:

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

이제는 DB 인스턴스를 설명할 때 DB 인스턴스의 상태가 modifying이 되어 스토리지가 확장되고 있는 중임을 나타내게 됩니다.

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

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

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

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

Copy
aws rds describe-events --source-type db-instance --source-identifier mydbinstance
Copy
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 MySQL 및 MariaDB 문제

인덱스 병합 최적화가 잘못된 결과를 반환

이 문제는 MySQL DB 인스턴스에만 적용됩니다.

인덱스 병합 최적화를 사용하는 쿼리는 MySQL 5.5.37에서 도입한 MySQL 쿼리 최적화 프로그램의 버그로 인해 잘못된 결과를 반환할 수도 있습니다. 복수의 인덱스가 있는 테이블에 대한 쿼리를 생성할 때 최적화 프로그램은 복수의 인덱스에 기반하여 행의 범위를 검사하지만 결과를 올바르게 병합하지는 않습니다. 쿼리 최적화 프로그램 버그에 대한 자세한 내용은 MySQL 버그 데이터베이스의 http://bugs.mysql.com/bug.php?id=72745http://bugs.mysql.com/bug.php?id=68194을(를) 참조하십시오.

예를 들면, 검색 인수가 인덱싱된 열을 참조하는 2개의 인덱스가 있는 테이블에 대한 쿼리를 고려합니다.

Copy
SELECT * FROM table1 WHERE indexed_col1 = 'value1' AND indexed_col2 = 'value2';

이 경우 검색 엔진이 두 인덱스를 모두 검색합니다. 그러나 버그로 인해 병합 결과가 정확하지 않습니다.

이 문제를 해결하려면 다음 중 한 가지 방법을 시도하면 됩니다.

  • MySQL DB 인스턴스용 DB 파라미터 그룹에서 optimizer_switch 파라미터를 index_merge=off로 설정합니다. DB 파라미터 그룹 파라미터 설정에 대한 자세한 내용은 DB 파라미터 그룹 작업을(를) 참조하십시오.

  • MySQL DB 인스턴스를 MySQL 버전 5.6 또는 5.7로 업그레이드합니다. 자세한 내용은 MySQL DB 스냅샷 업그레이드 단원을 참조하십시오.

  • 인스턴스를 업그레이드하거나 optimizer_switch 파라미터를 변경할 수 없는 경우, 쿼리에 대한 인덱스를 명시적으로 확인하여 버그를 해결할 수 있습니다. 예:

    Copy
    SELECT * FROM table1 USE INDEX covering_index WHERE indexed_col1 = 'value1' AND indexed_col2 = 'value2';

자세한 내용은 인덱스 병합 최적화을(를) 참조하십시오.

Read Replica 사이의 지연 문제 진단 및 해결

MySQL 또는 MariaDB 읽기 전용 복제본을 만들고 읽기 전용 복제본을 사용할 수 있게 된 후, Amazon RDS는 우선 읽기 전용 복제본 만들기 작업이 시작된 시간부터 원본 DB 인스턴스에서 변경된 내용을 복제합니다. 이 단계 중에 Read Replica에 대한 복제 지연 시간은 0보다 큽니다. Amazon RDS ReplicaLag 메트릭을 보고 Amazon CloudWatch에서 이 지연 시간을 모니터링할 수 있습니다.

ReplicaLag 측정치는 MySQL 또는 MariaDB SHOW SLAVE STATUS 명령에서 Seconds_Behind_Master 필드 값을 알려줍니다. 자세한 내용은 SHOW SLAVE STATUS을(를) 참조하십시오. ReplicaLag 메트릭이 0에 도달하면 복제본이 원본 DB 인스턴스를 따라잡은 것입니다. ReplicaLag 메트릭이 -1을 반환하는 경우에는 복제가 활성 상태가 아닐 수 있습니다. 복제 오류 문제를 해결하는 방법은 MySQL 또는 MariaDB 읽기 복제 오류 진단 및 해결을(를) 참조하십시오. ReplicaLag 값이 -1이라는 것은 Seconds_Behind_Master 값을 결정할 수 없거나 이 값이 NULL이라는 의미일 수도 있습니다.

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

MySQL 및 MariaDB 읽기 복제 기술은 비동기식이기 때문에, 원본 DB 인스턴스에서 BinLogDiskUsage 측정치와 읽기 전용 복제본에서 ReplicaLag 측정치의 경우 가끔 증가할 것으로 예상할 수 있습니다. 예를 들어 원본 DB 인스턴스에 대해 대량의 쓰기 작업이 동시에 발생할 수 있는 반면, 읽기 전용 복제본에 대한 쓰기 작업은 단일 I/O 스레드를 사용하여 직렬화됩니다. 이로 인해 원본 인스턴스와 읽기 전용 복제본 사이에 지연이 발생할 수 있습니다. 읽기 전용 복제본과 MySQL에 대한 자세한 정보는 MySQL 문서의 Replication Implementation Details을(를) 참조하십시오. 읽기 전용 복제본과 MariaDB에 대한 자세한 정보는 MariaDB 설명서에서 Replication Overview을(를) 참조하십시오.

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

  • 원본 DB 인스턴스의 스토리지 크기에 필적하는 스토리지 크기를 가지도록 읽기 전용 복제본의 DB 인스턴스 클래스를 설정합니다.

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

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

  • 읽기 전용 복제본에서 MySQL용 InnoDB 또는 MariaDB용 XtraDB 버퍼 풀을 워밍합니다. 자주 업데이트되는 작은 테이블 집합이 있고 InnoDB 또는 XtraDB 테이블 스키마를 사용 중이라면 이런 테이블을 읽기 전용 복제본에 덤프합니다. 그러면 데이터베이스 엔진이 디스크에서 해당 테이블의 행을 검사한 다음 버퍼 풀에 캐시하므로, 복제 지연을 줄일 수 있습니다. 다음은 그 한 예입니다.

    Linux, OS X, Unix의 경우:

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

    Windows의 경우:

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

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

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

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

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

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

  • 읽기 전용 복제본에 있는 테이블에 쓰기. 읽기 전용 복제본에서 인덱스를 만들 경우 read_only 파라미터를 0으로 설정하여 인덱스를 만들어야 합니다. 읽기 전용 복제본에 있는 테이블에 데이터를 쓰면 복제가 중단될 수 있습니다.

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

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

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

  • SYSDATE()와 같이 안전하지 않은 비결정적 쿼리 사용. 자세한 내용은 Determination of Safe and Unsafe Statements in Binary Logging을 참조하십시오.

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

  • 논리적 오류가 발생했는데 이 오류를 건너뛰어도 안전할 경우에는 현재 복제 오류 넘어가기에 설명되어 있는 단계를 따르십시오. 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 Statereplicating으로 변경됩니다. 자세한 내용은 MySQL 또는 MariaDB 읽기 전용 복제본의 문제 해결을(를) 참조하십시오.

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

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

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

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

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

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

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

    Linux, OS X, Unix의 경우:

    Copy
    aws rds create-db-parameter-group \ --db-parameter-group-name allow-triggers \ --db-parameter-group-family mysql15.5 \ --description "parameter group allowing triggers"

    Windows의 경우:

    Copy
    aws rds create-db-parameter-group ^ --db-parameter-group-name allow-triggers ^ --db-parameter-group-family mysql15.5 ^ --description "parameter group allowing triggers"
  2. DB 파라미터 그룹이 트리거를 허용하도록 수정합니다.

    Linux, OS X, Unix의 경우:

    Copy
    aws rds modify-db-parameter-group \ --db-parameter-group-name allow-triggers \ --parameters "name=log_bin_trust_function_creators,value=true, method=pending-reboot"

    Windows의 경우:

    Copy
    aws rds modify-db-parameter-group ^ --db-parameter-group-name allow-triggers ^ --parameters "name=log_bin_trust_function_creators,value=true, method=pending-reboot"
  3. DB 인스턴스가 새 DB 파라미터 그룹을 사용하도록 수정합니다.

    Linux, OS X, Unix의 경우:

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

    Windows의 경우:

    Copy
    aws rds modify-db-instance ^ --db-instance-identifier mydbinstance ^ --db-parameter-group-name allow-triggers ^ --apply-immediately
  4. 변경 사항을 적용하려면 DB 인스턴스를 수동으로 재부팅합니다.

    Copy
    aws rds reboot-db-instance mydbinstance

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

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

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

Copy
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에 대한 자세한 정보는 백업 작업DB 인스턴스를 지정된 시간으로 복원을(를) 참조하십시오.

Slave Down 또는 Disabled 오류

mysql.rds_skip_repl_error 명령을 호출하면 다음 오류 메시지가 표시될 수 있습니다. Slave is down or disabled.

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

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

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

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

Copy
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

Amazon Aurora 문제

No Space Left on Device 오류

Amazon Aurora에서 다음과 같은 오류 메시지가 표시될 수 있습니다.

Copy
ERROR 3 (HY000): Error writing file '/rdsdbdata/tmp/XXXXXXXX' (Errcode: 28 - No space left on device)

Amazon Aurora DB 클러스터의 각 DB 인스턴스에서 로컬 SSD 스토리지를 사용하여 세션에 대한 임시 테이블을 저장합니다. 임시 테이블에 대한 이 로컬 스토리지는 Aurora 클러스터 볼륨처럼 자동으로 증가하지 않습니다. 대신 로컬 스토리지의 양이 제한됩니다. DB 클러스터 내의 DB 인스턴스에 대한 DB 인스턴스 클래스를 기반으로 제한됩니다. R3 DB 인스턴스 유형에 대한 로컬 SSD 스토리지 양을 확인하려면 메모리 최적화 R3 인스턴스로 이동하십시오.

워크로드를 수정하여 필요한 임시 스토리지 양을 줄일 수 없는 경우, 로컬 SSD 스토리지가 더 큰 DB 인스턴스 클래스를 사용하도록 DB 인스턴스를 확장할 수 있습니다.

Amazon RDS Oracle GoldenGate 문제

충분한 시간 동안 로그 보존

원본 데이터베이스는 아카이빙된 다시 실행 로그를 보존해야 합니다. 로고 보존 기간은 시간 단위로 지정됩니다. Oracle GoldenGate가 필요에 따라 원본 인스턴스에서 로그를 복구할 수 있도록, 이 기간은 원본 인스턴스의 잠재적 가동 중지 시간이나 통신 또는 네트워킹 문제가 발생할 가능성이 있는 기간보다 길어야 합니다. 로그 보존 기간으로 필요한 절대 최소값은 1시간입니다. 로그 보존을 활성화하지 않거나 보존 값이 너무 작으면 다음 메시지가 표시됩니다.

Copy
2014-03-06 06:17:27 ERROR OGG-00446 error 2 (No such file or directory) opening redo log /rdsdbdata/db/GGTEST3_A/onlinelog/o1_mf_2_9k4bp1n6_.log for sequence 1306Not able to establish initial position for begin time 2014-03-06 06:16:55.

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

SQL Server Management Studio를 사용하여 DB 인스턴스에 연결하는 데 문제가 있을 때, 몇 가지 공통된 원인은 다음과 같습니다.

  • 로컬 방화벽에서 적용되는 액세스 규칙과 인스턴스의 보안 그룹에 있는 DB 인스턴스에 액세스하기 위한 권한을 부여한 IP 주소가 동기화되어 있지 않습니다. Microsoft SQL Server Management Studio와 함께 DB 인스턴스의 엔드포인트와 포트를 사용하는데 연결할 수 없다면 방화벽의 송신 또는 수신 규칙에 문제가 있을 가능성이 큽니다. 액세스 권한을 부여하려면 상황에 맞는 구체적인 수신 및 송신 규칙으로 자체적인 보안 그룹을 만들어야 합니다. 보안 그룹에 대한 자세한 내용은 Amazon RDS 보안 그룹을(를) 참조하십시오.

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

  • DB 인스턴스가 여전히 생성 중이므로 아직 사용할 수는 없습니다. DB 인스턴스의 크기에 따라, 인스턴스를 사용할 수 있을 때까지 최장 20분까지 걸릴 수 있습니다.

지정한 포트를 통해 통신을 송수신할 있는 경우 다음 SQL Server 오류가 있는지 확인하십시오.

  • SQL Server에 대한 연결을 열 수 없음 - Microsoft SQL Server, 오류: 53 – Microsoft SQL Server Management Studio를 사용할 때 서버 이름을 지정할 경우 포트 번호를 포함해야 합니다. 예를 들어 DB 인스턴스의 서버 이름(포트 번호 포함)은 sqlsvr-pdz.c6c8mdfntzgv0.region.rds.amazonaws.com,1433이 되어야 합니다.

  • 대상 컴퓨터에서 연결을 거부했으므로 연결하지 못함 - Microsoft SQL Server, 오류: 10061 – 이 경우에는 DB 인스턴스에 연결했지만 연결이 거부되었습니다. 이 오류는 주로 사용자 이름이나 암호가 잘못되었을 때 발생합니다.

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

PostgreSQL DB 인스턴스에 연결하려 할 때 가장 일반적으로 발생하는 문제는 DB 인스턴스에 할당된 보안 그룹의 액세스 규칙이 잘못된 경우입니다. 기본적으로 DB 인스턴스는 액세스를 허용하지 않습니다. 액세스 권한은 보안 그룹을 통해 부여됩니다. 액세스 권한을 부여하려면 상황에 맞는 구체적인 수신 및 송신 규칙으로 자체적인 보안 그룹을 만들어야 합니다. DB 인스턴스를 위한 보안 그룹을 만드는 자세한 방법은 보안 그룹을 생성하여 VPC 내부의 DB 인스턴스에 대한 액세스를 제공을(를) 참조하십시오.

가장 흔한 오류는 could not connect to server: Connection timed out입니다. 이 오류가 발생할 경우 호스트 이름이 DB 인스턴스 엔드포인트이고 포트 번호가 올바른지 확인하십시오. DB 인스턴스에 할당된 보안 그룹에 로컬 방화벽을 통해 액세스를 허용하는 데 필요한 규칙이 있는지 확인하십시오.