SQL Server 2008 R2からSQL Server 2016へのアップグレード/移行
SQL Serverインスタンスを2008 R2から2012にアップグレード/移行する計画のあるクライアントがいます。詳細は以下のとおりです。環境はすべて仮想実行OSバージョンWindows 2008 r2エンタープライズSP1であり、VMWareを使用します。
SQL003-WSFC上のSQL Server 2008 r2インスタンス。このSQL Serverインスタンスは、ローカルディストリビューターと2つの場所SQL007およびSQLDR003へのサブスクライバーを持つパブリッシャーです。また、レプリケーションとDRサイトへのミラーリングの一部であるいくつかのデータベース（SQLDR003）もあります。
SQL007-WSFC上のSQL Server 2008 R2インスタンス。このSQL Serverインスタンスは、SQLDR007およびSQL008のパブリッシャーであり、上記のSQL003のサブスクライバーでもあります。
SQL008-SQL Server 2012 SP1は、スタンドアロンのSQL Serverインスタンスです。私はこのインスタンスについてあまり心配していません。
SQL Server 2016へのアップグレードを進めるために、0Sは少なくともWindows 2012 OSである必要があることを知っていますOR後で。これを達成する方法を頭の中で考えています。 OSをWindows 2012または2016に直接アップグレードしてからSQL Serverを2016にパッチすることはできますが、レプリケーションなどで何かが壊れるか、クラスターを完全に再構築してオブジェクトを移行する必要があります。環境の構成方法に基づいてデータベースと関連するすべてのオブジェクトを移行するのに理想的な場所ではありません。既存のホスト名などを変更せずに時間を節約できる方法論が必要です。
OSとSQL Serverのインプレースアップグレードを計画しているようです。サイドバイサイドアップグレードを行うと、問題が大幅に軽減され、問題が発生した場合にロールバックする可能性が高くなります。
新しいサーバーを構築し、それらに移行します。これにより、既存のサーバーが機能し続け、ユーザーとデータに影響を与えることなく移行とテストを行うことができます。
このSQL Serverでサポートされているアプリケーションに悪影響を与える可能性のある多くの変更がある可能性があることも覚えておいてください。サーバーを追加すると、それらのアプリケーションをテストして、実行する必要のある軽減タスクを見つけることができます。
タスクと移行プロセスの詳細を把握したら、メインサーバーから新しいサーバーへのログ配布を利用して、ダウンタイムの少ない移行を促進できます。
また、クラスタリングの代わりにAlways On可用性グループを使用することを検討してください。これにより、より良いHA/DRが提供される場合があります。
変化しないホスト名の観点から、CNAME DNSエントリを利用します。このようにして、新しいサーバーを使用し、準備ができたらDNSエントリを新しいサーバー名にカットオーバーできます。ユーザーにとって、彼らは何も変わっていないと考えています。