^
--tags Key="AWSRDSCustom",Value="custom-sqlserver"
```
------
## ステップ 5: RDS Custom for SQL Server DB インスタンスを作成または変更する
ディレクトリで使用する RDS Custom for SQL Server DB インスタンスを作成または変更します。コンソール、CLI、RDS API を使用して DB インスタンスとディレクトリを関連付けることができます。これには以下の 2 つの方法があります。
+ コンソール、[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 からステップ 4 までを完了します。`--domain-fqdn`、`--domain-ou`、`--domain-auth-secret-arn` を AD に更新して、ドメイン参加の認証情報と設定を RDS Custom に登録し、モニタリング、CNAME の登録、復旧アクションの実行ができるようにします。
AWS CLI を使用する場合は、DB インスタンスが、作成したディレクトリを使用できるように、以下のパラメータが必要です。
+ `--domain-fqdn` パラメータには、セルフマネージド AD の完全修飾ドメイン名を使用します。
+ `--domain-ou` パラメータには、セルフマネージド AD で作成した OU を使用します。
+ `--domain-auth-secret-arn` パラメータには、作成した**シークレット ARN** の値を使用します。
**重要**
DB インスタンスを変更してセルフマネージド AD ドメインや AWS Managed Microsoft AD に参加させたり、これらから削除したりする場合、変更を有効にするには DB インスタンスを再起動する必要があります。変更をすぐに適用するか、次のメンテナンスウィンドウまで待つかを選択できます。**[すぐに適用]** オプションを選択すると、シングル AZ DB インスタンスのダウンタイムが発生します。マルチ AZ DB クラスターは、再起動を完了する前にフェイルオーバーを実行します。詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
次の CLI コマンドは、新しい RDS Custom for SQL Server DB インスタンスを作成し、それをセルフマネージドドメインまたは AWS Managed Microsoft AD ドメインに参加させます。
Linux、macOS、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 インスタンスを変更します。
Linux、macOS、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 インスタンスを削除します。
Linux、macOS、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/ja_jp/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 ログインを作成する
Amazon RDS マスターユーザーの認証情報を使用して、他の DB インスタンスと同じように SQL Server DB インスタンスに接続します。DB インスタンスは AD ドメインに参加しているため、SQL Server のログインとユーザーをプロビジョニングできます。これは、AD ドメインの AD ユーザーとグループユーティリティから行います。データベースへのアクセス許可は、これらの Windows ログインに付与され無効化されている標準の SQL サーバーのアクセス許可によって管理されています。
AD ユーザーが SQL Server で認証するには、AD ユーザーまたはそのユーザーがメンバーになっている Active Directory グループに SQL Server Windows ログインが必要です。これらの SQL Server ログインでアクセスを許可したり取り消したりして、細分化されたアクセスコントロールを処理します。AD ユーザーが SQL Server ログインを持っていないか、そのようなログインを持つ AD グループに属していない場合、SQL Server DB インスタンスにアクセスすることはできません。
AD SQL Server ログインを作成するには、`ALTER ANY LOGIN` アクセス許可が必要です。このアクセス許可を持つログインをまだ作成していない場合は、SQL Server 認証を使用して DB インスタンスのマスターユーザーとして接続し、マスターユーザーのコンテキストで AD SQL Server ログインを作成します。
AD ユーザーまたは AD グループの SQL Server ログインを作成するには、次に示すようなデータ定義言語 (DDL) コマンドを実行できます。
```
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 マネージャー]** を開きます。**[前方参照ゾーン]** と 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 インスタンスをドメイン内、ドメイン外、またはドメイン間で移動させることができます。
例えば、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 ドメインに追加する
SQL Server DB インスタンスの 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 (参加保留中)** – インスタンスのメンバーシップは保留中です。
+ **メンテナンスまで参加保留中** – 次に予定されているメンテナンスウィンドウ中に、AWS がインスタンスをドメインのメンバーにできるよう試みます。
+ **pending-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 コンピュータアカウントの名前は、RDS Custom for SQL Server DB インスタンスで `SELECT @@SERVERNAME` を実行することで確認できます。マルチ 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 にアクセスできることを確認します。 |
| エラー 1772 / 0x6BA | RPC サーバーは使用できません。 | AD ドメインの RPC サービスへのアクセスに問題がありました。これはサービスまたはネットワークの問題かもしれません。 | RPC サービスがドメインコントローラーで実行されていることと、RDS Custom for SQL Server DB インスタンスからドメインの TCP ポート `135` および `49152-65535` にアクセスできることを確認します。 |
| エラー 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 は、異なるアベイラビリティーゾーン (AZ) で同期スタンバイレプリカを自動的にプロビジョンおよび維持します。プライマリ DB インスタンスは、同期的にアベイラビリティーゾーン間でスタンバイレプリカにレプリケートされ、データの冗長性が提供されます。
**重要**
SRDS 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/ja_jp/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 インスタンスは、シングル AZ 配置と比較して書き込みとコミットのレイテンシーが増加する可能性があります。この増加は DB インスタンス間の同期データレプリケーションが原因で起こる可能性があります。AWS はアベイラビリティーゾーン間でのネットワーク接続レイテンシーが低くなるように設計されていますが、配置がスタンバイレプリカにフェイルオーバーした場合はレイテンシーに変化が見られる可能性があります。
**注記**
本番ワークロードの場合、高速で一貫したパフォーマンスを実現するために、プロビジョンド IOPS (1 秒あたりの入出力操作) を備えた 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)
## 利用可能なリージョンとバージョン
RDS Custom for SQL Server のマルチ AZ 配置は、次の SQL Server エディションでサポートされています。
+ 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 配置の前提条件
SQL Server シングル AZ 配置の既存の RDS Custom がある場合は、マルチ 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) の手順を実行します。
+ RDS セキュリティグループのインバウンドルールおよびアウトバウンドルールを更新して、ポート 1120 を許可します。
+ プライベートネットワークのアクセスコントロールリスト (ACL) に DB インスタンス VPC の TCP ポート `0-65535` を許可するルールを追加します。
+ 新しい Amazon SQS VPC エンドポイントを作成して、RDS Custom for SQL Server DB インスタンスが SQS と通信できるようにします。
+ インスタンスプロファイルロールの SQS アクセス許可を更新します。
## RDS Custom for SQL Server マルチ AZ 配置の作成
RDS Custom for SQL Server マルチ AZ 配置を作成するには、[Amazon RDS Custom 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 インスタンス間の同期ブロックレベルレプリケーションをオンにします。
**重要**
アクティビティのピーク時には、RDS Custom for SQL Server DB インスタンスを本稼働 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 前提条件テンプレートを既に適用している場合は、これらの手順をスキップできます。
CloudFormation を使用して RDS Custom for SQL Server マルチ AZ 配置の前提条件を設定するには
1. CloudFormation コンソール ([https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/)) を開きます。
1. スタックの作成ウィザードを開始するには、シングル AZ 配置の作成に使用した既存のスタックを選択し、**[更新]** を選択します。
**[スタックの更新]** ページが表示されます。
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] ** (DB 詳細の指定) ページが表示されます。
1. デフォルトのオプションを保持するには、**[次へ]** をクリックします。
**[詳細オプション]** ページが表示されます。
1. デフォルトのオプションを保持するには、**[次へ]** をクリックします。
1. デフォルトのオプションを保持するには、**[次へ]** をクリックします。
1. **[変更の確認]** ページで以下の操作を実行します。
1. **[機能]** で、**[**CloudFormation が IAM リソースを作成する可能性があることに同意する**]** チェックボックスをオンにします。
1. [**Submit**] を選択してください。
1. 更新が成功したことを確認します。成功した場合のステータスは `UPDATE_COMPLETE` と表示されます。
更新に失敗すると、更新プロセスで指定された新しい設定はすべてロールバックされます。既存のリソースは引き続き使用できます。例えば、18 と 19 の番号が付いたネットワーク ACL ルールを追加しても、同じ番号の既存のルールが存在する場合、更新によって次のエラーが返されます。`Resource handler returned message: "The network acl entry identified by 18 already exists.` このシナリオでは、既存の ACL ルールを 18 未満の番号を使用するように変更してから、更新を再試行できます。
## シングル AZ 配置をマルチ AZ 配置に手動で変更するための前提条件を設定する
**重要**
セットアップを簡単にするために、ネットワーク設定手順に記載されている最新の CloudFormation テンプレートファイルを使用することをお勧めします。詳細については、「[CloudFormation を使用してシングル AZ 配置からマルチ AZ 配置に変更するための前提条件の設定](#custom-sqlserver-multiaz.modify-saztomaz-prereqs.cf)」を参照してください。
前提条件を手動で設定する場合は、以下のタスクを実行します。
1. Amazon VPC コンソールの [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/) を開いてください。
1. **[エンドポイント]** を選択します。[**Create 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. Amazon RDS セキュリティグループのインバウンドおよびアウトバウンドルールを更新して、ポート 1120 を許可します。
1. **[セキュリティグループ]** で、*[-rds-custom-instance-sg]* グループを選択します。
1. **[インバウンドルール]** で、ソースの *[-rds-custom-instance-sg]* グループからのポート *1120* を許可する**カスタム TCP** ルールを作成します。
1. **[アウトバウンドルール]** で、**カスタム TCP** ルールを作成して、送信先の *[-rds-custom-instance-sg]* グループにポート *1120* を許可します。
1. DB インスタンスのソースサブネットの TCP ポート `0-65535` を許可するルールをプライベートネットワークのアクセスコントロールリスト (ACL) に追加します。
**注記**
**インバウンドルール**と**アウトバウンドルール**を作成するときは、既存の**ルール番号**の最大値を書き留めてください。作成する新しいルールの**ルール番号**は 100 未満で、既存の**ルール番号**と一致しない必要があります。
1. **[ネットワーク ACL]** で、*[-private-network-acl]* グループを選択します。
1. **[インバウンドルール]** で、*privatesubnet1* と *privatesubnet2* のソースを持つ TCP ポート `0-65535` を許可する **すべての TCP** ルールを作成します。
1. **[アウトバウンドルール]** で、TCP ポート `0-65535` を宛先の *privatesubnet1* と *privatesubnet2* に許可する**すべての 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 マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. Amazon RDS コンソールで、[**Databases (データベース)**] を選択します。
**[データベース]** ペインが表示されます。
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)」を参照してください。
Linux、macOS、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. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. Amazon RDS コンソールで、[**Databases (データベース)**] を選択します。
**[データベース]** ペインが表示されます。
1. 変更する RDS Custom for SQL Server DB インスタンスを選択します。
1. **[マルチ AZ 配置]** で、**[いいえ]** を選択します。
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)」を参照してください。
Linux、macOS、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 配置に変更するには、[ModifyDBInstance](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～120 秒です。ただし、大規模なトランザクションや長期にわたる復旧プロセスによって、フェイルオーバー時間が増加する場合があります。フェイルオーバーが完了してから、新しいアベイラビリティーゾーンが 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 Multi-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/ja_jp/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 Multi-AZ DB インスタンスのデプロイの現在の状態を表示します。
## RDS Custom for SQL Server Multi-AZ マルチ AZ 配置を使用するアプリケーションでの Time to live (TTL) 設定
フェイルオーバーメカニズムでは、スタンバイ DB インスタンスをポイントするように DB インスタンスのドメインネームシステム (DNS) レコードが自動的に変更されます。したがって、DB インスタンスへの既存の接続の再確立が必要になります。DNS キャッシュ Time to live (TTL) 設定値が低いことを確認し、アプリケーションが 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 Oracle スナップショットの作成](custom-backup-sqlserver.creating.md)」を参照してください。
スナップショットバックアップはフルバックアップとして機能しますが、課金はストレージの増分使用に対してのみ発生します。 RDS Custom DB インスタンスの初期のスナップショットには、フル DB インスタンスのデータが含まれています。同じ DB インスタンスの後続のスナップショットは増分です。つまり、直近のスナップショットの保存後に変更されたデータのみが含まれます。
**Topics**
+ [RDS Custom for Oracle スナップショットの作成](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 Oracle スナップショットの作成
RDS Custom for SQL Server は DB インスタンスのストレージボリュームのスナップショットを作成し、個々のデータベースだけではなく、DB インスタンス全体をバックアップします。スナップショットを作成するときに、バックアップする RDS Custom for SQL Server DB インスタンスを指定します。次に、スナップショットに名前を付けて、後でそこから復元できるようにします。
スナップショットを作成すると、RDS Custom for SQL Server は DB インスタンスにアタッチされたデータベースボリュームである、ボリューム `(D:)` の Amazon EBS スナップショットを作成します。特定の 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 マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで **[データベース]** を選択します。
1. RDS Custom DB インスタンスのリストで、スナップショットを取得する DB インスタンスを選択します。
1. **アクション** で、**スナップショットの取得** を選択します。
**[Take DB snapshot]** (DB スナップショットの取得) ウィンドウが表示されます。
1. **[スナップショット名]** に、スナップショットの名前を入力します。
1. **スナップショットの取得** を選択します。
## 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**
Linux、macOS、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 マネジメントコンソール にサインインし、Amazon RDS コンソール [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/) を開きます。
1. ナビゲーションペインで、[**Snapshots**] を選択します。
1. 復元の元にする DB スナップショットを選択します。
1. **[アクション]** で、**[スナップショットの復元]** を選択します。
1. **DB インスタンスの復元** ページで、**DB インスタンス識別子** に、復元した RDS Custom DB インスタンスの名前を入力します。
1. **DB インスタンスの復元** を選択します。
## AWS CLI
RDS Custom DB スナップショットを復元するには、[DBスナップショットからDBインスタンスを復元する](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html) AWS CLI コマンドを使用します。
復元元のスナップショットがプライベート 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 DB インスタンスの基盤となる Amazon EC2 インスタンスに関連付けられているインスタンスプロファイルを指定します。
次のコードは、`my-custom-instance` の `my-custom-snapshot` という名前のスナップショットを復元します。
**Example**
Linux、macOS、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 マネジメントコンソール、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 ではサポートされていません。OSまたは DB インスタンスのタイムゾーンを変更すると、PITR (およびその他のオートメーション) は機能しません。
## インスタンスクラスタイプごとに PITR の対象となるデータベースの数
次の表は、インスタンスクラスタイプに基づいて PITR の対象となるデータベースの最大数を示しています。
| インスタンスクラスのタイプ | PITR 対象のデータベースの最大数 |
| --- | --- |
| db.\$1.large | 100 |
| db.\$1.xlarge〜db.\$1.2xlarge | 150 |
| db.\$1.4xlarge〜db.\$1.8xlarge | 300 |
| db.\$1.12xlarge〜db.\$1.16xlarge | 600 |
| db.\$1.24xlarge、db.\$132xlarge | 1,000 |
`*` *さまざまなインスタンスクラスタイプを表します。*
1 つの DB インスタンスで PITR の対象となるデータベースの最大数は、インスタンスクラスタイプによって異なります。数値の範囲は、RDS Custom for SQL Server でサポートされる最小のインスタンスクラスタイプで 100、最大のインスタンスクラスタイプで 1000 に及びます。SQL Server システムデータベース `(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 は PITR バックアップ用に、データベース ID 順に最初の 300 個のデータベースを選択します。PITR の要件を満たす 200 個のデータベースのそれぞれが PITR の対象になります。
1. 次に、インスタンスを変更して db.\$1.xlarge にスケールダウンします。
1. スケールコンピューティングオペレーションが完了すると、RDS Custom for SQL Server は、PITR バックアップ用に、データベース ID 順に最初の 150 個のデータベースを再び選択します。
## データベースを 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 にアップロードされるかどうかを決定します。ゼロ以外の値は、自動バックアップが作成され、RDS Custom エージェントが 5 分ごとにトランザクションログを S3 にアップロードすることを意味します。
S3 上のトランザクションログファイルは、AWS KMS keyDB インスタンス作成時に提供したものを使って、静止時に暗号化されます。詳細については、「*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`ディレクトリには、2 つのサブディレクトリが含まれます。
+ `TransactionLogs` - 各データベースのトランザクションログとそれぞれのメタデータが含まれます。
トランザクションログファイル名は、例えば`yyyyMMddHHmm.database_id.timestamp`というパターンに従っています。
```
202110202230.11.1634769287
```
同じファイル名でサフィックスが`_metadata`のものには、ログシーケンス番号、データベース名、`RdsChunkCount`などのトランザクションログに関する情報が含まれます。`RdsChunkCount`は、1つのトランザクションログファイルを表す物理ファイルの数を決定します。`_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 マネジメントコンソール、AWS CLI、または RDS API を使用した PITR 復元
AWS マネジメントコンソール、AWS CLI、またはRDS API を使用して、 RDS Custom for SQL Server DB インスタンスをあるポイントに復元することができます。
### コンソール
**特定の時点に RDS Custom DB インスタンスを復元するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、「**自動バックアップ**」を選択します。
1. 復元する RDS Custom DB インスタンスを選択します。
1. 「**アクション**」 で、「**特定時点への復元**」 を選択します。
**[特定時点への復元]** ウィンドウが表示されます。
1. 「**Latest restorable time**」 を選択してできるだけ最新の時点に復元するか、「**カスタム**」 を選択して時刻を選択します。
「**カスタム**」 を選択した場合、インスタンスクラスターを復元する日時を入力します。
時刻は、協定世界時 (UTC) からのオフセットとしてローカルタイムゾーンで表示されます。例えば、UTC-5 は東部スタンダード時/中部夏時間です。
1. 「**DB インスタンス識別子**」 に、ターゲットが復元された RDS Custom DB インスタンスの名前を入力します。名前は一意である必要があります。
1. 必要に応じて、DB インスタンスクラスなどの他のオプションを選択します。
1. **[Restore to point in time]** (特定時点への復元) を選択します。
### AWS CLI
特定のポイントに 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コマンドを使用して、RDS Custom 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**
Linux、macOS、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 マネジメントコンソール にサインインし、Amazon RDS コンソール [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/) を開きます。
1. ナビゲーションペインで、「**Snapshots**」 を選択します。
1. 削除する DB スナップショットを選択します。
1. 「**アクション**」 で、「**スナップショットの削除**」 を選択します。
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` - 削除するスナップショット
以下の例では、DB スナップショット `my-custom-snapshot` を削除します。
**Example**
Linux、macOS、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 マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、**[Automated backups]** (自動バックアップ) を選択します。
1. **[Retained]** (保持) を選択します。
1. 削除する保持された自動バックアップを選択します。
1. 「**アクション**」 で、「**削除**」 を選択します。
1. 確認ページで、**delete me** を入力し、**[Delete]** (削除) を選択します。
## AWS CLI
AWS CLI コマンド [delete-db-instance-automated-backup](https://docs.aws.amazon.com/cli/latest/reference/rds/delete-db-instance-automated-backup.html) を使用して、保持されている自動バックアップを削除できます。
保持されている自動バックアップを削除するには、以下のオプションを使用します。
+ `--dbi-resource-id` - 出典 RDS Custom DB インスタンスのリソース識別子です。
AWS CLI コマンド [describe-db-instance-automated-backups](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instance-automated-backups.html) を使用すると、保持された自動バックアップの出典 DB インスタンスのリソース識別子を見つけることができます。
次の例では、ソース DB インスタンスのリソース識別子 `custom-db-123ABCEXAMPLE` を持つ保持された自動バックアップを削除します。
**Example**
Linux、macOS、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 インスタンスのサービスマスターキー (SMK) バックアップファイルを削除すると、DB スナップショットのコピーは非同期的に成功します。ただし、TDE が有効になっているデータベースなど、SQL Server の機能は SMK に依存するため、問題が発生します。詳細については、「[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 スナップショットをコピーできます。ただし、クロスリージョンのスナップショットコピーには、特定の制約と考慮事項があります。
### RDS がスナップショットのコピーのために AWS リージョン 間で通信することを許可する
リージョン間の 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 スナップショットに関連付けます。CEV に関連付けられたソース DB スナップショットを AWS リージョン 間でコピーするために、RDS はソース DB スナップショットとともに CEV をコピー先リージョンにコピーします。
同じ CEV に関連付けられた複数の DB スナップショットを同じコピー先リージョンにコピーする場合、最初のコピーリクエストは関連付けられた CEV をコピーします。次のリクエストのコピープロセスでは、最初にコピーされた CEV を検索し、それを次の DB スナップショットコピーに関連付けます。DB スナップショットコピーに関連付けるには、既存の CEV コピーが `AVAILABLE` 状態である必要があります。
CEV に関連付けられた DB スナップショットをコピーするには、リクエスタの IAM ポリシーに、DB スナップショットのコピーと関連付けられた CEV のコピーの両方を許可するアクセス許可が必要です。関連付けられた CEV のコピーを許可するには、リクエスタの IAM ポリシーで次のアクセス許可が必要です。
+ `rds:CopyCustomDBEngineVersion` - リクエスタ IAM プリンシパルには、ソース DB スナップショットとともにソース CEV をコピー先リージョンにコピーするアクセス許可が必要です。リクエスタ 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 ユーザー (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": "*"
}
]
}
```
------
**注記**
リストされたアクセス許可が、IAM プリンシパルに関連付けられたサービスコントロールポリシー (SCP)、アクセス許可の境界、またはセッションポリシーによって制限されていないことを確認します。
リクエスタの IAM ポリシーでコンテキストキーを使用した条件を指定すると、特定の条件によってリクエストが失敗する可能性があります。IAM ポリシー条件による一般的な落とし穴についての詳細は、「[クロスリージョン DB スナップショットコピーのリクエスト](USER_CopySnapshot.md#USER_CopySnapshot.AcrossRegions.Policy)」を参照してください。
## DB スナップショットのコピー
DB スナップショットをコピーするには、次の手順に従います。AWS アカウントごとに、AWS リージョン 間で同時に最大 20 個の DB スナップショットをコピーできます。別の AWS リージョン に DB スナップショットをコピーする場合には、その AWS リージョン に保持されている手動 DB スナップショットを作成します。コピー元の AWS リージョン から DB スナップショットをコピーすると、Amazon RDS のデータ転送料金が発生します。データ転送料金の詳細については、「[Amazon RDS の料金](https://aws.amazon.com/rds/pricing/)」を参照してください。
DB スナップショットのコピーが新しい AWS リージョン に作成されると、その DB スナップショットのコピーは、AWS リージョン にある他のすべての DB スナップショットと同じように動作します。
AWS マネジメントコンソール、AWS CLI、または Amazon RDS API を使用して DB スナップショットをコピーできます。
------
#### [ Console ]
次の手順では、AWS マネジメントコンソール を使用して RDS Custom for SQL Server DB スナップショットをコピーします。
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、「**Snapshots**」 を選択します。
1. コピーする RDS Custom for SQL Server DB スナップショットを選択します。
1. **[アクション]** ドロップダウンで、**[スナップショットをコピー]** を選択します。
![\[Amazon RDS コンソールの [スナップショットのコピー] ページ。設定がページにロードされます。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/XRSC-Snapshot-Copy.png)
1. DB スナップショットを別の AWS リージョン にコピーするには、**[送信先リージョン]** を必要な値に設定します。
**注記**
コピー先 AWS リージョン は、コピー元 AWS リージョン と同じデータベースエンジンのバージョンを使用できる必要があります。
1. **[新しい DB スナップショット ID]** に 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`
次のコードでは、スナップショットのコピーを `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
```
------
# オンプレミスデータベースを Amazon RDS Custom for SQL Server に移行する
次の手順で、ネイティブバックアップと復元を使用し、オンプレミス Microsoft SQL Server データベースを Amazon RDS Custom for SQL Server に移行できます。
1. オンプレミス DB インスタンスでデータベースのフルバックアップを作成します。
1. Amazon S3 にバックアップファイルをアップロードします。
1. S3 から RDS Custom for SQL Server DB インスタンスにバックアップファイルをダウンロードします。
1. RDS Custom for SQL Server DB インスタンスで、ダウンロードしたバックアップファイルを使用してデータベースを復元します。
このプロセスでは、ネイティブのフルバックアップと復元を使用して、オンプレミスから RDS Custom for SQL Server へのデータベースの移行について説明します。移行プロセス中のカットオーバー時間を短縮するために、差分バックアップまたはログバックアップの使用を検討してもよいでしょう。
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)
+ [RDS Custom for SQL Server DB インスタンスへのバックアップファイルの復元](#custom-migrating.restore)
## 前提条件
データベースを移行する前に、次のタスクを実行します。
1. RDS Custom for SQL Server DB インスタンスに、リモートデスクトップ接続 (RDP) を設定します。詳細については、「[RDP を使用した RDS Custom DB インスタンスへの接続](custom-creating-sqlserver.rdp.md)」を参照してください。
1. Amazon S3 へのアクセス権を設定して、データベースのバックアップファイルをアップロードおよびダウンロードできるようにします。
## オンプレミスデータベースのバックアップ
SQL Server ネイティブバックアップを使用して、オンプレミス DB インスタンス上のデータベースのフルバックアップを作成します。
次の例は、`mydatabase` という名前のデータベースのバックアップで、バックアップファイルのサイズを小さくするために指定される `COMPRESSION` オプションを示しています。
**オンプレミスデータベースをバックアップするには**
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 へのバックアップファイルのアップロード
バックアップファイルを `mydb-full-compressed.bak` Amazon S3 にアップロードするには AWS マネジメントコンソール を使用します。
**S3 にバックアップファイルをアップロードするには**
1. AWS マネジメントコンソール にサインインし、Amazon S3 コンソール [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/) を開きます。
1. **[Buckets]** (バケット) では、バックアップファイルのアップロード先のバケットの名前を選択します。
1. **[Upload]** (アップロード) を選択します。
1. **[Upload]** (アップロード) ウィンドウで、次のいずれかの操作を行います。
+ `mydb-full-compressed.bak` を **アップロード**ウインドウにドラッグアンドドロップします。
+ **ファイルを追加する**を選択し、「`mydb-full-compressed.bak`」を選択してから、**オープン**を選択します。
Amazon S3 はバックアップファイルを S3 オブジェクトとしてアップロードします。アップロードが完了すると、**[Upload: status]** (アップロード: ステータス) ページに成功のメッセージが表示されます。
## Amazon S3 からのバックアップファイルのダウンロード
コンソールを使用して、S3 から RDS Custom for SQL Server DB インスタンスにバックアップファイルをダウンロードします。
**S3 からバックアップファイルをダウンロードするには**
1. RDP を使用して、RDS Custom for SQL Server DB インスタンスに接続します。
1. AWS マネジメントコンソール にサインインし、Amazon S3 コンソール [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/) を開きます。
1. **[Buckets]** (バケット)リストで、バックアップファイルのアップロード先のバケットの名前を選択します。
1. バックアップファイル`mydb-full-compressed.bak`を選択します。
1. 「**アクション**」で、「**名前を付けてダウンロード**」を選択します。
1. 表示されたリンクのコンテキスト (右クリック) メニューを開き、**名前を付けて保存** を選択します。
1. `mydb-full-compressed.bak`を`D:\rdsdbdata\BACKUP` ディレクトリに保存します。
## RDS Custom for SQL Server DB インスタンスへのバックアップファイルの復元
SQL Server ネイティブ復元を使用して、バックアップファイルを RDS Custom for SQL Server DB インスタンスに復元します。
この例では、データファイルとログファイルのディレクトリがオンプレミス DB インスタンスと異なるため、`MOVE` オプションが指定されます。
**バックアップファイルを復元するには**
1. SSMS を使用して、RDS Custom for SQL Server DB インスタンスに接続します。
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 インスタンスのオペレーティングシステムの更新を管理するには、次の 2 つの方法があります。
+ シングル AZ インスタンスの場合、オペレーティングシステムの更新中はインスタンスを使用できません。
+ マルチ AZ 配置の場合、RDS は次の方法でオペレーティングシステムの更新を適用します。
+ まず、RDS はスタンバイインスタンスでオペレーティングシステムの更新を実行します。
+ RDS はアップグレードされたスタンバイ DB インスタンスにフェイルオーバーし、それを新しいプライマリ DB インスタンスにします。
+ 最後に、RDS は新しいスタンバイ DB インスタンスでオペレーティングシステムの更新を実行します。
マルチ AZ 配置におけるダウンタイムとは、フェイルオーバーにかかる時間のことです。
## システム更新メンテナンスアクションを使用してオペレーティングシステムの更新を適用する
Amazon RDS RPEV インスタンスにオペレーティングシステムの更新を適用するには、AWS マネジメントコンソール、AWS CLI、または RDS API を使用できます。詳細については、「[RDS DB インスタンスのオペレーティングシステムの更新](USER_UpgradeDBInstance.Maintenance.md#OS_Updates)」を参照してください。
**Example**
Linux、macOS、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 インスタンスのアップグレード
Amazon RDS Custom for SQL Server の DB インスタンスをアップグレードするには、新しい 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 を作成したら、この新しいバージョンを使用するようにデータベースインスタンスを変更します。詳細については、「[Performing a minor version upgrade for Amazon RDS Custom for SQL Server CEV with Multi-AZ](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 はインスタンスのローリングアップグレードを実行します。このアプローチでは、一度に 1 つのインスタンスをアップグレードすることでダウンタイムを最小限に抑えます。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 マネジメントコンソールを使用し、DB インスタンスを変更するときに使用可能なバージョンから選択します。または、CLI コマンド [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) を使用するか、RDS API コマンド [DescribeDBEngineVersions](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBEngineVersions.html) を使用します。
Linux、macOS、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 マネジメントコンソールを使用し、「[RDS Custom for SQL Server DB インスタンスの変更](custom-managing.modify-sqlserver.md)」の手順に従います。または、CLI コマンド [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) を使用するか、RDS API コマンド [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) を使用します。
Linux、macOS、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 DB をトラブルシューティングする方法について説明します。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 DB でサポートされていない構成の修正](#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)」を参照してください。
AWS CLIを使用してRDS Custom イベント通知を表示するには、`describe-events`コマンドを使用します。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 マシンイメージ (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.` | `setup` ファイルが `C:\Program Files\Microsoft SQL Server\nnn\Setup Bootstrap\SQLnnnn\setup.exe` にあることを確認してください。 |
| `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.` | Windows Server with SQL Server Enterprise、Standard、または Web エディションを備えた、サポートされている AMI を選択します。EC2 Marketplace から、以下のいずれかの使用オペレーションコードの AMI を選択してください。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/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.` | Classic 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.` | Windows Server with SQL Server Enterprise、Standard、または Web エディションを備えた、サポートされている AMI を選択します。EC2 Marketplace から、以下のいずれかの使用オペレーションコードの AMI を選択してください。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/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 DB でサポートされていない構成の修正
共有責任モデルであるため、RDS Custom for SQL Server DB インスタンスを`unsupported-configuration`状態にする設定上の問題は、お客様の責任で解決していただく必要があります。問題がAWSインフラストラクチャであれば、コンソールやAWS CLIを使用して修正できます。OSまたはデータベースの設定に問題がある場合は、ホストにログインして修正できます。
**注記**
このセクションでは 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` | サポートされていない手動設定 | `X` のため、RDS Custom DB インスタンスのステータスは、[サポートされていない設定] に設定されています。 | この問題を解決するには、サポートケースを作成します。 |
**AWS リソース (インフラストラクチャ)**
| イベントコード | 設定領域 | RDS イベントメッセージ | 検証プロセス |
| --- | --- | --- | --- |
| `SP-S1001` | EC2 インスタンスのステータス | 基盤となる EC2 インスタンス %s が RDS インスタンスを停止せずに停止されたため、RDS Custom DB インスタンスのステータスは [サポートされていない設定] に設定されています。これを解決するには、基盤となる EC2 インスタンスを起動し、バイナリボリュームとデータボリュームがアタッチされていることを確認します。RDS インスタンスを停止する場合は、まず基盤となる EC2 インスタンスのステータスが [利用可能] であることを確認してから、RDS コンソールまたは CLI を使用して RDS インスタンスを停止します。 | DB インスタンスのステータスを確認するには、コンソールを使用するか、次の AWS CLI コマンドを実行します。 aws rds describe-db-instances \
--db-instance-identifier db-instance-name |grep DBInstanceStatus
|
| `SP-S1002` | EC2 インスタンスのステータス | RDS DB インスタンスのステータスは [`STOPPED`] に設定されているが、基盤となる EC2 インスタンス %s が起動されたため、RDS Custom DB インスタンスのステータスは [サポートされていない設定] に設定されています。これを解決するには、基盤となる EC2 インスタンスを停止します。RDS インスタンスを起動する場合は、コンソールまたは CLI を使用します。 | DB インスタンスのステータスを確認するには、次の AWS CLI コマンドを使用します。 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 インスタンスクラス | EC2 ホストの期待される DB インスタンスクラスと設定されたクラスが一致しないため、RDS Custom DB インスタンスのステータスは [サポートされていない設定] に設定されています。これを解決するには、DB インスタンスクラスを元のクラスタイプに変更します。 | 次の CLI コマンドを使用して、期待される DB インスタンスクラスを確認します。 aws rds describe-db-instances \
--db-instance-identifier db-instance-name |grep DBInstanceClass
|
| `SP-S1004` | EBS ストレージボリュームにアクセスできない | EC2 インスタンスに関連付けられた元の EBS ストレージボリューム %s に現在アクセスできないため、RDS Custom DB インスタンスのステータスは [サポートされていない設定] に設定されています。 | |
| `SP-S1005` | EBS ストレージボリュームがデタッチされている | 元の EBS ストレージボリューム「volume-id」がアタッチされていないため、RDS Custom DB インスタンスのステータスは [サポートされていない設定] に設定されています。これを解決するには、関連付けられている EBS ボリュームを EC2 インスタンスにアタッチします。 | EBS ボリュームを再アタッチしたら、次の CLI コマンドを使用して、EBS ボリューム「volume-id」が RDS インスタンスに適切にアタッチされているかどうかを確認します。 aws ec2 describe-volumes \
--volume-ids volume-id |grep InstanceId
|
| `SP-S1006` | EBS ストレージボリュームサイズ | EBS ストレージボリューム「volume-id」の期待される設定と設定された設定が一致しないため、RDS Custom DB インスタンスのステータスは [サポートされていない設定] に設定されています。ボリュームサイズが 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 ストレージボリュームの設定 | EBS ストレージボリューム「volume-id」の期待される設定と設定された設定が一致しないため、RDS Custom DB インスタンスのステータスは [サポートされていない設定] に設定されています。これを解決するには、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 ストレージボリュームのサイズと設定 | EBS ストレージボリューム「volume-id」の期待される設定と設定された設定が一致しないため、RDS Custom DB インスタンスのステータスは [サポートされていない設定] に設定されています。これを解決するには、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 アクセス許可 | IAM インスタンスプロファイルに Amazon Simple Queue Service (SQS) のアクセス許可がないため、RDS Custom DB インスタンスのステータスは [サポートされていない設定] に設定されています。これを解決するには、ホストに関連付けられた IAM プロファイルに次のアクセス許可があることを確認します: ["SQS:SendMessage"、"SQS:ReceiveMessage"、"SQS:DeleteMessage"、"SQS:GetQueueUrl"]。 | |
| `SP-S1010` | SQS VPC エンドポイント | VPC エンドポイントポリシーが Amazon Simple Queue Service (SQS) オペレーションをブロックしているため、RDS Custom DB インスタンスのステータスは [サポートされていない設定] に設定されています。これを解決するには、必要な SQS アクションを許可するように VPC エンドポイントポリシーを変更します。 | |
| `SP-S1011` | イベントバスポリシー | イベントバス arn:aws:events:region-1:123456789012:event-bus/default のリソースベースのポリシーが Amazon CloudWatch の events:PutEvents アクションを拒否しているため、RDS Custom DB インスタンスのステータスは [サポートされていない設定] に設定されています。これを解決するには、EventBus %s の events:PutEvents アクションを許可するようにリソースベースのポリシーを変更します。 | |
| `SP-S1012` | CloudWatch VPC のアクセス許可 | VPC エンドポイントポリシーに Amazon CloudWatch イベントへのアクセス許可がないため、RDS Custom DB インスタンスのステータスは [サポートされていない設定] に設定されています。これを解決するには、EventBus arn:aws:events:region-1:123456789012:event-bus/default の events:PutEvents を許可するように VPC エンドポイントポリシーを変更します。 | |
| `SP-S1013` | サービスコントロールポリシー | AWS Organizations のサービスコントロールポリシーに Amazon CloudWatch イベントへのアクセス許可がないため、RDS Custom DB インスタンスのステータスは [サポートされていない設定] に設定されています。これを解決するには、EventBus arn:aws:events:region-1:123456789012:event-bus/default の events:PutEvents を許可するようにサービスコントロールポリシーを変更します。 | |
| `SP-S1014` | IAM インスタンスプロファイル | IAM インスタンスプロファイル %s のアクセス許可が Amazon CloudWatch イベントを拒否しているため、RDS Custom DB インスタンスのステータスは [サポートされていない設定] に設定されています。これを解決するには、["events:PutEvents"] を 'Allow' に設定し、インスタンスに関連付けられた IAM プロファイルで EventBus arn:aws:events:region-1:123456789012:event-bus/default の events:PutEvents を許可します。 | |
| `SP-S1015` | IAM インスタンスプロファイル | IAM インスタンスプロファイル %s に Amazon CloudWatch イベントへのアクセス許可がないため、RDS Custom DB インスタンスのステータスは [サポートされていない設定] に設定されています。これを解決するには、["events:PutEvents"] アクセス許可を含め、インスタンスに関連付けられた IAM プロファイルで EventBus arn:aws:events:region-1:123456789012:event-bus/default の events:PutEvents を許可します。 | |
| `SP-S1016` | IAM アクセス許可の境界 | IAM インスタンスプロファイル %s には Amazon CloudWatch イベントを拒否するアクセス許可の境界があるため、RDS Custom DB インスタンスのステータスは [サポートされていない設定] に設定されます。これを解決するには、IAM インスタンスプロファイルのアクセス許可の境界で EventBus arn:aws:events:region-1:123456789012:event-bus/default の ["events:PutEvents"] を 'Allow' に設定します。 | |
**オペレーティングシステム**
| イベントコード | 設定領域 | RDS イベントメッセージ | 検証プロセス |
| --- | --- | --- | --- |
| `SP-S2001` | SQL サービスステータス | SQL Server サービスが起動されていないため、RDS Custom DB インスタンスのステータスは [サポートされていない設定] に設定されています。これを解決するには、ホストで SQL Server サービスを再起動します。この DB インスタンスがマルチ AZ DB インスタンスで、再起動が失敗した場合、ホストを停止して起動し、フェイルオーバーを開始します。 | |
| `SP-S2002` | RDS Custom エージェントステータス | RDS Custom エージェントサービスがインストールされていないか、起動できなかったため、RDS Custom DB インスタンスのステータスは [サポートされていない設定] に設定されています。これを解決するには、Windows イベントログを確認して、サービスが起動されない理由を特定し、問題を解決するための適切な手順を実行します。さらにサポートが必要な場合は、サポートケースを作成してください。 | ホストにログインし、RDS Custom エージェントが実行されていることを確認します。 エージェントステータスを表示するには、次のコマンドを使用します。 $name = "RDSCustomAgent"
$service = Get-Service $name
Write-Host $service.Status
ステータスが `Running` でなければ、次のコマンドを使ってサービスを開始できます。 Start-Service $name
エージェントが起動できない場合は、Windows イベントをチェックして、起動できない理由を確認します。エージェントでは、Windows ユーザーがサービスを起動する必要があります。Windows ユーザーが存在し、サービスを実行する権限があることを確認します。 |
| `SP-S2003` | SSM エージェントステータス | Amazon SSM エージェントサービスにアクセスできないため、RDS Custom DB インスタンスのステータスは [サポートされていない設定] に設定されています。これをトラブルシューティングするには、`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 エンドポイントのトラブルシューティングについては、「[Unable to connect to SSM endpoints](https://docs.aws.amazon.com/systems-manager/latest/userguide/troubleshooting-ssm-agent.html#systems-manager-ssm-agent-troubleshooting-endpoint-access)」および「[Use ssm-cli to troubleshoot managed node availability](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-cli.html#agent-ts-ssm-cli)」を参照してください。 |
| `SP-S2004` | RDS Custom エージェントログイン | SQL ログイン `"$HOSTNAME/RDSAgent”` で予期しない問題が発生したため、RDS Custom DB インスタンスのステータスは [サポートされていない設定] に設定されています。この問題を解決するには、サポートケースを作成します。 | |
| `SP-S2005` | Timezone | Amazon EC2 インスタンス [%s] のタイムゾーンが変更されたため、RDS Custom DB インスタンスのステータスは [サポートされていない設定] に設定されています。これを解決するには、タイムゾーンをインスタンスの作成時に指定された設定に戻します。特定のタイムゾーンでインスタンスを作成する場合は、RDS Custom のドキュメントを参照してください。 | `Get-Timezone` PowerShell コマンドを実行して、タイムゾーンを確認します。 詳細については、「[RDS Custom for SQL Server DB インスタンスのローカルタイムゾーン](custom-reqs-limits-MS.TimeZone.md)」を参照してください。 |
| `SP-S2006` | 高可用性ソフトウェアソリューションバージョン | 現在のインスタンスの高可用性ソフトウェアソリューションが想定バージョンと異なるため、RDS Custom DB インスタンスのステータスは [サポートされていない設定] に設定されています。この問題を解決するには、サポートケースを作成します。 | |
| `SP-S2007` | 高可用性ソフトウェアソリューションの設定 | 高可用性ソフトウェアソリューションの設定がインスタンス %s で予期しない値に変更されているため、RDS Custom DB インスタンスのステータスは [サポートされていない設定] に設定されています。この問題を解決するには、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 Custom 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」で少なくとも 500 MiB のストレージスペースを解放するか、ボリュームサイズを増やして EC2 インスタンス「instance-id」の C ドライブのサイズを変更します。EC2 インスタンスを置き換えると、ルートボリュームサイズの変更は保持されません。 | ルート (C:) ボリュームで使用可能なストレージを表示するには、次のコマンドを使用します。 (Get-PSDrive -Name C).Free / 1MB
EBS ルートボリュームの変更の詳細については、「[How](https://forums.aws.amazon.com/knowledge-center/expand-ebs-root-volume-windows)」を参照してください。 |
**データベース**
| イベントコード | 設定領域 | RDS イベントメッセージ | 検証プロセス |
| --- | --- | --- | --- |
| `SP-S3001` | SQL Server 共有メモリプロトコル | SQL Server 共有メモリプロトコルが無効になっているため、RDS Custom DB インスタンスのステータスは [サポートされていない設定] に設定されています。これを解決するには、SQL Server Configuration Manager で共有メモリプロトコルを有効にします。 | これを検証するには、**[SQL Server Configuration Manager] > [SQL Server Network Configuration] > [Protocols for MSSQLSERVER] > [Shared Memory]** が有効になっていることを確認します。プロトコルを有効にしてから、SQL Server プロセスを再起動します。 |
| `SP-S3002` | サービスマスターキー | RDS オートメーションが、新しい SMK 生成の一部としてサービスマスターキー (SMK) のバックアップを取得できないため、RDS Custom DB インスタンスのステータスは [サポートされていない設定] に設定されています。この問題を解決するには、サポートケースを作成します。 | |
| `SP-S3003` | サービスマスターキー | サービスマスターキー (SMK) に関連するメタデータがないか不完全であるため、RDS Custom DB インスタンスのステータスは [サポートされていない設定] に設定されています。この問題を解決するには、サポートケースを作成します。 | |
| `SP-S3004` | DB エンジンのバージョンとエディション | RDS Custom DB インスタンスのステータスは [サポートされていない設定] に設定されています。これは、SQL Server の想定バージョンとインストールされているバージョンおよびエディションが一致しないためです。SQL Server のエディションの変更は、RDS Custom for 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 エンジンのエディション | 現在の SQL Server エディションが、想定される SQL Server のエディション [%s] と一致しないため、RDS Custom DB インスタンスのステータスが [サポートされていない設定] に設定されています。SQL Server のエディションの変更は、RDS Custom for 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 エンジンのバージョン | 現在の SQL Server バージョンが、想定される SQL Server のバージョン [%s] と一致しないため、RDS Custom DB インスタンスのステータスが [サポートされていない設定] に設定されています。SQL Server のエディションの変更は、RDS Custom EC2 のインスタンスではサポートされていません。この問題を解決するには、サポートケースを作成します。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` | データベースファイルの場所 | データベースファイルが D:\$1 ドライブの外部で設定されているため、RDS Custom DB インスタンスのステータスは [サポートされていない設定] に設定されています。これを解決するには、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` | データベース数の制限を超えました | DB インスタンスでのデータベースの総数が上限の 5,000 を超えているため、RDS Custom DB インスタンスのステータスは [サポートされていない設定] に設定されています。これを解決するには、データベースの数をサポートされている上限未満に減らします。 | データベースの総数を確認するには、次のコマンドを使用します。 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:) ボリュームもモニタリングします。ルートボリュームで利用できるディスク容量が 500 MiB 未満の場合、RDS Custom for SQL Server DB インスタンスは `unsupported-configuration` 状態に移行します。`Event SP-S2010` の「[RDS Custom for SQL Server DB でサポートされていない構成の修正](#custom-troubleshooting-sqlserver.fix-unsupported)」を参照してください。
## RDS Custom for SQL Server の TDE が有効なデータベースの PENDING\$1RECOVERY 状態のトラブルシューティング
自動復号で問題が発生した場合、透過的データ暗号化 (TDE) が有効になっている SQL Server データベースは `PENDING_RECOVERY` 状態のままになることがあります。これは通常、復元の完了前にアカウントの RDS Custom マネージド S3 バケットに保存されているソース DB インスタンスサービスマスターキー (SMK) バックアップファイルが削除された場合に、DB インスタンスの復元後に発生します。
自動復号を有効にして TDE が有効なデータベースをオンラインにするには、パスワードでデータベースマスターキー (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
```