PHPアプリケーションをMySQLからDB2に移行するプロセス: 第2部データの移行

IBM社内のイントラネット・アプリケーションの事例に基づく移行について

PHPアプリケーションをDB2に移行する意義を確認したうえで、IBMのイントラネット・アプリケーションの事例に基づいて、移行の計画を立て、実行し、その後のメンテナンスを行い、発生する可能性のあるリスクに対応する方法について説明します。本シリーズは4部に分かれており、IBM社内でibm.comのコンテンツの製作のために使用されるミッション・クリティカルなPHPに基づくイントラネット・アプリケーション(グローバルに4,000名のユーザーが存在)をMySQLからDB2にスムーズに移行したプロジェクトから得られた教訓について説明します。本第2部では、データベースの移行のステップについて説明します。

Daniel Krook, ソフトウェア・エンジニア, IBM

Daniel Krookはニューヨーク・エリアにおいてIBMとOpen Groupの認証を受けたITスペシャリストです。Webアプリケーションの開発に関して10年の経験があり、現在はJava EE、DB2、REST、およびモバイル・テクノロジーを使用して、IBM社内用のクラウド・インフラの構築を行っています。PHP、Java EE、Blackberry、DB2、およびSolarisに関する認定資格を有しています。IBMのdeveloperWorks向けにPHPに関連する記事を寄稿しており、IBM Redbook("Developing PHP Applications for IBM Data Servers.")の共著者でもあります。



Yan Li Mu, ITアーキテクト, IBM

Yan Li Muは中国の大連でITアーキテクトを務めています。Java EEテクノロジー、PHP、およびデータベース開発を中心として、Webアプリケーションの開発に8年以上従事しています。



Mark Nusekabel, シニアITアーキテクト, IBM

Mark Nusekabelは、フロリダ州タンバベイ・エリア在住のIBMとOpen Groupの認証を受けたITアーキテクトです。IT業界において20年間の実績があり、現在はJavaScript、PHP、Java、およびDB2を使用した社内ツールの構築を行っています。Markはe-ビジネス・ソリューション、Java、XMLに関する認定資格を保有しています。



2012年 6月 13日

本シリーズについて

My SQLは、現在PHPプログラミングで最も多く使用されているデータベース・サーバーですが、DB2もPHPの機能に対応した汎用度の高いデータベースであり、多くのアプリケーションに最適な機能を提供する点ではMySQLを上回る大きなメリットを提供します。

本シリーズでは、PHPアプリケーションをDB2に移行する際のメリットについて説明したうえで、実際の移行例に基づいて移行の準備方法および実行方法、メンテナンス方法、発生する恐れのあるリスクへの対応方法について説明します。プロジェクトをスムーズに進めるために有用なコードやコンフィギュレーションのサンプルならびに各種関連情報も提供します。

実際の環境でスムーズに移行を行った例とここから得た教訓を参照することで、明確に記載されたステップに基づいて移行を簡単に実行でき、大きなメリットが得られることを確認できます。

本シリーズは4部に分かれています。IBM社内でibm.comのコンテンツ製作のために本番システムで使用されるミッション・クリティカルなPHPアプリケーション(グローバルに4,000名のユーザーが存在)をMySQLからDB2にスムーズに移行したプロジェクトから得た教訓について説明します。

  • 第1部では、移行準備について説明します。
  • 第2部では、データベース移行について説明します。
  • 第3部では、PHPコード変換について説明します。
  • 第4部では、アプリケーションの実装とメンテナンスについて説明します。

本記事の内容

本記事は、PHPアプリケーションをMySQLからDB2に移行する際の一般的なステップについて理解を深めることを目的としています。あわせて、参照可能な関連情報について紹介し、IBMのプロジェクト・チームが2010年のはじめに実行したプロジェクトについて説明します。

MySQLからDB2への移行について調べた経験のあるユーザーであれば、製品の説明資料、パフォーマンス・ベンチマーク、DB2の説明資料に記載されている機能、IBM Redbookの比較資料(MySQL to DB2 Conversion Guide参考文献を参照)からDB2が提供するメリットについて既にご存知かもしれません。

さらに、機能をフルに装備した無償データ・サーバー、DB2 Express-Cも有益な製品です。本製品は、クラウドまたはAmazon EC2でIBM Smart Business Business Development and Testを活用して簡単にインストールと評価を行えます。本ソリューションに関するリンクも、参考文献のセクションに記載しました。

ここでは、IBM社内で頻繁に使用されるPHPによるイントラネット・アプリケーション(ibm.comのWebサイトのさまざまなページでコンテンツ管理用に使用)を2010年にスムーズに移行した実際の例について説明します。

本記事を読むと、同様の移行プロセスの概要把握、実行すべき項目のタイミングと条件の確認、発生する恐れのあるリスクの認識、各ステップにおけるサポートの受け方について確認することができます。これらの情報を確認すれば、ユーザーのPHPアプリケーションが現在MySQLで構築されている場合、確信を持ってDB2を選択し最大限に活用できます。

本記事の適用について

