Amazon RDS Custom의 DB 문제 해결 - Amazon Relational Database Service

Amazon RDS Custom의 DB 문제 해결

Amazon RDS Custom DB 인스턴스의 문제를 해결하는 방법을 알아볼 수 있습니다.

RDS Custom 이벤트 보기

RDS Custom 및 Amazon RDS DB 인스턴스의 이벤트 보기 절차는 동일합니다. 자세한 내용은 Amazon RDS 이벤트 보기 섹션을 참조하세요.

describe-events 명령을 사용하여 AWS CLI를 통해 RDS Custom 이벤트 알림을 볼 수 있습니다. RDS Custom에서는 몇 가지 새로운 이벤트가 도입되었습니다. 이벤트 카테고리는 Amazon RDS와 동일합니다. 이벤트 목록은 Amazon RDS 이벤트 범주 및 이벤트 메시지 섹션을 참조하세요.

다음 예제에서는 지정된 RDS Custom DB 인스턴스에 대해 발생한 이벤트의 세부 정보를 검색합니다.

aws rds describe-events \ --source-identifier my-custom-instance \ --source-type db-instance

이벤트 알림 구독

RDS Custom 및 Amazon RDS DB 인스턴스의 이벤트 구독 절차는 동일합니다. 자세한 내용은 Amazon RDS 이벤트 알림 구독 섹션을 참조하세요.

CLI를 사용하여 RDS Custom 이벤트 알림을 구독하려면 create-event-subscription 명령을 사용하면 되며, 다음 필수 파라미터를 포함합니다.

  • --subscription-name

  • --sns-topic-arn

다음 예제에서는 현재 AWS 계정에서 RDS Custom DB 인스턴스의 백업 및 복구 이벤트에 대한 구독을 생성합니다. 알림은 --sns-topic-arn에서 지정한 Amazon Simple Notification Service(Amazon SNS) 주제로 전송됩니다.

aws rds create-event-subscription \ --subscription-name my-instance-events \ --source-type db-instance \ --event-categories '["backup","recovery"]' \ --sns-topic-arn arn:aws:sns:us-east-1:123456789012:interesting-events

Oracle용 RDS Custom에 대한 사용자 지정 엔진 버전 생성 문제 해결

CEV 생성이 실패하면 RDS Custom에서 Creation failed for custom engine version major-engine-version.cev_name 메시지와 함께 RDS-EVENT-0198 오류가 발생하며, 실패 관련 세부 정보가 표시됩니다. 예를 들어, 이벤트는 누락된 파일을 인쇄합니다.

다음 문제로 인해 CEV 생성에 실패할 수 있습니다.

  • 설치 파일이 포함된 Amazon S3 버킷이 CEV와 동일한 AWS 리전에 있지 않습니다.

  • AWS 리전에서 CEV 생성을 처음으로 요청하면 RDS Custom이 CEV 아티팩트, AWS CloudTrail 로그 및 트랜잭션 로그와 같은 RDS Custom 리소스를 저장하기 위한 S3 버킷을 생성합니다.

    RDS Custom에서 S3 버킷을 생성할 수 없는 경우 CEV 생성에 실패합니다. 발신자에게 IAM 사용자에게 필요한 권한 부여에 설명된 대로 S3 사용 권한이 없거나 S3 버킷 수가 한도에 도달한 것일 수 있습니다.

  • 발신자에게 설치 미디어 파일이 포함된 S3 버킷에서 파일을 가져올 수 있는 권한이 없습니다. 이러한 권한은 필요한 IAM 권한 추가에 설명되어 있습니다.

  • IAM 정책에 aws:SourceIp 조건이 있습니다. AWS Identity and Access Management 사용 설명서소스 IP를 바탕으로 AWS에 대한 AWS 액세스 거부의 권장 사항을 따라야 합니다. 또한 IAM 사용자에게 필요한 권한 부여에 설명된 S3 권한이 호출자에게 있는지 확인합니다.

  • CEV 매니페스트에 나열된 설치 미디어 파일이 S3 버킷에 없습니다.

  • RDS Custom에서 설치 파일의 SHA-256 체크섬을 알 수 없습니다.

    제공된 파일의 SHA-256 체크섬이 Oracle 웹 사이트의 SHA-256 체크섬과 일치하는지 확인해야 합니다. 체크섬이 일치하는 경우 AWS 지원팀에 문의하여 실패한 CEV 이름, 파일 이름 및 체크섬을 제공합니다.

  • OPatch 버전이 패치 파일과 호환되지 않습니다. 다음과 같은 메시지가 표시될 수 있습니다. OPatch is lower than minimum required version. Check that the version meets the requirements for all patches, and try again. Oracle 패치를 적용하려면 호환되는 버전의 OPatch 유틸리티를 사용해야 합니다. 패치의 추가 정보 파일에서 필요한 Opatch 유틸리티의 버전을 찾을 수 있습니다. My Oracle 지원에서 최신 OPatch 유틸리티를 다운로드하고 CEV를 다시 생성해 보세요.

  • CEV 매니페스트에 지정된 패치의 순서가 잘못되었습니다.

