TOP>企業情報>コラム>技術情報>xDB Replication Server解説

xDB Replication Server解説

EDB Postgres

前回は、「Postgres Plus 9.3 いかに進化したのか検証してみた」と題してPostgreSQLに未実装のエンタープライズ向け機能を強力に補完したRDBMSである「Postgres Plus 9.3」の技術情報をご紹介しました。続く本稿では、Postgres Plus Enterprise Editionのデータ連携機能「xDB Replication Server」の詳細をご紹介します。

レプリケーション機能の利用シーン


レプリケーションとは、あるデータベース・サーバのデータと同じ内容の複製(レプリカ)を異なるデータベース・サーバに作成し、つねに内容を同期させる機能を指します。主に負荷分散や耐障害性の向上などを目的に利用します。

PPEEに実装されるxDB Replication Serverはテーブル単位でデータを複製する機能で、1つのマスタサーバと1つ以上のスレーブサーバで構成するシングルマスタレプリケーションと、複数のマスタサーバで構成するマルチマスタレプリケーションをサポートしています。シングルマスタレプリケーションは商用RDBMSとの連携もサポートしており、様々な用途で利用することができます。今回は、シングルマスタレプリケーションの利用シーンをいくつかご紹介します。

1)Web系サービス


インターネット系サービスのバックグラウンドは、図1のように3階層で処理を分散しながら、各階層が横にも展開できる構成になっているのが一般的です。WebサーバやAPサーバはデータを持たないため、ビジネスの成長に合わせてサーバを追加しシステム全体の処理能力を強化することが比較的簡単ですが、データベースはデータを保持するためサーバの追加は容易ではありません。Oracle Real Application Clusters(以下、RAC)のようなアクティブ‐アクティブ構成を採用できればデータベースは1つのままでデータを処理するサーバを追加可能ですが、システム規模などによっては採用が厳しい実情があります。

このような場合にAPサーバからの処理を一時的に引き受けるフロントデータベースを複数のPPEEで構築し、そのバックエンドにOracle Databaseを配置します。例えば、ショッピング系サイトで処理全体の約9割を占めるといわれる「商品検索」の参照系処理を顧客IDをキーにしてPPEEへ振り分けることで負荷分散し、「商品購入」の更新系処理はOracle Databaseで行います。Oracle Databaseで管理されている商品情報等をxDB Replication Serverを介してPPEEへリアルタイムに連携することで参照負荷を分散させた構成を実現します。

Web系サービス

図1:Web系サービス

2)基幹システムからサブシステムへのデータ連携


マスタデータを管理する基幹システムと周辺システムとの間でデータを受け渡すといった複数システム間のデータ連携は多くのシステムで必要不可欠になっています。これまでは、基幹システムから周辺システムへのデータ取り込みは主に夜間バッチが中心だったため、担当者が最新データを確認できるのは最短で翌朝という状態でした。このタイムラグを抑えるために担当者が基幹システムに直接アクセスしてしまうと、基幹システムへの負荷の集中が課題になります。

図2のようにxDB Replication Serverを利用することで各支店などのサブシステムに必要なデータのみをリアルタイムに連携できるため、各システムで常に最新データの参照を可能にし、マスタデータへのアクセスも防止します。

基幹システムからサブシステムへのデータ連携

図2:基幹システムからサブシステムへのデータ連携

3)DWH処理をオフロード


急激なデータ量増加とタイムリーで正確な情報分析への要求も増大し続ける中、これまで日単位から週単位で設定されていたデータウェアハウスへのデータロードのバッチ処理に可能な限り最新データが求められるようになり、オンライン処理と同一のサーバでデータウェアハウス処理が行われているケースも少なくありません。その場合、処理によってサーバ負荷が高くなるという課題があります。

図3のようにデータウェアハウス処理に必要なデータのみを切り出して参照用データベースへ配置し、xDB Replication Serverを介してデータ連携を行うことで、オンライン処理への影響を最小限に抑えながら最新データによる情報分析を可能にします。また、参照用データベースのテーブルデータはパーティション機能で複数の子テーブルへ分割配置することで、パーティション・プルニングによってアクセス対象のデータが絞り込まれディスクI/Oを抑制できます。さらに各子テーブルをそれぞれ異なるディスクへ配置することで検索性能の更なる向上を図ります。

図3:DWH処理をオフロード

図3:DWH処理をオフロード

4)災害対策


ITと事業そのものが切り離せない関係となっている現在、システムの継続性はそのまま事業の継続性に直結します。そのため事業やシステム規模に関わらず、多くの企業で災害対策が検討されています。

