ご覧のページは、お客様の利便性のために一部機械翻訳されています。また、ドキュメントは頻繁に更新が加えられており、翻訳は未完成の部分が含まれることをご了承ください。最新情報は都度公開されておりますため、必ず英語版をご参照ください。翻訳に問題がある場合は、こちらまでご連絡ください。

ステージ2：データバックアップファイルの作成

オンプレミス環境とLiferay Cloud環境でLiferayバージョンが一致したため、インストールしたデータを移行するための準備をします。移行のこの段階では、データベースダンプを作成し、ドキュメントライブラリストアを移行します。

警告

Liferay Cloud サポートに連絡せずに次のステップでアップロードするには、データベースダンプのサイズが 2 TB を超えてはなりません。

データの凍結

データのバックアップファイルを作成する前に、Liferayインスタンスのデータを凍結させるためのウィンドウを配置する必要があります。これにより、バックアップの取得中にデータが失われることを防ぐことができます。データベース管理者と調整し、データベースとドキュメントライブラリを凍結して移行するためのウィンドウを予約します。

データベースをPostgreSQLに変換する

データベースが PostgreSQL 16 と互換性があることを確認してください。 pgloader のようなツールを使用して、他のデータベース形式を PostgreSQL に変換できます。ただし、作成されたデータベースに正しいデータ型と関連するすべてのデータベースオブジェクト (テーブル、インデックス、ルール) が含まれていることを確認する必要があります。

初期スキーマを作成するには、空の PostgreSQL 16 データベースに対してすべてのカスタムモジュールを含む Liferay を実行し、それをデータベース変換のベースとして使用する必要があります。次に、 pgloaderなどのツールを使用して、データを新しいデータベーステーブルに移動できます。

重要

データベースを変換するときに、テーブル名の大文字と小文字を正しく使用していることを確認してください。詳細については、「表の大文字/小文字の正しい使用方法の確認」を参照してください。

データベースを変換する際の重要な考慮事項は次のとおりです。

すべてのLiferayテーブルは、 public スキーマ内に作成する必要があります。
ブール値 (true/false) のデータベース列データは、 boolean データ型で作成します。 tinyint や smallintデータ型ではありません。
アプリケーションでカスタムオブジェクトテーブルを使用する場合、空の PostgreSQL データベースを初期化してもこれらのテーブルは自動的に作成されません。その代わりに、これらのオブジェクトをエクスポートおよびインポートして、新しいスキーマに確実に含める必要がある。
システムオブジェクトの一部のオブジェクトテーブルは、名前に会社 ID フィールドを使用して作成されます。これらのオブジェクトテーブルを確認し、名前に含まれる会社 ID をすべて調整して、ソースデータベースの会社 ID と一致するようにします。
Liferay は PostgreSQL ルールを使用して、データベース内の大きなオブジェクトを適切に処理します。ここで定義されているのと同じルールを含めるようにしてください。
Liferayのスキーマの一部ではないカスタムテーブルに依存している場合は、それらの各テーブルを移行するためのソリューションを考案する必要があります。
アプリケーションに、独自のデータベース機能 (関数やストアドプロシージャなど) を活用するカスタムロジックが含まれていないか確認します。例えば、DAYや GROUP_CONCATのようなMySQLデータベース関数はPostgreSQLでは動作しません。

変換の前後にデータベース管理者と調整し、データの整合性を確保します。続行する前に、変換されたデータベースをローカルの Liferay インストールに接続してテストしてください。

データベースダンプの作成

データベースが PostgreSQL 形式になったので、データベースダンプを作成し、それを .gz アーカイブに圧縮してアップロードする必要があります。

データベースダンプを作成するには、次の手順に従ってください。完了すると、圧縮された SQL スクリプトが含まれた database.gz アーカイブファイルが作成されます。

ドキュメントライブラリをファイルシステムストアに移行する

ドキュメントライブラリがファイルシステムストア以外のファイルストレージ方法 (Amazon S3Store や DBStore など) を使用している場合は、続行する前にファイルシステムストアに移行する必要があります。シンプルファイルシステムストアまたは高度なファイルシステムストアを使用できます。

重要

高度なファイルシステムストアは、大規模なデータセットに簡単に拡張できるフォルダー構造を使用します。長期的にドキュメントライブラリ内のファイルを増やすには、Advanced File System Store への移行が推奨されます。これは、あらゆる運用環境で必須です。

ドキュメントライブラリを移行する手順については、「ファイルストアの移行」を参照してください。

変更した内容でJenkinsビルドを作成する

Liferay のローカルインストールを移行した後、 portal-ext.propertiesを変更したビルドを作成して Liferay Cloud 環境にデプロイする必要があります。ドキュメントライブラリストアを移行しなかった場合は、環境に変更を展開する必要はありません。

Gitコマンドを実行し、Gitがインストールされている端末で変更内容を送信します。

変更したファイルをGitに追加します。
```
git add .
```
変更内容とメッセージをコミットします。
```
git commit -m "Liferay Cloud Migration Stage 2"
```
変更をGitHubにプッシュします。
```
git push origin master
```

プロジェクトはGitHubのリポジトリにリンクされているため、変更をプッシュすると自動的にビルドが作成されます。ビルドが完了するのを待ってから、次に進みます。

ビルドを選択した環境にデプロイする

最後に、 Liferay Cloud Console を使用して、完成したビルドを選択した環境にデプロイします。

Liferay Cloud Consoleでビルドページに移動します（ページ上部のリンクを使用します）。
リストの中から前回作成したビルドを探し、アクションメニューから［Deploy build to］をクリックします。
ビルドをデプロイする環境を選択します（例： acme-dev）。
以下の情報を確認し、確認ボックスを選択して、デプロイ結果を確認します。
ビルドのデプロイをクリックします。

ビルドは選択した環境にデプロイされ、portal-ext.propertiesの変更はliferayサービスが再起動したときに適用されます。

重要

Liferay Cloud 上のすべての環境でドキュメントライブラリの同じ実装を使用する必要があります。そうすることで、が他の環境に復元された場合に、1 つの環境からのバックアップが機能するようになります。ビルドをすべての環境にデプロイして、すべての環境で移行したドキュメントライブラリストアが正しく使用されることを確認する必要があります。