Amazon Aurora を使用するために Confluence Data Center を構成する
On this page:
Confluence Data Center は、単一ライターの、PostgreSQL 互換の Amazon Aurora のクラスタ化データベースの使用をサポートしています。一般的なプロダクショングレードのクラスタでは、異なるアベイラビリティ ゾーンに少なくとも 1 つのリーダーが含まれます。ライターが失敗した場合、Amazon Aurora はリーダーの 1 つを自動的にプロモートしてライターにします。詳細は「Amazon Aurora の特徴: PostgreSQL 互換エディション」 を参照してください。
Confluence Data Center を Amazon Aurora とデプロイ
デプロイ方法としての AWS クイック スタート テンプレートはアトラシアンではサポートされなくなりました。テンプレートは今後も利用できますが、保守や更新は行われません。
より効率的で堅牢なインフラストラクチャと運用のセットアップのために、Helm チャートを使用して Data Center 製品を Kubernetes クラスターにデプロイすることをお勧めします。Kubernetes へのデプロイに関する詳細はこちらをご確認ください。
AWS は、現在、AWS クイック スタート テンプレートで使用される起動設定を起動テンプレートに切り替えることを推奨していますが、AWS クイック スタート テンプレートのサポートは終了しているため、アトラシアンではこの切り替えを行う予定はありません。そのため、このテンプレートを使用して起動設定を作成することはできません。
Amazon Aurora で新しい Confluence Data Center デプロイを作成するには、引き続き「Confluence の AWS クイック スタート」を使用できますが、AWS クイック スタート テンプレートに対するアトラシアンのサポートと保守は終了しています。このクイック スタートによって、1 つのライター インスタンスと 2 つのリーダー インスタンスがある PostgreSQL 互換の Amazon Aurora クラスターを、別々のアベイラビリティ ゾーンに構成できます。詳細については「AWS で Confluence Data Center を実行する」をご確認ください。
既存のクイックスタート デプロイを Amazon Aurora に接続
2019 年 6 月 11 日より前にクイックスタートを使用して Confluence Data Center をデプロイした場合、それを新しい Amazon Aurora クラスタに接続することはできません。この日付より前のクイックスタート バージョンでは、Aurora との互換性のない設定がいくつか適用されていました。
この場合、既存のデータを新しい Confluence Data Center デプロイに移行する必要があります。
最新の Confluence のための AWS クイックスタートを使用して、Confluence Data Center デプロイを作成します。
新旧両方のデプロイのアプリケーション ノードで Confluence をシャットダウンします。スタンドアロンの Synchrony クラスタを使用する場合、そのクラスタ内のすべてのノードもシャットダウンします。
古いデプロイから新しいデプロイにデータを移行します。
EFS: 簡単にデプロイできるバックアップ ソリューションを使用して古い EFS のバックアップを実行し、新しいデプロイに復元する方法について、「EFS-to-EFS Backup」をご参照ください。
データベース: Amazon RDS から PostgreSQL 互換の Amazon Aurora クラスタへの移行手順について、「PostgreSQL 互換で Amazon Aurora にデータを移行する」をご参照ください。
移行が完了したら、新しいデプロイのすべてのアプリケーション ノードで Confluence を再起動します。スタンドアロンの Synchrony クラスタを使用する場合、そのすべてのノードを再起動します。
Confluence 検索を期待どおりに動作させるため、移行後にコンテンツ インデックスの再構築を行うことを強くおすすめします。
Amazon Aurora データベースの手動セットアップ
Confluence Data Center では、以下の構成での Amazon Aurora クラスタの使用をサポートしています。
1 つ以上のリーダーにレプリケートするライターが 1 つのみ必要。
PostgreSQL エンジンはバージョン 9.6 以降である。
詳細は「サポート対象プラットフォーム」を確認してください。
AWS ドキュメント
Modular Architecture for Amazon Aurora PostgreSQL: PostgreSQL 互換 Aurora データベース クラスタのデプロイ方法を示すクイック スタートです。このクラスターには 1 つのライターと 2 つのリーダーがあり、それぞれ異なるアベイラビリティー ゾーンに配置することが推奨されています。
Amazon RDS の PostgreSQL DB エンジンのアップグレード: Amazon Aurora に移行する前にデータベース エンジンをサポート対象バージョンにアップグレードする方法を示します。
PostgreSQL 互換で Amazon Aurora にデータを移行する: Amazon RDS から PostgreSQL 互換の Amazon Aurora クラスタに移行するための手順が含まれています。
Amazon Aurora PostgreSQL を使用する際のベストプラクティス: PostgreSQL 互換 Amazon Aurora クラスタにデータを移行する際のベスト プラクティスとオプションについての追加情報が含まれています。
また、Amazon はマネージド移行を実現するための AWS Database Migration Service も提供しています。このサービスは、最小限のダウンタイムで、さまざまなソース データベースから Aurora への移行をサポートするものです。
2019 年 6 月 11 日より前にクイックスタートを使用して Confluence Data Center をデプロイした場合、それを新しい Amazon Aurora クラスタに接続することはできません。更新されたクイックスタートを使用して Confluence Data Center を再デプロイし、データを移行する必要があります。詳細については「既存のクイックスタートデプロイをAmazon Aurora に接続する」を参照してください。
Confluence Data Center を新しい Amazon Aurora データベースに接続する
Aurora クラスタをデプロイしてそこにデータベースを移行したら、それを Confluence に適切に接続する必要があります。これには、Confluence Data Center で使用されるデータベース URL の更新が含まれます。
Confluence Data Center は、Aurora クラスタのライター エンドポイント URL を指し、targetServerType
パラメーターを含んでいる必要があります。このパラメーターによって Confluence はライター データベース インスタンスをターゲットにできるため、フェイルオーバー後にアプリケーションが再接続できるようになります。
データベース URL は以下のようになります。
jdbc:postgresql://<CLUSTER_WRITER_ENDPOINT>:<CLUSTER_WRITER_PORT>/<DATABASE_NAME>?targetServerType=master
Modular Architecture for Amazon Aurora PostgreSQL にしたがって Aurora クラスタをデプロイした場合、AWS の [出力] タブでクラスタ ライターの詳細を確認できます。RDSEndpointAddress
および RDSEndpointAddressPort
の値が、それぞれ CLUSTER_WRITER_ENDPOINT
および CLUSTER_WRITER_PORT
になります。
以降の手順では、Confluence と Aurora を接続するプロセスについて説明します。
ステップ 1: Confluence Data Center のシャットダウン
Confluence Data Center のデータベース接続を安全に再構成するため、完全停止を行うことをおすすめします。これを行うには、すべてのアプリケーション ノードで Confluence を停止します。
スタンドアロンの Synchrony クラスタがある場合は、各ノードで Synchrony を停止します。
ステップ 2: 各 Confluence ノードが使用するデータベース URL の更新
この手順の実行方法は、現在の Confluence のデータベースへの接続方法によって異なります。
直接 JDBC 接続を使用する場合
1 つめのノードで、
<local-home>/confluence-cfg.xml
ファイルを編集します。次のように、
hibernate.connection.url
プロパティをクラスタのライター エンドポイント URL で更新します。<property name="hibernate.connection.url">jdbc:postgresql://<CLUSTER_WRITER_ENDPOINT>:<CLUSTER_WRITER_PORT>/<DATABASE_NAME>?targetServerType=master
他のすべてのノードでこの変更を繰り返します。
Confluence のノードを 1 つずつ起動します。
この変更は、共有ホームにある confluence-cfg.xml
のコピーではなく、各ノードのローカル ホーム ディレクトリで行う必要があります。
データソース接続を使用する場合
すべてのノードで Confluence を停止します。
1 つめのノードで、
<install-directory>/conf/server.xml
ファイルを編集します。次のように、データソースの
Resource
要素の url パラメータをクラスタのライター エンドポイント URL で更新します。<Resource name="jdbc/confluence" auth="Container" type="javax.sql.DataSource" username="<database-user>" password="<password>" driverClassName="org.postgresql.Driver" url="jdbc:postgresql://<CLUSTER_WRITER_ENDPOINT>:<CLUSTER_WRITER_PORT>/<DATABASE_NAME>?targetServerType=master" maxTotal="60" maxIdle="20" validationQuery="select 1"/>
他のすべてのノードでこの変更を繰り返します。
Confluence のノードを 1 つずつ起動します。
ステップ 3: 共同編集の構成
共同編集を実現する Synchrony は 2 つの異なる方法でデプロイ可能で、これに応じてデータベース URL の受け渡し方法が異なります。
Confluence で管理- Confluence が同じノードで自動的に Synchrony プロセスを起動して管理します。
スタンドアロンの Synchrony クラスタ - スタンドアロンの Synchrony を必要なノード数で独自のクラスタでデプロイおよび管理します。これはクイックスタートを使用して AWS で Confluence をデプロイする際の既定の方法です。
Synchrony を Confluenceで管理している場合、特別な操作は不要です。Confluence が URL を Synchrony に渡します。
スタンドアロンの Synchrony クラスタを実行する場合、スタートアップ スクリプトでクラスタのライター エンドポイント URL を提供する必要があります。このスクリプトは、オペレーティング システムに応じて、<synchrony-home>/start-synchrony.sh
または start-synchrony.bat
です。スクリプトを次のように編集します。
DATABASE_URL="jdbc:postgresql://<CLUSTER_WRITER_ENDPOINT>:<CLUSTER_WRITER_PORT>/<DATABASE_NAME>?targetServerType=master"
set DATABASE_URL=jdbc:postgresql://<CLUSTER_WRITER_ENDPOINT>:<CLUSTER_WRITER_PORT>/<DATABASE_NAME>?targetServerType=master
スタンドアロンの Synchrony クラスタのセットアップの詳細については、「Confluence Data Center 用に Synchrony クラスタをセットアップする」を参照してください。
Synchrony を Linux サービスとして実行する場合、サービスを再インストールする必要があります。
ステップ 4: Confluence の再起動
データベース URL の必要な更新を行ったら、Confluence を各アプリケーション ノードで再起動できます。一度に 1 ノードで操作を行います。
スタンドアロンの Synchrony クラスタがある場合、各クラスタ ノードでそれを再起動します。