xDB Replication Serverではテーブル単位(またはフィルタリングした特定の行データ)で連携できるため、遠隔地のバックアップ・データベースに重要なデータを配置しxDB Replication Serverを介して差分データのみを適宜連携します。大掛かりな災害対策がすぐに実施できない企業ではデータ保全の有効策と言えます。

災害対策

図4:災害対策

5)データベース移行


システムの中核であるデータベースを移行する場合、どのような方法で移行するか、システム停止時間を最小化するにはどうすればよいかなど多くの課題があります。

Oracle DatabaseからPPEEへ切り替える場合、PPEEで提供されているMigration Toolkit(以下、MTK)を利用します。MTKではストアドプログラムを含むOracle Databaseの主要オブジェクトが移行対象となっており、オブジェクト定義(DDL)とデータの一括移行に加え、定義またはデータのみの移行やスキーマ単位の移行など範囲を限定した移行も可能です。また、図5のように更新が行われないテーブルはMTKを利用して事前に移行しておき、切り替え直前まで更新処理が発生するテーブルはxDB Replication Serverで移行先へリアルタイムにデータを反映させることで、データ移行時のシステム停止時間を最小に抑えることができます。

データベース移行

図5:データベース移行

次項では、データベース間でデータを連携できるxDB Replication Serverの仕組みをご紹介します。

xDB Replication Serverのアーキテクチャ


xDB Replication Serverでは「Publish」と「Subscribe」と呼ばれる仕組みが使われています。Publisher(発行者)である連携元のデータベースのデータをSubscriber(購読者)である連携先のデータベースに届ける仕組みです。このPublishとSubscribeの仕組みを利用することで、連携先が変更になったり新たに追加された場合でも連携元の実装は変更する必要はなく、データ連携の柔軟性を確保することができます。

xDB Replication Serverでは、対象のテーブルおよびビューを1つのグループにまとめて「Publication」として定義し、このPublicationが格納されるデータベースを「Publication Database」と呼びます。

シングルマスタレプリケーションでは、データを受け取る側に「Subscription」を定義します。SubscriptionはPublicationと1対1の関係にあり、Publicationに含まれるテーブルとビュー(※1)に対応するテーブル群がSubscription Tableとして生成されます。尚、Subscriptionが格納されるデータベースを「Subscription Database」と呼びます。

(※1)ビューを連携対象とした場合、Subscription側ではテーブルとして定義されます。

xDB Replication Serverの基本アーキテキチャ

図6:xDB Replication Serverの基本アーキテキチャ

また、xDB Replication Serverは図7にあるように4つのシンプルなコンポーネントで構成されています。各コンポーネントはインストール時のウィザードに従って設定するだけで使えるようになります。

xDB Replication Serverを構成する基本コンポーネント

図7:xDB Replication Serverを構成する基本コンポーネント

1. Sublication Serverは、Publicationのメタデータ情報を管理するための内部オブジェクトをPublication DatabaseとxDB Control Databaseに生成するプロセスを指します。また、Publication Serverはデータ連携そのものも担当します。

2. Subscription Serverはシングルマスタレプリケーション環境でのみ動作するプロセスで、Subscriptionが作成されるとSubscriptionのメタデータ情報を管理するための内部オブジェクトをSubscription DatabaseとxDB Control Databaseに生成します。あわせてSubscription DatabaseにSubscription Tableを作成しますが、定義のみでテーブルへのデータ挿入は上述のとおりPublication Serverが担います。

3. xDB Control DatabaseはxDB Replication Server環境の主要メタデータが格納されたリポジトリデータベースです。メタデータにはレプリケーションの種類(シングルマスタなのかマルチマスタなのか)やPublication DatabaseやSubscription Databaseに対する接続情報、Publicationの名前やそれに含まれるテーブルとビューの情報、レプリケーション履歴情報などがあります。

4. xDB Replication Configuration FileはPublication ServerとSubscription Serverの各プロセスが起動する際に必要な接続情報や認証情報が記載されたテキストファイルです。

xDB Replication Serverには図8のようなxDB Replication Consoleと呼ばれるGUIツールが提供されており、レプリケーション環境の構築からデータ連携のスケジューリング設定、データ連携の状況確認など運用までを一元的に行うことができます。加えて、xDB Replication Server CLIと呼ばれるCUIベースのJavaアプリケーションも提供されており、xDB Replication Consoleが稼働する同一サーバ上でConsoleと同様の操作を行うことができるため、スクリプトなどへ処理を組み込んだバッチ実行に便利です。