RDS 이벤트는 RDS 콘솔(탐색 창에서 이벤트(Events) 선택)에서 보거나 describe-events AWS CLI 명령을 사용하여 볼 수 있습니다. 기본 지속 시간은 60분입니다. 이벤트가 반환되지 않으면 다음 예제와 같이 기간이 더 길게 지정됩니다.

aws rds describe-events --duration 360

현재 Amazon S3에서 파일을 가져와 CEV를 생성하는 MediaImport 서비스가 AWS CloudTrail에 통합되어 있지 않습니다. 이로 인해 CloudTrail에서 Amazon RDS에 대한 데이터 로깅을 설정하면 CreateCustomDbEngineVersion 이벤트와 같이 MediaImport 서비스에 대한 호출이 로깅되지 않습니다.

단, Amazon S3 버킷에 액세스하는 API 게이트웨이에서의 호출은 확인할 수 있습니다. 이러한 호출은 CreateCustomDbEngineVersion 이벤트의 MediaImport 서비스에서 전송됩니다.

RDS Custom 지원 경계 및 미지원 구성

RDS Custom은 지원 경계라는 모니터링 기능을 제공합니다. 지원 경계는 RDS Custom 인스턴스가 지원되는 AWS 인프라, 운영 체제 및 데이터베이스를 사용하도록 보장합니다.

지원 경계는 지원되지 않는 구성 수정에 나열된 요구 사항이 충족되었는지 확인합니다. RDS Custom은 이러한 요구 사항 중 하나라도 충족되지 않으면 DB 인스턴스가 지원 경계를 벗어난 것으로 간주합니다. 그런 다음 RDS Custom은 DB 인스턴스 상태를 unsupported-configuration으로 변경하고 이벤트 알림을 전송합니다. 구성 문제가 수정되면 RDS Custom은 DB 인스턴스 상태를 available로 변경합니다.

unsupported-configuration 상태에서 발생하는 상황

DB 인스턴스가 unsupported-configuration 상태일 때 다음과 같은 상황이 발생할 수 있습니다.

  • DB 인스턴스를 수정할 수 없습니다.

  • DB 스냅샷을 생성할 수 없습니다.

  • 자동화된 백업이 생성되지 않습니다.

  • RDS Custom 자동화가 기본 Amazon EC2 인스턴스가 손상된 경우 이를 교체하지 않습니다.

그러나 다음 RDS Custom 자동화는 계속 실행됩니다.

  • RDS Custom 에이전트는 DB 인스턴스를 모니터링하고 추가 변경 사항에 대해 지원 경계에 알림을 보냅니다.

  • 지원 경계는 변함없이 실행되며 DB 인스턴스에 대한 변경 이벤트를 캡처합니다. 여기에는 다음과 같은 두 가지 목적이 있습니다.

    • DB 인스턴스를 unsupported-configuration 상태로 만든 구성을 수정하면 지원 경계에서 DB 인스턴스를 available 상태로 되돌릴 수 있습니다.

    • 지원되지 않는 다른 구성을 생성할 경우 지원 경계에서 해당 구성을 알려 주어 수정할 수 있도록 합니다.

  • 다시 실행 로그는 특정 시점으로 복구(PITR)를 용이하게 하도록 계속해서 아카이브되고 Amazon S3에 업로드됩니다. 단, 다음에 유의해야 합니다.

    • PITR이 새로운 DB 인스턴스로 완전히 복원하는 데 시간이 오래 걸릴 수 있는데, DB 인스턴스가 unsupported-configuration 상태인 동안에는 자동 스냅샷이나 수동 스냅샷을 생성할 수 없기 때문입니다.

      PITR은 인스턴스가 unsupported-configuration 상태로 전환되기 전에 가장 최근에 생성된 스냅샷부터 시작해서 다시 실행 로그를 더 많이 재생해야 합니다.

    • 경우에 따라 다시 실행 로그 업로드 기능에 영향을 주는 변경 사항으로 인해 DB 인스턴스가 unsupported-configuration 상태일 수 있습니다. 이 경우 PITR이 DB 인스턴스를 복원 가능한 가장 빠른 시간으로 복원하지 못할 수 있습니다.

