AIX、Windows 上のセルフマネージド型 Db2 から Amazon RDS for Db2 へ IBM Q レプリケーションを使用してほぼゼロのダウンタイムで移行

本記事は 2024年6月11日にAWS Database Blogで公開された ”Near zero-downtime migrations from self-managed Db2 on AIX or Windows to Amazon RDS for Db2 using IBM Q Replication” を翻訳したものです。

Db2 は、大規模なトランザクションおよび分析ワークロードをサポートする IBM のリレーショナル・データベースです。 Amazon Relational Database Service (Amazon RDS) for Db2  は、クラウドで Db2 データベースのセットアップ、運用、スケーリングを簡単に行えるようにする新しい RDS エンジンです。これにより、お客様はアプリケーションやビジネスに集中できるようになります。

お客様がミッション・クリティカルな Db2 データベースをオンプレミスまたは Amazon Elastic Compute Cloud (Amazon EC2) から Amazon RDS for Db2 に移行する場合の重要な要件の １つはダウンタイムをほぼゼロにすることです。これには次のような理由が考えられます。

• テーブルをアンロードしても通常の業務が中断されることはありませんが、アンロードのために勤務時間中にアクセスを停止させると業務に影響がでる
• 一部の重要なテーブルには、サイズが 1TB を超える数10億のレコードが含まれています。これらの膨大なデータセットは、営業時間外での限られたメンテナンス時間内にはアンロードできない

これらの課題には、論理データ・レプリケーションを使用して対処できます。テーブルのロード中の変更をキャプチャすることで、停止する必要はなく、ソース・データベースに接続するアプリケーションへの影響もありません。

データベースを移行するには、最初に全てのデータベース・オブジェクトを再作成し、次にテーブルごとのフルロードを行います。その後、データベース・トランザクション・ログから変更を反映させることができます。

Db2 移行ツール (Db2mt) は、IBM と AWS が共同で開発したツールで、RDS for Db2 へのデータ移行を支援します。Db2MT は GitHub で配布およびサポートされています。問題や機能要望リクエストは、リポジトリ内で直接上げることができます。このツールは、並列処理を使用して全てのデータベース定義とデータをアンロードし、データとデータベース定義をクラウドへアップロードし、Amazon RDS for DB2 へ直接データをロードすることで、移行プロセスを簡素化し、大幅にスピードアップします。

ソリューション概要

このブログでは、IBM InfoSphere Data Replication (IIDR) の Q レプリケーションを使用し、最小限のダウンタイムでデータを移行する方法を説明します。ソース・データベース (オンプレミス) からターゲット・データベース (Amazon RDS for Db2) へデータをレプリケートするように Q レプリケーションを設定する手順を順を追って説明します。移行は、ソース・システムがオンラインのままバックグラウンドで行われます。ターゲット・データベースがフルロードされ、レプリケーション・プロセスによってソースとの同期が保たれたら、全てのデータが同期され、一貫性があることを確認するために短時間停止させるだけで新しいターゲット・データベースへ切り替えられます。

ソリューションアーキテクチャは下図となります。

Amazon EC2 を使用して Q レプリケーション・インスタンスをホストしています。Q レプリケーション・インスタンスは、リモートからソース・データベースの変更をキャプチャし、それらをターゲット RDS for Db2 データベースに適用します。Q レプリケーション・プロセスは、ソース・データベースのリカバリー・ログから抽出された変更をステージングするために IBM MQ を使用し、そのメタ・データを保持するために Db2 インスタンスを使用します。IBM MQ、Db2、Q レプリケーション実行ファイルが EC2 インスタンスにインストールされています。

• AWS Direct Connect を使用したオンプレミス-AWS間の接続
• RDS for Db2 インスタンス
• データ・マイグレーション用の Db2MT
• 全てのデータが移行されるまでのソース Db2 のリカバリー・ログの保持

Q レプリケーション環境のセットアップ

有効なアカウントがあれば、IBM Passport Advantage から IBM MQ および Db2 ソフトウェア・イメージをダウンロードできます。このブログでは、90日間有効な IBM MQ と Db2 エンタープライズのトライアル・ライセンスを使用します。

Q レプリケーション環境をセットアップするために、以下の手順を実行します。

1. 前提条件に従い EC2 インスタンス (Linux) を構成、IBM MQ インストール

