3 データベース移行の準備

次のトピックでは、データベースの移行の準備方法について説明します。

3.1 Zero Downtime Migrationソフトウェアの設定

要件 説明 コメント
Zero Downtime Migrationソフトウェアの設定
  1. 既存のユーザーを使用するか、Zero Downtime Migrationサービス・ホストでrootユーザーとして、zdmグループを作成し、zdmuserユーザーをグループに追加します。

    次に例を示します。

    root> groupadd zdm

    root> useradd –g zdm zdmuser

    非rootユーザーを使用してZero Downtime Migrationを設定できることに注意してください。このドキュメントの例では、すべてのコマンドがzdmuserとして実行されています。

  2. Zero Downtime Migrationソフトウェア・キットをhttps://www.oracle.com/database/technologies/rac/zdm-downloads.htmlからZero Downtime Migrationサービスのホストにダウンロードします。
  3. 必須パッケージの場合は、ダウンロードのREADMEを参照して、インストールします。
  4. ディレクトリをZero Downtime Migrationソフトウェアのダウンロード先に変更します。

    zdmuser> cd zdm_download_directory

    Zero Downtime Migrationのインストール・スクリプトを実行します。

    zdmuser>./zdminstall.sh setup oraclehome=zdm_oracle_home oraclebase=zdm_base_directory ziploc=zdm_software_location –zdm

    zmdinstall.shは、インストール・スクリプトです。

    oraclehomeは、Zero Downtime MigrationキットがインストールされているOracle Homeです。

    oraclebaseは、すべてのZero Downtime Migrationの構成ファイル、ログおよびその他のアーティファクトが格納されるベース・ディレクトリです。

    ziplocは、Zero Downtime Migrationキットに含まれる圧縮ソフトウェア・ファイル(ZIP)の場所です。

    次に例を示します。

    zdmuser>./zdminstall.sh setup oraclehome=/u01/app/zdmhome

    oraclebase=/u01/app/zdmbase ziploc=/u01/app/oracle/zdm/shiphome/zdm_home.zip -zdm

    今後、oraclehome値はZDM_HOMEと呼び、oraclebase値はZDM_BASEと呼びます。

  5. Zero Downtime Migrationサービスをユーザーzdmuserとして開始します。

    zdmuser> /u01/app/zdmhome/bin/zdmservice start

    Zero Downtime Migrationを使用してデータベースを移行するには、zdmserviceを開始する必要があります。

  6. Zero Downtime Migrationサービスを停止するには、次のコマンドを実行します。

    zdmuser> /u01/app/zdmhome/bin/zdmservice stop

  7. Zero Downtime Migrationサービスのインストールが正常に終了したことを確認します。

    次のコマンドを実行すると、出力は次に示すようなものになります。

    zdmuser> /u01/app/zdmhome/bin/zdmservice status

    ---------------------------------------

    Service Status

    ---------------------------------------

    Running: true

    Tranferport: 5000-7000

    Conn String: jdbc:derby:/u01/app/zdmbase/derbyRepo;create=true

    Repo Path: /u01/app/zdmbase/derbyRepo

    RMI port: 8895

    HTTP port: 8896

    Wallet path: /u01/app/zdmbase/crsdata/fopds/security

インストールの最後に端末に表示される次のメッセージは無視します。これらのスクリプトを実行する必要はありません。

rootユーザーとして、次のスクリプトを実行します。

  1. /u01/app/zdmhome/inventory/orainstRoot.sh
  2. /u01/app/zdmhome/root.sh"

3.2 Zero Downtime Migrationサービス・ホストからソースおよびターゲットのデータベース・サーバーへの接続の構成

