SharePlex 11.4 - 管理者ガイド

SharePlexの準備されたルーチン

SharePlexには、カスタムルーチンと組み合わせて使用するための準備されたオプションのルーチンがあります。これらのオプションは、基本的で一般的なコンフリクト解決フォーマットで使用することができます。列のタイプに制限はありません。

データベースでプライマリキーと一意キーのサプリメンタルロギングを有効にする必要があります。

サポート対象のソースデータベースとターゲットデータベースの組み合わせ

• OracleからOracleへ

• PostgreSQLからPostgreSQLへ

• PostgreSQLからOracleへ

• PostgreSQL Database as a ServiceからPostgreSQL Database as a Serviceへ

• PostgreSQL Database as a ServiceからOracleへ

• PostgreSQL Database as a ServiceからPostgreSQLへ

考慮事項

SharePlexの準備されたルーチンを実施する前に、以下の考慮事項を確認してください。

!HostPriority

この準備されたコンフリクト解決ルーチンは、INSERT、UPDATE、およびDELETE操作で機能します。これは、信頼できるソースシステム上で発生した行の変更に優先順位を割り当てることで、ホストベースのコンフリクト解決を実行します。信頼できるソースを定義するには、SP_OPO_TRUSTED_SOURCE（Oracleソース）またはSP_OPX_TRUSTED_SOURCE（PostgreSQLソース）パラメーターをソースシステム名に設定します。

解決ロジック

コンフリクト解決ファイル内の構文

owner.table {I | U | D} !HostPriority

!LeastRecentRecord

この準備されたルーチンは、INSERT、UPDATE、DELETE操作で機能します。これは、タイムスタンプによって決まる最も古い行の変更に優先順位を割り当てることで、時間ベースでコンフリクトを解決します。

タイムスタンプを取得するために、このルーチンを使用するテーブルには、テーブルに対してINSERTとUPDATEを実行するたびに更新されるNULLではないタイムスタンプ列が必要です。DMLまたは既存の行のタイムスタンプ列がNULLの場合、このルーチンはコンフリクトを解決できません。

このルーチンでは、OracleのSP_OCT_REDUCED_KEYパラメーターとPostgreSQLのSP_CAP_REDUCED_KEYパラメーターをソースシステム上で0に設定し、UPDATESのすべてのプリイメージの値をPost処理で使用できるようにする必要があります。

解決ロジック

コンフリクト解決ファイル内の構文

owner.table {I | U | D} !LeastRecentRecord(col_name)

ここで、col_nameはルーチンが使用するタイムスタンプ列です。

!MostRecentRecord

この準備されたルーチンは、INSERT、UPDATE、DELETE操作で機能します。これは、タイムスタンプによって決まる最新の行の変更に優先順位を割り当てることで、時間ベースでコンフリクトを解決します。

タイムスタンプを取得するために、このルーチンを使用するテーブルには、テーブルに対してINSERTとUPDATEを実行するたびに更新されるNULLではないタイムスタンプ列が必要です。DMLまたは既存の行のタイムスタンプ列がNULLの場合、このルーチンはコンフリクトを解決できません。

このルーチンでは、OracleのSP_OCT_REDUCED_KEYパラメーターとPostgreSQLのSP_CAP_REDUCED_KEYパラメーターをソースシステム上で0に設定し、UPDATESのすべてのプリイメージの値をPost処理で使用できるようにする必要があります。

解決ロジック

コンフリクト解決ファイル内の構文

owner.table {I | U | D} !MostRecentRecord(col_name)

ここで、col_nameはルーチンが使用するタイムスタンプ列です。

!UpdateUsingKeyOnly

このルーチンはUPDATE操作に対して機能します。これは、変更された行のキー値のみに依存するコンフリクトを解決します。通常、SharePlexがデータをポストするSQLステートメントを構築する場合、WHERE句は、確実に同期させるために変更された列のキーとプリイメージの両方を使用します。!UpdateUsingKeyOnlyルーチンは、キーが一致することを前提に、プリイメージの値が一致しなくてもデータをポストするようSharePlexに指示します。

該当する場合は、このルーチンをUPDATEのための唯一のルーチンとして使用することもできます。ただし、複数のUPDATEが同時に行われる場合は、システム優先度や時間優先度などの優先度を割り当てるロジックが含まれないことに留意してください。同期外エラーを避けるため、Questでは、!UpdateUsingKeyOnlyをより具体的な他のルーチンと組み合わせて使用し、カスタムルーチンが失敗した場合の最終オプションとして!UpdateUsingKeyOnlyを使用することを推奨しています。

