MySQL : types de données, objets et opérations pris en charge

Cette section contient des informations sur la prise en charge d'Oracle GoldenGate sur MySQL Database.

Oracle GoldenGate pour MySQL prend en charge la mise en correspondance, le filtrage et la transformation des données source, sauf indication contraire dans ce document, ainsi que la réplication des données dérivées d'autres bases de données source prises en charge par Oracle GoldenGate, en bases de données MySQL.

Types de données pris en charge par Oracle GoldenGate for MySQL

Oracle GoldenGate pour MySQL prend en charge les types de données suivants :

• BLOB

• BIGINT

• BINARY

• BIT(M)

• CHAR

• DATE

• DATETIME

• DECIMAL

• DOUBLE

• ENUM

• FLOAT

• INT

• JSON

• LONGBLOB

• LONGTEXT

• MEDIUMBLOB

• MEDIUMINT

• MEDIUMTEXT

• SMALLINT

• TEXT

• TIME

• TIMESTAMP

• TINYBLOB

• TINYINT

• TINYTEXT

• VARBINARY

• VARCHAR

• VECTOR

• YEAR

Limites et clarifications

Lors de l'exécution d'Oracle GoldenGate pour MySQL, tenez compte des points suivants :

• Les index fonctionnels ne sont pas pris en charge pour la capture ou la livraison.

• Oracle GoldenGate ne prend pas en charge les types BLOB ou TEXT lorsqu'il est utilisé en tant que clé primaire.

• Oracle GoldenGate prend en charge une plage de type TIME allant de 00:00:00 à 23:59:59.

• Oracle GoldenGate prend en charge les données d'horodatage de 0001/01/03:00:00:00 à 9999/12/31:23:59:59. Si un horodatage est converti de GMT en heure locale, ces limites s'appliquent également à l'horodatage résultant. Selon le fuseau horaire, la conversion peut ajouter ou soustraire des heures, ce qui peut entraîner un dépassement de la limite inférieure ou supérieure prise en charge.

• Oracle GoldenGate ne prend pas en charge les dates négatives.

• La prise en charge de la plage et de la précision pour les nombres à virgule flottante dépend de la machine hôte. En général, la précision est de 16 chiffres significatifs, mais vous devez consulter la documentation de la base de données pour déterminer les approximations attendues. Oracle GoldenGate arrondit ou tronque les valeurs dépassant la précision prise en charge.

• Lorsque vous utilisez le type ENUM dans une valeur sql_mode non stricte, la valeur sql_mode non stricte ne vous empêche pas de saisir une valeur ENUM non valide et une erreur est renvoyée. Pour éviter cette situation, effectuez l'une des opérations suivantes :

  • Utilisez sql_mode en tant que STRICT et redémarrez l'extraction. Cela empêche les utilisateurs de saisir des valeurs non valides pour l'un des types de données. Un utilisateur IE peut uniquement saisir des valeurs valides pour ces types de données.

  • Continuez à utiliser sql_mode non strict, mais n'utilisez pas les types de données ENUM.

  • Continuez à utiliser sql_mode non strict et utilisez les types de données ENUM avec des valeurs valides dans la base de données. Si vous indiquez des valeurs non valides, la base de données les acceptera silencieusement et le processus Extract abandonnera.

• La table avec une seule colonne n'est pas prise en charge pour le type de données JSON. L'extraction abandonnera au cas où elle serait configurée pour une table ayant une seule colonne de type de données JSON.

• Le type de données JSON ne prend pas en charge le CDR. Le message suivant est consigné dans le fichier de rapport si GETBEFORECOLS est configuré et que la table comporte des colonnes de type de données JSON :

  INFO OGG-06556 The following columns will not be considered for CDR

  Les limitations de la CDR s'appliquent aux cas où GETBEFORECOLS et COMPARECOLS sont utilisés.

• L'extraction MySQL n'abandonne pas et traite les valeurs de colonne ENUM qui ne sont pas définies dans la définition de table en tant que 'invalid_enum'.

Types de données MySQL non pris en charge

Oracle GoldenGate pour MySQL ne prend pas en charge les types de données suivants :

Tous les types spatiaux (GEOMETRY, etc.) et SET.

Tous les types GEOMETRY suivants ne sont pas pris en charge dans MySQL :

• POINT

• LINGE DE MAISON

• POLYGONE

• MULTIPOINT

• MULTILINER

• MULTIPOLYGONE

• GEOMCOLLECTION Remarque : L'extraction est abandonnée si elle est configurée pour la capture à partir de tables qui contiennent l'un des types de données non pris en charge. Assurez-vous donc que l'extraction n'est pas configurée pour la capture à partir de tables contenant des colonnes de types de données non pris en charge.