要件 説明 コメント
Zero Downtime Migrationサービスのホストからソースおよびターゲットのデータベース・サーバーへの接続の構成
  1. Zero Downtime Migrationサービス・ホストで、Zero Downtime Migrationソフトウェア・インストール・ユーザーに認証鍵ペアがパスフレーズなしで使用できることを確認します。

    新しい鍵ペアをパスフレーズなしで生成する必要がある場合は、Zero Downtime Migrationソフトウェア・インストール・ユーザーとして、パスフレーズなしの秘密SSH鍵の生成の説明に従って新しい鍵ペアを生成します。

  2. 秘密鍵ファイルの名前を変更します。

    ZDM_installed_user_home/.ssh/id_rsaファイルの名前をZDM_installed_user_home/.ssh/ZDM_service_host_name.ppkに変更します。

  3. ZDM_installed_user_home/.ssh/id_rsa.pubファイルの内容を、ソースおよびターゲットのすべてのデータベース・サーバー上のopc_user_home/.ssh/authorized_keysファイルに追加します。

    opcユーザーは、Oracle Cloud Infrastructure ClassicおよびExadata Cloud Serviceデータベース・サーバーへのアクセスに使用される標準のOracle Cloudユーザーであることに注意してください。

  4. ソースおよびターゲットのデータベース・サーバー名およびIPアドレスの詳細をZero Downtime Migrationサービスのホスト/etc/hostsファイルに追加します。

    次に例を示します。

    #OCI-C public IP of two node RAC server details

    192.0.2.1 zdm122011

    192.0.2.2 zdm122012

    #OCI public IP of two node RAC server details

    192.0.2.3 ocitarget1

    192.0.2.4 ocitarget2

  5. ソースおよびターゲットのデータベース・サーバーのポート22がZero Downtime Migrationサービス・ホストからの着信接続要求を受け入れることを確認します。
  6. Zero Downtime Migrationサービス・ホストからすべてのソースおよびターゲットのデータベース・サーバーへの接続をテストします。

    zdmuser> ssh -i ZDM_service_node_private_key_file_location user@source/target_database_server_name

    次に例を示します。

    zdmuser> ssh -i /home/zdmuser/.ssh/zdm_service_node.ppk opc@zdm122011

    zdmuser> ssh -i /home/zdmuser/.ssh/zdm_service_node.ppk opc@zdm122012

    zdmuser> ssh -i /home/zdmuser/.ssh/zdm_service_node.ppk opc@ocitarget1

    zdmuser> ssh -i /home/zdmuser/.ssh/zdm_service_node.ppk opc@ocitarget2

注意1: ソース・データベース・サーバーへのルート・アクセス権がある場合、ソース・データベース・サーバーに対してSSH鍵を介した接続を構成する必要はありません。

注意2: SSH鍵を介した接続を構成する場合、Zero Downtime Migrationサービスのホストは、パスワードの入力を求めずに、秘密鍵ファイルを使用してソースおよびターゲットのデータベース・サーバーに接続できる必要があります。

注意3: Zero Downtime Migrationサービスのホストが、ターゲット・サーバーに接続するためにプロキシ詳細を必要とする場合は、SSH鍵とともにZDM_installed_user_home/.ssh/configを次の詳細を指定して構成する必要もあります。それ以外の場合、ZDM_installed_user_home/.ssh/configファイルの構成は必要ありません。

cat ZDM_installed_user_home/.ssh/config

Host *

ServerAliveInterval 10

ServerAliveCountMax 2

Host Target_server_name

HostName Target_server_IP_address

IdentityFile Private_key_file_location

User Target_user_login

ProxyCommand /usr/bin/nc --proxy proxy_url:port %h %p

次に例を示します。

Host *

ServerAliveInterval 10

ServerAliveCountMax 2

Host ocitarget1

HostName 192.0.2.3

IdentityFile /home/zdmuser/.ssh/zdm_service_host.ppk

User opc

ProxyCommand /usr/bin/nc --proxy www-proxy-example.com:80 %h %p

注意4: authorized_keysファイル権限は次のようになります。

/home/opc/.ssh>ls -l authorized_keys

-rw------- 1 opc opc 1679 Oct 16 10:05 authorized_keys

3.3 ソース・データベース・サーバーとターゲット・データベース・サーバー間の接続の構成

要件 説明 コメント
ソース・データベース・サーバーとターゲット・データベース・サーバー間の接続の構成

2つのオプションのいずれかを使用して、ソース・データベース・サーバーとターゲット・データベース・サーバー間の接続を構成できます。

オプション1

ZDMCLIコマンドの-sourcenodeパラメータに指定したソース・データベース・サーバーは、ターゲットSCAN上のターゲット・データベース・インスタンスにそれぞれのSCANポートを介して接続できます。逆も同様です。ターゲットのSCANはソース・データベース・サーバーから解決可能である必要があり、ソースのSCANはターゲット・サーバーから解決される必要があります。