2. MQ ライセンス承諾、キュー・マネージャー作成 (このブログでは、QMRDSとしています）

sudo /opt/mqm/bin/mqlicense -accept
sudo /opt/mqm/bin/setmqenv -s dspmqver
sudo /opt/mqm/bin/crtmqm QMRDS

3. キュー・マネージャー起動

sudo su - mqm
/opt/mqm/bin/strmqm QMRDS

4. Db2 インストール

tar zxvf v11.5.8_linuxx64_server.tar.gz
sudo ./db2setup -f sysreq -r ../db2server.rsp

5. Db2 クライアント・インスタンス作成

sudo su -
groupadd db2adm
useradd -G db2adm db2rep
add db2rep to mqm group
cd /rdsdbdata/db2-v11.5.8/instance
./db2icrt -s client db2rep

データベース接続のセットアップ

データベース名はソースとターゲットで同じでもかまいませんが、ここで作成する Q レプリケーション・インスタンスのエイリアスは異なっていなければなりません。例では、どちらのインスタンスもデータベース名はbench10kですが、レプリケーションの目的で区別するために、ソースをBENCHS、ターゲットをBENCHTとしてカタログ化しています。

sudo su – db2rep
db2 catalog tcpip node source remote source_ip server 25010
db2 catalog tcpip node target remote rds_ip server 50000
db2 catalog db bench10k as benchs at node source
db2 catalog db benck10k as benckt at node target
mkdir REPL
cd REPL
asnpwd init 
asnpwd add alias benchs id db2inst1 password xxxxx
asnpwd add alias benckt id admin password xxxxx

MQ リソースの作成

MQ リソースを作成するために、以下の手順を実行します。

1. MQ コマンドを呼び出せるように、シェル環境に MQ のパスを追加

sudo su – db2rep

2. .bash_profile に次の行を追加

export PATH=$PATH:$HOME/.local/bin:$HOME/bin:/opt/mqm/bin
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/mqm/lib64\

source bash_profile

Q レプリケーションは、IBM MQ のキューを使用して、キャプチャー・プログラムと アプライ・プログラムの間でメッセージを交換し、キャプチャー・プログラムでリカバリー・ログからキャプチャされたデータをトラックし続けます。キャプチャーとアプライは同じインスタンス上で実行されるため、すべてのキューをローカル・キューにすることができます。以下のキューを作成します。

• RESTARTQ — 再始動キューは、キャプチャー・プログラムが変更のレプリケート状況を追跡し、停止した場合にどこから再開するかを決定するために使用されます。 これには、処理中で最も古いトランザクションの Db2 log シーケンス番号（LSN）と、既にレプリケートされたトランザクションの最大 Commit LSN が含まれます
• ADMINQ — 管理キューは、Q キャプチャー・プロセスと Q アプライ・プロセス間の通信に使用されます
• DATAQ1 — キャプチャー・プロセスによって取得されたトランザクションは、アプライ・プロセスがレプリケートできるようにこのキューにステージングされます。QDEPTHを999999999（デフォルトは5000）に設定し、アプライ・プログラムが停止した場合やターゲット・データベースが一時的に利用できなくなった場合に無制限の量のデータをステージングできるようにしています

3. 次のコードを使用しキューを作成

runmqsc QMRDS

# Execute the below commands in the runmqsc prompt

DEFINE QLOCAL ('QASN.ADMINQ')
DEFINE QLOCAL ('QASN.RESTARTQ')
DEFINE QLOCAL ('QASN.DATAQ1')
alter qlocal(QASN.RESTARTQ) MAXDEPTH(1)
alter qlocal('QASN.DATAQ1') MAXDEPTH(99999999)
end

Q レプリケーション・コントロール表の作成

Q レプリケーションのメタ・データ、モニタリング・データ、および生成されるすべてのメッセージは、Db2 テーブルに保存されます。Q レプリケーションasnclp スクリプトを使用して、Q レプリケーション・コントロール表と、移行したいテーブルのレプリケーション・サブスクリプションを作成します。サブスクリプションを作成すると、コントロール表にデータが挿入されます。asnclp スクリプトは asnclp -f filename として実行されます。

Amazon RDS for Db2 の場合、Q アプライ・コントロール表には独自のテーブル・スペースが必要です。これらのテーブル・スペースは、Amazon RDS for Db2 で直接作成できないため、ストアード・プロシージャーを使用して手動で作成する必要があります。

1. インスタンスの作成に使用した管理者ユーザー名とパスワードを使用して RDS for Db2 インスタンスに接続し、次のコマンドを実行

call rdsadmin.create_bufferpool('BENCH10K', 'BPQASN', 10000, 'Y', 'Y', 8192);
call rdsadmin.create_tablespace('BENCH10K', 'QAQASN', 'BPQASN', 8192);
call rdsadmin.create_tablespace('BENCH10K', 'TSDONEMG', 'BPQASN', 8192);
call rdsadmin.create_tablespace('BENCH10K', 'TSAPCMDOUT', 'BPQASN', 8192);

2. CREATE CONTROL TABLES コマンドで asnclp スクリプトを実行し、レプリケーションに必要なテーブルを作成します。

#
# file control.clp - Creating Control Tables for Q Replication 
#                    Run with: asnclp -f control.clp
#
ASNCLP SESSION SET TO Q REPLICATION;
SET PWDFILE "/home/db2rep/REPL/asnpwd.aut";
SET SERVER CAPTURE TO DBALIAS BENCHS ;
SET SERVER TARGET TO DBALIAS BENCHT ;
SET APPLY SCHEMA  QASN;
SET CAPTURE SCHEMA SOURCE  QASN;
SET QMANAGER "QMRDS" FOR CAPTURE SCHEMA;
SET QMANAGER "QMRDS" FOR APPLY SCHEMA;
SET OUTPUT CAPTURE SCRIPT "crtlcap.sql";
SET OUTPUT TARGET SCRIPT "crtlapp.sql";
#SET RUN SCRIPT LATER ;
SET RUN SCRIPT NOW STOP ON SQL ERROR ON;
CREATE CONTROL TABLES FOR CAPTURE SERVER USING RESTARTQ "QASN.RESTARTQ" ADMINQ "QASN.ADMINQ";
CREATE CONTROL TABLES FOR APPLY SERVER ;

Q レプリケーションでは、ソース・データベースからレプリケートするトランザクションのステージングと送信に使用されるキューを識別する QMAP オブジェクトを作成する必要があります。

3. この構成では、キャプチャーとアプライは同じシステム上で実行され、1つのローカル・キューを使用できます。そのため、CREATE REPLMAP コマンドでは、ソース・キューとターゲット・キューの名前はどちらも QASN.DATAQ1 となります。

#
# File qmap.clp - Creating Q Replication QMAP - run with asnclp -f qmap.clp
#
ASNCLP SESSION SET TO Q REPLICATION;
SET PWDFILE "/home/db2rep/REPL/asnpwd.aut";
SET SERVER CAPTURE TO DBALIAS BENCHT ;
SET SERVER TARGET TO DBALIAS BENCH ;
SET APPLY SCHEMA  QASN;
SET CAPTURE SCHEMA SOURCE  QASN;
SET QMANAGER "QMRDS" FOR CAPTURE SCHEMA;
SET QMANAGER "QMRDS" FOR APPLY SCHEMA;
SET OUTPUT CAPTURE SCRIPT "qmapcap.sql";
SET OUTPUT TARGET SCRIPT "qmapapp.sql";
#SET RUN SCRIPT NOW STOP ON SQL ERROR ON;
SET RUN SCRIPT LATER ;
CREATE REPLQMAP BENCHT_TO_BENCH USING ADMINQ "QASN.ADMINQ"
RECVQ "QASN.DATAQ1" SENDQ "QASN.DATAQ1" NUM APPLY AGENTS 4;

4. MQ キューを識別する QMAP を定義したら、レプリケーション・サブスクリプションを作成する準備は完了となります。

次のスクリプトは、1 つのスキーマの全てのテーブルのサブスクリプションを作成します。

CREATE QSUBコマンドでは HAS LOAD PHASE N オプション (ロードなし) を指定します。これは、Db2MT を使用してターゲットにテーブルをロードするためです。代わりに HAS LOAD PHASE I (内部ロード用) を指定した場合、デフォルトでは Q レプリケーションはカーソルからのロードを使用し、サブスクリプションがアクティブになると自動的にテーブルをロードします。

ターゲット・データベースに既に必要なオブジェクトが全て含まれている場合は、Db2MT ユーティリティを使用する代わりに内部ロードを検討できます。このブログでは、Db2MT を使用し、ロードなしでサブスクリプションを定義します。これは、非常に大きなテーブルをロードする場合や、ロード後にターゲットを同期する場合にも最速の方法だからです。全てのテーブルを一度に移行するには、この方法が推奨されます。ロードがない場合は、キャプチャーを再起動して、全てのテーブルのロードフェーズ中に行われた全ての変更を読み取ります。テーブルのロード中に キャプチャーを実行し、それらの変更を MQ に反映させる必要はありません。もし既に稼働しているレプリケーション構成があり、アクティブなレプリケーション・サブスクリプションを中断せずにテーブルを段階的に追加する必要がある場合は、自動ロードが適切です。

#
# File sub.clp - Creating subscriptions for all tables under a SCHEMA 
# 
#  Run with asnclp -f sub.clp
#
ASNCLP SESSION SET TO Q REPLICATION;
SET PWDFILE "/home/db2rep/REPL/asnpwd.aut";
SET SERVER CAPTURE TO DBALIAS BENCHT ;
SET SERVER TARGET TO DBALIAS BENCH ;
SET APPLY SCHEMA  QASN;
SET CAPTURE SCHEMA SOURCE  QASN;
SET OUTPUT CAPTURE SCRIPT "capsub.sql";
SET OUTPUT TARGET SCRIPT "appsub.sql";
SET RUN SCRIPT NOW STOP ON SQL ERROR ON;
#SET RUN SCRIPT LATER ;

CREATE QSUB USING REPLQMAP BENCHT_TO_BENCH
(SRC OWNER LIKE "RDSDB" SRC NAME LIKE "%"
 OPTIONS HAS LOAD PHASE N REPLICATE ADD COLUMN YES
 EXIST TARGET TABLE OWNER SAME AS SOURCE TABLE NAME SAME AS SOURCE
 TRGCOLS ALL
 CONFLICT ACTION F ERROR ACTION S
 
);

このブログで説明している手順は、ソース Db2 インスタンスのバージョン 11.5FP8 以降であることを前提としています。このバージョンでは、タイムス・タンプを使用し、後からキャプチャプログラムを再起動できるため、手順が大幅に簡略化されます。ソース Db2 が下位バージョンの場合、サブスクリプションを次のように定義します。サブスクリプションに OKSQLSTATE を指定することで、データ移行後に追いつきながらレプリケーションの例外をマスクします。

CREATE QSUB USING REPLQMAP BENCHT_TO_BENCH
(SRC OWNER LIKE "RDSDB" SRC NAME LIKE "%"
 OPTIONS HAS LOAD PHASE N REPLICATE ADD COLUMN YES
 EXIST TARGET TABLE OWNER SAME AS SOURCE TABLE NAME SAME AS SOURCE
 TRGCOLS ALL
 CONFLICT ACTION F ERROR ACTION S
 OKSQLSTATE "02000"  
);

レプリケーションを開始しサブスクリプションを有効化

キャプチャーおよびアプライ・プログラムを開始して、全てのサブスクリプションが正常にアクティブ化できることを確認します。v11.5FP8 より前のバージョンでは、これによりソースDb2 ログを読み取るためのリスタート・ポイントも設定されます。

asnqcap capture_server=BENCHS capture_schema=QASN startmode=warmsi &
asnqccmd capture_server=BENCHS capture_schema=QASN stop

asnqapp apply_server=BENCHT apply_schema=QASN apply_path="/home/db2rep/REPL" &
asnqacmd apply_server=BENCHT apply_schema=QASN stop

次の SQL クエリを実行すると、サブスクリプションの状態を確認できます。

connect to BENCHT;
select
      substr(subname,1,8)as subname,
      substr(recvq,1,10) as recvq,
      substr(target_owner,1,8) as owner,
      substr(target_name,1,20) as tablename,
      has_loadphase,
      STATE
from qasn.ibmqrep_targets;

RDR for Db2 環境のセットアップ

RDS for Db2 クラスターを作成及び、設定する手順については、こちらを参照してください。Q レプリケーション・インスタンスが RDS for Db2 クラスターと同じサブネットにあることを確認してください。

Db2MT を使用したデータ移行

全てのデータの移行を開始する前に、処理中の全てのトランザクションがコミットされる時間を把握する必要があります。これは、データ移行中に発生した変更を Db2 リカバリー・ログからキャプチャし、全ての変更がデータ移行に含まれるか、ログから読み取れることを保証する必要があるためです。

まだコミットされていない最も早いトランザクションの開始時間を取得するには、次のクエリを実行して実行中のトランザクションを全て確認します。クエリが空の場合、現在コミットされていないトランザクションはなく、クエリを実行した現在の時間で十分です。

SELECT
con.application_handle,
con.application_id,
con.application_name,
con.client_pid,
uow.uow_start_time,
uow.uow_log_space_used
FROM
table(mon_get_connection(cast(null as bigint), -1)) as con,
table(mon_get_unit_of_work(null, -1)) as uow
WHERE
con.application_handle = uow.application_handle and
uow.uow_log_space_used != 0
ORDER BY uow.uow_start_time  

オープンソースの Db2MT は、Db2 データベースを使用したデータ移行を簡素化します。Go で書かれた Db2MT は、生成するスクリプトをカスタマイズするための拡張可能なアーキテクチャを備えています。これらのスクリプトを使用すると、実行前に移行プロセスを検証できます。

Db2 のバックアップは通常、同じプラットフォーム・ファミリー内でのみ復元できます。ただし、Linux と UNIX では、バックアップ先と復元先のエンディアンが一致していれば、以前のバージョンからバックアップを復元できます。そうしないと、DDL、データをエクスポートしたり、ターゲット・データベースでオブジェクトを再作成したりする複雑なプロセスが必要になります。

Db2MT を使用すると、この移行プロセス全体が簡素化されます。Db2MT は、ソース・データベースからエクスポートしてターゲットにインポートするために必要なスクリプトを生成し、オブジェクトの再作成とデータロードを処理します。これにより、Db2 データベースの移行が簡単かつ効率的になります。

Db2MT を使用しAIX ソース・データベースから RDS for Db2 へデータを移行

AWS に直接接続している場合、Db2MT は AIX/Windows サーバーまたは Db2 クライアントに直接インストールできます。Db2MT は、ネイティブの db2look を使用して忠実度の高いメタ・データを取得し、複数のパスとチャンク・アップロードを使用して Db2 サーバーから Amazon Simple Storage Service（Amazon S3）にデータを直接アンロードするための並列パスを構築します。Db2MT は GO SDK を使用してデータを直接 Amazon S3 にアップロードします。これは、AIX には AWS Command Line Interface (AWS CLI) がないためです。Db2MT は IXF 形式を使用して最大限のデータ正確性を維持し、クライアント・マシンのコード・ページの影響を受けずにデータを転送します。

Db2MT を使用し Linux ソース・データベースから RDS for Db2 へデータを移行

Db2MT は、データベースのサイズに応じて複数のパスを使用して、オフラインおよびオンラインのデータベース・バックアップを Db2 クライアントから Amazon S3 に直接作成します。Amazon RDS for Db2 に接続している同じまたは別の Db2 クライアントは、RDS for Db2 ストアード・プロシージャー RDSADMIN_RESTORE を実行して、Amazon S3 からオフラインまたはオンラインのデータベース・バックアップを復元できます。オプションで、オンライン・バックアップのアーカイブ・ログを適用して変更を同期できます。

レプリケーションを再開し移行中の全ての変更をキャプチャ

Db2MT を使用したデータ・ロードが完了したら、Q レプリケーションを再起動して、変更のバック・ログをターゲット・データベース (Amazon RDS for Db2) に適用できます。

必ず、データ移行が開始される前に キャプチャー・プログラムを再起動し、Db2MT の起動時にまだコミットされていない (処理中の) トランザクションを全てキャプチャできるように、リカバリー・ログに戻ってください。Db2 V11.5FP8 以降では、以前に取得したタイムス・タンプを Q キャプチャーに提供できます。Q キャプチャーは、このタイム・スタンプを LSN にマッピングし、そこからログ・レコードの読み取りを開始します。以前のバージョンでは、LSN パラメータには LSN が必要でしたが、取得が難しい場合があります。V11FP8 より前のバージョンでは、再起動 LSN を提供する代わりに、サブスクリプションに OKSQLSTATES を設定して例外を無視するようにしました。ただし、移行が完了した後もレプリケーションを引き続き使用する場合は、サブスクリプションを変更してこのオプションを削除する必要があります。そうしないと、レプリケーションの例外を検出できません。

キャプチャーを LSN パラメーター（タイム・スタンプまたは実際の LSN のいずれか）で再起動すると、最後に停止した場所からの再起動（ウォーム・スタートとも呼ばれます）ではなく、ターゲット・データベースの一貫性を回復するために変更が適用され、競合が解消されます。このキャッチアップ期間中は、ソース・アプリケーションがまだ実行されている間にデータの読み取りとコピーが行われていたため、データの不一致が起こることが予想されます。このキャッチアップ期間中は、例外は報告されません。キャプチャ開始時刻までに全ての変更が複製されると、通常の処理が再開され、データ不一致の例外が報告されます。

例えば、Db2MT を 10:22 に起動し、まだコミットされていない最長のトランザクションが 10 分前に開始された場合は、キャプチャーを再起動して 10:12 からログを読み取ることができます。

asnqcap capture_server=BENCHS capture_schema=QASN LSN=2023-11-03-10.12.01.000001MAXCMTSEQ=0 &

asnqapp apply_server=BENCHT apply_schema=QASN apply_path="/home/db2rep/REPL" &

監視テーブルからクエリを実行することで、レプリケーション・プロセスの進行状況を追跡できます。

db2 connect to BENCHT;
db2 "select MONITOR_TIME, 
END2END_LATENCY, 
ROWS_APPLIED,
OLDEST_TRANS
from QASN.IBMQREP_APPLYMON 
order by MONITOR_TIME DESC 
fetch first 20 rows only with ur"