^
--tags Key="AWSRDSCustom",Value="custom-sqlserver"
```
------
## 5단계: RDS Custom for SQL Server DB 인스턴스 생성 또는 수정
디렉터리에서 사용할 RDS Custom for SQL Server DB 인스턴스를 생성하거나 수정합니다. 콘솔, CLI 또는 RDS API를 사용하여 DB 인스턴스를 디렉터리에 연결할 수 있습니다. 이 작업을 다음 중 한 가지 방법으로 수행할 수 있습니다.
+ 콘솔, [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) CLI 명령 또는 [CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) RDS API 작업을 사용하여 새 SQL Server DB 인스턴스를 생성합니다.
지침은 [Amazon RDS DB 인스턴스 생성](USER_CreateDBInstance.md) 섹션을 참조하세요.
+ 콘솔, [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) CLI 명령 또는 [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) RDS API 작업을 사용하여 기존 SQL Server DB 인스턴스를 수정합니다.
지침은 [Amazon RDS DB 인스턴스 수정](Overview.DBInstance.Modifying.md) 섹션을 참조하세요.
+ 콘솔, [restore-db-instance-from-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html) CLI 명령 또는 [RestoreDBInstanceFromDBSnapshot](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html) RDS API 작업을 사용하여 DB 스냅샷에서 SQL Server DB 인스턴스를 복원합니다.
지침은 [DB 인스턴스 복원](USER_RestoreFromSnapshot.md) 섹션을 참조하세요.
+ 콘솔, [restore-db-instance-to-point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html) CLI 명령 또는 [RestoreDBInstanceToPointInTime](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html) RDS API 작업을 사용하여 SQL Server DB 인스턴스를 특정 시점으로 복구합니다.
지침은 [Amazon RDS에서 DB 인스턴스를 지정된 시간으로 복원](USER_PIT.md) 섹션을 참조하세요.
**참고**
RDS Custom for SQL Server 인스턴스가 이미 AD에 수동으로 조인된 경우 [네트워크 구성 포트 규칙](custom-sqlserver-WinAuth.NWConfigPorts.md), [네트워크 검증](custom-sqlserver-WinAuth.NWValidation.md)의 설정을 확인하고 1\$14단계를 완료합니다. 도메인 조인 보안 인증 정보 및 구성이 RDS Custom에 등록되어 CNAME를 모니터링, 등록 및 복구 작업을 수행할 수 있도록 `--domain-fqdn`, `--domain-ou` 및 `--domain-auth-secret-arn`을 AD로 업데이트합니다.
AWS CLI를 사용하는 경우 생성한 도메인 디렉터리를 DB 인스턴스에서 사용하려면 다음과 같은 파라미터가 필요합니다.
+ `--domain-fqdn` 파라미터에는 자체 관리형 AD의 정규화된 도메인 이름을 사용합니다.
+ `--domain-ou` 파라미터에는 자체 관리형 AD에서 만든 OU를 사용합니다.
+ `--domain-auth-secret-arn` 파라미터에는 생성한 **보안 암호 ARN**의 값을 사용합니다.
**중요**
자체 관리형 AD 도메인에 조인하거나 자체 관리형 AD 도메인 또는 AWS Managed Microsoft AD에서 제거하도록 DB 인스턴스를 수정한 경우 변경 사항이 적용되려면 DB 인스턴스를 재부팅해야 합니다. 변경 사항을 즉시 적용하거나 다음 유지 관리 기간까지 기다릴 수 있습니다. **즉시 적용** 옵션을 선택하면 단일 AZ DB 인스턴스에 가동 중단이 발생합니다. 다중 AZ DB 클러스터는 재부팅을 완료하기 전에 장애 조치를 수행합니다. 자세한 내용은 [Amazon RDS DB 인스턴스 수정](Overview.DBInstance.Modifying.md) 섹션을 참조하세요.
다음 CLI 명령은 새 RDS Custom for SQL Server DB 인스턴스를 만들어 자체 관리형 또는 AWS Managed Microsoft AD 도메인에 조인합니다.
대상 LinuxmacOS, 또는Unix:
```
aws rds create-db-instance \
--engine custom-sqlserver-se \
--engine-version 15.00.4312.2.v1 \
--db-instance-identifier my-custom-instance \
--db-instance-class db.m5.large \
--allocated-storage 100 --storage-type io1 --iops 1000 \
--master-username my-master-username \
--master-user-password my-master-password \
--kms-key-id my-RDSCustom-key-id \
--custom-iam-instance-profile AWSRDSCustomInstanceProfileForRdsCustomInstance \
--domain-fqdn "corp.example.com" \
--domain-ou "OU=RDSCustomOU,DC=corp,DC=example,DC=com" \
--domain-auth-secret-arn "arn:aws:secretsmanager:region:account-number:secret:do-not-delete-rds-custom-my-AD-test-secret-123456" \
--db-subnet-group-name my-DB-subnet-grp \
--vpc-security-group-ids my-securitygroup-id \
--no-publicly-accessible \
--backup-retention-period 3 \
--port 8200 \
--region us-west-2 \
--no-multi-az
```
Windows의 경우:
```
aws rds create-db-instance ^
--engine custom-sqlserver-se ^
--engine-version 15.00.4312.2.v1 ^
--db-instance-identifier my-custom-instance ^
--db-instance-class db.m5.large ^
--allocated-storage 100 --storage-type io1 --iops 1000 ^
--master-usernamemy-master-username ^
--master-user-password my-master-password ^
--kms-key-id my-RDSCustom-key-id ^
--custom-iam-instance-profile AWSRDSCustomInstanceProfileForRdsCustomInstance ^
--domain-fqdn "corp.example.com" ^
--domain-ou "OU=RDSCustomOU,DC=corp,DC=example,DC=com" ^
--domain-auth-secret-arn "arn:aws:secretsmanager:region:account-number:secret:do-not-delete-rds-custom-my-AD-test-secret-123456" ^
--db-subnet-group-name my-DB-subnet-grp ^
--vpc-security-group-ids my-securitygroup-id ^
--no-publicly-accessible ^
--backup-retention-period 3 ^
--port 8200 ^
--region us-west-2 ^
--no-multi-az
```
**중요**
AWS Managed Microsoft AD에 대한 NetBIOS가 **corpexample**인 경우 OU 자체로 표시됩니다. 이전에 생성된 새 OU는 중첩 OU로 표시됩니다. AWS Managed Microsoft AD의 경우 `--domain-ou`을 `"OU=RDSCustomOU,OU=corpexample,DC=corp,DC=example,DC=com"`으로 설정합니다.
다음 명령은 Active Directory 도메인을 사용하도록 기존 RDS Custom for SQL Server DB 인스턴스를 수정합니다.
대상 LinuxmacOS, 또는Unix:
```
aws rds modify-db-instance \
--db-instance-identifier my-custom-instance \
--domain-fqdn "corp.example.com" \
--domain-ou "OU=RDSCustomOU,DC=corp,DC=example,DC=com" \
--domain-auth-secret-arn "arn:aws:secretsmanager:region:account-number:secret:do-not-delete-rds-custom-my-AD-test-secret-123456" \
```
Windows의 경우:
```
aws rds modify-db-instance ^
--db-instance-identifier my-custom-instance ^
--domain-fqdn "corp.example.com" ^
--domain-ou "OU=RDSCustomOU,DC=corp,DC=example,DC=com" ^
--domain-auth-secret-arn "arn:aws:secretsmanager:region:account-number:secret:do-not-delete-rds-custom-my-AD-test-secret-123456" ^
```
다음 CLI 명령은 Active Directory 도메인에서 RDS Custom for SQL Server DB 인스턴스를 제거합니다.
대상 LinuxmacOS, 또는Unix:
```
aws rds modify-db-instance \
--db-instance-identifier my-custom-instance \
--disable-domain
```
Windows의 경우:
```
aws rds modify-db-instance ^
--db-instance-identifier my-custom-instance ^
--disable-domain
```
콘솔을 사용하여 인스턴스를 생성하거나 수정할 때 **Microsoft SQL Server Windows 인증 활성화**를 클릭하여 다음 옵션을 확인합니다.
![\[Microsoft SQL Server Windows 인증 디렉터리\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/images/custom-sqs-WinAuth.png)
도메인 FQDN이 도메인 컨트롤러 IP 주소로 확인되고 있는지 확인하는 것은 사용자의 책임입니다. 도메인 컨트롤러 IP가 확인되지 않으면 도메인 조인 작업은 실패하지만 RDS Custom for SQL Server 인스턴스 만들기에 성공합니다. 문제 해결 정보는 [Active Directory 문제 해결](custom-sqlserver-WinAuth.Troubleshoot.md)를 참조하세요.
## 6단계: Windows 인증 SQL Server 로그인 생성
다른 DB 인스턴스의 경우와 같은 방법으로 Amazon RDS 마스터 사용자 보안 인증 정보를 사용하여 SQL Server DB 인스턴스에 연결합니다. DB 인스턴스는 AD 도메인에 조인되므로 SQL Server 로그인 및 사용자를 프로비저닝할 수 있습니다. 이 작업은 AD 도메인의 AD 사용자 및 그룹 유틸리티에서 수행합니다. 데이터베이스 권한은 이러한 Windows 로그인에 부여되거나 취소되는 표준 SQL Server 권한을 통해 관리됩니다.
AD 사용자가 SQL Server로 인증하려면 AD 사용자 또는 사용자가 속한 Active Directory 그룹에 대한 SQL Server Windows 로그인이 있어야 합니다. 세분화된 액세스 제어는 이러한 SQL Server 로그인에 대한 권한을 부여하거나 취소하여 처리합니다. SQL Server 로그인이 없거나 이러한 로그인이 있는 AD 그룹에 속하지 않은 AD 사용자는 SQL Server DB 인스턴스에 액세스할 수 없습니다.
AD SQL Server 로그인을 생성하려면 `ALTER ANY LOGIN` 권한이 필요합니다. 이 권한으로 로그인을 생성하지 않은 경우 SQL Server 인증을 사용하여 DB 인스턴스의 마스터 사용자로 연결하고 마스터 사용자의 맥락에서 AD SQL Server 로그인을 생성합니다.
다음과 같은 데이터 정의 언어(DDL) 명령을 실행하여 AD 사용자 또는 그룹에 대한 SQL Server 로그인을 생성할 수 있습니다.
```
USE [master]
GO
CREATE LOGIN [mydomain\myuser] FROM WINDOWS WITH DEFAULT_DATABASE = [master], DEFAULT_LANGUAGE = [us_english];
GO
```
도메인의 사용자(사람 및 애플리케이션)는 이제 Windows 인증을 사용하여 도메인이 조인된 클라이언트 컴퓨터의 RDS Custom for SQL Server 인스턴스에 연결할 수 있습니다.
## 7단계: Kerberos 또는 NTLM 인증 사용
### RDS 엔드포인트를 사용한 NTLM 인증
각 Amazon RDS DB 인스턴스에는 엔드포인트가 있으며, 각 엔드포인트에는 DB 인스턴스의 DNS 이름과 포트 번호가 있습니다. SQL 클라이언트 애플리케이션을 사용해 DB 인스턴스에 연결하려면 DB 인스턴스에 연결할 수 있는 DNS 이름과 포트 번호가 필요합니다. NTLM 인증을 사용하여 인증하려면 RDS 엔드포인트에 연결해야 합니다.
계획된 데이터베이스 유지 관리 또는 예기치 않은 서비스 중단이 발생할 경우 Amazon RDS가 최신 보조 데이터베이스로 자동으로 장애 조치를 수행하므로 수동 개입 없이 작업을 빠르게 재개할 수 있습니다. 기본 인스턴스 및 보조 인스턴스는 동일한 엔드포인트를 사용합니다. 이 엔드포인트의 물리적 네트워크 주소는 장애 조치 프로세스의 일환으로 보조로 전환됩니다. 장애 조치가 발생하는 경우 애플리케이션을 다시 구성할 필요가 없습니다.
### Kerberos 인증
RDS Custom for SQL Server에 대한 Kerberos 기반 인증을 수행하려면 특정 서비스 보안 주체 이름(SPN)에 연결해야 합니다. 그러나 장애 조치 이벤트 후 애플리케이션이 새 SPN을 인식하지 못할 수 있습니다. 이를 해결하기 위해 RDS Custom for SQL Server는 Kerberos 기반 엔드포인트를 제공합니다.
Kerberos 기반 엔드포인트는 특정 형식을 따릅니다. RDS 엔드포인트가 `rds-instance-name.account-region-hash.aws-region.rds.amazonaws.com`인 경우 해당 Kerberos 기반 엔드포인트는 `rds-instance-name.account-region-hash.aws-region.awsrds.fully qualified domain name (FQDN)`입니다.
예를 들어 RDS 엔드포인트가 `ad-test.cocv6zwtircu.us-east-1.rds.amazonaws.com`이고 도메인 이름이 `corp-ad.company.com`인 경우 Kerberos 기반 엔드포인트는 `ad-test.cocv6zwtircu.us-east-1.awsrds.corp-ad.company.com`입니다.
이 Kerberos 기반 엔드포인트는 기본 SQL Server 인스턴스의 새 SPN을 가리키도록 엔드포인트가 자동으로 업데이트되므로 장애 조치 이벤트 후에도 Kerberos를 사용하여 SQL Server 인스턴스로 인증하는 데 사용할 수 있습니다.
### CNAME 찾기
CNAME를 찾으려면 도메인 컨트롤러에 연결하고 **DNS Manager**를 엽니다. **정방향 조회 영역** 및 FQDN으로 이동합니다.
**awsrds**, **aws-region**, **계정 및 리전별 해시**를 탐색합니다.
RDS Custom EC2 인스턴스를 연결하고 CNAME를 사용하여 로컬에서 데이터베이스에 연결하려고 하면 연결에서 Kerberos 대신 NTLM 인증을 사용합니다.
원격 클라이언트에서 CNAME를 연결한 후 NTLM 연결이 반환되면 필요한 포트가 허용 목록에 있는지 확인합니다.
연결에서 Kerberos를 사용 중인지 확인하려면 다음 쿼리를 실행합니다.
```
SELECT net_transport, auth_scheme
FROM sys.dm_exec_connections
WHERE session_id = @@SSPID;
```
# 도메인에서 DB 인스턴스 관리
콘솔, AWS CLI 또는 Amazon RDS API를 사용하여 DB 인스턴스 및 DB 인스턴스와 도메인과의 관계를 관리할 수 있습니다. 예를 들어, DB 인스턴스를 도메인 내로, 도메인 외부로 또는 도메인 간에 이동할 수 있습니다.
예를 들어 Amazon RDS API를 사용하여 다음을 수행할 수 있습니다.
+ 실패한 멤버십에 대한 도메인 조인을 다시 시도하려면 [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) API 작업을 사용하고 현재 멤버십의 디렉터리 ID를 지정합니다.
+ 멤버십에 대한 IAM 역할 이름을 업데이트하려면 `ModifyDBInstance` API 작업을 사용하고 현재 멤버십의 디렉터리 ID 및 새 IAM 역할을 지정합니다.
+ 도메인에서 DB 인스턴스를 제거하려면 `ModifyDBInstance` API 작업을 사용하고 `none`을 도메인 파라미터로 지정합니다.
+ 한 도메인에서 다른 도메인으로 DB 인스턴스를 이동하려면 `ModifyDBInstance` API 작업을 사용하여 새 도메인의 도메인 식별자를 도메인 파라미터로 지정합니다.
+ 각 DB 인스턴스에 대한 멤버십을 나열하려면 [DescribeDBInstances](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/DescribeDBInstances.html) API 작업을 사용합니다.
## RDS Custom for SQL Server DB 인스턴스 복원 및 Active Directory 도메인에 추가
DB 스냅샷을 복원하거나 SQL Server DB 인스턴스에 대한 특정 시점 복구(PITR)를 수행한 후 Active Directory 도메인에 추가할 수 있습니다. DB 인스턴스가 복원된 후 [5단계: RDS Custom for SQL Server DB 인스턴스 생성 또는 수정](custom-sqlserver-WinAuth.settingUp.md#custom-sqlserver-WinAuth.settingUp.CreateDBInstance)에 설명된 프로세스를 사용하여 DB 인스턴스를 AD 도메인에 추가하도록 인스턴스를 수정합니다.
# 도메인 멤버십 이해
DB 인스턴스를 생성하거나 수정한 경우 해당 인스턴스는 도메인의 구성원이 됩니다. AWS 콘솔은 DB 인스턴스에 대한 도메인 멤버십의 상태를 나타냅니다. DB 인스턴스의 상태는 다음 중 한 가지가 될 수 있습니다.
+ **joined** – 인스턴스가 도메인의 구성원입니다.
+ **joining** – 인스턴스가 도메인 구성원이 되기 위한 과정을 진행하고 있습니다.
+ **pending-join** – 인스턴스 멤버십이 보류 중입니다.
+ **pending-maintenance-join** - AWS에서 다음 예약된 유지 관리 기간 동안 인스턴스를 도메인의 멤버로 만들려고 시도합니다.
+ **pending-removal** – 도메인에서 인스턴스 제거 작업이 보류 중입니다.
+ **pending-maintenance-removal** - AWS에서 다음 예약된 유지 관리 기간 동안 도메인에서 인스턴스를 제거하려고 시도합니다.
+ **failed** – 구성 문제가 발생하여 인스턴스가 도메인에 조인되지 않았습니다. 인스턴스 수정 명령을 다시 실행하기 전에 구성을 확인하고 수정합니다.
+ **removing** – 인스턴스를 도메인에서 제거하고 있습니다.
네트워크 연결 문제 또는 잘못된 IAM 역할로 인해 도메인 구성원 되기 요청이 실패할 수 있습니다. 예를 들어, DB 인스턴스를 생성하거나 기존 인스턴스를 수정하여 DB 인스턴스가 도메인의 멤버가 되려는 시도를 못하게 할 수 있습니다. 이 경우 명령을 다시 실행하여 DB 인스턴스를 생성 또는 수정하거나 새로 생성된 인스턴스를 수정하여 도메인에 조인할 수 있습니다.
# Active Directory 문제 해결
다음은 AD를 설정하거나 수정할 때 발생할 수 있는 문제입니다.
| 오류 코드 | 설명 | 일반적인 원인 | 문제 해결 제안 |
| --- | --- | --- | --- |
| 오류 2/0x2 | 시스템이 지정된 파일을 찾을 수 없습니다. | `—domain-ou` 파라미터로 지정된 조직 단위(OU)의 형식 또는 위치가 잘못되었습니다. AWS Secrets Manager를 통해 지정된 도메인 서비스 계정에는 OU에 가입하는 데 필요한 권한이 없습니다. | `—domain-ou` 파라미터를 검토합니다. 도메인 서비스 계정에 OU에 대한 올바른 권한이 있는지 확인합니다. |
| 오류 5/0x5 | 액세스가 거부되었습니다. | 도메인 서비스 계정에 대한 권한이 잘못 구성되었거나 컴퓨터 계정이 이미 도메인에 있습니다. | 도메인의 도메인 서비스 계정 권한을 검토하고 RDS 컴퓨터 계정이 도메인에 중복되지 않았는지 확인합니다. RDS Custom for SQL Server DB 인스턴스에서 `SELECT @@SERVERNAME`을 실행하여 RDS 컴퓨터 계정의 이름을 확인할 수 있습니다. 다중 AZ를 사용하는 경우 장애 조치를 사용하여 재부팅한 다음 RDS 컴퓨터 계정을 다시 확인합니다. 자세한 내용은 [ DB 인스턴스 재부팅](USER_RebootInstance.md) 단원을 참조하십시오. |
| 오류 87/0x57 | 파라미터가 올바르지 않습니다. | AWS Secrets Manager를 통해 지정된 도메인 서비스 계정에 올바른 권한이 없습니다. 사용자 프로필도 손상되었을 수 있습니다. | 도메인 서비스 계정의 요구 사항을 검토합니다. |
| 오류 234/0xEA | 지정된 조직 단위(OU)가 없습니다. | `—domain-ou` 파라미터로 지정된 OU가 AD에 존재하지 않습니다. | `—domain-ou` 파라미터를 검토하고 지정된 OU가 AD에 있는지 확인합니다. |
| 오류 1326/0x52E | 사용자 이름 또는 암호가 잘못되었습니다. | AWS Secrets Manager에 제공된 도메인 서비스 계정 보안 인증 정보에 알 수 없는 사용자 이름이나 잘못된 암호가 있습니다. AD에서 도메인 계정을 사용하지 않도록 설정할 수도 있습니다. | AWS Secrets Manager에 제공된 보안 인증 정보가 올바르고 Active Directory에서 도메인 계정이 활성화되어 있는지 확인합니다. |
| 오류 1355/0x54B | 지정된 도메인이 존재하지 않거나 해당 주소를 찾을 수 없습니다. | 도메인이 중지되었거나, 지정된 DNS IP 집합에 연결할 수 없거나, 지정된 FQDN에 연결할 수 없습니다. | `—domain-dns-ips` 및 `—domain-fqdn` 파라미터를 검토하여 올바른지 확인합니다. RDS Custom for SQL Server DB 인스턴스의 네트워킹 구성을 검토하고 AD에 연결할 수 있는지 확인합니다. |
| 오류 1722/0x6BA | RPC 서버를 사용할 수 없습니다. | AD 도메인의 RPC 서비스에 연결하는 중 문제가 발생했습니다. 서비스 또는 네트워크 문제일 수 있습니다. | RPC 서비스가 도메인 컨트롤러에서 실행되고 있고 TCP 포트 `135` 및 `49152-65535`에서 RDS Custom for SQL Server DB 인스턴스의 도메인에 연결할 수 있는지 확인합니다. |
| 오류 2224/0x8B0 | 계정이 이미 있습니다. | AD에 추가하려는 컴퓨터 계정이 이미 있습니다. | RDS Custom for SQL Server DB 인스턴스에서 `SELECT @@SERVERNAME`을 실행하여 컴퓨터 계정을 식별한 다음 AD에서 해당 계정을 신중히 제거합니다. |
| 오류 2242/0x8c2 | 이 사용자의 암호가 만료되었습니다. | AWS Secrets Manager를 통해 지정한 도메인 서비스 계정의 암호가 만료되었습니다. | RDS Custom for SQL Server DB 인스턴스를 AD에 가입시키는 데 사용되는 도메인 서비스 계정의 암호를 업데이트합니다. |
# RDS Custom for SQL Server에 대한 다중 AZ 배포 구성 및 관리
RDS Custom for SQL Server에 대한 다중 AZ DB 인스턴스 배포에서 Amazon RDS는 자동으로 서로 다른 가용 영역에 동기식 대기 복제본을 프로비저닝하고 유지합니다. 기본 DB 인스턴스는 가용 영역 전체에서 대기 복제본으로 동기식으로 복제되어 데이터 중복성을 제공합니다.
**중요**
RDS Custom for SQL Server에 대한 다중 AZ 배포는 RDS for SQL Server에 대한 다중 AZ 배포와 다릅니다. RDS for SQL Server에 대한 다중 AZ와 달리, RDS Custom은 사용자의 계정 내에서 실행되는데 이는 권한이 필요하므로 다중 AZ DB 인스턴스를 만들기 전에 RDS Custom for SQL Server의 사전 조건을 설정해야 합니다.
사전 조건을 완료하지 않으면 다중 AZ DB 인스턴스가 실행되지 않거나, 단일 AZ DB 인스턴스로 자동으로 되돌아갈 수 있습니다. 사전 조건에 대한 자세한 내용은 [RDS Custom for SQL Server를 사용한 다중 AZ 배포의 사전 조건](custom-sqlserver-multiaz.prerequisites.md) 단원을 참조하세요.
DB 인스턴스를 고가용성으로 실행하면 계획된 시스템 유지 관리 중 가용성을 높일 수 있습니다. 계획된 데이터베이스 유지 관리 또는 예기치 않은 서비스 중단이 발생할 경우, Amazon RDS가 최신 보조 DB 인스턴스로 자동으로 장애 조치를 수행합니다. 이 기능을 통해 수동 개입 없이 데이터베이스 작업을 빠르게 재개할 수 있습니다. 기본 인스턴스 및 예비 인스턴스는 동일한 엔드포인트를 사용합니다. 이 엔드포인트의 물리적 네트워크 주소는 장애 조치 프로세스의 일환으로 보조 복제본으로 전환됩니다. 장애 조치가 발생하는 경우 애플리케이션을 다시 구성할 필요가 없습니다.
![\[RDS Custom for SQL Server는 다중 AZ를 지원합니다.\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/images/custom-sqlserver-multiaz-architecture.png)
RDS Custom DB 인스턴스 생성 시 다중 AZ를 지정하여 RDS Custom for SQL Server 다중 AZ 배포를 생성할 수 있습니다. 콘솔을 사용하여 DB 인스턴스를 수정하고 다중 AZ 옵션을 지정함으로써 기존 RDS Custom for SQL Server DB 인스턴스를 다중 AZ 배포로 변환할 수 있습니다. 또한, AWS CLI 또는 Amazon RDS API를 사용하여 다중 AZ DB 인스턴스 배포를 지정할 수도 있습니다.
RDS 콘솔에 예비 복제본(보조 AZ)의 가용 영역이 표시됩니다. `describe-db-instances` CLI 명령 또는 `DescribeDBInstances` API 작업을 사용하여 보조 AZ를 찾을 수도 있습니다.
다중 AZ DB 인스턴스 배포를 사용하는 RDS Custom for SQL Server DB 인스턴스는 단일 AZ 배포에 비해 쓰기 및 커밋 대기 시간이 길어질 수 있습니다. 이러한 대기 시간 증가는 DB 인스턴스 간의 동기 데이터 복제로 인해 발생할 수 있습니다. AWS는 가용 영역 간 지연 시간이 짧은 네트워크 연결을 제공하도록 설계되었지만 배포가 예비 복제본으로 장애 조치될 경우 지연 시간이 변경될 수 있습니다.
**참고**
프로덕션 워크로드의 경우 빠르고 일관된 성능을 제공할 수 있도록 프로비저닝된 IOPS(초당 입/출력 작업)와 함께 DB 인스턴스 클래스를 사용하는 것이 좋습니다. DB 인스턴스 클래스에 대한 자세한 내용은 [Amazon RDS Custom for SQL Server 요구 사항 및 제한](custom-reqs-limits-MS.md) 섹션을 참조하세요.
**Topics**
+ [리전 및 버전 사용 가능 여부](#custom-sqlserver-multiaz.regionversion)
+ [RDS Custom for SQL Server를 사용한 다중 AZ 배포의 제한 사항](#custom-sqlserver-multiaz.limitations)
+ [RDS Custom for SQL Server를 사용한 다중 AZ 배포의 사전 조건](custom-sqlserver-multiaz.prerequisites.md)
+ [RDS Custom for SQL Server에 대한 다중 AZ 배포 생성](#custom-sqlserver-multiaz.creating)
+ [RDS Custom for SQL Server 단일 AZ 배포를 다중 AZ 배포로 수정](custom-sqlserver-multiaz.modify-saztomaz.md)
+ [RDS Custom for SQL Server 다중 AZ 배포를 단일 AZ 배포로 수정하려면](custom-sqlserver-multiaz.modify-maztosaz.md)
+ [RDS Custom for SQL Server 다중 AZ 배포에 대한 장애 조치 프로세스](custom-sqlserver-multiaz.failover.md)
## 리전 및 버전 사용 가능 여부
다음과 같은 SQL Server 에디션의 경우 RDS Custom for SQL Server에 대한 다중 AZ 배포가 지원됩니다.
+ SQL Server 2022 및 2019: Enterprise, Standard, Web, Developer Edition
**참고**
RDS Custom for SQL Server의 다중 AZ 배포는 SQL Server 2019 CU8(15.00.4073.23) 이하 버전에서는 지원되지 않습니다.
RDS Custom for SQL Server에 대한 다중 AZ 배포는 RDS Custom for SQL Server를 사용하는 모든 리전에서 사용할 수 있습니다. RDS Custom for SQL Server에 대한 다중 AZ 배포를 리전에서 사용할 수 있는지에 대한 자세한 내용은 [RDS Custom for SQL Server를 지원하는 리전 및 DB 엔진](Concepts.RDS_Fea_Regions_DB-eng.Feature.RDSCustom.md#Concepts.RDS_Fea_Regions_DB-eng.Feature.RDSCustom.sq)를 참조하세요.
## RDS Custom for SQL Server를 사용한 다중 AZ 배포의 제한 사항
RDS Custom for SQL Server를 사용한 다중 AZ 배포에는 다음과 같은 제한 사항이 있습니다.
+ 리전 간 다중 AZ 배포는 지원되지 않습니다.
+ 보조 DB 인스턴스가 데이터베이스 읽기 작업을 허용하도록 구성할 수 없습니다.
+ 다중 AZ 배포와 함께 사용자 지정 엔진 버전(CEV)을 사용할 경우 보조 DB 인스턴스도 동일한 CEV를 사용합니다. 보조 DB 인스턴스는 다른 CEV를 사용할 수 없습니다.
# RDS Custom for SQL Server를 사용한 다중 AZ 배포의 사전 조건
기존 RDS Custom for SQL Server 단일 AZ 배포가 있을 경우, 이 배포를 다중 AZ 배포로 수정하기 전에 다음과 같은 추가 사전 조건이 필요합니다. 사전 조건을 수동으로 완료하거나 제공된 CloudFormation 템플릿을 사용하여 완료하도록 선택할 수 있습니다. 최신 CloudFormation 템플릿에는 단일 AZ 배포와 다중 AZ 배포를 위한 사전 조건이 포함되어 있습니다.
**중요**
설정을 간소화하려면 네트워크 설정 지침에 제공된 최신 CloudFormation 템플릿 파일을 사용하여 사전 조건을 생성하는 것이 좋습니다. 자세한 내용은 [CloudFormation을 사용한 구성](custom-setup-sqlserver.md#custom-setup-sqlserver.cf) 단원을 참조하십시오.
**참고**
기존 RDS Custom for SQL Server 단일 AZ 배포를 다중 AZ 배포로 수정하는 경우 이러한 사전 조건을 완료해야 합니다. 사전 조건을 완료하지 않으면 다중 AZ 설정이 실패합니다. 사전 조건을 완료하려면 [RDS Custom for SQL Server 단일 AZ 배포를 다중 AZ 배포로 수정](custom-sqlserver-multiaz.modify-saztomaz.md)의 단계를 따릅니다.
+ 포트 1120을 허용하도록 RDS 보안 그룹 인바운드 및 아웃바운드 규칙을 업데이트합니다.
+ 프라이빗 네트워크 액세스 제어 목록(ACL)에 DB 인스턴스 VPC의 TCP 포트 `0-65535`를 허용하는 규칙을 추가합니다.
+ RDS Custom for SQL Server DB 인스턴스가 SQS와 통신할 수 있도록 새 Amazon SQS VPC 엔드포인트를 생성합니다.
+ 인스턴스 프로파일 역할에서 SQS 권한을 업데이트합니다.
## RDS Custom for SQL Server에 대한 다중 AZ 배포 생성
RDS Custom for SQL Server 다중 AZ 배포를 생성하려면 [Amazon RDS Custom for SQL Server의 DB 인스턴스 생성 및 연결](custom-creating-sqlserver.md)의 단계를 따릅니다.
**중요**
설정을 간소화하려면 네트워크 설정 지침에 제공된 최신 CloudFormation 템플릿 파일을 사용하는 것이 좋습니다. 자세한 내용은 [CloudFormation을 사용한 구성](custom-setup-sqlserver.md#custom-setup-sqlserver.cf) 단원을 참조하십시오.
다중 AZ 배포 생성을 완료하려면 몇 분 정도 걸립니다.
# RDS Custom for SQL Server 단일 AZ 배포를 다중 AZ 배포로 수정
기존 RDS Custom for SQL Server DB 인스턴스를 단일 AZ 배포에서 다중 AZ 배포로 수정할 수 있습니다. DB 인스턴스를 수정할 경우 Amazon RDS는 여러 가지 작업을 수행합니다.
+ 기본 DB 인스턴스의 스냅샷을 생성합니다.
+ 스냅샷에서 스탠바이 복제본용 새 볼륨을 생성합니다. 이러한 볼륨은 백그라운드에서 초기화되며 데이터가 완전히 초기화된 후에 최대 볼륨 성능이 달성됩니다.
+ 기본 DB 인스턴스와 보조 DB 인스턴스 간의 동기 블록 수준 복제를 활성화합니다.
**중요**
사용량이 가장 많은 기간에는 프로덕션 DB 인스턴스의 RDS Custom for SQL Server DB 인스턴스를 단일 AZ에서 다중 AZ 배포로 수정하지 않는 것이 좋습니다.
AWS는 스냅샷을 사용하여 대기 인스턴스를 생성하면 단일 AZ에서 다중 AZ로 변환할 때 가동 중지 시간을 피할 수 있지만, 다중 AZ로 변환하는 동안과 이후에 성능에 영향을 미칠 수 있습니다. 이는 쓰기 대기 시간에 민감한 워크로드에 상당한 영향을 미칠 수 있습니다. 이 기능을 사용하면 스냅샷에서 대용량 볼륨을 신속하게 복원할 수 있지만, 이 경우 동기식 복제로 인해 I/O 작업의 지연 시간이 증가할 수 있습니다. 이러한 지연 시간은 데이터베이스 성능에 영향을 줄 수 있습니다.
**참고**
2024년 8월 29일 이전에 RDS Custom for SQL Server DB 인스턴스를 생성한 경우 수정하기 전에 최신 마이너 버전으로 패치합니다.
SQL Server 2019 인스턴스의 경우 DB 엔진 버전을 `15.00.4410.1.v1` 이상으로 업그레이드합니다.
SQL Server 2022 인스턴스의 경우 DB 엔진 버전을 `16.00.4150.1.v1` 이상으로 업그레이드합니다.
**Topics**
+ [CloudFormation을 사용하여 단일 AZ를 다중 AZ 배포로 수정하기 위한 사전 조건 구성](#custom-sqlserver-multiaz.modify-saztomaz-prereqs.cf)
+ [단일 AZ를 다중 AZ 배포로 수동으로 수정하기 위한 사전 조건 구성](#custom-sqlserver-multiaz.modify-saztomaz-prereqs.manual)
+ [RDS 콘솔, AWS CLI 또는 RDS API를 사용하여 수정합니다.](#custom-sqlserver-multiaz.modify-saztomaz-afterprereqs)
## CloudFormation을 사용하여 단일 AZ를 다중 AZ 배포로 수정하기 위한 사전 조건 구성
다중 AZ 배포를 사용하려면 사전 조건이 포함된 최신 CloudFormation 템플릿을 적용하거나, 최신 사전 조건을 수동으로 구성해야 합니다. 최신 CloudFormation 사전 조건 템플릿을 이미 적용한 경우에는 이 단계를 건너뛰어도 됩니다.
CloudForma를 사용하여 RDS Custom for SQL Server 다중 AZ 배포를 구성하려면
1. [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/)에서 CloudFormation 콘솔을 엽니다.
1. 스택 생성 마법사를 시작하려면 단일 AZ 배포를 만드는 데 사용했던 기존 스택을 선택하고 **Update**(업데이트)를 선택합니다.
**스택 업데이트** 페이지가 표시됩니다.
1. **사전 조건 - 템플릿 준비**에서 **현재 템플릿 교체**를 선택합니다.
1. **템플릿 지정(Specify template)**에서 다음 작업을 수행합니다.
1. 최신 CloudFormation 템플릿 파일을 다운로드합니다. [custom-sqlserver-onboard.zip](samples/custom-sqlserver-onboard.zip) 링크의 컨텍스트 메뉴(마우스 오른쪽 버튼 클릭)를 열고 **Save Link As**(다른 이름으로 링크 저장)를 선택합니다.
1. `custom-sqlserver-onboard.json` 파일을 컴퓨터에 저장하고 압축을 풉니다.
1. **템플릿 소스**로 **템플릿 파일 업로드**를 선택합니다.
1. **파일 선택(Choose file)**에서 `custom-sqlserver-onboard.json`을 찾아 선택합니다.
1. **다음**을 선택합니다.
**스택 세부 정보 지정(Specify stack details)** 페이지가 나타납니다.
1. 기본 옵션을 유지하려면 **다음(Next)**을 선택합니다.
**고급 옵션** 페이지가 나타납니다.
1. 기본 옵션을 유지하려면 **다음(Next)**을 선택합니다.
1. 기본 옵션을 유지하려면 **다음(Next)**을 선택합니다.
1. **변경 사항 검토** 페이지에서 다음을 수행합니다.
1. **기능**에서 ****이 사용자 지정 이름을 사용하여 CloudFormation이 IAM 리소스를 생성할 수 있음에 동의합니다**** 확인란을 선택합니다.
1. **제출**을 선택합니다.
1. 업데이트가 성공했는지 확인합니다. 작업이 성공하면 `UPDATE_COMPLETE`가 표시됩니다.
업데이트가 실패하면 업데이트 프로세스에 지정된 새 구성이 모두 롤백됩니다. 기존 리소스는 계속 사용할 수 있습니다. 예를 들어 번호가 18과 19인 네트워크 ACL 규칙을 추가했는데 같은 번호로 된 기존 규칙이 있는 경우, 업데이트 시 `Resource handler returned message: "The network acl entry identified by 18 already exists.`라는 오류가 반환됩니다. 이러한 시나리오가 발생하면 18보다 작은 숫자를 사용하도록 기존 ACL 규칙을 수정한 후 업데이트를 다시 시도해볼 수 있습니다.
## 단일 AZ를 다중 AZ 배포로 수동으로 수정하기 위한 사전 조건 구성
**중요**
설정을 간소화하려면 네트워크 설정 지침에 제공된 최신 CloudFormation 템플릿 파일을 사용하는 것이 좋습니다. 자세한 내용은 [CloudFormation을 사용하여 단일 AZ를 다중 AZ 배포로 수정하기 위한 사전 조건 구성](#custom-sqlserver-multiaz.modify-saztomaz-prereqs.cf) 섹션을 참조하세요.
사전 조건을 수동으로 구성하도록 선택한 경우 다음 태스크를 수행합니다.
1. [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/)에서 Amazon VPC 콘솔을 엽니다.
1. **Endpoint**(엔드포인트)를 선택합니다. **엔드포인트 생성**페이지가 나타납니다.
1. **서비스 범주**에서 **AWS 서비스**를 선택합니다.
1. **서비스**에서 *SQS를* 검색합니다.
1. **VPC**에서 RDS Custom for SQL Server DB 인스턴스가 배포된 VPC를 선택합니다.
1. **서브넷**에서 RDS Custom for SQL Server DB 인스턴스가 배포된 서브넷을 선택합니다.
1. **보안 그룹**에서 *-vpc-endpoint-sg* 그룹을 선택합니다.
1. **정책**에서 **사용자 지정**을 선택합니다.
1. 사용자 지정 정책에서 *AWS 파티션*, *리전*, *accountId*, *IAM-Instance-role*을 고유한 값으로 바꿉니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Condition": {
"StringLike": {
"aws:ResourceTag/AWSRDSCustom": "custom-sqlserver"
}
},
"Action": [
"SQS:SendMessage",
"SQS:ReceiveMessage",
"SQS:DeleteMessage",
"SQS:GetQueueUrl"
],
"Resource": "arn:aws:sqs:us-east-1:111122223333:do-not-delete-rds-custom-*",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/{IAM-Instance-role}"
}
}
]
}
```
------
1. Amazon SQS에 액세스할 수 있는 권한으로 **인스턴스 프로파일**을 업데이트합니다. *AWS 파티션*, *리전*, *accountId*를 고유한 값으로 바꿉니다.
```
{
"Sid": "SendMessageToSQSQueue",
"Effect": "Allow",
"Action": [
"SQS:SendMessage",
"SQS:ReceiveMessage",
"SQS:DeleteMessage",
"SQS:GetQueueUrl"
],
"Resource": [
{
"Fn::Sub": "arn:${AWS::Partition}:sqs:${AWS::Region}:${AWS::AccountId}:do-not-delete-rds-custom-*"
}
],
"Condition": {
"StringLike": {
"aws:ResourceTag/AWSRDSCustom": "custom-sqlserver"
}
}
}
>
```
1. 포트 1120을 허용하도록 Amazon RDS 보안 그룹 인바운드 및 아웃바운드 규칙을 업데이트합니다.
1. **보안 그룹**에서 *-rds-custom-instance-sg* 그룹을 선택합니다.
1. **인바운드 규칙**의 경우 소스 *-rds-custom-instance-sg* 그룹의 포트 *1120*을 허용하는 **사용자 지정 TCP** 규칙을 만듭니다.
1. **아웃바운드 규칙**의 경우 대상 *-rds-custom-instance-sg* 그룹의 포트 *1120*을 허용하는 **사용자 지정 TCP** 규칙을 만듭니다.
1. 프라이빗 네트워크 액세스 제어 목록(ACL)에 DB 인스턴스 소스 서브넷의 TCP 포트 `0-65535`를 허용하는 규칙을 추가합니다.
**참고**
**인바운드 규칙** 및 **아웃바운드** 규칙을 생성할 때는 기존의 가장 높은 **규칙 번호**를 기록해 둡니다. 새로 생성하는 규칙의 **규칙 번호** 100보다 작아야 하며 기존 **규칙 번호**와 일치하지 않아야 합니다.
1. **네트워크 ACL**에서 *-private-network-acl* 그룹을 선택합니다.
1. **인바운드 규칙**의 경우 *privatesubnet1* 및 *privatesubnet2*에서 나오는 소스와 함께 TCP 포트 `0-65535`를 허용하는 **모든 TCP** 규칙을 생성합니다.
1. **아웃바운드 규칙**의 경우 대상인 *privatesubnet1* 및 *privatesubnet2*로 향하는 TCP 포트 `0-65535`를 허용하는 **모든 TCP** 규칙을 생성합니다.
## RDS 콘솔, AWS CLI 또는 RDS API를 사용하여 수정합니다.
사전 조건을 완료한 후에는 RDS 콘솔, AWS CLI 또는 RDS API를 사용하여 RDS Custom for SQL Server DB 인스턴스를 단일 AZ에서 다중 AZ 배포로 수정할 수 있습니다.
### 콘솔
**RDS Custom for SQL Server 단일 AZ 배포를 다중 AZ 배포로 수정하려면**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. Amazon RDS 콘솔에서 **데이터베이스**를 선택합니다.
**데이터베이스** 창이 표시됩니다.
1. 수정하려는 RDS Custom for SQL Server DB 인스턴스를 선택합니다.
1. **작업**에서 **다중 AZ 배포로 변환**을 선택합니다.
1. **확인** 페이지에서 **즉시 적용**을 선택하여 변경 사항을 즉시 적용합니다. 이 옵션을 선택하면 다운타임이 발생하지 않지만 성능이 영향을 받을 수 있습니다. 다음 유지 관리 기간에 업데이트를 적용하도록 선택할 수도 있습니다. 자세한 내용은 [수정 예약 설정 사용](USER_ModifyInstance.ApplyImmediately.md) 섹션을 참조하세요.
1. **확인** 페이지에서 **다중 AZ로 변환**을 선택합니다.
### AWS CLI
AWS CLI를 사용하여 다중 AZ DB 인스턴스 배포로 변환하려면 [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) 명령을 호출하고 `--multi-az` 옵션을 설정합니다. DB 인스턴스 식별자와 수정하려는 기타 옵션 값을 지정합니다. 각 옵션에 대한 자세한 내용은 [DB 인스턴스에 대한 설정](USER_ModifyInstance.Settings.md) 섹션을 참조하세요.
**Example**
다음 코드는 `--multi-az` 옵션을 포함하여 `mycustomdbinstance`를 수정합니다. 변경 사항은 `--no-apply-immediately`를 사용하여 다음 유지 관리 기간에 적용됩니다. 변경 사항을 바로 적용하려면 `--apply-immediately`를 사용합니다. 자세한 내용은 [수정 예약 설정 사용](USER_ModifyInstance.ApplyImmediately.md) 섹션을 참조하세요.
대상 LinuxmacOS, 또는Unix:
```
aws rds modify-db-instance \
--db-instance-identifier mycustomdbinstance \
--multi-az \
--no-apply-immediately
```
Windows의 경우:
```
aws rds modify-db-instance ^
--db-instance-identifier mycustomdbinstance ^
--multi-az \ ^
--no-apply-immediately
```
### RDS API
RDS API를 사용하여 다중 AZ DB 인스턴스 배포로 변환하려면 [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) 작업을 호출하고 `MultiAZ` 파라미터를 true로 설정합니다.
# RDS Custom for SQL Server 다중 AZ 배포를 단일 AZ 배포로 수정하려면
기존 RDS Custom for SQL Server DB 인스턴스를 다중 AZ 배포에서 단일 AZ 배포로 수정할 수 있습니다.
## 콘솔
**RDS Custom for SQL Server DB 인스턴스를 다중 AZ 배포에서 단일 AZ 배포로 수정할 수 있습니다.**
1. [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 AWS Management Console에 로그인한 후 Amazon RDS 콘솔을 엽니다.
1. Amazon RDS 콘솔에서 **데이터베이스**를 선택합니다.
**데이터베이스** 창이 표시됩니다.
1. 수정하려는 RDS Custom for SQL Server DB 인스턴스를 선택합니다.
1. **다중 AZ 배포**의 경우 **No**(아니요)를 선택합니다.
1. **확인** 페이지에서 **즉시 적용**을 선택하여 변경 사항을 즉시 적용합니다. 이 옵션을 선택하면 다운타임이 발생하지 않지만 성능이 영향을 받을 수 있습니다. 다음 유지 관리 기간에 업데이트를 적용하도록 선택할 수도 있습니다. 자세한 내용은 [수정 예약 설정 사용](USER_ModifyInstance.ApplyImmediately.md) 단원을 참조하십시오.
1. **확인** 페이지에서 **DB 인스턴스 수정**을 선택합니다.
## AWS CLI
AWS CLI를 사용하여 다중 AZ 배포를 단일 AZ 배포로 수정하려면 [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) 명령을 호출하고 `--no-multi-az` 옵션을 포함합니다. DB 인스턴스 식별자와 수정하려는 기타 옵션 값을 지정합니다. 각 옵션에 대한 자세한 내용은 [DB 인스턴스에 대한 설정](USER_ModifyInstance.Settings.md) 단원을 참조하세요.
**Example**
다음 코드는 `--no-multi-az` 옵션을 포함하여 `mycustomdbinstance`를 수정합니다. 변경 사항은 `--no-apply-immediately`를 사용하여 다음 유지 관리 기간에 적용됩니다. 변경 사항을 바로 적용하려면 `--apply-immediately`를 사용합니다. 자세한 내용은 [수정 예약 설정 사용](USER_ModifyInstance.ApplyImmediately.md) 단원을 참조하십시오.
대상 LinuxmacOS, 또는Unix:
```
aws rds modify-db-instance \
--db-instance-identifier mycustomdbinstance \
--no-multi-az \
--no-apply-immediately
```
Windows의 경우:
```
aws rds modify-db-instance ^
--db-instance-identifier mycustomdbinstance ^
--no-multi-az \ ^
--no-apply-immediately
```
## RDS API
RDS API를 사용하여 다중 AZ 배포를 단일 AZ 배포로 수정하려면 [modify-db-instance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) 작업을 호출하고 `MultiAZ` 파라미터를 `false`로 설정합니다.
# RDS Custom for SQL Server 다중 AZ 배포에 대한 장애 조치 프로세스
계획되거나 계획되지 않은 DB 인스턴스의 운영 중단으로 인해 인프라 장애가 발생한 경우, 다중 AZ를 설정하면 Amazon RDS는 자동으로 다른 가용 영역의 대기 복제본으로 전환됩니다. 장애 조치가 완료되는 데 소요되는 시간은 프라이머리 DB 인스턴스를 사용할 수 없게 된 시점의 데이터베이스 활동 및 기타 조건에 따라 달라집니다. 장애 조치에 소요되는 시간은 일반적으로 60\$1120초입니다. 그러나 트랜잭션의 규모가 크거나 복구 프로세스가 복잡한 경우 장애 조치에 소요되는 시간이 증가할 수 있습니다. 장애 조치가 완료되면 RDS 콘솔에 새 가용 영역이 표시되는 데 시간이 더 걸릴 수 있습니다.
**참고**
장애 조치를 사용하면 DB 인스턴스를 재부팅할 때 장애 조치를 수동으로 강제 적용할 수 있습니다. DB 인스턴스 재부팅에 대한 자세한 내용은 [ DB 인스턴스 재부팅](USER_RebootInstance.md)을 참조하세요.
Amazon RDS는 자동으로 장애 조치를 취하여 관리자의 개입 없이 데이터베이스 작업을 신속하게 재개할 수 있도록 합니다. 다음 표에 설명된 조건 중 하나가 발생하면 기본 DB 인스턴스는 자동으로 예비 복제본으로 전환됩니다. 이 장애 조치 이유는 RDS 이벤트 로그에서 확인할 수 있습니다.
****
| 장애 조치 이유 | 설명 |
| --- | --- |
| `The operating system for the RDS Custom for SQL Server Multi-AZ DB instance is being patched in an offline operation` | OS 패치 또는 보안 업데이트를 위한 유지 관리 기간 동안 장애 조치가 트리거되었습니다. 자세한 내용은 [DB 인스턴스 유지 관리](USER_UpgradeDBInstance.Maintenance.md) 단원을 참조하십시오. |
| `The primary host of the RDS Custom for SQL Server Multi-AZ DB instance is unhealthy.` | 다중 AZ DB 인스턴스 배포에서 손상된 프라이머리 DB 인스턴스를 감지하여 장애 조치를 수행했습니다. |
| `The primary host of the RDS Custom for SQL Server Multi-AZ DB instance is unreachable due to loss of network connectivity.` | RDS 모니터링이 기본 DB 인스턴스에 대한 네트워크 연결 실패를 감지하여 장애 조치를 트리거했습니다. |
| `The RDS Custom for SQL Server Multi-AZ DB instance was modified by the customer.` | DB 인스턴스 수정 때문에 장애 조치가 트리거되었습니다. 자세한 내용은 [RDS Custom for SQL Server DB 인스턴스 수정](custom-managing.modify-sqlserver.md) 단원을 참조하십시오. |
| `The storage volume of the primary host of the RDS Custom for SQL Server Multi-AZ DB instance experienced a failure.` | 다중 AZ DB 인스턴스 배포가 프라이머리 DB 인스턴스에서 스토리지 문제를 감지하여 장애 조치를 수행했습니다. |
| `The user requested a failover of the RDS Custom for SQL Server Multi-AZ DB instance.` | RDS Custom for SQL Server 다중 AZ DB 인스턴스가 장애 조치로 인해 재부팅되었습니다. 자세한 내용은 [ DB 인스턴스 재부팅](USER_RebootInstance.md) 단원을 참조하십시오. |
| `The RDS Custom for SQL Server Multi-AZ primary DB instance is busy or unresponsive.` | 기본 DB 인스턴스가 응답하지 않습니다. 다음 단계를 시도하는 것이 좋습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/custom-sqlserver-multiaz.failover.html) |
다음 단계에 따라 다중 AZ DB 인스턴스가 장애 조치를 수행했는지 확인할 수 있습니다.
+ 장애 조치가 시작되었음을 이메일 또는 SMS로 사용자에게 알리도록 DB 이벤트 구독을 설정합니다. 이벤트에 대한 자세한 내용은 [Amazon RDS 이벤트 알림 작업](USER_Events.md) 단원을 참조하세요.
+ RDS 콘솔 또는 API 작업을 사용하여 DB 이벤트를 확인합니다.
+ RDS 콘솔, CLI 또는 API 작업을 사용하여 RDS Custom for SQL Server 다중 AZ DB 인스턴스 배포의 현재 상태를 확인합니다.
## RDS Custom for SQL Server 다중 AZ 배포를 사용하는 애플리케이션의 TTL(Time To Live) 설정
장애 조치 메커니즘은 DB 인스턴스의 Domain Name System(DNS) 레코드가 예비 DB 인스턴스를 가리키도록 자동으로 변경합니다. 그 결과 DB 인스턴스의 기존 연결을 모두 재설정해야 합니다. DNS 캐시 TTL(Time-to-Live) 구성 값이 낮은지 확인하고, 애플리케이션이 오랜 시간 동안 DNS를 캐시하지 않는지 확인합니다. TTL 값이 높으면 장애 조치 후 애플리케이션이 DB 인스턴스에 빠르게 다시 연결되지 않을 수 있습니다.
# Amazon RDS Custom for SQL Server DB 인스턴스 백업 및 복원
Amazon RDS와 마찬가지로 RDS Custom은 백업 보존이 실행되면 RDS Custom for SQL Server DB 인스턴스의 자동 백업을 생성하고 저장합니다. 또한, 수동으로 DB 인스턴스를 백업할 수도 있습니다. 자동 백업은 스냅샷 백업과 트랜잭션 로그 백업으로 구성됩니다. 스냅샷 백업은 지정된 백업 기간 동안 DB 인스턴스의 전체 스토리지 볼륨에 대해 수행됩니다. PITR 대상 데이터베이스의 트랜잭션 로그 백업은 정기적으로 수행됩니다. RDS Custom은 지정한 백업 보존 기간에 따라 DB 인스턴스의 자동 백업을 저장합니다. 자동 백업을 사용하여 DB 인스턴스를 백업 보존 기간 내의 특정 시점으로 복구할 수 있습니다.
스냅샷을 수동으로 백업할 수도 있습니다. 언제든지 이러한 스냅샷 백업에서 새 DB 인스턴스를 생성할 수 있습니다. DB 스냅샷 수동 생성에 대한 자세한 내용은 [RDS Custom for SQL Server 스냅샷 생성](custom-backup-sqlserver.creating.md) 섹션을 참조하세요.
스냅샷 백업은 운영상 전체 백업으로 제공되지만, 증분 스토리지 사용에 대해서만 요금이 청구됩니다. RDS Custom DB 인스턴스의 첫 번째 스냅샷에는 전체 DB 인스턴스의 데이터가 포함되며, 동일한 데이터베이스의 후속 스냅샷은 증분식이며, 마지막 스냅샷 이후 변경된 데이터만 저장됩니다.
**Topics**
+ [RDS Custom for SQL Server 스냅샷 생성](custom-backup-sqlserver.creating.md)
+ [RDS Custom for SQL Server DB 스냅샷에서 복원](custom-backup-sqlserver.restoring.md)
+ [RDS Custom for SQL Server 인스턴스를 특정 시점으로 복원](custom-backup.pitr-sqs.md)
+ [RDS Custom for SQL Server 스냅샷 삭제](custom-backup-sqlserver.deleting.md)
+ [RDS Custom for SQL Server 자동 백업 삭제](custom-backup-sqlserver.deleting-backups.md)
# RDS Custom for SQL Server 스냅샷 생성
RDS Custom for SQL Server는 DB 인스턴스의 스토리지 볼륨 스냅샷을 생성하여 개별 데이터베이스뿐만 아니라 전체 DB 인스턴스를 백업합니다. 스냅샷을 생성할 때 백업할 RDS Custom for SQL Server DB 인스턴스를 지정하고, 나중에 복원할 수 있도록 스냅샷에 이름을 지정합니다.
스냅샷을 생성할 때 RDS Custom for SQL Server는 `(D:)` 볼륨에 대한 Amazon EBS 스냅샷을 생성하며, 이는 DB 인스턴스에 연결된 데이터베이스 볼륨입니다. 스냅샷을 특정 DB 인스턴스에 쉽게 연결할 수 있도록 `DBSnapshotIdentifier`, `DbiResourceId` 및 `VolumeType`으로 태그가 지정됩니다.
DB 스냅샷을 생성하면 I/O가 잠시 중단됩니다. 이러한 일시 중단은 DB 인스턴스의 크기와 클래스에 따라 몇 초에서 몇 분까지 지속될 수 있습니다. 스냅샷 생성 시간은 데이터베이스의 총 수와 크기에 따라 달라집니다. 시점 복구(PITR) 작업에 사용할 수 있는 데이터베이스 수에 대한 자세한 내용은 [인스턴스 클래스 유형별 PITR 대상 데이터베이스 수](custom-backup.pitr-sqs.md#custom-backup.pitr.sqlserver.eligiblecountperinstance) 섹션을 참조하세요.
스냅샷에는 전체 스토리지 볼륨이 포함되므로 임시 파일과 같은 파일의 크기도 스냅샷 생성 시간에 영향을 미칩니다. 스냅샷을 생성하는 방법에 대한 자세한 내용은 [Amazon RDS의 단일 AZ DB 인스턴스에 대한 DB 스냅샷 생성](USER_CreateSnapshot.md) 섹션을 참조하세요.
콘솔 또는 AWS CLI를 사용하여 RDS Custom for SQL Server 스냅샷을 생성할 수 있습니다.
## 콘솔
**RDS Custom 스냅샷을 생성하는 방법**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **Databases**(데이터베이스)를 선택합니다.
1. RDS Custom DB 인스턴스 목록에서 스냅샷을 생성할 인스턴스를 선택합니다.
1. **작업**에서 **스냅샷 만들기**를 선택합니다.
[**DB 스냅샷 생성(Take DB Snapshot)**] 창이 나타납니다.
1. **스냅샷 이름(Snapshot name)**에 스냅샷 이름을 입력합니다.
1. [**스냅샷 생성(Take Snapshot)**]을 선택합니다.
## AWS CLI
[create-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-snapshot.html) AWS CLI 명령을 사용하여 RDS Custom DB 인스턴스의 스냅샷을 생성합니다.
다음과 같은 옵션을 지정할 수 있습니다.
+ `--db-instance-identifier` - 백업할 RDS Custom DB 인스턴스를 식별합니다.
+ `--db-snapshot-identifier` - 나중에 복원할 수 있도록 RDS Custom 스냅샷의 이름을 지정합니다.
이 예제에서는 `my-custom-instance`라는 RDS Custom DB 인스턴스에 대해 *`my-custom-snapshot`*이라는 DB 스냅샷을 생성합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
1. aws rds create-db-snapshot \
2. --db-instance-identifier my-custom-instance \
3. --db-snapshot-identifier my-custom-snapshot
```
Windows의 경우:
```
1. aws rds create-db-snapshot ^
2. --db-instance-identifier my-custom-instance ^
3. --db-snapshot-identifier my-custom-snapshot
```
# RDS Custom for SQL Server DB 스냅샷에서 복원
RDS Custom for SQL Server DB 인스턴스를 복원하는 경우 DB 스냅샷의 이름과 새로운 인스턴스의 이름을 입력합니다. 스냅샷에서 기존 RDS Custom DB 인스턴스로 복원할 수 없습니다. 복원 시 새로운 RDS Custom for SQL Server DB 인스턴스가 생성됩니다.
스냅샷에서 복원하면 스토리지 볼륨이 스냅샷을 생성한 시점으로 복원됩니다. 여기에는 `(D:)` 볼륨에 있던 모든 데이터베이스와 기타 파일이 포함됩니다.
## 콘솔
**DB 스냅샷에서 RDS Custom DB 인스턴스를 복원하는 방법**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 [**Snapshots**]를 선택합니다.
1. 복원 원본으로 사용할 DB 스냅샷을 선택합니다.
1. **작업**에서 **스냅샷 복원**을 선택합니다.
1. **DB 인스턴스 복원(Restore DB instance)** 페이지의 **DB 인스턴스 식별자(DB instance identifier)**에 복원된 RDS Custom DB 인스턴스의 이름을 입력합니다.
1. **DB 인스턴스 복원**을 선택합니다.
## AWS CLI
[ restore-db-instance-from-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html) AWS CLI 명령을 사용하여 RDS Custom DB 스냅샷을 복원합니다.
복원하려는 스냅샷이 프라이빗 DB 인스턴스용인 경우 `db-subnet-group-name` 및 `no-publicly-accessible`을 모두 올바르게 지정해야 합니다. 그렇지 않으면 DB 인스턴스의 기본값에 공개적으로 액세스할 수 있게 됩니다. 다음 옵션이 필요합니다.
+ `db-snapshot-identifier` - 복구할 스냅샷을 식별합니다.
+ `db-instance-identifier` - DB 스냅샷에서 생성할 RDS Custom DB 인스턴스의 이름을 지정합니다.
+ `custom-iam-instance-profile` - RDS Custom for Oracle DB 인스턴스의 기본 Amazon EC2 인스턴스와 연결된 인스턴스 프로필을 지정합니다.
다음 코드는 `my-custom-instance`에 대한 `my-custom-snapshot`이라는 스냅샷을 복원합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
aws rds restore-db-instance-from-db-snapshot \
--db-snapshot-identifier my-custom-snapshot \
--db-instance-identifier my-custom-instance \
--custom-iam-instance-profile AWSRDSCustomInstanceProfileForRdsCustomInstance \
--no-publicly-accessible
```
Windows의 경우:
```
aws rds restore-db-instance-from-db-snapshot ^
--db-snapshot-identifier my-custom-snapshot ^
--db-instance-identifier my-custom-instance ^
--custom-iam-instance-profile AWSRDSCustomInstanceProfileForRdsCustomInstance ^
--no-publicly-accessible
```
# RDS Custom for SQL Server 인스턴스를 특정 시점으로 복원
DB 인스턴스를 특정 시점(PITR)으로 복원하여 새로운 DB 인스턴스를 생성할 수 있습니다. PITR을 지원하려면 DB 인스턴스에 백업 보존 기능이 활성화되어 있어야 합니다.
RDS Custom for SQL Server DB 인스턴스의 가장 빠른 복원 가능 시간은 여러 요소에 따라 달라지지만, 일반적으로 현재 시간에서 5분 이내입니다. DB 인스턴스의 최근 복원 가능 시간을 확인하려면 AWS CLI[describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) 명령을 사용한 후 DB 인스턴스의 `LatestRestorableTime` 필드에 반환되는 값을 살펴봅니다. Amazon RDS 콘솔에서 각 DB 인스턴스의 복원 가능한 최신 시간을 보려면 [ **자동 백업**을 선택합니다.
백업 보존 기간 중 어느 특정 시점으로든 복원할 수 있습니다. 각 DB 인스턴스의 복원 가능한 가장 빠른 시간을 보려면 Amazon RDS 콘솔에서 **자동 백업**을 선택합니다.
PITR에 대한 일반적인 정보는 [Amazon RDS에서 DB 인스턴스를 지정된 시간으로 복원](USER_PIT.md) 섹션을 참조하세요.
**Topics**
+ [RDS Custom for SQL Server에 대한 PITR 고려 사항](#custom-backup.pitr.sqlserver)
+ [인스턴스 클래스 유형별 PITR 대상 데이터베이스 수](#custom-backup.pitr.sqlserver.eligiblecountperinstance)
+ [데이터베이스를 PITR에 포함되지 않도록 설정](#custom-backup.pitr.sqlserver.ineligible)
+ [Amazon S3의 트랜잭션 로그](#custom-backup.pitr.sqlserver.tlogs)
+ [AWS Management Console, AWS CLI 또는 RDS API를 사용하여 PITR 복원합니다.](#custom-backup.pitr-sqs-concli)
## RDS Custom for SQL Server에 대한 PITR 고려 사항
RDS Custom for SQL Server에서 PITR은 다음과 같은 중요한 면에서 Amazon RDS의 PITR과 다릅니다.
+ PITR은 DB 인스턴스의 데이터베이스만 복원합니다. C: 드라이브의 운영 체제 또는 파일은 복원되지 않습니다.
+ RDS Custom for SQL Server DB 인스턴스의 경우 데이터베이스가 자동으로 백업되며 다음 조건에서만 PITR을 사용할 수 있습니다.
+ 데이터베이스가 온라인 상태입니다.
+ 복구 모델이 `FULL`로 설정되어 있습니다.
+ 쓰기가 가능합니다.
+ D: 드라이브에 실존 파일이 있습니다.
+ `rds_pitr_blocked_databases` 테이블에 등록되어 있지 않습니다. 자세한 내용은 [데이터베이스를 PITR에 포함되지 않도록 설정](#custom-backup.pitr.sqlserver.ineligible) 섹션을 참조하세요.
+ PITR 대상 데이터베이스는 데이터베이스 ID의 순서에 따라 결정됩니다. RDS Custom for SQL Server는 DB 인스턴스당 최대 5,000개의 데이터베이스를 허용합니다. 그러나 RDS Custom for SQL Server DB 인스턴스에 대해 PITR 작업을 통해 복원되는 최대 데이터베이스 수는 인스턴스 클래스 유형에 따라 달라집니다. 자세한 내용은 [인스턴스 클래스 유형별 PITR 대상 데이터베이스 수](#custom-backup.pitr.sqlserver.eligiblecountperinstance) 섹션을 참조하세요.
PITR에 포함되지 않는 다른 데이터베이스는 PITR에 사용되는 자동 스냅샷 백업을 비롯하여 DB 스냅샷에서 복원할 수 있습니다.
+ 새로운 데이터베이스를 추가하거나, 데이터베이스 이름을 바꾸거나, PITR 대상 데이터베이스를 복원하면 DB 인스턴스의 스냅샷이 시작됩니다.
+ PITR 대상인 최대 데이터베이스 수는 데이터베이스 인스턴스가 규모 조정 컴퓨팅 작업을 거칠 때 대상 인스턴스 클래스 유형에 따라 달라집니다. 인스턴스의 더 많은 데이터베이스가 PITR에 적합하도록 인스턴스를 확장하면 새 스냅샷이 생성됩니다.
+ 복원된 데이터베이스의 이름은 소스 DB 인스턴스와 동일합니다. 다른 이름을 지정할 수 없습니다.
+ `AWSRDSCustomSQLServerIamRolePolicy`는 다른 AWS 서비스에 대한 액세스가 필요합니다. 자세한 내용은 [AWSRDSCustomSQLServerInstanceRole에 액세스 정책 추가](custom-setup-sqlserver.md#custom-setup-sqlserver.iam.add-policy) 섹션을 참조하세요.
+ RDS Custom for SQL Server에는 표준 시간대 변경이 지원되지 않습니다. 운영 체제 또는 DB 인스턴스 시간대를 변경하면 PITR(및 기타 자동화)이 작동하지 않습니다.
## 인스턴스 클래스 유형별 PITR 대상 데이터베이스 수
다음 표에는 인스턴스 클래스 유형에 따라 PITR에 사용할 수 있는 최대 데이터베이스 수가 나와 있습니다.
| 인스턴스 클래스 유형 | PITR에 사용할 수 있는 최대 데이터베이스 수 |
| --- | --- |
| db.\$1.large | 100 |
| db.\$1.xlarge to db.\$1.2xlarge | 150 |
| db.\$1.4xlarge to db.\$1.8xlarge | 300 |
| db.\$1.12xlarge to db.\$1.16xlarge | 600 |
| db.\$1.24xlarge, db.\$132xlarge | 1000 |
`*` *서로 다른 인스턴스 클래스 유형을 나타냅니다.*
DB 인스턴스에서 PITR에 사용할 수 있는 최대 데이터베이스 수는 인스턴스 클래스 유형에 따라 다릅니다. RDS Custom for SQL Server에서 지원하는 최대 인스턴스 클래스 유형의 경우 100개부터 1,000개까지 다양합니다. SQL 서버 시스템 데이터베이스`(master, model, msdb, tempdb)`는 이 제한에 포함되지 않습니다. 대상 인스턴스 클래스 유형에 따라 DB 인스턴스를 확장하거나 축소할 때 RDS Custom은 PITR에 사용할 수 있는 데이터베이스 수를 자동으로 업데이트합니다. RDS Custom for SQL Server는 DB 인스턴스에서 PITR에 사용할 수 있는 최대 데이터베이스 수가 변경될 때 `RDS-EVENT-0352`를 전송합니다. 자세한 내용은 [사용자 지정 엔진 버전 이벤트](USER_Events.Messages.md#USER_Events.Messages.CEV) 섹션을 참조하세요.
**참고**
100개 이상의 데이터베이스에 대한 PITR 지원은 2023년 8월 26일 이후에 생성된 DB 인스턴스에서만 사용할 수 있습니다. 2023년 8월 26일 이전에 생성된 인스턴스의 경우 PITR에 사용할 수 있는 최대 데이터베이스 수는 인스턴스 클래스에 관계없이 100개입니다. 2023년 8월 26일 이전에 생성된 DB 인스턴스의 데이터베이스 100개 이상에 대해 PITR 지원을 활성화하려면 다음 작업을 수행할 수 있습니다.
DB 엔진 버전을 15.00.4322.2.v1 이상으로 업그레이드
PITR 작업 중에 RDS Custom은 복원 시 소스 DB 인스턴스에서 PITR에 속했던 모든 데이터베이스를 복원합니다. 대상 DB 인스턴스가 복원 작업을 완료하고 백업 보존을 활성화하면 대상 DB 인스턴스에서 PITR에 사용할 수 있는 최대 데이터베이스 수를 기준으로 DB 인스턴스가 백업을 시작합니다.
예를 들어, DB 인스턴스가 200개의 데이터베이스가 있는 `db.*.xlarge`에서 실행되는 경우는 다음과 같습니다.
1. RDS Custom for SQL Server는 PITR 백업을 위해 데이터베이스 ID를 기준으로 정렬된 처음 150개의 데이터베이스를 선택합니다.
1. db.\$1.4xlarge까지 확장하도록 인스턴스를 수정합니다.
1. 컴퓨팅 확장 작업이 완료되면 RDS Custom for SQL Server는 데이터베이스 ID를 기준으로 정렬된 처음 300개의 데이터베이스를 PITR 백업용으로 선택합니다. 이제 PITR 요구 사항 조건을 충족하는 200개 데이터베이스 각각이 PITR을 사용할 수 있습니다.
1. 이제 다시 db.\$1.xlarge로 인스턴스 규모를 축소합니다.
1. 컴퓨팅 축소 작업이 완료되면 RDS Custom for SQL Server는 데이터베이스 ID를 기준으로 정렬된 처음 150개의 데이터베이스를 PITR 백업용으로 다시 선택합니다.
## 데이터베이스를 PITR에 포함되지 않도록 설정
PITR에서 개별 데이터베이스를 제외하도록 선택할 수 있습니다. 이렇게 하려면 `database_id` 값을 `rds_pitr_blocked_databases` 테이블에 넣으면 됩니다. 다음 SQL 스크립트를 사용하여 테이블을 생성합니다.
**rds\$1pitr\$1blocked\$1databases 테이블을 생성하는 방법**
+ 다음 SQL 스크립트를 실행합니다.
```
create table msdb..rds_pitr_blocked_databases
(
database_id INT NOT NULL,
database_name SYSNAME NOT NULL,
db_entry_updated_date datetime NOT NULL DEFAULT GETDATE(),
db_entry_updated_by SYSNAME NOT NULL DEFAULT CURRENT_USER,
PRIMARY KEY (database_id)
);
```
대상 데이터베이스 및 대상이 아닌 데이터베이스 목록은 Amazon S3 버킷 `do-not-delete-rds-custom-$ACCOUNT_ID-$REGION-unique_identifier`의 `RDSCustomForSQLServer/Instances/DB_instance_resource_ID/TransactionLogMetadata` 디렉터리에 있는 `RI.End` 파일을 참조하세요. `RI.End` 파일에 대한 자세한 내용은 [Amazon S3의 트랜잭션 로그](#custom-backup.pitr.sqlserver.tlogs)를 참조하세요.
다음 SQL 스크립트를 사용하여 PITR 대상인 데이터베이스 목록을 확인할 수도 있습니다. `@limit` 변수를 인스턴스 클래스의 PITR에 사용할 수 있는 최대 데이터베이스 수로 설정합니다. 자세한 내용은 [인스턴스 클래스 유형별 PITR 대상 데이터베이스 수](#custom-backup.pitr.sqlserver.eligiblecountperinstance) 섹션을 참조하세요.
**DB 인스턴스 클래스의 PITR 대상인 데이터베이스 목록을 확인하려면**
+ 다음 SQL 스크립트를 실행합니다.
```
DECLARE @Limit INT;
SET @Limit = (insert-database-instance-limit-here);
USE msdb;
IF (EXISTS (SELECT * FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'dbo' AND TABLE_NAME = 'rds_pitr_blocked_databases'))
WITH TABLE0 AS (
SELECT hdrs.database_id as DatabaseId, sdb.name as DatabaseName, 'ALWAYS_ON_NOT_WRITABLE_REPLICA' as Reason, NULL as DatabaseNameOnPitrTable
FROM sys.dm_hadr_database_replica_states hdrs
INNER JOIN sys.databases sdb ON sdb.database_id = hdrs.database_id
WHERE (hdrs.is_local = 1 AND hdrs.is_primary_replica = 0)
OR (sys.fn_hadr_is_primary_replica (sdb.name) = 1 AND DATABASEPROPERTYEX (sdb.name, 'Updateability') = 'READ_ONLY')
),
TABLE1 as (
SELECT dbs.database_id as DatabaseId, sysdbs.name as DatabaseName, 'OPTOUT' as Reason,
CASE WHEN dbs.database_name = sysdbs.name THEN NULL ELSE dbs.database_name END AS DatabaseNameOnPitrTable
FROM msdb.dbo.rds_pitr_blocked_databases dbs
INNER JOIN sys.databases sysdbs ON dbs.database_id = sysdbs.database_id
WHERE sysdbs.database_id > 4
),
TABLE2 as (
SELECT
db.name AS DatabaseName,
db.create_date AS CreateDate,
db.state_desc AS DatabaseState,
db.database_id AS DatabaseId,
rs.database_guid AS DatabaseGuid,
rs.last_log_backup_lsn AS LastLogBackupLSN,
rs.recovery_fork_guid RecoveryForkGuid,
rs.first_recovery_fork_guid AS FirstRecoveryForkGuid,
db.recovery_model_desc AS RecoveryModel,
db.is_auto_close_on AS IsAutoClose,
db.is_read_only as IsReadOnly,
NEWID() as FileName,
CASE WHEN(db.state_desc = 'ONLINE'
AND db.recovery_model_desc != 'SIMPLE'
AND((db.is_auto_close_on = 0 and db.collation_name IS NOT NULL) OR db.is_auto_close_on = 1))
AND db.is_read_only != 1
AND db.user_access = 0
AND db.source_database_id IS NULL
AND db.is_in_standby != 1
THEN 1 ELSE 0 END AS IsPartOfSnapshot,
CASE WHEN db.source_database_id IS NULL THEN 0 ELSE 1 END AS IsDatabaseSnapshot
FROM sys.databases db
INNER JOIN sys.database_recovery_status rs
ON db.database_id = rs.database_id
WHERE DB_NAME(db.database_id) NOT IN('tempdb') AND
db.database_id NOT IN (SELECT DISTINCT DatabaseId FROM TABLE1) AND
db.database_id NOT IN (SELECT DISTINCT DatabaseId FROM TABLE0)
),
TABLE3 as(
Select @Limit+count(DatabaseName) as TotalNumberOfDatabases from TABLE2 where TABLE2.IsPartOfSnapshot=1 and DatabaseName in ('master','model','msdb')
)
SELECT TOP(SELECT TotalNumberOfDatabases from TABLE3) DatabaseName,CreateDate,DatabaseState,DatabaseId from TABLE2 where TABLE2.IsPartOfSnapshot=1
ORDER BY TABLE2.DatabaseID ASC
ELSE
WITH TABLE0 AS (
SELECT hdrs.database_id as DatabaseId, sdb.name as DatabaseName, 'ALWAYS_ON_NOT_WRITABLE_REPLICA' as Reason, NULL as DatabaseNameOnPitrTable
FROM sys.dm_hadr_database_replica_states hdrs
INNER JOIN sys.databases sdb ON sdb.database_id = hdrs.database_id
WHERE (hdrs.is_local = 1 AND hdrs.is_primary_replica = 0)
OR (sys.fn_hadr_is_primary_replica (sdb.name) = 1 AND DATABASEPROPERTYEX (sdb.name, 'Updateability') = 'READ_ONLY')
),
TABLE1 as (
SELECT
db.name AS DatabaseName,
db.create_date AS CreateDate,
db.state_desc AS DatabaseState,
db.database_id AS DatabaseId,
rs.database_guid AS DatabaseGuid,
rs.last_log_backup_lsn AS LastLogBackupLSN,
rs.recovery_fork_guid RecoveryForkGuid,
rs.first_recovery_fork_guid AS FirstRecoveryForkGuid,
db.recovery_model_desc AS RecoveryModel,
db.is_auto_close_on AS IsAutoClose,
db.is_read_only as IsReadOnly,
NEWID() as FileName,
CASE WHEN(db.state_desc = 'ONLINE'
AND db.recovery_model_desc != 'SIMPLE'
AND((db.is_auto_close_on = 0 and db.collation_name IS NOT NULL) OR db.is_auto_close_on = 1))
AND db.is_read_only != 1
AND db.user_access = 0
AND db.source_database_id IS NULL
AND db.is_in_standby != 1
THEN 1 ELSE 0 END AS IsPartOfSnapshot,
CASE WHEN db.source_database_id IS NULL THEN 0 ELSE 1 END AS IsDatabaseSnapshot
FROM sys.databases db
INNER JOIN sys.database_recovery_status rs
ON db.database_id = rs.database_id
WHERE DB_NAME(db.database_id) NOT IN('tempdb') AND
db.database_id NOT IN (SELECT DISTINCT DatabaseId FROM TABLE0)
),
TABLE2 as(
SELECT @Limit+count(DatabaseName) as TotalNumberOfDatabases from TABLE1 where TABLE1.IsPartOfSnapshot=1 and DatabaseName in ('master','model','msdb')
)
select top(select TotalNumberOfDatabases from TABLE2) DatabaseName,CreateDate,DatabaseState,DatabaseId from TABLE1 where TABLE1.IsPartOfSnapshot=1
ORDER BY TABLE1.DatabaseID ASC
```
**참고**
심볼 링크만 있는 데이터베이스도 PITR 작업 대상인 데이터베이스에서 제외됩니다. 위 쿼리는 이 기준에 따라 필터링되지 않습니다.
## Amazon S3의 트랜잭션 로그
백업 보존 기간에 따라 RDS Custom for SQL Server DB 인스턴스에 대한 트랜잭션 로그가 자동으로 추출되어 Amazon S3에 업로드되는지 여부가 결정됩니다. 0이 아닌 값은 자동 백업이 생성되고 RDS Custom 에이전트가 트랜잭션 로그를 5분마다 S3에 업로드함을 의미합니다.
S3의 트랜잭션 로그 파일은 DB 인스턴스를 생성할 때 입력한 AWS KMS key를 사용하여 유후 상태로 암호화됩니다. 자세한 내용은 *Amazon Simple Storage Service 사용 설명서*의 [서버 측 암호화를 사용하여 데이터 보호](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html)를 참조하세요.
각 데이터베이스의 트랜잭션 로그는 `do-not-delete-rds-custom-$ACCOUNT_ID-$REGION-unique_identifier`라는 이름이 지정된 S3 버킷에 업로드됩니다. S3 버킷의 `RDSCustomForSQLServer/Instances/DB_instance_resource_ID` 디렉터리에는 다음 두 개의 하위 디렉터리가 있습니다.
+ `TransactionLogs` - 각 데이터베이스 및 해당 메타데이터에 대한 트랜잭션 로그를 포함합니다.
트랜잭션 로그 파일 이름은 `yyyyMMddHHmm.database_id.timestamp`와 같은 패턴을 따릅니다.
```
202110202230.11.1634769287
```
`_metadata`라는 접미사가 있는 동일한 파일 이름에는 로그 시퀀스 번호, 데이터베이스 이름 및 `RdsChunkCount`와 같은 트랜잭션 로그에 대한 정보가 포함되어 있습니다. `RdsChunkCount`는 단일 트랜잭션 로그 파일을 나타내는 실제 파일 수를 결정합니다. 트랜잭션 로그 파일의 물리적 청크를 의미하는 접미사 `_0001`, `_0002` 등이 있는 파일이 표시될 수 있습니다. 청크된 트랜잭션 로그 파일을 사용하려면 청크를 다운로드한 후 병합해야 합니다.
다음과 같은 파일이 있는 경우를 생각해 봅니다.
+ `202110202230.11.1634769287`
+ ` 202110202230.11.1634769287_0001`
+ ` 202110202230.11.1634769287_0002 `
+ ` 202110202230.11.1634769287_metadata`
`RdsChunkCount`은 `3`입니다. 파일 병합 순서는 `202110202230.11.1634769287`, ` 202110202230.11.1634769287_0001`, `202110202230.11.1634769287_0002`입니다.
+ `TransactionLogMetadata` - 트랜잭션 로그 추출의 각 반복에 대한 메타데이터 정보를 포함합니다.
`RI.End` 파일에는 트랜잭션 로그가 추출된 모든 데이터베이스 및 존재하지만 트랜잭션 로그가 추출되지 않은 모든 데이터베이스에 대한 정보가 들어 있습니다. 예를 들어, `RI.End` 파일 이름은 `yyyyMMddHHmm.RI.End.timestamp` 패턴을 따릅니다.
```
202110202230.RI.End.1634769281
```
## AWS Management Console, AWS CLI 또는 RDS API를 사용하여 PITR 복원합니다.
AWS Management Console, AWS CLI 또는 RDS API를 사용하여 RDS Custom for SQL Server DB 인스턴스를 특정 시점으로 복원할 수 있습니다.
### 콘솔
**RDS Custom DB 인스턴스를 지정된 시간으로 복원하는 방법**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **자동 백업(Automated backups)**을 선택합니다.
1. 복원하려는 RDS Custom DB 인스턴스를 선택합니다.
1. **작업**에서 **특정 시점으로 복구**를 선택합니다.
**특정 시점으로 복구** 창이 나타납니다.
1. **최근 복원 가능 시간**을 선택하여 가능한 최근 시간으로 복원하거나, **사용자 지정**을 선택하여 시간을 선택합니다.
**사용자 지정(Custom)**을 선택한 경우 인스턴스를 복원하려는 날짜와 시간을 입력합니다.
시간은 현지 시간대로 표시됩니다. 즉, 협정 세계시(UTC)에서 오프셋으로 표시됩니다. 예를 들어 UTC-5는 동부 표준시/하절기 중부 표준시입니다.
1. **DB 인스턴스 식별자(DB instance identifier)**에는 복원된 대상 RDS Custom DB 인스턴스의 이름을 입력합니다. 이름은 고유해야 합니다.
1. 필요에 따라 DB 인스턴스 클래스와 같은 기타 옵션을 선택합니다.
1. **특정 시점으로 복구**를 선택합니다.
### AWS CLI
새로운 RDS Custom DB 인스턴스를 생성하려면 [restore-db-instance-to-point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html) AWS CLI 명령을 사용하여 DB 인스턴스를 지정된 시간으로 복원합니다.
다음 옵션 중 하나를 사용하여 복원 원본으로 사용할 백업을 지정합니다.
+ `--source-db-instance-identifier mysourcedbinstance`
+ `--source-dbi-resource-id dbinstanceresourceID`
+ `--source-db-instance-automated-backups-arn backupARN`
옵션은 `custom-iam-instance-profile` 필수입니다.
다음 예제는 지정된 시간을 기준으로 `my-custom-db-instance`를 `my-restored-custom-db-instance`라는 새로운 DB 인스턴스로 복원합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
1. aws rds restore-db-instance-to-point-in-time \
2. --source-db-instance-identifier my-custom-db-instance\
3. --target-db-instance-identifier my-restored-custom-db-instance \
4. --custom-iam-instance-profile AWSRDSCustomInstanceProfileForRdsCustomInstance \
5. --restore-time 2022-10-14T23:45:00.000Z
```
Windows의 경우:
```
1. aws rds restore-db-instance-to-point-in-time ^
2. --source-db-instance-identifier my-custom-db-instance ^
3. --target-db-instance-identifier my-restored-custom-db-instance ^
4. --custom-iam-instance-profile AWSRDSCustomInstanceProfileForRdsCustomInstance ^
5. --restore-time 2022-10-14T23:45:00.000Z
```
# RDS Custom for SQL Server 스냅샷 삭제
RDS Custom for SQL Server에서 관리하는 DB 스냅샷이 더 이상 필요하지 않으면 삭제할 수 있습니다. Amazon RDS와 RDS Custom DB 인스턴스의 삭제 절차는 동일합니다.
바이너리 및 루트 볼륨에 대한 Amazon EBS 스냅샷은 계정에서 실행 중인 일부 인스턴스 또는 다른 RDS Custom for SQL Server 스냅샷에 연결될 수 있어 계정에 더 오래 남아 있습니다. 이러한 EBS 스냅샷은 기존 RDS Custom for SQL Server 리소스(DB 인스턴스 또는 백업)와 더 이상 관련이 없는 경우 자동으로 삭제됩니다.
## 콘솔
**RDS Custom DB 인스턴스의 스냅샷을 삭제하는 방법**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 [**Snapshots**]를 선택합니다.
1. 삭제하고 싶은 DB 스냅샷을 선택합니다.
1. **작업(Actions)**에서 **스냅샷 삭제(Delete snapshot)**를 선택합니다.
1. 확인 페이지에서 **삭제**를 선택합니다.
## AWS CLI
RDS Custom 스냅샷을 삭제하려면 AWS CLI 명령 [delete-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/delete-db-snapshot.html)을 사용합니다.
다음 옵션이 필요합니다.
+ `--db-snapshot-identifier` - 삭제할 스냅샷입니다.
다음 예제에서는 `my-custom-snapshot` DB 스냅샷을 삭제합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
1. aws rds delete-db-snapshot \
2. --db-snapshot-identifier my-custom-snapshot
```
Windows의 경우:
```
1. aws rds delete-db-snapshot ^
2. --db-snapshot-identifier my-custom-snapshot
```
# RDS Custom for SQL Server 자동 백업 삭제
보관된 RDS Custom for SQL Server 자동 백업이 더 이상 필요하지 않으면 삭제할 수 있습니다. 절차는 Amazon RDS 백업을 삭제하는 절차와 동일합니다.
## 콘솔
**보관된 자동 백업을 삭제하려면**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 **자동 백업(Automated backups)**을 선택합니다.
1. **Retained(보관됨)**를 선택합니다.
1. 삭제하려는 보관된 자동 백업을 선택합니다.
1. [** Actions**]에 대해 [**Delete**]를 선택합니다.
1. 확인 페이지에서 **delete me**를 입력하고 **삭제**를 선택합니다.
## AWS CLI
[delete-db-instance-automated-backup](https://docs.aws.amazon.com/cli/latest/reference/rds/delete-db-instance-automated-backup.html)이라는 AWS CLI 명령을 사용하여 보관된 자동 백업을 삭제할 수 있습니다.
다음 옵션을 사용하여 보관된 자동 백업을 삭제할 수 있습니다.
+ `--dbi-resource-id` - 소스 RDS Custom DB 인스턴스의 리소스 식별자입니다.
보관된 자동 백업의 소스 DB 인스턴스에 대한 리소스 식별자는 AWS CLI 명령 [describe-db-instance-automated-backups](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instance-automated-backups.html)를 사용하여 찾을 수 있습니다.
다음 예시에서는 소스 DB 인스턴스 리소스 식별자가 `custom-db-123ABCEXAMPLE`인 보관된 자동 백업을 삭제합니다.
**Example**
대상 LinuxmacOS, 또는Unix:
```
1. aws rds delete-db-instance-automated-backup \
2. --dbi-resource-id custom-db-123ABCEXAMPLE
```
Windows의 경우:
```
1. aws rds delete-db-instance-automated-backup ^
2. --dbi-resource-id custom-db-123ABCEXAMPLE
```
# Amazon RDS Custom for SQL Server DB 스냅샷 복사
RDS Custom for SQL Server에서는 자동 백업 및 수동으로 DB 스냅샷을 복사할 수 있습니다. 스냅샷을 복사한 후 생성한 복사본은 수동 스냅샷입니다. 자동 백업 또는 수동 스냅샷의 복사본을 여러 개 만들 수 있지만, 각 복사본에는 고유한 식별자가 있어야 합니다.
RDS Custom for SQL Server를 사용하는 다른 AWS 리전에서 동일한 AWS 계정 내의 스냅샷만 복사할 수 있습니다. 다음 연산자는 현재 지원되지 않습니다.
+ 동일한 AWS 리전에서 DB 스냅샷을 복사합니다.
+ AWS 계정 간에 DB 스냅샷을 복사합니다.
RDS Custom for SQL Server는 증분 스냅샷 복사를 지원합니다. 자세한 내용은 [증분 스냅샷 복사 시 고려 사항](USER_CopySnapshot.md#USER_CopySnapshot.Incremental) 섹션을 참조하세요.
**Topics**
+ [제한 사항](#custom-copying-snapshot-sqlserver.Limitations)
+ [암호화 처리](#custom-copying-snapshot-sqlserver.Encryption)
+ [리전 간 복사](#custom-copying-snapshot-sqlserver.XRCopy)
+ [사용자 지정 엔진 버전(CEV)으로 만든 DB 인스턴스의 스냅샷](#custom-copying-snapshot-sqlserver.CEVSnap)
+ [IAM 보안 주체에 필요한 권한 부여](#custom-copying-snapshot-sqlserver.GrantPermIAM)
+ [DB 스냅샷 복사](#custom-copying-snapshot-sqlserver.CopyingDBSnapshot)
## 제한 사항
RDS Custom for SQL Server용 DB 스냅샷을 복사하는 데는 다음과 같은 제한이 적용됩니다.
+ 대상 스냅샷이 제공되기 전에 소스 스냅샷을 삭제하면 스냅샷 복사가 실패할 수 있습니다. 소스 스냅샷을 삭제하기 전에 대상 스냅샷의 상태가 `AVAILABLE`인지 확인하세요.
+ DB 스냅샷 복사 요청에서 옵션 그룹 이름을 지정하거나 옵션 그룹을 복사할 수 없습니다.
+ 복사 프로세스 이전 또는 복사 프로세스 중에 소스 DB 스냅샷의 종속 AWS 리소스를 삭제하면 스냅샷 복사 요청이 비동기적으로 실패할 수 있습니다.
+ 계정의 RDS Custom 관리형 S3 버킷에 저장된 소스 DB 인스턴스의 Service Master Key(SMK) 백업 파일을 삭제하면 DB 스냅샷 복사가 비동기적으로 성공합니다. 하지만 TDE 지원 데이터베이스와 같이 SMK에 의존하는 SQL Server 기능에는 문제가 있습니다. 자세한 내용은 [RDS Custom for SQL Server에서 TDE 지원 데이터베이스의 PENDING\$1RECOVERY 상태 문제 해결](custom-troubleshooting-sqlserver.md#custom-troubleshooting-sqlserver.pending_recovery) 섹션을 참조하세요.
+ 동일한 AWS 리전에서 DB 스냅샷을 복사하는 것은 현재 지원되지 않습니다.
+ AWS 계정 간 DB 스냅샷을 복사하는 것은 현재 지원되지 않습니다.
Amazon RDS의 DB 스냅샷 복사 제한은 RDS Custom for SQL Server에도 적용됩니다. 자세한 내용은 [제한 사항](USER_CopySnapshot.md#USER_CopySnapshot.Limitations) 섹션을 참조하세요.
## 암호화 처리
모든 RDS Custom for SQL Server DB 인스턴스 및 DB 스냅샷은 KMS 키로 암호화됩니다. 암호화된 스냅샷은 암호화된 스냅샷에만 복사할 수 있으므로, DB 스냅샷 복사 요청을 위해 대상 AWS 리전에서 유효한 KMS 키를 지정해야 합니다.
소스 스냅샷은 복사 프로세스 전체에서 암호화를 유지합니다. Amazon RDS는 봉투 암호화를 사용하여 지정된 대상 AWS 리전 KMS 키를 통해 복사 작업 중에 데이터를 보호합니다. 자세한 내용은 *AWS Key Management Service 개발자 안내서*의 [봉투 암호화](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping)를 참조하세요.
## 리전 간 복사
AWS 리전 간에 DB 스냅샷을 복사할 수 있습니다. 하지만 리전 간 스냅샷 복사와 관련한 특정 제약 및 고려 사항이 있습니다.
### 스냅샷 복사를 위해 AWS 리전 간에 통신할 수 있도록 RDS 권한 부여
리전 간 DB 스냅샷 복사 요청이 성공적으로 처리되면 RDS가 복사를 시작합니다. RDS가 소스 스냅샷에 액세스할 수 있도록 권한 부여 요청이 생성됩니다. 이 권한 부여 요청은 소스 DB 스냅샷을 대상 DB 스냅샷에 연결합니다. 이렇게 하면 RDS가 지정된 대상 스냅샷에만 복사할 수 있습니다.
RDS는 서비스 연결 IAM 역할의 `rds:CrossRegionCommunication` 권한을 사용하여 권한 부여를 확인합니다. 복사가 승인되면 RDS는 소스 리전과 통신하여 복사 작업을 완료할 수 있습니다.
RDS는 이전에 CopyDBSnapshot 요청에 의해 승인되지 않은 DB 스냅샷에 액세스할 권한이 없습니다. 복사가 완료되면 권한 부여가 취소됩니다.
RDS는 서비스 연결 역할을 사용하여 소스 리전에서 승인을 확인합니다. 복사 프로세스 중에 서비스 연결 역할을 삭제하면 복사가 실패합니다.
자세한 내용은 **AWS Identity and Access Management 사용 설명서의 [서비스 연결 역할 사용](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html)을 참조하세요.
### AWS Security Token Service 보안 인증 사용
전역 AWS Security Token Service(AWS STS) 엔드포인트의 세션 토큰은 기본적으로 활성화된 AWS 리전(상용 리전)에서만 유효합니다. `assumeRole`에서 AWS STS API 작업을 통해 얻은 자격 증명을 사용하는 경우 소스 리전이 옵트인 리전이면 리전별 엔드포인트를 사용합니다. 그렇지 않으면 요청이 실패합니다. 자격 증명은 두 리전 모두에서 유효해야 하며, 이는 리전 AWS STS 엔드포인트를 사용할 때만 옵트인 리전에 적용됩니다.
전역 엔드포인트를 사용하려면 작업의 두 리전 모두에 대해 전역 엔드포인트를 사용하도록 설정되어 있어야 합니다. 글로벌 엔드포인트를 AWS STS 계정 설정의 모든 AWS 리전에서 `Valid`로 설정합니다.
자세한 내용은 **AWS Identity and Access Management 사용 설명서의 [AWS 리전에서 AWS STS 관리](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html)를 참조하세요.
## 사용자 지정 엔진 버전(CEV)으로 만든 DB 인스턴스의 스냅샷
[사용자 지정 엔진 버전(CEV)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-cev-sqlserver.html)을 사용하는 DB 인스턴스의 DB 스냅샷의 경우 RDS는 CEV를 DB 스냅샷과 연결합니다. AWS 리전에서 CEV와 연결된 소스 DB 스냅샷을 복사하려면 RDS가 소스 DB 스냅샷과 함께 CEV를 대상 리전으로 복사합니다.
동일한 CEV와 연결된 여러 DB 스냅샷을 동일한 대상 리전에 복사하는 경우 첫 번째 복사 요청은 연결된 CEV를 복사합니다. 다음 요청의 복사 프로세스는 처음에 복사한 CEV를 찾아 다음 DB 스냅샷 사본과 연결합니다. 기존 CEV 사본은 DB 스냅샷 복사본과 연결할 수 있는 `AVAILABLE` 상태여야 합니다.
CEV와 연결된 DB 스냅샷을 복사하려면 요청자의 IAM 정책에 DB 스냅샷 복사와 연결된 CEV 복사를 모두 승인할 권한이 있어야 합니다. 연결된 CEV 복사를 허용하려면 요청자의 IAM 정책에 다음과 같은 권한이 필요합니다.
+ `rds:CopyCustomDBEngineVersion` ‐ 요청자 IAM 보안 주체는 소스 CEV를 소스 DB 스냅샷과 함께 대상 리전에 복사할 수 있는 권한이 있어야 합니다. 요청자 IAM 보안 주체가 소스 CEV를 복사할 권한이 없는 경우 권한 부여 오류로 인해 스냅샷 복사 요청이 실패합니다.
+ `ec2:CreateTags` ‐ 소스 CEV의 기본 EC2 AMI가 CEV 사본의 일부로 대상 리전에 복사됩니다. RDS Custom은 AMI를 복사하기 전에 AMI에 `AWSRDSCustom` 태그를 지정하려고 합니다. 요청자 IAM 보안 주체가 소스 리전의 소스 CEV를 기반으로 하는 AMI에 대해 태그를 생성할 권한이 있는지 확인하세요.
CEV 복사 권한에 대한 자세한 내용은 [IAM 보안 주체에 필요한 권한 부여](#custom-copying-snapshot-sqlserver.GrantPermIAM) 섹션을 참조하세요.
## IAM 보안 주체에 필요한 권한 부여
RDS Custom for SQL Server DB 스냅샷을 복사할 수 있는 충분한 액세스 권한을 가지고 있는지 확인하세요. 콘솔 또는 CLI를 사용하여 DB 스냅샷을 복사하는 IAM 역할 또는 사용자(IAM 보안 주체라고 함)는 DB 인스턴스를 성공적으로 생성하기 위해 다음 중 하나의 정책을 가지고 있어야 합니다.
+ `AdministratorAccess` 정책
+ 다음과 같은 추가 권한이 있는 `AmazonRDSFullAccess` 정책:
```
s3:CreateBucket
s3:GetBucketPolicy
s3:PutBucketPolicy
kms:CreateGrant
kms:DescribeKey
ec2:CreateTags
```
RDS Custom은 AWS 리전에서 스냅샷을 복사할 때 이러한 권한을 사용합니다. 이러한 권한은 RDS Custom 작업에 필요한 리소스를 계정에 구성합니다. `kms:CreateGrant` 권한에 대한 자세한 내용은 [AWS KMS key 관리](Overview.Encryption.Keys.md) 섹션을 참조하세요.
다음 샘플 JSON 정책은 `AmazonRDSFullAccess` 정책 외에 필요한 권한을 부여합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "CreateS3BucketAndReadWriteBucketPolicy",
"Effect": "Allow",
"Action": [
"s3:CreateBucket",
"s3:PutBucketPolicy",
"s3:GetBucketPolicy"
],
"Resource": "arn:aws:s3:::do-not-delete-rds-custom-*"
},
{
"Sid": "CreateKmsGrant",
"Effect": "Allow",
"Action": [
"kms:CreateGrant",
"kms:DescribeKey"
],
"Resource": "*"
},
{
"Sid": "CreateEc2Tags",
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "*"
}
]
}
```
------
**참고**
서비스 제어 정책(SCP), 권한 경계 또는 IAM 보안 주체와 연결된 세션 정책에서 나열된 권한을 제한하지 않는지 확인합니다.
요청자의 IAM 정책에 컨텍스트 키가 있는 조건을 사용하는 경우 특정 조건으로 인해 요청이 실패할 수 있습니다. IAM 정책 조건으로 인한 일반적인 위험에 대한 자세한 내용은 [리전 간 DB 스냅샷 복사 요청](USER_CopySnapshot.md#USER_CopySnapshot.AcrossRegions.Policy) 섹션을 참조하세요.
## DB 스냅샷 복사
다음 절차에 따라 DB 스냅샷을 복사합니다. 각 AWS 계정에 대해 AWS 리전 간에 DB 스냅샷을 한 번에 20개까지 복사할 수 있습니다. DB 스냅샷을 다른 AWS 리전으로 복사하면 그 AWS 리전에 유지되는 수동 DB 스냅샷이 생성됩니다. 소스 AWS 리전 외부로 DB 스냅샷을 복사하면 Amazon RDS 데이터 전송 요금이 발생합니다. 데이터 전송 요금에 대한 자세한 정보는 [Amazon RDS 요금](https://aws.amazon.com/rds/pricing/)을 참조하십시오.
새 AWS 리전에 DB 스냅샷 사본이 생성된 후 DB 스냅샷 사본은 해당 AWS 리전의 다른 모든 DB 스냅샷과 똑같이 동작합니다.
AWS Management Console, AWS CLI 또는 Amazon RDS API를 사용하여 DB 스냅샷을 복사할 수 있습니다.
------
#### [ Console ]
다음 프로시저는 AWS Management Console을 사용하여 RDS Custom for SQL Server DB 스냅샷을 복사합니다.
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)에서 Amazon RDS 콘솔을 엽니다.
1. 탐색 창에서 [**Snapshots**]를 선택합니다.
1. 복사하려는 RDS Custom for SQL Server DB 스냅샷을 선택합니다.
1. **작업** 드롭다운에서 **스냅샷 복사**를 선택합니다.
![\[Amazon RDS 콘솔의 스냅샷 복사 페이지. 설정이 페이지에 로드됩니다.\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/images/XRSC-Snapshot-Copy.png)
1. DB 스냅샷을 다른 AWS 리전에 복사하려면 **대상 리전**을 필요한 값으로 설정합니다.
**참고**
대상 AWS 리전에는 소스 AWS 리전과 동일한 가용 데이터베이스 엔진 버전이 있어야 합니다.
1. **새 DB 스냅샷 식별자**에 DB 스냅샷의 고유 이름을 입력합니다. 자동 백업 또는 수동 스냅샷의 복사본을 여러 개 만들 수 있지만, 각 복사본에는 고유한 식별자가 있어야 합니다.
1. (선택 사항) [**Copy Tags**]를 선택하여 스냅샷의 태그와 값을 스냅샷 사본에 복사합니다.
1. **암호화**에 대해 DB 스냅샷 복사본을 암호화하는 데 사용할 KMS 키 식별자를 지정합니다.
**참고**
RDS Custom for SQL Server는 모든 DB 스냅샷을 암호화합니다. 암호화되지 않은 DB 스냅샷을 생성할 수 없습니다.
1. **스냅샷 복사**를 선택합니다.
RDS Custom for SQL Server는 선택한 AWS 리전에 DB 인스턴스의 DB 스냅샷 복사본을 생성합니다.
------
#### [ AWS CLI ]
AWS CLI 명령 [https://docs.aws.amazon.com/cli/latest/reference/rds/copy-db-snapshot.html](https://docs.aws.amazon.com/cli/latest/reference/rds/copy-db-snapshot.html)을 사용하여 RDS Custom for SQL Server DB 스냅샷을 복사할 수 있습니다. 스냅샷을 새 AWS 리전으로 복사하는 경우 새 AWS 리전에서 명령을 실행합니다. 다음 옵션을 사용하여 DB 스냅샷을 복사할 수 있습니다. 시나리오에 따라 필요하지 않은 옵션도 있습니다.
+ `--source-db-snapshot-identifier` - 소스 DB 스냅샷의 식별자입니다.
+ 소스 스냅샷이 사본과 다른 AWS 리전에 있는 경우 유효한 DB 스냅샷 ARN을 지정합니다. 예를 들어 `arn:aws:rds:us-west-2:123456789012:snapshot:instance1-snapshot-12345678`입니다.
+ `--target-db-snapshot-identifier` – DB 스냅샷의 새 사본의 식별자입니다.
+ `--kms-key-id` – 암호화된 DB 스냅샷의 KMS 키 식별자입니다. KMS 키 식별자는 KMS 키의 Amazon 리소스 이름(ARN), 키 식별자 또는 키 별칭입니다.
+ 암호화된 스냅샷을 다른 AWS 리전에 복사하는 경우 대상 AWS 리전에 대해 KMS 키를 지정해야 합니다. KMS 키는 생성된 AWS 리전에만 적용되며, 다중 리전 키를 사용하지 않는 한 다른 AWS 리전의 한 AWS 리전에서 암호화 키를 사용할 수 없습니다. 다중 리전 KMS 키에 대한 자세한 내용은 [AWS KMS에서 다중 리전 키 사용](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html)을 참조하세요.
+ `--copy-tags` - 소스 스냅샷의 태그와 값을 스냅샷 복사본에 포함합니다.
RDS Custom for SQL Server DB 스냅샷의 복사에는 다음 옵션이 지원되지 않습니다.
+ `--copy-option-group `
+ `--option-group-name`
+ `--pre-signed-url`
+ `--target-custom-availability-zone`
다음 코드 예제에서는 암호화된 DB 스냅샷을 미국 서부(오리건) 리전에서 미국 동부(버지니아 북부) 리전으로 복사합니다. 대상(us-east-1) 리전에서 명령을 실행합니다.
Linux, macOS 또는 Unix의 경우는 다음과 같습니다.
```
aws rds copy-db-snapshot \
--region us-east-1 \
--source-db-snapshot-identifier arn:aws:rds:us-west-2:123456789012:snapshot:instance1-snapshot-12345678 \
--target-db-snapshot-identifier mydbsnapshotcopy \
--kms-key-id a1b2c3d4-1234-5678-wxyz-a1b2c3d4d5e6
```
Windows의 경우:
```
aws rds copy-db-snapshot ^
--region us-east-1 ^
--source-db-snapshot-identifier arn:aws:rds:us-west-2:123456789012:snapshot:instance1-snapshot-12345678 ^
--target-db-snapshot-identifier mydbsnapshotcopy ^
--kms-key-id a1b2c3d4-1234-5678-wxyz-a1b2c3d4d5e6
```
------
#### [ RDS API ]
Amazon RDS API 작업 [CopyDBSnapshot](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CopyDBSnapshot.html)을 사용하여 RDS Custom for SQL Server DB 스냅샷을 복사할 수 있습니다. 스냅샷을 새 AWS 리전으로 복사하는 경우 새 AWS 리전에서 작업을 수행합니다. 다음 파라미터를 사용하여 DB 스냅샷을 복사할 수 있습니다. 모든 파라미터가 필요한 것은 아닙니다.
+ `SourceDBSnapshotIdentifier` - 소스 DB 스냅샷의 식별자입니다.
+ 소스 스냅샷이 사본과 다른 AWS 리전에 있는 경우 유효한 DB 스냅샷 ARN을 지정합니다. 예를 들어 `arn:aws:rds:us-west-2:123456789012:snapshot:instance1-snapshot-12345678`입니다.
+ `TargetDBSnapshotIdentifier` – DB 스냅샷의 새 사본의 식별자입니다.
+ `KmsKeyId` – 암호화된 DB 스냅샷의 KMS 키 식별자입니다. KMS 키 식별자는 KMS 키의 Amazon 리소스 이름(ARN), 키 식별자 또는 키 별칭입니다.
+ 암호화된 스냅샷을 다른 AWS 리전에 복사하는 경우 대상 AWS 리전에 대해 KMS 키를 지정해야 합니다. KMS 키는 생성된 AWS 리전에만 적용되며, 다중 리전 키를 사용하지 않는 한 다른 AWS 리전의 한 AWS 리전에서 암호화 키를 사용할 수 없습니다. 다중 리전 KMS 키에 대한 자세한 내용은 [AWS KMS에서 다중 리전 키 사용](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html)을 참조하세요.
+ `CopyTags` - 소스 스냅샷의 태그와 값을 스냅샷 사본에 복사하려면 이 파라미터를 `true`로 설정합니다. 기본값은 `false`입니다.
다음 옵션에는 RDS Custom for SQL Server DB 스냅샷 복사가 지원되지 않습니다.
+ `CopyOptionGroup`
+ `OptionGroupName`
+ `PreSignedUrl`
+ `TargetCustomAvailabilityZone`
다음 코드는 US East (N. Virginia) 리전에 `mydbsnapshotcopy`라는 새 이름으로 스냅샷 복사본을 생성합니다.
```
https://rds.us-east-1.amazonaws.com/
?Action=CopyDBSnapshot
&KmsKeyId=a1b2c3d4-1234-5678-wxyz-a1b2c3d4d5e6
&SourceDBSnapshotIdentifier=arn%3Aaws%3Ards%3Aus-west-2%3A123456789012%3Asnapshot%3Ainstance1-snapshot-12345678
&TargetDBSnapshotIdentifier=mydbsnapshotcopy
&Version=2014-10-31
&X-Amz-Algorithm=AWS4-HMAC-SHA256
&X-Amz-Credential=AKIADQKE4SARGYLE/20161117/us-east-1/rds/aws4_request
&X-Amz-Date=20161117T221704Z
&X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date
&X-Amz-Signature=da4f2da66739d2e722c85fcfd225dc27bba7e2b8dbea8d8612434378e52adccf
```
------
# 온프레미스 데이터베이스를 SQL Server용 Amazon RDS Custom으로 마이그레이션
다음 프로세스를 따라 기본 백업 및 복원을 사용하여 온프레미스 Microsoft SQL Server 데이터베이스를 SQL Server용 Amazon RDS Custom으로 마이그레이션할 수 있습니다.
1. 온프레미스 DB 인스턴스에서 데이터베이스의 전체 백업을 수행합니다.
1. Amazon S3로 백업 파일을 업로드합니다.
1. S3의 백업 파일을 SQL Server DB 인스턴스용 RDS Custom으로 다운로드합니다.
1. SQL Server DB 인스턴스용 RDS Custom에서 다운로드한 백업 파일을 사용하여 데이터베이스를 복원합니다.
이 프로세스에서는 기본 전체 백업 및 복원을 사용하여 온프레미스에서 SQL Server용 RDS Custom으로 데이터베이스를 마이그레이션하는 방법을 설명합니다. 마이그레이션 프로세스 중에 전환 시간을 줄이기 위해 디퍼렌셜 또는 로그 백업을 사용하는 것도 고려할 수 있습니다.
RDS for SQL Server의 기본 백업 및 복원에 대한 일반적인 정보는 [기본 백업 및 복원 기능을 사용하여 SQL Server 데이터베이스 가져오기 및 내보내기](SQLServer.Procedural.Importing.md) 섹션을 참조하세요.
**Topics**
+ [사전 조건](#custom-migrating.prereqs)
+ [온프레미스 데이터베이스 백업](#custom-migrating.backup)
+ [Amazon S3로 백업 파일 업로드](#custom-migrating.upload)
+ [Amazon S3에서 백업 파일 다운로드](#custom-migrating.upload)
+ [SQL Server DB 인스턴스용 RDS Custom으로 백업 파일 복원](#custom-migrating.restore)
## 사전 조건
데이터베이스를 마이그레이션하기 전에 다음 작업을 수행합니다.
1. SQL Server DB 인스턴스용 RDS Custom에 대해 원격 데스크톱 연결(RDP)을 구성합니다. 자세한 내용은 [RDP를 사용하여 RDS Custom DB 인스턴스에 연결](custom-creating-sqlserver.rdp.md) 섹션을 참조하세요.
1. 데이터베이스 백업 파일을 업로드 및 다운로드할 수 있도록 Amazon S3에 액세스할 권한을 구성합니다.
## 온프레미스 데이터베이스 백업
SQL Server 기본 백업을 사용하여 온프레미스 DB 인스턴스의 데이터베이스 전체 백업을 수행할 수 있습니다.
다음 예제에서는 백업 파일 크기를 줄이는 `COMPRESSION` 옵션이 지정된 `mydatabase`라는 이름의 데이터베이스 백업을 보여줍니다.
**온프레미스 데이터베이스를 백업하는 방법**
1. SQL Server Management Studio(SSMS)를 사용하여 온프레미스 SQL Server 인스턴스에 연결합니다.
1. T-SQL 명령을 실행합니다.
```
backup database mydatabase to
disk ='C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Backup\mydb-full-compressed.bak'
with compression;
```
## Amazon S3로 백업 파일 업로드
AWS Management Console을 사용하여 `mydb-full-compressed.bak` 백업 파일을 Amazon S3로 업로드합니다.
**S3로 백업 파일을 업로드하는 방법**
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 S3 콘솔을 엽니다.
1. **버킷(Buckets)**에서 백업 파일을 업로드할 버킷의 이름을 선택합니다.
1. **업로드**를 선택합니다.
1. **업로드** 창에서 다음 중 하나를 수행합니다.
+ `mydb-full-compressed.bak`를 **업로드(Upload)** 창으로 끌어다 놓습니다.
+ **파일 추가(Add file)**와 `mydb-full-compressed.bak`를 차례로 선택한 다음 **열기(Open)**를 선택합니다.
Amazon S3는 백업 파일을 S3 객체로 업로드합니다. 업로드가 완료되면 **업로드: 상태** 페이지에서 성공 메시지를 볼 수 있습니다.
## Amazon S3에서 백업 파일 다운로드
콘솔을 사용하여 S3의 백업 파일을 SQL Server DB 인스턴스용 RDS Custom으로 다운로드할 수 있습니다.
**S3에서 백업 파일을 다운로드하는 방법**
1. RDP를 사용하여 SQL Server DB 인스턴스용 RDS Custom에 연결합니다.
1. AWS Management Console에 로그인한 후 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)에서 S3 콘솔을 엽니다.
1. **버킷(Buckets)** 목록에서 백업 파일이 들어 있는 버킷의 이름을 선택합니다.
1. `mydb-full-compressed.bak` 백업 파일을 선택합니다.
1. **작업(Actions)**에서 **다음으로 다운로드(Download as)**를 선택합니다.
1. 제공된 링크에 대한 컨텍스트(마우스 오른쪽 버튼 클릭) 메뉴를 열고 나서 **다른 이름으로 저장(Save As)**을 선택합니다.
1. `mydb-full-compressed.bak`를 `D:\rdsdbdata\BACKUP` 디렉터리에 저장합니다.
## SQL Server DB 인스턴스용 RDS Custom으로 백업 파일 복원
SQL Server 기본 복원을 사용하여 백업 파일을 SQL Server DB 인스턴스용 RDS Custom으로 복원할 수 있습니다.
이 예제에서는 데이터 및 로그 파일 디렉터리가 온프레미스 DB 인스턴스와 다르기 때문에 `MOVE` 옵션이 지정됩니다.
**백업 파일을 복원하는 방법**
1. SSMS를 사용하여 SQL Server DB 인스턴스용 RDS Custom에 연결합니다.
1. T-SQL 명령을 실행합니다.
```
restore database mydatabase from disk='D:\rdsdbdata\BACKUP\mydb-full-compressed.bak'
with move 'mydatabase' to 'D:\rdsdbdata\DATA\mydatabase.mdf',
move 'mydatabase_log' to 'D:\rdsdbdata\DATA\mydatabase_log.ldf';
```
# RDS Custom for SQL Server 운영 체제 업데이트
RDS Custom for SQL Server는 RDS 제공 엔진 버전(RPEV) 인스턴스에 운영 체제 업데이트 적용과 관련하여 다음과 같은 방법을 제공합니다.
+ *시스템 업데이트 유지 관리 작업*
+ *데이터베이스 마이너 버전 업그레이드*
+ RPEV를 사용한 DB 마이너 엔진 버전 업그레이드에는 최신 운영 체제 업데이트가 포함됩니다. 이 접근 방식은 OS 업데이트를 SQL Server 마이너 버전 업그레이드와 결합하려는 경우에 특히 유용합니다. 자세한 내용은 [Amazon RDS Custom for SQL Server DB 인스턴스 업그레이드](custom-upgrading-sqlserver.md) 섹션을 참조하세요.
## 운영 체제 업데이트 시나리오
다음의 두 가지 방법으로 RDS Custom for SQL Server 인스턴스의 운영 체제 업데이트를 관리할 수 있습니다.
+ 단일 AZ 인스턴스의 경우 운영 체제 업데이트 중에 인스턴스를 사용할 수 없습니다.
+ 다중 AZ 배포의 경우 RDS는 다음과 같은 방식으로 운영 체제 업데이트를 적용합니다.
+ 먼저 RDS는 대기 인스턴스에서 운영 체제 업데이트를 수행합니다.
+ 업그레이드된 대기 DB 인스턴스로 RDS 장애 조치하여 이를 새 기본 DB 인스턴스로 만듭니다.
+ 마지막으로 RDS는 새 대기 DB 인스턴스에서 운영 체제 업데이트를 수행합니다.
다중 AZ 배포의 가동 중지 시간은 장애 조치에 걸리는 시간입니다.
## 시스템 업데이트 유지 관리 작업을 사용하여 운영 체제 업데이트 적용
Amazon RDS RPEV 인스턴스에 운영 체제 업데이트를 적용하기 위해 AWS Management Console, AWS CLI 또는 RDS API를 사용할 수 있습니다. 자세한 내용은 [RDS DB 인스턴스의 운영 체제 업데이트](USER_UpgradeDBInstance.Maintenance.md#OS_Updates) 섹션을 참조하세요.
**Example**
대상 LinuxmacOS, 또는Unix:
**1단계: 사용 가능한 업데이트 확인**
`describe-pending-maintenance-actions` 명령을 사용하여 인스턴스에 OS 업데이트를 사용할 수 있는지 확인합니다.
```
aws rds describe-pending-maintenance-actions
```
응답 예제:
```
{
"PendingMaintenanceActions": [
{
"ResourceIdentifier": "arn:aws:rds:us-east-1:111122223333:db:my-sqlserver-instance",
"PendingMaintenanceActionDetails": [
{
"Action": "system-update",
"Description": "New Operating System update is available"
}
]
}
]
}
```
작업 유형이 `system-update`이면 인스턴스에 OS 업데이트를 사용할 수 있다는 의미입니다.
**2단계: OS 업데이트 적용**
`apply-pending-maintenance-action` 명령을 사용하여 일정을 업데이트합니다.
```
aws rds apply-pending-maintenance-action \
--resource-identifier arn:aws:rds:us-east-1:111122223333:db:my-sqlserver-instance \
--apply-action system-update \
--opt-in-type immediate
```
`opt-in-type` 입력에는 다음과 같은 옵션이 있습니다.
+ `immediate`: 업데이트 즉시 적용
+ `next-maintenance`: 예약된 다음 유지 관리 기간에 업데이트 적용
+ `undo-opt-in`: 이전에 예약된 업데이트 취소
응답 예제:
```
{
"ResourcePendingMaintenanceActions": {
"ResourceIdentifier": "arn:aws:rds:us-east-1:111122223333:db:my-sqlserver-instance",
"PendingMaintenanceActionDetails": [
{
"Action": "system-update",
"AutoAppliedAfterDate": "2024-04-10T20:41:01.695000+00:00",
"ForcedApplyDate": "2024-04-10T20:41:01.694000+00:00",
"CurrentApplyDate": "2024-04-10T20:41:01.695000+00:00",
"Description": "New Operating System update is available"
}
]
}
}
```
## OS 업데이트 알림
새로운 선택적 운영 체제 시스템 패치가 제공될 때 알림을 받으려면 보안 패치 이벤트 범주에서 [RDS-EVENT-0230](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.Messages.html#RDS-EVENT-0230) 구독을 신청하면 됩니다. RDS 이벤트 구독에 대한 자세한 내용은 [Amazon RDS 이벤트 알림 구독](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.Subscribing.html)을 참조하세요.
## 고려 사항
OS 업데이트에는 다음과 같은 고려 사항 및 제한 사항이 적용됩니다.
+ C:\$1 드라이브에 대한 운영 체제 사용자 지정은 운영 체제 업데이트 중에 보존되지 않습니다.
+ 업데이트를 적용하기 전에 수동 스냅샷을 생성하는 것이 좋습니다.
# Amazon RDS Custom for SQL Server DB 인스턴스 업그레이드
새 DB 엔진 버전을 사용하도록 수정하여 Amazon RDS Custom for SQL Server DB 인스턴스를 업그레이드할 수 있습니다. DB 인스턴스 업그레이드에 대한 일반적인 정보는 [DB 인스턴스 엔진 버전 업그레이드](USER_UpgradeDBInstance.Upgrading.md) 섹션을 참조하세요.
**Topics**
+ [RDS Custom for SQL Server 업그레이드 개요](#custom-upgrading-sqlserver.Overview)
+ [메이저 및 마이너 엔진 버전 업그레이드](#custom-upgrading-sqlserver.Upgrade)
+ [데이터베이스 호환성 수준](#custom-upgrading-sqlserver.Major.Compatibility)
## RDS Custom for SQL Server 업그레이드 개요
Amazon RDS Custom for SQL Server는 메이저 및 마이너 버전 업그레이드를 지원합니다. 마이너 버전 업그레이드에는 보안 패치, 버그 수정 및 엔진 개선 기능이 포함될 수 있습니다. Microsoft는 이러한 업데이트를 누적 업데이트(CU)로 릴리스합니다. 메이저 버전 업그레이드는 SQL Server 2019에서 2022로 업그레이드하는 것처럼 버전 간에 새로운 기능과 엔진 변경 사항을 도입합니다. 두 업그레이드를 즉시 적용하거나 예약된 유지 관리 기간 동안 적용할 수 있습니다. 잠재적인 이전 버전과의 호환성 문제를 방지하기 위해 업그레이드하기 전에 비프로덕션 환경에서 애플리케이션을 테스트하는 것이 좋습니다.
RDS Custom for SQL Server에서는 RDS 제공 엔진 버전(RPEV) 또는 사용자 지정 엔진 버전(CEV)을 업그레이드할 수 있습니다.
+ RDS 제공 엔진 버전(RPEV)에는 최신 운영 체제(OS) 패치와 SQL Server 누적 업데이트(CU)가 포함되어 있습니다.
+ 사용자 지정 엔진 버전(CEV)의 경우 2단계 프로세스를 따라야 합니다. 먼저 대상 SQL Server 버전으로 새 CEV를 생성합니다. [RDS Custom for SQL Server용 CEV 생성 준비](custom-cev-sqlserver.preparing.md) 섹션을 참조하세요. 이 대상 버전은 현재 버전과 같거나 더 최신 버전이어야 합니다. 새 CEV가 생성되면 이 새 버전을 사용하도록 데이터베이스 인스턴스를 수정합니다. 자세한 내용은 [다중 AZ를 사용하여 Amazon RDS Custom for SQL Server CEV에 대한 마이너 버전 업그레이드 수행](https://aws.amazon.com/blogs/database/performing-a-minor-version-upgrade-for-amazon-rds-custom-for-sql-server-cev-with-multi-az/)을 참조하세요.
실행 중인 RDS Custom 인스턴스에 SQL Server 누적 인플레이스 업데이트를 적용하지 마세요. 특정 SQL Server 버전(예: SQL Server 2022 CU16)으로 CEV를 생성한 경우 인스턴스에 직접 최신 누적 업데이트를 적용하면 지원 경계에서 벗어나 `SP-S3006` 오류를 보고합니다. CEV를 사용하여 기존 SQL Server 인스턴스를 패치하려면 원하는 누적 업데이트가 포함된 새 CEV를 생성한 다음 기존 인스턴스를 수정하여 새 CEV로 전환합니다.
다중 AZ 배포에서 RDS Custom for SQL Server DB 인스턴스를 업그레이드하는 경우 RDS Custom for SQL Server가 인스턴스에 대한 롤링 업그레이드를 수행합니다. 이 접근 방식은 한 번에 하나의 인스턴스를 업그레이드하여 가동 중지 시간을 최소화합니다. RDS는 롤링 업그레이드를 위해 다음 작업을 수행합니다.
1. 대기 DB 인스턴스를 업그레이드합니다.
1. 업그레이드된 대기 DB 인스턴스로 장애 조치하여 이를 새 기본 DB 인스턴스로 만듭니다.
1. 새 대기 DB 인스턴스를 업그레이드합니다.
다중 AZ 배포의 DB 인스턴스 가동 중지 시간은 장애 조치에 걸리는 시간입니다.
RDS Custom for SQL Server DB 인스턴스를 업그레이드할 때는 다음과 같은 제한 사항이 적용됩니다.
+ Custom DB 옵션 및 파라미터 그룹은 지원되지 않습니다.
+ RDS Custom for SQL Server DB 인스턴스에 연결하는 추가 스토리지 볼륨은 업그레이드 후에 연결되지 않습니다.
+ CEV의 경우 SQL Server 누적 업데이트의 인플레이스 적용은 지원되지 않으므로 인스턴스가 지원 경계에서 제거됩니다.
## 메이저 및 마이너 엔진 버전 업그레이드
메이저 및 마이너 엔진 버전 업그레이드는 모두 되돌릴 수 없으며 항상 더 최신 버전으로 업그레이드를 수행해야 합니다. 사용 가능한 대상 버전을 식별하려면 AWS Management Console을 사용하고 DB 인스턴스를 수정할 때 사용 가능한 버전 중에서 선택합니다. 또는 [https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html) CLI 명령 또는 [DescribeDBEngineVersions](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBEngineVersions.html) RDS API 명령을 사용합니다.
대상 LinuxmacOS, 또는Unix:
```
aws rds describe-db-engine-versions \
--engine custom-sqlserver-se \
--engine-version 15.00.4322.2.v1 \
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" \
--output table
```
Windows의 경우:
```
aws rds describe-db-engine-versions ^
--engine custom-sqlserver-se ^
--engine-version 15.00.4322.2.v1 ^
--query "DBEngineVersions[*].ValidUpgradeTarget[*].{EngineVersion:EngineVersion}" ^
--output table
```
출력에는 사용 가능한 대상 엔진 버전이 표시됩니다.
```
--------------------------
|DescribeDBEngineVersions|
+------------------------+
| EngineVersion |
+------------------------+
| 15.00.4410.1.v1 |
| 15.00.4415.2.v1 |
| 15.00.4430.1.v1 |
| 16.00.4165.4.v1 |
| 16.00.4175.1.v1 |
| 16.00.4185.3.v1 |
+------------------------+
```
대상 버전을 식별한 후 AWS Management Console을 사용하고 [RDS Custom for SQL Server DB 인스턴스 수정](custom-managing.modify-sqlserver.md)의 지침을 따릅니다. 또는 [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) CLI 명령 또는 [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) RDS API 명령을 사용합니다.
대상 LinuxmacOS, 또는Unix:
```
aws rds modify-db-instance \
--db-instance-identifier DB_INSTANCE_IDENTIFIER \
--engine-version ENGINE_VERSION \
--allow-major-version-upgrade \
--region Region \
--no-apply-immediately
```
Windows의 경우:
```
aws rds modify-db-instance ^
--db-instance-identifier DB_INSTANCE_IDENTIFIER ^
--engine-version ENGINE_VERSION ^
--allow-major-version-upgrade ^
--region Region ^
--no-apply-immediately
```
**참고**
메이저 버전 업그레이드를 수행하려면 `--allow-major-version-upgrade` 파라미터를 포함해야 합니다.
## 데이터베이스 호환성 수준
Microsoft SQL Server 데이터베이스 호환성 수준을 이용해 일부 데이터베이스 동작이 이전 버전의 SQL Server를 모방하도록 조정할 수 있습니다. 자세한 내용은 Microsoft 설명서의 [호환성 수준](https://msdn.microsoft.com/en-us/library/bb510680.aspx)을 참조하십시오.
DB 인스턴스를 업그레이드할 때 기존의 모든 데이터베이스는 원래 호환성 수준으로 유지됩니다. 예를 들어, SQL Server 2019에서 SQL Server 2022로 업그레이드할 경우 모든 기존 데이터베이스의 호환성 수준은 150입니다. 업그레이드 이후에 생성된 새 데이터베이스의 호환성 수준은 160입니다.
ALTER DATABASE 명령을 사용하여 데이터베이스의 호환성 수준을 변경할 수 있습니다. 예를 들어, `customeracct`라는 이름의 데이터베이스를 SQL Server 2022와 호환되도록 변경하려면 다음 명령을 실행합니다.
```
1. ALTER DATABASE customeracct SET COMPATIBILITY_LEVEL = 160
```
# Amazon RDS Custom for SQL Server의 DB 문제 해결
RDS Custom의 공동 책임 모델은 OS 셸 수준 액세스 권한과 데이터베이스 관리자 액세스 권한을 제공합니다. RDS Custom은 시스템 계정에서 리소스를 실행하는 Amazon RDS와 달리 계정에서 리소스를 실행합니다. 접근 권한이 높을수록 책임도 커집니다. 다음 섹션에서는 Amazon RDS Custom for SQL Server DB 인스턴스의 문제를 해결하는 방법을 알아볼 수 있습니다.
**참고**
이 섹션에서는 RDS Custom for SQL Server의 문제를 해결하는 방법을 설명합니다. RDS Custom for Oracle 관련 문제 해결을 보려면 [Amazon RDS Custom for Oracle의 DB 문제 해결](custom-troubleshooting.md) 섹션을 참조하세요.
**Topics**
+ [RDS Custom 이벤트 보기](#custom-troubleshooting-sqlserver.support-perimeter.viewing-events)
+ [RDS Custom 이벤트 구독](#custom-troubleshooting-sqlserver.support-perimeter.subscribing)
+ [RDS Custom for SQL Server의 CEV 오류 문제 해결](#custom-troubleshooting-sqlserver.cev)
+ [RDS Custom for SQL Server에서 지원되지 않는 구성 문제 해결](#custom-troubleshooting-sqlserver.fix-unsupported)
+ [RDS Custom for SQL Server에서 `Storage-Full` 문제 해결](#custom-troubleshooting-storage-full)
+ [RDS Custom for SQL Server에서 TDE 지원 데이터베이스의 PENDING\$1RECOVERY 상태 문제 해결](#custom-troubleshooting-sqlserver.pending_recovery)
## RDS Custom 이벤트 보기
RDS Custom 및 Amazon RDS DB 인스턴스의 이벤트 보기 절차는 동일합니다. 자세한 내용은 [Amazon RDS 이벤트 보기](USER_ListEvents.md) 섹션을 참조하세요.
`describe-events` 명령을 사용하여 AWS CLI를 통해 RDS Custom 이벤트 알림을 볼 수 있습니다. RDS Custom에서는 몇 가지 새로운 이벤트가 도입되었습니다. 이벤트 카테고리는 Amazon RDS와 동일합니다. 이벤트 목록은 [Amazon RDS 이벤트 카테고리 및 이벤트 메시지](USER_Events.Messages.md) 섹션을 참조하세요.
다음 예제에서는 지정된 RDS Custom DB 인스턴스에 대해 발생한 이벤트의 세부 정보를 검색합니다.
```
1. aws rds describe-events \
2. --source-identifier my-custom-instance \
3. --source-type db-instance
```
## RDS Custom 이벤트 구독
RDS Custom 및 Amazon RDS DB 인스턴스의 이벤트 구독 절차는 동일합니다. 자세한 내용은 [Amazon RDS 이벤트 알림 구독](USER_Events.Subscribing.md) 섹션을 참조하세요.
CLI를 사용하여 RDS Custom 이벤트 알림을 구독하려면 `create-event-subscription` 명령을 사용하면 되며, 다음 필수 파라미터를 포함합니다.
+ `--subscription-name`
+ `--sns-topic-arn`
다음 예제에서는 현재 AWS 계정에서 RDS Custom DB 인스턴스의 백업 및 복구 이벤트에 대한 구독을 생성합니다. 알림은 `--sns-topic-arn`에서 지정한 Amazon Simple Notification Service(Amazon SNS) 주제로 전송됩니다.
```
1. aws rds create-event-subscription \
2. --subscription-name my-instance-events \
3. --source-type db-instance \
4. --event-categories '["backup","recovery"]' \
5. --sns-topic-arn arn:aws:sns:us-east-1:123456789012:interesting-events
```
## RDS Custom for SQL Server의 CEV 오류 문제 해결
CEV 생성이 실패할 수 있습니다. 이 경우 RDS Custom이 `RDS-EVENT-0198` 이벤트 메시지를 표시합니다. RDS 이벤트 보기에 대한 자세한 내용은 [Amazon RDS 이벤트 카테고리 및 이벤트 메시지](USER_Events.Messages.md) 단원을 참조하세요.
다음 정보를 사용하면 가능한 원인을 해결하는 데 도움이 됩니다.
****
| 메시지 | 문제 해결 제안 |
| --- | --- |
| `Custom Engine Version creation expected a Sysprep’d AMI. Retry creation using a Sysprep’d AMI.` | AMI에서 생성한 EC2 인스턴스에서 Sysprep을 실행합니다. Sysprep을 사용한 AMI 준비에 대한 자세한 내용은 [Sysprep을 사용하여 표준화된 Amazon Machine Image(AMI) 생성](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/Creating_EBSbacked_WinAMI.html#sysprep-using-ec2launchv2)을 참조하세요. |
| `EC2 Image permissions for image (AMI_ID) weren't found for customer (Customer_ID). Verify customer (Customer_ID) has valid permissions on the EC2 Image.` | 생성에 사용한 계정 및 프로필에 선택한 AMI의 `create EC2 Instance` 및 `Describe Images`에 대한 필수 권한이 있는지 확인합니다. |
| `Failed to rebuild databases with server collation (collation name) due to missing setup.exe file for SQL Server.` | `C:\Program Files\Microsoft SQL Server\nnn\Setup Bootstrap\SQLnnnn\setup.exe`에서 `setup` 파일을 사용할 수 있는지 확인합니다. |
| `Image (AMI_ID) doesn't exist in your account (ACCOUNT_ID). Verify (ACCOUNT_ID) is the owner of the EC2 image.` | AMI가 동일한 고객 계정에 있는지 확인합니다. |
| `Image id (AMI_ID) isn't valid. Specify a valid image id, and try again.` | AMI 이름이 잘못되었습니다. 올바른 AMI ID가 제공되었는지 확인합니다. |
| `Image (AMI_ID) operating system platform isn't supported. Specify a valid image, and try again.` | SQL Server Enterprise, Standard 또는 Web Edition을 포함하는 Windows Server가 있는 지원되는 AMI를 선택하세요. EC2 Marketplace에서 다음 사용 작업 코드 중 하나를 사용하여 AMI를 선택합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/custom-troubleshooting-sqlserver.html) |
| `SQL Server Web Edition isn't supported for creating a Custom Engine Version using Bring Your Own Media. Specify a valid image, and try again.` | 지원되는 에디션의 SQL Server가 포함된 AMI를 사용하세요. 자세한 내용은 [RDS Custom for SQL Server CEV에 대한 버전 지원](custom-cev-sqlserver.preparing.md#custom-cev-sqlserver.preparing.VersionSupport) 섹션을 참조하세요. |
| `The custom engine version can't be the same as the OEV engine version. Specify a valid CEV, and try again.` | 클래식 RDS Custom for SQL Server 엔진 버전은 지원되지 않습니다. 예를 들어 **15.00.4073.23.v1** 버전은 지원되지 않습니다. 지원되는 버전 번호를 사용하세요. |
| `The custom engine version isn't in an active state. Specify a valid CEV, and try again.` | 작업을 완료하려면 CEV가 `AVAILABLE` 상태여야 합니다. CEV를 `INACTIVE`에서 `AVAILABLE`로 수정합니다. |
| `The custom engine version isn't valid for an upgrade. Specify a valid CEV with an engine version greater or equal to (X), and try again.` | 대상 CEV가 유효하지 않습니다. 유효한 업그레이드 경로에 대한 요구 사항을 확인하세요. |
| `The custom engine version isn't valid. Names can include only lowercase letters (a-z), dashes (-), underscores (_), and periods (.). Specify a valid CEV, and try again.` | 필수 CEV 명명 규칙에 따르세요. 자세한 내용은 [RDS Custom for SQL Server CEV 요구 사항](custom-cev-sqlserver.preparing.md#custom-cev-sqlserver.preparing.Requirements) 섹션을 참조하세요. |
| `The custom engine version isn't valid. Specify valid database engine version, and try again. Example: 15.00.4073.23-cev123.` | 지원되지 않는 DB 엔진 버전이 제공되었습니다. 지원되는 DB 엔진 버전을 사용하세요. |
| `The expected architecture is (X) for image (AMI_ID), but architecture (Y) was found.` | **x86\$164** 아키텍처를 기반으로 구축된 AMI를 사용하세요. |
| `The expected owner of image (AMI_ID) is customer account ID (ACCOUNT_ID), but owner (ACCOUNT_ID) was found.` | 권한이 있는 AMI에서 EC2 인스턴스를 생성하세요. EC2 인스턴스에서 Sysprep을 실행하여 기본 이미지를 생성하고 저장하세요. |
| `The expected platform is (X) for image (AMI_ID), but platform (Y) was found.` | Windows 플랫폼으로 구축된 AMI를 사용하세요. |
| `The expected root device type is (X) for image %s, but root device type (Y) was found.` | EBS 디바이스 유형을 사용하여 AMI를 생성하세요. |
| `The expected SQL Server edition is (X), but (Y) was found.` | SQL Server Enterprise, Standard 또는 Web Edition을 포함하는 Windows Server가 있는 지원되는 AMI를 선택하세요. EC2 Marketplace에서 다음 사용 작업 코드 중 하나를 사용하여 AMI를 선택합니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/custom-troubleshooting-sqlserver.html) |
| `The expected state is (X) for image (AMI_ID), but the following state was found: (Y).` | AMI가 `AVAILABLE` 상태인지 확인하세요. |
| `The provided Windows OS name (X) isn’t valid. Make sure the OS is one of the following: (Y).` | 지원되는 Windows OS를 사용하세요. |
| `Unable to find bootstrap log file in path.` | `C:\Program Files\Microsoft SQL Server\nnn\Setup Bootstrap\Log\Summary.txt`에서 로그 파일을 사용할 수 있는지 확인합니다. |
| `RDS expected a Windows build version greater than or equal to (X), but found version (Y).`. | 최소 OS 빌드 버전이 **14393**인 AMI를 사용하세요. |
| `RDS expected a Windows major version greater than or equal to (X), but found version (Y).`. | 최소 OS 메이저 버전이 **10.0** 이상인 AMI를 사용하세요. |
## RDS Custom for SQL Server에서 지원되지 않는 구성 문제 해결
공유 책임 모델이므로 RDS Custom for SQL Server DB 인스턴스를 `unsupported-configuration` 상태로 전환시키는 구성 문제는 사용자가 해결해야 합니다. AWS 인프라와 관련된 문제인 경우 콘솔 또는 AWS CLI를 사용하여 해결할 수 있습니다. 운영 체제 또는 데이터베이스 구성에 문제가 있는 경우 호스트에 로그인하여 해결하면 됩니다.
**참고**
이 섹션에서는 RDS Custom for SQL Server에서 지원되지 않는 구성 문제를 해결하는 방법을 알아봅니다. RDS Custom for Oracle에 대한 자세한 내용은 [RDS Custom for Oracle에서 지원되지 않는 구성 문제 해결](custom-troubleshooting.md#custom-troubleshooting.fix-unsupported) 섹션을 참조하세요.
다음 표에는 지원 경계에서 보내는 알림 이벤트와 이를 해결하는 방법에 대한 설명이 나와 있습니다. 이러한 알림과 지원 경계는 변경될 수 있습니다. 지원 경계의 배경은 [RDS Custom 지원 범위](custom-concept.md#custom-troubleshooting.support-perimeter) 섹션을 참조하세요. 이벤트 설명은 [Amazon RDS 이벤트 카테고리 및 이벤트 메시지](USER_Events.Messages.md) 섹션을 참조하세요.
| 이벤트 코드 | 구성 영역 | RDS 이벤트 메시지 | 검증 프로세스 |
| --- | --- | --- | --- |
| `SP-S0000` | 지원되지 않는 수동 구성 | RDS Custom DB 인스턴스 상태가 [지원되지 않는 구성]으로 설정된 이유는 다음과 같습니다. `X` | 이 문제를 해결하려면 지원 사례를 생성하세요. |
**AWS 리소스(인프라)**
| 이벤트 코드 | 구성 영역 | RDS 이벤트 메시지 | 검증 프로세스 |
| --- | --- | --- | --- |
| `SP-S1001` | EC2 인스턴스 상태 | RDS Custom DB 인스턴스 상태가 [지원되지 않는 구성](으)로 설정된 이유는 다음과 같습니다. 기본 EC2 인스턴스 %s이(가) RDS 인스턴스를 중단하지 않고 중지되었습니다. 기본 EC2 인스턴스를 시작하고 이진 볼륨 및 데이터 볼륨이 연결되어 있는지 확인하여 문제를 해결할 수 있습니다. RDS 인스턴스를 중지하려는 경우 먼저 기본 EC2 인스턴스가 AVAILABLE 상태인지 확인한 다음 RDS 콘솔 또는 CLI를 사용하여 RDS 인스턴스를 중지해야 합니다. | DB 인스턴스의 상태를 확인하려면 콘솔을 사용하거나 다음 AWS CLI 명령을 실행합니다. aws rds describe-db-instances \
--db-instance-identifier db-instance-name |grep DBInstanceStatus
|
| `SP-S1002` | EC2 인스턴스 상태 | RDS Custom DB 인스턴스 상태가 [지원되지 않는 구성](으)로 설정된 이유는 다음과 같습니다. RDS DB 인스턴스 상태는 `STOPPED`로 설정되었지만, 기본 EC2 인스턴스 %s이(가) 시작되었습니다. 기본 EC2 인스턴스를 중지하여 문제를 해결할 수 있습니다. RDS 인스턴스를 시작하려는 경우 콘솔 또는 CLI를 사용하세요. | 다음 AWS CLI 명령을 사용하여 DB 인스턴스의 상태를 확인합니다. aws rds describe-db-instances \
--db-instance-identifier db-instance-name |grep DBInstanceStatus
EC2 콘솔을 사용하여 EC2 인스턴스의 상태를 확인할 수도 있습니다. DB 인스턴스를 시작하려면 콘솔을 사용하거나 다음 AWS CLI 명령을 실행합니다. aws rds start-db-instance \
--db-instance-identifier db-instance-name
|
| `SP-S1003` | EC2 인스턴스 클래스 | RDS Custom DB 인스턴스 상태가 [지원되지 않는 구성](으)로 설정된 이유는 다음과 같습니다. EC2 호스트의 예상 DB 인스턴스 클래스와 구성된 DB 인스턴스 클래스 간에 불일치가 있습니다. DB 인스턴스 클래스를 원래 클래스 유형으로 수정하여 문제를 해결할 수 있습니다. | 다음 CLI 명령을 사용하여 예상 DB 인스턴스 클래스를 확인합니다. aws rds describe-db-instances \
--db-instance-identifier db-instance-name |grep DBInstanceClass
|
| `SP-S1004` | EBS 스토리지 볼륨에 액세스할 수 없음 | RDS Custom DB 인스턴스 상태가 [지원되지 않는 구성](으)로 설정된 이유는 다음과 같습니다. EC2 인스턴스에 연결된 원래 EBS 스토리지 볼륨 %s에 현재 액세스할 수 없습니다. | |
| `SP-S1005` | EBS 스토리지 볼륨이 분리됨 | RDS Custom DB 인스턴스 상태가 [지원되지 않는 구성](으)로 설정된 이유는 다음과 같습니다. 원본 EBS 스토리지 볼륨 'volume-id'가 연결되지 않았습니다. EC2 인스턴스에 연결된 EBS 볼륨을 연결하여 문제를 해결할 수 있습니다. | EBS 볼륨을 다시 연결한 후 다음 CLI 명령을 사용하여 EBS 볼륨 'volume-id'가 RDS 인스턴스에 제대로 연결되어 있는지 확인합니다. aws ec2 describe-volumes \
--volume-ids volume-id |grep InstanceId
|
| `SP-S1006` | EBS 스토리지 볼륨 크기 | RDS Custom DB 인스턴스 상태가 [지원되지 않는 구성](으)로 설정된 이유는 다음과 같습니다. EBS 스토리지 볼륨 'volume-id'의 예상 설정과 구성된 설정이 일치하지 않습니다. EC2 수준에서 볼륨 크기가 원래 값인 [%s]에서 수동으로 변경되었습니다. 이 문제를 해결하려면 지원 사례를 생성하세요. | 다음 CLI 명령을 사용하여 EBS 볼륨 'volume-id' 세부 정보와 RDS 인스턴스 세부 정보의 볼륨 크기를 비교합니다. aws rds describe-db-instances \
--db-instance-identifier db-instance-name |grep AllocatedStorage
다음 CLI 명령을 사용하여 실제 할당된 볼륨 크기를 확인합니다. aws ec2 describe-volumes \
--volume-ids |grep Size
|
| `SP-S1007` | EBS 스토리지 볼륨 구성 | RDS Custom DB 인스턴스 상태가 [지원되지 않는 구성](으)로 설정된 이유는 다음과 같습니다. EBS 스토리지 볼륨 'volume-id'의 예상 설정과 구성된 설정이 일치하지 않습니다. EBS 스토리지 볼륨 구성 [IOPS, 처리량, 볼륨 유형]을 EC2 수준에서 원래 값인 [IOPS: %s, 처리량: %s, 볼륨 유형: %s]로 수정하여 문제를 해결할 수 있습니다. 향후 스토리지 수정에는 RDS 콘솔 또는 CLI를 사용하세요. EC2 수준에서 볼륨 크기도 원래 값인 [%s]에서 수동으로 변경되었습니다. 이 문제를 해결하려면 지원 사례를 생성하세요. | 다음 CLI 명령을 사용하여 EBS 볼륨 'volume-id' 세부 정보의 볼륨 유형과 RDS 인스턴스 세부 정보를 비교합니다. EBS 수준의 값이 RDS 수준의 값과 일치하는지 확인하세요. aws rds describe-db-instances \
--db-instance-identifier db-instance-name |grep StorageType
RDS 수준에서 스토리지 처리량의 예상 값을 구하는 방법: aws rds describe-db-instances \
--db-instance-identifier db-instance-name |grep StorageThroughput
RDS 수준에서 볼륨 IOPS의 예상 값을 구하는 방법: aws rds describe-db-instances \
--db-instance-identifier db-instance-name |grep Iops
EC2 수준에서 현재 스토리지 유형을 가져오는 방법: aws ec2 describe-volumes \
--volume-ids |grep VolumeType
EC2 수준에서 스토리지 처리량의 현재 값을 구하는 방법: aws ec2 describe-volumes \
--volume-ids |grep Throughput
EC2 수준에서 볼륨 IOPS의 현재 값을 구하는 방법: aws ec2 describe-volumes \
--volume-ids |grep Iops
|
| `SP-S1008` | EBS 스토리지 볼륨 크기 및 구성 | RDS Custom DB 인스턴스 상태가 [지원되지 않는 구성](으)로 설정된 이유는 다음과 같습니다. EBS 스토리지 볼륨 'volume-id'의 예상 설정과 구성된 설정이 일치하지 않습니다. EBS 스토리지 볼륨 구성 [IOPS, 처리량, 볼륨 유형]을 EC2 수준에서 원래 값인 [IOPS: %s, 처리량: %s, 볼륨 유형: %s]로 수정하여 문제를 해결할 수 있습니다. 향후 스토리지 수정에는 RDS 콘솔 또는 CLI를 사용하세요. EC2 수준에서 볼륨 크기도 원래 값인 [%s]에서 수동으로 변경되었습니다. 이 문제를 해결하려면 지원 사례를 생성하세요. | 다음 CLI 명령을 사용하여 EBS 볼륨 'volume-id' 세부 정보의 볼륨 유형과 RDS 인스턴스 세부 정보를 비교합니다. EBS 수준의 값이 RDS 수준의 값과 일치하는지 확인하세요. aws rds describe-db-instances \
--db-instance-identifier db-instance-name |grep StorageType
RDS 수준에서 스토리지 처리량의 예상 값을 구하는 방법: aws rds describe-db-instances \
--db-instance-identifier db-instance-name |grep StorageThroughput
RDS 수준에서 볼륨 IOPS의 예상 값을 구하는 방법: aws rds describe-db-instances \
--db-instance-identifier db-instance-name |grep Iops
EC2 수준에서 현재 스토리지 유형을 가져오는 방법: aws ec2 describe-volumes \
--volume-ids |grep VolumeType
EC2 수준에서 스토리지 처리량의 현재 값을 구하는 방법: aws ec2 describe-volumes \
--volume-ids |grep Throughput
EC2 수준에서 볼륨 IOPS의 현재 값을 구하는 방법: aws ec2 describe-volumes \
--volume-ids |grep Iops
예상 할당된 볼륨 크기를 구하는 방법: aws rds describe-db-instances \
--db-instance-identifier db-instance-name |grep AllocatedStorage
실제 할당된 볼륨 크기를 구하는 방법: aws ec2 describe-volumes \
--volume-ids |grep Size
|
| `SP-S1009` | SQS 권한 | RDS Custom DB 인스턴스 상태가 [지원되지 않는 구성](으)로 설정된 이유는 다음과 같습니다. IAM 인스턴스 프로파일에 대한 Amazon Simple Queue Service(Amazon SQS) 권한이 누락되었습니다. 호스트와 연결된 IAM 프로파일에 ["SQS:SendMessage","SQS:ReceiveMessage","SQS:DeleteMessage","SQS:GetQueueUrl"] 권한이 있는지 확인하여 문제를 해결할 수 있습니다. | |
| `SP-S1010` | SQS VPC 엔드포인트 | RDS Custom DB 인스턴스 상태가 [지원되지 않는 구성](으)로 설정된 이유는 다음과 같습니다. VPC 엔드포인트 정책이 Amazon Simple Queue Service(Amazon SQS) 작업을 차단하고 있습니다. 필요한 SQS 작업을 허용하도록 VPC 엔드포인트 정책을 수정하여 문제를 해결할 수 있습니다. | |
| `SP-S1011` | 이벤트 버스 정책 | RDS Custom DB 인스턴스 상태가 다음과 같은 이유로 [지원되지 않는 구성]으로 설정되었습니다. 이벤트 버스 arn:aws:events:region-1:123456789012:event-bus/default에 대한 리소스 기반 정책이 Amazon CloudWatch events:PutEvents 작업을 거부함. EventBus %s에 대한 events:PutEvents 작업을 허용하도록 리소스 기반 정책을 수정하여 이 문제를 해결하세요. | |
| `SP-S1012` | CloudWatch VPC 권한 | RDS Custom DB 인스턴스 상태가 다음과 같은 이유로 [지원되지 않는 구성]으로 설정되었습니다. VPC 엔드포인트 정책에 Amazon CloudWatch 이벤트에 액세스할 수 있는 권한이 누락됨. EventBus arn:aws:events:region-1:123456789012:event-bus/default에 대해 events:PutEvents를 허용하도록 VPC 엔드포인트 정책을 수정하여 이 문제를 해결하세요. | |
| `SP-S1013` | 서비스 제어 정책 | RDS Custom DB 인스턴스 상태가 다음과 같은 이유로 [지원되지 않는 구성]으로 설정되었습니다. AWS Organizations의 서비스 제어 정책에 Amazon CloudWatch 이벤트에 액세스할 수 있는 권한이 누락됨. EventBus arn:aws:events:region-1:123456789012:event-bus/default에 대해 events:PutEvents를 허용하도록 서비스 제어 정책을 수정하여 이 문제를 해결하세요. | |
| `SP-S1014` | IAM 인스턴스 프로파일 | RDS Custom DB 인스턴스 상태가 다음과 같은 이유로 [지원되지 않는 구성]으로 설정되었습니다. IAM 인스턴스 프로파일 %s 권한이 Amazon CloudWatch 이벤트를 거부함. 인스턴스와 연결된 IAM 프로파일에서 ["events:PutEvents"]를 'Allow'로 설정하고 EventBus arn:aws:events:region-1:123456789012:event-bus/default에 대해 events:PutEvents를 허용하여 이 문제를 해결하세요. | |
| `SP-S1015` | IAM 인스턴스 프로파일 | RDS Custom DB 인스턴스 상태가 다음과 같은 이유로 [지원되지 않는 구성]으로 설정되었습니다. IAM 인스턴스 프로파일 %s에 Amazon CloudWatch 권한이 누락됨. 인스턴스와 연결된 IAM 프로파일에서 ["events:PutEvents"] 권한을 포함하고 EventBus arn:aws:events:region-1:123456789012:event-bus/default에 대해 events:PutEvents를 허용하여 이 문제를 해결하세요. | |
| `SP-S1016` | IAM 권한 경계 | RDS Custom DB 인스턴스 상태가 다음과 같은 이유로 [지원되지 않는 구성]으로 설정되었습니다. IAM 인스턴스 프로파일 %s 권한에 Amazon CloudWatch 이벤트를 거부하는 권한 경계가 있음. IAM 인스턴스 프로파일 권한 경계에서 EventBus arn:aws:events:region-1:123456789012:event-bus/default에 대해 ["events:PutEvents"]를 'Allow'로 설정하여 이 문제를 해결하세요. | |
**운영 체제**
| 이벤트 코드 | 구성 영역 | RDS 이벤트 메시지 | 검증 프로세스 |
| --- | --- | --- | --- |
| `SP-S2001` | SQL 서비스 상태 | RDS Custom DB 인스턴스 상태가 [지원되지 않는 구성](으)로 설정된 이유는 다음과 같습니다. SQL Server 서비스가 시작되지 않았습니다. 호스트에서 SQL Server 서비스를 다시 시작하여 문제를 해결할 수 있습니다. 이 DB 인스턴스가 다중 AZ DB 인스턴스이고 재시작이 실패할 경우 호스트를 중지하고 시작하여 장애 조치를 시작합니다. | |
| `SP-S2002` | RDS Custom 에이전트 상태 | RDS Custom DB 인스턴스 상태가 [지원되지 않는 구성](으)로 설정된 이유는 다음과 같습니다. RDS Custom 에이전트 서비스가 설치되지 않았거나 시작할 수 없습니다. Windows 이벤트 로그를 검토하여 서비스가 시작되지 않는 이유를 확인하고 적절한 조치를 취하여 문제를 수정하면 해결할 수 있습니다. 추가 지원이 필요한 경우 지원 사례를 생성하세요. | 호스트에 로그인하고 RDS Custom 에이전트가 실행 중인지 확인합니다. 다음 명령을 사용하여 에이전트 상태를 볼 수 있습니다. $name = "RDSCustomAgent"
$service = Get-Service $name
Write-Host $service.Status
상태가 `Running`이 아니면 다음 명령을 사용하여 서비스를 시작할 수 있습니다. Start-Service $name
에이전트를 시작할 수 없는 경우 Windows 이벤트를 확인하여 에이전트를 시작할 수 없는 이유를 확인합니다. 에이전트를 사용하려면 Windows 사용자가 서비스를 시작해야 합니다. Windows 사용자가 존재하고 서비스를 실행할 권한이 있는지 확인하세요. |
| `SP-S2003` | SSM 에이전트 상태 | RDS Custom DB 인스턴스 상태가 [지원되지 않는 구성](으)로 설정된 이유는 다음과 같습니다. Amazon SSM 에이전트 서비스에 연결할 수 없습니다. `Get-Service AmazonSSMAgent` PowerShell 명령으로 서비스 상태를 확인하거나 `Start-Service AmazonSSMAgent`로 서비스를 시작하여 문제를 해결할 수 있습니다. **ssm**, **ssmmessages**, **ec2messages** 리전 엔드포인트에 대한 HTTPS(포트 443) 아웃바운드 트래픽이 허용되는지 확인하세요. | 자세한 내용은 [SSM Agent 문제 해결](https://docs.aws.amazon.com/systems-manager/latest/userguide/troubleshooting-ssm-agent.html)을 참조하세요. SSM 엔드포인트 문제를 해결하려면 [SSM 엔드포인트에 연결할 수 없음](https://docs.aws.amazon.com/systems-manager/latest/userguide/troubleshooting-ssm-agent.html#systems-manager-ssm-agent-troubleshooting-endpoint-access) 및 [ssm-cli를 사용하여 관리형 노드 가용성 문제 해결](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-cli.html#agent-ts-ssm-cli)을 참조하세요. |
| `SP-S2004` | RDS Custom 에이전트 로그인 | RDS Custom DB 인스턴스 상태가 [지원되지 않는 구성](으)로 설정된 이유는 다음과 같습니다. SQL 로그인 `"$HOSTNAME/RDSAgent”`에서 예상치 못한 문제가 발생했습니다. 이 문제를 해결하려면 지원 사례를 생성하세요. | |
| `SP-S2005` | Timezone | RDS Custom DB 인스턴스 상태가 [지원되지 않는 구성](으)로 설정된 이유는 다음과 같습니다. Amazon EC2 인스턴스 [%s]의 시간대가 변경되었습니다. 인스턴스 생성 시 지정된 설정으로 시간대를 다시 수정하여 문제를 해결할 수 있습니다. 특정 시간대의 인스턴스를 만들려면 RDS Custom 설명서를 참조하세요. | `Get-Timezone` PowerShell 명령을 실행하여 시간대를 확인합니다. 자세한 내용은 [RDS Custom for SQL Server DB 인스턴스의 현지 시간대](custom-reqs-limits-MS.TimeZone.md) 섹션을 참조하세요. |
| `SP-S2006` | 고가용성 소프트웨어 솔루션 버전 | RDS Custom DB 인스턴스 상태가 [지원되지 않는 구성](으)로 설정된 이유는 다음과 같습니다. 현재 인스턴스의 고가용성 소프트웨어 솔루션이 예상 버전과 다릅니다. 이 문제를 해결하려면 지원 사례를 생성하세요. | |
| `SP-S2007` | 고가용성 소프트웨어 솔루션 구성 | RDS Custom DB 인스턴스 상태가 [지원되지 않는 구성](으)로 설정된 이유는 다음과 같습니다. 고가용성 소프트웨어 솔루션의 구성 설정이 %s 인스턴스에서 예상치 못한 값으로 수정되었습니다. 이 문제를 해결하려면 EC2 인스턴스를 재부팅합니다. EC2 인스턴스를 재부팅하면 설정이 고가용성 소프트웨어 솔루션에 필요한 구성으로 자동 업데이트됩니다. | |
| SP-S2008 | SQL Server 서비스 | RDS Custom DB 인스턴스가 [지원되지 않는 구성](으)로 설정되었습니다. SQLServer(MSSQLServer) 서비스가 호스트에 없습니다. 이 문제를 해결하려면 지원 사례를 만드세요. | 다음 명령을 사용하여 에이전트 상태를 볼 수 있습니다. $name = "MSSQLServer"
$service = Get-Service $name
Write-Host $service.Status
|
| SP-S2009 | SSL 인증서 | RDS 사용자 지정 DB 인스턴스는 RDS 중단을 유발하는 자체 서명되지 않은 SSL 인증서로 인해 [지원되지 않는 구성]으로 설정됩니다. 이 문제를 해결하려면 신뢰할 수 있는 루트 인증서 스토어에서 자체 서명되지 않은 인증서를 제거합니다. | 다음 PowerShell 명령을 실행하여 자체 서명되지 않은 인증서를 검토합니다. Get-ChildItem cert:\LocalMachine\root -Recurse | Where-Object {$_.Issuer -ne $_.Subject -and $_.Issuer -notlike "*RDSCustomAgentCA*"} 자세한 내용은 [HTTP Error 403.16 when you try to access a website that's hosted on IIS](https://learn.microsoft.com/en-us/troubleshoot/developer/webapps/iis/site-behavior-performance/http-403-forbidden-access-website)를 참조하시기 바랍니다. |
| SP-S2010 | 루트 볼륨 스토리지 상태 | RDS Custom DB 인스턴스 상태가 [지원되지 않는 구성]으로 설정된 이유는 루트 볼륨 스토리지가 가득 찼기 때문입니다. 이 문제를 해결하려면 루트 EBS 볼륨 ‘volume-id’에서 최소 500MiB의 스토리지 공간을 확보하거나 볼륨 크기를 늘리고 EC2 인스턴스 ‘instance-id’에서 C 드라이브 크기를 조정합니다. EC2 인스턴스를 교체하면 루트 볼륨 크기 변경 사항이 유지되지 않습니다. | 루트(C:) 볼륨에서 사용 가능한 스토리지를 보려면 다음 명령을 사용합니다. (Get-PSDrive -Name C).Free / 1MB
EBS 루트 볼륨 수정에 대한 자세한 내용은 [방법](https://forums.aws.amazon.com/knowledge-center/expand-ebs-root-volume-windows) 섹션을 참조하세요. |
**데이터베이스**:
| 이벤트 코드 | 구성 영역 | RDS 이벤트 메시지 | 검증 프로세스 |
| --- | --- | --- | --- |
| `SP-S3001` | SQL Server 공유 메모리 프로토콜 | RDS Custom DB 인스턴스 상태가 [지원되지 않는 구성](으)로 설정된 이유는 다음과 같습니다. SQL Server 공유 메모리 프로토콜이 비활성화되었습니다. SQL Server Configuration Manager에서 공유 메모리 프로토콜을 활성화하여 문제를 해결할 수 있습니다. | **SQL Server Configuration Manager > SQL Server 네트워크 구성 > MSSQLSERVER용 프로토콜 > 공유 메모리**에서 활성화됨 상태를 확인하면 됩니다. 프로토콜을 활성화한 후 SQL Server 프로세스를 다시 시작합니다. |
| `SP-S3002` | Service Master Key | RDS Custom DB 인스턴스 상태가 [지원되지 않는 구성](으)로 설정된 이유는 다음과 같습니다. RDS 자동화에서 새로운 Service Master Key(SMK) 생성의 일부로 SMK 백업을 수행할 수 없습니다. 이 문제를 해결하려면 지원 사례를 생성하세요. | |
| `SP-S3003` | Service Master Key | RDS Custom DB 인스턴스 상태가 [지원되지 않는 구성](으)로 설정된 이유는 다음과 같습니다. Service Master Key(SMK)와 관련된 메타데이터가 누락되었거나 불완전합니다. 이 문제를 해결하려면 지원 사례를 생성하세요. | |
| `SP-S3004` | DB 엔진 버전 및 에디션 | RDS Custom DB 인스턴스 상태가 [지원되지 않는 구성](으)로 설정된 이유는 다음과 같습니다. SQL Server의 필요한 버전 및 에디션과 설치된 버전 및 에디션 간에 불일치가 있습니다. RDS Custom for SQL Server에서 SQL Server 에디션 수정은 지원되지 않습니다. 또한 RDS Custom EC2 인스턴스에서 SQL Server 버전을 수동으로 변경하는 것도 지원되지 않습니다. 이 문제를 해결하려면 지원 사례를 생성하세요. | 다음 쿼리를 실행하여 SQL 버전을 가져옵니다. select @@version
다음 AWS CLI 명령을 실행하여 RDS SQL 엔진 버전 및 에디션을 가져옵니다. aws rds describe-db-instances \
--db-instance-identifier db-instance-name |grep EngineVersion
aws rds describe-db-instances \
--db-instance-identifier db-instance-name |grep Engine
자세한 내용은 [RDS Custom for SQL Server DB 인스턴스 수정](custom-managing.modify-sqlserver.md) 및 [DB 인스턴스 엔진 버전 업그레이드](USER_UpgradeDBInstance.Upgrading.md)(을)를 참조하세요. |
| `SP-S3005` | DB 엔진 에디션 | RDS Custom DB 인스턴스 상태가 [지원되지 않는 구성](으)로 설정된 이유는 다음과 같습니다. 현재 SQL Server 에디션이 필요한 SQL Server 에디션인 [%s]과(와) 일치하지 않습니다. RDS Custom for SQL Server에서 SQL Server 에디션 수정은 지원되지 않습니다. 이 문제를 해결하려면 지원 사례를 생성하세요. | 다음 쿼리를 실행하여 SQL 에디션을 가져옵니다.
**Example**
```
select @@version
``` 다음 AWS CLI 명령을 실행하여 RDS SQL 엔진 에디션을 가져옵니다. aws rds describe-db-instances \
--db-instance-identifier db-instance-name |grep Engine
|
| `SP-S3006` | DB 엔진 버전 | RDS Custom DB 인스턴스 상태가 [지원되지 않는 구성](으)로 설정된 이유는 다음과 같습니다. 현재 SQL Server 에디션이 필요한 SQL Server 에디션인 [%s]과(와) 일치하지 않습니다. RDS Custom EC2 인스턴스에서는 SQL Server 버전을 수동으로 변경할 수 없습니다. 이 문제를 해결하려면 지원 사례를 생성하세요. 향후 SQL Server 버전을 수정할 경우 AWS RDS 콘솔에서 또는 modify-db-instance CLI 명령을 통해 인스턴스를 수정할 수 있습니다. | 다음 쿼리를 실행하여 SQL 버전을 가져옵니다.
**Example**
```
select @@version
``` 다음 AWS CLI 명령을 실행하여 RDS SQL 엔진 버전을 가져옵니다. aws rds describe-db-instances \
--db-instance-identifier db-instance-name |grep EngineVersion
자세한 내용은 [RDS Custom for SQL Server DB 인스턴스 수정](custom-managing.modify-sqlserver.md) 및 [DB 인스턴스 엔진 버전 업그레이드](USER_UpgradeDBInstance.Upgrading.md)(을)를 참조하세요. |
| `SP-S3007` | 데이터베이스 파일 위치 | RDS Custom DB 인스턴스 상태가 [지원되지 않는 구성](으)로 설정된 이유는 다음과 같습니다. 데이터베이스 파일이 D:\$1 드라이브 외부에 구성되어 있습니다. ROW, LOG, FILESTREAM 등을 비롯한 모든 데이터베이스 파일이 D:\$1 드라이브에 저장되어 있는지 확인하여 문제를 해결할 수 있습니다. | 다음 쿼리를 실행하여 기본 경로에 없는 데이터베이스 파일의 위치를 나열합니다. USE master;
SELECT physical_name as files_not_in_default_path
FROM sys.master_files
WHERE SUBSTRING(physical_name,1,3)!='D:\';
|
| `SP-S3008` | 데이터베이스 수 한도를 초과함 | RDS Custom DB 인스턴스 상태가 다음과 같은 이유로 [지원되지 않는 구성]으로 설정되었습니다. DB 인스턴스의 총 데이터베이스 수가 최대 한도인 5,000개를 초과함. 이 문제를 해결하려면 데이터베이스 수를 지원되는 최대 한도 미만으로 줄이세요. | 다음 명령을 사용하여 총 데이터베이스 수를 확인하세요. SELECT COUNT(name) as databaseCount
FROM sys.databases
WHERE name not in ('tempdb','master','model','msdb','DWDiagnostics','DWConfiguration','DWQueue');
|
## RDS Custom for SQL Server에서 `Storage-Full` 문제 해결
RDS Custom은 루트(C:) 볼륨도 모니터링합니다. RDS Custom for SQL Server DB 인스턴스는 루트 볼륨에 사용 가능한 디스크 공간이 500MiB 미만일 때 `unsupported-configuration` 상태로 전환됩니다. ([RDS Custom for SQL Server에서 지원되지 않는 구성 문제 해결](#custom-troubleshooting-sqlserver.fix-unsupported)의 `Event SP-S2010` 섹션 참조)
## RDS Custom for SQL Server에서 TDE 지원 데이터베이스의 PENDING\$1RECOVERY 상태 문제 해결
자동 암호 해독에 문제가 발생해도 투명한 데이터 암호화(TDE)가 활성화된 SQL Server 데이터베이스는 `PENDING_RECOVERY` 상태를 유지할 수 있습니다. 이는 일반적으로 계정의 RDS Custom 관리형 S3 버킷에 저장된 소스 DB 인스턴스 Service Master Key(SMK) 백업 파일이 복원 완료 전에 삭제된 경우 DB 인스턴스 복원 후에 발생합니다.
자동 암호 해독을 활성화하고 TDE 지원 데이터베이스를 온라인으로 가져오려면 Database Master Key(DMK)를 암호로 열고 SMK를 사용하여 DMK를 암호화해야 합니다.
다음 SQL Server 명령을 참조용으로 사용하세요.
```
-- Identify PENDING_RECOVERY TDE databases
USE MASTER;
GO
SELECT name, is_encrypted, state_desc FROM sys.databases;
GO
-- Open DMK using password
OPEN MASTER KEY DECRYPTION BY PASSWORD = '';
GO
-- Encrypt DMK using SMK
ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY;
GO
-- Close SMK
CLOSE MASTER KEY;
GO
-- Bring the TDE databases online
ALTER DATABASE SET ONLINE;
GO
-- Verify TDE databases are now in ONLINE state
SELECT name, is_encrypted, state_desc FROM sys.databases;
GO
```