xDB Replication Console

図8:xDB Replication Console

xDB Replication Serverのデータ連携はユーザの処理とは非同期で動作する仕組みをとっており、「Snapshot」と「Synchronization」と呼ばれる2種類の方式が実装されています。

Snapshotは表の全データを対象として連携先のデータを一旦TRUNCATEで削除し、データを再投入する方式です。データのやりとりはJDBC経由で行われており、Subscription Databaseが商用RDBMSの場合、INSERT文をまとめて処理するJDBCバッチ更新機能が利用されています。Subscription DatabaseがPPEEの場合、JDBCバッチ更新機能よりも高速にデータ投入ができるJDBC COPYコマンドが採用されています。

Synchronizationは、Publicationのテーブルに加えられた更新データのみを連携先へ引き渡す方式です。シングルマスタレプリケーション環境でPublicationが作成されると、そのPublicationに含まれる各テーブルにINSERT、UPDATE、DELETEトリガが定義されます。あわせてシャドウテーブルと呼ばれる更新情報を格納するテーブルが対象テーブルごとに作成され、INSERTの場合はINSERT対象の行データ、UPDATEの場合はUPDATE後の行データ、DELETEの場合はDELETE対象の主キーがそれぞれ格納されます。Publication Serverはシャドウテーブルの情報を元にSubscriptionの各テーブルに更新データのみを連携します。連携が完了した行データは、xDB Replication Console上で履歴として簡単に確認することができます。

SnapshotとSynchronization

図9:SnapshotとSynchronization

レプリケーション環境のメンテナンスに関するHow to


xDB Replication Serverを使って複数サーバ間でデータ連携をするシステムでは、メンテナンス作業時に注意すべき事項がいくつかあります。またデータ連携方式がSnapshotなのかSynchronizationなのかによってSubscription Databaseでおさえておくべきポイントが異なります。本章では図10のようなOracle DatabaseをPublication Database、PPEEをSubscription Databaseとした構成でメンテナンスに関するHow toを紹介します。

Oracle DatabaseとPPEE間のレプリケーション

図10:Oracle DatabaseとPPEE間のレプリケーション

ケース1:テーブルの再作成


フラグメンテーション解消などを目的として、図11のようにEXPORTユーティリティを使って該当テーブルの論理バックアップを取得し、テーブルを削除後にIMPORTユーティリティでリストアするケースがあります。

Publication Databaseの対象テーブルには更新情報をシャドウテーブルに格納するためのトリガが設定されています。テーブル単位のEXPORTではトリガも取得対象となるため、xDB Replication ServerのPublicationはIMPORT実施後に有効な状態で復旧されます。また、IMPORTではテーブルデータを挿入した後にトリガが作成されるため、トリガが働いてIMPORT対象のデータが不必要にシャドウテーブルに格納されてしまうということもありません。

Subscription Databaseではデータ連携方式がSnapshotの場合、Subscriptionを再作成する必要はありませんが、メンテナンス作業中はスケジューリングされたデータ連携ジョブを停止する必要があります。Synchronizationの場合は、Publication Databaseでのテーブル再作成前にSubscriptionを削除し、テーブルの再作成が完了した後にSubscriptionを再設定します。

テーブル再作成

図11:テーブル再作成

ケース2:インデックスの再作成、追加と削除


SQL処理の性能改善などを目的として、図12のように既存インデックスの再作成や削除、また、インデックスを追加するケースがあります。

この場合、Publication Databaseはテーブルデータそのものに変更は加わらないため、特に注意すべき事項はありません。

一方、Subscription Databaseではデータ連携方式がSnapshotの場合、インデックスもテーブルデータと同じく連携対象となるため、メンテナンス作業中は連携処理が行われないようにスケジューリングされたデータ連携ジョブを停止する必要があります。またSynchronizationの場合、メンテナンスされたインデックスは連携対象とならないため、Subscription Database側で別途インデックスの再作成、追加または削除を実施します。

インデックスの再作成、追加と削除

図12:インデックスの再作成、追加と削除

ケース3:列の追加と削除


図13のように対象のテーブルに列を追加したり、不要な列を削除するケースではオブジェクト構成に変更が入るため特に注意が必要です。

対象テーブルの各列の情報を持つシャドウテーブルにはテーブルの列に対する変更は反映されないため、列定義変更後のデータ連携時にエラーが発生します。そのため、Publication Databaseではメンテナンス作業前にPublicationを削除し、作業後に再作成します。

