EDB Postgres™レプリケーションサーバー
マルチマスターサポート付き

ユーザーガイド

 

 

EDB Postgres™Replication Server 6.2

 

2019年11月20日

 

1 はじめに

このドキュメントでは、 EDB xDB Replication Server のインストール、構成、アーキテクチャ、および操作について説明し ます 。 EDB xDB（クロスデータベース）Replication Server（以降xDB Replication Serverと呼びます ）は、PostgreSQL®およびEDB Postgres™Advanced Serverで使用可能な非同期レプリケーションシステムです。後者は、単にAdvanced Serverと呼ばれます 。

xDB Replication Serverは、 シングルマスター （マスターからスレーブ）レプリケーションまたはマルチマスターレプリケーションの2つの異なるレプリケーションモデルのいずれかに基づいたレプリケーションシステムの実装に使用できます 。

選択したレプリケーションモデルに関係なく、xDB Replication Serverは非常に柔軟で使いやすいです。

シングルマスターレプリケーションの場合、PostgreSQL、Advanced Server、Oracle®、Microsoft®SQLServer®がさまざまな構成（カスケードレプリケーションを含む）でサポートされているため、組織はさまざまな利点を備えた複数のユースケースでそれを利用できます。

以下は、xDB Replication Serverがシングルマスターレプリケーションでサポートするデータベース間のレプリケーションのいくつかの組み合わせです。

•	OracleからPostgreSQLへ

•	OracleからAdvanced Serverへ

•	SQL ServerからPostgreSQLへ

•	SQL ServerからAdvanced Serverへ

•	Advanced ServerからOracleへ

•	PostgreSQLからSQL Serverへ

•	Advanced ServerからSQL Serverへ

•	PostgreSQLとAdvanced Serverの間

注： Oracle Real Application Clusters（RAC）およびOracle Exadataは、xDB Replication Serverではサポートされていません。これらのOracle製品は、xDB Replication Serverで評価および認定されていません。 xDB Replication Serverで使用できる認定およびサポートされているデータベースサーバー製品については、セクション10.1を参照してください。

マルチマスターレプリケーションの場合、xDB Replication Serverは次の構成をサポートします。

•	PostgreSQLデータベースサーバー間

•	PostgreSQLデータベースサーバーとPostgreSQL互換モードのAdvanced Serverの間

•	PostgreSQL互換モードのアドバンストサーバー間

•	Oracle互換モードのAdvanced Server間

注：サポートされているソースおよびターゲットデータベースサーバー構成の詳細については、セクション10.1.3を参照してください。

読者は、データベース、ユーザー、スキーマ、およびテーブルを作成し、データベースオブジェクトの権限を割り当てることができるように、基本的なSQLの知識と、基本的なOracle、SQL Server、またはPostgreSQLデータベース管理スキル（いずれか該当する方）を持っていると想定されています。

このドキュメントは次のように構成されています。

•	第1章の残りの部分では、このユーザーガイド全体で使用される規則と、このガイドの使用目的に基づいて読むべき推奨セクションを説明します。

•	第2章では、基本的なレプリケーションの概念と定義、xDB Replication Serverのアーキテクチャとコンポーネント、およびレプリケーションシステムをセットアップするための設計ガイドラインなど、xDB Replication Serverの概要を説明します。

•	第3章では、xDB Replication Serverのインストールとアンインストールの手順を説明します。

•	第4章では、xDB Replication Serverを使用するためのグラフィカルユーザーインターフェイスであるxDB Replication Consoleの概要を説明します。

•	第5章では、シングルマスター複製システム用のxDB Replication Serverの構成と操作の手順を説明します。

•	第6章では、マルチマスター複製システム用のxDB Replication Serverの構成と操作の手順を説明します。

•	第7章では、シングルマスター複製システムとマルチマスター複製システムの両方に共通する操作について説明します。

•	第8章では、xDB Replication Serverの構成と管理のためのグラフィカルユーザーインターフェイスの代替であるxDB Replication Serverコマンドラインインターフェイスについて説明します。

•	第9章では、データ検証ツールの構成と使用方法について説明します。

•	第10章は、トラブルシューティングのヒント、エラーメッセージのリスト、その原因と解決策、認定およびサポートされているデータベースサーバー製品、レプリケーションシステムで許可されているデータベースサーバーの組み合わせ、xDB Replication Server製品のアップグレード手順、およびその他の技術情報を含む付録です。

1.1 新機能

xDB Replication Serverバージョン6.1に次の機能が追加され、xDB Replication Serverバージョン6.2が作成されました。

•	xDB Replication Server製品をEnterpriseDB製品ライセンスキーに登録する必要はなくなりました。したがって、製品の登録に関連するすべてのコンポーネントが削除されました。削除されたコンポーネントは次のとおりです。1）xDB Replication Consoleの[ヘルプ]メニューからアクセスする[製品登録]ダイアログボックス、2） xDB Replication構成ファイルにあるlicense_keyパラメーター、3）xDB Replication Server CLI registerkeyコマンド。

•	PostgreSQLおよびAdvanced Serverバージョン10以降の 宣言型パーティション機能を使用して作成されたパーティションテーブルは、ログベースのシングルマスターまたはマルチマスター複製システムで複製できるようになりました。詳細については、セクション7.10を参照してください。

•	シングルマスターレプリケーションシステムでは、削除するテーブルが、外部キー制約で参照されていない子テーブルの親ではない限り、1つ以上の既存のサブスクリプションを持つパブリケーションからのテーブルの削除が許可されます。同様に削除されます。以前は、既存のサブスクリプションがある場合、シングルマスターレプリケーションシステムのパブリケーションからテーブルを削除できませんでした。詳細については、セクション 7.6.3.2を 参照してください 。

•	PostgreSQLバージョン11およびAdvanced Serverがサポートされるようになりました。詳細については、セクション 10.1.1を 参照してください 。

1.2 このガイドで使用される表記規則

このマニュアルでは、さまざまなコマンド、ステートメント、プログラム、例などの意味と使用法を明確にするために特定の表記規則を使用しています。このセクションでは、これらの規則の概要を説明します。

以下の説明では、 用語は、言語キーワード、ユーザー指定の値、リテラルなどの単語または単語のグループを指します。用語の正確な意味は、使用されるコンテキストによって異なります。

•	斜体フォントは、通常、初めて定義する文に新しい用語を導入します。

•	Fixed-width (mono-spaced) fontは、SQLコマンド、例で使用される特定のテーブル名と列名、プログラミング言語のキーワードなど、文字通り指定する必要がある用語に使用されます。たとえば、 SELECT * FROM emp;

•	Italic fixed-width fontは、ユーザーが実際の使用で値を置き換える必要がある用語に使用されます。たとえば、 DELETE FROM table_name ;

•	垂直パイプ|は、パイプの両側の用語間の選択を示します。角パイプ（オプションの選択肢）または中括弧（1つの必須の選択肢）内の2つ以上の代替用語を区切るために、垂直パイプが使用されます。

•	角カッコ[]は、囲まれた用語の1つを置換できることを示します。たとえば、 [ a | b ]は、「 a 」または「 b 」のいずれか、またはどちらも選択しないことを意味します。

•	中括弧{}は、囲まれた選択肢の1つを指定する必要があることを示します。たとえば、 { a | b }は、「 a 」または「 b 」のいずれか1つを指定する必要があることを意味します。

•	省略記号...は、前の用語が繰り返される可能性があることを示します。たとえば、 [ a | b ] ...は、「 baaba 」というシーケンスがあることを意味します。

1.3 このガイドで使用されるその他の規則

以下は、このドキュメント全体で使用されるその他の規則のリストです。

•	このガイドは、LinuxシステムとWindowsシステムの両方に適用されます。ディレクトリパスは、スラッシュ付きのLinux形式で表示されます。 Windowsシステムで作業する場合は、ドライブ文字の後にコロンを付けてディレクトリパスを開始し、スラッシュを円記号に置き換えます。

•	このドキュメントの情報の多くは、PostgreSQLとEDB Postgres Advanced Serverデータベースシステムに同じように適用されます。 Advanced Server という用語は、EDB Postgres Advanced Serverを指すために使用されます。 Postgresという用語は、PostgreSQLとAdvanced Serverの両方を総称するために使用されます。これら2つのデータベースシステムを区別する必要がある場合は、特定の名前、PostgreSQLまたはAdvanced Serverが使用されます。

•

PostgreSQLまたはAdvanced Server製品のインストールディレクトリパスは、 POSTGRES_INSTALL_HOME と呼ばれます。 PostgreSQL Linuxインストールの場合、デフォルトは/opt/PostgreSQL/ x .バージョン10以前のx 。それ以降のバージョンでは、PostgreSQLコミュニティパッケージを使用してください。 PostgreSQL Windowsインストールの場合、デフォルトはC:\Program Files\PostgreSQL\ x . x 。バージョン10以前の対話型インストーラーを使用して行われるAdvanced Server Linuxインストールの場合、これはデフォルトで/opt/PostgresPlus/ x . x ASまたは/opt/edb/as x . x 。 RPMパッケージを使用して行われるAdvanced Server Linuxインストールの場合、デフォルトは/usr/ppas- x . xまたは/usr/edb/as x . x 。 Advanced Server Windowsインストールの場合、デフォルトはC:\Program Files\PostgresPlus\ x . x ASまたはC:\Program Files\edb\as x . x 。製品のバージョン番号はxで表され. xまたはバージョン10以降の場合はxx 。

1.4 このガイドの使用方法

以下は、このガイドの使用目的に基づいて読むべき推奨セクションのリストです。

•	あなたはXDB Replication Serverの一般的な概要に興味がある場合、セクション読む 2.1 、 2.2 、および2.3 。

•	あなたはXDB Replication Serverのを使用してレプリケーションシステムの実装を計画している場合は、セクションを読んで 2.1 、 2.2 、 2.3 、および2.4 。

•	あなたは、インストール、設定、および単一マスター・レプリケーション用のXDB Replication Serverの使用を開始する準備ができている場合は、章読んで 3 、 4 、 5 、および7を 。

•	あなたは、インストール、設定、およびマルチマスターレプリケーションのためにXDB Replication Serverの使用を開始する準備ができている場合は、章読んで 3 、 4 、 6 、および7を 。

•	xDB Replication Serverの操作にグラフィカルユーザーインターフェイスの代わりにコマンドラインインターフェイスを使用することに関心がある場合は、第 8 章を参照してください 。

•	データ検証ツールの使用に興味がある場合は、第 9 章をお読みください 。

•	認定およびサポートされているデータベース製品のバージョンと構成の組み合わせについては、セクション 10.1をお 読みください 。

•	xDB Replication Serverの以前のバージョンからアップグレードする場合は、セクション 10.2をお 読みください 。

•	問題の解決策を見つけるのに支援が必要な場合は、セクション 10.3を 参照してください 。

2 概要

この章では、基本的なレプリケーションの用語と概念を定義し、xDB Replication Serverのコンポーネントとアーキテクチャの概要を示します。この章は、xDB Replication Serverを使用してレプリケーションシステムを実装するための設計ガイドラインと指示で終わります。

2.1 レプリケーションを使用する理由

データのレプリケーションは、複数の設定で同じデータを使用することが重要な組織のさまざまなユースケースで使用できます。これにより、ユーザーは複数の設定で信頼できる「実際の」結果をもたらす「実際の」データを操作できます。シングルマスターレプリケーションとマルチマスターレプリケーションの両方をサポートすることにより、xDB Replication Serverはサポートされている幅広いユースケースを利用できます。

シングルマスターレプリケーションのより一般的な使用法のいくつかは次のとおりです。

2.1.1 Offloading Reporting and Business Intelligence Queries

このユースケースでは、ユーザーは本番OLTPシステムからデータのすべてまたは一部を取得し、レポートクエリのサポートを唯一の目的とする別のデータベースに複製します。これには複数の利点があります。a）レポートの負荷がOLTPシステムから削除され、トランザクション処理のパフォーマンスが向上します。b）クエリのパフォーマンスもシステム上のトランザクションに従属せずに向上します。c）Oracleインストールでは、レポートサーバーの義務はAdvanced Serverなどの製品によって処理され、レポートサーバーのライセンスコストを削減します。

2.1.2 Using Warm Standby Servers

多くの組織がデータの可用性を改善したい場合、コスト効果の高いソリューションは多くの場合、ウォームスタンバイサーバーの使用です。これらは、本番システムで障害が発生した場合に迅速にオンラインにできるレプリケーションを介してオンラインシステムで最新に保たれたデータベースサーバーです。ウォームスタンバイサーバーは、スタンバイサーバーに適切に切り替えることで定期的なメンテナンスに使用することもできます。これにより、運用サーバーを定期的なメンテナンスのためにオフラインにできます。

2.1.3 Testing Systems in Parallel

多くの場合、アップグレードまたは新しいデータベースシステムへの移行には、リアルタイムでテストと結果の比較を可能にするために、古いシステムと新しいシステムが並行して稼働している必要があります。このユースケースではレプリケーションを使用でき、開発およびテスト環境で頻繁に使用されます。

2.1.4 Migrating Data

並列実行と同様に、ある種の「シード」操作でシステム間でデータが移行される可能性があります。この状況では、データをすばやくコピーすることにより、複製が非常に効果的になります。

マルチマスターレプリケーションを検討するいくつかの理由は次のとおりです。

2.1.5 Write Availability

シングルマスターレプリケーションでは、マスターデータベースのみが書き込みに使用できます。スレーブデータベースは、アプリケーションに対して読み取り専用です。レプリケートされたターゲットデータベースも書き込みアクセスに使用できる必要がある場合、シングルマスターレプリケーションで説明したのと同じユースケースでマルチマスターレプリケーションを使用できますが、スレーブへの書き込みアクセスという追加の利点があります。

2.1.6 Write Scalability

書き込み集中型アプリケーションでは、マルチマスターレプリケーションを使用すると、別々のホスト上の複数のデータベースサーバーを使用して、独自のマスターデータベース上で互いに独立して書き込みトランザクションを処理できます。その後、選択したスケジュールに従って、変更をマスターデータベース間で調整できます。

2.1.7 Localized Data Access

地理的に分散したアプリケーションでは、データベースへのローカルアクセスをクライアントのリージョンに提供できます。データベースサーバーを物理的にクライアントに近づけることで、データベースの待ち時間を短縮できます。マルチマスターレプリケーションを使用すると、地理的にクライアントグループに近いマスターデータベースのWAN接続ネットワークを使用しながら、マスターデータベース全体でデータの一貫性を維持できます。

2.2 レプリケーションの概念と定義

xDB Replication Serverは、レプリケーションシステムの実装を可能にするソフトウェア製品です。 複写システムは、その目的は、ある場所から別の場所へのデータのコピーを作成し、コピーされたデータを確保することである時間をかけてオリジナルと同じであり、ソフトウェアとハードウェアです。

xDB Replication Serverは、複製システムの概念をOracle、SQL Server、PostgreSQL、およびAdvanced Serverデータベース管理システムのテーブルに適用します。

以下のセクションでは、xDB Replication Serverについて説明するときに使用される特定の用語と概念を示します。

2.2.1 Comparison of Single-Master and Multi-Master Replication

xDB Replication Serverでサポートされるレプリケーションシステムには2つのモデルがあります。

•	シングルマスターレプリケーション（SMR）。テーブル行の変更（挿入、更新、および削除）は、指定されたマスターデータベースで発生することが許可されています。これらの変更は、1つ以上のスレーブデータベースのテーブルに複製されます。スレーブデータベースのレプリケートされたテーブルは、指定されたマスターデータベースを除き、変更を受け入れることができません。 （これは、マスターからスレーブへのレプリケーションとも呼ばれます。）

•	マルチマスターレプリケーション（MMR）。同じテーブル定義と初期行セットを持つテーブルが作成される2つ以上のデータベースが指定されます。テーブル行の変更（挿入、更新、削除）は、どのデータベースでも発生することが許可されています。特定のデータベースのテーブル行に対する変更は、他のすべてのデータベースの対応するテーブルに複製されます。

シングルマスター複製システムの場合、以下を含むさまざまな構成がサポートされます。

•	PostgreSQLとAdvanced Serverデータベース間のレプリケーション（どちらの方向の製品間でも）

•	レプリケーションオラクルからのPostgreSQL へ

•	OracleとAdvanced Serverの間のいずれかの方向の レプリケーション

•	SQL ServerとPostgreSQLの間のいずれかの方向の レプリケーション

•	SQL ServerとAdvanced Server間のいずれかの方向の レプリケーション

マルチマスターレプリケーションの場合、特定のマルチマスターレプリケーションシステムに参加するデータベースサーバーは同じタイプである必要があります。

•	PostgreSQLデータベースサーバー

•	PostgreSQL互換モードで動作するPostgreSQLデータベースサーバーおよびAdvanced Server

•	PostgreSQL互換モードで動作するアドバンストサーバー

•	Oracle互換モードで動作するアドバンストサーバー

注：特定のデータベースは、シングルマスター複製システムとマルチマスター複製システムの両方に同時に参加できません。

2.2.2 Publications and Subscriptions

xDB Replication Serverは、 publishおよびsubscribe と呼ばれるアーキテクチャを使用 します 。複製システムによるコピーに使用可能にするデータは、パブリケーションとして定義されます。そのデータのコピーを取得するには、そのパブリケーションを「サブスクライブ」する必要があります。サブスクライブの方法は、シングルマスター複製システムとマルチマスター複製システムではわずかに異なります。

xDB Replication Serverでは、 パブリケーションは、データベース内の名前付きのテーブルとビューのセットとして定義されます。パブリケーションを含むデータベースは、そのパブリケーションのパブリケーションデータベースと呼ばれます 。

シングルマスターレプリケーションシステムでは、xDB Replication Serverパブリケーションのコピーを取得するには、サブスクリプションを作成する必要があります。 xDB Replication Server サブスクリプションは、パブリケーションのコピー先であるデータベースへのパブリケーションの名前付き関連付けです。このデータベースは、 サブスクリプションデータベースと呼ばれます 。

シングルマスターレプリケーションシステムと同様に、マルチマスターレプリケーションシステムを作成するときは、最初にパブリケーションデータベースでパブリケーションを定義します。次に、このマルチマスターレプリケーションシステムに参加する1つ以上のデータベースを追加します。各データベースを追加すると、この複製システムに関連付けられます。マルチマスターレプリケーションシステムでは、明示的な名前付きサブスクリプションを作成しません。

シングルマスターレプリケーションシステムでは、xDB Replication Serverが次のプロセスのいずれかを開始および完了すると、 レプリケーションが発生すると言われます。1）最後のレプリケーションが発生してからパブリケーションの行に加えられた変更を、サブスクリプションデータベース（同期と呼ばれる）。または2）パブリケーションの行をサブスクリプションデータベースの空のテーブルにコピーします（スナップショットと呼ばれます）。スナップショットと同期の詳細については、セクション2.2.6を参照してください。

サブスクリプション・テーブルは、パブリケーション内のテーブルまたはビューに対応するから作成サブスクリプションデータベース内のテーブルです。

注：シングルマスターレプリケーションシステムでは、xDB Replication Serverはパブリケーションに含まれる各ビューのサブスクリプションデータベースにテーブルを作成します。

マルチマスタ複製システムでは、概念と定義データベースの任意の対の間に起こり得る1）同期（マスタノードとも呼ばれる）の複製に関与する： 複製は、以下の変更を加えたシングルマスタ複製システムとほぼ同じですシステム; 2）スナップショットは、マスター定義ノードとして指定されたパブリケーションデータベースから、他のマスターノードのいずれかに発生します。

次の図は、基本的なシングルマスター複製システムの例を示しています。

図2-1-あるデータベースのパブリケーションが別のデータベースのサブスクリプションに複製する

図2‑2-2つのサブスクリプションデータベースに複製するパブリケーション

図2‑3-1つのサブスクリプションデータベースに複製される2つのデータベースのパブリケーション

図2‑4 –カスケードレプリケーション：サブスクリプションとパブリケーションの両方で使用されるテーブル

前の図は、サブスクリプションのメンバーとして作成されたテーブルを、別のサブスクリプションに複製するパブリケーションで使用できることを示しています。このシナリオは、 カスケード複製 と呼ば れます。

次の図は、3つのマスターノードを持つマルチマスターレプリケーションシステムを示しています。

図2‑5 –マルチマスター複製システム

2.2.3 Single-Master (Master-to-Slave) Replication

xDB Replication Serverは 、シングルマスタレプリケーションシステムが実装されている場合に、 マスタからスレーブへのレプリケーションを実行します。パブリケーションがマスターであり、サブスクリプションがスレーブです。マスターとスレーブの関係では、変更はマスターからスレーブへの一方向にのみ伝播されます。

図2‑6 –シングルマスター（マスターからスレーブ）レプリケーション

通常、パブリケーションテーブルまたはサブスクリプションテーブルの定義は変更しないでください。パブリケーションテーブルにそのような変更が行われた場合、DDL変更レプリケーション機能がセクション7.8で説明されているように使用されない限り、それらはサブスクリプションに反映されません。 DDL変更レプリケーション機能を使用せずにテーブル定義を変更すると、将来のレプリケーション試行が失敗する可能性があります。

サブスクリプションテーブルの行を変更しないでください。そのような変更が行われた場合、それらはパブリケーションに反映されません。サブスクリプションテーブルの行に変更が加えられた場合、行がパブリケーションの対応する行と一致しなくなる可能性がかなり高くなります。また、将来のレプリケーションの試行が失敗するリスクもあります。

2.2.4 Multi-Master Replication

シングルマスター（マスターからスレーブ）レプリケーションモデルの代替として、xDB Replication Serverはマルチマスターレプリケーションをサポートします。

以下の定義は、マルチマスター複製システムを参照するときに使用されます。

マスターノードは 、マルチマスタ複製システムに参加しているデータベースです。

パブリケーションが最初に定義されるデータベース（マスターノード）は、 マスター定義ノード （MDN） として特別に指定され ます 。マスター定義ノードは常に1つしか存在できませんが、どのマスターノードがマスター定義ノードであるかを変更することは可能です。マスター定義ノードと、マスター定義ノードではない他のすべてのマスターノードを区別することが重要な場合、後者は非MDNノードと呼ばれます。

マスター定義ノードには次の意味があります。

•	パブリケーションは最初にマスター定義ノードで作成され、パブリケーションを構成するテーブルは、パブリケーションの定義時にマスター定義ノードとして指定されるデータベースに存在する必要があります。

•	パブリケーションは、マスター定義ノードからのスナップショットを使用して、最初に他のマスターノードに複製できます。

•	レプリケーションシステムに追加される後続の各マスターノードは、次のいずれかである必要があります。1）マスター定義ノードのパブリケーションテーブルと同じスキーマ修飾名を持つテーブルが含まれていない。または2）同じスキーマ修飾名を持つマスター定義ノードに存在するすべてのパブリケーションテーブル定義を含みます。最初のケースでは、マスターノードを追加するときに、マスター定義ノードからパブリケーションスキーマを複製するオプションを選択します。 2番目の場合、このオプションは選択しません。

•	マスターノードのテーブル行は、マスター定義ノードからリロードできます。マスターノードテーブルは切り捨てられ、マスター定義ノードからのスナップショットによって行が再ロードされます。

マルチマスターレプリケーションシステムが定義されると、マスターノード上のパブリケーションテーブルの行に対する変更（挿入、更新、削除）は、オンデマンドまたはスケジュールベースで他のすべてのマスターノードと同期されます。

通常、マスター定義ノードを含むどのマスターノードのテーブル定義も変更しないでください。このような変更が行われた場合、セクション7.8で説明されているDDL変更複製機能を使用して行われない限り、それらはマルチマスター複製システム内の他のノードに伝搬されません。 DDL変更レプリケーション機能を使用せずにテーブルを変更すると、将来のレプリケーションの試行が失敗するリスクがあります。

図2‑7-マルチマスターレプリケーションシステムでは、任意のマスターノードでテーブル行を更新できます

2.2.5 Asynchronous

xDB Replication Serverは、レプリケーションを 非同期的に 実行し ます 。レプリケーションを正常に実行するために、データベースをホストするシステムが常に継続的に実行されている必要はありません。 1つのシステムがオフラインになった場合、複製する保留中のデータがまだあると、オンラインに戻ったときに複製が再開されます。

さらに、複製システムのスケジュールを作成できます。 xDB Replication Serverは、割り当てられたスケジュールに従って定期的にレプリケーションを開始および実行します。これにより、レプリケーションシステムを無人で実行できます。スケジュールの作成方法については、セクション 7.2を参照してください 。

2.2.6 Snapshot and Synchronization Overview

xDB Replication Serverは、2種類のレプリケーションを実行します。これらの2つの主なタイプは、スナップショットレプリケーションと同期レプリケーションと呼ばれます。

いずれの方法でも、 ソーステーブルは、レプリケーションデータの 発信元のテーブル（シングルマスターレプリケーションシステムのパブリケーション、または変更がマルチマスターレプリケーションシステムの別のマスターノードにレプリケートされるマスターノード）を参照します。 。

ターゲット表は、ソース表から複製データを受信しているテーブル（シングルマスタ複製システム、またはマルチマスタ複製システム内の他のマスタノードから変更を受信したマスターノードでサブスクリプション・テーブル）です。

では スナップショットレプリケーション 、ターゲット表内のすべての既存の行は、データベース・システムの使用して削除されたTRUNCATEコマンドを。その後、テーブルはパブリケーションのソーステーブルから完全に再ロードされます。

同期複製 、最後の複製以降にソース・テーブル内の行にのみ変更（挿入、更新、および削除）は、ターゲット表に適用されます。

注： SQL TRUNCATEコマンドによって実行されたソーステーブルのすべての行を削除すると、同期レプリケーションのログベースの方法が使用されている場合にのみ、ターゲットテーブルへのレプリケーションが行われます。同期レプリケーションのトリガーベースの方法が使用されている場合、ソーステーブルでTRUNCATEコマンドを実行しても、ターゲットテーブルに効果が複製されません。トリガーベースの方法を使用する場合は、ソース表からターゲット表へのスナップショットを実行する必要があります。 （トリガーベースの方法とログベースの方法の違いは次のとおりです。）

同期レプリケーションは、トリガーベースの方法とログベースの方法の2つの異なる方法を使用して実装されます。

で トリガーベースの方法ソーステーブル内の行への変更は、行ベースのトリガの発火につながります。これらのトリガーは、シャドウテーブルの変更を記録します。その後、シャドウテーブルに記録された変更は、シャドウテーブルから定期的に抽出され、メモリ内データ構造に変換され、JDBCを使用して実行されるSQLステートメントによってターゲットテーブルに適用されます。トリガーベースの方法については、セクション2.2.9を参照してください。

では 、ログベースの方法 、ソース表の行への変更は、Postgresデータベース・サーバで使用可能な論理デコード機能により実現した非同期ストリーミングレプリケーションを使用して、先行書き込みログ・セグメント（WALファイル）から抽出されています。抽出された変更はメモリ内のデータ構造に変換され、JDBCを使用して実行されるSQLステートメントによってターゲットテーブルに適用されます。ログベースの方法については、セクション2.2.10を参照してください。

マルチマスター複製システムでは、すべてのマスターノードに蓄積された変更が他のすべてのマスターノードに複製される方法は、複製される変更を含むソースマスターノードによって識別されるグループで概念的に行われます。このプロセスと並列レプリケーションを使用したログベースの方法の改善については、 セクション 2.2.11を参照してください 。

シングルマスター複製システムでは、新しく作成されたサブスクリプションへの最初の複製は、常にスナップショットによって行われる必要があります。セクション 2.2.7で 説明されているように、パブリケーションがスナップショットのみのパブリケーションとして定義されていない場合、その後のレプリケーションはスナップショットまたは同期によって実行できます 。

マルチマスター複製システムでは、マスター定義ノードから新しく追加されたマスターノードへの最初の複製は、常にスナップショットによって行われる必要があります。マスターノード間の後続の複製は、同期によって発生します。ただし、マスター定義ノードから他のマスターノードへの後続のスナップショットを実行することは可能です。

2.2.7 Snapshot-Only Publications

パブリケーションがシングルマスターレプリケーションシステムで作成される場合、そのパブリケーションは スナップショットのみのパブリケーション として定義できます 。スナップショットのみのパブリケーションからのレプリケーションは、スナップショットレプリケーションメソッドを使用してのみ実行できます。スナップショットのみのパブリケーションでは、同期レプリケーションは許可されていません。

スナップショットのみのパブリケーションは、マルチマスターレプリケーションシステムでは作成できません。

スナップショットのみのパブリケーションを使用する利点については、 セクション 2.4.4を参照してください 。

2.2.8 Snapshot Replication

スナップショットレプリケーションでは、ソーステーブルからターゲットテーブルが完全に再ロードされます。データベースシステムの切り捨て操作は、ターゲットテーブルからすべての行を削除するために使用されます。

OracleおよびSQL Serverのみ： OracleおよびSQL Serverのターゲットテーブルは、 INSERTステートメントのJDBCバッチを使用してロードされます。

Postgresのみ：一般に、切り捨てとCOPYを使用すると、テーブル全体に対してSQL DELETEステートメントを実行してから、 INSERTステートメントのJDBCバッチを使用して行を追加する場合よりも一般に高速であるため、PostgresターゲットテーブルはJDBC COPYコマンドを使用してロードされます。 COPYコマンドが失敗すると、パブリケーションサーバーはINSERTステートメントのJDBCバッチを使用してスナップショットを再試行します。

（データベースの種類に関係なく）ターゲットテーブルに BYTEA 、 BLOB 、 CLOB などのラージオブジェクトデータ型が含まれている場合、 INSERTステートメントを使用してバッチごとに1行ずつロードされます。これは、潜在的に大きな行に起因するヒープスペースエラーを回避するためです。ロード時間は、バッチごとに複数の挿入を許可することで短縮できます。これは、セクション5.8.1で説明されている構成オプションlobBatchSize調整することで実行できます。

注： Advanced Serverは、データ型の多くのエイリアスをサポートしています。 BYTEA変換されるこのようなエイリアスは、ラージオブジェクトデータ型として扱われます。 Advanced Serverデータ型のリストについては、 『Oracle Developers Reference Databaseのデータベース互換性 』を参照してください。 （Advanced Serverバージョン9.5以前のバージョンのOracle開発者ガイドのデータベース互換性を参照してください。）

特定の状況では、特定のタイプのOracleパーティションテーブル用に作成された対応するPostgresターゲットテーブルは、継承されたテーブルのセットです。これらの場合、切り捨てられるのではなく、継承された子テーブルでSQL DELETEステートメントが使用されます。 Oracleパーティションテーブルの複製に関する追加情報については、セクション10.4.1.4を参照してください。

サーバー構成オプションを使用すると、スナップショットレプリケーションプロセスで、JDBC COPY 代わりにOracleデータベースリンクユーティリティを使用して 、OracleパブリケーションからPostgresターゲットテーブルにデータを取り込むことができます。 Oracleデータベースリンクにより、JDBC COPYよりもパフォーマンスが向上します。 Oracleデータベースリンクオプションの使用については、セクション5.8.1を参照してください。

スナップショットレプリケーションを最適化するためのさまざまな構成オプションについては、セクション 5.8.1を参照してください 。

2.2.9 Synchronization Replication with the Trigger-Based Method

シングルマスターレプリケーションシステムでパブリケーションが作成され、トリガーベースの方法で同期レプリケーションで使用される場合、パブリケーションサーバーは、各パブリケーションテーブルに挿入トリガー、更新トリガー、削除トリガーをインストールします。マルチマスターレプリケーションシステムでは、トリガーベースの方法を採用している各マスターノードの各レプリケートテーブルには、挿入トリガー、更新トリガー、削除トリガーがあります。

パブリケーションサーバーは、トリガーが作成されたソーステーブルごとにシャドウテーブルも作成します。 シャドウ・テーブルは、所与のソース・テーブルに加えられた変更（挿入、更新、および削除）を記録するXDBのReplication Serverで使用されるテーブルです。シャドウテーブルは、3種類の記録画像を記録します。ソーステーブルに挿入された各行について、シャドウテーブルは挿入された行の画像を記録します。ソーステーブルで更新される既存の各行について、シャドウテーブルは更新された行の変更後イメージを記録します。ソース表から削除された各行について、シャドー表は削除された行の主キー値を記録します。