両側から接続できると、どちらの側からでもソース・データベースとターゲット・データベース間で同期をとることができます。ソース・データベース・サーバーのSCANがターゲット・データベース・サーバーから解決できない場合は、レスポンス・ファイルでSKIP_FALLBACKパラメータをTRUEに設定する必要があり、ターゲット・データベースとソース・データベース間で同期をとることができません。

オプション1の接続をテストするには、次のようにします。

  1. ソースからターゲット環境への接続をテストします。

    ターゲット・データベースのTNSエントリをソース・データベース・サーバーのtnsnames.oraファイルに追加します。

    [oracle@zdm122011 ~]tnsping target-tns-string

  2. ターゲットからソース環境への接続をテストします。

    ソース・データベースのTNSエントリをターゲット・データベース・サーバーのtnsnames.oraファイルに追加します。

    [oracle@exacstarget1~] tnsping source-tns-string

オプション2

ソース・データベース・サーバーとターゲット・データベース・サーバー間でSCANおよびSCANポートを使用した接続ができない場合は、次の手順に従ってソース・データベース・サーバーからターゲット・データベース・サーバーへのSSHトンネルを設定します。このオプションを使用すると、ターゲット・データベースとソース・データベース間で同期をとることができません。

rootユーザーに対してソース・データベース・サーバーでSSHトンネルを設定するには、次のようにします。

  1. ターゲット・サーバー上のopcユーザーのパスフレーズなしの秘密SSH鍵ファイルを生成します。

    パスフレーズなしの秘密SSH鍵の生成を参照してください。

    ターゲットがOracle RACデータベースである場合は、最初のOracle RACサーバーからパスフレーズなしで秘密SSH鍵ファイルを生成します。

  2. ターゲット・サーバーのopc_user_home/.ssh/id_rsa.pubファイルの内容をソース・サーバーのopc_user_home/.ssh/authorized_keysファイルに追加します。

    ソースがOracle RACデータベースの場合は、すべてのOracle RACソース・サーバーのopc_user_home/.ssh/authorized_keysファイルにターゲット・サーバーのopc_user_home/.ssh/id_rsa.pubファイルの内容を追加します。

  3. ターゲット・サーバーの秘密SSH鍵ファイルを/root/.ssh/ディレクトリのソース・サーバーにコピーします。

    ソースがOracle RACデータベースである場合は、ファイルをすべてのソース・サーバーにコピーします。管理しやすくするために、秘密SSH鍵ファイルの名前はターゲット・サーバー名と同じままにし、.ppk拡張子を付けたままにしておきます。たとえば、exacstarget1.ppkとなります(exacstarget1がターゲット・サーバーの名前です)。

    ファイルの権限は次のようになります。

    /root/.ssh>ls -l exacstarget1t.ppk

    -rw------- 1 root root 1679 Oct 16 10:05 exacstarget1.ppk

  4. ソース・サーバーの/root/.ssh/configファイルに次のエントリを挿入します。

    Host *

    ServerAliveInterval 10

    ServerAliveCountMax 2

    Host Target_server_name

    HostName Target_server_IP_address

    IdentityFile Private_key_file_location

    User Target_user_login

    Target_server_nameは、ドメイン名なしのターゲット・データベース・サーバー名です。Oracle RACデータベースの場合は、ドメイン名なしの最初のOracle RACサーバー名を使用します。

    Target_server_IP_addressは、ターゲット・データベース・サーバーのIPアドレスです。Oracle RACデータベースの場合は、最初のOracle RACサーバーのIPアドレスを使用します。

    Private_key_file_locationは、秘密キー・ファイルの場所です。

    Target_user_loginは、ターゲット・データベース・サーバーへのアクセスに使用されるOSユーザーです。

    たとえば、関連する値を指定した後の/root/.ssh/configファイルの内容は次のようになります。

    Host *

    ServerAliveInterval 10

    ServerAliveCountMax 2

    Host exacstarget1

    HostName 192.0.2.3

    IdentityFile ~/.ssh/exacstarget1.ppk

    User opc

    ファイルの権限は次のようになります。

    /root/.ssh>ls -l config

    -rw------- 1 root root 1679 Oct 16 10:05 config

    前述の例では、ターゲット・サーバー名はexacstarget 1で、ターゲット・サーバーのパブリックIPアドレスは192.0.2.3です。

    ソースがOracle RACデータベースである場合は、同じ/root/.ssh/configファイルをすべてのソースOracle RACデータベース・サーバーにコピーします。

    SSHトンネルを有効にする前に、ソース・サーバーから最初のターゲット・サーバーにSSHできることを確認します。

    Oracle RACデータベースの場合は、すべてのソース・サーバーから最初のターゲット・サーバーへの接続をテストします。

    秘密キー・ファイルを使用して接続をテストし、ソース・データベース・サーバーがパスワードを要求されることなくターゲット・データベース・サーバーに接続できることを確認します。

    [root@zdm122011 ~] ssh -i /root/.ssh/exacstarget1.ppk opc@exacstarget1

    [root@zdm122012 ~] ssh -i /root/.ssh/exacstarget1.ppk opc@exacstarget1

  5. ソース・サーバーで次のコマンドを実行してSSHトンネルを有効にします。

    ssh -f Target_hostname_without_domain_name -L \ ssh_tunnel_port_number:Target_server_IP_address: Target_server_listener_port -N

    Target_hostname_without_domain_nameは、ドメイン名なしのターゲット・データベース・サーバー名です。Oracle RACデータベースの場合は、ドメイン名なしの最初のOracle RACサーバー名を使用します。

    ssh_tunnel_port_numberは、(1024-65545)の範囲で使用可能なエフェメラル・ポートです。SSHトンネル・ポートは、サーバーの他のプロセスで使用されていないことを確認してから使用します。

    Target_server_listener_portは、ターゲット・データベースのリスナー・ポート番号です。リスナー・ポートは、ソース・データベース・サーバーとターゲット・サーバー間で開いている必要があります。

    Target_server_IP_addressは、データベース・アーキテクチャに基づいて構成されています。シングル・インスタンス・データベースの場合は、ターゲット・サーバーのIPアドレスを指定します。Oracle RACデータベースの場合は、ターゲットのSCAN名をドメイン名付きで指定します。

    ドメイン名付きのSCAN名が解決できない場合や機能しない場合は、ターゲット・サーバーからLSNRCTL STATUSコマンド出力を使用して取得したIPアドレスを指定します。次に例を示します。

    Listening Endpoints Summary...

    (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=LISTENER)))

    (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.0.2.9)(PORT=1521)))

    (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.0.2.10)(PORT=1521)))

    次に、SSHトンネルを有効にするために実行するコマンドの例を示します。

    [root@zdm122011 ~]ssh -f exacstarget1 -L 9001:192.0.2.9:1521 -N

    Oracle RACデータベースの場合は、すべてのソース・サーバーについてこのステップを繰り返す必要があります。

  6. オプション2のSSHトンネルを使用して接続をテストします。

    Oracle RACの場合は、すべてのソース・サーバーについてこのステップを繰り返す必要があります。

    ソース・サーバーにログインし、oracleユーザーに切り替えてデータベース環境をソースとして参照し、次のコマンドを実行します。

    tnsping localhost:ssh_tunnel_port

    次に例を示します。

    [oracle@zdm122011 ~] tnsping localhost:9001

    コマンド出力は、次のようになります。

    TNS Ping Utility for Linux: Version 12.1.0.2.0 - Production on 22-JAN-2019 05:41:57

    Copyright (c) 1997, 2014, Oracle. All rights reserved.

    Used parameter files:

    Used HOSTNAME adapter to resolve the alias

    Attempting to contact(DESCRIPTION=(CONNECT_DATA= (SERVICE_NAME=))(ADDRESS=(PROTOCOL=TCP) (HOST=127.0.0.1)(PORT=9001)))

    OK (50 msec)

    tnspingが機能しない場合、SSHが有効になっていません。

