1. Zero Downtime Migrationを使用したOracle Cloudへの移行
  2. データベース移行の準備

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

Zero Downtime Migrationデータベース移行を開始する前に、接続の構成、データベースの準備、必要な移行ジョブのカスタマイズの構成を行います。

既知の問題、My Oracle Supportノートおよびランブックの最新情報は、Zero Downtime Migrationリリース・ノートを参照してください。

  • 接続の前提条件の構成
    Zero Downtime Migrationサービス・ホストとソースおよびターゲットのデータベース・サーバー間に接続を設定する必要があります。
  • 移行のためのデータベースの準備
    移行のためにソースおよびターゲットのデータベースを準備します。
  • 自動アプリケーション・スイッチオーバーの準備
    データベース移行およびスイッチオーバーの完了後にアプリケーションでのサービスの中断を最小限に抑えたり、なくすには、ソース・データベースからターゲット・データベースに接続を自動的に切り替えるようにアプリケーションを準備します。
  • 移行ジョブのカスタマイズ
    移行ジョブに含まれる操作フェーズの一環として実行するために、アクション・スクリプトまたはアクション・プラグインをアクション前またはアクション後として登録すると、Zero Downtime Migrationワークフローをカスタマイズできます。

接続の前提条件の構成

Zero Downtime Migrationサービス・ホストとソースおよびターゲットのデータベース・サーバー間に接続を設定する必要があります。

次の各トピックでは、移行ジョブを実行する前にZero Downtime Migration接続の前提条件を構成する方法について説明します。

親トピック: データベース移行の準備

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_node_name.ppkに変更します。
  3. 次の依存関係を用いて、ZDM_installed_user_home/.ssh/id_rsa.pubファイルの内容をopc_user_home/.ssh/authorized_keysファイルに追加します。
    • ソース・データベースがOracle Cloud Infrastructure Classic上にある場合は、ZDM_installed_user_home/.ssh/id_rsa.pubファイルの内容をすべてのソース・データベース・サーバー上にあるopc_user_home/.ssh/authorized_keysファイルに追加します。

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

    • ソース・データベース・サーバーにrootアクセス権がある場合、アクションは必要ありません。
    • ターゲット・データベースがOracle Cloud Infrastructure、Exadata Cloud at CustomerまたはExadata Cloud Service上にある場合は、ZDM_installed_user_home/.ssh/id_rsa.pubファイルの内容をすべてのターゲット・データベース・サーバー上にあるopc_user_home/.ssh/authorized_keysファイルに追加します。
  4. コマンドに指定するソースおよびターゲットのデータベース・サーバー名は、必ずZero Downtime Migrationサービス・ホストから名前の解決サーバーまたはご使用のITインフラストラクチャで承認されている代替方法で解決可能にします。
    ソースおよびターゲットのデータベース・サーバー名の解決方法の1つとして、ソースおよびターゲットのデータベース・サーバー名およびIPアドレスの詳細をZero Downtime Migrationサービス・ホストの/etc/hostsファイルに追加します。

    次に例を示します。

    #OCI public IP two node RAC server details
192.0.2.1 zdmhost1
192.0.2.2 zdmhost2
#OCIC public IP two node RAC server details
192.0.2.6 ocicdb1
192.0.2.7 ocicdb2
  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@zdmhost1
zdmuser> ssh -i /home/zdmuser/.ssh/zdm_service_node.ppk opc@ocicdb1

関連項目:

Zero Downtime Migrationのポートの要件

親トピック: 接続の前提条件の構成

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

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

オプション1

ZDMCLIコマンドの-sourcenodeパラメータで指定したソース・データベース・サーバーは、それぞれのSCANポートを使用してターゲットSCANを介してターゲット・データベース・インスタンスに接続でき、その逆も同様です。ターゲットのSCANはソース・データベース・サーバーから解決可能である必要があり、ソースのSCANはターゲット・サーバーから解決される必要があります。両側から接続できると、どちらの側からでもソース・データベースとターゲット・データベース間で同期をとることができます。ソース・データベース・サーバーのSCANがターゲット・データベース・サーバーから解決できない場合は、レスポンス・ファイルでSKIP_FALLBACKパラメータをTRUEに設定する必要があり、ターゲット・データベースとソース・データベース間で同期をとることができません。

オプション2

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

この手順は、一時チャネルと見なされるものを設定することになります。SSHトンネルを使用しないアクセスを設定することもできます。

ノート:

次の手順は、Oracle Cloud Infrastructureに言及していますが、Exadata Cloud at CustomerおよびExadata Cloud Serviceにも適用できます。
  1. rootユーザーに対して、SSHトンネルをソース・データベース・サーバーに設定します。
    1. ターゲットのOracle Cloud Infrastructureサーバーで、パスフレーズなしの秘密SSH鍵の生成の情報を使用して、パスフレーズなしの秘密SSH鍵ファイルをopcユーザー用に生成します。ターゲットがOracle RACデータベースである場合は、最初のOracle RACサーバーからパスフレーズなしで秘密SSH鍵ファイルを生成します。
    2. Oracle Cloud Infrastructureサーバーのopc_user_home/.ssh/id_rsa.pubファイルの内容をOracle Cloud Infrastructure server opc_user_home/.ssh/authorized_keysファイルに追加します。
    3. ターゲットのOracle Cloud Infrastructureサーバーの秘密SSH鍵ファイルをソース・サーバーの/root/.ssh/ディレクトリにコピーします。ソースがOracle RACデータベースである場合は、ファイルをすべてのソース・サーバーにコピーします。
      管理しやすくするために、秘密SSH鍵ファイルの名前はターゲット・サーバー名と同じままにし、.ppk拡張子を付けたままにしておきます。たとえば、rptest.ppk (rptestはターゲット・サーバー名)とします。

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

      /root/.ssh>ls -l rptest.ppk