Objets et opérations pris en charge pour MySQL

Oracle GoldenGate pour MySQL prend en charge les opérations et objets suivants :

• Oracle GoldenGate prend en charge les opérations LMD suivantes sur les tables transactionnelles des bases de données source et cible :

  • Insérer une opération

  • Opération de mise à jour (compressée incluse)

  • Opération de suppression (compressée incluse)

  • Opération de troncation

• Oracle GoldenGate prend en charge l'extraction et la réplication des opérations LDD (langage de définition de données).

• Oracle GoldenGate prend en charge les tables transactionnelles jusqu'à la taille de ligne complète et le nombre maximal de colonnes prises en charge par MySQL et le moteur de stockage de base de données utilisé. InnoDB prend en charge jusqu'à 1017 colonnes.

• Oracle GoldenGate prend en charge l'extraction des colonnes générées.

• La réplication n'est pas autorisée sur une colonne générée MySQL. Par conséquent, toutes les données de colonne générées source doivent être mises en correspondance avec une colonne non générée.

• Oracle GoldenGate prend en charge l'attribut de colonne AUTO_INCREMENT. La valeur d'incrément est capturée à partir du journal binaire par le processus Extract et appliquée à la table cible lors d'une opération d'insertion Replicat.

• Oracle GoldenGate peut fonctionner simultanément avec la réplication native MySQL.

• Oracle GoldenGate prend en charge la fonctionnalité DYNSQL pour MySQL.

Remarque : les transactions XA ne sont pas prises en charge pour la capture et les transactions XA journalisées dans binlog entraînent l'abandon de l'extraction. Par conséquent, vous ne devez pas utiliser de transactions XA sur une base de données configurée pour la capture. Si des transactions XA sont utilisées pour des bases de données non configurées pour la capture Oracle GoldenGate, excluez ces bases de données de la connexion aux journaux binaires MySQL à l'aide du paramètre binlog-ignore-db dans le fichier de configuration du serveur MySQL.

Les limites de la prise en charge de la table de signal d'activité automatique sont les suivantes :

• Assurez-vous que la base de données dans laquelle la table de signal d'activité doit être créée existe déjà pour éviter toute erreur lors de l'ajout de la table de signal d'activité.

• Dans la vue de décalage de l'historique des signaux d'activité, les informations des champs tels que heartbeat_received_ts, incoming_heartbeat_age et outgoing_heartbeat_age sont affichées par rapport à l'heure système. Vous devez vous assurer que l'heure du système d'exploitation est configurée avec les informations de fuseau horaire correctes et actuelles.

• La fonction Position by End of File (EOF) est prise en charge dans MySQL. L'extraction Oracle GoldenGate pour MySQL détecte la position correspondant à la fin du fichier et démarre la lecture de transactions à partir de ce dernier. La position EOF n'est pas exacte si des données ont été écrites continuellement dans le journal binaire.

  Le processus Extract est ajouté et modifié à l'aide de :

  ADD EXTRACT *group_name*, TRANLOG, EOF

  ALTER EXTRACT *group_name*, EOF

Détails de la prise en charge des objets et des opérations dans MySQL DDL

Voici la liste des objets MySQL et des types d'opération pris en charge par Oracle GoldenGate pour la capture et la réplication des opérations LDD.

• La réplication LDD pour MySQL est uniquement prise en charge entre les bases de données MySQL en tant que sources et cibles.