注：マルチマスターレプリケーションシステムでは、更新の競合検出を実行するために、更新された行の変更前イメージもシャドウテーブルに格納されます。マルチマスターレプリケーションシステムでの競合検出については、セクション6.6を参照してください。

ソーステーブルで変更が行われるたびに、挿入、更新、または削除のいずれかのトリガーが実行されます。これらは行トリガーであるため、変更の影響を受ける各行に対してトリガーが実行されます。トリガーを実行するたびに、適切なタイプ（挿入、更新、または削除）の行が、対応するソーステーブルのシャドウテーブルに記録されます。

最後のレプリケーションが発生してからソーステーブルに加えられた変更は、SQL INSERT 、 UPDATE 、およびDELETEステートメントを使用してターゲットテーブルに適用されますが、ターゲットテーブルに対して実行される実際のSQLステートメントは、ソーステーブルに対して実行されたSQLステートメントとは異なります。

同期レプリケーションが発生すると、パブリケーションサーバーは 、ターゲットテーブルに対してSQLステートメントのJDBCバッチ（ トランザクションセット とも呼ばれます）を実行します 。バッチには、挿入操作を記録する各シャドウテーブル行のINSERTステートメント、更新操作を記録する各シャドウテーブル行のUPDATEステートメント、および削除操作を記録する各シャドウテーブル行のDELETEステートメントが含まれます。各バッチは1つのトランザクションで実行されます。

ターゲット表に適用されたシャドウ表の行は、xDBレプリケーション・コンソールでシャドウ表履歴として表示できます（ 7.4.3 項を参照 ）。

注：ソース表に対して実行された単一のSQLステートメントは、シャドウ表に多くの行を記録する可能性があり、したがって、ターゲット表に対して実行された多くのSQLステートメントになります。たとえば、単一のUPDATEステートメントがソーステーブルの10行に影響する場合、10行がシャドウテーブルに挿入されます（更新されたソーステーブルの各行に1行）。パブリケーションサーバーがターゲットテーブルに変更を適用すると、10個のUPDATEステートメントが実行されます。

注：効率を高めるために、ソーステーブルへの変更がそれぞれ多数の行に影響するSQLステートメントで構成されている場合、パブリケーションサーバーは準備されたSQLステートメントの使用を使用できます。準備されたSQL文の使用を制御する方法の指示、および同期レプリケーションを最適化するための他の様々な構成オプションの情報については、セクション5.8.2を参照してください。

2.2.10 Synchronization Replication with the Log-Based Method

PostgreSQL 9.4では、 論理デコード （ 論理複製または変更セット抽出とも呼ばれます）と呼ばれる機能が導入されました 。この機能は、先読みログセグメント（WALファイル）から読み取り可能な形式でデータ操作言語（DML）の変更を抽出する機能を提供します。

論理デコードの詳細については、次の場所にあるPostgreSQL Core Documentationを 参照してください 。

https://www.postgresql.org/docs/current/static/logicaldecoding.html

この機能の主な重要性は、トリガーベースの方法を使用する場合に発生するこれらのテーブルに対するオンライントランザクション処理レートに影響を与えることなく、パブリケーションテーブルへのデータ変更をキャプチャできることです。トリガーベースの方法では、データの変更が発生するたびに行レベルのトリガーが起動され、これらのデータの変更が一時的なストレージのシャドウテーブルに挿入されてから、変更がターゲットデータベースに適用されます。

したがって、論理デコードを使用してデータの変更を抽出すると、データベースサーバーのスループットとレプリケーションの待機時間を改善するのに役立ちます。

ただし、論理デコードインターフェイスは、特定のデータベース内のすべてのテーブルのストリームを変更することに注意してください。これには、パフォーマンスオーバーヘッドが伴う場合があります。たとえば、データベースに100個のテーブルが含まれており、ユーザーがこれらのテーブルの小さなサブセット、たとえば単一のパブリケーションで20個のテーブルのみを複製することに関心がある場合、論理デコードプロトコルは100個すべてのテーブルの変更をパブリケーションサーバーにストリーミングします。パブリケーションサーバーは、最終的に無関係な80個のテーブルの変更を除外します。ただし、これにより、レプリケーションシステムが必要としない追加の変更セットの負荷によってネットワークオーバーヘッドが発生します。

論理デコードを使用してxDB同期レプリケーション中にパブリケーションデータベースから変更を抽出することを、 ログベースの方法 と呼び ます 。

次のセクションでは、同期レプリケーションのログベースの方法の基本的な要件と概念について説明します。

2.2.10.1 Requirements and Restrictions

以下は、シングルマスターまたはマルチマスター複製システムのデータベースにログベースの方法を使用する場合の一般的な要件と制限です。

•	トリガーベースの方法またはログベースの方法の選択は、パブリケーションデータベースのみに適用される特性です。シングルマスター複製システムのマスターデータベース（セクション 5.2.2を 参照 ）またはマルチマスター複製システムのマスター定義ノード（セクション6.2.2を参照）を定義するときに選択します 。

•	論理デコード機能、つまりログベースの方法は、PostgreSQLバージョン9.4以降でサポートされています。したがって、パブリケーションデータベースにログベースの方法を使用するには、そのパブリケーションデータベースがPostgreSQLバージョン9.4以降、またはAdvanced Serverバージョン9.4以降で実行されている必要があります。

•	シングルマスターレプリケーションシステムでは、マスターデータベースがトリガーベースの方法を使用するか、ログベースの方法を使用するかは、セクション 10.1で 説明されているサブスクリプションデータベースの選択ルールに追加の影響を与えません 。たとえば、masterデータベースにログベースの方法が選択されている場合でも、サブスクリプションデータベースは、Postgresバージョン9.4、およびサポートされている以前のバージョンのPostgres、および10.1項で説明したOracleまたはSQL Serverで実行されている可能性があります。

•	シングルマスターレプリケーションシステムでは、マスターデータベースに1つ以上のパブリケーション（つまり、レプリケーション用のテーブルの名前付きセット）が含まれる場合があります。これは、トリガーベースの方法またはログベースの方法のいずれかを使用するマスターデータベースに適用できます。

•	一部のマスターデータベースがトリガーベースの方法を使用し、他のマスターデータベースがログベースの方法を使用するパブリケーションサーバーで複数のシングルマスターレプリケーションシステムを実行することは許可されています。

•	マルチマスター複製システムでは、マスター定義ノードでのトリガーベースの方法またはログベースの方法の選択により、他のすべてのマスターノードの方法が決まります。つまり、マスター定義ノードにトリガーベースの方法が選択されている場合、他のすべてのマスターノードはトリガーベースの方法を使用します。マスター定義ノードにログベースの方法が選択されている場合、他のすべてのマスターノードはログベースの方法を使用します。

•	前の箇条書きで説明した制限の結果として、マルチマスターレプリケーションシステムにログベースの方法を使用するには、システムのすべてのマスターノードがPostgresバージョン9.4以降で実行されている必要があります。そのようなPostgresデータベースクラスターは、ログベースの方法で論理デコードを使用するように構成する必要があります。

データベースに対してログベースの方法を選択すると、そのデータベースを含むPostgresデータベースクラスターの構成に影響します。

Postgresデータベースサーバーで実行されているパブリケーションデータベースでログベースの方法を使用する場合、そのPostgresデータベースサーバーの構成ファイル postgresql.confで次の構成パラメーター設定が必要です 。

•	wal_level。 logical設定しlogical 。

•	max_wal_senders。同時接続の最大数（つまり、同時に実行されているWAL送信プロセスの最大数）を指定します。ログベースの方法を使用するこのデータベースサーバー上のシングルマスターレプリケーションシステムのマスターデータベースとマルチマスターレプリケーションシステムのマスターノードの合計数に、少なくとも設定します。

•

max_replication_slots。複製スロットの最大数を指定します。データベースサーバーがシングルマスターレプリケーションシステムとマルチマスターレプリケーションシステムの両方をサポートする場合、 max_replication_slotsは両方のレプリケーションシステムの要件の合計に少なくとも設定する必要があります。 SMRシステムをサポートするための最小要件は、ログベースの方法を使用するシングルマスターレプリケーションシステムのマスターデータベースの総数です。 MMRシステムをサポートするための最小要件は、マルチマスターレプリケーションシステム内のマスターノードの総数に、このデータベースサーバーにあるマスターノードの数を掛けたものです。詳細については、セクション2.2.10.4を参照してください。

•	track_commit_timestamp。 on設定onます。この構成パラメーターは、バージョン9.5のPostgresデータベースサーバーにのみ適用されます。詳細については、セクション6.6.1を参照してください。

シングルマスター複製システムのこれらのパラメーターの設定については、セクション 5.1.2 も参照してください 。マルチマスター複製システムについては、セクション6.1.2を参照してください。

さらに 、Postgresデータベースサーバーの pg_hba.conf構成ファイルには、データベースサーバーで実行されているログベースの方法を使用して各データベースのREPLICATIONアクセスを許可するエントリが含まれている必要があります。 xDBレプリケーションコンソールを使用してパブリケーションデータベース定義を作成するときに指定したパブリケーションデータベースユーザー（シングルマスターレプリケーションシステムについてはセクション5.2.2 、マルチマスターレプリケーションシステムについてはセクション6.2.2を参照）にアクセスを許可する必要があります。 xDB Replication Serverコマンドラインインターフェイス（CLI）（セクション8.3.6を参照）。

シングルマスター複製システムのREPLICATIONアクセスの設定については、セクション 5.1.6.3を参照してください 。マルチマスター複製システムについては、セクション6.1.5を参照してください。

ログベースの方法に特に適用可能なパブリケーションサーバー構成ファイルの構成オプションについては、セクション 10.4.1.15を 参照してください 。

2.2.10.2 Logical Replication Slots

パブリケーションデータベースでログベースの方法を使用する場合、基礎となる論理デコードフレームワークは、論理レプリケーションスロットを使用してデータ変更（ チェンジセットストリーム ）を公開します 。

論理複製スロットチェンジストリームを表し、単一のデータベースに適用されます。 xDB Replication Serverは、 xdb_ dboid _ pubid形式で作成する各論理レプリケーションスロットにスロット名と呼ばれる一意の識別子を割り当てますdboidはパブリケーションデータベースオブジェクト識別子（OID）で、 pubidはxDB Replicationによって割り当てられたパブリケーションIDです。サーバ。すべてのスロット名は、Postgresデータベースクラスター内で一意です。

したがって、ログベースの方法を使用する各シングルマスターレプリケーションシステムでは、そのような各システムのパブリケーションデータベースにレプリケーションスロットが必要です。

ログベースの方法を使用するマルチマスターレプリケーションシステムの場合、各マスターノードにはレプリケーションスロットが必要です。

データベースサーバーに許可されるレプリケーションスロットの最大数は 、 postgresql.confファイルのmax_replication_slots構成パラメーターによって制御されます。したがって、この構成パラメーターは、データベースサーバー上で実行されるシングルマスターレプリケーションシステムのログベースの方法で定義されたすべてのパブリケーションデータベースと、定義されたマルチマスターレプリケーションシステムのすべてのマスターノードを説明するのに十分な値に設定する必要がありますデータベースサーバーで実行されているログベースの方法で。複製元の使用をサポートするには、追加の複製スロットが必要です（セクションを参照 2.2.10.4 ）。シングルマスター複製システムの構成パラメーターに関する追加情報については、セクション5.1.2を参照してください。マルチマスター複製システムについては、セクション6.1.2を参照してください。

2.2.10.3 Streaming Replication with the WAL Sender Process

変更セットストリームは 、ストリーミングレプリケーションプロトコルを使用して、 WAL送信者プロセス （ walsender ） によってxDBパブリケーションサーバーにアクセスできます。

xDBパブリケーションサーバーは、変更が継続的にストリーミングされるwalsenderインターフェイスを使用して接続します。連続ストリーミングにより、変更を明示的にポーリングする必要がなくなります。

以下は、ログベースの方法を使用した基本的な同期手順です。

1。	データベースサーバーへのストリーミングレプリケーション接続が、 libpqを使用して開かれ、 walsender通信チャネルが確立されます。

2。	個別のスレッドを使用して、 walsenderインターフェイスを介してストリーミングされるデータの変更を監視します。

3。	データの変更が利用可能になると、それらは変換されてメモリ内キャッシュに入力されます。

4。	次のスケジュールされた間隔で 、トリガーベースのセクション2.2.9で説明したのと同じ方法で、 メモリ内のキャッシュされたデータの変更がSQLステートメントのJDBCバッチ（ トランザクションセット と呼ばれ ます ）の各ターゲットデータベースに適用されます方法。 1つ以上のターゲットデータベースサーバーにアクセスできない場合、データの変更は、パブリケーションサーバーを実行しているホスト上のローカルファイルに保存されます。インメモリキャッシュとデータ永続性については、セクション2.2.10.5を参照してください。

5。	WALセグメントのログシーケンス番号（LSN）の値は、最後に複製されたトランザクションに基づいて適用された変更の最後のセットを識別します。データベースサーバーに対して更新が確認されます。

6。	適用されたデータの変更は、メモリ内キャッシュから消去されます。

7。	手順3〜6が繰り返されます。

注：ソーステーブルに対して実行された単一のSQLステートメントは、変更セットストリームで多くの行が変更されて返される可能性があるため、ターゲットテーブルに対して実行された多くのSQLステートメントがあります。たとえば、単一のUPDATEステートメントがソーステーブルの10行に影響する場合、 UPDATEれたソーステーブルの行ごとに1行、変更セットストリームに10行が返されます。パブリケーションサーバーがターゲットテーブルに変更を適用すると、10個のUPDATEステートメントが実行されます。

2.2.10.4 Replication Origin

Postgresバージョン9.5から、 複製オリジン と呼ばれる機能が論理デコードフレームワークに導入されました。複製元により、アプリケーションは論理デコードセッションの特定の側面を識別、ラベル付け、およびマークできます。

複製元については、次の場所にあるPostgreSQL Core Documentationを 参照してください 。

https://www.postgresql.org/docs/current/static/replication-origins.html

ログベースの同期複製方法の場合、マスターノードがPostgresバージョン9.5以降で実行されている場合、これによりパフォーマンスが向上します。

前述のように、ログベースの方法では、WALファイルを使用してパブリケーションテーブルに適用された変更を取得します。 walsenderインターフェースを介して変更を取得した後、パブリケーションサーバーは、SQLステートメントのJDBCバッチで構成されるトランザクションセットを使用して、他のマスターノードに変更セットを適用します。これらの変更が他のターゲットマスターノードのテーブルに適用されると、同じ変更がターゲットマスターノードをホストする各データベースサーバーのWALファイルにも記録されます。

これらの冗長または「再生」された変更は、パブリケーションサーバーが受信する変更セットストリームに含まれます。再生されたこれらの変更は、JDBCバッチを介してターゲットテーブルにすでに適用されているすべての変更の複製であるため、無視して適用しないでください。

変更をリプレイすると、そのような変更はすべてデータベースサーバーからパブリケーションサーバーにネットワーク経由で送信されるため、パフォーマンスオーバーヘッドが発生し、パブリケーションサーバーはそのような冗長な変更を破棄する必要があります。

レプリケーションオリジン機能を使用すると、パブリケーションサーバーは論理デコードセッションを設定できるため、これらの再生された変更は、ネットワーク経由でパブリケーションサーバーに送信されるチェンジセットストリームに含まれないため、このパフォーマンスオーバーヘッドがなくなります。

複製元が使用される条件は次のとおりです。

•	複製元は、マルチマスター複製システムにのみ適用され、シングルマスター複製システムには適用されません。

•	複製元は、Postgresバージョン9.5以降からのみ、再生された変更のストリーミングを排除します。再生された変更は、Postgresバージョン9.4からの変更セットストリームに含まれていますが、パブリケーションサーバーによって破棄されます。したがって、Postgresバージョン9.4と9.5の両方で構成されるマルチマスター複製システムは、9.5データベースサーバーの複製元の利点を利用します。

•	max_replication_slots構成パラメータは、パブリケーションサーバは、複製起点のための追加のレプリケーション・スロットを作成できることを保証するために一定の最低レベルに設定しなければなりません。

各マスターノードデータベースには、変更セットストリームに使用される複製スロットに加えて、複製スロットの追加数が必要です。複製オリジンの使用をサポートするために、他のすべてのマスターノードに対応する追加スロットが1つ必要です。したがって、各マスターノードについて、必要な複製スロットの総数は、MMRシステム全体のマスターノードの総数に等しくなります。

したがって、特定のデータベースサーバー（つまり、マスターノードデータベースを含むPostgresデータベースクラスター）の場合、必要な複製スロットの合計数は、MMRシステム全体のマスターノードの合計数にマスターノードデータベースの数を掛けた値に等しくなります。指定されたデータベースクラスター内に存在します。

たとえば、次のように3つのデータベースクラスターを使用する6ノードマルチマスターレプリケーションシステムの使用を想定します。

•	データベースクラスター＃1には、3つのマスターノードデータベースが含まれています。

•	データベースクラスター＃2には、2つのマスターノードデータベースが含まれています。

•	データベースクラスター＃3には、1つのマスターノードデータベースが含まれています。

マスターノードの総数は6です。各データベースクラスターのマスターノードデータベースの数に6を max_replication_slots 、そのデータベースクラスターのmax_replication_slots 必要な最小設定を与えます。

以下の表に示すために必要な、最低限の設定 max_replication_slotsならびにmax_wal_senders 。

表2-1 –複製元の構成パラメーターの設定

Postgres Database Server	max_wal_senders	max_replication_slots
Cluster #1 (3 master nodes)	3	18
Cluster #2 (2 master nodes)	2	12
Cluster #3 (1 master node)	1	6

場合 max_replication_slotsパラメータが十分に高い値に設定されていない、同期レプリケーションはまだ成功しますが、複製起点のパフォーマンスの利点なし。

そのような場合、パブリケーションサーバーのログファイルには次の警告が含まれます。

WARNING: Failed to setup replication origin xdb_mmrnode_c_emp_pub_6. Reason: ERROR: could not find free replication state slot for replication origin with OID 4

Hint: Increase max_replication_slots and try again.

次の例は、単一のデータベースクラスターで実行されている3マスターノードシステムのレプリケーションスロット情報の一部を示しています。

以下は、複製スロットの最大許容数を示しています。

SHOW max_replication_slots;

 

max_replication_slots

-----------------------

9

(1 row)

この数は、現在割り当てられている複製スロットと複製元の数よりも十分に大きくする必要があります。

以下に複製スロットを表示します。

SELECT slot_name, slot_type, database, active FROM pg_replication_slots ORDER BY 1;

 

slot_name | slot_type | database | active

-------------+-----------+-----------+--------

xdb_47877_5 | logical | mmrnode_a | t

xdb_47878_5 | logical | mmrnode_b | t

xdb_47879_5 | logical | mmrnode_c | t

(3 rows)

以下に複製元を示します。

SELECT * FROM pg_replication_origin ORDER BY 2;

 

roident | roname

---------+--------------------------

5 | xdb_mmrnode_a_emp_pub_39

2 | xdb_mmrnode_a_emp_pub_6

1 | xdb_mmrnode_b_emp_pub_1

6 | xdb_mmrnode_b_emp_pub_39

3 | xdb_mmrnode_c_emp_pub_1

4 | xdb_mmrnode_c_emp_pub_6

(6 rows)

複製起点名形式で割り当てられ xdb_ srcdbname _ pubname _ remotedbid srcdbnameソースデータベースの名前であり、 pubnameパブリケーション名、 remotedbidリモート・データベースのパブリケーションデータベースのIDです。

パブリケーションサーバーが実行されている場合、レプリケーションスロットはアクティブな状態です。パブリケーションサーバーがシャットダウンすると、レプリケーションスロットは非アクティブになります。

xDB Replication ConsoleまたはxDB Replication Server CLIを使用して、対応するマスターノードがマルチマスターレプリケーションシステムから削除されると、レプリケーションスロットとレプリケーションオリジンセッションはデータベースクラスターから削除されます。

レプリケーションスロットが必要なときに適切に削除されない状況が発生した場合、手動で削除する手順については、セクション 10.3.4.4を参照してください 。

2.2.10.5 In-Memory Caching and Persistence

データの変更は、データレプリケーションプロセスを最適化するためにフェッチされ、メモリバッファに保存されます。これにより、複数のターゲットデータベースがある場合に、データベースサーバーから同じ変更セットを繰り返しフェッチすることに伴うオーバーヘッドを回避できます。

レプリケーションイベント中にすべてのターゲットデータベースにアクセスでき、使用可能なキャッシュ内にデータが収まる限り、このアプローチで十分です。

ただし、ネットワーク接続の問題、サーバーのダウンタイムなどのために1つ以上のターゲットデータベースが使用できない場合、ターゲットデータベースがソースデータベースと同期できるようになったときに、後で取得できるようにメモリ内データの変更を保持する必要があります。

xDB Replication Serverアーキテクチャは、Java オブジェクトのシリアル化を利用して 、データのメモリ内状態を保持します。オブジェクトのシリアル化とは、オブジェクトデータやその他の関連情報を一連のバイトに変換し、ファイルに保存できるようにすることです。

以下は、メモリ内のデータを永続ストレージに追い出すことができる例です。

•	次のレプリケーションイベントが発生する前に、メモリ内キャッシュはデータの変更でいっぱいになり、新しい一連の変更に対応するために削除する必要があります。

•	レプリケーションシステムには、複数のターゲットデータベースがあります。同期イベント中に、キャッシュで使用可能なすべての変更がターゲットデータベースの一部に正常に適用されます。ただし、1つ以上の他のターゲットデータベースにアクセスできません。アクセスできないデータベースが利用可能になったときにこれらの変更をリロードして適用できるように、メモリに保持されているすべての適用済みの変更を永続化して保持する必要があります。

キャッシュサイズは、xDBスタートアップ構成ファイルのJAVA_HEAP_SIZEパラメーターの-Xmx nnn m設定によってパブリケーションサーバーに構成されたヒープサイズに対応します。 xDBスタートアップコンフィギュレーションファイルの詳細については、セクション2.3.1.4を参照してください。

ヒープサイズの値を増やし、数秒ごとなどのより頻繁な同期間隔を定義することにより、永続性のI / Oオーバーヘッドを最小限に抑えることができます。レプリケーションスケジュールの設定については、セクション 7.2を参照してください 。

データの変更は、パブリケーションサーバーを実行しているホスト上のローカルファイルに保持されます。ファイルはディレクトリ XDB_HOME /xdata 保存されます 。

永続化が発生するたびに、新しいファイルが作成されます。ファイルが処理された後、それらは定期的にディスクから削除されます。

2.2.11 Multi-Master Parallel Replication

マルチマスターレプリケーションシステムの場合、前のセクションで説明した同期方法（トリガーベースの方法（セクション 2.2.9を 参照 ）またはログベースの方法（セクション2.2.10を参照）。

単一の複製イベントが完了したと見なされるには、構成された同期方法によって、前の複製イベントが他のすべてのマスターノードに正常に複製される必要があるため、すべてのマスターノードで発生したトランザクションが発生します。

これは、一連の複数のレプリケーションセットで構成され、それぞれがソースマスターノードとして機能するマスターノードによって識別され、ターゲットマスターノードとして機能する他のすべてのマスターノードにレプリケーションする必要があるトランザクションが含まれます。したがって、 n個のマスターノードで構成されるマルチマスターレプリケーションシステムの n 、 nそのようなレプリケーションセットがあり、それぞれがソースとして機能する異なるマスターノードを持ちます。

xDB Replication Serverバージョン5.0でのマルチマスターレプリケーションシステムの初期サポート以来、このような一連の複数のレプリケーションセットは常に厳密なシリアル方式で開始されていました。つまり、ソースマスターノードからすべてのターゲットマスターノードへのトランザクションレプリケーションは、次のマスターノードから他のすべてのターゲットマスターノードへのトランザクションレプリケーションの開始前に完了する必要があります。

たとえば、マスターノードA、マスターノードB、およびマスターノードCで構成される3つのマスターノードシステムを考えます。

アプリケーションが3つすべてのマスターノードのテーブルにトランザクションを適用し、xDB Replication Console、xDB Replication Server CLIコマンド、またはスケジュールされたレプリケーションのいずれかによりオンデマンドで同期レプリケーションイベントが開始された場合、トランザクションは次の方法でレプリケートされます：

1。	マスターノードAで行われたトランザクションは、マスターノードBとマスターノードCに複製されます。

2。	手順1が完了すると、マスターノードBで行われたトランザクションがマスターノードAとマスターノードCに複製されます。

3。	ステップ2が完了すると、マスターノードCで行われたトランザクションがマスターノードAとマスターノードBに複製されます。

待ち時間 全体と呼ばれる複製イベント全体を完了する時間は、基本的に各マスターノードがソースとして機能する複製時間の合計です（つまり、ステップ1、2、および3の時間の合計） 。

ログベースの方法では、ソースとして機能する特定のマスターノードからの各レプリケーションセットが、他のマスターノードが機能する他のすべてのレプリケーションセットと同時に実行および実行される 並列レプリケーション の実装により、この待ち時間が短縮されました。ソース。

したがって、マスターノードからのレプリケーションセットは、他のノードが完了するまで待機せずに開始できるため、ステップ1、2、および3はすべて、次々にではなく同時に実行されます。

並列レプリケーションは、ログベースの方法にのみ適用され、トリガーベースの方法には適用されないことに注意してください 。

ログベースのMMRシステムで並列レプリケーションの使用を有効にするために必要な構成設定はありません。

注：並列レプリケーションに加えて、特定のマスターノードから他のすべてのマスターノードへの（つまり、単一のレプリケーションセットのコンテキスト内での）レプリケーションの最適化は、複数のスレッドを使用して実装されています。これは、 並列同期と呼ばれます。並列同期は、トリガーベースの方法とログベースの方法の両方に適用されます。パラレル同期の詳細は、 5.8.2.2項を参照してください。

2.2.12 Table Filters

テーブルフィルターは、シングルマスターレプリケーションシステムのパブリケーションデータベースからのサブスクリプションへのレプリケーション中、またはマルチマスターレプリケーションシステムのマスターノード間に含まれるパブリケーションテーブルまたはビューの行の選択基準を指定します。選択基準を満たさない行は、これらのテーブルフィルターが有効になっているサブスクリプションまたはマスターノードへのレプリケーションから除外されます。

2.2.12.1 Implementing Table Filters

テーブルフィルタの実装は2つの部分から成るプロセスです。まず、使用可能なテーブルフィルターのセットを定義する必要があります。これは、SQL WHERE句の形式で表される選択されたパブリケーションテーブルまたはビューに適用可能な特定の名前付きルールを定義することにより、パブリケーションの作成プロセス中に実行できます 。

使用可能なテーブルフィルターのセットを定義したら、それらの特定のターゲットテーブルへのレプリケーション中にフィルタリングが発生するシングルマスターレプリケーションシステムのサブスクリプションテーブルまたはマルチマスターレプリケーションシステムのマスターノードテーブルでのみ有効にする必要があります。 。サブスクリプションまたはマスターノードのテーブルでフィルターが特に有効になっていない場合、ターゲットサブスクリプションテーブルまたはマスターノードテーブルへのレプリケーション中にフィルター処理は行われません。

フィルタールールの追加、フィルタールールの削除、または既存のフィルタールールの変更によってフィルター条件が変更されたテーブルを含むサブスクリプションまたはマスターノードに対して、スナップショットレプリケーションを実行することを強くお勧めします。

スナップショットにより、サブスクリプションテーブルまたはマスターノードテーブルの内容が、更新されたフィルター条件と一致することが保証されます。

注（MMRのみ）：マルチマスター複製システムでテーブルフィルターを使用する場合、スナップショットのテーブルコンテンツのソースを提供するマスター定義ノードには、他のマスターノードに含まれるすべてのデータのスーパーセットが含まれている必要がありますマルチマスター複製システムの。これにより、スナップショットのターゲットは、他のマスターノードで有効になっているフィルタリング基準を満たすすべてのデータを確実に受信します。

逆に、マスター定義ノードに他のマスターノードに含まれるすべてのデータのサブセットのみが含まれている場合、別のマスターノードへのスナップショットでは、そのターゲットマスターノードに必要なデータの完全なセットが得られない場合があります。

2.2.12.2 Effects of Table Filtering

テーブルで有効になっているフィルターは、xDB Replication Serverによってそのテーブルをターゲットにしたスナップショットまたは同期レプリケーションの結果にのみ影響します。フィルタリングは、SQLコマンドラインユーティリティなどの外部ユーザーアプリケーションによってターゲットテーブルに直接加えられた変更には影響しません。

フィルタリングは、対象となるフィルタリングされたテーブルに対して次の影響を及ぼします。

注：以下の説明では、 結果セットは、そのテーブルで実行されたUPDATEまたはDELETEステートメントの選択基準を満たすテーブル内の行のセットを指します。

スナップショットレプリケーションでは、行がフィルター条件を満たしている場合、スナップショットのソーステーブルの行がターゲットテーブルに挿入されます。それ以外の場合、行はターゲット表への挿入から除外されます。

場合 INSERTステートメントは、同期複製に続いて、ソーステーブルに実行され、行は、行満たすフィルタリング基準場合、同期の対象テーブルに挿入されます。それ以外の場合、行はターゲット表への挿入から除外されます。

場合 UPDATEステートメントは、同期複製に続いて、ソーステーブルに実行され、 UPDATE次のようにソース表の結果セットは、同期の対象テーブル上のアクションを決定します。

•	結果セット内の行に同じ主キー値を持つターゲットテーブル内の対応する行がなく、結果セット内の更新された行がフィルタリング基準を満たす場合、その行はターゲットテーブルに挿入されます。 （つまり、ソーステーブルの更新された行がフィルタリング基準を満たすようになったため、以前はターゲットテーブルに存在しなかった行が追加されます。）

•	結果セットの行に同じプライマリキー値を持つターゲットテーブルの対応する行があり、結果セットの更新された行がフィルタリング基準を満たす場合、ターゲットテーブルの行はそれに応じて更新されます。 （つまり、更新は、更新後もフィルタリング基準を満たしているターゲットテーブル内の既存の一致する行に適用されます。）

•	結果セット内の行に同じプライマリキー値を持つターゲットテーブル内の対応する行があり、結果セット内の更新された行がフィルタリング基準を満たさなくなった場合、ターゲットテーブル内の対応する行は削除されます。 （つまり、ターゲットテーブル内の既存の一致する行は、更新後にフィルター条件を満たさなくなるため、行はターゲットテーブルから削除されます。）

場合 DELETEステートメントは、同期複製に続いて、ソーステーブルに実行され、 DELETE次のようにソース表の結果セットは、同期の対象テーブル上のアクションを決定します。

•	結果セット内の行に、同じプライマリキー値を持つターゲットテーブル内の対応する行がある場合、そのプライマリキー値を持つ行はターゲットテーブルから削除されます。 （つまり、ターゲットテーブル内の既存の一致する行が削除されます。）

•	結果セットの行に、同じプライマリキー値を持つ対応する行がターゲットテーブルにない場合、その行のターゲットテーブルでアクションは実行されません。 （つまり、ターゲット表には一致する既存の行がないため、ターゲット表から削除する行はありません。）

したがって、ソーステーブルのトランザクションが INSERT 、 UPDATE 、またはDELETEステートメントであるかどうかに関係なく 、テーブルフィルターの目的は、ターゲットテーブル内のすべての行がフィルタールールを満たすことです。

2.2.12.3 Table Settings and Restrictions for Table Filters

このセクションでは、特定のテーブル設定と、テーブルフィルターの使用に関する制限を示します。

ログベースのレプリケーションシステムでのフィルタリングのためのレプリカIDENTITY設定

同期レプリケーションのログベースの方法を使用するレプリケーションシステムの場合、フィルタを定義するパブリケーションテーブルの REPLICA IDENTITYオプションをFULL設定する必要があります。

注意：このREPLICA IDENTITY FULL設定は、シングルマスターのスナップショットのみのパブリケーションの表には必要ありません。スナップショットのみのパブリケーションの詳細は、 2.2.7項を参照してください。

この設定は 、次のようにALTER TABLEコマンドを使用して行われます。

ALTER TABLE schema 。 table_name REPLICA IDENTITY FULL

詳細については、次の場所にあるPostgreSQL Core Documentation の ALTER TABLE SQLコマンドを参照してください 。

https://www.postgresql.org/docs/current/static/sql-altertable.html

