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

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

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

警告

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

データの凍結

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

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

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

初期スキーマを作成するために、すべてのカスタムモジュールを組み込んだLiferayを空のPostgreSQL 16データベースに対して実行し、それをデータベース変換の基盤として使用する必要があります。その後、 pgloader のようなツールを使用して、データを新しいデータベーステーブルに移動できます。

重要

データベースを変換する際は、テーブル名の大文字・小文字の区別が正しいことを確認してください。詳細については、表の大文字小文字を正しくするを参照してください。

データベースを変換する際に考慮すべき重要な事項をいくつかご紹介します。

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

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

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

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

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

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

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

重要

アドバンストファイルシステムストアは、大規模なデータセットに容易に拡張できるフォルダ構造を使用します。長期的には、ドキュメントライブラリにより多くのファイルを収容するために、高度なファイルシステムストアへの移行が推奨され、あらゆる運用環境では 必須です。

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

変更した内容で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 上のすべての環境では、ドキュメントライブラリに同じ実装を使用する必要があります。これにより、からバックアップを復元した場合に、他の環境でバックアップが機能するようになります。ビルドをすべての環境にデプロイして、すべての環境で移行したドキュメントライブラリストアが正しく使用されることを確認する必要があります。