本記事は、IBM社内で実施したMySQLからDB2への移行のプロセスで得られた教訓と同様の処理に利用可能な関連情報について説明します。本記事は、すべてのシナリオに対応しているわけではなく、移行に関する包括的ガイドではありません。


データベースの移行の概要

本記事はMySQLからDB2へのデータベース移行に必要な4つの主要ステップについて説明します。移行を開始する前に、本シリーズの第1部を参照して全体的な移行プロセスのスケジュールを確認できます。

ステップ1: MySQLのデータベース構造をDB2の形式に変換する

  • DB2で新規のデータベースを作成する。
  • 移行元のMySQLのデータベース構造を抽出する。
  • データベースのリバース・エンジニアリングを行い、エンティティーとリレーションシップのダイアグラムを取得する。
  • データモデル構造の精緻化と修正を行う。
  • その他のデータベース・オブジェクトの変換を行う。

ステップ2: MySQLのデータをDB2のデータベースに移行する

  • 不必要なテーブルとデータを排除する。
  • 移行先のDB2のデータ型と連携しない可能性のある移行元データベースのデータを変換する。
  • MySQLからデータを抽出する。
  • DB2にデータをロードする。
  • 生成されるID列の値をリセットする。

ステップ3: ユーザーのパーミッションとデータベースの管理設定を再構築する

  • 必要なユーザー・アカウントを設定し、適切なパーミッションを割り当てる。
  • データベースのバックとリカバリーのプランを設定する。
  • Cognosのレポーティング・システムが使用するミラー・システムを構築するために、レプリケーションの設定を行う。

ステップ4: データベースの移行に関するベースライン情報を保管する

  • データベースの移行が完了したことを確認する。移行が完了しない場合は、第1部の図1のとおり、移行が完了するまでステップ1からステップ3までを実行する。
  • システムのバックアップを行う。
  • アプリケーションの変換の準備を行う。

本事例に基づくMySQLによる既存のPTTデータベースについて

留意事項

必要に応じて参考文献を参照ください。本ステップにおいては、以下の文献が特に役立ちます。

  • 無償提供される“MySQL to DB2 Conversion Guide” (IBM Redbook)の第6章、第7章、および第9章
  • "Recommended reading list: DB2 for Linux, UNIX, and Windows database administration"(developerWorksの資料)
  • "Leverage MySQL skills to learn DB2 Express"(developerWorksの資料)

データベースの移行の際に使用したツールの参照資料、IBM Data Movement Tool、およびRational Software Architectも役立ちます。

移行のプロセスにおいてクラウドを活用することも可能です。Amazon EC2によるLinuxとDB2 AMIを活用ください。IBM Development and Test on the IBM Cloudの契約もできます(参考文献を参照)。

本記事の事例で使用されるプロジェクト・トラッキング・ツール(PTT)の移行元のMySQLデータベースには、テーブルあたり平均で6つの列を含む150個のテーブルが含まれ、合計でおよそ10 GBのテキスト・データが含まれています。PTTは当初MySQLのバージョン3.23で構築され、7年間の間にバージョン5.0に移行しました。テーブルの全ては、デフォルトのMyISAMのエンジンを使用していました。

PTTのデータベースはibm.comで公開されるワークフロー情報をサポートするさまざまな機能に使用されています。本アプリケーションは製品イメージやソリューション資料をはじめとするバイナリー・ファイルを処理するものの、ファイルはバイナリー・データとしてデータベース内に保存されるのではなく、データベースの列に対して論理リンクを設定したファイル・システムに保存されています。

PHP Webのフロントエンド経由で、世界中の4,000名を超えるユーザーが本データベースにアクセスし、データベースの修正を行っています。ある一時点では、最大数百名の同時アクセスユーザーが存在しています。

データは読み取りと書き込み双方に使用される単一のマスターMySQLサーバーからアクセスされます。レプリカ・データベースの同期が保たれており、読み取り専用のレポーティングとアドホックなクエリーに使用されています。データに対しては、毎夜バックアップとアーカイブが行われます。

本記事は、新規のDB2システムに対して同様のコンフィギュレーションを構築する方法と、さらにデータベースの設計を最適化し、データベースの一貫性とデータの品質を向上と、使用されていない古いデータベース構造の削除についても説明します。移行するオブジェクトの数とデータのサイズを削減することでプロセスの簡略化、ストレージ・スペースの節約ができるとともに、未使用データによって生じる可能性のある混乱を縮小できます。


移行のために必要なソフトウェアのインストール

本事例のデータベース移行準備のために、以下のコンポーネントを、移行ステップを実施する際に使用するWindowsワークステーション上にインストールします。

移行元データベースのMySQL(いずれかのバージョン)

データベースの移行は繰り返し実行するプロセスであるため、移行元のMySQLのデータベースのコピーを簡単にアクセス可能なワークステーションにインストールします。これにより、リモート・システムにインストールした場合に比べて、移行中のパフォーマンスを向上でき、移行ステップを実行する際に必要な移行元のデータベースの修正を自由に行えるようになります。

DB2(いずれかのバージョン)

ワークステーション上に新規の移行先のデータベースを構築するためにDB2をインストールします。通常、本データベースは本番システムで使用されているデータベースと同じエディションである必要はありませんが、全ての機能について互換性を保つために、同じエディションを使用することをおすすめします。本記事に記載される事例に基づいて、DB2 Enterprise Server Edition Version 9.7.2をインストールします。

