Yugabyte : objets et opérations pris en charge

La liste suivante décrit les objets et les opérations pris en charge pour Oracle GoldenGate pour Yugabyte :

• L'extraction Oracle GoldenGate prend en charge le module d'extension yboutput.

• L'identité de réplique CHANGE est le paramètre natif de Yugabyte. Elle est recommandée lors de l'utilisation du module d'extension yboutput, car elle offre de meilleures performances que les autres types d'identité de réplique.

• La réplication bidirectionnelle est prise en charge avec le plug-in yboutput. Lorsque vous utilisez le module d'extension yboutput pour la réplication bidirectionnelle, la table de points de reprise Oracle GoldenGate doit être créée et incluse dans la liste de publication avant de démarrer le processus d'extraction CDC.

  En outre, l'emplacement de réplication ne doit être créé qu'une fois la table de points de reprise créée et ajoutée à la publication.

• La réplication bidirectionnelle est prise en charge avec le plug-in test_decoding. Toutes les tables, y compris les tables de point de reprise, doivent être créées avant d'enregistrer une extraction lors de l'utilisation du module d'extension test_decoding. Dans le cas du module d'extension PGOUTPUT, la table de points de reprise ainsi que toutes les autres tables intéressées doivent être incluses dans la publication avant l'inscription de l'extraction.

Remarque : ne supprimez aucune table, y compris les tables de point de reprise.

• Les opérations de troncation multiples sont prises en charge dans le module d'extension pgoutput/yboutput uniquement.

• Commande Register exécutée avec l'option pgplugintype :

  • L'option pgplugintype est disponible dans l'interface Web et dans le client Admin sous la commande REGISTER EXTRACT. Cette option vous permet de choisir test_decoding ou pgoutput comme module d'extension de décodage logique.

  • Lorsque vous indiquez pgplugintype pgoutput, le module sous-jacent utilise automatiquement le module d'extension yboutput pour enregistrer le processus d'extraction.

  • Si vous n'indiquez aucune valeur pgplugintype, l'extraction CDC s'inscrit à l'aide du module d'extension test_decoding, par défaut.

  • Pour vous inscrire explicitement avec le module d'extension yboutput dans Yugabyte, vous devez indiquer le type de module d'extension pgoutput.

  Syntaxe :

    <pre class="copy"><code>REGISTER EXTRACT *group_name* PGPLUGINTYPE *plugin_option*;</code></pre>
  

  Exemple :

    <pre class="copy"><code>REGISTER EXTRACT ext_yb PGPLUGINTYPE pgoutput;</code></pre>
  

