Inbound replication to HeatWave Service does not support some of the configurations that are possible for MySQL replication.

• Only row-based replication is supported. This binary log format is the default in MySQL version 5.7 and higher. Statement-based replication and mixed replication are not supported.
• Only asynchronous replication is supported. Semi-synchronous replication is not supported.
• Only replication from a single source is supported. Multi-source replication is not supported.
• Changes to the mysql schema are not replicated and cause replication to stop.
• When a high availability DB system is upgraded, the inbound replication channel is suspended. The channel is resumed when the upgrade process is complete.
• Only statements which the applier username has privilege to execute can be replicated. Replication fails if the applier username has insufficient privilege to execute any statement read from the binary logs of the source server. The list of privileges is restricted to the privileges granted to the administrator of the DB system. See Default MySQL Privileges.
• Prior to MySQL 8.2, the username in the DEFINER clause of CREATE VIEW, CREATE PROCEDURE, and CREATE FUNCTION statements must be the same as the applier username in order to replicate these statements successfully. In MySQL 8.2 or higher, the applier user must have the SET_ANY_DEFINER privilege to replicate CREATE VIEW, CREATE PROCEDURE, and CREATE FUNCTION statements with DEFINER clause containing other username.
• DB systems (MySQL 8.3.0 or higher) created prior to May 2024 that do not have the TRANSACTION_GTID_TAG privilege need to be upgraded in order to replicate transactions with GTID tags.
• When the ALTER TABLE <table_name> SECONDARY_LOAD and ALTER TABLE <table_name> SECONDARY_UNLOAD statements are replicated to a target DB system, these statements do not load or unload data in the HeatWave cluster attached to the target DB system, if any.
  Note
  
  In versions before 8.4.0-u2, even though the data load is skipped, the replication channel can break if HeatWave Lakehouse is enabled in the target DB system and it does not have read and list access to the files specified in the engine attribute of the Lakehouse external table.
• In versions before 8.4.0-u2, if the target DB system has a stopped (inactive) HeatWave cluster, the replication channel cannot apply any DDL statement that creates or alters a Lakehouse external table. The replication channel will break.
• If you want to replicate Lakehouse external tables, it is recommended not to set the channel to GENERATE_IMPLICIT_PRIMARY_KEY for tables without primary key. Replication breaks when altering an InnoDB table with a generated primary key to a Lakehouse table.