IBM Data Movement Tool

IBM Data Movement Tool(参考文献を参照)の最新バージョンをダウンロードし、解凍します。本ツールを使用することで、MySQLからデータベースを抽出のうえDB2にインポートできます。

データ・パースペクティブを提供する、IBMによるEclipseベースのIntegrated Development Environment (IDE)(オプション)

データベース・モデルの可視化と編集に使用できるオールインワンの開発ツールである Rational Software Architect の使用が可能です。Rational Software ArchitectやInfoSphere Data ArchitectやOptim Development Studioをはじめとするその他のツールに関するリンクを参考文献のセクションで確認できます。

設定内容と得られた情報を詳細に記録しておくことで、展開のステップを繰り返し実行できます。重要な目標を達成した主なマイルストーンにおいてWindowsオペレーティング・システムのスナップショットを仮想イメージに保存することで、コンフィギュレーションのバックアップとして活用し、今後データベースの改善を行う際に活用可能なベースライン情報として使用できます。

物理マシンのコンフィギュレーションのイメージをキャプチャーしたい場合は、無償提供されるVMware vCenter Converterを活用できます。その他の方法としては、クラウドを活用して変更もできます。Amazon EC2によるDB2 AMIを使用したり、IBM Development and Test on the IBM Cloudの契約もできます。仮想コンピューターを使用することで、サーバー・ハードウェアの調達を行い、オペレーティング・システムとDB2をインストールする作業を省けるため、所要時間を削減し、移行プロセスを迅速化し、余裕を持ってニーズに最も合致するコンフィギュレーションを試すことが可能になります。これらの製品に関するリンクは、参考文献にあります。


ステップ1: MySQLのデータベース構造をDB2の形式に変換する

ワークステーション上で必要なソフトウェアのセットアップを完了後、まずMySQLデータベースからテーブルを抽出し、新規のDB2データベースで再作成する必要があります。本ステップには、以下のサブステップの実行が含まれます。

DB2で新規のデータベースを構築する

PTTアプリケーションは世界中のユーザーをサポートするため、新規のDB2データベースが複数の言語と文字セットに対応していることを最初の時点で確認する必要があります。本要件に対応するには、UTF-8のコードセットを持つデータベースを作成します。

コードセットの選択に加えて、どの参照アルゴリズムが目的に合致するかどうかを検証します。本アルゴリズムの設定によってDBがデータベース内でテキストのソートと評価を行う方法が決まり、文字列の比較を行う際のパフォーマンスに影響が出ることがあります。

MySQLによるシステムがデータを処理する方法を保存するために、大文字と小文字を区別しない設定に基づいて、UCA500R1_S1のUnicodeの参照アルゴリズムを選択します。これによって、ケースと文字のソートを行うことができます。本コンフィギュレーションによって、roleRole、およびrôleの文字列は同じ文字列としてソートされ、比較されます。

エンコードと比較に関するコンフィギュレーションを設定後、新規のデータベースを構築するために使用するコマンドがリスト1に表示されています。本コマンドは、DB2が提供するコマンドラインプロセッサーに含まれています。コマンドを読みやすくするため、本コマンドに改行を加えてあります。

リスト1. 新規のDB2データベースを作成するためのコマンド
CREATE DATABASE PTT 
USING CODESET UTF-8
TERRITORY US 
COLLATE USING UCA500R1_S1
PAGESIZE 4096;

データベースを構築する際にいくつかのデフォルト設定に同意することによって、DB2に組み込まれた自動化機能によるメンテナンス・タスクを自動的に実行できます。例えば、自動ストレージはデフォルトでオンに設定されており、セルフチューニング・メモリーも有効化されています。

データベースの構築時に設定できるオプションがいくつか存在しています。データベースの設定を後から修正するのではなく、当初からデータベースの設定を適切に行う方が好ましいため、各種設定について確認しておくことをおすすめします。“MySQL to DB2 Conversion Guide”(参考文献を参照)の6.2.1章では、これらのオプションの詳細情報について説明しています。

移行元のMySQLのデータベース構造を抽出する

次に、MySQLのデータベース構造を抽出し、DB2にロードします。データベースのサイズが小さい場合は、mysqldumpユーティリティーを使用して、MySQLから移行元のDDLを抽出し、対応するDB2の構文に合致するように修正することができます。MySQL to DB2 Conversion Guide参考文献を参照)の6.1章では、各データ型に関する説明とデータ型を比較した表が提供されています。

本記事で紹介されている150個のテーブルが含まれるような大規模なデータベースの場合、IBM Data Movement Toolを使用してデータベース構造の抽出を自動化することをおすすめします。IBM Data Movement Toolは単純なユーザーインターフェースによって、ローカルのMySQLデータベースと新規に構築されたDB2データベースの両方にアクセスすることができます。IBM Data Movement Toolを使用して本ステップで必要なデータベース構造の抽出を行う詳細の方法については、参考文献をご参照ください。

以下の図1の例では、「Data」のチェックボックスのみを選択し、「Extract DDL/Data」をクリックします。