重要: !UpdateUsingKeyOnlyは、優先順位が最後になるようにルーチンのリストの最後のエントリにしなければなりません。

以下の例では、UPDATEの実行中にowner.table1でコンフリクトが発生すると、SharePlexが最初に（優先順位の高い順に）2つのカスタムルーチンを呼び出し、次に!UpdateUsingKeyOnlyルーチンを呼び出します。

!UpdateUsingKeyOnly名では大文字と小文字を区別します。単語と単語の間にはスペースを入れず、この手順にあるとおりに正確に入力する必要があります。設定ファイルにはこのルーチンの所有者名を記載しないでください。INSERTおよびDELETE操作には、カスタムロジックを使用する必要があります。

Oracleデータベースの解決済みコンフリクトに関する情報のロギング

SharePlexの準備されたルーチンを使用している場合、成功したコンフリクトの解決操作に関する情報をログに記録するようにPostプロセスを設定することができます。この機能は、デフォルトでは無効になっています。

コンフリクト解決のロギングを有効にするには:

1. sp_ctrlをターゲットシステム上で実行します。

2. 次のコマンドを入力します。

   sp_ctrl> set param SP_OPO_LOG_CONFLICT {1 | 2}

   • 1に設定すると、SHAREPLEX_CONF_LOGテーブルへのコンフリクト解決のロギングが有効になります。

     注意: 1に設定すると、SHAREPLEX_CONF_LOGテーブルのEXISTING_TIMESTAMPおよびTARGET_ROWID列（既存のデータが置換されない場合）は更新されません。

   • 2に設定すると、SHAREPLEX_CONF_LOGテーブルへのコンフリクト解決のロギングが、Postによる追加のメタデータのクエリと共に有効になります。

     準備されたルーチンLeastRecentRecordまたはMostRecentRecordを使用すると、Postは既存のレコードのタイムスタンプ列のターゲットデータベースにクエリを実行します。クエリの結果は、SHAREPLEX_CONF_LOGテーブルのEXISTING_TIMESTAMP列にログ記録されます。

     準備されたルーチンでは、入力されたレコードで置換されなかった行に対し、Postは置換される可能性のある既存の行のTARGET_ROWIDを問い合わせます。そうでない場合、既存の行のROWIDは記録されません。

     注: 2と設定すると、クエリを実行した結果、Postのパフォーマンスに影響を与える可能性があります。

3. Postを再開します。

Postは、SHAREPLEX_CONF_LOGという名前のテーブルに情報を記録します。このテーブルについて以下に説明します。

PostgreSQLデータベースの解決済みコンフリクトに関する情報のロギング

SharePlexの準備されたルーチンを使用している場合、成功したコンフリクトの解決操作に関する情報をログに記録するようにPostプロセスを設定することができます。この機能は、デフォルトでは無効になっています。

コンフリクト解決のロギングを有効にするには:

1. sp_ctrlをターゲットシステム上で実行します。

2. 次のコマンドを入力します。

   sp_ctrl> set param SP_OPX_LOG_CONFLICT {1 | 2}

   • 1に設定すると、shareplex_conf_logテーブルへのコンフリクト解決のロギングが有効になります。

     注: 1に設定すると、shareplex_conf_logテーブルの列existing_timestamp（既存のデータが置換されない場合）は更新されません。

   • 2に設定すると、shareplex_conf_logテーブルへのコンフリクト解決のロギングが、Postによる追加のメタデータのクエリと共に有効になります。

     準備されたルーチンLeastRecentRecordまたはMostRecentRecordを使用すると、Postは既存のレコードのタイムスタンプ列のターゲットデータベースにクエリを実行します。クエリの結果は、shareplex_conf_logテーブルのexisting_timestamp列にログ記録されます。

     注: 2と設定すると、クエリを実行した結果、Postのパフォーマンスに影響を与える可能性があります。

3. Postを再開します。

Postは、shareplex_conf_logという名前のテーブルに情報を記録します。このテーブルについて以下に説明します。

中間システムを介したレプリケーションの設定

この説明では、カスケードレプリケーション （多層レプリケーションとも呼ばれます）を設定する方法を示します。この戦略では、ソースシステムから中間システムにデータをレプリケートし、次に中間システムから1つまたは複数のリモート・ターゲット・システムにデータをレプリケートします。

カスケードレプリケーションは、さまざまなレプリケーションの目的をサポートするために、以下のような状況の回避策として使用できます。