지원되지 않는 구성 수정

RDS Custom DB 인스턴스를 unsupported-configuration 상태로 전환시키는 구성 문제는 사용자가 해결해야 합니다. AWS 인프라와 관련된 문제인 경우 콘솔 또는 AWS CLI를 사용하여 해결할 수 있습니다. 운영 체제 또는 데이터베이스 구성에 문제가 있는 경우 호스트에 로그인하여 해결하면 됩니다.

다음 테이블에 지원 경계에서 보내는 알림 및 해결 방법에 대한 설명이 나와 있습니다. 이러한 알림과 지원 경계는 변경될 수 있습니다.

알림 설명 조치

데이터베이스 상태:

  • EC2 인스턴스 [i-xxxxxxxxxxxxxxxxx]에서 데이터베이스를 수동으로 복구해야 합니다.

  • DB 인스턴스가 재시작됩니다.

지원 경계는 DB 인스턴스 상태를 모니터링하며, 1시간 전과 하루 동안의 재시작 횟수를 모니터링합니다.

인스턴스가 여전히 존재하더라도 인스턴스와 상호 작용할 수 없는 경우 알림이 표시됩니다.

호스트에 로그인하고 데이터베이스 상태를 검사합니다.

ps -eo pid,state,command | grep smon

필요한 경우 DB 인스턴스를 재시작하여 다시 실행합니다. 호스트를 재부팅해야 하는 경우도 있습니다.

다시 시작한 후 RDS Custom 에이전트에서 DB 인스턴스가 더 이상 응답하지 않는 상태가 아님을 감지하면 지원 경계에 DB 인스턴스 상태를 재평가하도록 알립니다.

데이터베이스 아카이브 지연 대상(Oracle용 RDS Custom만 해당):

  • Amazon EC2 인스턴스 [i-xxxxxxxxxxxxxxxxx]에서 모니터링되는 아카이브 지연 대상 데이터베이스 파라미터가 [300]에서 [0]으로 변경되었습니다.

  • 다음 [1] 문제 때문에 RDS Custom 인스턴스가 지원되지 않는 구성을 사용하고 있습니다. (1) Amazon EC2 인스턴스 [i-xxxxxxxxxxxxxxxxx]의 아카이브 지연 대상 데이터베이스 파라미터가 원하는 범위인 {"lowerbound":60,"upperbound":7200}을 벗어났습니다.

지원 경계는 ARCHIVE_LAG_TARGET 데이터베이스 파라미터를 모니터링하여 DB 인스턴스의 가장 빠른 복원 가능 시간이 적절한 범위 내에 있는지 확인합니다.

호스트에 로그인하고 DB 인스턴스에 연결한 다음 ARCHIVE_LAG_TARGET 파라미터를 60~7,200 범위의 값으로 변경합니다.

예를 들어, 다음 SQL 명령을 사용합니다.

alter system set archive_lag_target=300 scope=both;

DB 인스턴스를 30분 안에 사용할 수 있게 됩니다.

데이터베이스 로그 모드(Oracle용 RDS Custom만 해당):

Amazon EC2 인스턴스 [i-xxxxxxxxxxxxxxxxx]에서 모니터링 중인 데이터베이스의 로그 모드가 [ARCHIVELOG]에서 [NOARCHIVELOG]로 변경되었습니다.

DB 인스턴스 로그 모드를 ARCHIVELOG로 설정해야 합니다.

호스트에 로그인하고 DB 인스턴스를 종료합니다. 다음 SQL 명령을 사용할 수 있습니다.

shutdown immediate;

RDS Custom 에이전트가 DB 인스턴스를 다시 시작하고 로그 모드를 ARCHIVELOG로 설정합니다.

DB 인스턴스를 30분 안에 사용할 수 있게 됩니다.

RDS Custom 에이전트 상태(Oracle용 RDS Custom):

EC2 인스턴스 [i-xxxxxxxxxxxxxxxxx]에서 모니터링 중인 RDS Custom 에이전트의 상태가 실행 중(RUNNING)에서 중지됨(STOPPED)으로 변경되었습니다.