図1. DDLの抽出
図1. DDLの抽出

IBM Data Movement Toolによってデータベース構造の抽出を行った後、migrディレクトリーに一連のDDLファイルが表示されます。空のファイルが存在する場合があります。本記事で取り上げた移行元のMySQLデータベースにはユーザーが設定した関数が存在しないため、db2udf.sqlファイルにはコンテンツが含まれていません。

DDLファイルと同じディレクトリーに存在するdb2ddl.cmdのバッチ・ジョブを実行することで、DDLをローカルのDB2データベースにロードします。

データベースのリバース・エンジニアリングを行い、ERダイアグラムを取得する

DDLをDB2にロードした後、RSAを使用してDB2内に存在するデータベース構造のリバース・エンジニアリングを行います。新規に構築したDB2データベースにアクセスし、Rational Software Architectを使用して本データベースのビジュアル・モデルを抽出します。本プロセスはリバース・エンジニアリングと呼ばれ、データベースをエンティティーとリレーションシップ(ER)のダイアグラムに変換することで、テーブル、テーブルの列、それらの間にあるリレーションシップを表示できます。

このステップでは、使用されていないテーブルを削除し、特定の列のデータ型を変更し、主キーと外部キーを追加することができます。このステップはオプションですが、実施することにより現在のニーズに、より適合するデータ構造を再構築できるようになります。

前述のとおり、DB2構文に合致するようにDDLを手作業で編集することでデータモデルの修正もできますが、ERダイアグラムの形でビジュアル・モデルを生成すると、データ構造の表示、文書化、および管理に役に立ちます。このERダイアグラムはITチームとビジネス部門の関係者向けの参照資料として活用できます。

本ダイアグラムを生成し、以下に説明される関連タスクを実行することで、以下のメリットを実現できます。

テーブルまたはビュー間のリレーションシップの構築

リレーショナル・データベース内のテーブル同士がどのように関連付けられているのかを理解するために役立ちます。

共通機能を提供するテーブルの特定の色付け

本記事の例では、USER、ACL、およびROLEのテーブルが相互に連携して権限付与と認証の機能を提供 しているため、データモデルにおいてこれらのテーブルを共通の色で表示することで、テーブル間に論理的な関連付けを設定することができます。

データ構造移行プロセス中に修正された列の強調と変更理由コメントの追加

移行プロセス中に変更された列やテーブルの管理に役立ちます。

既存のデータベースのリバース・エンジニアリングを行いデータモデルを構築する方法の詳細については、InfoSphere Data Architectにおける実行方法(参考文献を参照)で確認できます。IBMがEclipse Data Tools Platformに基づいて提供するEclipseベースのIDEでリバース・エンジニアリングを行う場合は、同様の手法を活用できます。その場合は、本記事の例で使用されているApache Derbyのデータベースを使用するのではなく、DB2データベースにアクセスする必要があります。

データモデル構造の精緻化と修正を行う

ERダイアグラムを生成したかどうかにかかわらず、この時点でデータ構造の強化を開始できます。本記事の例で行われた修正をおすすめします。

主キーと主キーに依存する外部キーの間でデータ型が同じであることを確認する

例えば、USERテーブルの主キーのデータ型がSMALLINTでありながら、別のテーブルでこの主キーを論理的に参照するUSER_ID外部キーがより大きな数値のINTEGERのデータ型であることがあります。このような事はMySQLのデータベース構造では頻繁に発生します。データ型が外部キーの適用ができないMySQLのバージョンで元々設定されたため、2つのデータ型の間で整合性を保つ必要がなかったためです。

必要に応じて、ID列の最大サイズを拡張する

アプリケーションを長期間使用している場合、ID列の値が設定された上限に近付いている場合があります。移行によって、この潜在的問題に対応することができます。例えば、USERテーブルのID列にSMALLINTのデータ型が設定されていて、ユーザー数が将来32,767を超える可能性がある場合は、ID列のデータ型をより大きな数に対応するINTEGERに現時点で拡張することで、将来的に最大20億名のユーザーに対応できるようになります。

可能な場合、MySQLのTEXTフィールドをDB2のCLOBのテキストオブジェクト型からVARCHARの文字の型に変更する

DB2のCLOBにはいくつかの制約があります。CLOBはDISTINCT値を検出に使用することはできず、バッファ・プールにロードができません。したがって、CLOBはページ・キャッシュを利用できないため、適切に機能しない場合があります。可能な場合、TEXTフィールドをVARCHARに変更することをおすすめします。テーブルスペースでVARCHAR列の最大サイズを設定しているため、最大32KBのテキストしか保存できないからです。

古い列や使用していない列を削除する

アプリケーションによってはレポートの保存にさまざまなアプローチが採用されていることがあるため、現在では意味のない大容量のデータを含むいくつかのレガシー・テーブルが存在し、ITチームに新しく加わった開発者を混乱させることがあります。このようなデータをアーカイブに保存し、有効なデータベースから削除することをおすすめします。

必要に応じて、主キーや一意制約を追加する

