制限

MySQL HeatWaveサービスへのインバウンド・レプリケーションでは、MySQLレプリケーションで可能な構成の一部がサポートされていません。

行ベース・レプリケーションのみがサポートされています。このバイナリログ形式は、MySQLバージョン5.7以降ではデフォルトです。ステートメントベースのレプリケーションと混在レプリケーションはサポートされていません。
ノート

MySQL 5.7には、DROP TEMPORARY TABLE文が行ベースのバイナリ・ログに誤って記録され、行ベースのレプリケーションが失敗する既知のバグがあります。MySQL 5.7は2023年10月からSustaining Supportに入っており、Oracle Lifetime Support Policyごとにそれ以上のバグ修正は提供されません。
非同期レプリケーションのみがサポートされています。準同期レプリケーションはサポートされていません。
単一のソースからのレプリケーションのみがサポートされています。マルチソース・レプリケーションはサポートされません。
チャネルは、最大30個のチャネル・フィルタをサポートできます。
mysqlスキーマに対する変更はレプリケートされません。変更されているとレプリケーションが停止します。
高可用性DBシステムがアップグレードされると、インバウンド・レプリケーション・チャネルは一時停止されます。アップグレード・プロセスが完了すると、チャネルが再開されます。
レプリケートできるのは、applierユーザー名が実行権限を持つ文のみです。ソース・サーバーのバイナリ・ログから読み取られた文を実行するための十分な権限がapplierユーザー名にない場合、レプリケーションは失敗します。権限のリストは、DBシステムの管理者に付与された権限に制限されます。デフォルトのMySQL権限を参照してください。
MySQL 8.2より前では、これらのステートメントを正常にレプリケートするには、CREATE VIEW、CREATE PROCEDURE、および CREATE FUNCTIONステートメントの DEFINER句内のユーザー名がapplierユーザー名と同じである必要があります。MySQL 8.2以上では、他のユーザー名を含むDEFINER句を使用してCREATE VIEW、CREATE PROCEDUREおよびCREATE FUNCTION文をレプリケートするには、applierユーザーにSET_ANY_DEFINER権限が必要です。
GTIDタグを使用してトランザクションをレプリケートするには、2024年5月より前に作成されたDBシステム(MySQL 8.3.0以上)で、TRANSACTION_GTID_TAG権限がないDBシステムをアップグレードする必要があります。
非同期レプリケーションでは、ソースDBシステムとターゲットDBシステムの両方を読取り/書込みDBシステムにすることができ、関連するHeatWaveクラスタは個別に管理できます。ただし、間にレプリケーション・チャネルがあるため、ソースで実行されるアクションはターゲットDBシステムの機能に影響する可能性があります。
ALTER TABLE <table_name> SECONDARY_LOAD文およびALTER TABLE <table_name> SECONDARY_UNLOAD文がターゲットDBシステムにレプリケートされる場合、ターゲットDBシステムにアタッチされているHeatWaveクラスタにデータがロードまたはアンロードされません(ある場合)。
これは、ソースにHeatWaveクラスタがあるが、ターゲットにHeatWaveクラスタがないDBシステム、およびプライマリDBシステムにのみHeatWaveクラスタがある高可用性DBシステム間のレプリケーションの設定に役立ちます。ただし、ALTER TABLE <table_name> SECONDARY_LOAD文がレプリケートされると、MySQLデータ・ディクショナリでセカンダリ・ロード・メタデータが更新されます。セカンダリ・ロード・メタデータはリカバリ時に参照されるため、ターゲットDBシステムが再起動すると、セカンダリ・ロードDDL文がレプリケートされる新しい表も、ターゲットDBシステムのHeatWaveクラスタでのリロードの対象とみなされます。
ソースDBシステムとターゲットDBシステムの両方で、HeatWaveクラスタ内の表を個別にロードまたはアンロードできます。ただし、MySQL 9.5.1以前のバージョンでは、最初にターゲットDBシステムのHeatWaveクラスタに表をロードしてから、ソースDBシステムのHeatWaveクラスタに同じ表をロードしようとすると、レプリケーション・チャネルが破損し、次のようなエラーが生成されます。
```
Replica SQL for channel 'replication_channel': Worker 1 failed executing transaction 
'<transaction_id>' at source log binary-log.<number>, end_log_pos <number>;
Error 'Secondary engine operation failed. Table already has a secondary engine defined.' on query.
Default database: ''. Query: 'ALTER TABLE <table_name> SECONDARY_ENGINE=RAPID', Error_code: MY-003889   
```
MySQL 9.5.1以前のバージョンでは、これは、ロードによって生成されたALTER TABLE <table_name> SECONDARY_ENGINE = RAPID DDL文がレプリケートされますが、対応する表がすでにHeatWaveクラスタにロードされ、SECONDARY_ENGINE = RAPIDがすでに設定されているため、ターゲットDBシステムで失敗するためです。
MySQL 9.5.2以降のバージョンでは、レプリケーションチャネルが壊れたりエラーを生成したりすることなく、ソースDBシステムとターゲットDBシステムの両方でテーブルを個別にロードおよびアンロードできます。
HeatWaveクラスタがソースDBシステムで削除または再作成されると、以前にロードされたすべての表がソースDBシステムのHeatWaveクラスタからアンロードされ、同じ表がターゲットDBシステムのHeatWaveクラスタからもアンロードされます。これは、ソースDBシステム上のHeatWaveクラスタが削除または再作成されると、ソースDBシステム内の以前にロードされたすべての表のSECONDARY_ENGINE設定がNULLにリセットされるためです。ソースDBシステムで表のSECONDARY_ENGINE設定がリセットされると、ターゲットDBシステムでも同じ表のSECONDARY_ENGINE設定がNULLにリセットされ、その結果、ターゲットDBシステムのHeatWaveクラスタから表がアンロードされます。
Lakehouse外部表をレプリケートする場合は、主キーのない表のチャネルをGENERATE_IMPLICIT_PRIMARY_KEYに設定しないことをお薦めします。生成された主キーを持つInnoDBテーブルをLakehouseテーブルに変更すると、レプリケーションが中断されます。
次の名前はレプリケーション・チャネルに使用できません:
- group_replication_applier
- group_replication_recovery
- oci_upgrade_channel
8.4.0-u2より前のバージョンでは、ターゲットDBシステムに停止(非アクティブ)したHeatWaveクラスタがある場合、レプリケーション・チャネルはLakehouse外部表を作成または変更するDDL文を適用できません。レプリケーション・チャネルが壊れます。
8.4.0-u2より前のバージョンでは、データ・ロードがスキップされても、ターゲットDBシステムでMySQL HeatWave Lakehouseが有効になっていて、Lakehouse外部表のengine属性で指定されたファイルへの読取りおよびリスト・アクセス権がないと、レプリケーション・チャネルが破損する可能性があります。

Oracle Cloud Infrastructureドキュメント

制限