RDS Custom 에이전트는 항상 실행 중이어야 합니다. 에이전트는 30초마다 IamAlive 지표를 Amazon CloudWatch에 게시합니다. 지표가 30초 동안 게시되지 않은 경우 경보가 트리거됩니다.

또한, 지원 경계는 호스트의 RDS Custom 에이전트 프로세스 상태를 30분마다 모니터링합니다.

Oracle용 RDS Custom에서 DB 인스턴스는 RDS Custom 에이전트가 중지되면 지원 경계를 벗어나게 됩니다.

호스트에 로그인하고 RDS Custom 에이전트가 실행 중인지 확인합니다.

다음 명령을 사용하여 에이전트 상태를 찾을 수 있습니다.

ps -ef | grep RDSCustomAgent
pgrep java

RDS Custom 에이전트가 다시 실행되면 IamAlive 지표가 Amazon CloudWatch에 게시되고 경보가 OK 상태로 전환됩니다. 이 스위치는 지원 경계에 에이전트가 실행 중임을 알립니다.

RDS Custom 에이전트 상태(SQL Server용 RDS Custom):

RDS Custom 에이전트에 지원되지 않는 구성이 사용되었기 때문에 RDS Custom 인스턴스가 경계를 벗어납니다.

RDS Custom 에이전트는 항상 실행 중이어야 합니다.

지원 경계는 호스트의 RDS Custom 에이전트 프로세스 상태를 1분마다 모니터링합니다.

SQL Server용 RDS Custom에서는 중지된 에이전트가 모니터링 서비스에 의해 복구됩니다. DB 인스턴스는 RDS Custom 에이전트가 제거되면 지원 경계를 벗어나게 됩니다.

호스트에 로그인하고 RDS Custom 에이전트가 실행 중인지 확인합니다.

다음 명령을 사용하여 에이전트 상태를 찾을 수 있습니다.

$name = "RDSCustomAgent" $service = Get-Service $name Write-Host $service.Status

상태가 Running이 아니면 다음 명령을 사용하여 서비스를 시작할 수 있습니다.

Start-Service $name

AWS Systems Manager 에이전트(SSM Agent) 상태(Oracle용 RDS Custom):

EC2 인스턴스 [i-xxxxxxxxxxxxxxxxx]의 AWS Systems Manager 에이전트에 현재 연결할 수 없습니다. 네트워크, 에이전트 및 IAM 권한을 올바르게 구성했는지 확인합니다.

SSM Agent는 항상 실행 중이어야 합니다. RDS Custom 에이전트는 Systems Manager 에이전트가 실행 중인지 확인하는 역할을 합니다.

SSM Agent가 다운되고 다시 시작된 경우 RDS Custom 에이전트는 CloudWatch에 지표를 게시합니다. RDS Custom 에이전트에는 이전 3분 동안 재시작된 경우 경보가 트리거되도록 설정된 지표 경보가 지정되어 있습니다.

또한, 지원 경계는 호스트의 SSM Agent 프로세스 상태를 30분마다 모니터링합니다.

자세한 내용은 SSM Agent 문제 해결을 참조하세요.

SSM Agent가 다시 실행되면 경보가 OK 상태로 전환됩니다. 이 스위치는 지원 경계에 에이전트가 실행 중임을 알립니다.

SSM Agent 상태(SQL Server용 RDS Custom):

SSM Agent에 지원되지 않는 구성이 사용되었기 때문에 RDS Custom 인스턴스가 경계를 벗어납니다.

SSM Agent는 항상 실행 중이어야 합니다. RDS Custom 에이전트는 Systems Manager 에이전트가 실행 중인지 확인하는 역할을 합니다.

지원 경계는 호스트의 SSM Agent 프로세스 상태를 1분마다 모니터링합니다.

자세한 내용은 SSM Agent 문제 해결을 참조하세요.

sudo 구성(Oracle용 RDS Custom만 해당):

EC2 인스턴스 [i-xxxxxxxxxxxxxxxxx]의 sudo 구성이 변경되었습니다.

지원 경계는 특정 OS 사용자가 상자에서 특정 명령을 실행할 수 있는지 모니터링합니다. 지원되는 상태를 기준으로 sudo 구성을 모니터링합니다.