データ連携方式がSnapshotの場合、Publication Databaseでの列の変更情報はSubscription Databaseへ連携されないため、エラーが発生します。それを防ぐためにはメンテナンス作業前にSubscriptionとともに実テーブルを明示的に削除し、作業後に再作成します。

Synchronizationの場合、メンテナンスの内容によって挙動が異なります。列の追加では対象の列以外のデータが連携され、列の削除ではPublication Databaseのシャドウテーブルに更新データが格納されるタイミングで以下のエラーが発生します。

エラー


そのため、いずれの場合もSnapshotと同じようにメンテナンス作業前にSubscriptionとともに実テーブルを明示的に削除し、作業後に再作成します。

列の追加と削除

図13:列の追加と削除

ケース4:TRUNCATE処理


図14のように対象テーブルに対してTRUNCATEが実行された場合、Publication Databaseでは特に注意事項はありません。

データ連携方式がSnapshotの場合、内部動作はTRUNCATEのためPublication Databaseのデータ更新が反映されます。Synchronizationの場合、DDLであるTRUNCATE処理は連携されません。そのためメンテナンス作業中はスケジューリングされたデータ連携ジョブを停止し、作業完了後に再設定します。

TRUNCATE処理

図14:TRUNCATE処理

ケース5:データベースの計画停止


メンテナンス作業のために図15のようにPublication DatabaseとSubscription Databaseそれぞれを計画停止する場合を見てみましょう。

Publication Databaseを停止した場合、Subscription Databaseではデータ連携方式がSnapshot、Synchronizationいずれの場合もデータ連携は行われないため、データ不整合が発生することはありません。

Subscription Databaseを停止した場合、スケジューリングされたデータ連携ジョブが実行されたタイミングで制御DBの履歴テーブルに以下のエラーが蓄積されます。

エラー


データ連携方式がSnapshotの場合、履歴テーブルにエラーが蓄積され続けるため、ジョブスケジュールの間隔を調整するか一時的な削除を検討します。Synchronizationの場合も対処は同じですが、データベースを再起動するとシャドウテーブルに蓄積されていた更新データが一括で連携されてしまうため、ネットワーク負荷に配慮が必要です。尚、更新データ量によってはSnapshotでデータを再取得したほうが効率が良い場合があります。

データベースの計画停止

図15:データベースの計画停止

ケース6:バックアップ


図16のようにPublication Database、Subscription Database、xDB Control Databaseのバックアップに関して見ていきましょう。

6‐1)Publication Database

連携元であるPublication Databaseには対象テーブルとあわせてシャドウテーブル、メタデータテーブルが格納されており、最も重要なデータです。Publication Databaseが障害により異常停止に陥ったり、データを消失した場合、xDB Replication Serverによるデータ連携ができなくなり、連携先のシステムにも大きな影響が及ぶ可能性があります。そのため、バックアップは物理オンラインバックアップの取得をお勧めします。

6‐2)Subscription Database

連携先であるSubscription Databaseには対象テーブルのみ格納されています。

Subscription Databaseが障害によって異常停止に陥ったり、データを消失した場合、データ連携時にエラーが発生し、Publication Databaseからデータの再取得が必要になりますが、元データはPublication Databaseで保持されているため、影響は限定的に抑えることができます。

連携データのみを利用するシステムであればバックアップを取得しないという選択も可能ですが、障害発生時にデータベースクラスタを再作成する手間を省略するために物理バックアップを取得することをお勧めします。

6‐3)xDB Control Database

xDB Control DatabaseにはPublication、Subscriptionの各情報はもちろん、データ連携の履歴やジョブスケジューリングの定義情報などxDB Replication Serverが動作するために必要な多くの情報が格納されています。xDB Control Databaseが障害により異常停止に陥いるとPublication ServerとSubscription Serverが起動できなくなり、xDB Replication Serverの動作が完全に停止してしまいます。データを消失した場合はxDB Replication Server環境を再構築するしか復旧手段がないため、影響は連携元だけでなく連携先のシステムも含め広範囲に及びます。

データ連携の履歴が随時更新されるため、基本は物理オンラインバックアップを取得します。データ連携が行われない時間帯を確保できる場合には物理オフラインバックアップの取得でもよいでしょう。

データベースのバックアップ

図16:データベースのバックアップ

メディア障害時のHow to


万が一、各データベースでメディア障害が発生した場合、どのような手順でレプリケーションが再開されるのでしょうか。