-rw------- 1 root root 1679 Oct 16 10:05 rptest.ppk
    4. ソース・サーバーの/root/.ssh/configファイルに次のエントリを挿入します。
      Host *
  ServerAliveInterval 10  
  ServerAliveCountMax 2

Host OCI_server_name   
  HostName OCI_server_IP_address
  IdentityFile Private_key_file_location 
  User OCI_user_login  
  ProxyCommand /usr/bin/nc -X connect -x proxy_name:proxy_port %h %p

      説明

      • OCI_server_nameは、ドメイン名なしのOracle Cloud Infrastructureターゲット・データベース・サーバー名です。Oracle RACデータベースの場合は、ドメイン名なしの最初のOracle RACサーバー名を使用します。
      • OCI_server_IP_addressは、Oracle Cloud Infrastructureターゲット・データベース・サーバーのIPアドレスです。Oracle RACデータベースの場合は、最初のOracle RACサーバーのIPアドレスを使用します。
      • Private_key_file_locationは、秘密鍵ファイルの場所です。
      • OCI_user_loginは、ターゲット・データベース・サーバーへのアクセスに使用されるOSユーザーです。
      • proxy_nameは、プロキシ・サーバーのホスト名です。
      • proxy_portは、プロキシ・サーバーのポートです。

      プロキシ設定は、プロキシ・サーバーを接続に使用しない場合には不要になることもあります。たとえば、ソース・データベース・サーバーがOracle Cloud Infrastructure Classic上にある場合、ProxyCommandで始まる行を削除したり、コメントにすることができます。

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

      Host *
  ServerAliveInterval 10  
  ServerAliveCountMax 2

Host rptest
  HostName 192.0.2.9
  IdentityFile /root/.ssh/rptest.ppk
  User opc
  ProxyCommand /usr/bin/nc -X connect -x www-proxy.example.com:80 %h %p

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

      /root/.ssh>ls -l config
-rw------- 1 root root 1679 Oct 16 10:05 config

      前述の例では、Oracle Cloud Infrastructureサーバー名はrptestであり、Oracle Cloud InfrastructureサーバーのパブリックIPアドレスは192.0.2.9です。

      ソースがOracle Cloud Infrastructure Classicサーバーである場合、proxy_nameは必要ないため、ProxyCommandで始まる行を削除したり、コメントにすることができます。

      ソースがOracle RACデータベースである場合は、同じ/root/.ssh/configファイルをすべてのソースOracle RACデータベース・サーバーにコピーします。このファイルには、Oracle Cloud Infrastructureサーバー名、Oracle Cloud InfrastructureサーバーのパブリックIPアドレスおよび最初のOracle Cloud Infrastructure Oracle RACサーバーの秘密鍵ファイルの場所といった情報が構成されます。

    5. 最初のターゲットOracle Cloud Infrastructureサーバーにソース・サーバーからSSHできることを確認してから、SSHトンネルを有効にします。
      Oracle RACデータベースの場合は、すべてのソース・サーバーから最初のターゲットOracle Cloud Interfaceサーバーへの接続をテストします。

      秘密鍵を使用して、次のようにします。

      [root@ocic121 ~] ssh -i /root/.ssh/rptest.ppk opc@rptest
Last login: Fri Dec  7 14:53:09 2018 from 192.0.2.11

[opc@rptest ~]$
    6. ソース・サーバーで次のコマンドを実行してSSHトンネルを有効にします。
      ssh -f OCI_hostname_without_domain_name -L ssh_tunnel_port_number:OCI_server_IP_address:OCI_server_listener_port -N

      説明

      • OCI_hostname_without_domain_nameは、ドメイン名なしのOracle Cloud Infrastructureターゲット・データベース・サーバー名です。Oracle RACデータベースの場合は、ドメイン名なしの最初のOracle RACサーバー名を使用します。
      • ssh_tunnel_port_numberは、1024-65545の範囲の使用できる一時的なポートです。SSHトンネル・ポートは、サーバーの他のプロセスで使用されていないことを確認してから使用します。
      • OCI_server_listener_portはターゲット・データベースのリスナー・ポート番号です。リスナー・ポートは、ソース・データベース・サーバーとOracle Cloud Infrastructureターゲット・サーバー間でオープンされている必要があります。
      • OCI_server_IP_addressは、データベース・アーキテクチャに基づいて構成されています。シングル・インスタンス・データベースの場合は、Oracle Cloud InfrastructureサーバーのIPアドレスを指定します。Oracle RACデータベースの場合は、Oracle Cloud Infrastructureの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@ocic121~]ssh -f rptest -L 9000:192.0.2.9:1521 -N

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

    7. SSHトンネルをテストします。
      ソース・サーバーにログインし、oracleユーザーに切り替えてデータベース環境をソースとして参照し、次のコマンドを実行します。 
      tnsping localhost:ssh_tunnel_port

      次に例を示します。 

      [oracle@ocic121 ~] tnsping localhost:9000

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

      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=9000)))
OK (50 msec)

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

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

  2. ソースからターゲット環境への接続をテストします。
    ターゲット・データベースのTNSエントリをソース・データベース・サーバーの$ORACLE_HOME/network/admin/tnsnames.oraファイルに追加します。
    [oracle@sourcedb ~] tnsping target-tns-string
  3. ターゲットからソース環境への接続をテストします。
    ソース・データベースのTNSエントリをターゲット・データベース・サーバーの$ORACLE_HOME/network/admin/tnsnames.oraファイルに追加します。
    [oracle@targetdb ~] tnsping source-tns-string

    ノート:

    Zero Data Loss Recovery Applianceを使用してExadata Cloud at Customerにデータベースを移行するには、ターゲット・ホストからソース・データベースへの必須のSQL*Net接続が必要です。

    注意:

関連項目:

Zero Downtime Migrationのポートの要件

親トピック: 接続の前提条件の構成

パスフレーズなしの秘密SSH鍵の生成

Zero Downtime Migrationサービス・ホスト、ソース・データベース・サーバーまたはターゲット・データベース・サーバーで、Zero Downtime Migrationソフトウェア・インストール・ユーザーに認証鍵ペアがパスフレーズなしで使用できない場合は、次の手順に従って新しいSSH鍵を生成できます。

Zero Downtime Migrationの操作時のSSH接続では、Zero Downtime Migrationサービス・ホストとソースおよびターゲットのデータベース・サーバーの間と、ソース・データベース・サーバーとターゲット・データベース・サーバー間に、パスフレーズの入力を必要としない非対話型の直接アクセスが必要です。

注意:

次の手順に、ソフトウェア・インストール・ユーザー用に秘密SSH鍵を生成する例を示します。この手順は、opcユーザーにも使用できます。

Zero Downtime Migrationソフトウェア・インストール・ユーザーとして、次のコマンドをZero Downtime Migrationサービス・ホストで実行します。

zdmuser> ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/opc/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/opc/.ssh/id_rsa.
Your public key has been saved in /home/opc/.ssh/id_rsa.pub.
The key fingerprint is:
c7:ed:fa:2c:5b:bb:91:4b:73:93:c1:33:3f:23:3b:30 opc@rhost1
The key's randomart image is:
+--[ RSA 2048]----+
|                 |
|                 |
|                 |
|         . . .   |
|        S o . =  |
|         . E . * |
|            X.+o.|
|          .= Bo.o|
|          o+*o.  |
+-----------------+

このコマンドにより、id_rsaファイルおよびid_rsa.pubファイルがzdmuserホーム(/home/zdmuser/.sshなど)に生成されます。

Oracle Cloud Infrastructureコンソールを使用して公開鍵(/home/zdmuser/.ssh/id_rsa.pubなど)をソースおよびターゲットのデータベース・サーバーに追加することも、次に示すように、それらのサーバー上にあるauthorized_keysファイルに手動で追加することもできます。

次に示すように、Zero Downtime Migrationサービス・ホストの/home/zdmuser/.ssh/id_rsa.pubファイルの内容をOracle Cloud Infrastructureサーバーのopcユーザーの/home/opc/.ssh/authorized_keysファイルに追加します。

[opc@rptest.ssh]$ export PS1='$PWD>'
/home/opc/.ssh>ls
authorized_keys  authorized_keys.bkp  id_rsa  id_rsa.pub  known_hosts  zdmkey
/home/opc/.ssh>cat id_rsa.pub >> authorized_keys

秘密鍵を別のセキュアなファイルに保存し、ソースおよびターゲットのデータベース・サーバーへの接続に使用します。たとえば、権限を600に設定してzdm_service_node.ppkファイルを作成し、Zero Downtime Migrationサービス・ホストのソフトウェア・インストール・ユーザーのhome/.sshのファイルに秘密鍵ファイルを挿入し、ソースおよびターゲットのデータベース・サーバーに接続します。

親トピック: 接続の前提条件の構成

透過的データ暗号化ウォレットの設定

Oracle Database 12cリリース2以降では、ソース・データベースでTDEが有効になっていない場合、移行を開始する前に、TDEウォレットを構成する必要があります。Oracle Database 11gリリース2 (11.2.0.4)およびOracle Database 12cリリース1でのTDEの有効化は必要ありません。

ソースおよびターゲットのデータベースで透過的データ暗号化(TDE)が必須としてまだ構成されていない場合、次の手順に従って(TDE)ウォレットを設定します。TDEは有効になっている必要があり、ソースとターゲットの両方のデータベースのWALLETステータスはOPENに設定する必要があり、WALLET_TYPEはAUTOLOGINに設定する必要があります。
  1. $ORACLE_HOME/network/admin/sqlnet.oraファイルにENCRYPTION_WALLET_LOCATIONを設定します。
    $ cat /u01/app/oracle/product/12.2.0.1/dbhome_2/network/admin/sqlnet.ora 

ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)
  (METHOD_DATA=(DIRECTORY=/u01/app/oracle/product/12.2.0.1/dbhome_2/network/admin/)))
  2. データベースに接続してキーストアを構成します。
    $ sqlplus "/as sysdba"
SQL> ADMINISTER KEY MANAGEMENT CREATE KEYSTORE '/u01/app/oracle/product/12.2.0.1/dbhome_2/network/admin'
 identified by **********;
keystore altered.

    非CDB環境の場合は、次のコマンドを実行します。

    SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY **********;
keystore altered.

    CDB環境の場合は、次のコマンドを実行します。

    SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY ********** container = ALL;

    非CDB環境の場合は、次のコマンドを実行します。

    SQL> ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY ********** with backup;
keystore altered.

    CDB環境の場合は、次のコマンドを実行します。

    SQL> ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY ********** with backup container = ALL;

    次に、次のとおり実行します。

    
SQL> select * FROM v$encryption_keys;
  3. 自動ログインを設定します。
    SQL> SELECT * FROM v$encryption_wallet;