たとえば、 edb.dept という名前のパブリケーションテーブルの場合、次のALTER TABLEコマンドを使用します。

ALTER TABLE edb.dept REPLICA IDENTITY FULL;

REPLICA IDENTITY設定は、使用してPSQLユーティリティで表示することができます\d+コマンドを：

edb=# \d+ edb.dept

Table "edb.dept"

Column | Type | Modifiers | Storage | Stats target | Description

--------+-----------------------+-----------+----------+--------------+-------------

deptno | numeric(2,0) | not null | main | |

dname | character varying(14) | | extended | |

loc | character varying(13) | | extended | |

Indexes:

"dept_pk" PRIMARY KEY, btree (deptno)

"dept_dname_uq" UNIQUE CONSTRAINT, btree (dname)

Referenced by:

TABLE "emp" CONSTRAINT "emp_ref_dept_fk" FOREIGN KEY (deptno) REFERENCES dept(deptno)

TABLE "jobhist" CONSTRAINT "jobhist_ref_dept_fk" FOREIGN KEY (deptno) REFERENCES dept(deptno) ON DELETE SET NULL

Replica Identity: FULL

REPLICA IDENTITY FULL設定は、ログ・ベースのレプリケーション・システムの以下のデータベース内のテーブルの上に必要です。

•	シングルマスターレプリケーションシステムでは、テーブルフィルターはmasterデータベースで定義されます。したがって、フィルター定義を必要とするmasterデータベースのパブリケーションテーブルは 、パブリケーションがスナップショットのみのパブリケーションでない場合にのみ、 REPLICA IDENTITY FULL設定に変更する必要があります 。スナップショットのみのパブリケーションについては、セクション2.2.7を参照してください。

•	マルチマスターレプリケーションシステムでは、テーブルフィルターはマスター定義ノードで定義されます。したがって、フィルター定義を必要とするマスター定義ノードのパブリケーションテーブルは、 REPLICA IDENTITY FULL設定に変更する必要があります 。

•	マルチマスターレプリケーションシステムでは、トランザクションがそれらの非MDNノードを対象とすることが予想される場合を除き、非MDNノードのテーブルの REPLICA IDENTITYオプションをFULL設定しないでください。他のマスターノード。

ソーステーブルの REPLICA IDENTITY FULL設定により、ソーステーブルの特定のタイプのトランザクションが、フィルターが有効になっているターゲットテーブルに適切に更新されます。

注：テーブルのフィルタリング要件に加えて、xDB Replication Serverの他の理由により、パブリケーションテーブルでREPLICA IDENTITY FULL設定が必要になる場合があります。追加の要件については、セクション6.6.1を参照してください。

データ型のフィルタリング制限

テーブルフィルターは、バイナリデータ型の列ではサポートされていません。バイナリデータ型は、Postgresデータ型 BYTEAです。さらに、テーブルフィルタは、データ型がBINARY 、 VARBINARY 、 BLOB 、 LONG RAW 、およびRAW Advanced Server列ではサポートされていません。これらはBYTEAデータ型のエイリアス名であるためです。

2.2.12.4 Roadmap for Further Instructions

テーブルフィルタリングの実装に関する具体的な詳細は、シングルマスターレプリケーションシステムを使用しているか、マルチマスターレプリケーションシステムを使用しているかによって異なります。以下は、レプリケーションシステムの各タイプに関連するセクションへのロードマップです。

シングルマスターレプリケーションシステムでテーブルフィルターを使用するには、次のセクションを参照してください。

•	サブスクリプションの選択的な有効化に使用できるテーブルフィルターの初期セットの定義については、 セクション 5.2.3

•	新しく作成されたサブスクリプションで利用可能なテーブルフィルターを有効にする方法については、 セクション 5.3.3

•	利用可能なテーブルフィルターのセットを構成するルールの追加、削除、または変更については、 セクション 7.6.4

•	既存のサブスクリプションで有効になっているテーブルフィルターの変更については、 セクション 5.5.4

マルチマスターレプリケーションシステムでテーブルフィルターを使用するには、次のセクションを参照してください。

•	マスターノードでの選択的な有効化に使用できるテーブルフィルターの初期セットの定義については、 セクション 6.2.3

•	新しく作成されたマスターノードで使用可能なテーブルフィルターを有効にする方法については、 セクション 6.3

•	利用可能なテーブルフィルターのセットを構成するルールの追加、削除、または変更については、 セクション 7.6.4

•	既存のマスターノードで有効にしたテーブルフィルターの変更については、 セクション 6.9

2.3 xDB Replication Serverのコンポーネントとアーキテクチャ

このセクションでは、xDB Replication Serverのコンポーネントとアーキテクチャについて説明します。セクション 2.3.1では、xDB Replication Serverを構成する実行可能プログラム、ファイル、およびデータベースについて説明します。セクション2.3.2では、複製システムの論理コンポーネントと、それらがプログラムおよびデータベースにどのように対応するかを定義します。セクション2.3.3は、複製システムの例を示しています。

2.3.1 Physical Components

xDB Replication Serverは、単一の実行可能プログラムではなく、構成情報とメタデータを含むデータストアを備えたプログラムのセットであり、連携して複製システムを形成します。

次の図は、xDB Replication Serverのコンポーネントと、それらを使用して完全な基本的な単一マスターレプリケーションシステムを形成する方法を示しています。

図2‑8-xDB Replication Server-物理ビュー（シングルマスターレプリケーションシステム）

次の図は、xDB Replication Serverのコンポーネントと、それらを使用して完全な基本的なマルチマスターレプリケーションシステムを形成する方法を示しています。

図2‑9-xDB Replication Server-物理ビュー（マルチマスターレプリケーションシステム）

基本的な複製システム用のxDB Replication Serverの最小構成は、次のソフトウェアコンポーネントで構成されています。

•	出版サーバー。パブリケーションデータベースとマスターノードをレプリケーション用に構成し、レプリケーションを実行するプログラム。

•	サブスクリプションサーバー。レプリケーション用にサブスクリプションデータベースを構成し、レプリケーションを開始するプログラム。サブスクリプションサーバーは、シングルマスターレプリケーションシステムでのみ使用されます。

•	xDBレプリケーション構成ファイル。コントローラーデータベースとして指定されたパブリケーションデータベースに接続するために、起動時にパブリケーションサーバーおよびサブスクリプションサーバーによって使用される接続および認証情報を含むテキストファイル。レプリケーションシステムを作成するときに、ユーザーインターフェイスからパブリケーションサーバーとサブスクリプションサーバーの登録を認証するためにも使用されます。

•	xDBスタートアップコンフィギュレーションファイル。パブリケーションサーバーおよびサブスクリプションサーバーの起動時にJavaランタイム環境に使用されるインストールおよび構成情報を含むテキストファイル。

次のコンポーネントを追加することで、複製システム全体が完成します。

•	複製システムを構成および保守するためのユーザーインターフェイス

•	シングルマスターレプリケーションシステム用の1つ以上のパブリケーションデータベース

•	シングルマスターレプリケーションシステム用の1つ以上のサブスクリプションデータベース

•	マルチマスター複製システム用の1つのマスター定義ノード

•	マルチマスター複製システム用の1つ以上の追加マスターノード

ユーザーインターフェイス、パブリケーションサーバー、サブスクリプションサーバー、パブリケーションデータベース、サブスクリプションデータベース、およびマスターノードはすべて、同じホストまたは個別のネットワークホストで実行できます。

パブリケーションおよびサブスクリプションサーバーのネットワークの場所、ユーザー名、およびパスワードがわかっている限り、ネットワーク上の任意の数のパブリケーションサーバーおよびサブスクリプションサーバーにアクセスするために、いつでも任意の数のユーザーインターフェイスを使用できます。

任意の数のパブリケーションおよびサブスクリプションデータベースをシングルマスターレプリケーションシステムに参加させることができます。

任意の数のマスターノードがマルチマスター複製システムに参加できます。

次のセクションでは、各コンポーネントについて詳しく説明します。

2.3.1.1 Publication Server

パブリケーションサーバーは、パブリケーションのメタデータを作成および管理します。パブリケーションが作成されると、パブリケーションサーバーは、パブリケーションデータベースのコントロールスキーマにデータベースオブジェクトを作成して、パブリケーションに関するメタデータを記録します。

マスターノードがマルチマスターレプリケーションシステムに追加されるたびに、パブリケーションサーバーは、メタデータを記録するためにマスターノードの制御スキーマにデータベースオブジェクトを作成します。非MDNノードの場合、パブリケーションサーバーは、マスターノードの作成時に選択された場合、EnterpriseDBのMigration Toolkitを呼び出してパブリケーションテーブル定義を作成します。

注：制御スキーマについては、セクション2.3.1.11を参照してください。

パブリケーションサーバーは、レプリケーションの実行も担当します。スナップショットレプリケーションの場合、パブリケーションサーバーはEnterpriseDBのMigration Toolkitを呼び出してスナップショットを実行します。

シングルマスター同期レプリケーションの場合、パブリケーションサーバーはJava Database Connectivity（JDBC）インターフェースを使用して、次の2つの方法のいずれかで記録された変更に基づいてサブスクリプションテーブルの行に変更を適用します。 Postgresバージョン9.4以降およびパブリケーションの作成時に論理デコードオプションが選択された場合、論理レプリケーションスロットを使用してPostgres WALファイルから変更が取得される、またはb）その他のすべての状況では、変更はメタデータテーブル（シャドウテーブルと呼ばれる）に記録される）パブリケーションテーブルの行に対する挿入、更新、または削除時に起動する行ベースのトリガーによるパブリケーションデータベース内。

マルチマスター同期レプリケーションの場合、パブリケーションサーバーはシングルマスター同期と同じプロセスを実行しますが、マルチマスターレプリケーションシステムの各マスターノードペアの組み合わせに対して実行します。

パブリケーションサーバーは、他のxDB Replication Serverコンポーネントと同じホストで実行される場合もあれば、別のネットワークホストで実行される場合もあります。

2.3.1.2 Subscription Server

注：サブスクリプションサーバーは、シングルマスターレプリケーションシステムにのみ必要です。サブスクリプションサーバーを実行する必要はありません。また、マルチマスターレプリケーションシステムのみが使用されている場合はインストールする必要もありません。

サブスクリプションサーバーは、サブスクリプションのメタデータを作成および管理します。サブスクリプションが作成されると、サブスクリプションサーバーは、パブリケーションデータベースのコントロールスキーマにデータベースオブジェクトを作成して、サブスクリプションに関するメタデータを記録します。

サブスクリプションが作成されると、サブスクリプションサーバーはEnterpriseDBのMigration Toolkitを呼び出して、サブスクリプションデータベースにサブスクリプションテーブル定義を作成します。サブスクリプションテーブルの行は、レプリケーションが発生するまで入力されません。行には、パブリケーションサーバーのアクションが入力されます。

サブスクリプションサーバーは、ユーザーインターフェイスを介したユーザーの手動操作、またはサブスクリプション用に作成されたスケジュールの結果としてレプリケーションを開始する役割も担います。サブスクリプションサーバーは、関連付けられたパブリケーションを管理するパブリケーションサーバーへの呼び出しを開始します。その後、公開サーバーは実際のレプリケーションを実行します。

サブスクリプションサーバーは、他のxDB Replication Serverコンポーネントと同じホスト上で実行することも、別のネットワークホスト上で実行することもできます。

サブスクリプションサーバーが起動されると、ホスト上にあるxDBレプリケーション構成ファイルの情報を使用して、指定されたコントローラーデータベースに接続します。

2.3.1.3 xDB Replication Configuration File

xDBレプリケーション構成ファイルには、ファイルを含むホストで実行されているパブリケーションサーバーまたはサブスクリプションサーバーが使用する接続および認証情報が含まれています。

具体的には、xDBレプリケーション構成ファイルは、次の状況でアクセスされます。

•	パブリケーションサーバーまたはサブスクリプションサーバーがホスト上で起動されたとき。

•	レプリケーションシステムの作成プロセス中にパブリケーションサーバーまたはサブスクリプションサーバーが登録されたとき。パブリケーションサーバーまたはサブスクリプションサーバーの登録は、xDB Replication ConsoleまたはxDB Replication Serverコマンドラインインターフェイスを使用して行われます。

次の表には、xDBレプリケーション構成ファイルのパラメーターの簡単な説明が含まれています。

表2‑2-xDBレプリケーション構成ファイル

Parameter	Description
admin_user	xDB administrator user name (the admin user name) for registering a publication server or a subscription server on this host containing the xDB Replication Configuration file
admin_password	Encrypted password of the admin user
database	Database name of the controller database
user	Database user name of the controller database
password	Encrypted password of the controller database user
port	Port number on which the database server of the controller database listens for requests
host	IP address of the host running the database server of the controller database
type	Database type of the controller database such as oracle, enterprisedb, etc.

xDB Replication Server製品は、このファイルのコンテンツを次のように作成します。

•	xDB Replication Serverのインストールプロセス中にパブリケーションサーバーまたはサブスクリプションサーバーをホストにインストールすると、xDB Replication構成ファイルとその初期コンテンツの一部が作成されます。

•	パラメータ admin_userおよびadmin_passwordは、xDB Replication Serverのインストールプロセス中に決定されます。これらのパラメーターの内容の決定方法については、第3章を参照してください。

•

パラメータ database 、 user 、 password 、 port 、 host 、およびtypeは、xDB Replication ConsoleまたはxDB Replication Server CLIで作成した最初のパブリケーションデータベース定義の接続および認証情報で設定されます。このデータベースは、コントローラーデータベースとして指定されています。コントローラデータベースの詳細については、セクション2.3.1.12を参照してください。シングルマスターレプリケーションシステムのパブリケーションデータベース定義の作成については、セクション5.2.2を参照してください。マルチマスターレプリケーションシステムのパブリケーションデータベース定義の作成については、セクション6.2.2を参照してください。

以下は、xDBレプリケーション構成ファイルの内容の例です。

#xDB Replication Server Configuration Properties

#Tue May 26 13:45:37 GMT-05:00 2015

port=1521

admin_password=ygJ9AxoJEX854elcVIJPTw\=\=

user=pubuser

admin_user=admin

type=oracle

password=ygJ9AxoJEX854elcVIJPTw\=\=

database=xe

host=192.168.2.23

注：管理者ユーザー名とコントローラーデータベースユーザー名のパスワードは暗号化されています。これらのパスワードのいずれかを変更した場合、xDBレプリケーション構成ファイル内の対応するパスワードパラメーターを変更して、新しいパスワードの暗号化された形式を含める必要があります。パスワードの暗号化形式を生成する方法については、セクション10.4.2を参照してください。

xDBレプリケーション構成ファイルのファイルシステムの場所については、 セクション 3.5を参照してください 。

2.3.1.4 xDB Startup Configuration File

xDBスタートアップ構成ファイルには、ファイルを含むホストでパブリケーションサーバーまたはサブスクリプションサーバーが起動するときに主にJavaランタイム環境（JRE）によって使用されるインストールおよび構成情報が含まれています。

ファイルの内容は、xDB Replication Serverのインストール時にxDB Replication Serverインストーラーによって作成されます。

以下は、xDBスタートアップ構成ファイルの内容の例です。

#!/bin/sh

 

JAVA_EXECUTABLE_PATH="/usr/bin/java"

JAVA_MINIMUM_VERSION=1.7

JAVA_BITNESS_REQUIRED=64

JAVA_HEAP_SIZE="-Xms256m -Xmx1536m"

PUBPORT=9051

SUBPORT=9052

次の表には、xDB起動構成ファイルのパラメーターの簡単な説明が含まれています。

表2‑3-xDBスタートアップ構成ファイル

Parameter	Description
JAVA_EXECUTABLE_PATH	Directory path to the Java runtime program used to start and run the publication and subscription servers
JAVA_MINIMUM_VERSION	The earliest JRE version that can be used by the publication and subscription servers
JAVA_BITNESS_REQUIRED	The bitness of the Java virtual machine required by the installed publication and subscription servers
JAVA_HEAP_SIZE	In -Xms NNN m nnn specifies the minimum Java heap size in megabytes. In -Xmx NNN m nnn specifies the maximum Java heap size in megabytes
PUBPORT	Port number on which the publication server listens for requests
SUBPORT	Port number on which the subscription server listens for requests

JAVA_EXECUTABLE_PATHパラメータは、インストールプロセス中にXDB Replication Serverのインストーラによって識別されるJavaランタイムプログラムの場所を指定します。このパラメーターの設定は、必要に応じて別のJREインストールに後で変更できます。

JAVA_MINIMUM_VERSIONパラメータは、XDB Replication Serverのに使用することができますJavaランタイム環境の最も古いバージョンを指定します。この設定は変更しないでください。

JAVA_BITNESS_REQUIREDパラメータは変更しないでください。インストールされた値が変更された場合、またはJAVA_EXECUTABLE_PATHで識別されるJava仮想マシンのJAVA_EXECUTABLE_PATH数と一致しない場合、パブリケーションおよびサブスクリプションサーバーの起動の失敗やxDBレプリケーションの登録の失敗など、多くのエラーが発生する可能性がありますサーバー製品。

JAVA_HEAP_SIZEパラメータの設定については、 5.1.1 項を参照してください 。

節を参照してください 5.1.6.1については、 PUBPORTとSUBPORTパラメータ。

xDBスタートアップ構成ファイルに変更を加えた後、パブリケーションサーバーとサブスクリプションサーバーを再起動する必要があります。

xDB起動構成ファイルのファイルシステムの場所については、 セクション 3.5を参照してください 。

2.3.1.5 xDB Replication Console

xDBレプリケーションコンソールは、レプリケーションシステムのあらゆる側面を作成および制御するために使用できるグラフィカルユーザーインターフェイスプログラムです。

単一のxDBレプリケーションコンソールを使用して、xDBレプリケーションコンソールがインストールされているホストと同じホストで実行されているレプリケーションシステムを構成および操作できます。または、xDBレプリケーションサーバーコンポーネントがネットワーク環境。

図2‑10-複数のホストにアクセスするxDBレプリケーションコンソール

前の図では、2つのネットワークホストで実行されている2つのPostgresインストールがあり、それぞれに独自のxDB Replication Serverインストールがあります。各ホストは、パブリケーションサーバーとサブスクリプションサーバーを実行しています。

パブリケーションサーバーとサブスクリプションサーバーがリモートホストにインストールされたネットワークIPアドレス、ポート番号、ユーザー名、パスワードが指定されている場合、各ホストのxDBレプリケーションコンソールは、他のホストのレプリケーションシステムにアクセスして管理できます。

xDB Replication Consoleのユーザーインターフェイスの詳細については、第 4 章を参照してください 。

2.3.1.6 xDB Replication Server Command Line Interface

xDB Replication Serverコマンドラインインターフェイス（CLI）は、xDB Replication Consoleグラフィカルユーザーインターフェイスに代わるコマンドライン駆動型であり、レプリケーションシステムのあらゆる側面を作成および制御するための同等の機能を提供します。

Bash for LinuxなどのスクリプトにxDB Replication Server CLIコマンドを組み込むことにより、レプリケーションシステムの操作を自動化できます。

xDB Replication Server CLIは、xDB Replication Consoleのインストールを選択するたびにインストールされます。

第 8 章では、xDB Replication Server CLIの使用方法について説明します。

2.3.1.7 Publication Database

パブリケーションデータベースには、パブリケーションで使用されるテーブルとビューが含まれています。パブリケーションデータベースは、ホストがネットワークによって相互にアクセスできる限り、パブリケーションサーバーが実行されているのと同じホストまたは異なるホストで実行されている場合があります。

各パブリケーションデータベースには、コントロールスキーマも含まれます。これは、このパブリケーションデータベースに接続されているパブリケーションサーバーによって制御される、シングルマスターとマルチマスターの両方のすべてのレプリケーションシステムのメタデータを含むデータベースオブジェクトのコレクションです。制御スキーマの詳細は、 2.3.1.11 項を参照してください 。

マルチマスターレプリケーションシステムでは、すべてのマスターノードがパブリケーションデータベースと見なされます。

データベースは、パブリケーションとサブスクリプションが含まれている場合、パブリケーションデータベースとサブスクリプションデータベースの両方の役割を果たします。

2.3.1.8 Subscription Database

注：サブスクリプションデータベースは、シングルマスターレプリケーションシステムにのみ適用されます。

サブスクリプションデータベースには、サブスクリプションから作成されたテーブルが含まれます。サブスクリプションデータベースは、ホストがネットワークによって相互にアクセス可能である限り、サブスクリプションサーバーが実行されているのと同じホストまたは異なるホストで実行できます。

サブスクリプションデータベースは、必要に応じて3番目のサーバーに複製するためのパブリケーションソースとしても機能します。この構成は、 カスケード複製 と呼ばれます 。

データベースは、カスケードレプリケーションシナリオなどでパブリケーションとサブスクリプションが含まれている場合、パブリケーションデータベースとサブスクリプションデータベースの両方の役割を果たします。

2.3.1.9 Master Node

マルチマスターレプリケーションシステムでは、行の変更がレプリケートされるテーブルのセット（パブリケーション）を含むデータベースはマスターノードと呼ばれます。ホストがネットワークで相互にアクセスできる限り、パブリケーションサーバーが実行されているのと同じホストまたは異なるホストでマスターノードが実行されている場合があります。

各マスターノードには、コントロールスキーマも含まれます。これは、このマスターノードに接続されたパブリケーションサーバーによって制御される、シングルマスターとマルチマスターの両方のすべてのレプリケーションシステムのメタデータを含むデータベースオブジェクトのコレクションです。制御スキーマの詳細は、 2.3.1.11 項を参照してください 。

マスターノードは、同じまたは複数のデータベースサーバーインスタンス（Postgresデータベースクラスター）の下で実行されている場合があります。

2.3.1.10 Master Definition Node

マルチマスター複製システムを作成するために追加された最初のノードは、最初はマスター定義ノードとして指定されます。このノードには、パブリケーションに含まれるテーブル定義（およびオプションで、行の初期セット）が含まれている必要があります。

後続のデータベースがマスターノードとして複製システムに追加されると、テーブル定義と初期行セットをオプションでマスター定義ノードから新しく追加されたマスターノードに伝達できます。

マルチマスター複製システムが定義された後、マスター定義ノードの役割をマルチマスター複製システム内の別のマスターノードに再割り当てすることができます。この再割り当ての重要性は、新しく指定されたマスター定義ノードから他のマスターノードにスナップショットを取得できることです。これは、古いマスター定義ノードのデータが破損したり、他のマスターノードと同期しなくなったり、別のマスターノードからのスナップショットで完全に更新する必要がある場合に役立ちます。

すべてのマスターノードと同様に、マスター定義ノードにはコントロールスキーマが含まれます。これは、このマスターノードに接続されたパブリケーションサーバーによって制御される、シングルマスターとマルチマスターの両方のすべてのレプリケーションシステムのメタデータを含むデータベースオブジェクトのコレクションです制御スキーマの詳細は、 2.3.1.11 項を参照してください 。

2.3.1.11 Control Schema and Control Schema Objects

制御スキーマは、論理的および物理的な構造を定義するメタデータ・データベース・オブジェクトのコレクションを指す概念的な用語であり、そしてXDB Replication Serverのシングルマスタおよびマルチマスタ複製システムの運用・保守を可能にします。

これらのメタデータデータベースオブジェクトは、 コントロールスキーマオブジェクト と呼ばれ、テーブル、シーケンス、関数、プロシージャ、トリガー、パッケージなどで構成されます。

コントロールスキーマオブジェクトには、レプリケーションシステムのタイプ（シングルマスターまたはマルチマスター）、ネットワークロケーション、データベースタイプ、パブリケーションデータベース、サブスクリプションデータベース、マスターノードの接続および認証情報、パブリケーションの名前、テーブルなどのメタデータが格納されます。ビューに含まれるビュー、サブスクリプションの名前、サブスクライブ先のパブリケーション、レプリケーショントランザクションステータス、レプリケーションスケジューリング、レプリケーション履歴クリーンアップスケジューリング、レプリケーション履歴など

トリガーベースのシングルマスターレプリケーションシステムの各パブリケーションデータベースには、パブリケーションの行に加えられた変更と、それらの変更がサブスクリプションテーブルに適用されているかどうかのステータスを持つコントロールスキーマオブジェクトも含まれています。

同様に、マルチマスターレプリケーションシステムの場合、各トリガーベースのマスターノードには、そのマスターノードにあるパブリケーションの行に加えられた変更を含むコントロールスキーマオブジェクトと、それらの変更が適用されたかどうかのステータスが含まれますマルチマスター複製システム内の他のマスターノードへ。

注：ログベースのシングルマスターおよびマルチマスターレプリケーションシステムの場合、変更はコントロールスキーマオブジェクトに保存されるのではなく、データベースサーバーのWALファイルから抽出されます。ログベースの方法については、セクション2.2.10を参照してください。

制御スキーマオブジェクトが属する制御スキーマを実装する実際の物理データベーススキーマは、データベースタイプ（Oracle、SQL Server、またはPostgres）およびxDB Replication Serverで使用するためにデータベースが最初に構成された方法によって異なります。

制御スキーマについて、次の点に注意する必要があります。

•	コントロールスキーマとそのコントロールスキーマオブジェクトは、シングルマスターとマルチマスターの両方のレプリケーションシステムのすべてのパブリケーションデータベースに作成されます。つまり、シングルマスター複製システムのすべてのマスター（パブリケーション）データベースとマルチマスター複製システムのすべてのマスターノード。

•	シングルマスター複製システムに新しいマスターデータベースを追加する場合、またはマルチマスター複製システムに新しいマスターノードを追加する場合、スナップショット操作を使用して、既存のコントローラーデータベースがあると仮定して、新しく追加されたパブリケーションデータベースに制御スキーマを複製します。コントローラデータベースに関する情報については、 セクション 2.3.1.12を参照してください 。

•	xDBレプリケーションコンソールまたはxDB Replication Serverコマンドラインインターフェイスによって行われたシングルマスターレプリケーションシステムまたはマルチマスターレプリケーションシステムの構成の更新は、すべてのパブリケーションデータベースの制御スキーマ間で同期され、メタデータの一貫性が確保されます。すべての出版物データベース。

•	シングルマスターレプリケーションシステムのスレーブ（サブスクリプション）データベースには、メタデータデータベースオブジェクトとして1つの単一のテーブルが含まれています。 サブスクリプションメタデータオブジェクト という用語は、 サブスクリプションデータベース内のこのデータベースオブジェクトを指すために特に使用されます。一般的な用語、コントロールスキーマ、およびコントロールスキーマオブジェクトは、パブリケーションデータベース内のデータベースオブジェクトを指します。

•	同じ公開サーバーによって制御されるすべてのデータベースの制御スキーマオブジェクトには、通常、同じ情報が含まれています。これにより、そのようなデータベースは、xDB Replication Serverが必要とする情報を提供し、その特定のパブリケーションサーバーで実行されているすべてのシングルマスターおよびマルチマスターレプリケーションシステムを制御できます。

•	データベースサーバーの問題、ネットワーク接続の問題などにより、レプリケーションシステムの特定のパブリケーションデータベースがオフラインになった場合、他のパブリケーションデータベースが必要な制御スキーマ情報を提供できるため、同じパブリケーションサーバーで実行されている他のレプリケーションシステムは引き続き機能しますすべての複製システムを実行します。

2.3.1.12 Controller Database

xDBレプリケーション構成ファイルには、1つのパブリケーションデータベースの接続および認証情報が含まれており、 コントローラーデータベース として指定されて います 。

すべてのパブリケーションデータベースと同様に、コントローラーデータベースには、そのxDBレプリケーション構成ファイルにアクセスするパブリケーションサーバーによって実行されるすべてのシングルマスターおよびマルチマスターレプリケーションシステムのレプリケーションシステム情報を含む制御スキーマが含まれます。

コントローラーデータベースは、パブリケーションサーバーおよびサブスクリプションサーバーに対するレプリケーションシステム情報のプライマリプロバイダーとして機能します。したがって、最初の起動時に、パブリケーションサーバーとサブスクリプションサーバーは指定されたコントローラーデータベースへの接続を試みます。このコントローラーデータベースは、すべてのレプリケーションシステムのメタデータ情報を提供します。

何らかの理由でコントローラーデータベースへの初期接続が失敗した場合、xDBレプリケーション構成ファイルを手動で編集して、別のパブリケーションデータベースの接続および認証情報を提供できます。その後、パブリケーションサーバーとサブスクリプションサーバーの起動時に、この代替パブリケーションデータベースの制御スキーマを使用して、レプリケーションシステム情報が提供されます。

初期コントローラデータベースは、シングルマスターまたはマルチマスターレプリケーションシステム用に、xDBレプリケーションコンソールまたはxDBレプリケーションサーバーCLIによって作成された最初のパブリケーションデータベース定義によって決定されます。パブリケーションサーバーは、xDBレプリケーション構成ファイルに接続および認証情報を記録します。

現在のコントローラーデータベースのパブリケーションデータベース定義を削除する場合は、xDBレプリケーションコンソールを使用して、最初に同じパブリケーションサーバーで定義された別のパブリケーションデータベースをコントローラーとして指定する必要があります。コントローラを別のパブリケーションデータベースに切り替える方法については、セクション 7.7を参照してください 。

以下は、コントローラーデータベースに関するいくつかのポイントです。

•	パブリケーションサーバーとサブスクリプションサーバーを起動する前に、コントローラーデータベースを実行するデータベースサーバーが実行され、アクセス可能である必要があります。

•	シングルマスターレプリケーションシステムの場合、パブリケーションデータベースとパブリケーションが定義されるパブリケーションサーバーと、サブスクリプションデータベースとパブリケーションに関連するサブスクリプションが定義されるサブスクリプションサーバーは、両方とも同じコントローラーデータベースに接続する必要があります。これにより、パブリケーションサーバーとサブスクリプションサーバーが同じ制御スキーマにアクセスできるようになります。

•	コントローラーデータベースのコントロールスキーマによって保持されているメタデータに変更が加えられると、これらの変更は、パブリケーションサーバーによって他のすべてのパブリケーションデータベースのコントロールスキーマに複製されます。これにより、すべてのパブリケーションデータベースの制御スキーマで、すべてのシングルマスターシステムとマルチマスターシステムのメタデータが完全で一貫したものになります。これにより、後のある時点でコントローラーデータベースを切り替えることができます。コントローラーデータベースの切り替えについては、セクション 7.7を参照してください 。

注：コントローラーデータベースがOracleまたはSQL Serverパブリケーションデータベースの場合、2番目のOracleまたはSQL Serverパブリケーションデータベースを追加して、2番目のシングルマスターレプリケーションシステムを作成することはできません。 xDB Replication ServerがOracleまたはSQL Serverパブリケーションデータベースで構成される複数のシングルマスタレプリケーションシステムを実行するには、Postgresパブリケーションデータベースをコントローラーデータベースとして指定する必要があります。

Postgresコントローラーデータベースを備えたシングルマスターレプリケーションシステムに複数のOracleまたはSQL Serverパブリケーションデータベースをセットアップしたら、コントローラーデータベースをOracleまたはSQL Serverパブリケーションデータベースに切り替えないでください。

2.3.2 Logical Components

このセクションでは、複製システムの論理コンポーネント、それらの相互関係、および複製システム内のプログラムとデータベースとの対応について説明します。

論理コンポーネントは、xDB Replication ConsoleまたはxDB Replication Server CLIを使用して複製システムを構築するときに作成されます。論理コンポーネントは、レプリケーションデータベースのメタデータの一部として、パブリケーションデータベースの制御スキーマに保存されます。

複製システムを作成するには、次の手順が必要です。

•	パブリケーションサーバーを登録する

•	パブリケーションデータベース定義を作成する

•	パブリケーションを作成する

シングルマスターレプリケーションシステムの場合、次を実行します。

•	サブスクリプションサーバーを登録する

•	サブスクリプションデータベース定義を作成する

•	サブスクリプションを作成する

マルチマスターレプリケーションシステムの場合、追加のパブリケーションデータベース定義を作成して、追加のマスターノードを作成します。

これらの各手順は、xDBレプリケーションコンソールのレプリケーションツリーのノードで表される論理コンポーネントを作成します。 xDB Replication Consoleの説明については、 第 4 章を参照してください 。これらのコンポーネントの簡単な説明は、次のセクションで説明します。

2.3.2.1 Publication Server