パスワードを要求せずにソース・データベース・サーバーがターゲット・データベース・サーバーに接続できることを確認します。そうでない場合、ソースからターゲット側へのData Guard同期が発生しません。

3.4 レスポンス・ファイル・テンプレートの準備

移行をオンラインで実行するかオフラインで実行するかに従って、レスポンス・ファイルのテンプレートを準備します。

3.4.1 オンライン移行のためのレスポンス・ファイルの準備

要件 説明 コメント
オンライン移行のためのレスポンス・ファイルの準備

レスポンス・ファイル・テンプレートを$ZDM_HOME/rhp/zdm/template/zdm_template.rspから取得し、次の設定を編集します。

  • TGT_DB_UNIQUE_NAMEをターゲット・データベースのdb_unique_name値に設定します。
  • MIGRATION_METHODDG_OSSにします。ここで、DGはData Guardを表し、OSSはObject Storageサービスを表します。
  • PLATFORM_TYPEVMDBに設定します。
  • Zero Downtime Migrationサービス・ホストからソース・データベース・サーバーへのアクセスにSSHプロキシが必要な場合は、SRC_HTTP_PROXY_URLおよびSRC_HTTP_PROXY_PORTを設定します。
  • Zero Downtime Migrationサービス・ホストからターゲット・データベース・サーバーへのアクセスにSSHプロキシが必要な場合は、TGT_HTTP_PROXY_URLおよびTGT_HTTP_PROXY_PORTを設定します。
  • SSHトンネリングを設定した場合は、TGT_SSH_TUNNEL_PORTパラメータを設定します。
  • ターゲット・データベースのデータ・ファイル・ストレージ(ASMまたはACFS)のプロパティを適宜(TGT_DATADGTGT_REDODGおよびTGT_RECODG)または(TGT_DATAACFSTGT_REDOACFSおよびTGT_RECOACFS)と指定します。
  • HOSTおよびOPC_CONTAINERにオブジェクト・ストアURLおよびバケット名を設定します。
  • 任意でまたはターゲットとソース間の接続がないために、REDOログをターゲットからソース・スタンバイに移さない場合は、SKIP_FALLBACK=TRUEを設定します。
  • データベースの移行後にソース・データベースを停止する場合は、SHUTDOWN_SRC=TRUEを設定します。
  • SRC_RMAN_CHANNELSに、ソースで割り当てられてRMANバックアップの実行に使用されるRMANチャネルの数を設定します。デフォルトは10です。
  • TGT_RMAN_CHANNELSに、ターゲットで割り当てられてRMANリストアの実行に使用されるRMANチャネルの数を設定します。デフォルトは10です。