WRL_TYPE	WRL_PARAMETER
--------------------	--------------------------------------------------------------------------------
STATUS                         WALLET_TYPE          WALLET_OR FULLY_BAC	CON_ID
------------------------------ -------------------- --------- ---------			----------
FILE		/u01/app/oracle/product/12.2.0.1/dbhome_2/network/admin/
OPEN                           PASSWORD             SINGLE    NO         0

SQL> ADMINISTER KEY MANAGEMENT CREATE AUTO_LOGIN KEYSTORE FROM KEYSTORE
 '/u01/app/oracle/product/12.2.0.1/dbhome_2/network/admin/' IDENTIFIED BY **********;
keystore altered.

    Oracle RACデータベースを使用している場合は、各クラスタ・ノードの同じ場所の下または共有ファイル・システムにファイルをコピーします。

    /u01/app/oracle/product/12.2.0.1/dbhome_2/network/admin/ew* 
/u01/app/oracle/product/12.2.0.1/dbhome_2/network/admin/cw*   

SQL> SELECT * FROM v$encryption_wallet;
WRL_TYPE	WRL_PARAMETER
--------------------	--------------------------------------------------------------------------------
STATUS                         WALLET_TYPE          WALLET_OR FULLY_BAC	    CON_ID
------------------------------ -------------------- --------- ---------			----------
FILE		/u01/app/oracle/product/12.2.0.1/dbhome_2/network/admin/
OPEN                           PASSWORD             SINGLE    NO	         	0

    この段階で、PASSWORDベースのウォレットが有効になっています。AUTOLOGINベースのウォレットを有効にするには、この手順の残りのステップを完了します。

    パスワード・ウォレットを閉じます。

    SQL> administer key management set keystore close identified by **********;
keystore altered.

    次に、autologinが構成されていることを確認します。TDE WALLETステータスをOPENに、WALLET_TYPEをAUTOLOGINに設定します。そうしないと、ウォレット構成が正しく設定されません。 

    $ sqlplus "/as sysdba"
SQL> SELECT * FROM v$encryption_wallet;
WRL_TYPE WRL_PARAMETER
-------------------- --------------------------------------------------------------------------------
STATUS WALLET_TYPE WALLET_OR FULLY_BAC CON_ID
------------------------------ -------------------- --------- --------- ---------
FILE /u01/app/oracle/product/12.2.0.1/dbhome_2/network/admin/
OPEN AUTOLOGIN SINGLE NO

Oracle DatabaseをOracle Cloudに移行する際、Oracle Cloud内のOracleデータベースではTDEがデフォルトで有効になっていることに留意してください。Zero Downtime Migrationでは、ソースOracle DatabaseでTDEがデフォルトで有効になっている場合でも、ターゲット・データベースの暗号化を処理します。ただし、移行のスイッチオーバー・フェーズが発生すると、Oracle Cloud内の新しいプライマリ・データベースがオンプレミスの新しいスタンバイ・データベースに送信するREDOログは暗号化されます。したがって、オンプレミス・データベースを再度プライマリにし、Oracle Cloud内のデータベースをスタンバイにして再度切り替えてロールをスワップすることにした場合、オンプレミス・データベースでは、TDEがオンプレミスで有効になっていないかぎり、REDOログによって適用された新しく暗号化された変更済のブロックを読み取ることができません。元のスイッチオーバーを移行プロセスの一環として実行する前に、移行後の不一致を避けるために、適切なテストおよび検証を実行することをベスト・プラクティスとしてお薦めします。スナップショット・スタンバイ・データベースでのテストにはZero Downtime Migration以外のオプションがあり、続行する準備ができたら、スナップショット・スタンバイ・データベースを削除し、スイッチオーバーの実行および移行プロセスの完了をZero Downtime Migrationに指示します。

親トピック: 接続の前提条件の構成

移行のためのデータベースの準備

移行のためにソースおよびターゲットのデータベースを準備します。

移行のためにソースおよびターゲットのデータベースを準備する方法の詳細は、次の各トピックを参照してください。

親トピック: データベース移行の準備

ソース・データベースの前提条件

Zero Downtime Migrationプロセスを開始する前に、ソース・データベースで前提条件を満たします。

  1. ソース・データベースはアーカイブ・ログ・モードで稼働している必要があります。
  2. Oracle Database 12cリリース2以降では、ソース・データベースで透過的データ暗号化(TDE)が有効になっていない場合、移行を開始する前にTDEウォレットを構成する必要があります。WALLET_TYPEは、AUTOLOGIN (優先)またはPASSWORDベースのいずれかです。
  3. ウォレットのSTATUSがOPENであり、WALLET_TYPEがAUTOLOGIN (AUTOLOGINウォレット・タイプの場合)またはWALLET_TYPEがPASSWORD (PASSWORDベースのウォレット・タイプの場合)であることを確認します。マルチテナント・データーベースの場合は、すべてのPDBおよびCDBでウォレットがオープンされており、マスター鍵がすべてのPDBおよびCDBに設定されていることを確認します。
    SQL> SELECT * FROM v$encryption_wallet;
  4. ソースがOracle RACデータベースで、SNAPSHOT CONTROLFILEが共有の場所にない場合、Oracle Object Storeへのバックアップ中にORA-00245エラーが発生しないように、すべてのOracle RACノード上にある共有の場所を指すようSNAPSHOT CONTROLFILEを構成します。
    たとえば、データベースがASMストレージにデプロイされている場合は次のようにします。
    $ rman target /  