• レプリケーション戦略で、特定のソースシステムからの直接のルートが許可される1024ルートを超える場合、データを中間システムに送信し、そこから追加ターゲットにブロードキャストすることができます。
• ソースが、ファイアウォールの制限などにより、最終的なターゲットに直接接続されていない場合、ソースシステムからのリモート接続を許可しているシステムにカスケードすることができます。

カスケード戦略を使用するには、直接接続を行う機能は必要ありませんが、ソースマシンが最終的なターゲットマシン名を解決できる必要があります。

サポート対象のソース

OracleおよびPostgreSQL

サポート対象

Oracle

OracleおよびOpen Target（最終ターゲット）

機能

このレプリケーション戦略では以下をサポートします。

• 1つまたは複数のターゲットシステムへのレプリケーション
• 同一または異なるソース名とターゲット名
• 垂直分割レプリケーションの使用
• 水平分割レプリケーションの使用
• 名前付きexportキューおよびpostキューの使用

要件

• 『SharePlexインストールガイド』の説明に従ってシステムを準備し、SharePlexをインストールして、データベースアカウントを設定します。

  重要!SharePlexを使用して中間システム上のデータベースにポストする場合は、すべてのシステムで同じSharePlexユーザを作成します。

• ターゲットオブジェクトに対してDMLを実行するトリガを無効にします。

• SharePlexを除き、ターゲットテーブルに対してDMLやDDLを実行しないでください。レプリケーション設定の外にあるターゲットシステム上のテーブルでは、レプリケーションに影響を与えることなくDMLおよびDDL操作を行うことができます。

• ターゲットシステムでシーケンスが不要な場合は、レプリケートしないでください。レプリケーションが遅くなる可能性があります。ソーステーブルのキー生成にシーケンスが使用されている場合でも、レプリケートされた行がターゲットシステムに挿入されると、シーケンス値がキー列の一部になります。シーケンス自体をレプリケートする必要はありません。

DDLレプリケーションのサポート

中間システムを介したソースからターゲットへのDDLレプリケーションは、『管理ガイド』の「SharePlexがサポートするDDL」の章に記載されている情報に従ってサポートされます。ただし、次の例外があります。

• ソースではなく、中間システムでDDLを開始すると、ポストエラーにつながる不整合を引き起こすため、DDLがすべてのシステムで同期されていない限り避ける必要があります。
• すべてのシステムは、中間システムでの遅延やエラーが不整合の原因とならないように監視する必要があります。

重要! これらの説明は、SharePlex設定ファイルを完全に理解していることを前提としています。重要な構文要素の省略表現が使用されています。詳細については、データをレプリケートするためのSharePlexの設定を参照してください。

構文で使用される規則

このトピックの設定構文では、プレースホルダは以下を表しています。

• source_specification[n]は、ソースオブジェクトの完全修飾名（owner.object）、またはワイルドカード指定です。
• target_specification[n]は、ターゲットオブジェクトの完全修飾名、またはワイルドカード指定です。
• hostは、SharePlexが実行されるシステムの名前です。異なるシステムは、hostBのように名前に文字を付加することで識別します。
• dbはデータベース指定です。データベース指定は、o. 、またはr. が、接続タイプに応じて、Oracle SID、TNSエイリアス、またはデータベース名の前に付加されて構成されます。ターゲットがJMS、Kafka、またはファイルの場合は、データベース識別子は必要ありません。

重要! データをレプリケートするためのSharePlexの設定ページを参照してください。

導入オプション

データをカスケードするには、以下のオプションがあります。

• 中間システムにデータベースがある場合、そのデータベースにポストし、データをもう一度キャプチャして1つ以上のリモートターゲットにレプリケートするようにSharePlexを設定できます。

• 中間システムにデータベースがない場合、データをインポートし、キューに入れてから、1つ以上のリモートターゲットにエクスポートするようにSharePlexを設定できます。システム上にCaptureプロセスはありません。これはパススルー設定として知られています。ソースシステムからターゲットシステムに直接データを渡します。

中間システムへのポストによるカスケード

この設定を使用するには:

• SharePlexデータベースアカウントがすべてのシステムに存在し、すべてのシステムで同じ名前である必要があります。このアカウントは通常、SharePlexのインストール時に作成されます。詳細については、『SharePlexインストールガイド』を参照してください。
• 中間データベースとターゲットシステムでトリガを無効にしておく必要があります。

