検索
連載

SQL Serverマイグレーションの歩き方［前編］――マイグレーションの作業ステップ：SQL Server 2008 EOSにも対応できる！（2/3 ページ）

2019年7月のSQL Server 2008／2008 R2の延長サポート終了に伴い、EOS対応としてアップグレードやマイグレーションを準備／実施している方も多いでしょう。「前編」となる今回は、SQL Serverのマイグレーションに必要な作業ステップについて解説します。

Share
Tweet
LINE
Hatena
前のページへ | 次のページへ

データベース移行

　アセスメントで、マイグレーション先で稼働させた場合にどのような問題が発生するかを把握できたら、次はデータベースの移行方法を検討する必要があります。データベースの移行では次のような内容を検討しましょう。

  • 移行環境の構成
  • データベースの移行方法
  • 切り替え時の作業
  • 関連システムの接続先の切り替え

●移行環境の構成

■マイグレーション方法
　SQL Serverのマイグレーションの方法は、大きく分けて次の2種類があります。

  • インプレースアップグレード（図2）
  • 新しい環境にマイグレーション（図3）
図2
図2　インプレースアップグレード
図3
図3　新しい環境にマイグレーション

　SQL Serverでは「インプレースアップグレード」がサポートされており、サポートされているバージョン間であれば、SQL Serverを同一環境上でアップグレードインストールすることが可能です。インプレースアップグレードを実施すると、後述するシステムデータベースの情報もそのまま移行できるというメリットがあります。

　一方で、既存環境にソフトウェアのメジャーバージョンアップを行うというリスクも考慮しなければなりません。また、アップグレードが必要となる環境では、OSやハードウェアも老朽化しているのではないでしょうか。そのため、インプレースアップグレードではなく、「事前に作成した新しい環境のSQL Server」にマイグレーションすることを基本として考えることになるでしょう。

■可用性環境
　移行元が可用性環境として構築されていた場合は、移行先をどのようにするのかも検討しておきましょう。

　SQL Serverでは、可用性環境を構築する方法として、次のような高可用性ソリューションを利用できます（図4）。


図4
図4　SQL Serverの高可用性ソリューション

　近年、使用機会が増えているのが「AlwaysOn可用性グループ」です。AlwaysOn可用性グループは、SQL Server 2012以降で追加された高可用性ソリューションです。共有ストレージが不要なので、シンプルなハードウェア構成で可用性環境を構築できます。

　SQL Server 2016からは、Standard EditionでもAlwaysOn可用性グループが利用可能になりました。Enterprise Editionの場合は、AlwaysOn可用性グループのセカンダリーサーバを「読み取りワークロード」「バックアップの取得先」として利用することでができ、待機系サーバを有効活用できるようになります。

　「データベースミラーリング」はSQL Server2017でも利用できますが、将来のバージョンでは非推奨の機能となっており、今後はAlwaysOn可用性グループが推奨されます。

　SQL Serverをバージョンアップすることで、利用できる高可用性ソリューションも変化します。移行元と同じ可用性環境を構築することも可能ですが、バージョンに適した環境を構築することも検討してください。

■クラウドへの移行
　マイグレーション先としては、データセンター内に新たに構築したSQL Serverだけでなく、クラウドを検討することもあるでしょう。

　「Microsoft Azure」では、次のようなSQL Serverベースのクラウド環境が提供されています。


　「SQL Server on Azure Virtual Machines（仮想マシン）」は、IaaSに構築したOSにSQL Serverをインストールするので、SQL Serverの全機能が利用できます。IaaSに移行することで、ハードウェアのライフサイクルサポートとの分離や、クラウドプラットフォーム上のさまざまな機能を利用できるメリットがあります。

　ただし、オンプレミスのSQL Serverに移行する場合と、ソフトウェアのライフサイクルサポートの基本的な考え方は同じになるので、アップグレードしたSQL ServerやOSのサポート期間が終了するタイミングで、再度マイグレーションを検討する必要があります。

　PaaSでは、SQL Serverと実行基盤の自動的な最新化、標準で冗長化された高可用性環境、データベースの自動的なバックアップなど、さまざまなメリットが得られる他、運用の利便性も大幅に向上します。前項で記載した可用性環境も、シンプルな構成で運用できる可能性があります。Azure SQL Database／Azure SQL Database Managed Instance／Azure SQL Data Warehouseはデフォルトで冗長化されており、PaaSに移行することで、“可用性環境に移行した”と見なすことができます。

　なお、PaaSではSQL Serverの全機能はサポートされていないため、SQL Serverを移行先としたシンプルなバージョンアップと比較した場合に、“利用可能な機能の違い”を考慮する必要があります。PaaSとIaaSの違いや、通常のSQL ServerとPaaSのSQL Serverの機能比較については情報が公開されていますので、こちらを確認してください。

　クラウドのSQL Serverは常に進化しています。以前、機能の違いでクラウドの利用を見送ったことがあっても、最新環境ではその機能が利用可能になっていることもあります。移行のタイミングで、常に最新の情報をチェックしておきましょう。

●データベースの移行方法