パブリケーション作成の最初のステップは、パブリケーションの管理に使用されるパブリケーションサーバーを識別することです。このプロセスは 、パブリケーションサーバーの登録 と呼ば れます 。

xDBレプリケーションコンソールまたはxDBレプリケーションサーバーCLIを使用して、パブリケーションサーバーは、パブリケーションサーバーが実行されているホストのIPアドレスとポート番号、およびxDBレプリケーション構成に格納されている管理ユーザー名とパスワードを指定することで登録されますパブリケーションサーバーを実行しているホストにあるファイル。 （この情報は、パブリケーションサーバーのインストールプロセス中に決定されます。）

xDB Replication Consoleで表示すると、登録されたパブリケーションサーバーが、レプリケーションツリーの最上位のReplication Serverノードの下に表示されます。パブリケーションに関連するすべての論理コンポーネントは、登録されたパブリケーションサーバーの下位に作成され、レプリケーションツリーでその下に表示されます。

5.2.1 項では、シングルマスターレプリケーションシステム用のパブリケーションサーバーを登録する方法を説明しています。マルチマスター複製システムについては、セクション6.2.1を参照してください。

2.3.2.2 Replication System Type (SMR/MMR)

登録されたパブリケーションサーバーの下位に、レプリケーションシステムタイプを表す2つのノードが表示されます。 1つはシングルマスター複製のラベル SMRで識別され、もう1つはマルチマスター複製のラベルMMRで識別されます。

シングルマスター複製システムを作成している場合は、SMRタイプのノードの下に論理コンポーネントを追加します。

マルチマスター複製システムを作成する場合は、MMRタイプノードの下に論理コンポーネントを追加します。

2.3.2.3 Publication Database Definition

登録されたパブリケーションサーバーの下のレプリケーションシステムタイプノードの1つに従属して、1つ以上のパブリケーションデータベース定義を作成できます。

パブリケーションデータベース定義は、パブリケーションで使用されるテーブルとビューを持つデータベースを識別します。識別情報は、データベースサーバーのIPアドレス、ポート番号、データベースユーザー名とパスワード、およびデータベース識別子で構成されます。

パブリケーションサーバーは、この情報を使用してパブリケーションデータベースに接続し、パブリケーションデータベースにレプリケーションシステム制御スキーマを作成し、レプリケーションを実行します。

パブリケーションデータベース定義の作成プロセスは、シングルマスターとマルチマスターのレプリケーションシステムで似ていますが、レプリケーションシステム内での使用方法は多少異なります。

シングルマスターレプリケーションシステムでは、パブリケーションデータベースの定義により、1つ以上のパブリケーションのストレージ領域が識別されます。各パブリケーションは、最終的に、マスターとスレーブの関係で独自のサブスクリプションに関連付けられます。

マルチマスターレプリケーションシステムでは、特定のパブリケーションサーバーのMMRタイプノードに従属する各パブリケーションデータベース定義は、単一のマルチマスターレプリケーションシステムのマスターノードを識別します。

注：現在、パブリケーションサーバーごとに1つのマルチマスターレプリケーションシステムしか存在できません。

セクション 5.2.2では、シングルマスターレプリケーションシステムのパブリケーションデータベース定義の作成について説明します。マルチマスター複製システムについては、セクション6.2.2および6.3を参照してください。

2.3.2.4 Publication

シングルマスターレプリケーションシステムのパブリケーションデータベース定義に従属して、1つ以上のパブリケーションを定義できます。パブリケーションには、サブスクリプションデータベースにレプリケートされるテーブルとビューのリストが含まれます。

シングルマスターレプリケーションシステムでは、レプリケーションツリーで表示されるパブリケーションの親のパブリケーションデータベース定義で指定されたデータベースユーザー名には、パブリケーションに含まれるテーブルまたはビューに対するSELECTオブジェクト権限が必要です。

マルチマスターレプリケーションシステムのパブリケーションデータベース定義に従属する、定義できるパブリケーションは1つだけです。パブリケーションには、複製され、マルチマスター複製システムのマスターノードで同期が維持されるテーブルのリストが含まれます。

マルチマスターレプリケーションシステムでは、レプリケーションツリーで表示されるパブリケーションの親のパブリケーションデータベース定義で指定されたデータベースユーザー名は、スーパーユーザー権限を持ち、パブリケーションに含まれるすべてのテーブルの所有者である必要があります。

5.2.3 項では、シングルマスターレプリケーションシステム用のパブリケーションの作成について説明します。マルチマスター複製システムについては、セクション6.2.3を参照してください。

2.3.2.5 Subscription Server

注：サブスクリプションサーバーは、シングルマスターレプリケーションシステムにのみ適用されます。マルチマスターレプリケーションシステムを作成するとき、サブスクリプションサーバーを登録しません。

サブスクリプションを作成する最初の手順は、サブスクリプションの管理に使用するサブスクリプションサーバーを識別することです。このプロセスは 、サブスクリプションサーバーの登録 と呼ば れます 。

xDBレプリケーションコンソールまたはxDBレプリケーションサーバーCLIを使用して、サブスクリプションサーバーが実行されているホストのIPアドレスとポート番号、およびxDBレプリケーション構成に保存されている管理ユーザー名とパスワードを指定することにより、サブスクリプションサーバーが登録されますサブスクリプションサーバーを実行しているホストにあるファイル。 （この情報は、サブスクリプションサーバーのインストールプロセス中に決定されます。）

xDB Replication Consoleで表示すると、登録されたサブスクリプションサーバーが、レプリケーションツリーの最上位のReplication Serversノードの下に表示されます。サブスクリプションに関連するすべての論理コンポーネントは、登録済みのサブスクリプションサーバーに従属して作成され、レプリケーションツリー内でその下に表示されます。

5.3.1 項では、サブスクリプションサーバーを登録する方法について説明します。

2.3.2.6 Subscription Database Definition

注：サブスクリプションデータベースの定義は、シングルマスターレプリケーションシステムにのみ適用されます。マルチマスターレプリケーションシステムを作成する場合、サブスクリプションデータベース定義は作成しません。

登録済みのサブスクリプションサーバーに従属して、1つ以上のサブスクリプションデータベース定義を作成できます。

サブスクリプションデータベース定義は、パブリケーションのテーブルとビューがレプリケートされるデータベースを識別します。識別情報は、データベースサーバーのIPアドレス、ポート番号、データベースユーザー名とパスワード、およびデータベース識別子で構成されます。

サブスクリプションサーバーはこの情報を使用してサブスクリプションデータベースに接続し、テーブル定義を作成します。

また、パブリケーションサーバーはこの情報を使用して、レプリケーションの実行時にサブスクリプションデータベースに接続します。

セクション 5.3.2では、サブスクリプションデータベース定義の作成について説明します。

2.3.2.7 Subscription

注：サブスクリプションは、シングルマスター複製システムにのみ適用されます。マルチマスター複製システムを作成するとき、サブスクリプションを作成しません。

サブスクリプションデータベース定義に従属して、1つ以上のサブスクリプションを定義できます。サブスクリプションは、パブリケーションのテーブルとビューがレプリケートされるサブスクリプションデータベースにパブリケーションを関連付けます。

各サブスクリプションは、1つのパブリケーションにのみ関連付けることができます。

セクション 5.3.3では、サブスクリプションの作成について説明します。

2.3.3 xDB Replication System Examples

このセクションには、複製システムの例と、それらを定義するために論理コンポーネントを使用する方法が含まれています。

添付の図では、xDB Replication Consoleの複製ツリーのノードで表される論理コンポーネントが物理コンポーネント図に重ねられています。論理コンポーネントは、ダイアグラムでそれらを識別するのに役立つように黄色で網掛けされています。

2.3.3.1 Oracle to PostgreSQL or Advanced Server Replication

以下は、基本的なOracleからPostgreSQLまたはAdvanced Serverのシングルマスターレプリケーションシステムの図です。 Oracleの1つのパブリケーションには、PostgreSQLまたはAdvanced Serverにあるデータベースに複製される2つのスキーマのテーブルが含まれます。

図2‑11-OracleからPostgreSQLまたはAdvanced Serverレプリケーション

次の図は、前の図の論理コンポーネントを示しています。

•	使用するパブリケーションサーバーは、ネットワークの場所、ユーザー名、およびパスワードを登録することにより識別されます。

•	パブリケーションデータベース定義は、パブリケーションサーバーの下のSMRタイプノードに従属して作成されます。 Oracleデータベースのユーザー名 pubuserは、データベースネットワークの場所とデータベース識別子とともに定義で指定されます。あなたが名前のユーザーを作成するときpubuserオラクルでは、名前のスキーマpubuser同時に自動的に、Oracleによって作成されます。パブリケーションデータベースの定義を作成すると、パブリケーションサーバーは、レプリケーションシステムのメタデータのpubuserコントロールスキーマにコントロールスキーマオブジェクトを作成します。

•	pub という名前のパブリケーションは、パブリケーションデータベース定義に従属して作成されます。パブリケーションは、テーブルから成るAスキーマにS1とテーブルBとCスキーマ内S2 。

•	使用するサブスクリプションサーバーは、ネットワークの場所、ユーザー名、およびパスワードを登録することで識別されます。

•	サブスクリプションデータベース定義は、サブスクリプションサーバーに従属して作成されます。 Postgresデータベースのユーザー名 subuser ユーザーは、データベースネットワークの場所とデータベース識別子とともに定義で指定されます。

•	sub という名前のサブスクリプションは、サブスクリプションデータベース定義に従属して作成されます。サブスクリプションが作成されると、サブスクリプションサーバーは、サブスクリプションデータベースにS1およびS2という名前のスキーマを作成します。この時点で、テーブルA 、 B 、およびCのテーブル定義も作成されます。レプリケーションが発生すると、パブリケーションサーバーはこれらのテーブルにパブリケーションの行を取り込みます。

次のスクリーンキャプチャは、この複製システムの論理コンポーネントがxDB Replication Console複製ツリーにどのように表示されるかを示しています。

図2‑12-OracleからPostgresへのレプリケーションツリー

xDBレプリケーションコンソールの概要については、 第 4 章を参照してください 。

2.3.3.2 SQL Server to PostgreSQL or Advanced Server Replication

以下は、基本的なSQL ServerからPostgreSQLまたはAdvanced Serverのシングルマスターレプリケーションシステムの図です。 SQL Serverの単一のパブリケーションには、PostgreSQLまたはAdvanced Serverにあるデータベースに複製される2つのスキーマのテーブルが含まれます。

図2-13-SQL ServerからPostgreSQLまたはAdvanced Serverレプリケーション

次の図は、前の図の論理コンポーネントを示しています。

•	使用するパブリケーションサーバーは、ネットワークの場所、ユーザー名、およびパスワードを登録することにより識別されます。

•

パブリケーションデータベース定義は、パブリケーションサーバーの下のSMRタイプノードに従属して作成されます。 SQL Serverログイン pubuserは、データベースネットワークの場所とデータベース識別子とともに定義で指定されます。スキーマpubuserは、セクション5.1.4.2で説明されているパブリケーションデータベースの準備ステップで作成されました。 pubuser 3つの物理スキーマからなる制御スキーマと一緒にスキーマ_edb_replicator_pub 、 _edb_replicator_sub 、および_edb_schedulerパブリケーションデータベースの定義を作成するときに、レプリケーションシステムのメタデータ用のコントロール・スキーマ・オブジェクトが移入されています。

•	pub という名前のパブリケーションは、パブリケーションデータベース定義に従属して作成されます。パブリケーションは、テーブルから成るAスキーマにS1とテーブルBとCスキーマ内S2 。

•	使用するサブスクリプションサーバーは、ネットワークの場所、ユーザー名、およびパスワードを登録することで識別されます。

•	サブスクリプションデータベース定義は、サブスクリプションサーバーに従属して作成されます。 Postgresデータベースのユーザー名 subuser ユーザーは、データベースネットワークの場所とデータベース識別子とともに定義で指定されます。

•	sub という名前のサブスクリプションは、サブスクリプションデータベース定義に従属して作成されます。サブスクリプションが作成されると、サブスクリプションサーバーは、サブスクリプションデータベースにS1およびS2という名前のスキーマを作成します。この時点で、テーブルA 、 B 、およびCのテーブル定義も作成されます。レプリケーションが発生すると、パブリケーションサーバーはこれらのテーブルにパブリケーションの行を取り込みます。

次のスクリーンキャプチャは、この複製システムの論理コンポーネントがxDB Replication Console複製ツリーにどのように表示されるかを示しています。

図2‑14-SQL ServerからPostgresへのレプリケーションツリー

xDBレプリケーションコンソールの概要については、 第 4 章を参照してください 。

2.3.3.3 Advanced Server to Oracle Replication

以下は、基本的なAdvanced ServerからOracleへのシングルマスター複製システムの図です。 Advanced Serverデータベースの単一のパブリケーションには、Oracleデータベースに複製される2つのスキーマのテーブルが含まれます。

図2‑15-Advanced ServerからOracleへのレプリケーション

次の図は、前の図の論理コンポーネントを示しています。

•	使用するパブリケーションサーバーは、ネットワークの場所、ユーザー名、およびパスワードを登録することにより識別されます。

•	パブリケーションデータベース定義は、パブリケーションサーバーの下のSMRタイプノードに従属して作成されます。 Postgresデータベースのユーザー名 pubuserは、データベースネットワークの場所とデータベース識別子とともに定義で指定されます。パブリケーションサーバーは、3つの物理スキーマ_edb_replicator_pub 、 _edb_replicator_sub 、および_edb_schedulerコントロールスキーマを作成し、パブリケーションデータベース定義の作成時にレプリケーションシステムのメタデータのコントロールスキーマオブジェクトを設定します。

•	pub という名前のパブリケーションは、パブリケーションデータベース定義に従属して作成されます。パブリケーションは、テーブルから成るAスキーマにS1とテーブルBとCスキーマ内S2 。

•	使用するサブスクリプションサーバーは、ネットワークの場所、ユーザー名、およびパスワードを登録することで識別されます。

•	サブスクリプションデータベース定義は、サブスクリプションサーバーに従属して作成されます。 Oracleデータベースのユーザー名 subuser ユーザーは、データベースネットワークの場所とデータベース識別子とともに定義で指定されます。

•	sub という名前のサブスクリプションは、サブスクリプションデータベース定義に従属して作成されます。あなたが名前のユーザーを作成するときsubuserオラクルでは、名前のスキーマsubuser同時に自動的に、Oracleによって作成されます。サブスクリプションsubを作成すると、テーブルA 、 B 、およびCのテーブル定義がスキーマsub subuserに作成されます。レプリケーションが発生すると、パブリケーションサーバーはこれらのテーブルにパブリケーションの行を取り込みます。

次のスクリーンキャプチャは、この複製システムの論理コンポーネントがxDB Replication Console複製ツリーにどのように表示されるかを示しています。

図2‑16-Advanced ServerからOracleへのレプリケーションツリー

xDBレプリケーションコンソールの概要については、 第 4 章を参照してください 。

2.3.3.4 PostgreSQL or Advanced Server to SQL Server Replication

以下は、基本的なPostgreSQLまたはAdvanced ServerからSQL Serverへのシングルマスターレプリケーションシステムの図です。 PostgreSQLまたはAdvanced Serverデータベースの単一のパブリケーションには、SQL Serverデータベースに複製される2つのスキーマのテーブルが含まれます。

図2‑17-PostgreSQLまたはAdvanced ServerからSQL Serverへのレプリケーション

次の図は、前の図の論理コンポーネントを示しています。

•	使用するパブリケーションサーバーは、ネットワークの場所、ユーザー名、およびパスワードを登録することにより識別されます。

•	パブリケーションデータベース定義は、パブリケーションサーバーの下のSMRタイプノードに従属して作成されます。 Postgresデータベースのユーザー名 pubuserは、データベースネットワークの場所とデータベース識別子とともに定義で指定されます。パブリケーションサーバーは、3つの物理スキーマ_edb_replicator_pub 、 _edb_replicator_sub 、および_edb_schedulerコントロールスキーマを作成し、パブリケーションデータベース定義の作成時にレプリケーションシステムのメタデータのコントロールスキーマオブジェクトを設定します。

•	pub という名前のパブリケーションは、パブリケーションデータベース定義に従属して作成されます。パブリケーションは、テーブルから成るAスキーマにS1とテーブルBとCスキーマ内S2 。

•	使用するサブスクリプションサーバーは、ネットワークの場所、ユーザー名、およびパスワードを登録することで識別されます。

•	サブスクリプションデータベース定義は、サブスクリプションサーバーに従属して作成されます。 SQL Serverログイン subuserは、データベースネットワークの場所とデータベース識別子とともに定義で指定されます。

•	sub という名前のサブスクリプションは、サブスクリプションデータベース定義に従属して作成されます。サブスクリプションが作成されると、サブスクリプションサーバーは、サブスクリプションデータベースにS1およびS2という名前のスキーマを作成します。この時点で、テーブルA 、 B 、およびCのテーブル定義も作成されます。レプリケーションが発生すると、パブリケーションサーバーはこれらのテーブルにパブリケーションの行を取り込みます。

次のスクリーンキャプチャは、この複製システムの論理コンポーネントがxDB Replication Console複製ツリーにどのように表示されるかを示しています。

図2‑18-PostgresからSQL Serverへのレプリケーションツリー

xDBレプリケーションコンソールの概要については、 第 4 章を参照してください 。

2.3.3.5 Postgres Multi-Master Replication

以下は、基本的なPostgresマルチマスターレプリケーションシステムの図です。 Postgresマスター定義ノードのパブリケーションには、最初に他の2つのPostgresマスターノードに複製される2つのスキーマのテーブルが含まれます。その後、3つすべてのマスターノードのテーブルを更新し、相互に同期できます。

図2‑19-Postgresマルチマスターレプリケーションシステム

次の図は、前の図の論理コンポーネントを示しています。

•	使用するパブリケーションサーバーは、ネットワークの場所、ユーザー名、およびパスワードを登録することにより識別されます。

•

パブリケーションデータベース定義は、パブリケーションサーバーの下のMMRタイプノードに従属して作成されます。この最初のパブリケーションデータベース定義は、マスター定義ノードを識別します。 Postgresデータベースのユーザー名 mmruser_aは、データベースネットワークの場所とデータベース識別子とともに定義で指定されます。パブリケーションサーバーは、3つの物理スキーマ_edb_replicator_pub 、 _edb_replicator_sub 、および_edb_schedulerコントロールスキーマを作成し、パブリケーションデータベース定義の作成時にレプリケーションシステムのメタデータのコントロールスキーマオブジェクトを設定します。

•	pub という名前のパブリケーションは、パブリケーションデータベース定義に従属して作成されます。パブリケーションは、テーブルから成るAスキーマにS1とテーブルBとCスキーマ内S2 。

•	マスター定義ノードが存在するパブリケーションサーバーのMMRタイプノードに従属する別のパブリケーションデータベース定義を作成することにより、2番目のマスターノードが追加されます。 Postgresデータベースのユーザー名 mmruser_bは、2番目のマスターノードを作成するために、データベースネットワークの場所とデータベース識別子とともに定義で指定されます。

•

2番目のマスターノードを追加するときに、パブリケーションサーバーにスキーマ S1およびS2とA 、 B 、およびCテーブル定義を作成させるか、事前にスキーマおよびテーブル定義を手動で作成するかを選択できます。パブリケーションサーバーは、マスターノードのメタデータを格納するコントロールスキーマオブジェクトを作成する3つの物理スキーマ_edb_replicator_pub 、 _edb_replicator_sub 、および_edb_schedulerで_edb_schedulerコントロールスキーマを作成します。マスターノードを定義するときに、パブリケーションサーバーにこれらのテーブルにパブリケーションの行をこの時点で追加するか、テーブルのロードを後の時点に延期するかを選択できます。

•	Postgresデータベースのユーザー名 mmruser_c を使用して、同様の方法で3番目のマスターノードが追加されます 。

次のスクリーンキャプチャは、この複製システムの論理コンポーネントがxDB Replication Console複製ツリーにどのように表示されるかを示しています。

図2‑20-Postgresマルチマスターレプリケーションツリー

xDBレプリケーションコンソールの概要については、 第 4 章を参照してください 。

2.4 レプリケーションシステムの設計

このセクションでは、実際の実装を開始する前に、レプリケーションシステムを設計するための一般的な手順、設計上の考慮事項、およびベストプラクティスを示します。

2.4.1 General Steps

次の手順は、レプリケーションシステムを実装するための一般的なガイドラインを提供します。

手順1： xDB Replication Serverが要件に適したソリューションであり、特定のニーズに最適なソリューションを選択したかどうかを判断します。 xDB Replication Serverを使用して、シングルマスターまたはマルチマスターのレプリケーションシステムを実装できます。シングルマスターレプリケーションシステムの場合、xDB Replication Serverの際立った特徴は、OracleデータベースからPostgreSQLまたはAdvanced Serverデータベースへ、SQL ServerデータベースからPostgreSQLまたはAdvanced Serverデータベースへ、Advanced Serverデータベースからレプリケートする能力です。 Oracleデータベース、またはPostgreSQLまたはAdvanced ServerデータベースからSQL Serverデータベースへ。

ステップ2： xDB Replication Serverの使用方法に関する一般的な戦略を計画します。シングルマスターモデルまたはマルチマスターモデルは、ニーズに最適ですか？ （シングルマスターおよびマルチマスター複製システムの使用例については、セクション2.1を参照してください。）OracleからPostgres、SQL ServerからPostgres、Advanced ServerからOracle、またはPostgresからSQL Serverに複製しますか？ PostgreSQLデータベースまたはAdvanced Serverデータベース、あるいはその両方の間で複製しますか？どのくらいの頻度でデータを複製する必要がありますか？レプリケーションはアドホックベースで実行されますか、それともスケジュールに従って定期的に実行する必要がありますか？

ステップ3：複製システムのロジスティクスを計画します。レプリケートするテーブルの数と、合計バイト数と行数のサイズはどのくらいですか？各レプリケーションの間、各テーブルで行の何パーセントが変更されると予想されますか？データベースサーバーは専用マシンで実行する必要がありますか？

ステップ4：複製システムを設計します。レプリケーションシステムを分散するか、単一のホストで実行するかを決定します。必要なパブリケーションとサブスクリプション、およびそれらのテーブルとビューを決定します。パブリケーションテーブルがxDB Replication Serverパブリケーションの要件を満たしていることを確認してください。詳細については、セクション2.4.2および2.4.3を参照してください。

手順5：テスト環境でレプリケーションシステムを実装してテストします。パブリケーションデータのサブセットでレプリケーションシステムを試して、レプリケーションプロセスが期待どおりに機能することを確認します。結果の複製されたテーブルがアプリケーションで期待どおりに使用できることを確認してください。完全な実稼働環境でレプリケーションプロセスにかかると予想される時間に関する予備的なメトリックを確立します。

手順6：運用環境でレプリケーションシステムを実装およびテストします。

2.4.2 Design Considerations

レプリケーションシステムを設計するときは、次の点に注意してください。

•	マルチマスターレプリケーションは、Postgresデータベースでのみサポートされています。さらに、Advanced Serverデータベースは、同じ互換モード（すべてOracleまたはすべてPostgreSQL）で実行されている必要があります。

•	すべてのパブリケーションが1つのパブリケーションデータベース定義に従属する場合、Oracleテーブルは最大で1つのパブリケーションのメンバーになることができます。ただし、各パブリケーションが異なるパブリケーションデータベース定義に従属している場合、Oracleテーブルは複数のパブリケーションのメンバーになることができます。

•	Postgresテーブルは、最大1つのパブリケーションのメンバーになることができます。

•	パブリケーションで使用される各テーブルには、プライマリキーが必要です。ただし、スナップショットのみのパブリケーションでは、プライマリキーは不要です。

•	パブリケーションを作成する前に、テーブル定義が確立されていることを確認してください。セクション 7.8で説明されているようにDDL変更レプリケーション機能が使用されない限り、テーブル定義が変更された場合、関連するサブスクリプションとともにテーブルを含むパブリケーションを削除して再作成する必要があります。同じことが、マスター定義ノードとそれに関連するマスターノードのテーブル定義にも当てはまります。レプリケーションの失敗は、レプリケーション履歴で確認できます。

•	ビューは、スナップショットのみのパブリケーションのメンバーになることができます。サブスクリプションデータベースでは、ビューはテーブルとして複製されます。

•	パブリケーションには複数のサブスクリプションがあります。

•	サブスクリプションは、最大で1つのパブリケーションに関連付けることができます。

•	データベースには、パブリケーションとサブスクリプションの両方を含めることができます。

•	特定のパブリケーションサーバーは、1つのマルチマスターレプリケーションシステムのみをサポートできます。特定のパブリケーションサーバーに従属して作成されたすべてのマスターノードは、同じマルチマスターレプリケーションシステムの一部であると想定されます。

•	サブスクリプションの結果として作成されたテーブルは、別のパブリケーションで使用できます。したがって、パブリケーションはサブスクリプションにデータを複製できます。サブスクリプションは、パブリケーションで別のサブスクリプションに複製するために使用でき、カスケードレプリケーションアーキテクチャを作成します。

•	パブリケーションとそのサブスクリプションに使用できるデータベースサーバーの組み合わせと構成には制限があります。これらの制限の詳細については、 セクション 10.1.3を参照してください。

•	複製を行うため、または複製システムで構成、操作、または変更を実行する前に、すべての複製システムコンポーネントが実行されている必要があります。 （xDBレプリケーションコンソールは、レプリケーションシステムの構成と変更に使用されます。レプリケーションを実行するために、xDBレプリケーションコンソールを実行する必要はありません。）

•	一般に、レプリケーションシステムの作成順序は次のとおりです。1）レプリケーションシステムで使用する必要な物理データベース、データベースユーザー名、テーブル、およびビューを作成します。 2）xDB Replication ConsoleまたはxDB Replication Server CLIを使用して、複製システムの論理コンポーネントを定義します。 3）レプリケーションを実行します。

•

一般に、シングルマスターレプリケーションシステムの削除順序は次のとおりです。1）xDB Replication ConsoleまたはxDB Replication Server CLIを使用して、サブスクリプション（サブスクリプションノード）から始めて、その親コンポーネント（サブスクリプションデータベースノード）。 2）サブスクリプションサーバーが不要になった場合は、登録を解除します。 3）パブリケーションに対して同じプロセスを繰り返します。 4）すべてのレプリケーションシステムの論理コンポーネントを削除した後（パブリケーションサーバーとサブスクリプションサーバーを除く）、Oracle、SQL Server、またはPostgresの物理データベースオブジェクトを削除できます。 SQLコマンドラインユーティリティなどを使用して、コントロールスキーマオブジェクトを手動で削除しないでください。これを行うと、xDB Replication ConsoleおよびxDB Replication Server CLIが動作不能になる場合があります。 （この問題が発生した場合は、セクション10.3.4.3を参照してください。）xDB Replication ConsoleまたはxDB Replication Server CLIを使用してレプリケーションシステムの論理コンポーネントを削除すると、物理データベースからコントロールスキーマオブジェクトが自動的に削除されます。

•

マルチマスターレプリケーションシステムの削除順序は次のとおりです。1）非MDNノードのパブリケーションデータベース定義で始まるxDB Replication ConsoleまたはxDB Replication Server CLIを使用して、レプリケーションシステムの論理コンポーネントを削除します。 2）マスター定義ノードの下からパブリケーションを削除します。 3）マスター定義ノードのパブリケーションデータベース定義を削除します。 4）すべてのレプリケーションシステムの論理コンポーネントを削除した後（おそらくパブリケーションサーバーを除く）、Postgresの物理データベースオブジェクトを削除できます。 SQLコマンドラインユーティリティなどを使用して、コントロールスキーマオブジェクトを手動で削除しないでください。これを行うと、xDB Replication ConsoleおよびxDB Replication Server CLIが動作不能になる場合があります。

2.4.3 Restrictions on Replicated Database Objects

サブスクリプションがシングルマスターレプリケーションシステムで作成されると、テーブル定義と、パブリケーションテーブルに関連付けられているほとんどのデータベースオブジェクトと属性が、サブスクリプションサーバーによってサブスクリプションデータベースに作成されます。

そのように選択した場合、マスターノードがマルチマスターレプリケーションシステムに追加されると、同じプロセスが自動的に発生します。パブリケーションテーブルに関連付けられたテーブル定義とほとんどのデータベースオブジェクトと属性は、パブリケーションサーバーによって新しく追加されたマスターノードに作成できます。

以下は、シングルマスターまたはマルチマスターのいずれかのレプリケーションシステムで、パブリケーションからレプリケートされるデータベースオブジェクトとテーブル属性のリストです。

•

テーブル

•	サブスクリプションデータベースのテーブルとして作成されたビュー（スナップショットのみのパブリケーション用）

•

主キー

•

非ヌル制約

•

ユニークな制約

•

チェック制約

•

インデックス

注：外部キー制約は、シングルマスター複製システムのパブリケーションまたはサブスクリプションサーバーによって複製されません。ただし、マルチマスター複製システムでは、外部キー制約はマスター定義ノードから他のマスターノードに複製されます。

注：シーケンス（ CREATE SEQUENCEステートメントによって作成されたデータベースオブジェクト）は、シングルマスターレプリケーションシステムのパブリケーションデータベースからサブスクリプションデータベースにレプリケートされません。また、シーケンスは、マルチマスター複製システム内のマスター定義ノードから他のマスターノードに複製されません。

xDB Replication Serverには、複製できる表のタイプにいくつかの制限があります。

2.4.3.1 Restrictions on Oracle Database Objects

特定のタイプのOracleパーティションテーブルを複製できます。詳細については、セクション 10.4.1.4を参照してください。

Oracleグローバル一時テーブルは複製できません。

次のデータ型を含むOracleテーブルは複製できません。

•

BFILE

•	BINARY_DOUBLE

•	BINARY_FLOAT

•

MLSLABEL

•

XMLTYPE

次のデータ型のOracleテーブルは、スナップショットのみのパブリケーションで使用できますが、同期レプリケーションでは使用できません。

•

BLOB

•

CLOB

•

LONG

•

LONG RAW

•

NCLOB

•

RAW

2.4.3.2 Restrictions on SQL Server Database Objects

次のデータ型を含むSQL Serverテーブルは複製できません。

•

GEOGRAPHY

•

GEOMETRY

•	SQL_VARIANT

注：特定の条件下でSQL_VARIANTデータ型を含むテーブルを複製する方法については、セクション10.4.6を参照してください。

次のデータ型のSQL Serverテーブルは、スナップショットのみのパブリケーションで使用できますが、同期レプリケーションでは使用できません。

•

BINARY

•

IMAGE

•

NTEXT

•	NVARCHAR(max)

•

TEXT

•

TIMESTAMP

•

VARBINARY

•	VARBINARY(max)

2.4.3.3 Restrictions on Postgres Database Objects

Postgresパーティションテーブルの複製については、詳細についてセクション 7.10を参照してください。

主キーの一部である列に次のデータ型があるPostgresテーブルは複製できません。

•

BLOB

•

BYTEA

•

RAW

OIDベースのラージオブジェクトを含むPostgresテーブルは複製できません。 OIDベースのラージオブジェクトについては、 pg_largeobjectにあるPostgreSQLコアドキュメントの pg_largeobjectを参照してください 。

https://www.postgresql.org/docs/current/static/catalog-pg-largeobject.html

POINT 、 POLYGONなどの幾何データ型を含むPostgresテーブルは 、Oracleサブスクリプションデータベースに複製できません。

次のデータ型を含むPostgresテーブルは、SQL Serverサブスクリプションデータベースに複製できません。

•

ABSTIME

•

ACLITEM

•

CHKPASS

•

CIRCLE

•

CUBE

•

JSON

•

ROWID

•

SEG

•	任意の ARRAYデータ型（つまり、 data_type []として定義）

•	ユーザー定義のデータ型（つまり、 CREATE TYPE type_name として定義されている ）

範囲データ型の制限

範囲 型と呼ばれるPostgresデータ型は、PostgreSQLバージョン9.2およびAdvanced Serverバージョン9.2で最初にサポートされました。 組み込み範囲タイプは、次の組み込みデータタイプを参照します： int4range 、 int8range 、 numrange 、 tsrange 、 tstzrange 、およびdaterange 。

組み込みの範囲タイプを含むPostgresテーブルは、シングルマスターまたはマルチマスター複製システムのパブリケーションに含めることができます。

