Documentation sur 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 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.
  • 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 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.
  • 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 la grappe HeatWave associée peut être gérée indépendamment. Toutefois, 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 é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, ils 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.

    Cela permet de configurer la réplication entre les systèmes de base de données dans lesquels la source comporte une grappe HeatWave mais où la cible n'a pas de grappe 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 comporte une grappe HeatWave. Toutefois, lorsque l'énoncé ALTER TABLE <table_name> SECONDARY_LOAD est répliqué, les métadonnées de chargement secondaire sont mises à jour dans le dictionnaire de données MySQL. Comme 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 énoncés LDD de chargement secondaire sont répliqués sont également prises en compte pour le rechargement dans la grappe HeatWave sur le système de base de données cible.

  • Vous pouvez charger ou décharger indépendamment des tables dans la grappe HeatWave sur les systèmes de base de données source et cible. Toutefois, si vous chargez d'abord une table dans la grappe HeatWave sur le système de base de données cible, puis que vous tentez de charger la même table dans la grappe HeatWave sur le système de base de données source, cela peut provoquer l'interruption du canal de réplication et une erreur similaire à la suivante est générée dans de tels 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 parce que l'énoncé LDD ALTER TABLE <table_name> SECONDARY_ENGINE = RAPID généré par le chargement est répliqué mais échoue sur le système de base de données cible, car la table correspondante est déjà chargée dans la grappe HeatWave et SECONDARY_ENGINE = RAPID est déjà défini.
  • Lorsque la grappe HeatWave est supprimée ou recréée sur le système de base de données source, toutes les tables précédemment chargées sont déchargées de la grappe HeatWave sur le système de base de données source, et les mêmes tables sont également déchargées de la grappe HeatWave sur le système de base de données cible. En effet, lorsque la grappe HeatWave du système de base de données source est supprimée ou recréée, le paramètre SECONDARY_ENGINE pour toutes les tables précédemment chargées dans le système de base de données source est réinitialisé à NULL. Lorsque le paramètre SECONDARY_ENGINE pour une table est réinitialisé sur le système de base de données source, le paramètre SECONDARY_ENGINE pour la même table est également réinitialisé à NULL sur le système de base de données cible, ce qui entraîne le déchargement de la table de la grappe HeatWave sur le système de base de données cible.
  • 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.
  • 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.
  • Dans les versions antérieures à 8.4.0-u2, même si le chargement de données est ignoré, le canal de réplication peut être interrompu 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 spécifiés dans l'attribut de moteur de la table externe Lakehouse.