　データベースの移行では、「ユーザーデータベース」と「システムデータベース」でその方法が異なることに注意が必要です。

■ユーザーデータベースの移行
　SQL Server 2005以降のデータベースは、SQL Server 2016／2017にリストアすることができます。SQL Serverデータベースのマイグレーションで最もシンプルなのが、「バックアップとリストア」による移行です。ユーザーが作成したユーザーデータベースについては、この方法での移行をお勧めします。

　通常のSQL ServerやPaaSのAzure SQL Database Managed Instanceをマイグレーション先とする場合は、SQL Serverのバックアップをそのままリストアできるので、シンプルな移行が可能です。

　PaaSのAzure SQL Databaseを使用する場合は、SQL Serverのバックアップをリストアする機能がサポートされていないため、シンプルにデータベースを移行できません。今回は、Azure SQL Databaseを例としましたが、他にもバックアップをリストアできない環境への移行が発生するかもしれません。

　そのような場合は、データベースのオブジェクトをスクリプト化し、データについて「bcpユーティリティー」を利用する方法や、スキーマとデータを含んだ「BACPACファイル」を利用する方法があります。

　この他、「インポート／エクスポートウィザード」といった機能もあるので、移行先の制約に応じて「どの機能使用してユーザーデータベースの移行を行うか」も検討しておきましょう。

■システムデータベースの移行
　master／model／msdbといったシステムデータベースについては、同一バージョンのSQL Server間でなければバックアップをリストアできません。そのためマイグレーションでは、システムデータベースに含まれるオブジェクトは、ユーザーデータベースとは別の移行方式を検討しておく必要があります。システムデータベースに含まれる情報の代表的なオブジェクトには、SQL Serverのインスタンスの設定、ログイン、SQL Serverエージェントのジョブ、リンクサーバがあります。

　システムデータベースに含まれているオブジェクトの移行については、「メタデータの移行方法」に情報があります。ユーザーデータベースに含まれていない設定については、こちらを参考に移行方法を検討してください。

●切り替え時の作業

　データベースの移行方法とともに、実際に環境を切り替える際の作業についても検討しておきましょう。データベースの切り替えには「オフライン移行」「オンライン移行」の2つの方法があります。それぞれの移行方法には、次のような特徴があります。

■オフライン移行
　データベースサーバをある程度の時間停止できるのであれば、停止時間帯に次のような作業を行うことで、データベースをマイグレーションできます。

  • 移行元のデータベースで更新が行われない状態にする
  • 移行元のデータベースのバックアップを取得
  • 移行先にデータベースのバックアップをコピー
  • 移行先でデータベースのバックアップをリストア

　切り替え作業は停止した状態で実施し、停止状態で取得した静止点のデータを使用して移行します。このような、切り替え作業中にダウンタイムを伴う移行方法は「オフライン移行」と呼ばれます。

　移行作業中のシステムのダウンタイムはデータ量に応じて長くなりますが、シンプルな作業で移行できます。

■オンライン移行
　停止時間を可能な限り抑えて移行する場合には、「本番切り替えまでの継続的なデータ移行（データ同期）」を検討します。SQL Serverへの移行であれば、「ログ配布」「レプリケーション」といった機能で、初期のデータ移行と初期データの移行後に発生した変更を継続的に移行先に反映できます（SQL Serverのバージョンごとに、レプリケーションが可能なSQL Serverのバージョンが異なりますので注意してください）。

　継続的なデータ同期を行うことで、切り替え時には最終的なデータ同期のみで移行が完了するため、必要となる停止時間を短くできます。このようなデータを同期する仕組みを活用し、停止時間を極力短くした移行方法は「オンライン移行」と呼ばれます。

　オンライン移行はダウンタイムが少ないのですが、データ同期機能を活用する必要があり、移行元環境に対してデータ同期のための設定変更（または、機能の追加）が発生する可能性があります。「使用したい機能が移行元で利用できる状態となっているか」という調査が必要となることは考慮しておきましょう。

●関連システムの接続先の切り替え

　データベースの切り替えだけでなく、データベースを参照しているシステムの接続先を、移行先のSQL Serverに変更する必要性も考慮しておく必要があります。

　新しい環境として構築したSQL Serverに移行する場合、移行先のSQL Serverのホスト名は既存環境とは異なる設定で構築するのが一般的ではないでしょうか。

　DNSやHOSTSファイルのような名前解決の仕組みで、SQL Serverのホスト名を解決している場合は、名前解決の設定を変更することで接続先を切り替えることができる可能性があります。名前解決を使用していない場合は、データベースに接続しているそれぞれのシステムで接続先の切り替えが必要となります。データベースの切り替え時には、関連システムの接続先の切り替えについても考慮するようにしてください。

　SQL Serverのホスト名を変更する際に必要となる作業の情報が公開されていますので、関連システムの参照先変更を回避するために、移行後にホスト名を移行前の名称と同一にすることを検討している場合は、こちらを参照してください。

Copyright © ITmedia, Inc. All Rights Reserved.

前のページへ | 次のページへ
ページトップに戻る