本処理は、一意制約によって提供されるデータの一貫性以上にDB2のレプリケーションにとって重要なものです。バックアップ・データベースに一意性のある値を提供するには、各テーブルに主キーまたは一意キーが必要です。

新規の外部キーを設定し、導入する

本記事の例にあるMySQLデータベースには外部キーは存在しません。元々本アプリケーションの構築に使用されたデフォルトのMyISAMのストレージ・エンジンは外部キーに対応していなかったためです。データ変換の段階において、データの一貫性を向上するために必要な外部キーを追加します。例えば、USERテーブルをTASK_HISTORYテーブルに関連付けることで、ユーザーの変更を管理する監査レコードの整合性が失われないようにできます。

インデックス、ビュー、ストアード・プロシージャー、および関数のようなその他のオブジェクトの変換と追加を行う

データ構造の可視化を行うことで、テーブル間のリレーションシップ、各テーブルの重要性、アクセス頻度といったパフォーマンスに影響を及ぼす要因を把握できます。これを行うことによって、データの品質と読み取りスピードを向上するために、制約を適用すべき箇所を把握し、関連するアクションを連携させるべき箇所を把握できます。

RSAで設定した新規のデータ構造モデルが存在する場合、当該モデルを単一のDDLファイルとしてエクスポートし、 当該ファイルに基づいて新規のDB2データベースを構築できます。データベース構造の複雑度によっては、異なるオブジェクトのタイプごとに個別のDDLファイルを生成することで、オブジェクトの整合性をローカルで管理できます。

反復する移行プロセスの実行にあたり推奨する例として、テーブル用、インデックス用そして外部キー用と、それぞれ別のファイルでDDLを作成する事が挙げられます。 これにより、データ構造を関連性のある部分に論理的に分割できるようになります。このような手法を実施することで、時の経過とともに変化するインデックスやその他のより継続的に使用されるオブジェクト(例: テーブルやビュー)の定義をDDLファイル内で検索する必要がなくなり、最新の一連のインデックスについて確認したい場合は各ファイルのDDLを参照すれば済みます。

IBMが提供するEclipseベースのツールを使用してデータモデルを修正しエクスポートする方法は、前日のリバース・エンジニアリングのタスクと同様、参考文献で紹介されているInfoSphereの資料の物理データモデルをDDLに変換するプロセスを参照して確認できます。

その他のデータベース・オブジェクトを変換する

IBM Data Movement Toolでは、テーブル、キー、インデックス、およびテーブルスペースをはじめとするほとんどのデータベース・オブジェクトを自動的に変換できますが、移行元のMySQLデータベースに存在する一部のオブジェクトは手作業で変換する必要があります。これには、ビュー、ストアード・プロシージャー、ユーザーが設定した関数(UDF)、およびトリガーが挙げられます。

MySQLとDB2は両方ともSQL:2003のストレージ・プロシージャ―構文に準拠しているため、これらのオブジェクトを手作業で移行することは難しくありません。また、DB2のトリガー機能はMySQLで提供されている機能を上回るため、簡単にトリガーの再構築もできます。“Developing PHP Applications for IBM Data Servers” (IBM Redbook)の第6章では、認識すべき両製品の差異を詳述しています。

さらに、ステップ2においてデータ移行中に発生するエラー防止方法として、データをDB2にロードするプロセスが完了するまで本タスクを延期し、データベースの精度を向上した後、再度データ移行の段階で本タスクを実行することができます。


ステップ2: MySQLのデータをDB2データベースに移行する

本ステップでは、MySQLデータベースからデータを抽出し、DB2にロードします。本プロセスによって、データの品質を向上できます。本ステップには以下が含まれます。

不必要なテーブルとデータを削除する

IBM Data Movement Toolは、table name.tablesファイルを生成します。本ファイルはデータベース・テーブルごとにSELECTクエリーを特定することで、移行元データベースから抽出すべきデータを指定します。例えば、開始後4年未満のタスクのみを抽出することができます。移行対象のデータの量を設定するにあたっては、いくつかの行を削除し、WEHERE文で他の行を追加する必要があります。

MySQLからDB2に移行したくないテーブルがある場合は、本ファイルから当該テーブルを完全に削除する必要があります。データの一部を移行したい場合は、SELECT句を適切に修正します。本事例においては、リスト2のとおり行を削除することで、WORK_TMPテーブルがDB2に移行されないように設定します。

リスト 2. timetrac.tablesファイルから行を削除する
"timetrac"."work_tmp":SELECT * FROM "timetrac"."work_tmp"

さらに、WORKテーブルで2008年以降に作成されたデータのみを移行対象とすることもできます。この場合は、リスト3のとおりWHERE句を追加します。

リスト 3. 日付に基づいて移行対象のデータを設定するために、行を編集する
"timetrac"."work":SELECT * FROM "timetrac"."work" WHERE ts >= '2008-01-01'

DB2と互換性を持たないMySQLのデータを変換する

さらに重要なタスクとして、移行元のデータベースと新規のデータベースのデータ型の互換性を確認する必要があります。ステップ1のデータモデルの再構築によってDB2に修正を加えているため、MySQLから移行されるデータがDB2で規定されたデータ型と互換性を持っていることを確認する必要があります。