ただし、これにより、シングルマスター複製システムのサブスクリプションデータベースまたはマルチマスター複製システムの追加マスターノードに次の制限が生じます。

•	シングルマスターレプリケーションシステムのパブリケーションテーブルに組み込み範囲タイプが含まれている場合、目的のサブスクリプションデータベースのデータベースサーバーがPostgresバージョン9.2以降である場合にのみ、データベースをサブスクリプションデータベースとして追加できます。

•	マルチマスターレプリケーションシステムのマスター定義ノードのパブリケーションテーブルに組み込みの範囲タイプが含まれている場合、この目的のマスターノードのデータベースサーバーがPostgresバージョン9.2または後。

CREATE TYPE AS RANGEコマンドで構築されたカスタム範囲タイプは、xDB Replication Serverではサポートされていません。

2.4.4 Performance Considerations

このセクションでは、パフォーマンスの考慮事項に関するいくつかの一般的なガイドラインについて説明します。

2.4.4.1 When to Use Snapshot or Synchronization

一般に、同期は最後のレプリケーションが発生してからターゲットテーブルにのみ変更を適用するため、最も高速なレプリケーション方法になります。

ただし、各レプリケーション間で行の大部分が変更された場合、スナップショットを使用してターゲット表を完全にリロードする方が、大部分の行で個々のSQLステートメントを実行するよりも高速になる場合があります同期レプリケーション。スナップショットが高速であるかどうか、およびその時点で実験する必要がある場合があります。

スナップショットレプリケーションは、次の特性を持つテーブルのオプションです。

•	テーブルのサイズは比較的小さい

•	レプリケーション間で行の大部分が変更される

同期レプリケーションは、次の特性を持つテーブルに適したオプションです。

•	テーブルはサイズが大きい

•	レプリケーション間で変更される行の割合が少ない

シングルマスターレプリケーションシステムでは、スナップショットレプリケーションを使用してテーブルの1つのグループが一貫して高速にレプリケートされる場合、これらのテーブルはスナップショットのみのパブリケーションの一部にでき、残りのテーブルは同期レプリケーションを使用するパブリケーションのメンバーにできます。

2.4.4.2 When to Use On Demand Replication

xDB Replication ConsoleとxDB Replication Server CLIはどちらも、レプリケーションをすぐに開始する機能を提供します。これは、 オンデマンド複製と呼ばれます。

オンデマンドレプリケーションは、既存のスケジュールがあるかどうかに関係なく、いつでも実行できます。オンデマンド複製では、既存のスケジュールに従って次の複製が行われるようにスケジュールされている日時は変更されません。

パブリケーションがスナップショットのみのパブリケーションである場合、このパブリケーションで実行できるオンデマンドレプリケーションの唯一のタイプはスナップショットです。

パブリケーションがスナップショットのみのパブリケーションではない場合、スナップショット方式または同期方式のいずれかを使用して、オンデマンドレプリケーションを実行できます。

レプリケーションシステムの開発フェーズとテストフェーズでは、通常、オンデマンドレプリケーションを使用して、レプリケーションを即座に強制的に実行し、結果を分析できるようにします。

レプリケーションシステムの運用準備が整ったら、通常はスケジュールを使用して、レプリケーションを定期的に無人で実行できるようにします。スケジュールの作成方法については、セクション 7.2を参照してください 。

通常のスケジュールよりも早く複製を強制的に実行したい場合があります。オンデマンドレプリケーションを実行する理由には、次のものがあります。

•	ソーステーブルへの変更の数は通常より速い速度で増加しているため、定期的にスケジュールされた同期時間を待って、蓄積されたすべての変更を複製することは望ましくありません。

•	同期を実行するようにレプリケーションシステムを設定しましたが、この場合、ソーステーブルに対して異常に多数の変更が行われたため、多数のSQLステートメントを実行するのではなく、すべてのソーステーブルのスナップショットを実行します。ターゲットテーブルに対して。

•	ターゲットテーブルの行に直接変更が加えられたため、対応するソーステーブルと同じ内容がなくなりました。オンデマンドスナップショットレプリケーションを実行して、ソーステーブルの現在のセットからターゲットテーブルのすべての行を再ロードできます。

注：マルチマスター複製システムでは、オンデマンドのスナップショットは、マスター定義ノードから別のマスターノードにのみ作成できます。

シングルマスター複製システムのオンデマンド複製の実行方法については、セクション 5.4を参照してください 。マルチマスター複製システムについては、セクション6.5を参照してください。

2.4.5 Distributed Replication

xDB Replication Serverは、ネットワーク上の別々のマシンでレプリケーションシステムのコンポーネントを実行できる柔軟性を提供します。

実際、xDB Replication Serverは、各コンポーネント（パブリケーションサーバー、サブスクリプションサーバー、パブリケーションデータベース、サブスクリプションデータベース、およびマスターノード）がすべて同じホスト上で実行され、各コンポーネントが独自の個別のホストで実行するか、コンポーネントの任意の組み合わせを任意の数のホストで実行できます。

ただし、実際的な目的のために、2つの基本的なシナリオがあります。最も単純なケースは、すべてのコンポーネントが同じホスト上にある場合です。もう1つのケースは、他のレプリケーションシステムコンポーネントとは別のホストで実行されているOracleまたはSQL Serverデータベースサーバーがある場合です。

このセクションでは、各シナリオの長所と短所について説明します。

2.4.5.1 Single Host

レプリケーションシステムの最も単純な実装は、すべてのレプリケーションコンポーネントが単一のホストで実行される場合です。これは、PostgreSQLまたはAdvanced Serverのインストール、完全なxDB Replication Serverのインストール（パブリケーションサーバーとサブスクリプションサーバー）、およびOracleまたはSQL Serverデータベースサーバーが同じマシンに存在することを意味します。

Postgresパブリケーションまたはサブスクリプションデータベースは、場合によっては、ホストにPostgresをインストールしたときに作成される初期データベースクラスターに存在できます。

図2-21-単一ホスト複製システム

単一ホスト複製システムの利点は次のとおりです。

•	特に大きなスナップショットが含まれる場合、レプリケーションデータをプッシュするネットワークがないため、パフォーマンス上の利点があります。

•	設定はずっと簡単です。複製システムの論理コンポーネントを作成するとき、すべてのコンポーネントのIPアドレスは同じです。

単一ホスト複製システムの欠点は次のとおりです。

•	レプリケーションシステムとデータベースサーバーはすべて1台のマシンのリソースを消費するため、データベースアプリケーションのパフォーマンスに悪影響を及ぼす可能性があります。

•	パブリケーションデータベースとサブスクリプションデータベースは地理的に異なる場所にある可能性があり、そのため複数のネットワークホストが必要です。

•	サイトでは、xDB Replication Serverを同じマシンに配置できないように、OracleまたはSQL Serverデータベースサーバー専用のホストを使用する必要がある場合があります。

2.4.5.2 Single-Master Replication Distributed Hosts

xDB Replication Serverを使用すると、パブリケーションデータベースとサブスクリプションデータベースのいずれかまたは両方を別々のホストに配置して、レプリケーションシステムを構築できます。これを次の図に示します。

図2-22-分散ホスト上のOracleデータベースサーバー

パブリケーションデータベースの代わりに、またはパブリケーションデータベースに加えて、同じリモートディストリビューションをサブスクリプションデータベースに使用できます。

分散ホスト複製システムの利点は次のとおりです。

•	レプリケーションシステムとデータベースサーバーは、それぞれ独自のマシンのリソースを消費できます。これらのリソースは、個別に選択して調整できます。

•	パブリケーションデータベースとサブスクリプションデータベースは、地理的に異なる場所に配置できます。

•	データベースサーバーのみがホストで実行できる場合、より強力なデータベースセキュリティを適用できます。

分散ホスト複製システムの欠点は次のとおりです。

•	特に大きなスナップショットが含まれる場合は、レプリケーションデータをプッシュするネットワークがあるため、パフォーマンスが低下する可能性があります。

•	PostgresデータベースをxDB Replication Serverとは異なるホストで実行する必要がある場合、インストールはより複雑になります。これには、2つの別個のホストにPostgresをインストールすることが含まれます。

•	構成はより複雑です。分散コンポーネントが通信できるように、ネットワークとファイアウォールを適切に構成する必要があります。複製システムの論理コンポーネントを作成するときは、すべてのコンポーネントの正しいIPアドレスを使用する必要があります。さらに、ネットワーク環境で変更された場合、レプリケーションシステムの制御スキーマで正しいIPアドレスを最新の状態に保つ必要があります。

2.4.5.3 Multi-Master Replication Distributed Hosts

マルチマスターレプリケーションシステムでは、マスターノードを実行しているPostgresデータベースサーバーを単一または複数のホストで実行できます。次の例は、別々のホスト上のデータベースサーバーで実行されている2つのマスターノードと、パブリケーションサーバーと同じデータベースサーバーで実行されているマスターノードを示しています。

図2-23-分散ホストでのマルチマスターレプリケーション

3 インストールとアンインストール

この章では、xDB Replication Serverをインストールおよびアンインストールする方法について説明します。

xDB Replication Serverのインストールは、さまざまな方法で実行できます。

•	グラフィカルユーザーインターフェイスの使用

•	テキストモードまたは無人モードでコマンドラインコンソールからxDB Replication Serverインストーラープログラムを実行する

•	Yumパッケージマネージャーを使用したxDB RPMパッケージのインストール

xDB Replication Serverの最も一般的なインストールは、PostgreSQLを使用しているかAdvanced Serverを使用しているかに応じて、Stack BuilderまたはStackBuilder Plusによって呼び出されるグラフィカルユーザーインターフェイスを使用して行われます。

•	PostgreSQLの場合。 PostgreSQLをインストールした後、Stack Builderを使用してxDB Replication Serverをインストールします。

•	Advanced Serverの場合。 Advanced Serverをインストールした後、StackBuilder Plusを使用してxDB Replication Serverをインストールします。

グラフィカルユーザーインターフェイスを使用したくない場合は、xDB Replication ServerインストーラープログラムをEnterpriseDB Webサイトからダウンロードし、テキストモードまたは無人モードおよびグラフィカルユーザーインターフェイスモードで呼び出すことができます。コマンドラインからxDB Replication Serverをインストールする手順については、セクション 3.2を参照してください 。

xDB Replication Server製品はRPMパッケージとしても利用できます。この場合、インストールにはYumパッケージマネージャーが使用されます。 RPMパッケージからxDB Replication Serverをインストールする手順については、セクション 3.3を参照してください 。

セクション 3.1では 、Stack BuilderまたはStackBuilder Plusのグラフィカルユーザーインターフェイスを使用したxDB Replication Serverのインストールについて説明します。

注：古いバージョンのxDB Replication Serverと既存のレプリケーションシステムがある場合は、xDB Replication Serverをインストールする前にセクション10.2を確認してください。

後でシステムからxDB Replication Serverを削除する場合は、グラフィカルユーザーインターフェイスを使用して最初にインストールした場合、またはコマンドラインからインストーラープログラムを起動してxDB Replication Serverをアンインストールする方法についてセクション 3.6を参照してください 。 RPMパッケージからインストールされたxDB Replication Serverをアンインストールする方法については、セクション3.7を参照してください。

3.1 Stack BuilderまたはStackBuilder Plusを使用したインストール

Stack BuilderとStackBuilder Plusは、アドオン製品とPostgreSQLおよびAdvanced Serverのアップデートのダウンロードとインストールに使用されるプログラムです。 Stack BuilderはPostgreSQLに使用されます。 StackBuilder PlusはAdvanced Serverに使用されます。

Stack BuilderとStackBuilder Plusは、機能とルックアンドフィールが非常に似ており、主に提供される製品のリストが異なります。

このセクションでは、StackBuilder Plus for Advanced Serverを使用したxDB Replication Serverのインストールについて説明します。 Stack Builderを使用してPostgreSQLにインストールする場合のインストールプロセスが異なる場合の手順に注意してください。

手順1： xDB Replication Serverコンポーネント（xDB Replication Console、パブリケーションサーバー、またはサブスクリプションサーバー）をインストールするホストにJava Runtime Environment（JRE）バージョン1.7以降をインストールする必要があります。 Oracle JavaやOpenJDKなどのJava製品を使用できます。

ホストオペレーティングシステムの指示に従って、Javaランタイムをインストールします。

Windowsの場合のみ：システム環境変数JAVA_HOMEが、xDB Replication Serverで使用するJREバージョンとビット数（32ビットまたは64ビット）のJREインストールディレクトリに設定されていることを確認してください。 Windowsプラットフォーム用のxDB Replication Serverインストーラーには、32ビット版と64ビット版の両方が含まれています。 JAVA_HOME設定は、xDB Replication Serverの32ビットバージョンと64ビットバージョンのどちらをインストールするかを決定しJAVA_HOME 。 （ JAVA_HOMEが設定されていない場合、 Pathシステム環境変数で最初に検出されたJREバージョンによって、インストールするxDB Replication Serverのバージョンが決まります。）

注： 9.3より前のAdvanced Serverバージョンの場合、JavaランタイムがAdvanced Serverインストールプロセスの一部として提供およびインストールされますが、ホストに別個のJavaランタイムシステムを事前にインストールしておく必要があります。 xDB Replication Serverのインストールプロセスでは、Advanced Serverに付属のJavaランタイムは使用されません。

注： xDB Replication Serverのインストールが完了すると、Javaランタイムプログラムへのパスは、xDB Replication Serverが使用するxDBスタートアップコンフィギュレーションファイルに保存されます。 xDBスタートアップ構成ファイルに設定されているJavaランタイムプログラムへのパスが正しいことを確認します。このファイルの場所については、セクション3.5を参照してください。

ステップ2：ホストのアプリケーションメニューから、Postgresメニューを開き、Stack BuilderまたはStackBuilder Plusを選択します。

図3‑1-Postgresアプリケーションメニュー

ステップ3（Linuxのみ）： Linuxホストに応じて、 rootアカウントのパスワードを要求するダイアログボックスまたはプロンプトが表示されます。 rootパスワードを入力し、[OK]ボタンをクリックします。

図3‑2-ルートアカウントパスワードの入力

ステップ4： StackBuilder Plusのようこそ画面が表示されます。ドロップダウンリストからPostgresインストールを選択し、[次へ]ボタンをクリックします。

図3‑3-StackBuilder Plusのようこそ画面

ステップ5（Advanced Serverの場合）： EnterpriseDB Toolsノードを展開し、Replication Serverのチェックボックスをオンにします。 [次へ]ボタンをクリックします。

注：次の図はReplication Server v6.0を示していますが、Replication Server v6.2でも同じプロセスを使用してください。

図3‑4-StackBuilder Plusアプリケーション

手順5（PostgreSQLの場合）： [登録が必要な試用版]ノードを展開し、[EnterpriseDBツール]ノードを展開します。 EnterpriseDB Toolsリストの下にあるReplication Serverのボックスをチェックし、Nextボタンをクリックします。

図3‑5-Stack Builderアプリケーション

図3‑6-PostgreSQL用のEnterpriseDBツール

ステップ6（Advanced Serverのみ）：アカウント登録画面で、EnterpriseDBユーザーアカウントの電子メールアドレスとパスワードを入力するか、リンクをクリックします。この場合、EnterpriseDBの登録ページに移動します。アカウントを作成できるウェブサイト。 [次へ]ボタンをクリックします。

注（PostgreSQLのみ）：手順7に進みます 。PostgreSQLを使用している場合、プロセスの後半でアカウント登録が行われます。

図3‑7-EnterpriseDBアカウントの登録

ステップ7：選択したパッケージのリストにReplication Serverが表示されることを確認します。 [次へ]ボタンをクリックします。

図3‑8-選択したパッケージ

Replication Serverパッケージのダウンロードの進行状況を示す情報ボックスが表示されます。これには数分かかる場合があります。

図3‑9-ダウンロードの進行状況

手順8： Replication Serverパッケージのダウンロードが完了すると、xDB Replication Serverのインストールを開始する次の画面が表示されます。 [次へ]ボタンをクリックします。

注： xDB Replication Serverをもう一度インストールする場合は、[インストールをスキップ]ボックスをチェックできます。

図3‑10 –インストールの開始

ステップ9：インストール言語を選択し、[OK]ボタンをクリックします。

図3‑11-インストール言語

ステップ10： [xDB Replication Serverのセットアップ]画面で、[次へ]ボタンをクリックします。

図3‑12 – xDBレプリケーションサーバーのセットアップ

ステップ11：ライセンス契約を読みます。契約に同意する場合は、「同意する」ラジオボタンを選択し、「次へ」ボタンをクリックします。

図3‑13-ライセンス契約

手順12： xDB Replication Serverコンポーネントをインストールするディレクトリを参照するか、表示されているデフォルトの場所にコンポーネントをインストールできるようにします。 [次へ]ボタンをクリックします。

図3‑14-インストールディレクトリ

ステップ13：特定のxDB Replication Serverコンポーネントをこの特定のホストにインストールしたくない場合は、コンポーネント名の隣のボックスをオフにします。 [次へ]ボタンをクリックします。

図3‑15-コンポーネントの選択

ステップ14：アカウント登録画面で、該当するラジオボタンを選択します。 [次へ]ボタンをクリックします。

図3‑16-アカウント登録

EnterpriseDBユーザーアカウントを持っていない場合は、EnterpriseDB Webサイトの登録ページに移動します。

すでにEnterpriseDBユーザーアカウントを持っている場合は、次の画面に示すように、EnterpriseDBユーザーアカウントのメールアドレスとパスワードを入力します。 [次へ]ボタンをクリックします。

図3‑17-私のEnterpriseDBアカウント

ステップ15： xDB管理者の情報を入力します。

注：この時点から、パブリケーションおよびサブスクリプションサーバーの登録プロセス中に必要になるため、これらの画面に入力した値を記録することをお勧めします。

次のフィールドに値を入力します。

•	管理者ユーザー。このホストで実行されているパブリケーションサーバーまたはサブスクリプションサーバーの登録など、xDB Replication Serverの特定の使用を認証するためのxDB管理者ユーザー名。管理ユーザー名には、任意の英数字文字列を入力できます。デフォルトの管理ユーザー名はadminです。

•	管理者のパスワード。 [管理者ユーザー]フィールドで指定されたxDB管理者用に選択したパスワード。

図3‑18-xDB管理ユーザー情報

管理ユーザーと管理パスワード（暗号化された形式）は、 \etc\edb-repl.conf （WindowsホストのXDB_HOME \etc\edb-repl.conf ） という名前の /etc/edb-repl.conf レプリケーション構成ファイルに保存されます。 [次へ]ボタンをクリックします。

ステップ16（公開サーバーが選択されたコンポーネントである場合のみ）：公開サーバーが実行される利用可能なポートを入力します。デフォルトのポート番号は9051です。 [次へ]ボタンをクリックします。

図3‑19-公開サーバーの詳細

ステップ17（サブスクリプションサーバーが選択されたコンポーネントの場合のみ）：サブスクリプションサーバーが実行される使用可能なポートを入力します。デフォルトのポート番号は9052です。 [次へ]ボタンをクリックします。

図3‑20-サブスクリプションサーバーの詳細

ステップ18：パブリケーションサーバーまたはサブスクリプションサーバーを実行するオペレーティングシステムアカウントの場合、 postgres （Oracle互換構成モードでインストールされたAdvanced Serverを使用している場合はenterprisedb ）を入力します。

図3-21-パブリケーション/サブスクリプションサーバーのオペレーティングシステムアカウント

ステップ19： [インストールの準備完了]画面で、[次へ]ボタンをクリックします。

図3‑22-インストールの準備完了

xDB Replication Serverが選択したコンポーネントのインストールの進行状況を示す情報ボックスが表示されます。これには数分かかる場合があります。

図3-23-インストールの進行状況

ステップ20：インストールが完了すると、次の画面が表示されます。 [完了]ボタンをクリックします。

図3‑24 – xDB Replication Serverのインストール完了

ステップ21： StackBuilder Plus Installation Complete画面で、Finishボタンをクリックします。

図3-25-StackBuilder Plusのインストール完了

xDB Replication Serverが正常にインストールされると、セクション 3.5で 説明されているように、ホスト環境にディレクトリ構造とファイルが作成されます 。

3.2 コマンドラインからのインストール

このセクションでは、LinuxまたはWindowsのコマンドラインコンソールからxDB Replication Serverをインストールする方法を説明します。

コマンドラインインストールを実行するには、基本的に3つの方法があります。

•	テキスト。インストーラーを呼び出してコマンドラインからインストールを実行するときに--mode textパラメーターを含め、その間にユーザー入力のプロンプトが表示されます。

•	無人。インストーラーを呼び出してユーザー入力なしでインストールを実行する場合は、 --mode unattendedパラメーターを含めます。この場合、インストーラーを呼び出すときにコマンドラインで--optionfileパラメーターを指定するか、パラメーター設定を含むファイルを指定するために--optionfileパラメーターを使用する必要があります。

•	抽出のみ。 --extract-onlyパラメーターを指定してインストーラーを起動し、完全なインストールを実行するために必要なroot権限を持っていない場合にのみファイルを抽出します。

xDB Replication Serverインストーラープログラムは、EnterpriseDB Webサイトから直接ダウンロードするか、Stack BuilderまたはStackBuilder Plusを使用してダウンロードできます。

インストーラーのプログラム名は、入手方法によって異なる場合があります。以下は、コマンドラインインストールを示すいくつかの例です。

注：コマンドラインからEnterpriseDB製品をインストールする方法の詳細については、次の場所にある 『 EDB Postgres Advanced Serverインストールガイド』を参照してください。

https://www.enterprisedb.com/resources/product-documentation

注： xDB Replication Serverコンポーネント（xDB Replication Console、パブリケーションサーバー、またはサブスクリプションサーバー）をインストールするホストにJava Runtime Environment（JRE）バージョン1.7以降をインストールする必要があります。 Oracle JavaやOpenJDKなどのJava製品を使用できます。

ホストオペレーティングシステムの指示に従って、Javaランタイムをインストールします。

注： 9.3より前のAdvanced Serverバージョンの場合、JavaランタイムがAdvanced Serverインストールプロセスの一部として提供およびインストールされますが、ホストに別個のJavaランタイムシステムを事前にインストールしておく必要があります。 xDB Replication Serverのインストールプロセスでは、Advanced Serverに付属のJavaランタイムは使用されません。

次の例は、xDB Replication Serverのインストールをテキストモードで開始する方法を示しています。

$ ./xdbreplicationserver-6.1.0-alpha-1-linux-x64.run --mode text

Language Selection

 

Please select the installation language

[1] English - English

.

.

.

Please choose an option [1] :

----------------------------------------------------------------------------

Welcome to the Postgres Plus xDB Replication Server Setup Wizard.

.

.

.

次の例は、オプションファイルを使用して無人モードでインストールを開始する方法を示しています。

$ su root

Password:

$ ./xdbreplicationserver-6.1.0-alpha-1-linux-x64.run --optionfile /home/user/xdb_config

以下は、オプションファイル xdb_config 内容です 。

mode=unattended

existing-user=user@xyz.com

existing-password=password

installer-language=en

prefix=/opt/PostgreSQL/EnterpriseDB-xDBReplicationServer

enable-components=repconsole,pubserver,subserver

admin_user=admin

admin_password=password

pubport=9051

subport=9052

serviceaccount=enterprisedb

servicepassword=password

以下は、インストーラープログラムの実行時に指定できるパラメーターの一覧です。パラメーターが指定されていない場合、ほとんどのパラメーターにはデフォルト値があります。

パラメーター

--help

有効なオプションのリストを表示します。

--version

製品のバージョン情報を表示します。

--extract-only { yes | no }

yesまたは1を指定して、インストールを実行せずにxDB Replication Serverコンポーネントとファイルを抽出します。 noまたは0を指定して、xDB Replication Serverのインストールも実行します。デフォルトはnoまたは0です。

--unattendedmodeui { none | minimal | minimalWithDialogs }

無人インストール中にユーザーインターフェイスを表示する範囲を指定します。進行状況バーを表示しnone場合は、 none 指定します。プログレスバーを表示する場合はminimal指定します。エラーが発生した場合にダイアログボックスで進行状況バーを表示する場合は、 minimalWithDialogs指定します。デフォルトはminimalです。

--optionfile filename

parameter= value形式のインストール構成パラメーターを含む指定されたファイルを使用します 。

--mode { qt | gtk | xwindow | text | unattended }

インストールモードを指定します。 qtを指定して、Qtグラフィカルツールキットを使用します。 Gtkグラフィカルツールキットを使用するにはgtkを指定します（Linuxのみ）。指定xwindow （Linuxのみ）X Windowsのグラフィカルツールキットを使用します。コマンドラインコンソールでインストールするtextを指定しtext （Linuxのみ）。ユーザー入力を要求せずにインストールを実行するには、 unattendedを指定します。デフォルトはqtです。

--debugtrace debug_logfile

デバッグログファイルを作成するには、このパラメーターを指定します。

--debuglevel { 0 | 1 | 2 | 3 | 4 }

デバッグログファイルに書き込む詳細の量を指定します。値が大きいほど詳細が表示されます。デフォルトのレベルは 2です。

--existing-user edb_user_account

EnterpriseDBユーザーアカウントを指定します。 （これは、EnterpriseDB Webサイトの登録ページでアカウントを作成したときに識別子として使用される電子メールアドレスです。）

--existing-password edb_user_password

EnterpriseDBユーザーアカウントのパスワードを指定します。

--installer-language { en | zh_CN | zh_TW | ja | ko }

インストール言語を指定します。英語の場合はenを指定します。簡体字中国語にはzh_CNを指定します。繁体字中国語にはzh_TWを指定します。日本語にjaを指定します。韓国語にはkoを指定します。デフォルトはenです。

--prefix installation_directory

xDB Replication Serverコンポーネントがインストールされるディレクトリ。 Linuxシステムのデフォルトは /opt/PostgreSQL/EnterpriseDB-xDBReplicationServerです。 Windowsシステムの場合、デフォルトはC:\Program Files\PostgreSQL\EnterpriseDB-xDBReplicationServerです。

--enable-components {[ repconsole ] [,pubserver ] [,subserver ]}

インストールするxDB Replication Serverコンポーネントを指定します。 xDB Replication ConsoleおよびxDB Replication Serverコマンドラインインターフェースにrepconsoleを指定します。 xDB出版サーバーのpubserverを指定します。指定subserver XDBのサブスクリプションサーバーのために。このコンマ区切りリストには、少なくとも1つのコンポーネントを含める必要があります。デフォルトはrepconsole,pubserver,subserverです。

--disable-components {[ repconsole ] [,pubserver ] [,subserver ]}

インストールから除外するxDB Replication Serverコンポーネントを指定します。デフォルトは空のリストです。

--admin_user admin_user

このホストで実行されているパブリケーションサーバーまたはサブスクリプションサーバーの登録など、xDB Replication Serverの特定の使用を認証するためのxDB管理者ユーザー名。管理ユーザー名には、任意の英数字文字列を入力できます。デフォルトの管理ユーザー名は adminです。

--admin_password admin_password

xDB管理者用に選択したパスワード。このパラメーターにはデフォルトはありません。

--pubport port

パブリケーションサーバーのポート番号。デフォルトは 9051です。

--subport port

サブスクリプションサーバーのポート番号。デフォルトは 9052です。

--serviceaccount account_name

パブリケーションサーバーまたはサブスクリプションサーバーを実行するオペレーティングシステムアカウント。デフォルトは postgresです。

--servicepassword account_password

オペレーティングシステムアカウントのパスワード。このパラメーターにはデフォルトはありません。

xDB Replication Serverが正常にインストールされると、セクション 3.5で 説明されているように、ホスト環境にディレクトリ構造とファイルが作成されます 。

3.3 xDB RPMパッケージのインストール

xDB Replication Serverは、EDB Yumリポジトリで利用可能なRPMパッケージとして提供されます。 Yumパッケージマネージャーを使用して、RPMパッケージからxDB Replication Serverをインストールします。

Yumの使用については、次の場所にあるYumプロジェクトのWebサイトを参照してください。

http://yum.baseurl.org/

EDB Yumリポジトリーに資格情報を要求するには、次のWebサイトにアクセスしてください。

https://www.enterprisedb.com/repository-access-request

EDB Yumリポジトリの使用については、次の場所にあるEnterpriseDB Webサイトから入手可能なEDB Postgres Advanced Serverインストールガイドの 第3章を参照してください 。

https://www.enterprisedb.com/resources/product-documentation

注：以下では主にxDB Replication Serverバージョン6.2のインストールについて説明しますが、これらの異なるバージョンのインストールを区別するために、以前のxDB Replication ServerバージョンのRPMパッケージへのアクセスについても説明します。

各xDB Replication Serverコンポーネントは、個別のRPMパッケージとして利用できます。したがって、1つの yum installコマンドですべてのxDB Replication Serverコンポーネントを yum installできます。または、特定のRPMパッケージのみをインストールすることにより、選択した個々のコンポーネントをインストールすることもできます。

次の表に、RPMパッケージとそれに含まれるxDB Replication Serverコンポーネントを示します。

表3‑1-xDB Replication ServerコンポーネントRPMパッケージ

Package Name	xDB Replication Server Component
ppas-xdb	All components
ppas-xdb-console	xDB Replication Console and the xDB Replication Server Command Line Interface
ppas-xdb-publisher	Publication server
ppas-xdb-subscriber	Subscription server
ppas-xdb-libs	Library files required by all components

Advanced Serverサーバーのlibsパッケージは、xDB RPMパッケージコンポーネントをインストールするときにYumからアクセスできる必要があります。 edb-as xx -server-libsパッケージには、バージョン9.6以降のための高度なサーバーのリポジトリのパッケージのコンポーネントです。 ppas xx -server-libsパッケージは、バージョン9.5以前のAdvanced Serverリポジトリパッケージのコンポーネントです。ステップ3は、YumがサーバーlibsパッケージにアクセスできるようにAdvanced Serverリポジトリへのアクセスを有効にする方法を示しています。

前提条件

xDBをインストールする前に、epel-releaseパッケージをインストールする必要があります。

yum -yインストールhttps://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm

注： CentOS-Base.repo ファイル（ /etc/yum.repos.dにあります ）で [extras]リポジトリー定義を有効にする必要がある 場合があり ます 。

パッケージをインストールするには、 rootアカウントとして次のコマンドを呼び出します。

yum install package_name

package_nameは、前述の表の「パッケージ名」列にリストされているパッケージのいずれかです。

たとえば、すべてのxDBコンポーネントをインストールするには、次を呼び出します。

yum install ppas-xdb

xDB Replication ConsoleとxDB Replication Serverコマンドラインインターフェイスのみをインストールするには、次を呼び出します。

yum install ppas-xdb-console

パブリケーションサーバーのみをインストールするには、次を呼び出します。

yum install ppas-xdb-publisher

注：すべてのxDBコンポーネントは依存しているため、サーバーライブラリパッケージのインストールが必要ですが、Yumを使用すると、xDBコンポーネントのインストール時にサーバーライブラリへの依存関係が認識されます。 Yumは、選択したxDB RPMパッケージとともに、有効なAdvanced Serverリポジトリからサーバーlibsパッケージを自動的にインストールします。

以下は、すべてのxDBコンポーネントを使用して完全なxDB Replication Serverのインストールを実行する手順です。

手順1： xDB Replication Serverコンポーネント（xDB Replication Console、パブリケーションサーバー、またはサブスクリプションサーバー）をインストールするホストにJava Runtime Environment（JRE）バージョン1.7以降をインストールする必要があります。 Oracle JavaやOpenJDKなどのJava製品を使用できます。

ホストオペレーティングシステムの指示に従って、Javaランタイムをインストールします。

注： 9.3より前のAdvanced Serverバージョンの場合、JavaランタイムがAdvanced Serverインストールプロセスの一部として提供およびインストールされますが、ホストに別個のJavaランタイムシステムを事前にインストールしておく必要があります。 xDB Replication Serverのインストールプロセスでは、Advanced Serverに付属のJavaランタイムは使用されません。

ステップ2： EDB Yumリポジトリから、 edb-repoリンクをクリックして、すべてのEnterpriseDB RPMのリポジトリRPMをダウンロードします。

rootアカウントとして、次のコマンドを実行して、このリポジトリ構成パッケージをインストールします。

yum -yインストールhttps://yum.enterprisedb.com/edb-repo-rpms/edb-repo-latest.noarch.rpm