• L'extraction et la réplication des opérations LDD sont prises en charge pour les versions MySQL 8.0 et ultérieures. Les opérations LDD prises en charge sont les suivantes :

  • CREATE TABLE (à l'exclusion de CREATE TABLE AS SELECT)

  • DROP TABLE

  • TRUNCATE TABLE (Prise en charge à l'aide de GETTRUNCATES)

  • ALTER TABLE TRUNCATE PARTITION

  • ALTER TABLE ADD COLUMN

  • ALTER TABLE ADD COLUMN AFTER

  • ALTER TABLE DROP COLUMN

  • ALTER TABLE MODIFY COLUMN (COLUMN_NAME, TYPE, SIZE)

  • ALTER TABLE ADD (constraints) PRIMARY KEY

  • ALTER TABLE DROP PRIMARY KEY

• Pour MySQL 8.0, la capture LDD locale et distante est prise en charge.

• Les opérations TRUNCATE sont prises en charge en tant que DML via le paramètre d'extraction et de réplication GETTRUNCATES et ne nécessitent pas de configuration d'Oracle GoldenGate pour la prise en charge de DDL MySQL.

• La réplication LDD n'est pas prise en charge dans une configuration bidirectionnelle Oracle GoldenGate.

• La réplication LDD n'est pas prise en charge pour les services de base de données cloud où le paramètre de base de données binlog_row_metadata ne peut pas être défini sur FULL.

Objets et opérations non pris en charge pour MySQL

Oracle GoldenGate pour MySQL ne prend pas en charge les objets et opérations suivants :

• colonnes invisibles

• Fonctionnalité BATCHSQL d'Oracle GoldenGate pour la réplication.

• Les jeux de caractères suivants ne sont pas pris en charge :

  • ULIB_CS_ARMSCII8, /* National américain 166-9 */

  • ULIB_CS_GEOSTD8, /* Norme géogienne */

  • ULIB_CS_KEYBCS2, /* Kemennicky MS-DOS

• La capture des données LOB NLS à l'aide des options FETCHMOCOLS et FETCHMODCOLEXCEPT TABLE n'est pas prise en charge lorsque le langage DDL est activé.

• Modification du nom des tables.

• Les instructions LDD contenues dans les procédures stockées ne sont pas prises en charge.

• Lorsque le fuseau horaire du serveur d'installation Oracle GoldenGate ne correspond pas au fuseau horaire du serveur de base de données source, les données TIMESTAMP envoyées à la base de données cible diffèrent de la base de données source. Pour les installations de microservices Oracle GoldenGate, quels que soient les fuseaux horaires identiques, le processus Extract résout le fuseau horaire en UTC. Déterminez le fuseau horaire de la base de données source en exécutant la requête suivante :

  select @@system_time_zone;

  Cette action renvoie une valeur de fuseau horaire, telle que PDT.

  Dans le déploiement, créez une variable contenant l'extraction source, appelée TZ, et définissez-la sur la valeur du fuseau horaire de la base de données source. Ensuite, arrêtez les processus Oracle GoldenGate en cours d'exécution, redémarrez le service d'administration, puis démarrez les extractions et les réplications.

• L'extraction et la réplication à partir et vers des vues ne sont pas prises en charge.

• Les transactions appliquées par l'esclave sont journalisées dans les journaux de relais et non dans le fichier binlog de l'esclave. Si vous voulez qu'un esclave écrive les transactions binlog qu'il reçoit du maître, vous devez démarrer l'esclave de réplication avec l'option de mise à jour de l'esclave de journal 1 dans my.cnf. Ceci s'ajoute aux autres paramètres de journalisation binaire. Une fois que les transactions du maître se trouvent dans le fichier binlog de l'esclave, vous pouvez configurer une capture régulière sur l'esclave pour capturer et traiter le fichier binlog de l'esclave.

Limites des objets et des opérations SingleStoreDB

Oracle GoldenGate pour MySQL prend désormais en charge SingleStoreDB et SingleStoreDB Cloud, mais avec les limitations suivantes :

• La réplication vers des vues dans SingleStoreDB n'est pas prise en charge, car seules les tables de base sont accessibles en écriture.

• Les mises à jour des colonnes qui font partie de la clé SHARD ne sont pas prises en charge.

• Les mises à jour de clé primaire sur les tables sans clé SHARD explicite ne sont pas prises en charge. En effet, SingleStoreDB affecte la clé primaire en tant que clé SHARD dans ce cas et les mises à jour des colonnes de clé SHARD ne sont pas autorisées.

• Le comportement DBOPTIONS LIMITROWS de la réplication pour les tables SingleStoreDB sans clé primaire ou unique répartie entre plusieurs partitions n'est pas pris en charge.

• Les options de paramètre DBOPTIONS LIMITROWS et NOLIMITROWS ne sont pas prises en charge pour SingleStoreDB.

• SingleStoreDB ne prend pas en charge les transactions entre bases de données, ce qui signifie qu'une réplication ne peut prendre en charge que la mise en correspondance avec un seul schéma/une seule base de données. Cela inclut les mappings pour les tables de point de reprise et de signal d'activité. Ces objets doivent donc être créés sous le même schéma/base de données que les tables utilisateur à répliquer.

Schémas système

Les schémas ou objets suivants ne sont pas automatiquement répliqués par Oracle GoldenGate, sauf s'ils sont explicitement indiqués sans caractère générique.

• MySQL

  • 'information_schema'

  • 'performance_schema'

  • 'mysql'

  • 'sys'

• SingleStore

  • 'information_schema'

  • 'cluster'

  • 'memsql'