RMAN> CONFIGURE SNAPSHOT CONTROLFILE NAME TO '+DATA/snapcf_matrix.f';

    データベースがACFSファイル・システムにデプロイされている場合は、前述のコマンドに共有のACFSの場所を指定します。

  5. ソースおよびターゲットのデータベース・サーバーのポート22でZero Downtime Migrationサービス・ホストからの着信接続要求が許可されることを確認します。
  6. ソース・データベース・サーバーのSCANリスナー・ポート(1521など)でターゲット・データベース・サーバーからの着信接続要求が許可されることと、その逆も同様であることを確認します。
    ファイアウォールでSCANリスナー・ポートを使用する着信リモート接続がブロックされる場合は、代替SQL接続を使用可能にする必要があります。
  7. 移行時にソース・データベースのリカバリ時間目標(RTO)およびリカバリ・ポイント目標(RPO)を保持するには、既存のRMANバックアップ計画を保持する必要があります。
    移行中に、デュアル・バックアップ計画が実施されます。既存のバックアップ計画と、Zero Downtime Migrationにより使用される計画です。2つのRMANバックアップ・ジョブ(既存のジョブとZero Downtime Migrationにより開始されたジョブ)を同時に実行することは避けてください。ソース・データベースでアーカイブ・ログが削除され、これらのアーカイブ・ログが、ターゲット・クラウド・データベースをインスタンス化するためにZero Downtime Migrationで必要な場合は、Zero Downtime Migrationで移行プロセスを続行できるように、これらのファイルをリストアする必要があります。

関連項目:

透過的データ暗号化ウォレットの設定

Zero Downtime Migrationのポートの要件

親トピック: 移行のためのデータベースの準備

ターゲット・データベースの前提条件

Zero Downtime Migrationプロセスを開始する前に、ターゲット・データベースで次の前提条件を満たす必要があります。

  1. データベース移行の開始前に、プレースホルダ・ターゲット・データベースを作成する必要があります。
    プレースホルダ・ターゲット・データベースは移行時に上書きされますが、全体の構成は維持されます。

    次の要件に細心の注意を払ってください。

    • 将来のサイズ - コンソールからデータベースを作成する際、選択したシェイプがソース・データベースを収容でき、将来のサイズ変更の要件に適応できることを確認します。適切なガイドラインは、ソース・データベースと同程度以上のサイズのシェイプを使用することです。
    • nameパラメータの設定 - ターゲット・データベースのdb_nameは、ソース・データベースのdb_nameと同じである必要があり、ターゲット・データベースのdb_unique_nameパラメータ値は、Oracle Data Guardでターゲットをソース・データベースとは異なるデータベースとして識別できるように一意である必要があります。
    • 自動バックアップの無効化 - 自動バックアップを有効にせずに、コンソールからターゲット・データベースをプロビジョニングします。

      Oracle Cloud InfrastructureおよびExadata Cloud Serviceの場合は、「Configure database backups」セクションの「Enable automatic backups」オプションを選択しないでください。

      Exadata Cloud at Customerの場合は、「Configure Backups」セクションでバックアップ先の「Type」を「None」に設定します。

  2. ターゲット・データベース・バージョンをソース・データベース・バージョンと同じにする必要があります。ターゲット・データベースのパッチ・レベルもソース・データベースと同じ(またはそれ以上)にする必要があります。
    ターゲット・データベース環境がソース・データベースよりも高いパッチ・レベルである場合(ソース・データベースがOct 2018 PSU/BPであり、ターゲット・データベースがJan 2019 PSU/BPである場合など)は、データベースの移行後にdatapatchを実行する必要があります。
  3. 透過的データ暗号化(TDE)が有効になっており、ウォレットのSTATUSがOPENであり、WALLET_TYPEがAUTOLOGIN (AUTOLOGINウォレット・タイプの場合)またはWALLET_TYPEがPASSWORD (PASSWORDベースのウォレット・タイプの場合)であることを確認します。
    SQL> SELECT * FROM v$encryption_wallet;
  4. ターゲットがOracle RACデータベースの場合は、OracleユーザーのOracle RACサーバー間にパスフレーズなしのSSH接続を設定する必要があります。
  5. ターゲット・データベースのディスク・グループ(ASMディスク・グループまたはACFSファイル・システム)のサイズおよび使用率をチェックし、十分な記憶域がターゲット・データベース・サーバーでプロビジョニングされ、使用可能であることを確認します。
  6. ソース・データベースのバックアップを収容するのに十分な記憶域がオブジェクト・ストアでプロビジョニングされ、使用可能であることを確認します。
  7. Oracle Cloud InfrastructureまたはExadata Cloud at Customer環境のターゲット・サーバーでポート22および1521がオープンされており、ファイアウォールによってブロックされていないことを確認します。
  8. 移行後のRMAN設定を比較できるように、RMAN SHOW ALLコマンドの出力を取得した後、変更されたRMAN構成設定をリセットして問題なくバックパップが機能することを確認します。
    RMAN> show all;

関連項目:

Object Storageバックアップ用の認証トークンの生成方法の詳細は、ユーザー資格証明の管理を参照してください。

Zero Downtime Migrationのポートの要件

親トピック: 移行のためのデータベースの準備

Oracle Cloud Infrastructureへの移行の準備

