Documentation Oracle Cloud Infrastructure

Limites

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.
  • Un canal peut prendre en charge un maximum de 30 filtres de canal.
  • 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.
  • Dans la réplication asynchrone, les systèmes de base de données source et cible peuvent être des systèmes de base de données en lecture/écriture et le cluster HeatWave associé peut être géré indépendamment. Cependant, comme il existe un canal de réplication entre les deux, les actions effectuées à la source peuvent avoir une incidence sur les fonctionnalités du système de base de données cible.
  • 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.

    Cela permet de configurer la réplication entre les systèmes de base de données dans lesquels la source a un cluster HeatWave mais la cible n'a pas de cluster HeatWave, ainsi que dans les systèmes de base de données haute disponibilité où seul le système de base de données principal a un cluster HeatWave. Toutefois, lorsque l'instruction ALTER TABLE <table_name> SECONDARY_LOAD est répliquée, les métadonnées de chargement secondaires sont mises à jour dans le dictionnaire de données MySQL. Etant donné que les métadonnées de chargement secondaire sont consultées au moment de la récupération, si le système de base de données cible redémarre, les nouvelles tables dont les instructions LDD de chargement secondaire sont répliquées sont également prises en compte pour le rechargement dans le cluster HeatWave sur le système de base de données cible.

  • Vous pouvez charger ou décharger indépendamment des tables dans le cluster HeatWave sur les systèmes de base de données source et cible. Toutefois, si vous chargez d'abord une table dans le cluster HeatWave sur le système de base de données cible, puis que vous tentez de charger la même table dans le cluster HeatWave sur le système de base de données source, le canal de réplication risque de se rompre et une erreur similaire à la suivante est générée dans ce cas : 
    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
    Cela se produit car l'instruction LDD ALTER TABLE <table_name> SECONDARY_ENGINE = RAPID générée par le chargement est répliquée mais échoue sur le système de base de données cible car la table correspondante est déjà chargée dans le cluster HeatWave et SECONDARY_ENGINE = RAPID est déjà défini.
  • Lorsque le cluster HeatWave est supprimé ou recréé sur le système de base de données source, toutes les tables précédemment chargées sont déchargées du cluster HeatWave sur le système de base de données source et les mêmes tables sont déchargées du cluster HeatWave sur le système de base de données cible. En effet, lorsque le cluster HeatWave sur le système de base de données source est supprimé ou recréé, le paramètre SECONDARY_ENGINE de toutes les tables précédemment chargées dans le système de base de données source est réinitialisé sur NULL. Lorsque le paramètre SECONDARY_ENGINE d'une table est réinitialisé sur le système de base de données source, le paramètre SECONDARY_ENGINE de la même table est également réinitialisé sur NULL sur le système de base de données cible, ce qui entraîne le déchargement de la table du cluster HeatWave sur le système de base de données cible.
  • 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.
  • 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.
  • 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 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.