ステップ3：ディレクトリ/etc/yum.repos.dに、リポジトリ構成ファイルedb.repoが作成されます。このファイルには、テキスト[ repository_name ]始まるエントリで示されるEnterpriseDBリポジトリのリストが含まれています。

これらのリポジトリのいずれかのパッケージへのアクセスは、リポジトリエントリで以下を編集してリポジトリを有効にすることで実現されます。

•	EDB Yumリポジトリの要求された資格情報を使用して 、 baseurlパラメーターの <username>:<password>プレースホルダーをユーザー名とパスワードに baseurlます。

•	enabledパラメーターの設定をenabled=1 変更します 。

たとえば、Advanced Serverバージョン9.6のリポジトリからサーバーlibsパッケージにアクセスするには、次のエントリを有効にします。

[edbas96]

name=EnterpriseDB Advanced Server 9.6 $releasever - $basearch

baseurl=http://<username>:<password>@yum.enterprisedb.com/9.6/redhat/rhel-$releasever-$basearch

enabled=1

gpgcheck=1

gpgkey=file:///etc/pki/rpm-gpg/ENTERPRISEDB-GPG-KEY

xDB Replication Serverの目的のバージョンをインストールするために適切なリポジトリを有効にするには、次のエントリのいずれかを有効にします。

•	バージョン6.2をインストールするには、 [enterprisedb-xdb60] エントリを有効にします。

•	以前のバージョンをインストールするには、 [enterprisedb-tools] エントリを有効にし [enterprisedb-tools] 。

どちらのバージョンを選択した場合でも、他のエントリが無効になっていることを確認してください（つまり、選択されていないエントリのパラメータ設定は enabled=0です）。

たとえば、xDB Replication Serverバージョン6.2にアクセスするには、次のエントリを有効にします。

[enterprisedb-xdb60]

name=EnterpriseDB XDB 6.0 $releasever - $basearch

baseurl=http://<username>:<password>@yum.enterprisedb.com/xdb60/redhat/rhel-$releasever-$basearch

enabled=0

gpgcheck=1

gpgkey=file:///etc/pki/rpm-gpg/ENTERPRISEDB-GPG-KEY

ステップ4： xDB Replication Server RPMパッケージをインストールします。

次の構文は、xDB RPMパッケージをインストールします。

yum install ppas-xdb

次に例を示します。

[root@localhost ~]# yum install ppas-xdb

Loaded plugins: fastestmirror, refresh-packagekit, security

Loading mirror speeds from cached hostfile

* base: mirrors.lga7.us.voxel.net

* epel: mirror.steadfast.net

* extras: mirror.vcu.edu

* updates: mirror.vtti.vt.edu

edb-repos | 2.4 kB 00:00

edbas10 | 2.5 kB 00:00

enterprisedb-dependencies | 2.5 kB 00:00

enterprisedb-xdb60 | 2.4 kB 00:00

enterprisedb-xdb60/primary_db | 4.2 kB 00:00

Setting up Install Process

Resolving Dependencies

--> Running transaction check

---> Package ppas-xdb.x86_64 0:6.2.0-1.rhel6 will be installed

--> Processing Dependency: ppas-xdb-subscriber for package: ppas-xdb-6.2.0-1.rhel6.x86_64

--> Processing Dependency: ppas-xdb-publisher for package: ppas-xdb-6.2.0-1.rhel6.x86_64

--> Processing Dependency: ppas-xdb-console for package: ppas-xdb-6.2.0-1.rhel6.x86_64

--> Running transaction check

---> Package ppas-xdb-console.x86_64 0:6.2.0-1.rhel6 will be installed

--> Processing Dependency: ppas-xdb-libs for package: ppas-xdb-console-6.2.0-1.rhel6.x86_64

---> Package ppas-xdb-publisher.x86_64 0:6.2.0-1.rhel6 will be installed

--> Processing Dependency: ppas-libs for package: ppas-xdb-publisher-6.2.0-1.rhel6.x86_64

--> Processing Dependency: libpq.so.5()(64bit) for package: ppas-xdb-publisher-6.2.0-1.rhel6.x86_64

---> Package ppas-xdb-subscriber.x86_64 0:6.2.0-1.rhel6 will be installed

--> Running transaction check

---> Package edb-as10-server-libs.x86_64 0:10.2.7-2.rhel6 will be installed

---> Package ppas-xdb-libs.x86_64 0:6.2.0-1.rhel6 will be installed

--> Finished Dependency Resolution

 

Dependencies Resolved

 

==============================================================================================================================================================

Package Arch Version Repository Size

==============================================================================================================================================================

Installing:

ppas-xdb x86_64 6.2.0-1.rhel6 enterprisedb-xdb60 6.8 k

Installing for dependencies:

edb-as10-server-libs x86_64 10.2.7-2.rhel6 edbas10 536 k

ppas-xdb-console x86_64 6.2.0-1.rhel6 enterprisedb-xdb60 3.0 M

ppas-xdb-libs x86_64 6.2.0-1.rhel6 enterprisedb-xdb60 13 M

ppas-xdb-publisher x86_64 6.2.0-1.rhel6 enterprisedb-xdb60 35 k

ppas-xdb-subscriber x86_64 6.2.0-1.rhel6 enterprisedb-xdb60 12 k

 

Transaction Summary

==============================================================================================================================================================

Install 6 Package(s)

 

Total download size: 17 M

Installed size: 20 M

Is this ok [y/N]: y

Downloading Packages:

(1/6): edb-as10-server-libs-10.2.7-2.rhel6.x86_64.rpm | 536 kB 00:09

(2/6): ppas-xdb-6.2.0-1.rhel6.x86_64.rpm | 6.8 kB 00:00

(3/6): ppas-xdb-console-6.2.0-1.rhel6.x86_64.rpm | 3.0 MB 00:01

(4/6): ppas-xdb-libs-6.2.0-1.rhel6.x86_64.rpm | 13 MB 00:01

(5/6): ppas-xdb-publisher-6.2.0-1.rhel6.x86_64.rpm | 35 kB 00:00

(6/6): ppas-xdb-subscriber-6.2.0-1.rhel6.x86_64.rpm | 12 kB 00:00

-----------------------------------------------------------------------------------------------------------------------------------------------------------------

Total 1.2 MB/s | 17 MB 00:13

Running rpm_check_debug

Running Transaction Test

Transaction Test Succeeded

Running Transaction

Warning: RPMDB altered outside of yum.

Installing : ppas-xdb-libs-6.2.0-1.rhel6.x86_64 1/6

Installing : ppas-xdb-console-6.2.0-1.rhel6.x86_64 2/6

Installing : ppas-xdb-subscriber-6.2.0-1.rhel6.x86_64 3/6

Installing : edb-as10-server-libs-10.2.7-2.rhel6.x86_64 4/6

Installing : ppas-xdb-publisher-6.2.0-1.rhel6.x86_64 5/6

Installing : ppas-xdb-6.2.0-1.rhel6.x86_64 6/6

Verifying : ppas-xdb-6.2.0-1.rhel6.x86_64 1/6

Verifying : ppas-xdb-publisher-6.2.0-1.rhel6.x86_64 2/6

Verifying : ppas-xdb-console-6.2.0-1.rhel6.x86_64 3/6

Verifying : edb-as10-server-libs-10.2.7-2.rhel6.x86_64 4/6

Verifying : ppas-xdb-subscriber-6.2.0-1.rhel6.x86_64 5/6

Verifying : ppas-xdb-libs-6.2.0-1.rhel6.x86_64 6/6

 

Installed:

ppas-xdb.x86_64 0:6.2.0-1.rhel6

 

Dependency Installed:

edb-as10-server-libs.x86_64 0:10.2.7-2.rhel6 ppas-xdb-console.x86_64 0:6.2.0-1.rhel6 ppas-xdb-libs.x86_64 0:6.2.0-1.rhel6

ppas-xdb-publisher.x86_64 0:6.2.0-1.rhel6 ppas-xdb-subscriber.x86_64 0:6.2.0-1.rhel6

 

Complete!

xDB Replication Serverは、ディレクトリの場所 /usr/ppas-xdb- x インストールされます . xここでx . xは、以下に示すxDB Replication Serverのバージョン番号です。

[root@localhost ppas-xdb-6.2]# pwd

/usr/ppas-xdb-6.2

[root@localhost ppas-xdb-6.2]# ls -l

total 84

drwxr-xr-x 2 root root 4096 Feb 23 16:05 bin

drwxr-xr-x 3 root root 4096 Feb 23 16:05 etc

drwxr-xr-x 4 root root 4096 Feb 23 16:05 lib

drwxr-xr-x 2 root root 4096 Feb 23 16:05 share

drwx------ 2 enterprisedb enterprisedb 4096 Feb 20 22:17 xdata

-r--r--r-- 1 enterprisedb enterprisedb 64035 Feb 20 20:40 xdb_3rd_party_licenses.txt

xDB Replication Serverが正常にインストールされると、セクション 3.5で 説明されているように、ホスト環境にディレクトリ構造とファイルが作成されます 。

注：パブリケーションサーバーもサブスクリプションサーバーも、インストール後すぐには実行されていません。残りの手順を確認した後、パブリケーションサーバーを起動する場合は、セクション5.2.1を参照してください。サブスクリプションサーバーの起動については、セクション5.3.1を参照してください。

ステップ5（xDB Replication Server 6.2または6.1の場合）： xDBレプリケーション構成ファイル/etc/edb-repl.confでは、デフォルトのパスワード（ edb ）を管理ユーザーパスワードとして使用するか、または次のパスワードに置き換えることができます。あなたの選択。独自のパスワードを使用する場合は、パスワードの暗号化された形式を生成する方法についてセクション10.4.2を参照してください。 xDBレプリケーション構成ファイルのadmin_passwordパラメーターに暗号化されたパスワードを配置します。デフォルトの管理ユーザー名はadmin設定されており、同様に変更できます。 xDBレプリケーション構成ファイルの詳細は、 2.3.1.3項を参照してください。

ステップ5（xDB Replication Server 5.1の場合）： xDBレプリケーション構成ファイル/etc/edb-repl.conf 、希望するPostgresデータベースへのアクセスを許可するようにパラメーターhost 、 port 、 database 、 user 、およびpasswordが設定されていることを確認しますxDB Controlデータベースとして使用します。現在のデフォルト設定で識別されるデータベース以外を使用する場合は、目的のデータベースを作成し、パラメータを変更して、このデータベースへの接続と認証をxDB制御データベースとして使用できるようにします。

手順6：パブリケーションサーバーとサブスクリプションサーバーの起動時にJavaランタイムプログラムにアクセスできるように、xDBスタートアップ構成ファイルのJAVA_EXECUTABLE_PATHパラメーターを設定する必要があります。 Javaプログラムにアクセスできないためにパブリケーションサーバーまたはサブスクリプションサーバーの起動に失敗した場合は、xDB起動構成ファイルでJavaランタイムプログラムへのパスを設定してください。 xDBスタートアップコンフィギュレーションファイルの詳細については、セクション2.3.1.4を参照してください。このファイルの場所については、セクション3.5を参照してください。

3.3.1 Updating an RPM Installation

既存のxDB RPMインストールがある場合は、 yum を 使用 してリポジトリ構成ファイルをアップグレードし、より新しい製品バージョンに更新できます。 edb を更新するには 。 リポジトリ ファイル、スーパーユーザー権限を想定して入力します。

yum upgrade edb-repo

yum は edb を更新し ます 。 edbで 指定された資格情報で接続するように構成された現在のEDBリポジトリへのアクセスを可能にする レポ ファイル 。 リポジトリ ファイル。次に、yumを使用して、インストールされているパッケージをアップグレードできます。

yum upgrade ppas-xdb

3.4 SLES 12ホストへのxDBのインストール

zypperパッケージマネージャーを使用して、xDB Replication ServerをSLES 12ホストにインストールできます。 zypperは、パッケージをインストールするときにパッケージの依存関係を満たそうとしますが、EnterpriseDBでホストされていない特定のリポジトリへのアクセスが必要です。

xDBをインストールする前に、次のコマンドを使用してEnterpriseDBリポジトリ構成ファイルをSLESホストに追加します。

zypper addrepo https://zypp.enterprisedb.com/suse/epas96-sles.repo
zypper addrepo https://zypp.enterprisedb.com/suse/epas-sles-tools.repo
zypper addrepo https://zypp.enterprisedb.com/suse/epas-sles-dependencies.repo

各コマンドは、 /etc/zypp/repos.dディレクトリーにリポジトリー構成ファイルを作成します 。ファイルの名前は次のとおりです。

•	edbas96suse.repo

•	edbasdependencies.repo

•	edbastools.repo

リポジトリ構成ファイルを作成した後、 zypper refreshコマンドを使用してSLESホストのメタデータを更新し、EnterpriseDBリポジトリを含めます。

/etc/zypp/repos.d # zypper refresh
Repository 'SLES12-12-0' is up to date.
Repository 'SLES12-Pool' is up to date.
Repository 'SLES12-Updates' is up to date.
Retrieving repository 'EDB Postgres Advanced Server 9.6 12 - x86_64' metadata -----------------------[\]

Authentication required for 'https://zypp.enterprisedb.com/9.6/suse/suse-12-x86_64'
User Name:
Password:

Retrieving repository 'EDB Postgres Advanced Server 9.6 12 - x86_64' metadata...................................[done]
Building repository 'EDB Postgres Advanced Server 9.6 12 - x86_64' cache..........................[done]
All repositories have been refreshed.
...

入力を求められたら User NameとPassword 、EnterpriseDBのリポジトリ用の接続の資格情報を提供しています。資格情報が必要な場合は、次のWebサイトにアクセスしてください。

https://www.enterprisedb.com/repository-access-request

EDB Postgres Advanced Serverまたはサポートコンポーネントをインストールする前に、SUSEConnectとSUSE Package Hub拡張機能をSLESホストに追加し、ホストをSUSEに登録して、SUSEリポジトリへのアクセスを許可する必要があります。次のコマンドを使用します。

zypper install SUSEConnect
SUSEConnect -p PackageHub/12/x86_64
SUSEConnect -p sle-sdk/12/x86_64

SUSEホストの登録に関する詳細については、次を参照してください。

https://www.suse.com/support/kb/doc/?id=7016626

次に、Javaリポジトリを追加し、リポジトリメタデータを更新します。

JavaコンポーネントのSLESホストでは、OpenJDK（バージョン1.8）のみがサポートされていることに注意してください。 RPMインストーラーを使用してAdvanced ServerまたはJavaを必要とするサポートコンポーネントを追加する前に、zypperを使用してシステムにサポートリポジトリの場所を追加します。

次のコマンドを使用します。

zypper addrepo " http://download.opensuse.org/repositories/Java:/Factory/SLE_12_SP2/Java:Factory.repo "
zypper addrepo "http://download.opensuse.org/repositories/server:/Kolab:/3.3/SLE_12/server:Kolab:3.3.repo"

zypper refresh

次に、zypperユーティリティを使用してxDB Replication Serverコンポーネントをインストールできます。

zypper install ppas-xdb*

注：パブリケーションサーバーとサブスクリプションサーバーを起動する前に、 /etc/hostsファイルには、次の例に示すように、ホスト名のエントリがホストIPアドレスに関連付けられている必要がありますlinux-dm8sはIPアドレスで、 linux-dm8sはホスト名です。

192.168.187.133 linux-dm8s

3.5 インストール後のホスト環境

グラフィカルユーザーインターフェイスまたはコマンドラインを使用してxDB Replication ServerをインストールしたLinuxホストでは、パブリケーションサーバーおよびサブスクリプションサーバーコンポーネントをインストールすることを選択した場合、コンピューターでパブリケーションサーバーデーモンとサブスクリプションサーバーデーモンを実行する必要があります。 xDB RPMパッケージをインストールした場合、パブリケーションサーバーについてはセクション 5.2.1 、サブスクリプションサーバーについてはセクション5.3.1 の指示に基づいて、パブリケーションサーバーとサブスクリプションサーバーを起動する必要があります。 Windowsシステムでは、パブリケーションサーバーとサブスクリプションサーバーは、 Publication ServiceおよびSubscription Serviceという名前のPublication Serviceとして実行されます。

Postgresアプリケーションメニューには、xDBレプリケーションコンソールの新しい項目が含まれています。

注：一部のLinuxシステムでは、アプリケーションメニューにxDB Replication Consoleの選択肢が表示される前にサーバーを再起動する必要がある場合があります。アプリケーションメニューでxDBレプリケーションコンソールの選択がまだ利用できない場合は、スクリプトXDB_HOME /bin/runRepConsole.shを呼び出して開始できます。

注： xDB RPMパッケージからインストールされたxDB Replication Serverの場合、xDB Replication Consoleは、スクリプトXDB_HOME /bin/runRepConsole.shを呼び出すことにより開始されます。

構成プロセス中に必要になる可能性がある次のファイルが作成されます。

表3‑2 –インストール後のファイル

File Name	Location	Description
edb-repl.conf (Linux)	/etc	xDB Replication Configuration file
edb-repl.conf (Windows)	XDB_HOME \etc	xDB Replication Configuration file
edb-xdbpubserver (Linux)	/etc/init.d	Start, stop, or restart the publication server
edb-xdbpubserver.service (Linux)	/usr/lib/systemd/system	Start, stop, or restart the publication server (CentOS 7, RHEL 7)
edb-xdbsubserver (Linux)	/etc/init.d	Start, stop, or restart the subscription server
edb-xdbsubserver.service (Linux)	/usr/lib/systemd/system	Start, stop, or restart the subscription server (CentOS 7, RHEL 7)
xdb_pubserver.conf	XDB_HOME /etc	Publication server configuration file
xdb_subserver.conf	XDB_HOME /etc	Subscription server configuration file
xdbReplicationServer- xx .config	XDB_HOME /etc/sysconfig	xDB Startup Configuration file
pubserver.log (Linux)	/var/log/xdb- x . バツ	Publication server log file
pubserver.log (Windows)	POSTGRES_HOME \.enterprisedb\xdb\ x . バツ	Publication server log file
subserver.log (Linux)	/var/log/xdb- x . バツ	Subscription server log file
subserver.log (Windows)	POSTGRES_HOME \.enterprisedb\xdb\ x . バツ	Subscription server log file
edb-xdbpubserver.log (Linux)	/var/log/edb/xdbpubserver	Publication services startup log file
edb-xdbsubserver.log (Linux)	/var/log/edb/xdbsubserver	Subscription services startup log file
servers.xml	USER_HOME /.enterprisedb/xdb/ x . バツ	Server login file

注： XDB_HOMEは、xDB Replication Serverがインストールされているディレクトリーです。

注： POSTGRES_HOMEは、 postgresオペレーティングシステムアカウント（Oracle互換構成モードでインストールされたAdvanced Serverのenterprisedb ）のホームディレクトリです。

注：パブリケーションおよびサブスクリプションサービスのスタートアップログファイル（ edb-xdbpubserver.logおよびedb-xdbsubserver.log ）は、WindowsおよびMac OS Xオペレーティングシステムでは生成されません。

注： USER_HOMEは、使用中のオペレーティングシステムアカウントのホームディレクトリです。

注： xDB Replication Serverのバージョン番号はxで表され. xまたはxx （ 6.2または62 ）。

3.6 xDB Replication Serverのアンインストール

xDB Replication Serverをアンインストールすると、パブリケーションサーバー、サブスクリプションサーバー、xDB Replication Console、xDB Replication Serverコマンドラインインターフェイス、xDBレプリケーション構成ファイル、xDBスタートアップ構成ファイル、パブリケーションサーバー構成ファイル、およびサブスクリプションサーバー構成ファイル。

xDB Replication Serverをアンインストールしても、マスターノード、パブリケーションデータベース、またはサブスクリプションデータベースとして使用されるデータベースは削除されません。

xDB Replication ServerまたはxDB Replication Serverコマンドラインインターフェイスを使用して、xDB Replication Serverをアンインストールする前に既存のシングルマスターまたはマルチマスターレプリケーションシステムを削除します。そうしないと、パブリケーションデータベースまたはマスターノードで作成されたコントロールスキーマオブジェクトがそれらに残りますデータベース。これらのコントロールスキーマオブジェクトは、SQLコマンドラインユーティリティなどを使用して手動で削除する必要があります。

セクション 3.1で 説明したようにStack BuilderまたはStackBuilder Plusから呼び出されたxDB Replication Serverインストーラープログラムを使用してxDB Replication Serverをインストールした場合、またはセクション3.2で説明したようにコマンドラインからxDB Replication Serverインストーラープログラムを呼び出した場合、xDB Replication Serverをアンインストールしてアンインストールしますこのセクションで説明されているuninstall-xdbreplicationserverスクリプト。

RPMパッケージからxDB Replication Serverをインストールした場合は、Yumパッケージマネージャーを使用してアンインストールします。詳細については、セクション 3.7を参照してください。

Linuxの場合のみ：以下の手順は、LinuxホストからxDB Replication Serverをアンインストールするためのものです。

手順1： rootアカウントとして、xDB Replication ServerをインストールしたディレクトリからXDB_HOME /uninstall-xdbreplicationserverスクリプトを実行します。

$ su root

Password:

$ cd /opt/PostgreSQL/EnterpriseDB-xDBReplicationServer

$ ./uninstall-xdbreplicationserver

ステップ2： [はい]ボタンをクリックして、xDB Replication Serverのアンインストールを確認します。

図3‑26-xDB Replication Serverのアンインストールの確認

手順3：プロセスが完了すると、[アンインストールの完了]ダイアログボックスが表示されます。 OKボタンをクリックします。

図3‑27-アンインストールの完了

Windowsの場合のみ：次の手順は、WindowsホストからxDB Replication Serverをアンインストールするためのものです。

ステップ1： Windowsのコントロールパネルから、[プログラムのアンインストール]を選択します。

図3‑28-プログラムのアンインストール

ステップ2：アンインストールまたは変更するプログラムのリストでxDB Replication Server製品を選択します。 [アンインストール/変更]ボタンをクリックします。

図3‑29-プログラムのアンインストールまたは変更

ステップ3： [はい]ボタンをクリックして、xDB Replication Serverのアンインストールを確認します。

図3‑30-xDB Replication Serverのアンインストールの確認

手順4：プロセスが完了すると、[アンインストールの完了]ダイアログボックスが表示されます。 OKボタンをクリックします。

図3‑31-アンインストールの完了

テキストモードまたは無人モードでのアンインストール

xDB Replication Serverのアンインストールは、グラフィカルユーザーインターフェイスを使用せずに実行することもできます。これを次の例で説明します。

以下は、テキストモードでxDB Replication Serverをアンインストールする方法を示しています。

$ su root

Password:

$ ./uninstall-xdbreplicationserver --mode text

Do you want to uninstall xDB Replication Server and all of its modules? [Y/n]: y

 

----------------------------------------------------------------------------

Uninstall Status

 

Uninstalling xDB Replication Server

0% ______________ 50% ______________ 100%

#########################################

 

Info: Uninstallation completed

Press [Enter] to continue :

$

以下は、無人モードでxDB Replication Serverをアンインストールする方法を示しています。

$ su root

Password:

$ ./uninstall-xdbreplicationserver --mode unattended

$

3.7 xDB RPMパッケージのアンインストール

あなたはRPMパッケージからXDB Replication Serverのをインストールした場合は、起動することにより、任意のXDBコンポーネントをアンインストールすることができます yum remove package_nameようなコマンドをrootアカウントpackage_name 、セクションの表に記載されている任意のXDB Replication ServerのコンポーネントのRPMパッケージである3.3 。

すべてのxDB Replication Serverコンポーネントは、次のコマンドで削除できます。

yum remove ppas-xdb *

以下に例を示します。

[root@localhost ~]# yum remove ppas-xdb*

Loaded plugins: fastestmirror, refresh-packagekit, security

Setting up Remove Process

Resolving Dependencies

--> Running transaction check

---> Package ppas-xdb.x86_64 0:6.2.0-1.rhel6 will be erased

---> Package ppas-xdb-console.x86_64 0:6.2.0-1.rhel6 will be erased

---> Package ppas-xdb-libs.x86_64 0:6.2.0-1.rhel6 will be erased

---> Package ppas-xdb-publisher.x86_64 0:6.2.0-1.rhel6 will be erased

---> Package ppas-xdb-subscriber.x86_64 0:6.2.0-1.rhel6 will be erased

--> Finished Dependency Resolution

 

Dependencies Resolved

 

==================================================================================================================================================================

Package Arch Version Repository Size

==================================================================================================================================================================

Removing:

ppas-xdb x86_64 6.2.0-1.rhel6 @enterprisedb-xdb60 0.0

ppas-xdb-console x86_64 6.2.0-1.rhel6 @enterprisedb-xdb60 3.3 M

ppas-xdb-libs x86_64 6.2.0-1.rhel6 @enterprisedb-xdb60 15 M

ppas-xdb-publisher x86_64 6.2.0-1.rhel6 @enterprisedb-xdb60 126 k

ppas-xdb-subscriber x86_64 6.2.0-1.rhel6 @enterprisedb-xdb60 19 k

 

Transaction Summary

==================================================================================================================================================================

Remove 5 Package(s)

 

Installed size: 18 M

Is this ok [y/N]: y

Downloading Packages:

Running rpm_check_debug

Running Transaction Test

Transaction Test Succeeded

Running Transaction

Erasing : ppas-xdb-6.2.0-1.rhel6.x86_64 1/5

Erasing : ppas-xdb-subscriber-6.2.0-1.rhel6.x86_64 2/5

Erasing : ppas-xdb-console-6.2.0-1.rhel6.x86_64 3/5

Erasing : ppas-xdb-publisher-6.2.0-1.rhel6.x86_64 4/5

Erasing : ppas-xdb-libs-6.2.0-1.rhel6.x86_64 5/5

Verifying : ppas-xdb-6.2.0-1.rhel6.x86_64 1/5

Verifying : ppas-xdb-console-6.2.0-1.rhel6.x86_64 2/5

Verifying : ppas-xdb-subscriber-6.2.0-1.rhel6.x86_64 3/5

Verifying : ppas-xdb-libs-6.2.0-1.rhel6.x86_64 4/5

Verifying : ppas-xdb-publisher-6.2.0-1.rhel6.x86_64 5/5

 

Removed:

ppas-xdb.x86_64 0:6.2.0-1.rhel6 ppas-xdb-console.x86_64 0:6.2.0-1.rhel6 ppas-xdb-libs.x86_64 0:6.2.0-1.rhel6

ppas-xdb-publisher.x86_64 0:6.2.0-1.rhel6 ppas-xdb-subscriber.x86_64 0:6.2.0-1.rhel6

 

Complete!

4 xDBレプリケーションコンソールの概要

xDBレプリケーションコンソールは、レプリケーションシステムの構成と管理に使用するグラフィカルユーザーインターフェイスです。 xDB Replication Server CLIユーティリティを使用して、同等の機能を実行することもできます。 xDB Replication Server CLIについては、 第 8 章を参照してください 。

[xDB Replication Console]ウィンドウは、次の主要な領域で構成されています。

•	メニューバー。複製システムコンポーネントのメニュー

•	ツールバー。ダイアログボックスにすばやくアクセスするためのアイコン

•	レプリケーションツリー。逆ツリーのノードとして表される複製システムコンポーネント

•	情報ウィンドウ。レプリケーションツリーで強調表示されたノードに関する情報を含むタブ付きウィンドウ

図4-1-[xDB Replication Console]ウィンドウ

メニューバーとツールバーで使用できるオプションは、レプリケーションツリーで強調表示されているノードによって異なります。強調表示されたノードに関連するオプションのみがメニューバーとツールバーで使用できます。

情報ウィンドウの内容は、強調表示されたノードにも適用されます。

4.1 xDBレプリケーションコンソールのツールバー

このセクションでは、さまざまなツールバーアイコンがアクティブになるタイミングについて説明します。ツールバーに関連する操作については 、シングルマスターレプリケーションのセクション 5.2および5.3で説明しています 。マルチマスターレプリケーションについては、セクション6.2を参照してください。

注：パブリケーションに関連するツールを使用するには、パブリケーションサーバーが実行されている必要があります。同様に、サブスクリプションに関連するツールを使用するには、サブスクリプションサーバーが実行されている必要があります。

4.1.1 Refresh

更新アイコンは常にアクティブになっています。レプリケーションツリーまたは情報ウィンドウが表示されない場合は、更新アイコンをクリックして、操作の実行後に最新の情報を表示します。 [更新]アイコンをクリックすると、最新の情報がレプリケーションツリーと情報ウィンドウに表示されます。

図4‑2-更新アイコン

4.1.2 Create Publication

パブリケーションデータベースノードがレプリケーションツリーで強調表示されると、パブリケーションの作成アイコンがアクティブになります。

図4‑3-パブリケーションの作成アイコン

4.1.3 Publication Management

パブリケーションノードがレプリケーションツリーで強調表示されると、パブリケーションの削除アイコン、パブリケーションテーブルの追加アイコン、およびパブリケーションテーブルの削除アイコンがアクティブになります。

図4‑4-パブリケーションの削除、パブリケーションテーブルの追加、およびパブリケーションテーブルの削除アイコン

4.1.4 Create Subscription

サブスクリプションデータベースノードがレプリケーションツリーで強調表示されると、サブスクリプションの作成アイコンがアクティブになります。

図4‑5-サブスクリプションの作成アイコン

4.1.5 Subscription Management

サブスクリプションノードがレプリケーションツリーで強調表示されると、サブスクリプションの削除アイコン、スナップショットアイコン、同期アイコン、スケジュールの構成アイコン、およびスケジュールの削除アイコンがアクティブになります。

図4‑6-サブスクリプションの削除、スナップショット、同期、スケジュールの構成、およびスケジュールの削除アイコン

4.2 サーバーログイン情報の保存

xDBレプリケーションコンソールを使用してレプリケーションシステムを作成する場合、パブリケーションサーバーとサブスクリプションサーバーを登録する必要があります。このプロセス中に、サーバーのログイン情報を保存するオプションが提供されます。このセクションでは、このオプションを選択した場合の動作について説明します。

次の説明は、パブリケーションサーバーとサブスクリプションサーバーの両方に適用されます。この説明では、これらを総称して「サーバー」と呼びます。

4.2.1 Server Login File

ログイン情報を保存することを選択した場合、サーバーのネットワークの場所（IPアドレスとポート番号）、管理者ユーザー名、およびパスワードは、ユーザーが使用するオペレーティングシステムアカウントのホームディレクトリの下にある隠し場所のサーバーログインファイルに保存されますxDBレプリケーションコンソールを開きました。このファイルの場所については、セクション3.5を参照してください。

ログイン情報を保存するオプションがチェックボックスとして表示される[パブリケーションサーバーの登録]ダイアログボックスを次に示します。この例では、ホストフィールドに入力された192.168.2.22 、ポートフィールドに入力された9051 、ユーザー名フィールドに入力されたadmin 、およびパスワードフィールドに入力されたパスワードの暗号化された形式は、このパブリケーションサーバーのサーバーログインファイルに保存されます管理ユーザー名とパスワードの検証が成功した場合。

入力したユーザー名とパスワードの値は 、この場合、 ホスト 192.168.2.22 にあるxDBレプリケーション構成ファイルの管理ユーザー名とパスワードに対して検証されます 。パブリケーションサーバーの登録およびサーバーログインファイルへのパブリケーションサーバーのログイン情報の保存が行われる前に、管理ユーザー名とパスワードが正常に認証される必要があります。 xDBレプリケーション構成ファイルの詳細は、 2.3.1.3項を参照してください。

図4‑7-パブリケーションサーバーのログイン情報の保存オプション

これらのフィールドの目的とパブリケーションサーバーの登録プロセスの詳細については、セクション 5.2.1を参照してください 。

以下に、[サブスクリプションサーバーの登録]ダイアログボックスを示します。この例では、ホストフィールドに入力された192.168.2.22 、ポートフィールドに入力された9052 、ユーザー名フィールドに入力されたadmin 、およびパスワードフィールドに入力されたパスワードの暗号化された形式がこのサブスクリプションサーバーのサーバーログインファイルに保存されます管理ユーザー名とパスワードの検証が成功した場合。

図4‑8-サブスクリプションサーバーのログイン情報の保存オプション

これらのフィールドの目的とサブスクリプションサーバーの登録プロセスの詳細については、セクション 5.3.1を参照してください 。