データをOracle Cloud Infrastructure仮想マシンまたはベア・メタル・ターゲットに移行する前に、次の準備を完了します。

  1. レスポンス・ファイル・テンプレートを準備します。
    レスポンス・ファイル・テンプレートは、データ移行手順のためのZero Downtime Migrationレスポンス・ファイルの作成に使用されますが、/u01/app/zdmhome/rhp/zdm/template/zdm_template.rspから取得して、次のようにファイルを更新します。
    • TGT_DB_UNIQUE_NAMEをターゲット・データベースのdb_unique_name値に設定します。
    • PLATFORM_TYPEをVMDBに設定します。
    • MIGRATION_METHODをDG_OSSに設定します(DGはData Guardの略、OSSはObject Storageサービスの略です)。
    • 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_DATADG、TGT_REDODGおよびTGT_RECODG)または(TGT_DATAACFS、TGT_REDOACFSおよびTGT_RECOACFS)と指定します。
    • 任意でまたはターゲットとソース間の接続がないために、REDOログをターゲットからソース・スタンバイに移さない場合は、SKIP_FALLBACK=TRUEを設定します。
    • 移行後、ソース・データベースを停止する場合は、SHUTDOWN_SRC=TRUEを設定します。
  2. Object Storageサービスのアクセスを設定します。
    Oracle Cloudアカウントにアクセスするには、次のパラメータを入力ファイルに設定します。
    • クラウド・ストレージのRESTエンドポイントURL値をHOSTに設定します。値の形式は通常、https://swiftobjectstorage.us-phoenix-1.oraclecloud.com/v1/acme (Oracle Cloud Infrastructureストレージの場合)またはhttps://acme.storage.oraclecloud.com/v1/Storage-acme (Oracle Cloud Infrastructure Classicストレージの場合)です。
    • Object StorageバケットのOPC_CONTAINERパラメータを設定します。バケットは、Oracle Cloud Infrastructure Classicストレージではコンテナとも呼ばれます。必要に応じてOracle Cloud Serviceコンソールを使用してObject Storageバケットが作成されていることを確認します。ソース・データベースのバックアップを収容するのに十分な記憶域がオブジェクト・ストアでプロビジョニングされ、使用可能であることを確認します。
    • ソース・データベース・サーバーからオブジェクト・ストアへのアクセスにプロキシが必要な場合は、SRC_OSS_PROXY_HOSTおよびSRC_OSS_PROXY_PORTを設定します。
    • ターゲット・データベース・サーバーからオブジェクト・ストアへのアクセスにプロキシが必要な場合は、TGT_OSS_PROXY_HOSTおよびTGT_OSS_PROXY_PORTを設定します。

親トピック: 移行のためのデータベースの準備

Exadata Cloud Serviceへの移行の準備

データをExadata Cloud Serviceターゲットに移行する前に、次の準備を完了します。

  1. レスポンス・ファイル・テンプレートを準備します。
    レスポンス・ファイル・テンプレートは、データ移行手順のためのZero Downtime Migrationレスポンス・ファイルの作成に使用されますが、/u01/app/zdmhome/rhp/zdm/template/zdm_template.rspから取得して、次のようにファイルを更新します。
    • TGT_DB_UNIQUE_NAMEをターゲット・データベースのdb_unique_name値に設定します。
    • PLATFORM_TYPEをEXACSに設定します。
    • MIGRATION_METHODをDG_OSSに設定します(DGはData Guardの略、OSSはObject Storageサービスの略です)。
    • 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_DATADG、TGT_REDODGおよびTGT_RECODG)または(TGT_DATAACFS、TGT_REDOACFSおよびTGT_RECOACFS)と指定します。
    • 任意でまたはターゲットとソース間の接続がないために、REDOログをターゲットからソース・スタンバイに移さない場合は、SKIP_FALLBACK=TRUEを設定します。
    • 移行後、ソース・データベースを停止する場合は、SHUTDOWN_SRC=TRUEを設定します。
  2. Object Storageサービスのアクセスを設定します。
    Oracle Cloudアカウントにアクセスするには、次のパラメータを入力ファイルに設定します。
    • クラウド・ストレージのRESTエンドポイントURL値をHOSTに設定します。値の形式は通常、https://swiftobjectstorage.us-phoenix-1.oraclecloud.com/v1/acme (Oracle Cloud Infrastructureストレージの場合)またはhttps://acme.storage.oraclecloud.com/v1/Storage-acme (Oracle Cloud Infrastructure Classicストレージの場合)です。
    • Object StorageバケットのOPC_CONTAINERパラメータを設定します。バケットは、Oracle Cloud Infrastructure Classicストレージではコンテナとも呼ばれます。必要に応じてOracle Cloud Serviceコンソールを使用してObject Storageバケットが作成されていることを確認します。ソース・データベースのバックアップを収容するのに十分な記憶域がオブジェクト・ストアでプロビジョニングされ、使用可能であることを確認します。
    • ソース・データベース・サーバーからオブジェクト・ストアへのアクセスにプロキシが必要な場合は、SRC_OSS_PROXY_HOSTおよびSRC_OSS_PROXY_PORTを設定します。
    • ターゲット・データベース・サーバーからオブジェクト・ストアへのアクセスにプロキシが必要な場合は、TGT_OSS_PROXY_HOSTおよびTGT_OSS_PROXY_PORTを設定します。

親トピック: 移行のためのデータベースの準備

Exadata Cloud at Customerへの移行の準備

データをExadata Cloud at Customerターゲットに移行する前に、次の準備を完了します。

  1. ターゲット・データベースをプロビジョニングします。
    Exadata Cloud at Customer環境で、オンプレミス・データベースのdb_nameと同じdb_nameを使用して新しいプレースホルダ・データベースを構成します。
  2. ZDMCLI入力レスポンス・ファイル・テンプレートを準備します。
    レスポンス・ファイル・テンプレートは、データ移行手順のためのZero Downtime Migrationレスポンス・ファイルの作成に使用されますが、$ZDM_HOME/rhp/zdm/template/zdm_template.rspから取得して、次の各トピックの説明に従ってバックアップ媒体に基づいてファイルを更新します。

親トピック: 移行のためのデータベースの準備

Zero Data Loss Recovery Applianceバックアップを使用したExadata Cloud at Customer用のテンプレートの準備

