La réplication entrante vers le service MySQL HeatWave ne prend pas en charge certaines des configurations possibles pour la réplication MySQL.

• Seule la réplication basée sur les lignes est prise en charge. Ce format de journal binaire est la valeur par défaut dans MySQL version 5.7 et supérieure. La réplication basée sur des instructions et la réplication mixte ne sont pas prises en charge.
  Remarque
  
  MySQL 5.7 comporte un bogue connu dans lequel l'instruction DROP TEMPORARY TABLE est journalisée à tort dans le journal binaire basé sur les lignes et entraîne l'échec de la réplication basée sur les lignes. MySQL 5.7 bénéficie d'un Support de Soutien depuis octobre 2023, et aucun autre correctif de bugs ne sera fourni conformément à Oracle Lifetime Support Policy.
• Seule la réplication asynchrone est prise en charge. La réplication semi-synchrone n'est pas prise en charge.
• Seule la réplication d'une source unique est prise en charge. La réplication multiorigine n'est pas prise en charge.
• Les modifications apportées au schéma mysql ne sont pas répliquées et entraînent l'arrêt de la réplication.
• Lorsqu'un système de base de données haute disponibilité est mis à niveau, le canal de réplication entrante est suspendu. Le canal est repris lorsque le processus de mise à niveau est terminé.
• Seules les instructions que le nom utilisateur de l'applicateur a le privilège d'exécuter peuvent être répliquées. La réplication échoue si le nom utilisateur de l'applicateur ne dispose pas des privilèges suffisants pour exécuter une instruction lue à partir des journaux binaires du serveur source. La liste des privilèges est limitée aux privilèges accordés à l'administrateur du système de base de données. Reportez-vous à Privilèges MySQL par défaut.
• Avant MySQL 8.2, le nom utilisateur dans la clause DEFINER des instructions CREATE VIEW, CREATE PROCEDURE et CREATE FUNCTION doit être identique au nom utilisateur de l'applicateur pour que ces instructions puissent être répliquées. Dans la version MySQL 8.2 ou supérieure, l'utilisateur de l'applicateur doit disposer du privilège SET_ANY_DEFINER pour répliquer les instructions CREATE VIEW, CREATE PROCEDURE et CREATE FUNCTION avec la clause DEFINER contenant un autre nom utilisateur.
• Les systèmes de base de données (MySQL 8.3.0 ou version ultérieure) créés avant mai 2024 qui ne disposent pas du privilège TRANSACTION_GTID_TAG doivent être mis à niveau afin de répliquer les transactions avec des balises GTID.
• Lorsque les instructions ALTER TABLE <table_name> SECONDARY_LOAD et ALTER TABLE <table_name> SECONDARY_UNLOAD sont répliquées vers un système de base de données cible, elles ne chargent ni ne déchargent les données dans le cluster HeatWave attaché au système de base de données cible, le cas échéant.
  Remarque
  
  Dans les versions antérieures à 8.4.0-u2, même si le chargement des données est ignoré, le canal de réplication peut s'interrompre si MySQL HeatWave Lakehouse est activé dans le système de base de données cible et qu'il ne dispose pas d'un accès en lecture et en liste aux fichiers indiqués dans l'attribut de moteur de la table externe Lakehouse.
• Dans les versions antérieures à 8.4.0-u2, si le système de base de données cible a un cluster HeatWave arrêté (inactif), le canal de réplication ne peut appliquer aucune instruction LDD qui crée ou modifie une table externe Lakehouse. Le canal de réplication va se rompre.
• Si vous voulez répliquer des tables externes Lakehouse, il est recommandé de ne pas définir le canal sur GENERATE_IMPLICIT_PRIMARY_KEY pour les tables sans clé primaire. La réplication s'interrompt lors de la modification d'une table InnoDB avec une clé primaire générée vers une table Lakehouse.