たとえば、次に示すように、レスポンス・ファイルを$ZDM_HOME/rhp/zdm/template/zdm_template_ZDM12201.rspにコピーして、ソースとターゲットに基づいて設定値を追加します。

TGT_DB_UNIQUE_NAME=ZDM12201_phx1xx

MIGRATION_METHOD=DG_OSS

PLATFORM_TYPE=VMDB

TGT_HTTP_PROXY_URL=www-proxy-example.com

TGT_HTTP_PROXY_PORT=80

TGT_SSH_TUNNEL_PORT=9001

TGT_DATADG=+DATA

TGT_REDODG=+RECO

TGT_RECODG=+RECO

HOST=https://swiftobjectstorage.us-phoenix-1.oraclecloud.com/v1/tenancyname

OPC_CONTAINER=DEMOZDM

SKIP_FALLBACK=TRUE

SHUTDOWN_SRC=TRUE

SRC_RMAN_CHANNELS=6

サンプル・レスポンス・ファイルは、/$ZDM_HOME/rhp/zdm/template/zdm_template.rspにあります。

3.4.2 オフライン移行(バックアップおよびリカバリ)のためのレスポンス・ファイルの準備

要件 説明 コメント
オフライン移行のためのレスポンス・ファイルの準備(バックアップとリカバリを使用)

レスポンス・ファイル・テンプレートを$ZDM_HOME/rhp/zdm/template/zdm_template.rspから取得し、次の設定を編集します。

  • TGT_DB_UNIQUE_NAMEをターゲット・データベースのdb_unique_name値に設定します。
  • ターゲット環境に応じて、PLATFORM_TYPEを適切な値に設定ます。
  • Oracle Cloud Infrastructureの場合は、PLATFORM_TYPE=VMDBを設定します。
  • MIGRATION_METHODBACKUP_RESTORE_OSSに設定します(OSSはObject Storageサービスを表します)。
  • ターゲット・データベースのデータ・ファイル・ストレージ(ASMまたはACFS)のプロパティを適宜指定します。ASMの場合は、TGT_DATADGTGT_REDODGおよびTGT_RECODGを設定します。ACFSの場合は、TGT_DATAACFSTGT_REDOACFSおよびTGT_RECOACFSを設定します。
  • Zero Downtime Migrationサービス・ホストからソース・データベース・サーバーへのアクセスにSSHプロキシが必要な場合は、SRC_HTTP_PROXY_URLおよびSRC_HTTP_PROXY_PORTを設定します。
  • Zero Downtime Migrationサービス・ホストからターゲット・データベース・サーバーへのアクセスにSSHプロキシが必要な場合は、TGT_HTTP_PROXY_URLおよびTGT_HTTP_PROXY_PORTを設定します。
  • HOSTおよびOPC_CONTAINERにオブジェクト・ストアURLおよびバケット名を設定します。
  • データベースの移行後にソース・データベースを停止する場合は、SHUTDOWN_SRC=TRUEを設定します。
  • SRC_RMAN_CHANNELSを、ソースで割り当てられてRMANバックアップの実行に使用されるRMANチャネルの数に設定します。デフォルトは10です。
  • TGT_RMAN_CHANNELSを、ターゲットで割り当てられてRMANリストアの実行に使用されるRMANチャネルの数に設定します。デフォルトは10です。

