Microsoft SQL Server マルチ AZ 配置の制限、注意事項、および推奨事項

クロスリージョンマルチ AZ はサポートされていません。

マルチ AZ 配置の RDS for SQL Server DB インスタンスはサポートされていません。

データベースの読み取りアクティビティを受け入れるように、セカンダリ DB インスタンスを設定することはできません。

Always On 可用性グループ (AG) を備えたマルチ AZ は、メモリ内最適化をサポートします。

Always On 可用性グループ (AG) を使用するマルチ AZ は、可用性グループリスナーでの Kerberos 認証をサポートしていません。これは、リスナーにサービスプリンシパル名 (SPN) がないためです。

ブロックレベルレプリケーションを使用するマルチ AZ は現在、SQL Server Web Edition インスタンスでのみサポートされています。

SQL Server マルチ AZ 配置内の SQL Server DB インスタンス上のデータベースの名前を変更することはできません。そのようなインスタンスのデータベースの名前を変更する必要がある場合、まず DB インスタンスのマルチ AZ を無効にし、それから名前を変更します。最後に、DB インスタンスのマルチ AZ を再び有効にします。

完全な復旧モデルを使用してバックアップされているマルチ AZ DB インスタンスのみ復元できます。

マルチ AZ 配置は、SQL Server エージェントジョブの数が 10,000 に制限されています。

制限の引き上げが必要な場合は、サポート に連絡して緩和をリクエストしてください。AWS サポート センターのページを開き、必要に応じてサインインし、[ケースの作成] を選択します。[Service Limit increase] (サービス制限の緩和) を選択します。フォームに入力して送信します。

SQL Server マルチ AZ 配置内の SQL Server DB インスタンス上にオフラインのデータベースを配置することはできません。

ボリュームメトリクスは、ブロックレベルレプリケーションを使用するインスタンスのセカンダリホストでは使用できません。

Amazon RDS は常時稼働 AG 可用性グループのリスナーエンドポイントを公開します。エンドポイントはコンソールに表示され、DescribeDBInstances API オペレーション によってエンドポイントフィールドのエントリとして返されます。

Amazon RDS は 可用性グループのマルチサブネットフェイルオーバーをサポートします。

仮想プライベートクラウド (VPC) 内の SQL Server DB インスタンスで SQL Server のマルチ AZ を使用するには、まず、少なくとも 2 つの異なるアベイラビリティーゾーンにサブネットを持つ DB サブネットグループを作成します。次に、その DB サブネットグループを SQL Server DB インスタンスのプライマリレプリカに割り当てます。

マルチ AZ 配置にするために DB インスタンスが変更されている場合、変更中は、[変更中] のステータスになります。Amazon RDS によりスタンバイが作成され、プライマリ DB インスタンスのバックアップが作成されます。このプロセスが完了した後で、プライマリ DB インスタンスのステータスが [利用可能] になります。

マルチ AZ 配置では、すべてのデータベースが同じノードにあります。プライマリホストのデータベースがフェイルオーバーする場合は、すべての SQL Server データベースが 1 つのアトミックユニットとしてスタンバイホストにフェイルオーバーします。Amazon RDS により新しい正常なホストがプロビジョニングされ、異常なホストに置き換わります。

DBM、AG、またはブロックレベルレプリケーションを使用したマルチ AZ は、単一のスタンバイレプリカをサポートします。

マルチ AZ 配置では、RDS for SQL Server は SQL Server ログインを作成して Always On AG またはデータベースミラーリングを許可します。RDS が作成するログインのパターンは、db_<dbiResourceId>_node1_login、db_<dbiResourceId>_node2_login、db_<dbiResourceId>_witness_login です。

RDS for SQL Server は、リードレプリカへのアクセスを許可する SQL Server ログインを作成します。RDS が作成するログインのパターンは、db_<readreplica_dbiResourceId>_node_login です。