例えば、TIMEのデータ型はySQLとDB2の両方に存在しているものの、データの範囲が異なります。MySQLではTIMEは-838:59:59から838:59:59までの範囲の時間を指しますが、DB2ではTIMEは00:00:00から24:00:00までの24時間を指します。24時間に当てはまらないTIMEのデータ型のデータが存在している場合、移行を行う前にMySQLのデータがDB2のデータ型と互換性を持つように正規化を行います。リスト4では、変換を行うために使用できるSQL文を表示しています。

リスト4. MySQLのTIMEデータの変換を行うことで、DB2と互換性を保持する
mysql> UPDATE WORK W SET W.HOUR = SUBTIME(W.HOUR, '24:00:00') WHERE W.HOUR >= '24:00:00';

移行を行う前に、移行元のデータベースで変更の必要があるデータ型が他にも存在する場合があります。“MySQL to DB2 Conversion Guide”(参考文献を参照)の6.1章では、各データ型の詳細説明とデータの互換性を説明した表を提供しています。

MySQLからデータを抽出する

移行用のためにMySQLのデータが準備できた時点で、IBM Data Movement Toolを再度開き、図2のとおり「Data」チェックボックスをチェックし、「Extract DDL/Data」をクリックします。

図2. 抽出のためのスクリプトを生成する
図2. 抽出のためのスクリプトを生成する

本設定が完了すると、migrフォルダにgeninput、rowcount、timetrac.tables(timetracはデータベース名を指します)、およびunloadの4つのファイルが生成されます。

timetrac.tablesファイルを、移行対象のデータを一部のデータに絞るデータベースの抽出ステップの後で編集したファイルで置き換えます。「unload」を起動することで、MySQLからデータを抽出します。移行が完了した時点で、IBMDataMovementTool.logファイルのエラー・メッセージを確認します。アンロードがスムーズに完了すると、db2load.cmdファイルやデータ・フォルダ等の多くのファイルが生成されています。

DB2にデータをロードする

migrディレクトリーに移動し、「db2load.cmd」のバッチスクリプトを起動して、データを実際にDB2に移行するプロセスを実行します。

db2load.logをチェックして、全てのデータがDB2に適切にロードされたか確認します。IBM Data Movement Toolによって、移行元のMySQLデータベースの行数がDB2のテーブルの行数と同一か確認するスクリプトが提供されます。「rowcount」コマンドを起動して行数が合致するか確認もできます。

これ以外にも、重要なクエリーの出力結果を比較する等の他の手法で、DB2のデータを慎重に検証したいと考える場合があります。“MySQL to DB2 Conversion Guide”(参考文献を参照)の7.2.7章では、移行済みのデータを検証する戦略についていくつか説明しています。

生成されるID列の値をリセットする

データの移行が完了すると、データベースのアップデートを行い、自動的に生成されたID列の値を移行データの全ての既存の値よりも大きくする必要がある場合があります。例えば、移行したデータに3,000行のデータが存在する場合、データベースの修正を行うことで、新規のレコード用に1から始まるIDを割り当てて混乱を生じさせるのではなく、3,000よりも大きい数のID(例: 5,000)を生成したいと考える場合があります。リスト5では、列の定義を修正することで生成されるID列の番号をリセットするコマンドについて説明しています。

リスト5. 生成されるID列の値をリセットするためのコマンド
ALTER TABLE WORK ALTER COLUMN ID RESTART WITH 5000;

ステップ3: ユーザーのパーミッションとデータベースの管理設定を再構築する

データベース構造とデータのDB2へのインポートが完了すると、3番目の重要なステップとして、データのアクセスと管理が正確に設定されているか確認する必要があります。そのため、必要なユーザー・アカウントの設定を行い、当該アカウントに適切なパーミッションを割り当てる必要があります。その後、DB2の担当者と調整を行ったDB2の設定方法に基づいて、データベースのバックアップと災害復旧のコンフィギュレーションを実装します。最後にレプリケーションの設定を行い、レポートを生成するためのCognosのビジネスインテリジェンス・システムが使用するミラー・システムを構築します。

本ステップには、以下のサブステップが含まれます。

パーミッションのモデルを変換する

DB2,のインストールを行った時点で、デフォルトのインスタンスオーナーユーザーIDであるdb2inst1が作成されています。MySQLのデータベースでは、これと同様の管理ユーザーのルートIDが存在していました。したがって、 ルートユーザーが通常実行する関数を実行する場合には、db2inst1を使用することになります。

これ以外に2つのユーザー・アカウントを設定する必要があります。pttuserユーザーは、アプリケーションが必要とする読み取りと書き込み処理を実行します。さらに、本番データベースとレプリカ・データベースにおいて、readユーザーが必要です。このアカウントは本番データベースで読み取り専用クエリーの実行に必要となります。レプリカ・データベースのCognosのレポーティング・システムもこの読み取り処理用のアカウントを使用します。表1では、これらのアカウントについて説明しています。

表1. ユーザーのリスト
ユーザー内容データベース
管理ユーザー(db2inst1)SYSADM権限を有するユーザー・アカウント本番データベースとレポーティング・データベース
アプリケーション・ユーザー(pttuser)本番データベースへの読み取りと書き込みを行うユーザー本番データベース
レポーティング・ユーザー(read)本番データベースとレポーティグ・データベースへの読み取り処理を行うユーザー本番データベースとレポーティング・データベース