sudo 구성이 지원되지 않으면 RDS Custom은 해당 구성을 지원되는 이전 상태로 다시 덮어쓰려고 시도합니다. 성공하면 다음 알림이 전송됩니다.

RDS Custom이 구성을 성공적으로 덮어썼습니다.

덮어쓰기에 실패하면 호스트에 로그인하여 최근 sudo 구성 변경이 지원되지 않는 이유를 확인할 수 있습니다.

다음 명령을 사용할 수 있습니다.

visudo -c -f /etc/sudoers.d/individual_sudo_files

지원 경계에서 지원되는 sudo 구성이 확인되면 30분 이내에 DB 인스턴스를 사용할 수 있습니다.

Amazon Elastic Block Store(Amazon EBS) 볼륨:

Oracle용 RDS Custom:

  • Amazon EBS 볼륨[[vol-01234abcd56789ef0, vol-0def6789abcd01234]]이 Amazon EC2 인스턴스 [i-xxxxxxxxxxxxxxxxx]에 연결됩니다.

  • Amazon EC2 인스턴스 [i-xxxxxxxxxxxxxxxxx]에 연결된 원본 Amazon EBS 볼륨 연결이 해제되었거나 수정되었습니다. RDS Custom 인스턴스에 연결된 초기 EBS 볼륨을 연결하거나 수정할 수 없습니다.

SQL Server용 RDS Custom:

  • EBS 볼륨 메타데이터에 지원되지 않는 구성이 사용되었기 때문에 RDS Custom 인스턴스가 경계를 벗어납니다.

RDS Custom은 Amazon Machine Image(AMI)에서 생성된 루트 볼륨 외에 두 가지 유형의 EBS 볼륨을 생성하여 EC2 인스턴스에 연결합니다.

바이너리 볼륨은 데이터베이스 소프트웨어 바이너리가 있는 곳입니다. 데이터 볼륨은 데이터베이스 파일이 있는 위치입니다. DB 인스턴스를 생성할 때 설정한 스토리지 구성은 데이터 볼륨을 구성하는 데 사용됩니다.

지원 경계는 다음을 모니터링합니다.

  • DB 인스턴스로 생성된 초기 EBS 볼륨이 여전히 연결되어 있습니다.

  • 초기 EBS 볼륨에 스토리지 유형, 크기, 프로비저닝된 IOPS 및 스토리지 처리량 등 초기 설정과 동일한 구성이 그대로 적용되어 있습니다.

  • (Oracle용 RDS Custom만 해당) DB 인스턴스에 연결된 추가 EBS 볼륨이 없습니다.

초기 EBS 볼륨을 분리한 경우 AWS Support에 문의하세요.

EBS 볼륨의 스토리지 유형, 프로비저닝된 IOPS 또는 스토리지 처리량을 수정한 경우 수정 내용을 원래 값으로 되돌립니다.

EBS 볼륨의 스토리지 크기를 수정한 경우 AWS Support에 문의하세요.

(Oracle용 RDS Custom만 해당) 추가 EBS 볼륨을 연결한 경우 다음 중 하나를 수행합니다.

  • RDS Custom DB 인스턴스에서 추가 EBS 볼륨을 분리합니다.

  • AWS Support에 문의하세요.

EBS 최적화 인스턴스(Oracle용 RDS Custom만 해당):

Amazon EC2 인스턴스 [i-xxxxxxxxxxxxxxxxx]의 EBS 최적화 속성이 [활성화됨(enabled)]에서 [비활성화됨(disabled)]으로 변경되었습니다.

Amazon EC2 인스턴스는 EBS에 최적화되어야 합니다.

EBS-optimized 속성이 해제(disabled)되어 있는 경우 지원 경계는 DB 인스턴스를 unsupported-configuration 상태로 전환하지 않습니다.

EBS-optimized 속성을 설정하려면 다음 단계를 수행하세요.

  1. EC2 인스턴스를 중지합니다.

  2. EBS-optimized 속성을 enabled로 설정합니다.

  3. EC2 인스턴스를 시작합니다.

  4. 바이너리 및 데이터 볼륨을 다시 탑재합니다.

Amazon EC2 인스턴스 상태:

  • EC2 인스턴스 [i-xxxxxxxxxxxxxxxxx]의 상태가 [실행 중(RUNNING)]에서 [중지 중(STOPPING)]으로 변경되었습니다.

  • Amazon EC2 인스턴스 [i-xxxxxxxxxxxxxxxxx]가 종료되어 찾을 수 없습니다. 데이터베이스 인스턴스를 삭제하여 리소스를 정리합니다.

  • Amazon EC2 인스턴스 [i-xxxxxxxxxxxxxxxxx]가 중지되었습니다. 인스턴스를 시작하고 호스트 구성을 복원합니다. 자세한 내용은 문제 해결 문서를 참조하세요.