• Oracle DDLレプリケーションは、中間システム上のOracleデータベースからターゲットシステムへのレプリケーションには対応していません。ソースシステムから中間システムへのレプリケーションのみサポートされます。

• ソースシステムに1つ、中間システムに1つ、合計2つの設定ファイルを作成します。

• Captureが完了する前にREDOログがラップする場合に備えて、ソースシステムと中間システムでアーカイブロギングを有効にします。

ソースシステム上の設定オプション

この設定では、ソースシステムから中間システム上のデータベースにレプリケートします。

注意: このテンプレートでは、hostBが中間システムです。

ソースシステムでの例

注意: この同じ設定で、他のソースオブジェクトからのデータを、中間システムを介してカスケードせずに他のターゲットに直接ルーティングすることができます。別の行で適切なルーティングを指定するだけです。

中間システムでの設定オプション

この設定では、中間システム上のデータベースからデータをキャプチャし、そのデータをターゲットシステムにレプリケートします。ソース設定ではターゲットテーブルであったテーブルが、この設定ではソーステーブルになります。ターゲットは、サポートされているどのSharePlexターゲットでも可能です。

中間システムの例

注意: この例の最後の項目は、水平分割レプリケーションを使用して、sales.accountsテーブルのさまざまなデータをさまざまな地域データベースに配布する方法を示しています。詳細については、水平分割レプリケーションの設定を参照してください。を参照してください。

中間システムで必要なパラメータ設定

（Oracle中間データベース）中間データベースがOracleの場合、 SP_OCT_REPLICATE_POSTERパラメータを1に設定します。これにより、中間システム上のCaptureプロセスに、SharePlexによってポストされた変更をキャプチャし、ターゲットシステムにレプリケートするように指示します。（デフォルトは0であり、Captureが同じシステム上のPostアクティビティを無視することを意味します。）

sp_ctrlで、以下のコマンドを発行します。この変更は、次にCaptureを開始したときに有効になります。

set param SP_OCT_REPLICATE_POSTER 1

中間システムでのパススルーによるカスケード

この設定を使用するには:

• oratabファイルに、OracleインスタンスとORACLE_SID指定を作成します（UnixおよびLinuxシステム）。データベースは空でも構いません。

• DDLレプリケーションはサポートされていません。

• ソースシステム上に1つの設定ファイルを作成します。

ソースシステム上の設定オプション

注意: このテンプレートでは、hostBが中間システムです。

• hostB*host構文は、パススルー動作を設定します。
• すべてのデータが最初に中間システムを通過する複合ルーティングマップを使用する場合、各ターゲットルートでhostB*コンポーネントを必ず使用してください。
• この設定ファイルの3行目にあるように、ソースオブジェクトからのデータをあるターゲットに直接レプリケートし、さらに中間システムを経由して別のターゲットにレプリケートする複合ルーティングマップを使うこともできます。

例

高可用性を維持するためのレプリケーションの設定

この説明では、高可用性の目的でSharePlexをセットアップし、ソースデータベースのミラーであるセカンダリOracleデータベースにレプリケートする方法を示します。この戦略では、互いに逆向きの2つのSharePlex設定による双方向のレプリケーションを使用します。セカンダリ（スタンバイ）マシンの設定は、プライマリマシンに障害が発生した場合のフェールオーバーに備えて、そのシステムのExportプロセスを停止したままアクティブな状態を維持します。

注意: CrunchyData高可用性クラスタ環境のセットアップ情報については、『SharePlexインストールおよびセットアップガイド』の「PostgreSQL高可用性クラスタへのSharePlexのインストール」セクションを参照してください。

この戦略は、以下のようなビジネス要件をサポートします。

• ディザスタリカバリ
• メンテナンスサイクルや機械的な故障が発生した場合の、ビジネスアプリケーションの継続的な稼働

この戦略では、SharePlexは次のように動作します。

• 通常の状態では、SharePlexはプライマリデータベースからセカンダリデータベースに変更をレプリケートします。
• プライマリシステムまたはデータベースがオフラインになり、ユーザがセカンダリシステムに移されると、SharePlexはその変更をキャプチャし、プライマリシステムがリストアされるまで、そのシステムのデータをキューに入れます。
• プライマリシステムがリストアされると、SharePlexはこれらの変更でプライマリシステムを更新し、プライマリデータベースからのキャプチャとレプリケーションを再開します。

サポート対象のソース

OracleおよびPostgreSQL

サポート対象

Oracle

機能

このレプリケーション戦略は、名前付きexportキューとpostキューの使用をサポートします。

