Amazon RDS for SQL Server 上で SQL Server 2008 R2 から SQL Server 2016 にアップグレードする方法に関するベストプラクティス

Amazon RDS for SQL Server 上で SQL Server 2008 R2 から SQL Server 2016 にアップグレードする方法に関するベストプラクティス:



このブログ記事では、Microsoft SQL Server 2008 R2 のサポート終了に備えて、Amazon RDS for SQL Server 上で SQL Server 2008 R2 から SQL Server 2016 にアップグレードする方法を中心にご紹介します。また、ご紹介するプラクティスの多くは、SQL Server のすべてのバージョン、あるいは他の RDS のエンジンにも適用することができます。

注意: 現在、SQL Server 2008 R2 から RDS の SQL Server 2017 へのアップグレードパスはありません。SQL Server 2017 にアップグレードする場合は、2012、2014、または 2016 にアップグレードしておく必要があります。

自己管理型プラットフォームでは、最新のデータベースバージョンへのアップグレードに多くのリスクが伴います。多くの企業は「壊れてないものは直すな」をモットーとしています。 幸い、自己管理型プラットフォームでふだん直面する課題の多くは、Amazon RDS が提供する自動化によって軽減されます。

SQL Server DB インスタンスの場合、アップグレードには次の 2 種類があります。

• メジャーバージョンのアップグレード (SQL Server 2008 R2 から SQL Server 2012 へのアップグレードなど)
• マイナーバージョンのアップグレード (SQL Server 2016 RTM から SQL Server 2016 SP1 へのアップグレードなど)

Amazon RDS for SQL Server は、Microsoft がリリースした最新バージョンで旧バージョンのバグが修正されたり、セキュリティアップデートが行われるたびに、新しいマイナーバージョンをリリースします。(重要なアップデートがない場合、比較的小規模なリリースについては省略することがあります) 最新バージョンを確認するには、ドキュメントを参照してください。最新のマイナーバージョンを最新の状態に保つことを強く推奨します。

メジャーバージョンについては、Amazon RDS は、ベンダー (この場合は Microsoft) がサポートしている限りサポートを行います。お客様が Amazon RDS に期待するのは、常に一貫した信頼できるサービスを利用できることです。この期待に応えるために、セキュリティ上の重大なリスクにさらすこと、および顧客の DB インスタンスの可用性を維持することのどちらかを選択することは Amazon RDS チームは望んでいません。Amazon RDS SQL Server がメジャーバージョンを終了することはありませんが、SQL Server 2008 R2 の延長サポートは 2019 年 7 月 9 日に終了します。

重要: 以下の手順を実行する前に、このブログ記事を最後まで読み、すべてのベストプラクティスについて検討することをおすすめします。

インスタンスのテストおよびアップグレードの方法

まず第一に、プラットフォームやサービスの保証に関係なく、必ずデータベースへの変更をテストしてから本番環境のデータベースに適用してください。Amazon RDS に対するテストは、すべての自動化が利用可能な状態で非常にシンプルに行われます。テストしない理由は何もありません。Amazon RDS では、AWS マネジメントコンソール、AWS CLI、または RDS API を使用してテストできます。わかりやすくするために、以下の例で、コンソールを使用してデータベースをアップグレードします。

1. スナップショットを作成:
   
   • コンソールで、アップグレードするインスタンスを選択し、インスタンスの [アクション] から [Take snapshot (スナップショットを作成する)] を選択します
     
     
2. スナップショットを復元:
   
   • スナップショットが完了したら、スナップショットを選択し、[アクション] から [Restore snapshot (スナップショットの復元)] を選択します
   • テスト目的で使用するため、インスタンスの仕様はすべて同じにすることをお勧めします。これらは、必要に応じて、インスタンスをアップグレードするときに変更できます。
