概要
TIBCO EBXにおけるアドオン設定やデータモデル、データスペースの環境間移行には、主に「ステージング機能」を利用する方法と、「DBダンプ」を利用する方法の2種類が存在します。
ステージング機能はデータモデル、ワークフロー、プロファイル・権限設定などの特定の構成要素を選んで差分適用できるのに対し、DBダンプはデータを含むリポジトリ全体を丸ごと上書き・複製する方式です。
本記事では、それぞれの方式の特徴や移行対象の差異を比較し、DBダンプの手順および使用上の注意点を解説します。
移行方式の比較
EBXにおける代表的な2つの環境間移行方式（ステージング機能およびDBダンプ）のそれぞれの特徴・相違点は以下の通りです。
| 比較項目 | ステージング機能 | DBダンプ |
|---|---|---|
| 移行の粒度 | 選択可能（一部のみ移行可） データモデル、ワークフロー、プロファイル・権限設定などの特定の構成要素を選んで移行できる。※1 | 全体（選択不可） リポジトリ全体を丸ごと上書きするため、個別の選択はできない。 |
| 既存環境への影響 | 移行先の既存データを保持したまま、差分としてインポートが可能。 | 移行先の既存設定やデータはすべて上書き（消失）される。 |
| 主なユースケース | 開発環境からテスト・本番環境へ、特定の設定変更や追加テンプレートだけをリリースしたい場合。 | 環境構築の初期段階でのクローン作成や、本番環境のデータをそのまま検証環境に完全再現したい場合。 |
| Tomcatの停止 | 不要（画面操作で実行可能。ただし本番等への反映時はユーザーアクセスの停止/抑止を推奨） | 必須（ファイルロックや整合性破壊を防ぐため） |
| indexesディレクトリ内の削除 | 不要（EBXが自動で整合性を維持） | 必須（EBXサーバー上の indexes ディレクトリ内を起動前に手動削除し、再インデックスを実施） |
| 作業負荷 | 小（画面操作のみで完結） | 大（DBコマンド操作、権限設定、事前バックアップが必要） |
| 大容量データへの対応 | タイムアウトやメモリ圧迫のリスクあり | RDBエンジンのダンプ・リストア機能を利用するため、大容量データにも対応可能 |
※1: EBXのバージョンや使用アドオンによって、ステージング対象外となる要素が存在する場合があります。
- ステージングが向いているケース
- 開発環境で作成したデータモデル、ワークフロー設定、プロファイル・権限などを、テスト環境や本番環境へ「差分適用」したい場合
- 移行先環境にある既存のテストデータや運用データを消さずに、設定変更のみを適用したい場合
- DBダンプが向いているケース
- 本番環境のデータを開発・検証環境へ「完全再現（リフレッシュ）」したい場合
- 新規環境構築時に、初期リポジトリ構造およびデータをまるごと複製・投入する場合
移行元と移行先でバージョン不一致がある場合の挙動
ステージング機能とDBダンプにおいて、移行元環境と移行先環境の間でバージョンの不一致（差分）が発生した場合のシステム挙動に関して記載します。
| 比較項目 | ステージング機能 | DBダンプ |
|---|---|---|
| EBXのバージョンの差分 | 同一マイナーバージョンかつ、移行先のバージョンが同等以上の場合のみ可※1 | 移行先のバージョンが同等以上の場合のみ可※2 |
| DBMSのバージョンの差分 | 影響なし（移行先で異なるDBMS製品でも可） | 同一DBMS製品で、移行先のバージョンが同等以上の場合のみ可 |
※1: EBXのバージョンはメジャー・マイナー・パッチ・hotfixで構成されています。
（例: バージョン 6.2.3 の場合、メジャー: 6、マイナー: 2、パッチ: 3）
例えば、バージョン 6.2.2 から 6.2.3 への移行は可能ですが、6.1.x から 6.2.x への移行はステージング非対応です。
※2: メジャーバージョンのアップグレード（例: v5.9.x から v6.x.x）など、メジャーバージョンが異なる場合は直接のDBダンプ移行を行わず、公式のバージョンアップ手順書に従ってください。
DBダンプを利用する移行手順
リポジトリDBにPostgreSQLを使用している場合の移行手順を記載します。
※コマンドを実行するユーザーには、データベースの管理者権限（またはDB所有者権限）が必要です。
▼エクスポート手順
処理中のデータ変更による不整合を防ぐため、移行元のEBXアプリケーションサーバーを停止します。
データベース管理ツール（pg_dump）を使用し、EBXリポジトリのデータベース全体をエクスポートします。コマンドプロンプトで以下のコマンドを参考に実行してください。
"<PostgreSQLインストール先>\bin\pg_dump" -U <DBユーザー名> -h <DBホスト> -p <ポート番号> -d <データベース名> -F c -f <出力ファイル名>.dump -v
▼インポート手順
ファイルロックや不整合を防ぐため、移行先のEBXアプリケーションサーバーを停止します。
万が一リストアに失敗した場合やデータに問題があった場合に備え、現在の移行先DBのバックアップを取得します。コマンドプロンプトで以下のコマンドを参考に実行してください。
"<PostgreSQLインストール先>\bin\pg_dump" -U <移行先DBユーザー名> -h <DBホスト> -p <ポート番号> -d <移行先DB名> -F c -f ebx_target_backup.dump -v移行元から取得したダンプファイルを使い、移行先のデータベースへリストアを実行します。コマンドプロンプトで以下のコマンドを参考に実行してください。
"<PostgreSQLインストール先>\bin\pg_restore" -U <移行先DBユーザー名> -h <DBホスト> -p <ポート番号> -d <移行先DB名> -c -1 --no-owner <移行元ファイル名>.dump -v【重要】--no-owner オプションの役割:
移行元と移行先でDBの所有者（ロール/ユーザー）が異なる場合、所有者の変更処理で権限エラーが発生しリストアが停止します。リストア時に --no-owner（または -O）オプションを付与することで、ダンプファイル内の「所有者変更コマンド（ALTER OWNER）」を無視し、現在リストアを実行している接続ユーザーをそのまま全テーブルの所有者として復元できます。
移行先の
ebx.properties内の接続情報（DB URL、ユーザー名、パスワード）や各ディレクトリーパス（ebx.repository.directory等）が、移行先サーバーの環境に合わせて正しいことを確認します。ディスク上のインデックス（indexes）を削除します。
対象フォルダ:<ebx.repository.directory のパス>\indexes\
作業内容:indexesフォルダの中にあるすべてのファイルおよびサブフォルダを削除します（※indexesフォルダ自体は残します）。移行先のEBXアプリケーションサーバーを起動します。
※起動時、削除したindexesの再構築（Reindex）が自動的に実行されます。データ量に応じた時間がかかりますので、起動完了後にEBX管理画面にログインし、データが正常に反映されているか確認してください。