注意: 列のマッピングと分割レプリケーションは、高可用性設定では適切ではありません。ソースとターゲットのオブジェクトは異なる名前を持つことができますが、これは高可用性構造の管理をより複雑にします。

要件

• 『SharePlexインストールガイド』の説明に従ってシステムを準備し、SharePlexをインストールして、データベースアカウントを設定します。
• すべてのオブジェクトは、両方のシステム上に完全に存在する必要があります。
• ターゲットオブジェクトは、ソースオブジェクトと同じ構造と修飾名を持っている必要があります。

• すべてのシステムでアーカイブロギングを有効にします。

• SharePlexを除くすべてのユーザに対して、INSERT、UPDATE、DELETE操作を拒否するスクリプトを作成します。

フェールオーバーの目的では、以下が必要です。

• プライマリシステムで使用しているアプリケーションをセカンダリシステムでも利用できるようにします。
• レプリケートされないデータベースオブジェクトとインスタンスの外部にある重要なファイルをセカンダリシステムにコピーします。
• すべてのユーザに対してINSERT、UPDATE、およびDELETE権限を付与するスクリプトを作成します。これはフェールオーバー手順中に実行できます。
• フェールオーバー手順中にセカンダリシステムで制約を使用できるようにするスクリプトを作成します。
• ユーザをセカンダリシステムに移すためのフェールオーバー手順を開発します。

注意: Oracleのホットバックアップを使用してセカンダリインスタンスを作成する場合は、スクリプトを保存しておいてください。これを修正することで、プライマリインスタンスを再作成することができます。

構文で使用される規則

このトピックの設定構文では、プレースホルダは以下を表しています。

• hostAはプライマリシステムです。

• hostBはセカンダリシステムです。
• ownerA.objectは、hostA上のオブジェクトの完全修飾名、またはワイルドカード指定です。
• ownerB.objectは、hostB上のオブジェクトの完全修飾名、またはワイルドカード指定です。
• oraAはhostA上のOracleインスタンスです。
• oraBはhostB上のOracleインスタンスです。

重要! 設定ファイルのコンポーネントの詳細については、「データをレプリケートするためのSharePlexの設定」を参照してください。

設定

高可用性設定は、互いに逆向きの2つの設定を使用します。データベース内の全オブジェクトをレプリケートする場合、config.sqlスクリプトを使用すると、設定プロセスを簡素化できます。詳細については、『SharePlexリファレンスガイド』の「設定スクリプト」セクションを参照してください。

ソースシステム（プライマリシステム）上の設定

ターゲットシステム（セカンダリシステム）上の設定

システムのフェールオーバー対応準備

1. セカンダリシステム（最初にパッシブシステムとなるシステム）でsp_ctrlを実行し、次のコマンドを発行してセカンダリシステムのExportプロセスを停止します。これにより、セカンダリシステムで誤って発生したこと（スケジュールされたジョブによるデータの変更など）がプライマリシステムにレプリケートされないようにします。システム間で役割の切り替えが必要になるまで、そのシステム上のSharePlexをこの状態にしておく必要があります。
2. 初期同期とスタートアップを実行します。この手順中にソース設定をアクティベーションします。詳細については、本番システムでのレプリケーションの開始を参照してください。
3. セカンダリシステムでExportプロセスが停止していることを確認し、そのシステムで設定をアクティベーションします。セカンダリマシンの設定はアクティベーションされますが、Exportプロセスが停止しており、ユーザアクティビティがないため、システムはフェールオーバーに備えた状態で静止しています。
4. セカンダリOracleインスタンスにリンクされているSharePlexインスタンスを監視して、SharePlex以外のDDLまたはDMLの変更が実行されていないことを確認します。これは次のように実行できます。sp_ctrlのqstatusコマンドを使用して、セカンダリシステム上のexportキューのステータスを表示します。キューは空のはずです。システム上のCaptureプロセスは、そのシステムのPostプロセスを無視するからです。exportキューにメッセージがある場合、トランザクションがセカンダリシステムで発生したか、SP_OCT_REPLICATE_POSTERパラメータが誤って有効になったことを意味します。SharePlexのコマンドとパラメータの詳細については、『SharePlexリファレンスガイド』を参照してください。
5. レプリケーションファイルのバックアップを維持します。

リカバリ手順の実行

高可用性環境でシステムに障害が発生した場合、レプリケーションをセカンダリシステムに移動し、リストア後にプライマリシステムに戻すことができます。詳細については、Oracleのフェイルオーバー後のレプリケーションのリカバリ を参照してください。