サーバーログイン情報を保存すると、パブリケーションサーバーとその下位パブリケーションへの即時アクセス、またはサブスクリプションサーバーとその下位サブスクリプションへのアクセスが簡単になります。つまり、xDBレプリケーションコンソールを開くと、保存されたパブリケーションサーバーのパブリケーションサーバーノードがすぐにレプリケーションツリーに表示され、その下位パブリケーションで管理タスクを実行できます。

同様に、保存されたサブスクリプションサーバーのサブスクリプションサーバーノードはすぐにレプリケーションツリーに表示され、その下位サブスクリプションで管理タスクを実行できます。

サーバーのログイン情報を保存しなかった場合、サーバーノードはレプリケーションツリーに表示されません。サーバーのネットワークの場所、管理ユーザー名、およびパスワードを再入力する必要があります。つまり、xDBレプリケーションコンソールを開くたびにサーバーを登録する必要があります。

注：特定のホスト上の各オペレーティングシステムアカウントには、独自のサーバーログインファイルがあります。したがって、保存され、開いたときにxDBレプリケーションコンソールに表示されるサーバーは、オペレーティングシステムアカウントごとに個別に決定されます。

4.2.2 Security Risks of Saved Server Login Information

前のセクションでは、サーバーのログイン情報を保存する利点について説明しました。

これに関連するセキュリティリスクは、許可されていない人がオペレーティングシステムアカウントにアクセスすると、オペレーティングシステムアカウントを使用してホスト上のxDB Replication Consoleを開く可能性があることです。

パブリケーションサーバーまたはサブスクリプションサーバーのログイン情報が保存されると、対応するパブリケーションサーバーノードまたはサブスクリプションサーバーノードがすぐにxDBレプリケーションコンソールに表示され、認証情報の要求はありません。

これにより、権限のない人が、公開されたパブリケーションおよびサブスクリプションに対して、レプリケーションシステムを完全に削除する可能性を含む操作を実行できます。

注：パブリケーションデータベースとサブスクリプションデータベースを削除することはできませんが、不正な複製が発生する可能性があります。

したがって、オペレーティングシステムアカウントは、xDBレプリケーションコンソールおよびレプリケーションシステムにアクセスできるホスト上で安全であることが重要です。

5 シングルマスターレプリケーション操作

この章では、シングルマスター複製システム用にxDB Replication Serverを構成および実行する方法について説明します。

レプリケーションシステムの構成と管理には、xDBレプリケーションコンソールのグラフィカルユーザーインターフェイスを使用して、この章の手順と例を示します。 xDB Replication Serverコマンドラインインターフェイス（CLI）を使用して、オペレーティングシステムのコマンドラインから同じ手順を実行できます。 xDB Replication Server CLIユーティリティのコマンドについては、第 8 章で説明します 。

5.1 前提条件の手順

シングルマスターレプリケーションシステムの構築プロセスを開始する前に、ホスト環境とパブリケーションおよびサブスクリプションデータベースサーバーを準備する特定の手順を実行する必要があります。このセクションでは、これらの手順について説明します。

5.1.1 Setting Heap Memory Size for the Publication and Subscription Servers

パブリケーションサーバーとサブスクリプションサーバーは、ヒープサイズパラメーターの既定のセットで実行するように構成されています。 32ビットプラットフォームのデフォルト設定または64ビットプラットフォームのデフォルト設定は 、xDB Replication Serverのインストール時にパラメーター JAVA_HEAP_SIZE によって設定されます 。

このパラメーターは、xDBスタートアップ構成ファイルで構成されます。 xDBスタートアップコンフィギュレーションファイルの詳細については、セクション 2.3.1.4を参照してください 。

以下は、xDBスタートアップ構成ファイルの例です。

#!/bin/sh

 

JAVA_EXECUTABLE_PATH="/usr/bin/java"

JAVA_MINIMUM_VERSION=1.7

JAVA_BITNESS_REQUIRED=64

JAVA_HEAP_SIZE="-Xms256m -Xmx1536m"

PUBPORT=9051

SUBPORT=9052

32ビットシステムでは、初期ヒープサイズは128メガバイト（ -Xms128m ）に設定され、最大制限は512メガバイト（ -Xmx512m ）に設定されます。 64ビットシステムでは、初期ヒープサイズは256メガバイト（ -Xms256m ）で、最大制限は1536メガバイト（ -Xmx1536m ）です。

通常、これらの値は平均的なワークロードを処理できます。ただし、レプリケーションの更新の平均行サイズと保留中のバックログによっては、デフォルトのヒープサイズ設定を増やすことが有益な場合があります。

デフォルト値は 、xDBスタートアップ構成ファイルのJAVA_HEAP_SIZEパラメーター設定を変更することにより変更できます。このような変更を行った後は、必ずパブリケーションサーバーとサブスクリプションサーバーを再起動してください（セクション5.2.1および5.3.1を参照）。

ヒープサイズの値は、パブリケーションサーバーまたはサブスクリプションサーバーを実行しているホストで使用可能なRAMに準拠する必要があります。基本的なガイドラインは、最大ヒープサイズが合計RAMサイズの25％を超えないことです。

次の要因も考慮する必要があります。

パブリケーションサーバーとサブスクリプションサーバーの両方が同じホストで実行されている場合、最小および推奨のRAM容量は次のように表示されます。

•	最小RAMサイズ。 32ビットシステムの場合、4ギガバイトを使用します。 64ビットシステムでは8ギガバイトを使用します。

•	推奨RAMサイズ。 32ビットシステムの場合、8ギガバイトを使用します。 64ビットシステムの場合、16ギガバイトを使用します。

デフォルトでは、パブリケーションサーバーとサブスクリプションサーバーの両方が起動され、シングルマスターレプリケーションシステムには両方が必要です。ただし、マルチマスターレプリケーションシステムのみを構成して使用する場合は、サブスクリプションサーバーは必要ありません。このような場合、サブスクリプションサーバーを停止して、メモリの冗長使用を回避する必要があります。

パブリケーションサーバーとサブスクリプションサーバーの両方が同じホストで実行されている場合、各サーバーは独自のヒープバッファーを予約します。したがって、パブリケーションサーバーとサブスクリプションサーバーの両方の合計ヒープサイズは、両方のサーバーの最大ヒープサイズを追加することによって取得され、ホストで使用可能なRAMに準拠する必要があります。

5.1.2 Enabling Synchronization Replication with the Log-Based Method

このセクションは、バージョン9.4以降のPostgresデータベースサーバーにのみ適用されます。

Postgresデータベースサーバーで実行されているパブリケーションデータベースとログベースの同期レプリケーションを使用する場合、Postgresデータベースサーバーの構成ファイル postgresql.confで次の構成パラメーター設定が必要です 。

•	wal_level。 logical設定しlogical 。

•	max_wal_senders。同時接続の最大数（つまり、同時に実行されているWAL送信プロセスの最大数）を指定します。少なくとも、ログベースの方法を使用するこのデータベースサーバー上のSMRパブリケーションデータベースの数に設定します。さらに、このデータベースサーバーでMMRマスターノードを実行する場合は、ログベースの方法を使用するMMRマスターノードの数も追加します。

•	max_replication_slots。複製スロットの最大数を指定します。少なくとも、ログベースの方法を使用するこのデータベースサーバー上のSMRパブリケーションデータベースの数に設定します。さらに、MMRマスターノードがログベースの方法でこのデータベースサーバーで実行される場合、必要な追加のレプリケーションスロットの数については、セクション2.2.10.4を参照してください。

同期レプリケーションのログベースの方法については、 セクション 2.2.10を参照してください 。

これらの構成パラメーターのいずれかを変更した後、Postgresデータベースサーバーを再起動する必要があります。

さらに、 pg_hba.confファイルには、ログベースの方法を使用するパブリケーションデータベースの各パブリケーションデータベースユーザーのエントリが必要です。このようなデータベースユーザーは、 pg_hba.confファイルにレプリケーションデータベースユーザーとして含める必要があります。追加情報については、セクション5.1.6.3を参照してください。

5.1.3 Enabling Access to the Database Servers

以下のセクションでは、さまざまなタイプのデータベースサーバーでxDB Replication Serverを使用するために必要な構成手順について説明します。

次のセクションでは、Oracleへのアクセスを有効にする手順について説明します。 SQL Serverへのアクセスを有効にする方法については、セクション 5.1.3.2を参照してください 。

Postgresデータベースサーバーへのアクセスを有効にするための特別な手順は必要ありません。

5.1.3.1 Enabling Access to Oracle

注：このセクションの指示は、Oracleがパブリケーションデータベースまたはサブスクリプションデータベースとして使用される場合にのみ適用されます。

ojdbc5.jar などのOracle JDBCドライバーjarファイルは、パブリケーションサーバーとサブスクリプションサーバーを実行しているホスト上のJava仮想マシン（JVM）にアクセスできる必要があります。パブリケーションサーバーとサブスクリプションサーバーが別々のホストで実行されている場合、Oracle JDBCドライバーは各ホストのJVMにアクセスできる必要があります。 Oracle JDBCドライバーバージョンojdbc5以降を使用する必要があります。

ステップ1： Oracle JDBCドライバー（ ojdbc5.jarなど）をOracleダウンロードサイトからパブリケーションサーバーを実行するホストにダウンロードします。

ステップ2：ファイルojdbc5.jarをディレクトリXDB_HOME /lib/jdbcコピーします。

$ su root

Password:

$ cd /opt/PostgreSQL/EnterpriseDB-xDBReplicationServer/lib/jdbc

$ cp /home/user/Downloads/ojdbc5.jar .

$ ls -l

total 4032

-rw-rw-r-- 1 root root 355655 Jan 25 02:38 edb-jdbc14.jar

-rw-rw-r-- 1 root root 716209 Jan 25 02:38 edb-jdbc17.jar

-rw-rw-r-- 1 root root 317816 Jan 25 02:38 jtds-1.3.1.jar

-rw-r--r-- 1 root root 2091137 Jan 28 16:45 ojdbc5.jar

-rw-rw-r-- 1 root root 642809 Jan 25 02:38 postgresql-9.4-1201.jdbc4.jar

注： ojdbc5.jarファイルを、Javaランタイム環境をインストールした場所のjre/lib/extサブディレクトリにコピーすることもできます。

手順3：サブスクリプションサーバーがパブリケーションサーバーとは異なるホストで実行されている場合は、サブスクリプションサーバーのホストに対して手順1と2を繰り返します。

5.1.3.2 Enabling Access to SQL Server

注：このセクションの指示は、SQL Serverをパブリケーションデータベースまたはサブスクリプションデータベースとして使用する場合にのみ適用されます。

jTDS JDBCドライバーjarファイル jtds-1.3.1.jarは、パブリケーションサーバーとサブスクリプションサーバーを実行しているホスト上のJava仮想マシン（JVM）にアクセスできる必要があります。パブリケーションサーバーとサブスクリプションサーバーが別々のホストで実行されている場合、jTDS JDBCドライバーは各ホストのJVMにアクセスできる必要があります。

xDB Replication Serverをインストールすると、 jtds-1.3.1.jarファイルがディレクトリXDB_HOME /lib/jdbc配置されるため、この要件のために手動で構成する必要はありません。

手順1： SQL ServerデータベースエンジンでSQL Server認証モードが有効になっていることを確認します。 SQL Server認証モードでは、組み込みのシステム管理者ログインsaなどのSQL Serverログインを使用できます。

SQL Serverインストールのデフォルト設定を使用すると、 Windows認証モード のみが有効になり、Windowsオペレーティングシステムのアカウントを認証に利用します。

SQL Server認証モードを許可するには、認証モードを Mixed Mode Authenticationに変更する必要があります。これは、Windows認証とSQL Server認証の両方を許可します。

これは、 SQL Server Management Studio を使用して実行できます 。 SQL Server Management Studioの使用については、適切なSQL Serverのドキュメントを参照してください。