これらのユーザー・アカウントはLinuxオペレーティング・システムで作成ができ、これらのアカウントに正確なデータベース権限を割り当てるためにGRANT文を使用します。本プロセスは、通常DB2データベースを構築しMySQLからDB2にデータの移行を完了した後で、個別のアクティビティーとして実行します。しかし、本番システムを実装する際には、データベース構造を構築するために使用したDDLと同じDDLにGRANT文を組み込む必要があります。

MySQLでは各ユーザー(アクセスを行う際に使用するホスト名によって識別される)にデータベース全体への読み取り、書き込み、またはその他の管理を行うパーミッションを付与するため、アクセスの提供を精緻に行うことはできません。本事例では、pttuserユーザーはデータベースへの読み取りと書き込みを行う権限を有している(Webサーバーのホスト名からのみ当該処理を行うことが可能)ため、データベース内の各テーブルへのアクセスと修正ができます。

DB2でもユーザーにアクセスを付与しますが、ユーザーがアクセスする際に使用するホスト名を指定することはありません。また、DB2では、MySQLと同様にデータへのアクセス権限の検索・追加・更新ができます。しかし、データベース全体へのアクセスを付与する単一のコマンドは存在しないため、データベースの各テーブルに対してユーザー・アクセスを設定する必要があります。(当該ユーザー用のデータベースとテーブルを作成した場合は、この条件は適用されないものの、このような設定を行うことはおすすめしません。)したがって、通常はテーブルなどのオブジェクトが構築された後で、DDLにGRANTコマンドが挿入されます。

リスト6は、本事例でWORKテーブルに権限を付与するパーミッションを示しています。アプリケーション・ユーザーには読み取りと書き込みに関するフルアクセスが付与されますが、レポーティング・ユーザーは読み取り処理のみできます。

リスト6. GRANT文の例
-- GRANT statements to provide read/write access to the application user account
GRANT DELETE ON TABLE "TIMETRAC"."WORK" TO USER "PTTUSER"; 
GRANT INSERT ON TABLE "TIMETRAC"."WORK" TO USER "PTTUSER"; 
GRANT SELECT ON TABLE "TIMETRAC"."WORK" TO USER "PTTUSER";  
GRANT UPDATE ON TABLE "TIMETRAC"."WORK" TO USER "PTTUSER"; 

-- GRANT statement to provide read only access to the reporting/ad hoc user account
GRANT SELECT ON TABLE "TIMETRAC"."WORK" TO USER "READ";

MySQL to DB2 Conversion Guide”(参考文献を参照)の7.13章では、DB2によるユーザー・アカウントの管理機能と精緻な管理機能の詳細情報について説明しています。

バックアップとリストアのプロシージャーを変換する

この時点で災害復旧プランを構築して、可用性の高いアプリケーションを実現したうえで、データのアーカイブを行う要件にも対応できます。

MySQLでは、mysqldumpのようなコマンドを使用することでデータのバックアップを行い、データのリストアを行うSQLを実行することができます。本事例のシステムでは、mysqldumpを使用して毎夜バックアップを行い、読み取り専用のレポーティングのためにレプリカ・データベースにおいてデータの同期を行うことができます。本レプリカ・データベースはフェイルオーバー・システムとしても機能します。

新規に実装されるデータベースにおいては、DB2が提供するツールを使用してバックアップとリストアのコマンドを定期的に実行します。オフラインまたはオンラインでフルバックアップまたはインクリメンタル・バックアップを行うためのコマンドの使用方法にはいくつかのオプションがあります。例えば、毎日1度オンラインのインクリメンタル・バックアップを行い、その後メンテナンスの時間帯を利用して毎週1回オフラインのフルバックアップができます。表2は、本事例のバックアップとリストアのポリシーとスケジュールを説明しています。

表2. バックアップと災害復旧のプラン
タスク内容
毎夜のオンライン・バックアップ毎夜DB2データベースのオンライン・バックアップを行い、当該DB2サーバーに保存します。これにより、単純なデータベースのトラブルが発生した際に、迅速かつ簡単にリカバリーを行えます。バックアップを行う際に、アプリケーションの中断を行う必要はありあません。しかし、ログに基づいてバックアップ・データからロールフォワード・リカバリーを行うことはできないため、バックアップが行われた時点からデータベースがクラッシュした時点までのデータの全てが失われる可能性があります。
週次のオフライン・バックアップ毎週末にDB2データベースのオフライン・バックアップを行い、できれば他のロケーションに存在する他のサーバーに保存します。これにより、サーバーで重大なトラブルが発生した際に、より信頼性の高いリカバリーができます。この場合、アプリケーションの処理は中断します。しかし、ログに基づいてバックアップ・データからロールフォワード・リカバリーができるため、ログを再生することで、バックアップ・データとバックアップを行った後に記録された業務データを使用して全てのデータをリカバリーできます。

