SharePlex 11.4 - リファレンス・ガイド

PostgreSQLの設定のパージ

purge configコマンドを使用して、キューそのものを削除したり設定を非アクティベーションにしたりすることなく、設定に関連付けられたすべてのキューからデータを削除します。非アクティベーションを回避することで、SharePlexでは 、設定データを再計算する必要がなくなります。これにより、テーブルが大きく数が多い場合に、時間を節約し、レプリケーションをより早く開始できるようになります。

ソースシステムでpurge configコマンドを発行して、設定されたルートにあるソースシステムとすべてのターゲットシステムに影響を与えます。purge configアクティビティの実行前または実行中にSharePlexプロセスが停止すると、このコマンドも動作を停止します。プロセスが再開されると、コマンドは動作を再開します。したがって、purge configは、ネットワークが一時的に利用できなくなった場合でも機能し、接続が復元されるまでコマンドはキューに残ります。

purge configコマンド使用上の注意点:

設定をアクティブにしてから、activate configコマンドの後に、purge configコマンドを実行しないでください。レプリケーションを制御する設定情報など、キューに入れられたデータ以上のものをパージし、アクティベーションが無効になる可能性があります。

用途

構文

構文の説明

PostgreSQLの照合

reconcileコマンドをプロシージャの一部として使用して、データベースユーザの中断を最小限に抑えると共に、ソースデータとターゲットデータを同期（インスタンス化）します。reconcileコマンドは、進行中のレプリケーションの結果を、ホットバックアップやネイティブ・コピー・ユーティリティなどによってターゲットシステムに適用されたソースデータのコピーと照合します。照合機能は、postキュー内のレプリケートされた変更を、リカバリプロセス後のターゲットデータベースの状態とcompareします。リカバリ中に適用されたトランザクションと、まだ適用されていない（postキューで待機している）トランザクションを区別し、両システムが同期するように、重複していない変更のみをポストします。

reconcileコマンドは、大容量環境で使用するように設計されていますが、状況によっては照合プロセスが停滞する可能性があることを理解すれば、小容量環境でも使用することができます。この状況は、ソースシステムから継続して届くデータにreconcileコマンドが依存しているために生じます。ホットバックアップまたはコピーの実施以降、ソースシステムにレプリケーションアクティビティがない場合、照合プロセスはソースのアクティビティが再開するまで待機します。

reconcileコマンド使用時の注意点

reconcileコマンドは、ソースデータとターゲットデータの初期同期を特定の手順で行う場合に使用します。したがって、これは独立したコマンドではありません。初期同期手順については、『SharePlex管理ガイド』を参照してください。

用途

構文

構文の説明

PostgreSQLの設定名の変更

設定ファイルに別の名前を付けるには、rename configコマンドを使用します。システム上の設定ファイル間で固有の名前を使用します。

用途

構文

構文の説明

PostgreSQLのrepair/repair using

repairおよびrepair usingコマンド（repairコマンドと総称される）を使用して、ターゲットテーブル内の同期していない行をrepairします。

• repairコマンドは、ワイルドカードを使用して指定されたスキーマ内の個々のターゲットテーブルまたは任意の数のターゲットテーブルをrepairします。個々のテーブルをrepairする場合は、列ベースのフィルタリングを使用して、repair用に選択される行を制御することができます。
• repair usingコマンドは、アクティブ設定またはアクティブ設定内のテーブルのサブセットを含む別のファイルにリストされたターゲットテーブルをすべてrepairします。

repairコマンドは、まずcompareを実行してrepairが必要な行を特定してからrepairを実行します。テーブルがどのようにcompareされるかについては、compare / compare usingを参照してください。

注意: 実行中のcompareまたはrepairは、ソーステーブルには一切影響を与えません。SharePlexは、読み取りの一貫性についてのクエリを実行するためだけにデータベースにログインし、ソーステーブルのロックは短時間です。SharePlexは、処理中にターゲットテーブルを短時間ロックしますが、ユーザはロックをほとんど意識することなくアクセスを継続できます。ターゲットテーブル（またはしきい値より小さい場合は非同期行）は、非同期行を修正するためにrepairプロセスにロックされます。

サポートされている操作

SharePlexは、DML操作（INSERT、UPDATE、DELETE）によって発生した、ターゲットテーブル内の非同期行を検出し、repairすることができます。

サポートなし

SharePlexは、以下のcompareとrepairをサポートせずにスキップします。

• シーケンス。
• トランスフォーメーションが使用されたテーブル
• ソースサーバとターゲットサーバ間のデータ受け渡しにパススルーサーバを使用するネットワーク構成
• カスケードレプリケーション環境では、compareとrepairはサポートされません。