지원 경계는 EC2 인스턴스 상태 변경 알림을 모니터링합니다. EC2 인스턴스는 항상 실행 중이어야 합니다.

EC2 인스턴스가 중지되면 인스턴스를 시작하고 바이너리 및 데이터 볼륨을 다시 탑재합니다.

Oracle용 RDS Custom에서 EC2 인스턴스가 종료된 경우 RDS Custom DB 인스턴스를 삭제합니다.

SQL Server용 RDS Custom에서 EC2 인스턴스가 종료되면 RDS Custom이 자동 복구를 수행하여 새 EC2 인스턴스를 프로비저닝합니다.

Amazon EC2 인스턴스 속성:

Oracle용 RDS Custom:

  • Amazon EC2 인스턴스 [i-xxxxxxxxxxxxxxxxx]의 속성이 변경되었습니다.

SQL Server용 RDS Custom:

  • EC2 인스턴스 메타데이터에 지원되지 않는 구성이 사용되었기 때문에 RDS Custom 인스턴스가 경계를 벗어납니다.

지원 경계는 RDS Custom DB 인스턴스가 실행 중인 EC2 인스턴스의 인스턴스 유형을 모니터링합니다. EC2 인스턴스 유형은 RDS Custom DB 인스턴스를 생성하면서 설정한 유형과 동일하게 유지되어야 합니다.

EC2 콘솔 또는 CLI를 사용하여 EC2 인스턴스 유형을 원래 유형으로 다시 변경합니다.

크기 조정 요구 사항으로 인해 인스턴스 유형을 변경하려면 PITR을 수행하고 새 인스턴스 유형 및 클래스를 지정합니다. 그러나 이렇게 하면 새 호스트 및 도메인 이름 시스템(DNS) 이름을 가진 RDS Custom DB 인스턴스가 새로 생성됩니다.

Oracle Data Guard 역할(Oracle용 RDS Custom만 해당):

  • DB 인스턴스 my-custom-instance의 인스턴스 역할이 변경되었습니다.

  • 데이터베이스 역할 [논리적 대기]는 지원되지 않습니다. Amazon EC2 인스턴스 [i-xxxxxxxxxxxxxxxxx]에서 데이터베이스에 대한 Oracle Data Guard 구성을 검증합니다.

지원 경계는 15초마다 현재 데이터베이스 역할을 모니터링하고 데이터베이스 역할이 변경된 경우 CloudWatch 알림을 보냅니다.

Oracle Data Guard DATABASE_ROLE 파라미터는 PRIMARY 또는 PHYSICAL STANDBY여야 합니다.

Oracle Data Guard 데이터베이스 역할을 지원되는 값으로 복원합니다.

지원 경계에서 데이터베이스 역할이 지원됨을 확인하면 15초 이내에 Oracle DB 인스턴스용 RDS Custom을 사용할 수 있게 됩니다.

공유 메모리 연결(SQL Server용 RDS Custom만 해당):

공유 메모리 프로토콜에 지원되지 않는 구성이 사용되었기 때문에 RDS Custom 인스턴스가 경계를 벗어납니다.

EC2 호스트의 RDS Custom 에이전트는 공유 메모리 프로토콜을 사용하여 SQL Server에 연결됩니다.

이 프로토콜이 해제된 경우(EnabledNo로 설정) RDS Custom은 관리 작업을 수행할 수 없으며, DB 인스턴스를 지원 경계 밖에 배치합니다.

SQL Server DB 인스턴스용 RDS Custom을 지원 경계에 속하도록 되돌리려면 공유 메모리 속성 창의 프로토콜 페이지에서 EnabledYes로 지정하여 공유 메모리 프로토콜을 설정합니다.

프로토콜을 활성화한 후 SQL Server를 다시 시작합니다.

데이터베이스 파일 위치(SQL Server용 RDS Custom만 해당):

데이터베이스 파일 위치에 지원되지 않는 구성이 사용되었기 때문에 RDS Custom 인스턴스가 경계를 벗어납니다.