同期的データレプリケーションのため、1 つのアベイラビリティーゾーン内のスタンダード DB インスタンスのデプロイと比較した場合、レイテンシーが長くなる可能性があります。

フェイルオーバー時間は、復旧プロセスの完了までにかかる時間の影響を受けます。大量のトランザクションがあると、フェイルオーバー時間はより長くなります。

SQL Server マルチ AZ 配置では、フェイルオーバー再起動でプライマリ DB インスタンスのみを再起動します。フェイルオーバー後、プライマリ DB インスタンスは新しいセカンダリ DB インスタンスになります。マルチ AZ インスタンスのパラメータは更新されない可能性があります。フェイルオーバーなしの再起動の場合、プライマリ DB インスタンスとセカンダリ DB インスタンスの両方が再起動し、再起動後にパラメータが更新されます。DB インスタンスが応答しない場合は、フェイルオーバーなしで再起動することをお勧めします。

本稼働または本稼働前に使用するデータベースでは、以下のオプションを使用することをお勧めします。

セカンダリ用のインスタンスにはアベイラビリティーゾーン (AZ) を選択することができません。アプリケーションホストをデプロイするときには、この点を考慮してください。データベースが別の AZ にフェイルオーバーする可能性があるため、アプリケーションホストがデータベースと同じ AZ に含まれない場合があります。このため、特定の AWS リージョン内のすべての AZ 間で、アプリケーションホストのバランスをとることをお勧めします。

最高のパフォーマンスのために、大量のデータをロードするオペレーション中はデータベースミラーリング、Always On AG、またはブロックレベルレプリケーションを有効にしないでください。できる限り高速でデータを更新する必要がある場合は、DB インスタンスをマルチ AZ 配置に変換する前にデータの更新を終了します。

SQL Server データベースにアクセスするアプリケーションには、接続エラーを見つける例外処理が必要です。以下のコード例では、通信エラーを見つける try/catch ブロックを示しています。この例では、接続が成功した場合に break ステートメントは while ループを終了しますが、例外がスローされた場合は最大 10 回再試行します。

int RetryMaxAttempts = 10;
int RetryIntervalPeriodInSeconds = 1;
int iRetryCount = 0;
while (iRetryCount < RetryMaxAttempts)
{
   using (SqlConnection connection = new SqlConnection(DatabaseConnString))
   {
      using (SqlCommand command = connection.CreateCommand())
      {
         command.CommandText = "INSERT INTO SOME_TABLE VALUES ('SomeValue');";
         try
         {
            connection.Open();
            command.ExecuteNonQuery();
            break;
         }
         catch (Exception ex) 
         {
            Logger(ex.Message);
            iRetryCount++;
         }
         finally {
            connection.Close();
         }
      }
   }
   Thread.Sleep(RetryIntervalPeriodInSeconds * 1000);
}

DBM または AG を使用してマルチ AZ インスタンスを操作する場合は、Set Partner Off コマンドを使用しないでください。このコマンドは、ブロックレベルレプリケーションを使用するインスタンスではサポートされていません。例えば、以下は実行しないでください。

--Don't do this
ALTER DATABASE db1 SET PARTNER off   

復旧モードを simple に設定しないでください。例えば、以下は実行しないでください。

--Don't do this
ALTER DATABASE db1 SET RECOVERY simple   

高可用性のためにブロックレベルレプリケーションを使用しない限り、マルチ AZ DB インスタンスに新しいログインを作成するときは、DEFAULT_DATABASE パラメータは使用しないでください。これらの設定は、スタンドバイ用ミラーには適用できないためです。例えば、以下は実行しないでください。

--Don't do this
CREATE LOGIN [test_dba] WITH PASSWORD=foo, DEFAULT_DATABASE=[db2]   

また、以下の操作をしないでください。

--Don't do this
ALTER LOGIN [test_dba] WITH DEFAULT_DATABASE=[db3]