Publication Databaseで障害が発生した場合、取得済みの物理バックアップをリストアする前にデータ連携ジョブを削除しておきます。図17のように完全リカバリができる場合は障害発生直前のデータまで復旧できるため、リカバリ完了後にデータ連携ジョブを再設定するだけです。

一方、不完全リカバリしかできず、さらに連携対象データを消失している場合は、Subscription Databaseの対象テーブルからデータ復旧を試みます。xDB Replication Serverでは、PPEEをPublication Database、Oracle DatabaseをSubscription Databaseとした構成をとることができるため、一時的にマスタスレーブの役割を変更することで対処します。データ復旧後にマスタスレーブの役割を元に戻し、データ連携ジョブを再設定します。

Publication Database障害からのリカバリ

図17:Publication Database障害からのリカバリ

Subscription Databaseで障害が発生し、完全リカバリができる場合は、障害発生直前のデータまで復旧できますが、その間もPublication Databaseで更新処理が行われている可能性があるため、図18のように復旧後にSnapshot方式でPublicationのテーブルデータを再取得します。

Subscription Database障害からのリカバリ

図18:Subscription Database障害からのリカバリ

xDB Control Databaseで障害が発生した場合、レプリケーションが全面停止となり影響が広範囲に及びます。完全リカバリができる場合はリカバリ完了後にスケジュールに従ってデータ連携が再開されます。不完全リカバリしかできず、さらにxDB Replicationの関連テーブルデータ(※履歴テーブルを除く)を消失している場合は、図19にあるようにxDB Replication Serverモジュールの再導入を含みxDB Replication Server環境を最初から設定し直す必要があります。

制御DB障害からのリカバリ

図19:制御DB障害からのリカバリ

チューニングに関するHow to


xDB Replication Serverでは、図20にあるようにデータ連携方式ごとに一回にフェッチするデータ量を調整したり、複数テーブルのデータを同時に連携するためのスレッド数を変更するといった各種チューニングパラメータが提供されています。パラメータを単体または複数組み合わせることで最適なチューニングを実施することができます。

チューニングパラメータはPublication ServerおよびSubscription Serverの動作に関係するため、それぞれのConfiguration Fileへ値を設定し、プロセスを再起動することで反映されます。

データ連携のチューニングパラメータ部

図20:データ連携のチューニングパラメータ部

xDB Replication Serverでは前述のようにJDBC経由でデータ連携を行っており、JDBC バッチ更新と呼ばれる複数の更新SQL(DML)を1度に送って処理する機能を利用しています。今回は、弊社で実施した検証の中からsyncBatchSizeパラメータを調整した場合の効果を紹介します。syncBatchSizeパラメータはBatch更新時のSQLの数を制御しています。

検証では対象テーブルに格納された1,000万件のデータから500万件をランダムに更新し、その更新データをSynchronization方式でSubscription Databaseへ連携した場合、syncBatchSizeを100(デフォルト値)、1,000、5,000と増加させてデータ連携の所要時間がどのように変化するかを確認しました。図21のグラフにあるようにパラメータの値を大きくすることで1度に処理するSQLが増えるため、比例して所要時間が短縮されることが確認されています。

syncBatchSizeパラメータの効果

図21:syncBatchSizeパラメータの効果

xDB Replication Serverは2014年6月に5.1がリリースされたにも関わらず、2014年11月には早くも5.2がリリース予定となっており、エンタープライズ向けに必要な機能として積極的な開発が行われています。5.1では、更新情報を格納するためのトリガの性能向上や行レベルで連携対象範囲を絞ることができるなど、より柔軟な使いやすい機能が多数実装されています。その実力の詳細は次の機会をお楽しみに。

  • Postgres Plus は、EDB Postgres の旧製品名です。


高瀬 洋子(Youko Takase)

株式会社アシスト データベース技術本部

アシスト入社後、Oracle Databaseのサポート業務を経て、2009年よりPostgreSQL、EDB Postgresのサービス立ち上げに参画。「PostgreSQLなら高瀬に聞こう」と社内外から言ってもらえる存在となることを目標に日々活動。2014年4月よりイギリスに拠点を移し、PostgreSQL、EDB Postgresの啓蒙活動と顧客対応の後方支援を担当。

高瀬の紹介記事はこちら

関連製品/サービス


Facebookで情報をお届けしています

Facebookでは、アシストの「今」を週3回のペースでお届けしています。「めげない、逃げない、あまり儲けない」を合言葉に日々頑張っておりますので、応援よろしくお願いします。



ページの先頭へ戻る