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

• Seule la réplication basée sur des 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.
  Note
  
  MySQL 5.7 a un bogue connu où l'énoncé DROP TEMPORARY TABLE est mal connecté au journal binaire basé sur une rangée et entraîne l'échec de la réplication basée sur une rangée. MySQL 5.7 is in Sustaining Support since Oct 2023 and no further bug fixes will be delivered per 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 à partir d'une seule source est prise en charge. La réplication multisource 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 entrant est suspendu. Le canal est repris lorsque le processus de mise à niveau est terminé.
• Seules les instructions que le nom d'utilisateur du demandeur a le privilège d'exécuter peuvent être répliquées. La réplication échoue si le nom d'utilisateur du demandeur ne dispose pas de privilèges suffisants pour exécuter toute 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. Voir Privilèges MySQL par défaut.
• Avant MySQL 8.2, le nom d'utilisateur dans la clause DEFINER des énoncés CREATE VIEW, CREATE PROCEDURE et CREATE FUNCTION doit être identique au nom d'utilisateur du demandeur pour que ces énoncés puissent être répliqués avec succès. Dans MySQL 8.2 ou une version supérieure, l'utilisateur demandeur doit disposer du privilège SET_ANY_DEFINER pour répliquer les énoncés CREATE VIEW, CREATE PROCEDURE et CREATE FUNCTION avec la clause DEFINER contenant un autre nom d'utilisateur.
• Les systèmes de base de données (MySQL 8.3.0 ou version supérieure) créés avant mai 2024 qui ne disposent pas du privilège TRANSACTION_GTID_TAG doivent être mis à niveau pour répliquer des transactions avec des marqueurs GTID.
• Lorsque les énoncés ALTER TABLE <table_name> SECONDARY_LOAD et ALTER TABLE <table_name> SECONDARY_UNLOAD sont répliqués vers un système de base de données cible, ces énoncés ne chargent pas ou ne déchargent pas de données dans la grappe HeatWave attachée au système de base de données cible, le cas échéant.
  Note
  
  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 être interrompu si l'entrepôt avec lac de données HeatWave 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 spécifiés dans l'attribut de moteur de la table externe d'entrepôt avec lac de données.
• Dans les versions antérieures à 8.4.0-u2, si le système de base de données cible a une grappe HeatWave arrêtée (inactive), le canal de réplication ne peut pas appliquer d'énoncé LDD qui crée ou modifie une table externe d'entrepôt avec lac de données. Le canal de réplication va se briser.
• Si vous voulez répliquer des tables externes avec entrepôt avec lac de données, il est recommandé de ne pas régler le canal à GENERATE_IMPLICIT_PRIMARY_KEY pour les tables sans clé primaire. La réplication est interrompue lors de la modification d'une table InnoDB avec une clé primaire générée en table d'entrepôt avec lac de données.