たとえば、次に示すように、レスポンス・ファイル・テンプレートを$ZDM_HOME/rhp/zdm/template/zdm_template_ZDM12201.rspにコピーして、ソースとターゲットに基づいて設定値を入力します。

TGT_DB_UNIQUE_NAME=ZDM12201_phx1xx

MIGRATION_METHOD=BACKUP_RESTORE_OSS

PLATFORM_TYPE=VMDB

TGT_HTTP_PROXY_URL=www-proxy-example.com

TGT_HTTP_PROXY_PORT=80

TGT_DATADG=+DATA

TGT_REDODG=+RECO

TGT_RECODG=+RECO

HOST=https://swiftobjectstorage.us-phoenix-1.oraclecloud.com/v1/tenancyname

OPC_CONTAINER=DEMOZDM

SHUTDOWN_SRC=TRUE

SRC_RMAN_CHANNELS=6

サンプル・レスポンス・ファイルは、$ZDM_HOME/rhp/zdm/template/zdm_template.rspにあります。

3.5 自動アプリケーション・スイッチオーバーの準備

要件 説明 コメント
自動アプリケーション・スイッチオーバーの準備 データベース移行およびスイッチオーバーの完了後にアプリケーションでのサービスの中断を最小限に抑えたり、なくすには、ソース・データベースからターゲット・データベースに接続を自動的に切り替えるようにアプリケーションを準備します。

次のサンプル接続文字列では、アプリケーションはソース・データベースに接続し、使用できない場合は、接続がターゲット・データベースに切り替わります。

(DESCRIPTION=(FAILOVER=on)(LOAD_BALANCE=on) (CONNECT_TIMEOUT=3)(RETRY_COUNT=3)(ADDRESS_LIST= (ADDRESS=(PROTOCOL=TCP)(HOST=source_database_scan) (PORT=1521))(ADDRESS=(PROTOCOL=TCP) (HOST=target_database_scan)(PORT=1521)))(CONNECT_DATA= (SERVICE_NAME=zdm_prod_svc)))

この例では、ソース・データベースで、zdm_prod_svcという名前のサービスを作成します。

srvctl add service -db clever -service zdm_prod_svc -role PRIMARY -notification TRUE -session_state dynamic -failovertype transaction -failovermethod basic -commit_outcome TRUE -failoverretry 30 -failoverdelay 10 -replay_init_time 900 -clbgoal SHORT -rlbgoal SERVICE_TIME -preferred clever1,clever2 -retention 3600 -verbose

3.6 移行ジョブのカスタマイズ

要件 説明 コメント
移行ジョブのカスタマイズ

移行ジョブに含まれる操作フェーズの一環として実行するために、アクション・スクリプトまたはアクション・プラグインをアクション前またはアクション後として登録すると、Zero Downtime Migrationワークフローをカスタマイズできます。

次の各トピックでは、移行ジョブをカスタマイズする方法について説明します。

アクション・プラグインの登録

カスタム・プラグインは、特定の操作フェーズのためのカスタマイズとしてプラグインするために、Zero Downtime Migrationサービス・ホストに登録する必要があります。

特定のプラグインを関連付ける必要がある操作フェーズを決定し、-optype MIGRATE_DATABASEと操作の各フェーズ、プラグインがそのフェーズと比較して-preまたは-postのどちらで実行されるか、エラー時の要件を指定して、ZDMCLIコマンドadd useractionを実行します。カスタム・プラグインは、移行ジョブ・ワークフローのZDM_SETUP_TGTの後の操作フェーズに登録できます。