• compareまたはrepair中のテーブルに対してDDLを実行しないでください。compareは、SharePlexがサポートするものも含め、DDL操作によって引き起こされる非同期状態を検出しません。DDLがテーブル定義を変更すると、compareする必要がある行を取得するためにcompareプロセスにより作成されたSELECTステートメントが無効になります。

  DDLによって発生した非同期状態を修正したら、repairコマンドを使用して行のデータを再同期することができます。

• 255文字を超えるcompareおよびrepairコマンド文字列はサポートされていません。これはオペレーティングシステムの制限です。この制限を回避するには、ソースシステムでeditコマンドを使用します。テキストファイル内にコマンド文字列を入力すると、コマンドが自動的にファイルを実行します。

compareおよびcompare usingでサポートされるデータ型の詳細については、『SharePlexリリースノート』を参照してください。

その他の条件

• compareまたはrepairするテーブルは、アクティブな設定ファイルの一部でなければなりません。
• ソーステーブル上にコミットされていないトランザクションがあると、読み取りの一貫性を得るためにcompareおよびrepair処理に必要な短時間のロックを取得できなくなります。compareやrepairを実行する前に、すべてのトランザクションがコミットされていることを確認してください。

• レプリケーションのレイテンシは、compareやrepairの処理のパフォーマンスを低下させる可能性があります。ターゲット上でcompareおよびrepairプロセスを生成するためにソースから送信されたメッセージは、複製されたデータと共にキューを通じて送信されます。データバックログによる遅延が生じると、生成メッセージの送信が遅れることにより、プロセスが読み取りの一貫性を失うことがあります。可能であれば、compareやrepairはピーク以外の時間帯に行います。

• compareまたはrepair中のテーブルをトランケートしないでください。compareコマンドは、開始時に各ソーステーブルのスナップショットを取ります。テーブルがトランケートされると、スナップショットのテーブルビューもトランケートされ、コマンドが無効な非同期状態を返すことがあります。

• ビューをrepairするには、以下が真でなければなりません。

  • ビューテーブルが、基礎となるテーブルのすべての制約列を含んでいること。
  • ビューの制約列の名前が、基礎となるテーブルの制約列の名前と同一であること。