手順2： SQL ServerがTCP / IP接続を受け入れていることを確認します。 SQL Server構成マネージャーの[ SQL Serverネットワーク構成]で、SQL ServerインスタンスのTCP / IPプロトコルが[ Enabled設定されていることを確認します。一般的なデフォルトのSQL Serverインスタンス名はMSSQLSERVERまたはSQLEXPRESSです。

ステップ3（SQL Serverパブリケーションデータベースにのみ必要）： SQL Serverエージェントが有効で実行されていることを確認します 。 SQL Serverエージェントは、SQL Serverでジョブのスケジューリングと実行を制御するWindowsサービスです。

xDB Replication Serverは、スケジュールされたシャドウテーブル履歴のクリーンアップなどの特定の操作にSQL Serverエージェントを使用します（セクション 7.5.1を 参照 ）。

SQL Server Configuration Manager を使用して、SQL Serverエージェントを起動できます 。 SQL Server Configuration Managerの使用については、適切なSQL Serverのドキュメントを参照してください。

5.1.4 Preparing the Publication Database

このセクションでは、パブリケーションのメンバーになるテーブルとビューを含むデータベースの準備について説明します。

特定のパブリケーションに使用されるテーブルとビューは、すべて同じデータベースに存在する必要があります。このデータベースは、そのパブリケーションのパブリケーションデータベースになります。 パブリケーションデータベースのユーザー名は、作成したか、すでに次の特性を持つ存在している必要があります。

•	パブリケーションデータベースユーザーは、パブリケーションデータベースに接続できます。

•	パブリケーションデータベースユーザーには、レプリケーションプロセスの制御と追跡に使用されるメタデータを格納するコントロールスキーマオブジェクトを作成する権限があります。

•	パブリケーションデータベースユーザーは、パブリケーションのメンバーになるテーブルとビューを読み取ることができます。

•	トリガーベースの方法で同期レプリケーションを使用するパブリケーションの場合、パブリケーションデータベースユーザーは、パブリケーションテーブルにトリガーを作成できます。 （Oracleの場合、パブリケーションデータベースユーザーは、スナップショットのみのパブリケーションに対してもトリガー作成特権を持っている必要がありますが、トリガーは同期レプリケーションを使用するパブリケーションに対してのみ作成されます。）

このユーザーズガイドの残りの部分で使用されている例は、以下に基づいています。

•	パブリケーションデータベースのユーザー名は pubuserです。

•	パブリケーションで使用されるテーブルとビューは、 edb という名前のスキーマにあります 。

•	dept 、 emp 、およびjobhist という名前の3つのテーブルは、スキーマedbメンバーです。

•	salesemp という名前の salesempは、スキーマedbメンバーです。このビューは、 empテーブルに対するSELECTステートメントです。

•	パブリケーションデータベースのOracleシステム識別子（SID）は xeです。 SQL Serverパブリケーションデータベース名はedbです。 Postgresパブリケーションデータベース名はedbです。 （パブリケーションデータベースとしてのOracle、パブリケーションデータベースとしてのSQL Server、およびパブリケーションデータベースとしてのPostgresの例については、このセクションの例を参照してください。）

Oracleパブリケーションデータベースの準備については、次のセクションを参照してください。 SQL Serverパブリケーションデータベースの準備については、セクション 5.1.4.2を 参照してください 。 Postgresパブリケーションデータベースの準備については、セクション5.1.4.3を参照してください。

5.1.4.1 Oracle Publication Database

注（Oracle 12cの場合）： Oracle 12c マルチテナントアーキテクチャは、複数のプラガブルデータベース （PDB）を含むことができるコンテナーデータベース （CDB）の概念を導入します 。プラグ可能なデータベースは、シングルマスターレプリケーションシステムのパブリケーションデータベースまたはサブスクリプションデータベースとして使用できます。

Oracle 12cは、12cより前のOracleバージョンと互換性のある非コンテナデータベース（非CDB）と呼ばれる単一のデータベースの使用を引き続きサポートしています。 Oracle 12c非コンテナデータベースは、シングルマスターレプリケーションシステムのパブリケーションデータベースまたはサブスクリプションデータベースとしても使用できます。

Oracle 12cパブリケーションデータベースまたはサブスクリプションデータベースを使用するためのセットアップ手順は、以前のOracleバージョンと同じです。特別な区別は、指示内の注記で示されます。

手順1：パブリケーションデータベースユーザーのデータベースユーザー名を作成します。パブリケーションデータベースのユーザー名にはパスワードが必要であり、データベースセッションを作成できる必要があります。パブリケーションデータベースユーザーは、レプリケーションプロセスと履歴を追跡、制御、および記録するためにパブリケーションデータベースに作成されるコントロールスキーマオブジェクトの所有者になります。

注（Oracle 12c Pluggable Databaseの場合）：パブリケーションデータベースユーザーは、Oracle ローカルユーザーまたは共通ユーザーにすることができます 。ローカルユーザーは、パブリケーションデータベースとして使用される単一のユーザー作成プラガブルデータベース （PDB）内にのみ存在し、アクセスできます。一般的なユーザー名は通常C##またはc##始まり、複数のプラグ可能なデータベースにアクセスできます。

注（Oracle 12cプラグ可能データベースの場合）：パブリケーションデータベースとして使用するプラグ可能データベースに接続している間に、ローカルユーザーの特権の作成と付与を行う必要があります。共通ユーザーの作成は、Oracle 12cルートコンテナーCDB$ROOT内で行う必要があります。共通ユーザーへの特権の付与は、パブリケーションデータベースとして使用するプラガブルデータベースに接続している間に行う必要があります。

注（Oracle 12c Non-Container Databaseの場合）：パブリケーションデータベースユーザーへの特権の作成と付与は、12cより前のOracleバージョンの場合と同じ方法で実行されます。

パブリケーションデータベース定義を作成するとき、パブリケーションデータベースのユーザー名は、[パブリケーションサービス-データベースの追加]ダイアログボックスに入力されます（セクション 5.2.2を 参照 ）。

CREATE USER pubuser IDENTIFIED BY password;

GRANT CONNECT TO pubuser;

手順2：コントロールスキーマオブジェクトの作成に必要な特権を付与します。

コントロールスキーマオブジェクトは、パブリケーションデータベースユーザーと同じ名前で所有されるスキーマに作成されます。つまり、パブリケーションデータベースユーザーのスキーマは、Oracleパブリケーションデータベースの制御スキーマです。

GRANT RESOURCE TO pubuser;

ステップ3：パブリケーションテーブルでトリガーを作成するために必要な特権を付与します。パブリケーションデータベースユーザーにCREATE ANY TRIGGER特権を付与する必要があります。

GRANT CREATE ANY TRIGGER TO pubuser;

ステップ4：トリガーの作成時にパブリケーションテーブルをロックするために必要な特権を付与します。パブリケーションデータベースユーザーにLOCK ANY TABLE権限を付与する必要があります。

GRANT LOCK ANY TABLE TO pubuser;

ステップ5（Oracle 12cのみ）：表領域にアクセスするために必要な特権を付与します。 GRANT UNLIMITED TABLESPACE特権は、パブリケーションデータベースユーザーに付与する必要があります。この要件は、プラガブルデータベースと非コンテナデータベースの両方に適用されます。

GRANT UNLIMITED TABLESPACE TO pubuser;

ステップ6：パブリケーションデータベースユーザーは、パブリケーションに含まれるテーブルとビューを読み取ることができる必要があります。

GRANT SELECT ON edb.dept TO pubuser;

GRANT SELECT ON edb.emp TO pubuser;

GRANT SELECT ON edb.jobhist TO pubuser;

GRANT SELECT ON edb.salesemp TO pubuser;

ステップ7（オプション）：アプリケーションユーザーが必要とするパブリケーションのテーブルとビューにアクセスするために必要な特権を含む1つ以上の「グループ」ロールを作成します。

パブリケーションテーブルから選択、挿入、更新、または削除する特権が必要な新しいアプリケーションユーザーを追加する場合は、ロールを使用すると便利です。各ユーザーに各特権を個別に付与する代わりに、必要な特権を含むロールを新しいユーザーに付与できます。

次の例は、ロールの作成と、パブリケーションテーブルに対する権限のロールへの付与を示しています。

CREATE ROLE appgroup;

GRANT SELECT, INSERT, UPDATE, DELETE ON edb.dept TO appgroup;

GRANT SELECT, INSERT, UPDATE, DELETE ON edb.emp TO appgroup;

GRANT SELECT, INSERT, UPDATE, DELETE ON edb.jobhist TO appgroup;

GRANT SELECT, INSERT, UPDATE, DELETE ON edb.salesemp TO appgroup;

次の例は、新しいユーザーの作成とユーザーへの新しいロールの付与を示しています。

CREATE USER appuser IDENTIFIED BY password;

GRANT CREATE SESSION TO appuser;

GRANT appgroup TO appuser;

5.1.4.2 SQL Server Publication Database

SQL Serverでは、アプリケーションは、 SQL Serverログインとそれに関連付けられたパスワードを提供することにより、データベースサーバーにアクセスします。

アプリケーションが特定のデータベースに接続すると、アプリケーションはそのデータベースで定義された データベースユーザーの IDと特権を引き継ぎます。任意のデータベースのデータベースユーザーは、ロールメンバシップや特権などのプロパティに関して、他のデータベースのデータベースユーザーとは無関係です。実際、同じデータベースユーザー名を複数のデータベースで定義でき、それぞれに独自のプロパティがあります。

各データベースでは、データベースユーザーを SQL Serverログインにマップ できます。データベースユーザーがマップされているSQL Serverログインを使用してアプリケーションがデータベースに接続すると、アプリケーションはそのデータベースユーザーのIDと特権を引き継ぎます。

SQL Serverデータベースをパブリケーションデータベースとして使用する場合、次のルールに従って、多数のデータベースユーザーを定義し、SQL Serverログインにマップする必要があります。

•	発行サーバーがSQL Serverに接続するために使用するSQL Serverログインが存在する必要があります。 SQL Serverログインとパスワードは、パブリケーションデータベース定義の作成時に指定されます。

•	パブリケーションデータベースには、コントロールスキーマオブジェクトの作成者および所有者となるデータベースユーザーが存在する必要があります。このデータベースユーザーは、パブリケーションサーバーが使用するSQL Serverログインにマップする必要があります。

•

特定の制御スキーマオブジェクトを含むスキーマが存在する必要があります。前述の箇条書きで説明したデータベースユーザーは、このスキーマを所有するか、このスキーマに対する特定の権限を持っている必要があります。これにより、データベースユーザーはこのスキーマでコントロールスキーマオブジェクトを作成および更新できます。このスキーマは、制御スキーマ全体の1つの物理スキーマコンポーネントであり、そのデータベースユーザーのデフォルトスキーマ としても定義する必要があります。制御スキーマ全体を構成する他の物理スキーマは、パブリケーションサーバーによって常に_edb_replicator_pub 、 _edb_replicator_sub 、および_edb_schedulerとして作成されます。

•	複製されるアプリケーションテーブルのデータを更新するSQL Serverデータベースユーザーは、コントロールスキーマオブジェクトに対する特定の権限を持っている必要があります。レプリケートされたテーブルで更新が発生すると、特定のコントロールスキーマオブジェクトにアクセスして更新するトリガーが起動します。アプリケーションテーブルへの更新アクセスを必要とするSQL Serverデータベースユーザーに適切な特権を付与する必要があります。

•	データベースユーザーは 、パブリケーションサーバーが使用するSQL Serverログインにマップされるmsdbデータベースに存在する必要があります。このデータベースユーザーには、 msdbデータベースのdboスキーマでジョブを実行するための特定の特権が必要です。 （ msdbデータベースは、 SQL Serverエージェントがアラートとジョブをスケジュールするために使用されます msdbエージェントはWindowsサービスとして実行されます。）

この例では、次のSQL Serverログイン、データベースユーザー、およびマッピングを使用して、前述のルールに準拠しています。

•	パブリケーションテーブルはデータベース edbます。

•	パブリケーションテーブルとパブリケーションテーブル自体を含むスキーマを所有するデータベースユーザーは edbです。

•	パブリケーションサーバーがSQL Serverに接続するために使用するSQL Serverログインは pubuserです。

•	コントロールスキーマオブジェクトを所有し、データベースedb SQL Serverログイン pubuserにマップされているデータベースedbはpubuserです。

•	パブリケーションサーバーによって作成された特定のコントロールスキーマオブジェクトを含めるために使用されるコントロールスキーマは pubuserです。他の制御スキーマオブジェクトは、常に_edb_replicator_pub 、 _edb_replicator_sub 、および_edb_scheduler作成されます。

•	データベースmsdb SQL Serverログイン pubuserにマップされるデータベースユーザーはpubuser_msdbです。

注：これらの例のSQLステートメントを実行するには、 sqlcmdユーティリティプログラムを使用します。 USEコマンドは、後続のステートメントが適用されるデータベースを確立します。 GOコマンドは、前述のSQLステートメントをバッチとして実行します。 SQLステートメントのストリーム内でのGOコマンドの配置は、特定のSQLステートメントによっては重要な場合があります。

手順1： xDB Replication ServerパブリケーションデータベースユーザーのSQL Serverログインを作成します。ログインにはパスワードが必要です。

パブリケーションデータベース定義を作成するとき、SQL Serverログインが[パブリケーションサービス-データベースの追加]ダイアログボックスに入力されます（セクション 5.2.2を 参照 ）。

USE master;

GO

CREATE LOGIN pubuser WITH PASSWORD = 'password';

GO

手順2：データベースmsdbデータベースユーザーとジョブスケジューリングに必要な権限を作成します。

USE msdb;

GO

CREATE USER pubuser_msdb FOR LOGIN pubuser;

GO

GRANT EXECUTE ON SCHEMA :: dbo TO pubuser_msdb;

GRANT SELECT ON SCHEMA :: dbo TO pubuser_msdb;

GO

手順3：コントロールスキーマオブジェクトの作成と所有権用のデータベースユーザーを作成します。レプリケーションプロセスと履歴を追跡、制御、および記録するために、コントロールスキーマオブジェクトがパブリケーションデータベースに作成されます。この例では、コントロールスキーマオブジェクトの一部がpubuserという名前のスキーマに作成されることを想定しています。

注： WITH DEFAULT_SCHEMA句で指定するスキーマ名は、ステップ5で選択したスキーマである必要があります。このスキーマは、 CREATE USER FOR LOGIN WITH DEFAULT_SCHEMAステートメントで使用する前に存在する必要はありません。

USE edb;

GO

CREATE USER pubuser FOR LOGIN pubuser WITH DEFAULT_SCHEMA = pubuser;

GO

注：残りの手順は、コマンドがパブリケーションデータベースで指定されていることを前提としています（つまり、 USE edbデータベースは、パブリケーションデータベースedbを現在のデータベースとして確立するために以前に指定されています）。

手順4：パブリケーションデータベースユーザーがコントロールスキーマオブジェクトを作成するために必要なデータベースレベルの権限を付与します。

GRANT CREATE TABLE TO pubuser;

GRANT CREATE PROCEDURE TO pubuser;

GRANT CREATE FUNCTION TO pubuser;

GRANT CREATE SCHEMA TO pubuser;

GO

ステップ5：いくつかの制御スキーマオブジェクトが存在する制御スキーマを選択します。

パブリケーションデータベースユーザーが所有し、この目的専用に作成された新しいスキーマ（推奨アプローチ）でコントロールスキーマオブジェクトを作成するには、次のコマンドを発行します。

CREATE SCHEMA pubuser AUTHORIZATION pubuser;

GO

または、パブリケーションテーブルを含む同じスキーマ（この例ではスキーマ edb ） などの既存のスキーマにコントロールスキーマオブジェクトを作成するには 、次のコマンドを使用します。

GRANT ALTER ON SCHEMA :: edb TO pubuser;

GRANT EXECUTE ON SCHEMA :: edb TO pubuser;

GRANT SELECT ON SCHEMA :: edb TO pubuser;

GRANT INSERT ON SCHEMA :: edb TO pubuser;

GRANT UPDATE ON SCHEMA :: edb TO pubuser;

GRANT DELETE ON SCHEMA :: edb TO pubuser;

GO

ステップ6：パブリケーションテーブルでトリガーを作成するために必要な権限を付与します。パブリケーションデータベースユーザーには、パブリケーションテーブルに対するALTER権限が必要です。

GRANT ALTER ON edb.dept TO pubuser;

GRANT ALTER ON edb.emp TO pubuser;

GRANT ALTER ON edb.jobhist TO pubuser;

GO

ステップ7：パブリケーションデータベースユーザーは、パブリケーションに含まれるテーブルとビューを読み取ることができる必要があります。

GRANT SELECT ON edb.dept TO pubuser;

GRANT SELECT ON edb.emp TO pubuser;

GRANT SELECT ON edb.jobhist TO pubuser;

GRANT SELECT ON edb.salesemp TO pubuser;

GO

ステップ8（オプション）：アプリケーションユーザーが必要とするパブリケーションのテーブルとビューにアクセスするために必要な特権を含む1つ以上の「グループ」ロールを作成します。

注：これらのロールの作成は、xDB Replication ConsoleまたはxDB Replication Server CLIを使用してSQL Serverパブリケーションデータベース定義を作成した後にのみ実行できます。 （たとえば、xDB Replication Consoleの使用法については、セクション5.2.2を参照してください。）

パブリケーションテーブルから選択、挿入、更新、または削除する特権が必要な新しいアプリケーションユーザーを追加する場合は、ロールを使用すると便利です。各ユーザーに各特権を個別に付与する代わりに、必要な特権を含むロールを新しいユーザーに付与できます。

パブリケーションテーブルに対する特権に加えて、パブリケーションテーブルの挿入、更新、または削除操作を実行するユーザーには、パブリケーションの特定のコントロールスキーマオブジェクトに対する特権が必要です。

次の例は、ロール appgroup 作成と、ロールへのパブリケーションテーブルに対する特権の付与を示しています。この例では、ステップ5で、スキーマpubuserがいくつかのコントロールスキーマオブジェクトを格納するコントロールスキーマとして選択されていることを前提としています。

CREATE ROLE appgroup AUTHORIZATION edb;

GRANT SELECT, INSERT, UPDATE, DELETE ON edb.dept TO appgroup;

GRANT SELECT, INSERT, UPDATE, DELETE ON edb.emp TO appgroup;

GRANT SELECT, INSERT, UPDATE, DELETE ON edb.jobhist TO appgroup;

GRANT SELECT, INSERT, UPDATE, DELETE ON edb.salesemp TO appgroup;

GRANT EXECUTE ON SCHEMA :: _edb_replicator_pub TO appgroup;

GRANT SELECT ON SCHEMA :: _edb_replicator_pub TO appgroup;

GRANT INSERT ON SCHEMA :: _edb_replicator_pub TO appgroup;

GRANT UPDATE ON SCHEMA :: _edb_replicator_pub TO appgroup;

GRANT INSERT ON SCHEMA :: pubuser TO appgroup;

GO

次の例は、新しいログインおよびデータベースユーザーの作成、およびその権限を継承するためのロールのメンバーとしてのデータベースユーザーの追加を示しています。

CREATE LOGIN applogin WITH PASSWORD = 'password', DEFAULT_DATABASE = edb;

CREATE USER appuser FOR LOGIN applogin WITH DEFAULT_SCHEMA = edb;

EXEC sp_addrolemember @rolename = 'appgroup', @membername = 'appuser';

GO

注（個々のユーザーへの特権の付与）：前述のように、パブリケーションテーブルのデータを変更する各アプリケーションデータベースユーザーには、パブリケーションテーブルおよびコントロールスキーマオブジェクトに対する特定の特権を付与する必要があります。このステップで前述したように、この目的でグループロールを使用すると、このプロセスを簡素化できます。

個々のデータベースユーザーには、同様の方法でパブリケーションテーブルとコントロールスキーマオブジェクトにアクセスする特権を付与できます。

次の例は、新しいログインおよびデータベースユーザーの作成と、パブリケーションテーブルおよびコントロールスキーマオブジェクトに対する特権のユーザーへの付与を示しています。

CREATE LOGIN newlogin WITH PASSWORD = 'password', DEFAULT_DATABASE = edb;

CREATE USER newuser FOR LOGIN newlogin WITH DEFAULT_SCHEMA = edb;

GRANT SELECT, INSERT, UPDATE, DELETE ON edb.dept TO newuser;

GRANT SELECT, INSERT, UPDATE, DELETE ON edb.emp TO newuser;

GRANT SELECT, INSERT, UPDATE, DELETE ON edb.jobhist TO newuser;

GRANT SELECT, INSERT, UPDATE, DELETE ON edb.salesemp TO newuser;

GRANT EXECUTE ON SCHEMA :: _edb_replicator_pub TO newuser;

GRANT SELECT ON SCHEMA :: _edb_replicator_pub TO newuser;

GRANT INSERT ON SCHEMA :: _edb_replicator_pub TO newuser;

GRANT UPDATE ON SCHEMA :: _edb_replicator_pub TO newuser;

GRANT INSERT ON SCHEMA :: pubuser TO newuser;

GO

注：スキーマレベルで特権を付与する上記のステートメントを使用する代わりに、次のステートメントを使用して、データベースオブジェクトレベルでより詳細なレベルの特権を発行できます。

CREATE LOGIN newlogin WITH PASSWORD = 'password', DEFAULT_DATABASE = edb;

CREATE USER newuser FOR LOGIN newlogin WITH DEFAULT_SCHEMA = edb;

GRANT SELECT, INSERT, UPDATE, DELETE ON edb.dept TO newuser;

GRANT SELECT, INSERT, UPDATE, DELETE ON edb.emp TO newuser;

GRANT SELECT, INSERT, UPDATE, DELETE ON edb.jobhist TO newuser;

GRANT SELECT, INSERT, UPDATE, DELETE ON edb.salesemp TO newuser;

GRANT INSERT ON pubuser.rrst_edb_dept TO newuser;

GRANT INSERT ON pubuser.rrst_edb_emp TO newuser;

GRANT INSERT ON pubuser.rrst_edb_jobhist TO newuser;

GO

さらに、SQL Serverのバージョンに応じて、次の追加の特権を付与します。

SQL Server 2008の場合：次の特権を付与します。

GRANT EXECUTE ON _edb_replicator_pub.nextval TO newuser;

GRANT SELECT ON _edb_replicator_pub.rrep_tx_seq TO newuser;

GRANT INSERT ON _edb_replicator_pub.rrep_tx_seq TO newuser;

GO

SQL Server 2012、2014の場合：次の権限を付与します。

GRANT UPDATE ON _edb_replicator_pub.rrep_tx_seq TO newuser;

GRANT UPDATE ON _edb_replicator_pub.rrep_txset_seq TO newuser;

GRANT UPDATE ON _edb_replicator_pub.rrep_common_seq TO newuser;

GO

ただし、このアプローチを使用するには、後でパブリケーションに追加される各アプリケーションテーブルに追加の特権を発行する必要があります。

5.1.4.3 Postgres Publication Database

パブリケーションデータベース定義を作成するときは、次の特性を持つデータベースユーザー名を指定する必要があります。

•	データベースユーザーは、パブリケーションデータベースに接続できます。

•	データベースユーザーにはスーパーユーザー権限があります。データベース構成パラメーター session_replication_roleが、ある公開データベースから別の公開データベースへの制御スキーマの複製を伴うスナップショット操作のreplicaデータベースユーザーによって変更されるため、スーパーユーザー特権が必要です 。

•	データベースユーザーは、1つのパブリケーションデータベースから別のパブリケーションデータベースへのコントロールスキーマのレプリケーションを含むスナップショット操作のコントロールスキーマテーブルの外部キー制約を無効にするために、システムカタログテーブルを変更する機能を持っている必要があります。 （この要件の詳細については、付録 10.4.4を参照してください 。）

手順1：パブリケーションデータベースユーザーのデータベーススーパーユーザーを作成します。パブリケーションデータベースのユーザー名にはパスワードが必要であり、データベースセッションを作成できる必要があります。パブリケーションデータベースユーザーは、レプリケーションプロセスと履歴を追跡、制御、および記録するためにパブリケーションデータベースに作成されるコントロールスキーマオブジェクトの所有者になります。

パブリケーションデータベース定義を作成するとき、パブリケーションデータベースのユーザー名は、[パブリケーションサービス-データベースの追加]ダイアログボックスに入力されます（セクション 5.2.2を 参照 ）。

CREATE ROLE pubuser WITH LOGIN SUPERUSER PASSWORD 'password';

ステップ2（オプション）：アプリケーションユーザーが必要とするパブリケーションのテーブルとビューにアクセスするために必要な特権を含む1つ以上の「グループ」ロールを作成します。

注：この手順で説明するプロセスは、シングルマスターとマルチマスターの両方のレプリケーションシステムのPostgresパブリケーションに適用できます。

パブリケーションテーブルから選択、挿入、更新、または削除する特権が必要な新しいアプリケーションユーザーを追加する場合は、ロールを使用すると便利です。各ユーザーに各特権を個別に付与する代わりに、必要な特権を含むロールを新しいユーザーに付与できます。

パブリケーションテーブルの挿入、更新、または削除操作を実行するユーザーには、パブリケーションテーブルとそのスキーマ、およびパブリケーションの特定のコントロールスキーマオブジェクトに対する権限が必要です。これらの制御スキーマオブジェクトは、スキーマ _edb_replicator_pub 下にあります 。

次の例は、ロール appgroup 作成と、ロールへのパブリケーションテーブルに対する特権の付与を示しています。

CREATE ROLE appgroup;

GRANT USAGE ON SCHEMA edb TO appgroup;

GRANT SELECT, INSERT, UPDATE, DELETE ON edb.dept TO appgroup;

GRANT SELECT, INSERT, UPDATE, DELETE ON edb.emp TO appgroup;

GRANT SELECT, INSERT, UPDATE, DELETE ON edb.jobhist TO appgroup;

GRANT SELECT, INSERT, UPDATE, DELETE ON edb.salesemp TO appgroup;

また、同期レプリケーションのログベースの方法では、パブリケーションテーブルでTRUNCATEコマンドを許可する場合、次の追加の権限を付与します。

GRANT TRUNCATE ON edb.dept TO appgroup;

GRANT TRUNCATE ON edb.emp TO appgroup;

GRANT TRUNCATE ON edb.jobhist TO appgroup;

また、 TRUNCATEコマンドを使用するための同期レプリケーションのログベースの方法では、パブリケーションデータベース定義の作成後に次の特権を付与します。 （シングルマスターレプリケーションシステムのパブリケーションデータベース定義の作成については、セクション5.2.2を参照してください。マルチマスターレプリケーションシステムについては、セクション6.2.2を参照してください。）

GRANT USAGE ON SCHEMA _edb_replicator_pub TO appgroup;

GRANT INSERT ON _edb_replicator_pub.rrep_wal_events_queue TO appgroup;

最後に、目的のデータベースユーザーにグループロールを付与します。次の例は、新しいユーザーの作成とユーザーへのロールの付与を示しています。

CREATE ROLE appuser WITH LOGIN PASSWORD 'password';

GRANT appgroup TO appuser;

注（パブリケーションの作成後にロールに特権を付与する）：パブリケーションを作成する前に、パブリケーションテーブルの特権を含むロールを作成する必要があります。 （シングルマスター複製システム用のパブリケーションの作成については、セクション5.2.3を参照してください。マルチマスター複製システムについては、セクション6.2.3を参照してください。）

パブリケーションを作成すると、その時点で存在するロールにパブリケーションテーブルで付与された特権が、それらのロールのコントロールスキーマオブジェクトに適用されます。したがって、前述の例では、 edb.dept 、 edb.emp 、 edb.jobhist 、またはedb.salesemp を使用して作成されたパブリケーションのコントロールスキーマオブジェクトに必要な特権は、そのパブリケーションの作成時にロールappgroupに付与されます。

ただし、パブリケーションの作成後にロールを作成する場合、パブリケーションテーブルに必要な特権を明示的に付与し、新しいロールにスキーマオブジェクトを制御する必要があります。

同期レプリケーションのトリガーベースの方法を使用する場合、ロールには、コントロールスキーマオブジェクトに対する次の権限が付与されている必要があります。

•	スキーマ_edb_replicator_pub USAGE特権。

•	シーケンスrrep_tx_seq USAGE特権。

•	ロールが行を挿入、更新、または削除するパブリケーションテーブルに対応するシャドウテーブルに対するINSERT特権。シャドウテーブルは、命名規則rrst_ schema _ table rrst_ schema 。シャドウテーブルは、トリガーベースの同期方法を使用する場合にのみ存在することに注意してください。

次の例は、新しいロールの作成と、パブリケーションテーブルとコントロールスキーマオブジェクトに対する特権の同期レプリケーションのトリガーベースの方法のロールへの付与を示しています。

CREATE ROLE newuser WITH LOGIN PASSWORD 'password';

GRANT USAGE ON SCHEMA edb TO newuser;

GRANT SELECT, INSERT, UPDATE, DELETE ON edb.dept TO newuser;

GRANT SELECT, INSERT, UPDATE, DELETE ON edb.emp TO newuser;

GRANT SELECT, INSERT, UPDATE, DELETE ON edb.jobhist TO newuser;

GRANT USAGE ON SCHEMA _edb_replicator_pub TO newuser;

GRANT USAGE ON SEQUENCE _edb_replicator_pub.rrep_tx_seq TO newuser;

GRANT INSERT ON _edb_replicator_pub.rrst_edb_dept TO newuser;

GRANT INSERT ON _edb_replicator_pub.rrst_edb_emp TO newuser;

GRANT INSERT ON _edb_replicator_pub.rrst_edb_jobhist TO newuser;

ログベースの方法を使用する場合、特定の状況では、ロールはパブリケーションテーブルおよび特定のコントロールスキーマオブジェクトにアクセスする必要があります。

同期レプリケーションのログベースの方法を使用する場合 、パブリケーションテーブルでTRUNCATEコマンドを使用することをロールに許可する場合は、ロールにコントロールスキーマオブジェクトに対する次の権限を付与する必要があります 。

•	スキーマ_edb_replicator_pub USAGE特権。

•	テーブル_edb_replicator_pub.rrep_wal_events_queue INSERT特権。

次の例は、新しいロールの作成と、同期レプリケーションのログベースのメソッドのロールへのパブリケーションテーブルに対する特権の付与を示しています。

CREATE ROLE newuser WITH LOGIN PASSWORD 'password';

GRANT USAGE ON SCHEMA edb TO newuser;

GRANT SELECT, INSERT, UPDATE, DELETE ON edb.dept TO newuser;

GRANT SELECT, INSERT, UPDATE, DELETE ON edb.emp TO newuser;

GRANT SELECT, INSERT, UPDATE, DELETE ON edb.jobhist TO newuser;

さらに 、パブリケーションテーブルでTRUNCATEコマンドを許可する場合は 、次の追加の特権を付与します。

GRANT TRUNCATE ON edb.dept TO newuser;

GRANT TRUNCATE ON edb.emp TO newuser;

GRANT TRUNCATE ON edb.jobhist TO newuser;

GRANT USAGE ON SCHEMA _edb_replicator_pub TO newuser;

GRANT INSERT ON _edb_replicator_pub.rrep_wal_events_queue TO newuser;

5.1.5 Preparing the Subscription Database

このセクションでは、サブスクリプションデータベースとして使用されるデータベースの準備について説明します。

特定のパブリケーションのテーブルとビューはすべて同じデータベースに複製する必要があります。このデータベースは、サブスクリプションデータベースと呼ばれます。 サブスクリプションデータベースのユーザー名は、次の特性を使用して作成する必要があります。

•	サブスクリプションデータベースユーザーは、サブスクリプションデータベースに接続できます。

•	サブスクリプションデータベースユーザーには、パブリケーションからレプリケートされたテーブルとビューのデータベースオブジェクトを作成する権限があります。

•	サブスクリプションデータベースユーザーには 、レプリケートされたテーブルでTRUNCATEコマンドを実行するために必要な特権があります 。

Postgresサブスクリプションデータベースの準備については、 セクション 5.1.5.1を参照してください 。 Oracleサブスクリプションデータベースの準備については、セクション5.1.5.2を参照してください。 SQL Serverサブスクリプションデータベースの準備については、セクション5.1.5.3を参照してください。

5.1.5.1 Postgres Subscription Database

サブスクリプションデータベースユーザーとして機能するデータベースユーザー名を選択または作成する必要があります。ユーザー名にはパスワードが必要です。サブスクリプションデータベースユーザーは、レプリケートされたデータベースオブジェクトの所有者になります。

サブスクリプションデータベース定義を作成するとき、サブスクリプションデータベースのユーザー名が[サブスクリプションサービス-データベースの追加]ダイアログボックスに入力されます（セクション 5.3.2を 参照 ）。

サブスクリプションデータベースユーザーは 、サブスクリプションテーブルでTRUNCATEコマンドを実行する機能も持っている必要があります 。これには以下が必要です。

•	サブスクリプションデータベースユーザーには、スーパーユーザー権限が必要です。

•	サブスクリプションデータベースユーザーは、サブスクリプションテーブルの外部キー制約を無効にするために、システムカタログテーブルを変更できる必要があります。 （この要件の詳細については、付録 10.4.4を参照してください 。）

サブスクリプションデータベースのユーザー名を選択するには、次の2つの選択肢があります。

•	サブスクリプションデータベースのユーザー名には、PostgreSQLのインストール時に作成されたPostgresユーザー名 postgres （Oracle互換構成モードでインストールされたAdvanced Serverのenterprisedb ）を使用します。このオプションを選択した場合は、手順1をスキップして手順2に進みます。

•	新しいサブスクリプションデータベースユーザー名を作成します。このオプションについては、手順1に進みます。

手順1：サブスクリプションデータベースユーザーとしてスーパーユーザーを作成します。

CREATE ROLE subuser WITH LOGIN SUPERUSER PASSWORD 'password';

ステップ2：サブスクリプションデータベースを作成または選択します。

パブリケーションテーブルとビューを含むスキーマの名前は、サブスクリプションテーブルのPostgresスキーマの名前になります。サブスクリプションサーバーは、サブスクリプションが作成されると、サブスクリプションデータベースにこれらのスキーマを作成します。これらの名前のスキーマがサブスクリプションデータベースに既に存在する場合、既存のスキーマがサブスクリプションテーブルの格納に使用されます。

SQL Serverパブリケーションデータベースの場合：SQL Serverのパブリケーションテーブルとビューを含むスキーマの名前がdbo場合、サブスクリプションサーバーは、サブスクリプションテーブルのPostgresサブスクリプションデータベースにdbo_sqlという名前のスキーマを作成します。 （スキーマdboは、Postgresで特別に予約されたスキーマです。）

既存のスキーマには、パブリケーションのテーブルおよびビューと同じ名前のテーブルまたはビューを含めることはできません。同じ名前のテーブルまたはビューが既に存在する場合、サブスクリプションサーバーはエラーを返します。サブスクリプションを作成する前に、これらのテーブルとビューを削除または名前変更する必要があります。

サブスクリプションデータベースユーザー subuser ユーザーが所有する新しいサブスクリプションデータベースは、次を使用して作成できます。

CREATE DATABASE subdb OWNER subuser;

5.1.5.2 Oracle Subscription Database

ステップ1（オプション）：サブスクリプションデータベースとして使用する既存のデータベースがない場合は、新しいデータベースを作成します。このステップはかなり複雑になる可能性があります。このタスクを実行するには、適切なOracleのドキュメントを参照してください。

手順2：サブスクリプションデータベースユーザーのデータベースユーザー名を作成します。サブスクリプションデータベースのユーザー名にはパスワードが必要であり、データベースセッションを作成できる必要があります。サブスクリプションデータベースユーザーは、レプリケートされたデータベースオブジェクトの所有者になります。

注（Oracle 12c Pluggable Databaseの場合）：サブスクリプションデータベースユーザーは、Oracle ローカルユーザーまたは共通ユーザーにすることができます 。ローカルユーザーは、サブスクリプションデータベースとして使用される単一のユーザー作成のプラガブルデータベース （PDB）内にのみ存在し、アクセスできます。一般的なユーザー名は通常C##またはc##始まり、複数のプラグ可能なデータベースにアクセスできます。

注（Oracle 12cプラグ可能データベースの場合）：サブスクリプションデータベースとして使用するプラグ可能データベースに接続している間に、ローカルユーザーの特権の作成と付与を行う必要があります。共通ユーザーの作成は、Oracle 12cルートコンテナーCDB$ROOT内で行う必要があります。共通ユーザーへの特権の付与は、サブスクリプションデータベースとして使用するプラガブルデータベースに接続している間に行う必要があります。

注（Oracle 12c非コンテナーデータベースの場合）：サブスクリプションデータベースユーザーへの特権の作成と付与は、12cより前のOracleバージョンと同じ方法で実行されます。

サブスクリプションデータベース定義を作成するとき、サブスクリプションデータベースのユーザー名が[サブスクリプションサービス-データベースの追加]ダイアログボックスに入力されます（セクション 5.3.2を 参照 ）。

CREATE USER subuser IDENTIFIED BY password;

GRANT CONNECT TO subuser;

手順3：複製されたデータベースオブジェクトの作成に必要な特権を付与します。

レプリケートされたデータベースオブジェクトは、サブスクリプションデータベースユーザーが所有するスキーマに、サブスクリプションデータベースユーザーと同じ名前で作成されます。

GRANT RESOURCE TO subuser;

ステップ4（Oracle 12cのみ）：テーブルスペースにアクセスするために必要な特権を付与します。 GRANT UNLIMITED TABLESPACE特権をサブスクリプションデータベースユーザーに付与する必要があります。この要件は、プラガブルデータベースと非コンテナデータベースの両方に適用されます。

GRANT UNLIMITED TABLESPACE TO subuser;

5.1.5.3 SQL Server Subscription Database

ステップ1：サブスクリプションデータベースを作成または選択します。

パブリケーションテーブルとビューを含むスキーマの名前は、サブスクリプションテーブルのSQL Serverスキーマの名前になります。サブスクリプションサーバーは、サブスクリプションが作成されると、サブスクリプションデータベースにこれらのスキーマを作成します。これらの名前のスキーマがサブスクリプションデータベースに既に存在する場合、既存のスキーマがサブスクリプションテーブルの格納に使用されます。

注：パブリケーションテーブルとビューを含むスキーマの名前がpublic場合、サブスクリプションサーバーは、サブスクリプションテーブルのSQL Serverサブスクリプションデータベースにpublic_sqlという名前のスキーマを作成します。

既存のスキーマには、パブリケーションのテーブルおよびビューと同じ名前のテーブルまたはビューを含めることはできません。同じ名前のテーブルまたはビューが既に存在する場合、サブスクリプションサーバーはエラーを返します。サブスクリプションを作成する前に、これらのテーブルとビューを削除または名前変更する必要があります。

次のように、新しいサブスクリプションデータベースを作成できます。

USE master;

GO

CREATE DATABASE subdb;

GO

手順2：サブスクリプションデータベースユーザーのSQL Serverログインを作成します。ログインにはパスワードが必要です。

サブスクリプションデータベース定義を作成するとき、SQL Serverログインが[サブスクリプションサービス-データベースの追加]ダイアログボックスに入力されます（セクション 5.3.2を 参照 ）。

CREATE LOGIN subuser WITH PASSWORD = 'password';

GO

ステップ3：サブスクリプションデータベースには、サブスクリプションテーブルの作成者および所有者となるデータベースユーザーが存在する必要があります。このデータベースユーザーは、手順2で作成したSQL Serverログインにマップする必要があります。

この例では、データベースユーザーにはSQL Serverログイン subuser ユーザーと同じ名前が付けられます 。

USE subdb;

GO

CREATE USER subuser FOR LOGIN subuser;

GO

手順4：サブスクリプションのスキーマとテーブルを作成するために、サブスクリプションデータベースユーザーが必要とするデータベースレベルの権限を付与します。

GRANT CREATE SCHEMA TO subuser;

GRANT CREATE TABLE TO subuser;

GO

5.1.6 Verifying Host Accessibility

複数のコンピューターを使用してレプリケーションシステムのコンポーネントをホストする場合、各コンピューターはネットワーク上の他のコンピューターと通信できる必要があります。

次のセクションで説明するように、このトピックにはさまざまな側面があります。

5.1.6.1 Firewalls and Access to Ports

ホスト上のファイアウォールが、レプリケーションシステムコンポーネントを実行している他のホストからのアクセスを許可していることを確認します。アクセシビリティを有効にするには、ホストのオペレーティングシステムの指示を参照してください。

さらに、パブリケーションサーバーまたはサブスクリプションサーバーが実行されているホストとは異なるホストでxDB Replication ConsoleまたはxDB Replication Server CLIを実行している場合、これらのサーバーを実行しているホストのファイアウォールがパブリケーションで使用されるポートへのアクセスを許可していることを確認してくださいサーバーおよびサブスクリプションサーバー。

xDBレプリケーションコンソールとxDBレプリケーションサーバーCLIは、指定されたポートを介してJavaリモートメソッド呼び出し（RMI）を使用して、パブリケーションサーバーとサブスクリプションサーバーにアクセスします。

パブリケーションサーバーは、セクション 3.1の 手順16の[パブリケーションサーバーの詳細]画面で指定したポート番号と、この指定したポート番号より2大きい値のポートオフセットを使用します。したがって、デフォルトのパブリケーションサーバーのインストールでは、ポート番号9051および9053にアクセスする必要があります。

サブスクリプションサーバーは、セクション 3.1の ステップ17の[サブスクリプションサーバーの詳細]画面で指定したポート番号と、この指定したポート番号より2大きい値のポートオフセットを使用します。そのため、デフォルトのサブスクリプションサーバーのインストールでは、ポート番号9052および9054にアクセスする必要があります。

xDB Replication Serverをインストールすると、パブリケーションサーバーとサブスクリプションサーバーに指定したポート番号は、次の例に示すようにxDBスタートアップ構成ファイルに保存されます。 xDBスタートアップコンフィギュレーションファイルの詳細については、セクション 2.3.1.4を参照してください 。

#!/bin/sh

 

JAVA_EXECUTABLE_PATH="/usr/bin/java"

JAVA_MINIMUM_VERSION=1.7

JAVA_BITNESS_REQUIRED=64

JAVA_HEAP_SIZE="-Xms256m -Xmx1536m"

PUBPORT=9051

SUBPORT=9052

別のポート番号を使用する場合は、xDBスタートアップ構成ファイルの PUBPORTおよびSUBPORTエントリを変更し 、パブリケーションサーバーとサブスクリプションサーバーを再起動します。

注：既存のレプリケーションシステムがあるパブリケーションサーバーまたはサブスクリプションサーバーのポート番号を変更する場合、これらの既存のレプリケーションシステムで実行する必要がある追加の更新があります。サブスクリプションサーバーで使用されるポート番号が変更された場合、コントロールスキーマ内のパブリケーションサーバーメタデータに対して行う必要がある変更については、セクション7.6.1.2を参照してください。パブリケーションサーバーが使用するポート番号が変更された場合に、コントロールスキーマ内のサブスクリプションメタデータに対して行う必要がある変更については、セクション5.5.3を参照してください。

5.1.6.2 Network IP Addresses

レプリケーションシステムを構成する場合、パブリケーションサーバー、サブスクリプションサーバー、パブリケーションデータベースサーバー、サブスクリプションデータベースサーバーなどのさまざまなコンポーネントのネットワークの場所を指定する必要があります。コンポーネントのIPアドレスとポート番号で構成されるこの情報は、制御スキーマに保存されます。

あるコンポーネントが別のコンポーネントにアクセスする必要がある場合、コントロールスキーマに保存されているネットワークの場所を参照します。

レプリケーションシステムの構成中に、すべてのコンポーネントが同じホストで実行されている場合でも、各コンポーネントの実際のネットワークIPアドレスを提供し、ループバックアドレスlocalhostまたは127.xxxの使用を避けることを強くお勧めします。

次のコマンドを使用して、ネットワークIPアドレスを取得できます。

Linuxのみ： /sbin/ifconfigコマンドを使用します。

Windowsのみ：コマンドプロンプトウィンドウを開き、 ipconfigコマンドを使用します。

ループバックアドレスは、通信するコンポーネントが同じホスト上にある限り機能しますが、将来、コンポーネントをネットワーク上の別のホストに移動する場合、ループバックアドレスはコンポーネントのネットワークアドレスとして制御スキーマに保存されます。接続を確立しようとするコンポーネントでは機能しなくなります。

Linuxのみ：ホストのネットワークIPアドレスがホスト名に関連付けられるように、 /etc/hostsファイルを変更する必要がある場合があります。

注： /etc/hostsファイルを変更する代替方法については、セクション10.4.1.7を参照してください。

Linuxシステムのデフォルト設定では、次の例に示すように、ホスト名を /etc/hostsファイルのループバックアドレスに関連付けます。

127.0.0.1 localhost.localdomain localhost

これは 、ホスト名に関連付けられたIPアドレスを返すhostname -iコマンドを使用して確認することもできます。

$ hostname -i

127.0.0.1

これらの状況では、特定のxDB Replication Serverコンポーネントは、次の場合のようにネットワーク上の他のコンポーネントを見つけるのに問題があります。

•	ユーザーインターフェイスがパブリケーションサーバーまたはサブスクリプションサーバーに接続しようとするとき

•	サブスクリプションサーバーがパブリケーションサーバーに接続しようとするとき

ループバックアドレスが 127. x 場合 . x .上記の例のようにxが返されます。代わりにネットワークIPアドレスがホスト名に関連付けられるように/etc/hostsファイルを編集/etc/hostsます。

次の例は、ホスト名localhostがループバックアドレス127.0.0.1ではなくネットワークIPアドレス192.168.2.22に関連付けられるように変更された /etc/hostsファイルを示して /etc/hostsます。

#127.0.0.1 localhost.localdomain localhost

192.168.2.22 localhost.localdomain localhost

::1 localhost6.localdomain6 localhost6

一部のLinuxシステムでは、 /etc/hostsファイルを変更した後にネットワークサービスを再起動する必要がある場合があります。これは、次のバリエーションに示すように、使用しているLinuxシステムに応じてさまざまな方法で実行できます。

サービスネットワークの再起動

/etc/init.d/networking restart

sudo /etc/init.d/networking restart

次の例は、 service networkコマンドを示して service network 。

$ su root

Password:

$ service network restart

Shutting down loopback interface: [ OK ]

Bringing up loopback interface: [ OK ]

CentOS 7またはRHEL 7には次のコマンドを使用します。

systemctl restart network

hostname -iコマンドはホストのネットワークIPアドレスを返します。

$ hostname -i

192.168.2.22

5.1.6.3 Postgres Server Authentication

Postgresデータベースサーバーは、ホストベースの認証ファイル pg_hba.conf使用して、データベースサーバー内のデータベースへのアクセスを制御します。

次の場所にある pg_hba.confファイルを変更する必要があります。

•	Postgresパブリケーションデータベースを含む各Postgresデータベースサーバー

•	Postgresサブスクリプションデータベースを含む各Postgresデータベースサーバー

デフォルトのPostgresインストールでは、このファイルはディレクトリ POSTGRES_INSTALL_HOME /data 。

前述の各ケースでpg_hba.confファイルに必要な変更については、次のセクションで説明します。

Postgres出版データベース

Postgresパブリケーションデータベースの場合、パブリケーションデータベースへのアクセスを許可するには以下が必要です。

ホスト pub_dbname pub_dbuser pub_ipaddr / 32 md5

ホスト pub_dbname pub_dbuser sub_ipaddr / 32 md5

pub_dbname 代わりに pub_dbname 値は、使用するPostgresパブリケーションデータベースの名前です。 pub_dbuser代わりにpub_dbuser値は、セクション5.1.4.3の手順1で作成したパブリケーションデータベースのユーザー名です。

edb という名前のPostgresパブリケーションデータベースの場合、結果のpg_hba.confファイルは次のように表示されます。

# TYPE DATABASE USER ADDRESS METHOD

 

# "local" is for Unix domain socket connections only

local all all md5

# IPv4 local connections:

host edb pubuser 192.168.2.22/32 md5

host all all 127.0.0.1/32 md5

# IPv6 local connections:

host all all ::1/128 md5

# Allow replication connections from localhost, by a user with the

# replication privilege.

#local replication enterprisedb md5

#host replication enterprisedb 127.0.0.1/32 md5

#host replication enterprisedb ::1/128 md5

注：上記の例では、パブリケーションサーバーとサブスクリプションサーバーが同じホスト上で実行されているため、データベースedb単一エントリがedbれています。パブリケーションサーバーとサブスクリプションサーバーが別々のホストで実行されている場合、パブリケーションデータベースサーバー上のpg_hba.confファイルは次のようになります。

# TYPE DATABASE USER ADDRESS METHOD

 

# "local" is for Unix domain socket connections only

local all all md5

# IPv4 local connections:

host edb pubuser 192.168.2.22/32 md5

host edb pubuser 192.168.2.24/32 md5

host all all 127.0.0.1/32 md5

# IPv6 local connections:

host all all ::1/128 md5

# Allow replication connections from localhost, by a user with the

# replication privilege.

#local replication enterprisedb md5

#host replication enterprisedb 127.0.0.1/32 md5

#host replication enterprisedb ::1/128 md5

さらに、前述の例では、パブリケーションデータベース edbがトリガーベースの同期レプリケーションの方法を使用していることを前提としています 。ログベースの方法を使用する場合、 pg_hba.confファイルには、DATABASEフィールドがpub_dbname 、 pub_dbuser 、およびpub_ipaddr replicationに設定された追加のエントリが含まれている必要があります。

次に、この追加エントリをファイルの最後の行として使用して、前述の例を修正します。

# TYPE DATABASE USER ADDRESS METHOD

 

# "local" is for Unix domain socket connections only

local all all md5

# IPv4 local connections:

host edb pubuser 192.168.2.22/32 md5

host edb pubuser 192.168.2.24/32 md5

host all all 127.0.0.1/32 md5

# IPv6 local connections:

host all all ::1/128 md5

# Allow replication connections from localhost, by a user with the

# replication privilege.

#local replication enterprisedb md5

#host replication enterprisedb 127.0.0.1/32 md5

#host replication enterprisedb ::1/128 md5

host replication pubuser 192.168.2.22/32 md5

ログベースの方法を使用した同期レプリケーションの詳細については、セクション 2.2.10および5.1.2を参照してください 。

変更を行った後、構成ファイルを再ロードします。

Postgresアプリケーションメニューから[構成の再読み込み]（エキスパート構成、[Advanced Server上の構成の再読み込み]）を選択します。これにより、変更された pg_hba.confファイルが有効になります。

Postgresサブスクリプションデータベース

Postgresサブスクリプションデータベースの場合、サブスクリプションデータベースへのアクセスを許可するには、次のエントリが必要です。

ホスト sub_dbname sub_dbuser pub_ipaddr / 32 md5

ホスト sub_dbname sub_dbuser sub_ipaddr / 32 md5

sub_dbuserおよびsub_dbname 代わりに sub_dbuser 値は、セクション5.1.5.1の手順1および2で作成したサブスクリプションデータベースユーザー名とサブスクリプションデータベース名です。

subdb という名前のPostgresサブスクリプションデータベースの場合、結果のpg_hba.confファイルは次のように表示されます。

# TYPE DATABASE USER ADDRESS METHOD

 

# "local" is for Unix domain socket connections only

local all all md5

# IPv4 local connections:

host subdb subuser 192.168.2.22/32 md5

host all all 127.0.0.1/32 md5

# IPv6 local connections:

host all all ::1/128 md5

# Allow replication connections from localhost, by a user with the

# replication privilege.

#local replication enterprisedb md5

#host replication enterprisedb 127.0.0.1/32 md5

#host replication enterprisedb ::1/128 md5

注：前の例では、パブリケーションサーバーとサブスクリプションサーバーが同じホスト上で実行されているため、データベースsubdb必要なエントリは1つだけsubdb 。パブリケーションサーバーとサブスクリプションサーバーが別々のホストで実行されている場合、サブスクリプションデータベースサーバー上のpg_hba.confファイルは次のようになります。

# TYPE DATABASE USER ADDRESS METHOD

 

# "local" is for Unix domain socket connections only

local all all md5

# IPv4 local connections:

host subdb subuser 192.168.2.22/32 md5

host subdb subuser 192.168.2.24/32 md5

host all all 127.0.0.1/32 md5

# IPv6 local connections:

host all all ::1/128 md5

# Allow replication connections from localhost, by a user with the

# replication privilege.

#local replication enterprisedb md5

#host replication enterprisedb 127.0.0.1/32 md5

#host replication enterprisedb ::1/128 md5

変更を行った後、構成ファイルを再ロードします。

Postgresアプリケーションメニューから[構成の再読み込み]（エキスパート構成、[Advanced Server上の構成の再読み込み]）を選択します。これにより、変更された pg_hba.confファイルが有効になります。