Zero Data Loss Recovery ApplianceをZero Downtime Migrationのバックアップ媒体として使用する場合は、次の説明に従ってパラメータをレスポンス・ファイルに設定します。

  • TGT_DB_UNIQUE_NAMEをターゲット・データベースのdb_unique_name値に設定します。
  • PLATFORM_TYPEをExaCCに設定します。
  • MIGRATION_METHODをDG_ZDLRAに設定します(DGはData Guardの略、ZDLRAはZero Data Loss Recovery Applianceの略です)。
  • Zero Data Loss Recovery Applianceに存在するバックアップを使用するように、次のZero Data Loss Recovery Applianceのパラメータを設定します。
    • 次のように、SRC_ZDLRA_WALLET_LOCをウォレットの場所に設定します。 
      SRC_ZDLRA_WALLET_LOC=/u02/app/oracle/product/12.1.0/dbhome_3/dbs/zdlra
    • TGT_ZDLRA_WALLET_LOCを設定します。
    • 次のように、ZDLRA_CRED_ALIASをウォレットの資格証明別名に設定します。 
      ZDLRA_CRED_ALIAS=zdlra_scan:listener_port/zdlra9:dedicated
  • ターゲット・データベースのデータ・ファイル・ストレージ(ASMまたはACFS)のプロパティを適宜指定します。ASMの場合は、TGT_DATADG、TGT_REDODGおよびTGT_RECODGを設定します。ACFSの場合は、TGT_DATAACFS、TGT_REDOACFSおよびTGT_RECOACFSを設定します。
  • 任意でまたはターゲットとソース間の接続がないために、REDOログをターゲットからソース・スタンバイに移さない場合は、SKIP_FALLBACK=TRUEを設定します。
  • 移行後、ソース・データベースを停止する場合は、SHUTDOWN_SRC=TRUEを設定します。
Object Storageバックアップを使用したExadata Cloud at Customer用のテンプレートの準備

Oracle Cloud Infrastructure Object StorageサービスをZero Downtime Migrationのバックアップ媒体として使用する場合は、次の説明に従ってパラメータをレスポンス・ファイルに設定します。

  • TGT_DB_UNIQUE_NAMEをターゲット・データベースのdb_unique_name値に設定します。
  • PLATFORM_TYPEをExaCCに設定します。
  • MIGRATION_METHODをDG_OSSに設定します(DGはData Guardの略、OSSはObject Storageサービスの略です)。
  • Oracle Cloud Infrastructure Object Storageサービスのアクセスおよびコンテナの詳細を指定します。

    ソース・データベースは、指定されたコンテナにバックアップされ、RMAN SQL*Net接続を使用してExadata Cloud at Customerにリストアされます。

  • ターゲット・データベースのデータ・ファイル・ストレージ(ASMまたはACFS)のプロパティを適宜指定します。ASMの場合は、TGT_DATADG、TGT_REDODGおよびTGT_RECODGを設定します。ACFSの場合は、TGT_DATAACFS、TGT_REDOACFSおよびTGT_RECOACFSを設定します。
  • 任意でまたはターゲットとソース間の接続がないために、REDOログをターゲットからソース・スタンバイに移さない場合は、SKIP_FALLBACK=TRUEを設定します。
  • 移行後、ソース・データベースを停止する場合は、SHUTDOWN_SRC=TRUEを設定します。
NFSバックアップを使用したExadata Cloud at Customer用のテンプレートの準備

NFSストレージをZero Downtime Migrationのバックアップ媒体として使用する場合は、次の説明に従ってパラメータをレスポンス・ファイルに設定します。

  • TGT_DB_UNIQUE_NAMEをターゲット・データベースのdb_unique_name値に設定します。
  • PLATFORM_TYPEをExaCCに設定します。
  • MIGRATION_METHODをDG_SHAREDPATHまたはDG_EXTBACKUPに設定します(DGはData Guardの略です)。

    新しいバックアップを作成し、外部ストレージ・マウント(NFSマウント・ポイントなど)に配置する場合はDG_STORAGEPATHを使用します。

    すでに外部共有マウント(NFSストレージ)に配置されている既存のバックアップを使用する場合は、DG_EXTBACKUPを使用します。

    MIGRATION_METHODをDG_EXTBACKUPに設定した場合、Zero Downtime Migrationでは新しいバックアップが実行されません。

  • BACKUP_PATHを設定して、ソースとターゲットの両方のデータベース・サーバーからアクセスできるようになっている実際のNFSパス(NFSマウント・ポイントなど)を指定します。NFSマウント・パスはソースとターゲットの両方のデータベース・サーバーで同じである必要があります。このパスは、Zero Downtime Migrationサービス・ホストにマウントされている必要はありません。

    次の考慮事項に注意してください。

    • ソース・データベースは、RMAN SQL*Net接続を使用して、指定されたパスにバックアップされ、Exadata Cloud at Customerにリストアされます。
    • BACKUP_PATHに設定するパスには、ソース・データベース・ユーザーの場合は'rwx'権限が、ターゲット・データベース・ユーザーの場合は読取り権限以上が必要です。
    • BACKUP_PATHで指定したパスに、Zero Downtime Migrationバックアップ・プロシージャによってディレクトリ$BACKUP_PATH/dbnameが作成され、このディレクトリにバックアップ・ピースが格納されます。
  • DG_EXTBACKUPをMIGRATION_METHODとして使用する場合は、スタンバイ制御ファイルのバックアップを指定のパスに作成し、バックアップ・ピースに対する読取り権限をターゲット・データベース・ユーザーに付与する必要があります。次に例を示します。
    RMAN> BACKUP CURRENT CONTROLFILE FOR STANDBY FORMAT '< BACKUP_PATH >/lower_case_dbname/standby_ctl_%U';

    standby_ctl_%Uは、システム生成の一意のファイル名です。

  • ターゲット・データベースのデータ・ファイル・ストレージ(ASMまたはACFS)のプロパティを適宜指定します。ASMの場合は、TGT_DATADG、TGT_REDODGおよびTGT_RECODGを設定します。ACFSの場合は、TGT_DATAACFS、TGT_REDOACFSおよびTGT_RECOACFSを設定します。
  • 任意でまたはターゲットとソース間の接続がないために、REDOログをターゲットからソース・スタンバイに移さない場合は、SKIP_FALLBACK=TRUEを設定します。
  • 移行後、ソース・データベースを停止する場合は、SHUTDOWN_SRC=TRUEを設定します。

