制限
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文をレプリケートするためのSET_ANY_DEFINER権限が、applierユーザーに必要です。 - GTIDタグを使用してトランザクションをレプリケートするには、
TRANSACTION_GTID_TAG権限がない2024年5月より前に作成されたDBシステム(MySQL 8.3.0以上)をアップグレードする必要があります。 - 非同期レプリケーションでは、ソース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クラスタ内の表を個別にロードまたはアンロードできます。ただし、最初にターゲット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-003889ALTER TABLE <table_name> SECONDARY_ENGINE = RAPIDDDL文がレプリケートされたが、対応する表がすでにHeatWaveクラスタにロードされており、SECONDARY_ENGINE = RAPIDが設定されているため、ターゲットDBシステムで失敗するためです。 - HeatWaveクラスタがソースDBシステムで削除または再作成されると、以前にロードされたすべての表がソースDBシステムのHeatWaveクラスタからアンロードされ、ターゲットDBシステムのHeatWaveクラスタからも同じ表がアンロードされます。これは、ソースDBシステム上のHeatWaveクラスタが削除または再作成されると、ソースDBシステム内のすべての以前にロードされた表の
SECONDARY_ENGINE設定がNULLにリセットされるためです。ソースDBシステムで表のSECONDARY_ENGINE設定がリセットされると、ターゲットDBシステムでも同じ表のSECONDARY_ENGINE設定がNULLにリセットされ、その結果、ターゲットDBシステムのHeatWaveクラスタから表がアンロードされます。 - レイクハウスの外部表をレプリケートする場合は、主キーのない表に対してチャネルを
GENERATE_IMPLICIT_PRIMARY_KEYに設定しないことをお薦めします。レイクハウス表に対して生成された主キーを持つInnoDB表を変更すると、レプリケーションが中断されます。 - 8.4.0-u2より前のバージョンでは、ターゲットDBシステムに停止(非アクティブな)HeatWaveクラスタがある場合、レプリケーション・チャネルはレイクハウスの外部表を作成または変更するDDL文を適用できません。レプリケーション・チャネルが破損します。
- 8.4.0-u2より前のバージョンでは、データ・ロードがスキップされても、ターゲットDBシステムでMySQL HeatWave Lakehouseが有効になっていて、Lakehouse外部表のengine属性で指定されたファイルに対する読取りおよびリスト・アクセス権がない場合、レプリケーション・チャネルが破損する可能性があります。