ユーザー・アクションでエラーが発生した場合の実行時の処理は、-onerrorオプションを使用して指定でき、ABORT (処理を終了する場合)またはCONTINUE (カスタム・プラグインがエラー状態で存在する場合でも移行ジョブを続行する場合)のいずれかに設定できます。コマンドの使用例は次を参照してください。

Zero Downtime Migrationソフトウェアのインストール済ユーザー(たとえば、zmduser)を使用して、ユーザーアクションをデータベース移行ジョブに追加します。add useractionコマンドを使用したユーザー・アクションzdmvaltgtおよびzdmvalsrcの追加は、次のようになります。

zdmuser>$ZDM_HOME/bin/zdmcli add useraction -useraction zdmvaltgt -optype MIGRATE_DATABASE -phase ZDM_VALIDATE_TGT -pre -onerror ABORT -actionscript /home/zdmuser/useract.sh

zdmuser>$ZDM_HOME/bin/zdmcli add useraction -useraction zdmvalsrc -optype MIGRATE_DATABASE -phase ZDM_VALIDATE_SRC -pre -onerror CONTINUE -actionscript /home/zdmuser/useract1.sh

前述のコマンドでは、スクリプト/home/zdmuser/useract.shおよび/home/zdmuser/useract1.shがZero Downtime Migrationサービス・ホストのリポジトリにコピーされ、アクション・テンプレートを使用して実行される任意の移行ジョブに関連付けられている場合に実行されます。

アクション・テンプレートの作成

ユーザー・アクション・プラグインを登録した後、移行ジョブに関連付けることができる一連のアクション・プラグインをまとめたアクション・テンプレートを作成します。

アクション・テンプレートは、ZDMCLIコマンドadd imagetypeを使用して作成します(イメージ・タイプimagetypeは、特定のタイプのデータベース移行に必要なすべてのユーザー・アクションをまとめたものです)。

データベースの移行に必要なすべてのユーザー・アクション・プラグインを関連付けるイメージ・タイプを作成します。作成したイメージ・タイプは、同じプラグイン・セットを必要とするすべての移行操作で再利用できます。

ここで作成するイメージ・タイプの基本タイプは、次の例に示すようにCUSTOM_PLUGINである必要があります。

たとえば、前述の例で作成したユーザー・アクションzdmvalsrczdmvaltgtの両方をまとめたイメージ・タイプACTION_ZDMを作成できます。

zdmuser>$ZDM_HOME/bin/zdmcli add imagetype -imagetype ACTION_ZDM -basetype CUSTOM_PLUGIN -useractions zdmvalsrc,zdmvaltgt

アクション・プラグインの更新

Zero Downtime Migrationサービス・ホストに登録されたアクション・プラグインを更新できます。

次の例では、ユーザー・アクションzdmvalsrcを変更して-preアクションのかわりに、-postアクションにする方法を示します。

zdmuser>$ZDM_HOME/bin/zdmcli modify useraction -useraction zdmvalsrc -phase ZDM_VALIDATE_SRC -optype MIGRATE_DATABASE -post

この変更は、すべての関連するアクション・テンプレートに伝播されるため、アクション・テンプレートを更新する必要はありません。

移行ジョブとのアクション・テンプレートの関連付け

移行ジョブを実行する際、移行ジョブの一環として実行するプラグインを指定するイメージ・タイプを指定できます。

例として、前述の例(-imagetype ACTION_ZDM)で作成したアクション・テンプレートACTION_ZDMを指定して移行コマンドを実行すると、イメージ・タイプが組み込まれて移行ジョブ・ワークフローの一環としてuseract.shuseract1.shスクリプトが実行されます。

デフォルトでは、アクション・プラグインは、クラスタのすべてのノードの指定された操作フェーズで実行されます。移行コマンド・オプション-tgtarg2で指定されたアクセス資格証明が指定のターゲット・ノードに対して一意である場合、追加のauth引数を組み込んで、他のクラスタ・ノードへのアクセスに必要な認証資格証明を指定する必要があります。たとえば、-tgtarg2 nataddrfile:auth_file_with_node_and_identity_file_mappingと指定します。

node1およびnode2で構成される2クラスタ・ノード用の一般的なnataddrfileを次に示します。

node1:node1:identity_file_path_available_on_zdmservice_node

node2:node2:identity_file_path_available_on_zdmservice_node

なし