オフライン移行(バックアップおよびリカバリ)の準備

データベースをOracle Cloud Infrastructure、Exadata Cloud at CustomerまたはExadata Cloud Serviceのターゲット環境に移行する前に、次の準備を完了します。

  1. レスポンス・ファイル・テンプレートを準備します。
    レスポンス・ファイル・テンプレートは、データ移行手順のためのZero Downtime Migrationレスポンス・ファイルの作成に使用されますが、/u01/app/zdmhome/rhp/zdm/template/zdm_template.rspから取得して、次のようにファイルを更新します。
    • TGT_DB_UNIQUE_NAMEをターゲット・データベースのdb_unique_name値に設定します。
    • ターゲット環境に応じて、PLATFORM_TYPEを適切な値に設定ます。
      • Oracle Cloud Infrastructureの場合は、PLATFORM_TYPE=VMDBを設定します。
      • Exadata Cloud at Customerの場合は、PLATFORM_TYPE=EXACCを設定します。
      • Exadata Cloud Serviceの場合は、PLATFORM_TYPE=EXACSを設定します。
    • MIGRATION_METHODをBACKUP_RESTORE_OSSに設定します(OSSはObject Storageサービスの略です)。
    • ターゲット・データベースのデータ・ファイル・ストレージ(ASMまたはACFS)のプロパティを適宜指定します。ASMの場合は、TGT_DATADG、TGT_REDODGおよびTGT_RECODGを設定します。ACFSの場合は、TGT_DATAACFS、TGT_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を設定します。
  2. Object Storageサービスのアクセスを設定します。
    Oracle Cloudアカウントにアクセスするには、次のパラメータを入力ファイルに設定します。
    • クラウド・ストレージのRESTエンドポイントURL値をHOSTに設定します。値の形式は通常、https://swiftobjectstorage.us-phoenix-1.oraclecloud.com/v1/acme (Oracle Cloud Infrastructureストレージの場合)またはhttps://acme.storage.oraclecloud.com/v1/Storage-acme (Oracle Cloud Infrastructure Classicストレージの場合)です。
    • Object StorageバケットのOPC_CONTAINERパラメータを設定します。バケットは、Oracle Cloud Infrastructure Classicストレージではコンテナとも呼ばれます。必要に応じてOracle Cloud Serviceコンソールを使用してObject Storageバケットが作成されていることを確認します。ソース・データベースのバックアップを収容するのに十分な記憶域がオブジェクト・ストアでプロビジョニングされ、使用可能であることを確認します。
    • ソース・データベース・サーバーからオブジェクト・ストアへのアクセスにプロキシが必要な場合は、SRC_OSS_PROXY_HOSTおよびSRC_OSS_PROXY_PORTを設定します。
    • ターゲット・データベース・サーバーからオブジェクト・ストアへのアクセスにプロキシが必要な場合は、TGT_OSS_PROXY_HOSTおよびTGT_OSS_PROXY_PORTを設定します。

親トピック: 移行のためのデータベースの準備

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

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

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

(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

関連項目:

https://www.oracle.com/goto/maaのOracle Active Data Guardのベスト・プラクティス・ページのクライアント・フェイルオーバーのベスト・プラクティスに関するOracle MAAホワイト・ペーパー

Oracle Database開発ガイドの高可用性

親トピック: データベース移行の準備

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

移行ジョブに含まれる操作フェーズの一環として実行するために、アクション・スクリプトまたはアクション・プラグインをアクション前またはアクション後として登録すると、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> ./zdmcli add useraction -useraction zdmvaltgt -optype MIGRATE_DATABASE 
-phase ZDM_VALIDATE_TGT -pre -onerror ABORT -actionscript /home/useract.sh

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

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

親トピック: 移行ジョブのカスタマイズ

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

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

アクション・テンプレートは、ZDMCLIコマンドadd imagetypeを使用して作成します(イメージ・タイプimagetypeは、特定のタイプのデータベース移行に必要なすべてのユーザーアクションをまとめたものです)。データベースの移行に必要なすべてのユーザーアクション・プラグインを関連付けるイメージ・タイプを作成します。作成したイメージ・タイプは、同じプラグイン・セットを必要とするすべての移行操作で再利用できます。

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

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

zdmuser>./zdmcli add imagetype -imagetype ACTION_ZDM -basetype 
CUSTOM_PLUGIN -useractions zdmvalsrc,zdmvaltgt

親トピック: 移行ジョブのカスタマイズ

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

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

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

zdmuser>./zdmcli modify useraction -useraction zdmvalsrc -phase ZDM_VALIDATE_SRC
 -optype MIGRATE_DATABASE -post

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

親トピック: 移行ジョブのカスタマイズ

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

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

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

親トピック: 移行ジョブのカスタマイズ