| Oracle Streams概要および管理 11g リリース1（11.1） E05775-02 |
|
 前へ |
 次へ |
この付録では、Oracle Streamsと他のOracle Databaseコンポーネントとの連携について説明します。
内容は次のとおりです。
次の項では、Oracle StreamsとOracle Real Application Clusters（Oracle RAC）との連携について説明します。
|
関連項目: Oracle RAC環境におけるOracle Streamsのベスト・プラクティスについては、Oracle Streamsレプリケーション管理者ガイドを参照 |
取得プロセスは、Oracle Real Application Clusters（Oracle RAC）環境での変更を取得できます。同じ環境で1つ以上の取得プロセスとOracle RACを使用する場合は、取得プロセスによって取得される変更を含むすべてのアーカイブ・ログは、Oracle RAC環境のすべてのインスタンスで使用可能である必要があります。Oracle RAC環境では、取得プロセスによってすべてのインスタンスによる変更が読み取られます。単一の取得プロセスによって使用されるプロセスは、Oracle RAC環境の単一インスタンスで実行されます。
各取得プロセスは、起動プロシージャまたは停止プロシージャが別のインスタンスで実行されている場合でも、そのANYDATAキューの所有者インスタンスで起動および停止されます。また、現行の所有者インスタンスが使用不可能になった場合、取得プロセスは別のインスタンスに対するキューに従います。キュー自体は、プライマリ・インスタンスとセカンダリ・インスタンスの所有権のルールに従います。
取得プロセスによって使用されるキューを含むキュー表の所有者インスタンスが使用不可能になった場合、キュー所有権がクラスタ内の別のインスタンスに自動的に移動します。さらに、所有者インスタンスが使用不可能になったときに取得プロセスが有効であった場合、取得プロセスは新しい所有者インスタンスで自動的に再起動されます。所有者インスタンスが使用不可能になったときに取得プロセスが無効であった場合、取得プロセスは新しい所有者インスタンスでも無効のままです。
LogMinerではLOG_ARCHIVE_DEST_n初期化パラメータがサポートされており、Oracle Streamsの取得プロセスでは、LogMinerを使用してREDOログから変更が取得されます。1つの宛先からアーカイブ・ログ・ファイルにアクセスできない場合は、ローカル取得プロセスで、アクセス可能な別の宛先からアーカイブ・ログ・ファイルを読み取ることができます。Oracle RACデータベースでは、この機能を使用して、インスタンス間アーカイブ（CIA）を使用することもできます。CIAでは、各インスタンスによってファイルがすべてのインスタンスにアーカイブされます。この方法では、アーカイブ・ログ・ファイルの欠落による差異を検出したり、解決することはできません。このため、この方法は、既存の方法を補完して、アーカイブ・ファイルをすべてのインスタンスで共有可能にする場合にのみ使用できます。
ダウンストリーム取得プロセス環境では、ソース・データベースは、単一インスタンス・データベースまたは複数インスタンスのOracle RACデータベースです。ダウンストリーム・データベースは、ソース・データベースが単一インスタンスか複数インスタンスかに関係なく、単一インスタンスのデータベースまたは複数インスタンスのOracle RACデータベースとして構成できます。
|
関連項目:
|
同期取得は、Oracle Real Application Clusters（Oracle RAC）環境での変更を取得できます。Oracle RAC環境では、同期取得によって、すべてのインスタンスで行われた変更が読み取られます。
Oracle RAC環境での同期取得のパフォーマンスを向上させるには、個別の表セットに対する変更を個別の同期取得で取得する必要があります。たとえば、様々なアプリケーションでデータベース内の異なるセットのデータベース・オブジェクトが使用されている場合は、各アプリケーションのデータベース・オブジェクトに対する変更を取得する個別の同期取得を構成します。この場合、各同期取得で、別々のキューおよびキュー表を使用する必要があります。
取得と適用の複合はOracle Real Application Clusters（Oracle RAC）環境で使用できます。Oracle RAC環境では、取得プロセスおよび適用プロセスは、同じインスタンス、単一のOracle RACデータベース内の異なるインスタンス、または異なるデータベースに存在することができます。取得プロセスおよび適用プロセスが同じデータベースの異なるインスタンスまたは異なるデータベースに存在する場合、取得と適用の複合を使用するには、取得プロセス・キューと適用プロセス・キューの間の伝播を構成する必要があります。
Oracle Real Application Clusters（Oracle RAC）環境で、LCRとユーザー・メッセージをステージングするようにキューを構成できます。Oracle RAC環境では、キューのバッファを使用できるのは所有者インスタンスのみですが、別のインスタンスは、別のキューのバッファを使用できます。バッファ・キューは、キューに関連付けられたシステム・グローバル領域（SGA）メモリーです。
Oracle Streamsのプロセスおよびジョブは、キュー表のプライマリ・インスタンスおよびセカンダリ・インスタンスの指定をサポートしています。これらの指定を使用する場合、プライマリ・インスタンスが使用不可能になると、セカンダリ・インスタンスがキュー表の所有者となります。プライマリ・インスタンスが再度使用可能になると、所有権はプライマリ・インスタンスに戻ります。
プライマリ・インスタンスおよびセカンダリ・インスタンスの指定は、DBMS_AQADMパッケージのALTER_QUEUE_TABLEプロシージャを使用して設定できます。DBA_QUEUE_TABLESデータ・ディクショナリ・ビューは、キュー表の所有者インスタンスに関する情報を示します。キュー表には、複数のキューが含まれている場合があります。この場合、キュー表内の各キューの所有者インスタンスは、キュー表と同じになります。
|
関連項目:
|
伝播は、あるキューからOracle Real Application Clusters（Oracle RAC）環境内の別のキューにメッセージを伝播できます。インスタンスで実行されている伝播ジョブは、そのインスタンスで所有されるキューから宛先キューに論理変更レコード（LCR）を伝播します。
Oracle RACデータベースへの伝播は、データベース・リンクを介して行われます。データベース・リンクは、メッセージを受信予定のキューを所有している宛先インスタンスに接続するように構成する必要があります。
伝播で宛先キューを含むキュー表の所有者インスタンスが使用不可能になると、キューの所有権がクラスタ内の別のインスタンスに自動的に移動します。宛先キューを含むキュー表のプライマリ・インスタンスおよびセカンダリ・インスタンスの両方が使用不可能になると、キューの所有権がクラスタ内の別のインスタンスに自動的に移動します。この場合、プライマリ・インスタンスまたはセカンダリ・インスタンスが再度使用可能になると、所有権は使用可能になったインスタンスに戻ります。
バッファ宛先キューへのキュー・ツー・キュー伝播は、サービスを使用してOracle RAC環境での透過的フェイルオーバーを提供します。つまり、キュー・ツー・キュー伝播の伝播ジョブは、宛先キューを所有するインスタンスに自動的に接続します。キュー・ツー・キュー伝播で使用されるサービスは、常に宛先キューの所有者インスタンスで実行されます。このサービスは、Oracle RACデータベース内のバッファ・キュー用にのみ作成されます。Oracle RACデータベースにバッファリングされたメッセージ機能を使用する予定の場合は、任意のインスタンスでメッセージをバッファ・キューにエンキューできます。キューを所有していないインスタンスにメッセージがエンキューされた場合、メッセージは正しいインスタンスに送信されますが、キューを所有しているインスタンスにメッセージをエンキューする方がより効率的です。このサービスを使用すると、メッセージをバッファ・キューにエンキューする前にキューの所有者インスタンスに接続できます。
キュー・サービスはキューの所有者インスタンスで常に実行しているため、Oracle RACインスタンスが失敗すると、透過的フェイルオーバーが行われます。複数のキュー・ツー・キュー伝播が1つのデータベース・リンクを使用する場合、メッセージを適切な宛先キューに伝播するように各伝播の接続記述が自動的に変わります。
これに対し、キュー・ツーdblink伝播ではサービスを使用しません。伝播で宛先キューを含むOracle RACデータベースの所有者インスタンスが失敗すると、キュー・ツーdblink伝播ではユーザーがデータベース・リンクを再び指す必要があります。伝播ジョブが宛先データベースの正しいインスタンスに接続するようにするには、宛先キューを所有しているインスタンスに接続するようにソース・データベースからのデータベース・リンクを手動で再構成します。
DBA_SERVICESデータ・ディクショナリ・ビューのNAME列に、キューのサービス名が含まれています。DBA_QUEUESデータ・ディクショナリ・ビューのNETWORK_NAME列には、キューのネットワーク名が含まれています。キュー・ツー・キュー伝播のサービスを管理することはできません。これらのサービスはOracleによって自動的に管理されます。キュー・ツーdblink伝播の場合、正しいインスタンスに接続するには、データベース・リンクの接続文字列でネットワーク名をサービス名として使用します。
|
注意: Oracle RAC環境でキューが取得LCRを含む場合、キュー・ツー・キュー伝播を使用してOracle RACの宛先データベースにメッセージを伝播する必要があります。キュー・ツーdblink伝播で取得LCRがOracle RACの宛先データベースに伝播される場合、この伝播は、宛先キューの所有者インスタンスを参照するインスタンス固有のデータベース・リンクを使用する必要があります。このような伝播が他のインスタンスに接続すると、伝播でエラーが発生します。 |
Oracle Streamsの適用プロセスは、Oracle Real Application Clusters（Oracle RAC）環境での変更を適用するように構成できます。各適用プロセスは、開始プロシージャおよび停止プロシージャが別のインスタンスで実行されている場合でも、そのANYDATAキューの所有者インスタンスで開始または停止されます。適用コーディネータ・プロセス、それに対応する適用リーダー・サーバーおよびそのすべての適用サーバーは、単一インスタンスで実行されます。
適用プロセスで使用されるキューが含まれているキュー表の所有者インスタンスが使用不可能になると、キューの所有権は自動的にクラスタ内の別のインスタンスに譲渡されます。また、現行の所有者インスタンスが使用不可能になった場合、適用プロセスは、別のインスタンスに対するキューに従います。キュー自体は、プライマリ・インスタンスとセカンダリ・インスタンスの所有権のルールに従います。また、適用プロセスは、所有者インスタンスが使用不可能になったときに有効だった場合、新しい所有者インスタンスで自動的に起動されます。所有者インスタンスが使用不可能になったときに無効だった場合は、新しい所有者インスタンスでも無効のままになります。
次の項では、Oracle Streamsと透過的データ暗号化との連携について説明します。
|
関連項目: 透過的データ暗号化の詳細は、Oracle Database Advanced Security管理者ガイドを参照 |
ローカル取得プロセスでは、透過的データ暗号化を使用して暗号化されている列に対する変更を取得できます。ダウンストリーム取得プロセスでは、ダウンストリーム・データベースがソース・データベースとウォレットを共有している場合にのみ、暗号化されている列に対する変更を取得できます。ウォレットは、ネットワーク・ファイル・システム（NFS）を介して共有するか、または1つのコンピュータ・システムから別のコンピュータ・システムに手動でコピーできます。ウォレットがダウンストリーム・データベースと共有されている場合は、ダウンストリーム・データベースのsqlnet.oraファイルのENCRYPTION_WALLET_LOCATIONパラメータにウォレットの場所が指定されていることを確認してください。
ダウンストリーム・データベースにウォレットをコピーする場合は、ソース・データベースのウォレットが変更されるたびに、ソース・データベースからダウンストリーム・データベースにウォレットをコピーしてください。ダウンストリーム・データベースのウォレットに対して、レプリケートされた表の暗号化キーの変更などの操作は実行しないでください。
ローカル取得プロセスまたはダウンストリーム取得プロセスによって取得された行論理変更レコード（行LCR）内の暗号化された列は、行LCRがバッファ・キューにステージングされると復号化されます。透過的データ暗号化が有効になっているデータベース内のディスクに行LCRがオーバーフローした場合、行LCRはディスクに格納されますが、すべての暗号化された列はOracle Streamsによって透過的に暗号化されます。
|
注意: 取得プロセスによって使用されるREDOログが互換性レベル11.0.0以上のデータベースで生成されている場合、取得プロセスでは、暗号化された列のみがサポートされます。互換性レベルは、COMPATIBLE初期化パラメータによって制御されます。 |
同期取得では、透過的データ暗号化を使用して暗号化されている列に対する変更を取得できます。同期取得によって取得された行論理変更レコード（行LCR）内の暗号化された列は、行LCRが永続キューにステージングされている場合は暗号化されたままになります。
明示的取得を使用すると、データベース表で暗号化されている列の行論理変更レコード（行LCR）を作成およびエンキューできます。ただし、行LCRの作成時に列が暗号化されるように指定することはできません。したがって、明示的に取得された行LCRがキューにステージングされると、行LCRのすべての列が復号化されます。
永続キューは、同期取得によって取得された行論理変更レコード（行LCR）を格納できます。これらの行LCRには、透過的データ暗号化を使用して暗号化された列に対する変更を含めることができます。行LCRは、永続キューに格納されている間は暗号化されたままです。明示的に取得された行LCRには、暗号化された列を含めることはできません。
バッファ・キューは、取得プロセスによって取得された変更を含む行LCRを格納できます。これらの行LCRには、透過的データ暗号化を使用して暗号化された列に対する変更を含めることができます。暗号化された列を含む行LCRがバッファ・キューに格納されると、それらの列は復号化されます。行LCRがディスクにオーバーフローした場合に、その行LCRがディスクに格納されている間、Oracle Streamsは透過的に暗号化された列を暗号化します。
伝播では、透過的データ暗号化を使用して暗号化された列に対する変更を含む行論理変更レコード（行LCR）を伝播できます。伝播によって、暗号化された列とともに行LCRが伝播されると、行LCRがネットワーク上を転送される間に、暗号化された列が復号化されます。必要に応じて、Oracle Advanced Securityの機能を使用して、ネットワーク上でのデータ転送を暗号化できます。
適用プロセスでは、透過的データ暗号化を使用して暗号化された列を含む、暗黙的に取得された行論理変更レコード（行LCR）をデキューおよび処理できます。暗号化された列は、それらの暗号化列を含む行LCRが適用プロセスによってデキューされると復号化されます。復号化された列を含むこれらの行LCRは、カスタム処理のために適用ハンドラに送信するか、または直接適用することができます。行LCRが適用され、変更された表に暗号化された列が含まれている場合、暗号化された列に対する変更は適用時に暗号化されます。
暗号化された列が行LCRに含まれていて、宛先データベースの対応する列が暗号化されていない場合は、preserve_encryption適用プロセス・パラメータによって適用プロセスの動作が制御されます。
preserve_encryptionパラメータがYに設定されているときに、暗号化された列が行LCRに含まれていて、宛先データベースの対応する列が暗号化されていない場合は、適用プロセスでエラーが発生します。エラーが発生すると、行LCRは適用されず、トランザクションのすべての行LCRがエラー・キューに移動されます。
preserve_encryptionパラメータがNに設定されているときに、暗号化された列が行LCRに含まれていて、宛先データベースの対応する列が暗号化されていない場合は、適用プロセスによって行の変更が適用されます。
適用プロセスが、暗黙的に取得された行LCR（暗号化された列を含む）をエラー・キューに移動する場合、行LCRがエラー・キュー内に存在している間は暗号化された列は暗号化されています。行LCRは、取得プロセスおよび同期取得を使用して暗黙的に取得されます。
メッセージ・クライアントは、暗黙的に取得された行LCR（透過的データ暗号化を使用して暗号化された列を含む）をデキューできます。暗号化された列を含む行LCRがメッセージ・クライアントでデキューされるとその列は復号化されます。
Oracle Streamsは、フラッシュバック・データ・アーカイブ内の表をサポートします。取得プロセスは、これらの表に対して行われたデータ操作言語（DML）およびデータ定義言語（DDL）の変更を取得できます。同期取得は、これらの表に対するDMLの変更を取得できます。適用プロセスは、論理変更レコード（LCR）でカプセル化された変更をこれらの表に適用できます。
また、Oracle Streamsの取得プロセスおよび適用プロセスは、次のDDL文もサポートします。
CREATE FLASHBACK ARCHIVE
ALTER FLASHBACK ARCHIVE
DROP FLASHBACK ARCHIVE
FLASHBACK ARCHIVE句を指定したCREATE TABLE
FLASHBACK ARCHIVE句を指定したALTER TABLE
|
注意: Oracle Streamsは、フラッシュバック・データ・アーカイブによって使用される内部表に対して行われた変更を取得または適用しません。 |
|
関連項目:
|
次の項では、Oracle StreamsとRecovery Manager（RMAN）との連携について説明します。
|
関連項目: Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド |
Recovery Managerを使用すると、Oracle Streamsレプリケーション環境の構成中にデータベース・オブジェクトをインスタンス化することができます。Recovery ManagerのDUPLICATEおよびCONVERT DATABASEコマンドはデータベース全体をインスタンス化することができ、Recovery ManagerのTRANSPORT TABLESPACEコマンドは1つの表領域または表領域のセットをインスタンス化することができます。
|
関連項目: インスタンス化のためのRecovery Managerの使用については、Oracle Streamsレプリケーション管理者ガイドを参照 |
Recovery Manager（RMAN）の一部の削除ポリシーおよびコマンドは、アーカイブREDOログ・ファイルを削除します。Recovery Managerのこれらのポリシーまたはコマンドのいずれかを、1つ以上の取得プロセスに対してREDOログ・ファイルを生成するデータベースで使用する場合は、そのRecovery Managerのコマンドが取得プロセスで必要となるアーカイブREDOログ・ファイルを削除しないことを確認してください。
次の項では、ローカル取得プロセスおよびダウンストリーム取得プロセスにおけるRecovery Managerの削除ポリシーおよびコマンドの動作について説明します
|
関連項目:
|
ローカル取得プロセスが構成されるとき、フラッシュ・リカバリ領域に余裕があれば、Recovery Managerはローカル取得プロセスで必要となるアーカイブERDOログ・ファイルを削除しません。具体的には、Recovery Managerは、ローカル取得プロセスの必須チェックポイントSCN以上のシステム変更番号（SCN）値の変更を含むアーカイブREDOログ・ファイルを削除しません。これは、Recovery Managerのすべての削除ポリシーおよびDELETEコマンド（DELETE ARCHIVELOGおよびDELETE OBSOLETEを含む）におけるRecovery Managerのデフォルトの動作です。
フラッシュ・リカバリ領域に新しいログ・ファイルを書き込む領域が十分にない場合、Recovery Managerは1つ以上のアーカイブREDOログ・ファイルを自動的に削除します。Recovery Managerが自動的に削除したアーカイブREDOログ・ファイルがローカル取得プロセスで必要なものであれば、Oracle Databaseによってアラート・ログに警告が書き込まれます。
アーカイブREDOログ・ファイルのバックアップがローカル取得プロセス・データベースで作成される場合は、Recovery Managerの次の削除ポリシーをお薦めします。
CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP integer TIMES TO DEVICE TYPE deviceSpecifier;
この削除ポリシーでは、ログ・ファイルが削除対象とみなされるまでにinteger回バックアップされる必要があります。
アーカイブREDOログ・ファイルのバックアップがローカル取得プロセス・データベースで作成されない場合は、推奨される特定の削除ポリシーはありません。デフォルトでは、Recovery Managerはローカル取得プロセスで必要となるアーカイブREDOログ・ファイルを削除しません。
ダウンストリーム取得プロセスが、ソース・データベースで行われたデータベースの変更を取得する場合、アーカイブREDOログ・ファイルがソース・データベースからダウンストリーム取得プロセス・データベースに移動されるまで、Recovery Managerの削除ポリシーまたはコマンドがそのアーカイブREDOログ・ファイルを削除しないことを確認してください。
アーカイブREDOログ・ファイルを削除するRecovery Managerの特定の削除ポリシーおよびコマンドの考慮事項を次に示します。
Recovery ManagerコマンドCONFIGURE ARCHIVELOG DELETION POLICYは、フラッシュ・リカバリ領域内のアーカイブREDOログ・ファイルが削除対象となるタイミングを決定する削除ポリシーを設定します。また、この削除ポリシーは、Recovery ManagerのすべてのDELETEコマンド（DELETE ARCHIVELOGおよびDELETE OBSOLETEを含む）に適用されます。
次の設定は、ソース・データベースでの動作を決定します。
TO SHIPPED TO STANDBYを設定した削除ポリシーは、ログ・ファイルを必要とするダウンストリーム取得プロセス・データベースにそのファイルが移動されるまで、ログ・ファイルを削除しません。これらのログ・ファイルは、ダウンストリーム取得プロセスで処理された場合もあれば、処理されなかった場合もあります。自動削除が発生するのは、フラッシュ・リカバリ領域に新しいログ・ファイルを書き込む領域が十分にない場合です。
TO APPLIED ON STANDBYを設定した削除ポリシーは、ログ・ファイルが、そのファイルを必要とするダウンストリーム取得プロセスに移動されたかどうかを現在はチェックしません。自動削除が発生するのは、フラッシュ・リカバリ領域に新しいログ・ファイルを書き込む領域が十分にない場合です。
TO BACKED UP integer TIMES TO DEVICE TYPEを設定した削除ポリシーでは、ログ・ファイルが削除対象とみなされるまでに、そのログ・ファイルはinteger回バックアップされる必要があります。ログ・ファイルは、そのファイルを必要とするダウンストリーム取得プロセスで処理されていない場合であっても削除できます。
TO NONEを設定した削除ポリシーは、フラッシュ・リカバリ領域に余裕がなくなった場合に、ログ・ファイルが、そのファイルを必要とするダウンストリーム取得プロセスで処理されていなくても、そのログ・ファイルを削除できることを意味します。
Recovery ManagerコマンドDELETE ARCHIVELOGは、次の条件をすべて満たすアーカイブREDOログ・ファイルを削除します。
ログ・ファイルが、DELETE ARCHIVELOGコマンドで指定した条件を満たしている。
CONFIGURE ARCHIVELOG DELETION POLICYに従ってログ・ファイルを削除できる。たとえば、ポリシーにTO SHIPPED TO STANDBYを設定した場合、ログ・ファイルが、そのファイルを必要とするダウンストリーム取得プロセス・データベースに移動されるまで、このコマンドではそのログ・ファイルを削除できません。
この動作は、データベースがマウントまたはオープンされたときに適用されます。
アーカイブREDOログ・ファイルがダウンストリーム取得プロセスで必要な変更を含むために削除されない場合は、Recovery Managerによって警告メッセージが表示され、これらのファイルに対する削除操作がスキップされたことが示されます。
Recovery ManagerコマンドDELETE OBSOLETEは、次の条件をすべて満たすアーカイブREDOログ・ファイルを完全に削除します。
ログ・ファイルが、保存ポリシーに従って不要になっている。
CONFIGURE ARCHIVELOG DELETION POLICYに従ってログ・ファイルを削除できる。たとえば、ポリシーにTO SHIPPED TO STANDBYを設定した場合、ログ・ファイルが、そのファイルを必要とするダウンストリーム取得プロセス・データベースに移動されるまで、このコマンドではそのログ・ファイルを削除できません。
この動作は、データベースがマウントまたはオープンされたときに適用されます。
Recovery ManagerコマンドBACKUP ARCHIVELOG ALL DELETE INPUTは、アーカイブREDOログ・ファイルをコピーし、バックアップの完了後に元のファイルを削除します。このコマンドでは、次の条件が満たされている場合、ログ・ファイルがダウンストリーム取得プロセス・データベースに移動されるまで、そのログ・ファイルは削除されません。
データベースがマウントまたはオープンされている。
ログ・ファイルが、ダウンストリーム取得プロセスで必要である。
削除ポリシーにTO SHIPPED TO STANDBYを設定している。
アーカイブREDOログ・ファイルがダウンストリーム取得プロセスで必要な変更を含むために削除されない場合は、Recovery Managerによって警告メッセージが表示され、これらのファイルに対する削除操作がスキップされたことが示されます。
ダウンストリーム取得プロセスの場合、ソース・データベースにおけるRecovery Managerの削除ポリシーを次のいずれかにすることをお薦めします。
アーカイブREDOログ・ファイルのバックアップがソース・データベースで作成される場合、削除ポリシーを次のように設定します。
CONFIGURE ARCHIVELOG DELETION POLICY TO SHIPPED TO STANDBY BACKED UP integer TIMES TO DEVICE TYPE deviceSpecifier;
アーカイブREDOログ・ファイルのバックアップがソース・データベースで作成されない場合、削除ポリシーを次のように設定します。
CONFIGURE ARCHIVELOG DELETION POLICY TO SHIPPED TO STANDBY;
|
注意: ダウンストリーム取得プロセス・データベースでは、ソース・データベースから移動されたアーカイブREDOログ・ファイルは、Recovery Managerで管理されません。 |
Oracle Streamsでは、単方向レプリケーション環境におけるリカバリ・カタログのレプリケートがサポートされます。リカバリ・カタログの双方向レプリケーションはサポートされません。
|
関連項目:
|