• Le paramètre STREAMINGOPTIONS a été introduit sous TRANLOGOPTIONS. Ce paramètre vous permet de spécifier publication_name pour la commande de démarrage de réplication.

  Exemple :

  TRANLOGOPTIONS STREAMINGOPTIONS (publication_names="my*123,my_publication2,123 pub,my_publication";)

  Les directives et restrictions suivantes doivent être prises en compte lors de l'utilisation de ce paramètre :

  • La ou les publications doivent être créées avant d'enregistrer le traitement d'extraction.

  Les noms de publication ne doivent pas contenir de caractères spéciaux, notamment virgule (,) guillemet simple (') guillemet double (").

  • Plusieurs noms de publication peuvent être indiqués sous forme de liste séparée par des virgules dans publication_names. Exemple :

    TRANLOGOPTIONS STREAMINGOPTIONS (publication_names="my*123,my_publication2,123 pub,my_publication";)

  Le nom de publication final de la liste doit se terminer par un point-virgule ( ;)

Limites de Yugabyte

Tenez compte des limites suivantes pour la base de données Yugabyte, tout en la configurant pour la capture et la distribution :

• Transactions LOB manquantes : lorsqu'un objet LOB (objet volumineux) a une taille comprise entre 200 et 400 Mo, la totalité de la transaction, qu'il s'agisse d'une instruction INSERT ou UPDATE, peut être manquante dans le flux CDC.

• Données non concordantes en aval en raison de plusieurs mises à jour dans la même transaction : lorsque plusieurs mises à jour se produisent au sein de la même transaction, le module CDCSDK de Yugabyte peut ne pas envoyer l'image AFTER correcte si l'identité de réplique de la table est définie sur FULL ou DEFAULT. Cela peut entraîner des divergences de données pour l'image AFTER dans le système en aval.

• La connexion de réplication s'interrompt après le DDL sur les tables répliquées (module d'extension test_decoding) : lorsque vous utilisez le module d'extension test_decoding, toutes les tables de la base de données sont automatiquement incluses dans la liste d'interrogation, par défaut. Si une opération LDD (telle qu'une suppression de table) est effectuée sur une table incluse dans cette liste, le serveur met fin à la connexion de réplication. Toutefois, la suppression de tables qui font partie de la liste d'interrogation n'est pas prise en charge avec le module d'extension test_decoding. Par conséquent, si vous avez besoin de cette flexibilité, vous devez passer au module d'extension yboutput.

  Remarque : avant de supprimer une table, assurez-vous qu'elle ne fait partie d'aucune publication afin d'éviter les erreurs de réplication ou les interruptions de connexion. De même, ne supprimez pas la table de points de reprise Oracle GoldenGate car elle entraînera également la même erreur.

• Expiration de l'emplacement de réplication en raison d'une inactivité prolongée : les emplacements de réplication conservent certaines ressources pour empêcher le nettoyage de la mémoire des enregistrements WAL (journal d'écriture anticipée) requis pour la réplication. Si un créneau reste inactif pendant une longue période, il est marqué comme expiré et les ressources conservées sont libérées. Après expiration, l'emplacement de réplication devient inutilisable et doit être recréé.

  Fenêtre de conservation par défaut :

  • 8 heures à partir de la version 2024.2.1

  • 4 heures en versions antérieures à la version 2024.2.1

  Ceci est un problème connu comme mentionné sur le site de Yugabyte :

  https://github.com/yugabyte/yugabyte-db/issues/27766

  Actions recommandées pour empêcher l'expiration :

  • Activez la fonctionnalité de signal d'activité pour assurer une activité WAL continue et éviter de longues périodes d'inactivité.

  • Configurez les options autostart ou autorestart pour le processus CDC afin qu'il se reconnecte automatiquement au module CDCSDK, ce qui réduit les temps d'arrêt et évite l'expiration des emplacements.

• BatchSQL ne fonctionne pas correctement lorsque BatchMechanism 3 est défini avec le pilote DD de progression, qui est la valeur par défaut du processus de réplication pour Yugabyte. Par conséquent, si vous devez utiliser BatchSQL, vous devez configurer le paramètre DBOPTIONS _BatchMechanism 2 dans le fichier de paramètres de réplication pour une fonctionnalité appropriée. Cette solution de contournement peut être appliquée au processus Replicat dans Oracle GoldenGate 23.10 et versions ultérieures pour Yugabyte.

• Tables pouvant être publiées uniquement : les tables de base persistantes et les tables partitionnées peuvent être incluses dans une publication. Les types d'objet suivants ne peuvent pas faire partie d'une publication :

  • Tables temporaires

  • Tables non consignées

  • Tables étrangères

  • Vues matérialisées

  • Vues régulières

• Impact de la suppression de publication sur l'extraction CDC : si une publication est supprimée alors que l'extraction CDC est toujours en cours d'exécution, il existe un risque d'altération de l'emplacement de réplication, ce qui entraîne son arrêt de fonctionnement. Dans ce cas, l'emplacement de réplication affecté devient inutilisable et la simple recréation de la même publication ne résout pas le problème. Il n'y a pas de solution pour reprendre le flux existant et la seule façon est de créer une nouvelle composition et de l'associer à un nouvel emplacement de réplication.

• Limites avec fuseau horaire (TZ) : le processus d'expéditeur WAL transmet toujours les horodatages validés au format UTC. Si le fuseau horaire de la session Oracle GoldenGate est différent de UTC, des divergences peuvent se produire lors du positionnement par horodatage dans le processus d'extraction CDC. Pour éviter ce problème, vous devez définir la variable d'environnement TZ=UTC au niveau de la couche de déploiement. Cette limitation s'applique spécifiquement au plug-in yboutput.

• Le module d'extension pgoutput n'est pas pris en charge pour Yugabyte.

• La globalisation n'est pas prise en charge avec le module d'extension yboutput

• Clé primaire sur la table : seules les tables avec une clé primaire sont prises en charge pour la transmission en continu CDC en Yugabyte. La table qui n'a pas de clé primaire ne sera pas capturée par l'extraction CDC Oracle GoldenGate.

• Mises à jour de clé primaire en yugaoctet : une mise à jour de clé primaire en yugaoctet est consignée en tant que suppression suivie d'une instruction INSERT. Le processus Extract Oracle GoldenGate affiche les statistiques d'une mise à jour de clé primaire sous la forme DELETE et INSERT uniquement. Bien que les statistiques ne soient pas affichées en tant qu'opération de mise à jour dans les statistiques Extract, les données source et cible ne présentent aucune divergence.

• Comportement d'identité de la réplique : l'identité de la réplique des tables présentes au moment de la création de l'emplacement ne peut pas être modifiée après la création de l'emplacement. Toutefois, l'identité de réplique de toutes les tables créées après la création de l'emplacement peut être définie à l'aide de l'indicateur ysql_yb_default_replica_identity, cdcsdk_publication_list_refresh_interval_secs et csdk_enable_dynamic_table_support tserver. Ces indicateurs doivent être définis dans le maître et dans t-server avant la création de nouvelles tables.

  Par défaut, cdcsdk_publication_list_refresh_interval_secs est défini sur 900 secondes, soit 15 minutes. Vous devez définir cela selon vos besoins. La réduction de sa valeur réduira la nouvelle table à actualiser rapidement dans le module CDCSDK, ce qui aidera Oracle GoldenGate à capturer tous les enregistrements de ces nouvelles tables. L'exemple suivant montre les indicateurs qui sont définis pour les tables créées dynamiquement après la création de la SLOT :

  ysql_yb_default_replica_identity=FULL,cdcsdk_publication_list_refresh_interval_secs=120,cdcsdk_enable_dynamic_table_support=true

• Le positionnement par fin de journal (EOL) ou fin de fichier (EOF) n'est pas pris en charge : au lieu de EOL/EOF, vous pouvez modifier la position de l'emplacement par horodatage actuel, ce qui permet de filtrer les enregistrements existants.

• Opération de troncation : les paramètres tels que GETTRUNCATES/IGNORETRUNCATES ne sont pas pris en charge car la base de données ne permet pas à l'utilisateur de vider la table s'ils sont activés pour la capture des données de modification.

• Conservation WAL : Yugabyte purge normalement les segments WAL après une certaine période. Cela signifie qu'Oracle GoldenGate risque de perdre les données de journal WAL si les journaux sont tronqués lorsque l'extraction est arrêtée pour une durée plus longue. La conservation WAL n'est pas garantie en yugabyte tant que quelques paramètres tels que cdc_intent_retention_ms et cdc_wal_retention_time_secs n'ont pas été ajustés pour conserver les journaux WAL pendant une durée plus longue. Il doit être ajusté dans tous les noeuds ou clusters sur lesquels le processus d'extraction Oracle GoldenGate est en cours d'exécution.

  Les valeurs recommandées sont les suivantes :

  cdc_wal_retention_time_secs=86400

  cdc_intent_retention_ms = 86400000

• Commande UNREGISTER EXTRACT : Oracle GoldenGate utilise la commande UNREGISTER EXTRACT pour supprimer l'emplacement de réplication. Un emplacement de réplication ne peut être supprimé qu'une fois que le client qui l'utilise a été arrêté pendant au moins ysql_cdc_active_replication_slot_window_ms. La valeur par défaut de l'indicateur est de 5 minutes, ce qui signifie que vous devez attendre la fenêtre de temps maximale pendant laquelle un emplacement de réplication peut rester inactif avant d'être considéré comme obsolète.

  Dans le cas d'une configuration de cluster, ce paramètre doit être ajusté dans tous les noeuds ayant la même valeur.

• Limites BLOB/CLOB : le type de données tel que text/image est limité à la capture de seulement 200 Mo de données. La taille de ligne ne doit pas dépasser 32 Mo et chaque colonne contenant les données LOB doit être conservée jusqu'à 2 Mo.

  https://docs.yugabyte.com/stable/develop/best-practices-ysql/#row-limite de taille

• Limites relatives à SAVEPOINT et à l'annulation dans les opérations LMD : l'extraction CDC Oracle GoldenGate ne prend pas en charge les opérations d'annulation SAVEPOINT. Le module d'extension CDC test_decoding ne respecte pas les commandes ROLLBACK TO SAVEPOINT. Par conséquent, les enregistrements qui auraient dû être exclus en raison d'une annulation sont toujours capturés et traités par le processus Extract.

  Ce comportement est une limitation connue du module SDK CDC de Yugabyte. Pour en savoir plus, reportez-vous aux liens suivants :

  https://yugabyte.atlassian.net/browse/DB-11714

  https://docs.yugabyte.com/stable/develop/change-data-capture/using-logical-replication/#limitations

• Limitation de la suppression de table : une fois qu'un emplacement est créé, l'utilisateur ne doit supprimer aucune table de la base de données tant que l'emplacement n'est pas supprimé. Si l'emplacement est actif et que l'utilisateur tente de supprimer une table de la base de données, l'extraction CDC ne pourra pas capturer d'enregistrements à partir d'autres tables CDC faisant partie de la réplication. En outre, il est suggéré que lorsque l'extraction CDC est en cours d'exécution, l'utilisateur ne doit supprimer aucune table de la base de données dans laquelle le créneau est créé. Si ce n'est pas le cas, l'extraction CDC abandonne avec une erreur de déconnexion similaire à la suivante :

  Error: The server has ended the streaming connection.

• Limitation sur statement_timeout : le paramètre Yugabyte statement_timeout ne doit pas être modifié au niveau de l'utilisateur ou de la base de données et doit être conservé par défaut. Si elle est définie sur une valeur inférieure, l'extraction CDC ne pourra pas lire les enregistrements à partir de WAL. Si nécessaire, il doit toujours être défini au niveau de la session uniquement.

• La création d'un emplacement dans le noeud de réplique en mode lecture seule n'est pas prise en charge : l'extraction CDC ne pourra pas capturer les enregistrements à partir du noeud de réplique. En effet, les versions que nous prenons en charge comme 2024.2.1.0 ou 2024.2.2.0 sont construites sur PostgreSQL 11.2, qui ne prend pas en charge la création de l'emplacement dans le noeud de réplique.