• Compareプロセスのパフォーマンスを向上させるために、SharePlexはSP_DEQ_PARALLELISMパラメーターによる並列ヒントをサポートしています。このため、並列度、つまり起動するワーカープロセスの数を指定できます。

  デフォルトでは、PostgreSQLデータベースオプティマイザはSQLステートメントに最適な問い合わせ実行計画を選択します。これは、並列ヒントで指定した並列度に直接関連していないこともあります。pg_hint_planにより、クエリを実行するたびに配列ヒントを使用して実行計画を調整することができます。SharePlexは、データベースにpg_hint_plan拡張機能がインストールまたは設定されている場合、内部でこれを利用します。

  並列クエリを使用するための構文の例は以下の通りです。

  pg_hint_plan拡張機能は並列ヒントをサポートしています。Parallel(table <# of workers> [soft|hard])

  SharePlexはハードパースをサポートする並列ヒントを使用します。Parallel(table <# of workers> [hard])

  注意: ワーカーの数は、データベースシステムのCPU VCoreより少なくなければなりません。

repairコマンドの使用方法

compareおよびrepairコマンドによって同期されたデータを維持するための推奨手順は、まずcompareまたはcompare usingコマンドを実行し、次にrepair statusコマンドで結果を表示することです。このコマンドは、非同期行とその考えられる原因を表示します。非同期状態の原因が修正されない限り、今回行をrepairしても、レプリケーションは再び非同期になります。問題が解決した後、repairまたはrepair usingコマンドを実行します。

repairまたはrepair usingコマンドは、予めcompareを行うことなく実行できます。このコマンドはまずcompareを行い、同期していない行を特定し、その行をrepairします。しかし、将来的な非同期状態を防ぐには、非同期状態の根本的な原因を解決しなければなりません。

非同期状態の原因と解決策については、『SharePlex管理ガイド』を参照してください。

repairを実行するタイミング

ターゲットテーブルをrepairする最適なタイミングは、テーブルのサイズ、問題の原因、非同期行の範囲、ユーザをロックアウトできる時間の長さによって異なります。repairを開始する前に、以下を考慮してください。

• 通常、テーブルのユーザは、テーブルのcompare時に適用される短時間のロックの影響は受けませんが、repair処理中はターゲットテーブルからロックアウトされます。小さなテーブルであれば支障はないかもしれませんが、大規模なrepairが必要な大きなテーブルの場合、待ち時間が非常に長くなることがあります。
• ターゲットテーブルのロックは、Postがrepairの終了を待ってから、そのテーブルに変更を適用し、他のテーブルに移動しなければならない場合、ポストのパフォーマンスを低下させる可能性があります。これがターゲットデータのレイテンシを増加させ、postキューに操作が蓄積される原因となります。Postが変更する必要があるオブジェクトと、repair中のオブジェクトが異なる場合、2つのプロセスは同時に実行されます。

• テーブルをすぐにrepairしなければならないが、ロックやレプリケーションのレイテンシを許容できない場合、whereオプションを使用して、特定の行に限定してrepairすることができます。別の方法としてkeyオプションを使用することもできますが、このオプションを使用すると、非同期行を見逃してしまう可能性があります。

• repairを待つことができる場合は、問題の原因をすぐに修正し、ピーク時以外の時間帯にrepairを行います。

特別な使用例

以下のシナリオでは、compareを実行する際に特別な処理が必要となります。

repairの仕組み

repair操作では、以下のようにDML操作によって発生した、ターゲットテーブルの非同期状態をrepairします。

• 余分な行または欠けている行
• 値が一致しない行

repairの条件

repairおよびrepair usingコマンドは 、以下の修正SQLステートメントを発行します。

• ソース側に行が存在し、ターゲット側に行が存在しない場合、SharePlexはINSERTステートメントを発行します。
• ターゲット側に行が存在し、ソース側に存在しない場合、SharePlexはDELETEステートメントを発行します。
• ターゲット行がソース行と異なり、キー列が一致する場合、SharePlexはソース値に基づいてUPDATEステートメントを発行します。

プロセス

repairには常に、ターゲットテーブル内の非同期状態を特定するためのcompareが含まれます。repairまたはrepair usingコマンドを実行すると、SharePlexは以下の一連のイベントを開始します。

1. sp_copプロセスは、ソースシステム上にsp_xdesvr （サーバ）プロセスを生成します。
2. sp_xdesvrプロセスは、sp_ctrlインターフェイスの制御と使用をユーザに返します。compareが進行している間、レプリケーションは続行されます。
3. sp_xdesvrプロセスは、ターゲットシステム上でsp_xdeclt （クライアント）プロセスを開始するために、Postプロセスにメッセージを送信します。
4. サーバプロセスとクライアントプロセスによって相互の通信が確立されます。

5. 行の選択とrepairは次のように進行します。

   • repairコマンドを使用している場合、sp_xdesvrはソーステーブルから行を選択し、sp_decltはターゲットテーブルから行を選択します。行はソートされ、compareされてrepairされます。
   • repair usingコマンドを使用している場合、sp_xdesvrプロセスはターゲットシステム上に多数の処理スレッドを作成します。SP_DEQ_THREADSパラメーターによって設定される値は、作成されるスレッド数を制御します。各スレッドはsp_xdeclt（クライアント）プロセスを生成します。サーバプロセスとクライアントプロセスによって相互の通信が確立されます。処理負荷はクライアントプロセス間で分割されます。ソースとターゲットの各テーブルから行が選択され、ソートされ、compareされてrepairされます。ターゲットテーブルは、repairの順番になるとロックされ、その後ロックが解除されます。

   • ターゲットテーブルは、repairの順番になるとロックされ、その後ロックが解除されます。

6. 終了すると、プロセスによってログファイルが書き出され、show repairコマンドで結果を見ることができます。

エラー処理

SharePlexは 、repair SQLステートメントの適用時にデータベースエラーが発生すると、そのステートメントから先のrepairを停止し、直前に適用された有効なステートメントのみをコミットします。このように、テーブルは部分的にrepairされますが、まだ同期していない可能性があります。repair statusコマンドは、この状況を警告します。

SQLログファイルの管理

compareおよびrepairコマンドは、すべての非同期行をrepairするために必要なSQLを、ログファイルと同じ場所にあるSQLファイルに書き込みます。compareコマンドのみが発行された場合、SharePlexはこれらのSQLステートメントを実行しません。repairコマンドを実行した場合、このコマンドは、非同期行をrepairするSQLステートメントを実行すること以外はcompareコマンドと同じように動作します。

SQLログファイルの出力を抑制することができます。このファイルを抑制する理由には以下のようなものがあります。

• データには機密情報が含まれています。SQLログファイルはクリアテキストで書き込まれます。SQLログファイルを生成しないことで、機密データはディスクに保存されず、PCIコンプライアンス基準を満たすために要求されるような保存データのセキュリティ要件を満たすことができます。
• compareまたはrepairされたテーブルには、非常に多くの非同期行があります。このサイズのログファイルは、大量のディスクスペースを消費する可能性があります。

SQLログファイルを抑制するには、nosqllogオプションをcompareまたはrepairコマンドで使用します。

SharePlexの現在のインスタンスの実行中に、compareとrepairのすべての実行についてSQLログファイルの出力を抑制するには、SP_SYS_SECURE_MODE環境変数を1に設定します。この変数はSharePlexを起動する前に設定する必要があるため、sp_copプロセスが実行されている場合は、この変数を設定した後に再起動する必要があります。この環境変数を指定してsp_copを実行すると、compareコマンドとrepairコマンドによってSQLファイルにデータは保存されず、Post処理でもSharePlexのエラーログにデータは保存されません。

複数のプロセスの実行

すべてのcompareおよびrepairコマンドでは、複数のプロセスを同時に実行することができます。

• 複数のcompareおよびrepairコマンドを同時に実行し、それぞれがソーステーブルとターゲットテーブルのペアを処理することも、PostgreSQLのワイルドカードを使用して1つのコマンドで複数のテーブルセットを指定することもできます。SharePlexによるワイルドカードのサポートの詳細については、『SharePlex管理ガイド』を参照してください。
• compare usingとrepair usingコマンドはファイル全体で機能します。例えば、設定ファイル全体のテーブルをcompareまたはrepairすることも、ターゲットテーブルのサブセットに影響を与える1つ以上のcompare filesまたはrepair filesを作成し、そのうちの1つまたは複数を同時に実行することもできます。手順については、コマンドの構文を参照してください。

レプリケーションプロセスとcompareおよびrepairプロセスなど、最大で20のSharePlexプロセスでpostキューを同時に使用することができます。一度に最大で5つのcompareおよびrepairプロセスを実行できるようにすることをお勧めします。compare usingおよびrepair usingコマンドを使用すると、compareするプロセスあたりのテーブル数を増やすことで20回のプロセス制限を回避できます。

制限に達したためにcompareやrepairに失敗した場合、SharePlexはイベントログにメッセージを記録します。

注意: editコマンドを使用し、以前のコマンドを編集して新しいコマンドを作成すれば、複数のコマンドをより簡単に実行できます。

設定のサブセットのrepair

アクティブな設定のサブセットは、以下の方法でrepairできます。

• 1つのスキーマに属するレプリケーション内の全ターゲットテーブルをrepairするには、以下のようにrepairコマンドにワイルドカードを指定します。

  sp_ctrl> repair scott.%

• 設定ファイル内のすべてのターゲットテーブルをrepairするには、以下のようにrepair usingコマンドを使用します。

  sp_ctrl>repair using myconfig

• 1つのターゲットルート内のすべてのターゲットテーブルをrepairするには、以下のようにatオプションを指定して、repair usingコマンドを使用します。

  sp_ctrl> repair using config.active at prodsys@r.dbid

• 設定内のテーブルのカスタムサブセットをrepairするには、repairファイルから指定します。これはプレーン・テキスト・ファイルであり、repairしたいターゲットのソーステーブルのみをリストします。ターゲットテーブルは、コマンドが発行された時点の設定ファイルから取得されます。create configまたはcopy configコマンドを使用してrepairファイルを作成できます。このファイルには、必ず設定ファイルでないことを明確に示す名前を付けてください。詳細については、コマンドの構文を参照してください。

どの行をrepairするかを制御

compareおよびrepairコマンドには、処理の対象として選択する行をフィルタリングできるwhereオプションがあります。デフォルトでは、これらのコマンドはテーブルのすべての行に影響し、ソーステーブルに含まれていないターゲットテーブルの列は無視されます。

• whereオプションを使用すると、ソーステーブルとターゲットテーブルの同じ名前の列に基づいて行をフィルタリングすることができます。

• 垂直分割レプリケーションを使用するテーブルにはwhereオプションを使用します。ソース列とターゲット列には異なる名前を付けることができます。whereの選択をソース列に基づいて行います。SharePlexは、ターゲットテーブルの正しいWHERE句を構築するために、設定ファイルから列マッピングを読み取ります。

• ソーステーブルまたはターゲットテーブルに1つ以上の余分な列が存在し、それらの行に行の一意性を決定する値が含まれている場合は、sourcewhereおよびtargetwhereオプションを使用します。

  • ソーステーブルに余分な列が含まれている場合は、sourcewhereを使用します。
  • ターゲットテーブルに余分な列が含まれている場合は、targetwhereを使用します。

  このオプションを正しく使用するには:

  • 余分な列にはsourcewhereまたはtargetwhereオプションのみを使用します。

  • ソースとターゲットの両方で同じ名前を持つ他の列には、標準のwhereオプションを使用します。

  • SharePlexは、whereオプションとsourcewhereまたはtargetwhereオプションを組み合わせて、完全なWHERE句を作成します。

  重要! 余分な行を持つターゲットテーブルに対してcompareとrepairの両方を実行する予定がある場合は、UPDATEとDELETEのcompare用にtargetwhereのみを使用してください。repairコマンドはINSERTの正しい値を決定できません。この問題を回避するには、余分な列にデフォルト値を設定するか、挿入された行を手動で更新します。

プロセスの特定

compareまたはrepairコマンドが発行されるたびに、ジョブIDがsp_ctrlディスプレイに表示されます。sp_ctrlディスプレイを利用できない場合は、compare statusコマンドを実行することでジョブIDを表示できます。

sp_ctrlでステータスと結果を表示

repairのステータスや結果を表示するには、sp_ctrlのrepair statusコマンドを使用します。

• 基本コマンドは、最近開始されたrepairジョブの処理ステータスと、まだ終了していないその他のジョブを表示します。
• 追加オプションを使用すると、履歴のあるすべての修理ジョブのサマリーステータスを表示したり、1つのジョブに関する詳細情報を表示したりすることができます。

詳細については、repair statusを参照してください。

警告とエラーの表示

sp_xdesvrおよびsp_xdecltプロセスは、実行するシステム上にログファイルを書き込みます。SharePlexの変数データディレクトリのlogサブディレクトリにあるファイルを開きます。

sp_xdesvrプロセスが書き込むログの名前はxdesvr_<jobid>_r.<dbid>_p<process id>.logです。ここで、

• JobIDは、SharePlexによって割り当てられたジョブIDです。
• DBIDはPostgreSQLインスタンスのデータベースIDです。
• ProcessIDはsp_xdesvrプロセスのプロセスIDです。

sp_xdecltプロセスが書き込むファイル名は、xdeclt_<jobid>-<tableid>_r.<dbid>_p<processid>.logに.logまたは.sqlを付加したものです。ここで、

• JobIDは、SharePlexによって割り当てられたジョブのジョブIDです。
• TableIDは、SharePlexによって割り当てられたジョブ内のテーブルのテーブルIDです。
• DBIDはPostgreSQLインスタンスのデータベースIDです。
• SourceHostは、ソースホストの名前またはIPアドレスです。
• ProcessIDはsp_xdecltプロセスのプロセスIDです。

ログファイル名の例:

ディスク使用量を制御するために、ログは循環方式でエージングされます。現在のログがサイズの限界に達すると、SharePlexは新しいログファイルを生成します。新しいログは最大ログ数まで作成され、その後、SharePlexは最も古いログから上書きを開始します。

repairジョブのキャンセル

実行中のcompareまたはrepairジョブを停止するには、cancelコマンドを使用します。

sp_ctrl(sysA)>cancel JOBID

詳細については、「cancel」を参照してください。

compare履歴とログの管理

SharePlex は、終了した各ジョブの履歴をソースシステムのデータベースに保持します。SP_SYS_JOB_HISTORY_RETENTIONパラメーターは、履歴の保持期間を制御します。

この履歴を必要に応じて消去するには、clear historyコマンドを使用します。SharePlexがジョブの履歴を削除すると、履歴の元となったログファイルも削除されます。

データベースのジョブ履歴を消去せずにソースシステムからログファイルを削除するには、remove logコマンドを使用します。このコマンドは、ターゲットシステムから古いログファイルを削除するためにも使用できます。

ログファイルのサイズを制御するには、SP_DEQ_LOG_FILESIZEパラメーターを設定します。

バッチサイズのコントロール

プロセスがSELECTクエリを実行するときにフェッチされる行のブロックのサイズを制御することができます。ブロックサイズは、SP_DEQ_MALLOCパラメーターで設定された値に基づいて計算されます。この値は、使用されるcompareスレッドの数で等分され、その後、すべての列のサイズを足した値に基づいて再計算されます。

用途

構文

構文の説明

必須コマンドコンポーネント

オプションのコマンドコンポーネント

リモートオプション

これらのオプションにより、リモートマシンにコマンドを発行したり、ログイン名、パスワード、ポート番号、またはそれらの組み合わせを含むコマンドをスクリプト化したりすることができます。