3. スナップショットでアップグレードを実行:
   
   • スナップショットの復元が完了したら、アップグレードしたものをテストできます。
   • すべて正しく動作していることを確認するまで、DB インスタンスへの書き込み操作を許可しないことをお勧めします。
   • すべての通常のテストケースに加えて、すべてのストアドプロシージャと関数をテストしてください。
   • インスタンスで、復元されたスナップショットを選択し、インスタンスの [アクション] から [変更] を選択します。DB インスタンスを変更すると、[DB Engine Version (DB エンジンバージョン)] で、次のようないくつかのアップデートをすることができます。
     
     • DB インスタンスクラス – 処理能力またはメモリの要件を満たすようにインスタンスクラスを変更します。
     • ストレージタイプ – 必要に応じて、プロビジョンド IOPS または汎用のストレージタイプを変更できます。
     • 拡張モニタリング – 本番用インスタンスの拡張モニタリングを有効にすることを強く推奨します。
   • アップグレードするデータベースエンジンのバージョンを選択します。この例では、SQL Server 2016 13.00.4466.4.v1 を選択します。
     注意: 2008 から SQL Server 2017 にアップグレードする場合は、2016、2014、または 2012 にアップグレードしておく必要があります。
     
     
   • 必ず [Apply Immediately (すぐに適用)] を選択してください。そうしなければ、インスタンスは指定されたメンテナンスウィンドウまでアップグレードされません。
   インスタンスをアップグレードするにあたり、いくつかのことに留意してください。以下は、Amazon の推奨事項をまとめたリストです。
   
   

   マルチ AZ インスタンスとの連携

   マルチ AZ インスタンスをアップグレードするとき、RDS はまずスタンバイインスタンスでアップグレードを実行します。するとフェイルオーバーが実行され、古いプライマリがアップグレードされます。これが重要である理由 設定によっては、データベースをアップグレードするとデフォルトの設定にリセットされます。
   
   これらの設定でリスクを軽減するためのベストプラクティスは、マルチ AZ インスタンスをシングル AZ にダウングレードしておくことです。その後、マルチ AZ を再適用して、セカンダリがプライマリから最新の設定を取り込んでいることを確認します。
   
   この変更を行う場合、セカンダリはデータを完全に取り込むために一定の時間を必要とします。ボリュームはすぐに利用可能です。ただし、割り当てられた必要なパフォーマンスを完全に手に入れるためには、ボリュームが完全に動作するまで待つ必要があります。シングル AZ とマルチ AZ の変換を行う場合は、アップグレードを実行する 3〜4 日前に行うことをお勧めします。このタイミングで行うことで、フェイルオーバーが発生する前にセカンダリがデータを完全に取り込み、プライマリインスタンスになるための時間の余裕が生まれます。
   
   マルチ AZ インスタンスの Tempdb データベースは複製できません。Tempdb のプライマリインスタンスに格納するデータは、セカンダリインスタンスでは使用できません。アップグレード時、Tempdb はアプリケーションアクティビティに応じて自動拡張を試みるため、この機能によってアプリケーションに問題が発生することがあります。
   
   この影響を軽減するには、次の 2 つのオプションがあります。
   
   
   
   1. 前述のメソッドで DB インスタンスを変更し、マルチ AZ を無効にします。次に、Tempdb を変更し、最後にマルチ AZ を有効に戻します。このメソッドではダウンタイムが発生しません。
   2. 元のプライマリインスタンスで Tempdb を変更してから手動でフェイルオーバーし、新しいプライマリインスタンスの Tempdb を変更します。このメソッドではダウンタイムが発生します。
   プロビジョンド IOPS – インスタンスがシングル AZ に配置され、アップグレードまでに最小限のダウンタイムでマルチ AZ に移行すると仮定します。この場合、シングル AZ でプロビジョンド IOPS を使用していて、すでに最大 I/O に近づいているようであれば、I/O を 2 倍にすることをお勧めします。これをお勧めするのは、セカンダリインスタンスがプライマリのパフォーマンスに影響を与えないように追加のリソースを必要とするためです。マルチ AZ のアップグレードではフェイルオーバーが必要になるため、I/O が不十分だとフェイルオーバー時間が長くなる可能性があります。データベースの復旧には I/O が必要です!
   
   SQL Server データベースの互換性– アップグレード時に古いバージョンの SQL Server との互換性を維持するには、互換性レベルを現在使用している SQL Server のバージョンに設定します。コマンドと互換性の概要については、SQL Server ドキュメントの ALTER DATABASE (Transact-SQL) 互換性レベルを参照してください。データベースの互換性を変更しない場合は、アップグレードされたバージョンで新しい機能を使用することはできません。アップグレードを実行するとき、RDS 自体はデータベースの互換性レベルを変更しません。
   
   オプショングループ – DB インスタンスでカスタムオプショングループを使用している場合、Amazon RDS は DB インスタンスに新しいオプショングループを自動的に割り当てられないことがあります。たとえば、新しいメジャーバージョンにアップグレードする場合などです。この場合は、アップグレード時に新しいオプショングループを指定する必要があります。新しいオプショングループを作成して、既存のカスタムオプショングループと同じオプションを追加することをお勧めします。詳細については、RDS ドキュメントのオプショングループを使用するまたはオプショングループのコピーの作成を参照してください。
   
   パラメータグループ – DB インスタンスでカスタムパラメータグループを使用している場合、Amazon RDS は DB インスタンスに新しいパラメータグループを自動的に割り当てられないことがあります。たとえば、新しいメジャーバージョンにアップグレードする場合などです。この場合は、アップグレード時に新しいパラメータグループを指定する必要があります。新しいパラメータグループを作成して、既存のカスタムパラメータグループと同じようにパラメータを設定することをお勧めします。詳細については、RDS ドキュメントの DB パラメータグループを使用するまたは DB パラメータグループをコピーするを参照してください。
   
   RDS SQL Server への移行 – Amazon RDS for SQL Server への移行に関する各種メソッドを提供しています。これらはドキュメントで確認できます。また、ネイティブバックアップの復元、AWS DMS での進行中のレプリケーション、トランザクションレプリケーションなどに関する他のブログ記事でも、詳細なガイダンスをご覧になれます。  SQL Server 2008 R2 のサポートが終了しても、オンプレミスのデータベースから RDS に移行することができます。RDS ドキュメントに記載されているとおり、プロビジョニングした SQL Server インスタンスに基づいてアップグレードを処理します。
   
   RDS SQL Server のアップグレードに関するアイデアやこれまでに体験したことをお聞かせください。 コメントへの投稿をお待ちしています!
   
   
   

   ---

   今回のブログ投稿者について

   Justin Benton は、アマゾン ウェブ サービスの RDS Commercial Engines (SQL Server および Oracle) プロダクトマネージャーです。