모든 SQL Server 데이터베이스 파일은 기본적으로 D:\rdsdbdata\DATA 디렉터리의 D: 드라이브에 저장됩니다.

데이터베이스 파일 위치를 D: 드라이브가 아닌 다른 위치로 생성하거나 변경하는 경우 RDS Custom은 DB 인스턴스를 지원 경계 외부에 배치합니다.

데이터베이스 파일은 C: 드라이브에 저장하지 않는 것이 좋습니다. 하드웨어 오류와 같은 특정 작업이 발생하면 C: 드라이브의 데이터가 손실될 수 있습니다. C: 드라이브의 스토리지는 EBS 볼륨인 D: 드라이브와 동일한 지속성을 제공하지 않습니다.

데이터베이스 파일을 찾을 수 없는 경우에도 RDS Custom은 DB 인스턴스를 지원 경계 외부에 배치합니다.

모든 SQL Server용 RDS Custom 데이터베이스 파일을 D: 드라이브에 저장합니다.

Amazon RDS Custom이 손상된 호스트를 교체하는 방법

Amazon EC2 호스트가 손상되면 RDS Custom이 호스트를 재부팅하려고 시도합니다. 이 작업이 실패하면 RDS Custom은 Amazon EC2에 포함되어 있는 동일한 중지 및 시작 기능을 사용합니다.

호스트 중지 및 시작

RDS Custom은 사용자 개입 없이 다음 단계를 자동으로 수행합니다.

  1. Amazon EC2 호스트를 중지합니다.

    EC2 인스턴스는 정상적인 종료를 수행하고 실행을 중지합니다. 모든 Amazon EBS 볼륨이 인스턴스에 연결된 상태로 유지되고 해당 데이터도 남습니다. 호스트 컴퓨터의 인스턴스 스토리지 볼륨(RDS Custom에서 지원되지 않음) 또는 RAM에 저장된 모든 데이터가 사라집니다.

    자세한 내용은 Linux 인스턴스용 Amazon EC2 사용 설명서인스턴스 중지 및 시작을 참조하세요.

  2. Amazon EC2 호스트를 시작합니다.

    EC2 인스턴스는 새로운 기본 호스트 하드웨어로 마이그레이션됩니다. 경우에 따라 RDS Custom DB 인스턴스가 원래 호스트에 남아 있기도 합니다.

호스트 교체의 영향

RDS Custom에서는 루트 디바이스 볼륨 및 Amazon EBS 스토리지 볼륨을 완벽하게 제어할 수 있습니다. 루트 볼륨에는 유실되어서는 안 될 중요한 데이터 및 구성이 포함될 수 있습니다.

Oracle용 RDS Custom은 루트 볼륨 데이터를 포함한 모든 데이터베이스 및 고객 데이터를 작업 후에도 유지합니다. 따라서 사용자가 별다른 조치를 취할 필요가 없습니다. SQL Server용 RDS Custom에서 데이터베이스 데이터는 유지되지만, 운영 체제 및 고객 데이터를 포함한 C: 드라이브의 모든 데이터는 손실됩니다.

교체 프로세스가 끝나면 Amazon EC2 호스트가 새로운 퍼블릭 IP 주소를 갖게 됩니다. 호스트는 다음을 유지합니다.

  • 인스턴스 ID

  • 프라이빗 IP 주소

  • 탄력적 IP 주소

  • 인스턴스 메타데이터

  • 데이터 스토리지 볼륨 데이터

  • Oracle용 RDS Custom의 루트 볼륨 데이터

Amazon EC2 호스트 모범 사례

Amazon EC2 호스트 교체 기능은 Amazon EC2가 손상되는 대부분의 상황에서 사용할 수 있습니다. 다음 모범 사례를 따르는 것이 좋습니다.

  • 구성 또는 운영 체제를 변경하기 전에 데이터를 백업합니다. 루트 볼륨 또는 운영 체제가 손상되면 호스트 교체로 복구할 수 없습니다. 이 경우 유일한 옵션은 DB 스냅샷 또는 특정 시점으로 복구에서 복원하는 것입니다.

  • 물리적 Amazon EC2 호스트를 수동으로 중지하거나 종료하지 마세요. 이렇게 하면 인스턴스가 RDS Custom 지원 경계 밖에 배치됩니다.

  • (RDS Custom for SQL Server) 추가 볼륨을 Amazon EC2 호스트에 연결하는 경우 재시작할 때 다시 탑재하도록 구성합니다. 호스트가 손상된 경우 RDS Custom이 호스트를 자동으로 중지하고 시작할 수 있습니다.