MySQL to DB2 Conversion Guide”(参考文献を参照)の第9章は、新規のバックアップとリカバリーのプロセスの設計と実装を行うための詳細情報を説明しています。バックアップのためのサンプル・コマンドが提供され、DB2 Control CenterやOptim Development Studioを使用してバックアップを定期的に実行するための注意事項が説明されています。

レポーティングのためのレプリケーション・モデルを変換する

本シリーズの第1部で説明したとおり、Cognosのようなツールを導入することでビジネスインテリジェンス機能を改善できることが、DB2への移行を促進する主な要因となります。したがって、クエリーを実行し、レポートを抽出するためのレプリカ・データベースの構築が、データベースの移行プロセスで重要な意味を持ちます。

データに対してレポーティングを実行している場合は、マスターデータを提供する本番データベースの負荷を削減するために読み取り専用のレプリカ・データベースが存在している場合がよくあります。レプリカ・データベースは本番データベースをそのままコピーしたものです。データベースのマスター・インスタンスに対して情報にアクセスし修正するアプリケーションを起動し、全てのデータをレプリカ・データベースにクローンし、データベースの読み取り専用インスタンスに対してレポーティングを実行します。

MySQLとDB2ではレプリケーションの機能が異なります。MySQLではいくつかのコンフィギュレーション・パラメーターを変更することで、あるサーバーから別のサーバーにリアルタイムでデータベース全体のレプリケーションを行うことができます。または、バックアップしたデータを別のタイミングで他のデータベースに非同期でリストアップすることもできます。

DB2では、SQLレプリケーションQレプリケーションという似通ったオプションを提供しています。本事例では、SQLレプリケーションを使用しています。これは、Qレプリケーションを処理する際に必要となるチャネルベースのメッセージキュー・マネージャーによって、プロセスが複雑になることを回避するためです。SQLレプリケーションでは、コンフィギュレーションを構築することで、レプリケーションの対象となるデータベース内の各テーブルを指定します。データベース構造に変更を加えた場合は、コンフィギュレーションをアップデートする必要があります。

さらに、DB2でレプリケーションの設定を行う前に、各データベース・テーブルに主キーと一意インデックスが存在していることを確認する必要があります。主キーと一意インデックスが存在することが好ましいものの、この条件を満たしていないデータベースも存在するためです。前述のとおり、本事例のMySQLテーブルはデフォルトのMyISAMストレージ・エンジンに基づいて構築されたため、これらの値を持っていませんでした。MySQLのレプリケーションは主キーや一意インデックスのあるなしにかかわらず機能しますが、DB2のレプリケーションではテーブルにおいて一意的に行を特定するキーまたはインデックスが必要です。テーブルに主キーや一意インデックスが存在しない場合、更新されたレコードを検出するためのキーが存在しないため、本番データベースで更新されたレコードは、更新された既存レコードではなく作成された新規レコードとしてみなされる場合があります。

MySQL to DB2 Conversion Guide”(参考文献を参照)の第9章では、レプリケーションの設定に役立つ情報を提供しています。DB2によってレプリケーション設定を管理するために役立つツールが提供されており、ログデータを転送することでカスタム・ソリューションを実装することもできます。


ステップ4: データベースの移行に関するベースライン情報を保管する

ステップ1からステップ3(各ステップに複数のサブステップが存在)までの繰り返し行うプロセスを1度完了した時点では、Windowsワークステーション上に一連の機能を提供するデータベース・システムが完成し、変更を行った項目や問題の発生した項目についていくつかの教訓が得られているはずです。

仮想マシンを使用した場合、Winsowsシステムのイメージをスナップショットとしてキャプチャーできます。本情報は利用可能な機能をアーカイブした情報として活用できれば、将来パフォーマンスの変化を比較するためのベースライン資料としても使用できます。その他の方法として、IBMやAmazonによるクラウド環境における仮想イメージを使用することで、同じ目的を達成できます。

いくつかの移行プロセスを試験的に実行することで、どの方法が自社の環境に最適かどうかを確認できます。ステップ1からステップ3で使用されたWindowsワークステーションのシステムに納得した時点で、データベースを専用のサーバーに移行します。さらに、本シリーズの第3部に記載されるとおり、本サーバーにおいてPHPアプリケーションにアップデートを適用します。


結論

本記事の目的は、PHPアプリケーションをMySQLからDB2に移行する際に通常必要となるプロセスを理解し、利用可能な参照資料を把握し、実際にスムーズに移行を行った事例について確認することです。

本シリーズの第2部は、以下の情報を提供します。

  • 変換対象の移行元のMySQlデータベースについて確認する。
  • DB2用にデータベース構造を変換する方法について確認する。
  • データをDB2に移行する方法について確認する。
  • データベースの管理機能の設定方法について確認する。

本シリーズの次のセクションでは、PHPコードの変換方法について確認することができます。

謝辞

本記事の記載内容を確認し、コメントを提供してくれたLeons PetrazickisとAmbrish Bhargavaに感謝します。

参考文献

学ぶために

製品や技術を入手するために

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Information Management, Open source
ArticleID=779833
ArticleTitle=PHPアプリケーションをMySQLからDB2に移行するプロセス: 第2部データの移行
publish-date=06132012