Oracle DB 인스턴스용 RDS Custom 업그레이드 문제 해결

RDS Custom의 공동 책임 모델은 OS 셸 수준 액세스 권한과 데이터베이스 관리자 액세스 권한을 제공합니다. RDS Custom은 시스템 계정에서 리소스를 실행하는 Amazon RDS와 달리 계정에서 리소스를 실행합니다. 접근 권한이 높을수록 책임도 커집니다. 따라서 업그레이드 실패와 같은 특정 이벤트가 발생할 경우 사용자가 개입해야 할 수 있습니다.

아래에서 Oracle DB 인스턴스용 RDS Custom DB 업그레이드 중에 사용할 수 있는 몇 가지 중요한 기술, 파일 및 명령을 확인할 수 있습니다.

  • 다음 로그 파일을 검사합니다.

    • 모든 업그레이드 출력 로그 파일은 DB 인스턴스의 /tmp 디렉터리에 보관됩니다.

    • 이러한 로그 파일의 이름은 catupg*.log입니다.

    • 이름이 /tmp/catupgrd0.log로 지정된 기본 출력 파일은 모든 오류와 수행된 단계를 보고합니다.

    • DB 인스턴스의 alert.log 파일은 /rdsdbdata/log/trace 디렉터리에 있습니다. 이 파일을 정기적으로 검사하는 것이 가장 좋습니다.

  • root 디렉터리에서 다음 grep 명령을 실행하여 업그레이드 OS 프로세스를 추적합니다. 이 명령은 로그 파일이 기록되는 위치를 표시하고 업그레이드 프로세스의 상태를 확인합니다.

    ps -aux | grep upg

    다음과 유사하게 출력됩니다.

    root 18884 0.0 0.0 235428 8172 ? S< 17:03 0:00 /usr/bin/sudo -u rdsdb /rdsdbbin/scripts/oracle-control ORCL op_apply_upgrade_sh RDS-UPGRADE/2.upgrade.sh rdsdb 18886 0.0 0.0 153968 12164 ? S< 17:03 0:00 /usr/bin/perl -T -w /rdsdbbin/scripts/oracle-control ORCL op_apply_upgrade_sh RDS-UPGRADE/2.upgrade.sh rdsdb 18887 0.0 0.0 113196 3032 ? S< 17:03 0:00 /bin/sh /rdsdbbin/oracle/rdbms/admin/RDS-UPGRADE/2.upgrade.sh rdsdb 18900 0.0 0.0 113196 1812 ? S< 17:03 0:00 /bin/sh /rdsdbbin/oracle/rdbms/admin/RDS-UPGRADE/2.upgrade.sh rdsdb 18901 0.1 0.0 167652 20620 ? S< 17:03 0:07 /rdsdbbin/oracle/perl/bin/perl catctl.pl -n 4 -d /rdsdbbin/oracle/rdbms/admin -l /tmp catupgrd.sql root 29944 0.0 0.0 112724 2316 pts/0 S+ 18:43 0:00 grep --color=auto upg
  • 다음 SQL 쿼리를 실행하여 구성 요소의 현재 상태를 확인하고 데이터베이스 버전 및 DB 인스턴스에 설치된 옵션을 찾습니다.

    set linesize 180 column comp_id format a15 column comp_name format a40 trunc column status format a15 trunc select comp_id, comp_name, version, status from dba_registry order by 1;

    다음과 유사하게 출력됩니다.

    COMP_NAME STATUS PROCEDURE ---------------------------------------- -------------------- -------------------------------------------------- Oracle Database Catalog Views VALID DBMS_REGISTRY_SYS.VALIDATE_CATALOG Oracle Database Packages and Types VALID DBMS_REGISTRY_SYS.VALIDATE_CATPROC Oracle Text VALID VALIDATE_CONTEXT Oracle XML Database VALID DBMS_REGXDB.VALIDATEXDB 4 rows selected.
  • 다음 SQL 쿼리를 실행하여 업그레이드 프로세스를 방해할 수 있는 유효하지 않은 객체가 있는지 확인합니다.

    set pages 1000 lines 2000 col OBJECT for a40 Select substr(owner,1,12) owner, substr(object_name,1,30) object, substr(object_type,1,30) type, status, created from dba_objects where status <>'VALID' and owner in ('SYS','SYSTEM','RDSADMIN','XDB');