Formats de stockage des données dans les files d'attente de messages - Data Transmission Service

Formats de stockage des données

DTS prend en charge les trois formats de stockage suivants pour les données écrites dans une file d'attente de messages :

DTS Avro : format de sérialisation qui convertit les structures de données ou les objets dans un format facile à stocker ou à transmettre.
Shareplex Json : lorsque le logiciel de réplication de données SharePlex lit les données depuis une base de données source et les écrit dans une file d'attente de messages, celles-ci sont stockées au format Shareplex Json.
Canal Json : Canal analyse les journaux incrémentiels d'une base de données et transmet les données incrémentielles à une file d'attente de messages. Les données sont stockées au format Canal Json.

DTS Avro

Analysez les données selon la définition du schéma DTS Avro. Pour plus d'informations, consultez la définition du schéma DTS Avro et l'exemple de désérialisation DTS Avro.

Remarque

Au format DTS Avro, les instructions DDL sont de type String.

Shareplex Json

Description des paramètres

Paramètre

Description

time

L'heure de validation de la transaction dans la base de données. Le format est yyyy-MM-ddTHH:mm:ssZ (UTC).

userid

L'ID de l'utilisateur ayant validé la transaction.

op

Le type d'opération sur les données. Les valeurs possibles sont INSERT, UPDATE, DELETE, TRUNCATE, DROP COLUMN, UPDATE BEFORE et UPDATE AFTER.

scn

Numéro de changement système (SCN). Il identifie la version d'une transaction validée à un instant donné dans la base de données. Chaque transaction validée reçoit un SCN unique.

rowid

Valeur d'adresse relativement unique permettant de localiser un enregistrement dans la base de données.

trans

L'ID de la transaction.

seq

Le numéro ordinal de l'opération au sein de la transaction. La valeur commence à 1.

size

Le nombre total d'opérations dans la transaction.

table

Le nom de la table.

idx

L'index de l'opération au sein de la transaction. Le format est seq/size. Par exemple, 1/11 indique qu'il s'agit de la première opération d'une transaction contenant 11 opérations.

posttime

L'heure de validation de la transaction dans la base de données de destination.

Exemples

Insertion de données

{
    "meta": {
        "time": "2017-06-16T14:24:34", 
        "userid": 84,                                    
        "op": "ins",                                   
          "scn": "14589063118712",                  
          "rowid": "AAATGpAAIAAItcIAAA",      
        "trans": "7.0.411499",                 
        "seq": 1,                                          
        "size": 11,                                         
        "table": "CL_BIZ1.MIO_LOG",       
          "idx": "1/11",                                       
        "posttime": "2017-06-16T14:33:52"
    },
    "data": {
        "MIO_LOG_ID": "32539737"
     }
}

Mise à jour des données

{
    "meta": {
        "time": "2017-06-16T15:38:13",
        "userid": 84,
        "op": "upd",                             
        "table": "CL_BIZ1.MIO_LOG"
        ….
    },
    "data": {                                          
        "CNTR_NO": "1171201606"
    },
    "key": {                                            
        "MIO_LOG_ID": "32537893",
        "PLNMIO_REC_ID": "31557806",
        "POL_CODE": null,
        "CNTR_TYPE": null,
        "CNTR_NO": "1171201606syui26"
    }
}

Suppression de données

{
    "meta": {
        "time": "2017-06-16T15:51:35",
        "userid": 84,
        "op": "del",                      
     },
    "data": {                                    
        "MIO_LOG_ID": "32539739",
        "PLNMIO_REC_ID": "31557806",
        "POL_CODE": null,
        "CNTR_TYPE": null,
        "CG_NO": null
     }
}

Canal Json

Remarque

Si vous activez l'option Split message delivery after partition key update, Kafka délivre un message DELETE et un message INSERT lorsqu'une clé de partition est modifiée. Kafka sélectionne la partition pour chaque message en fonction de sa valeur de clé de partition respective.

Exemple : la clé de partition id a pour valeur 1. Le message est délivré à partition-1. La liste suivante décrit les différences avant et après l'activation de l'option Split message delivery after partition key update.

Activé : lorsque vous exécutez la commande UPDATE SET id = 2 WHERE id = 1 dans la base de données source, un message DELETE avec id=1 est délivré à partition-1, et un message INSERT avec id=2 est délivré à partition-2.
Désactivé : un seul message UPDATE est délivré à partition-1. L'opération UPDATE sélectionne la partition pour la livraison en fonction de la valeur avant la modification.

Description des métriques

Paramètre	Description
`database`	Le nom de la base de données.
`es`	L'heure d'exécution de l'opération dans la base de données source. Il s'agit d'un horodatage UNIX de 13 chiffres en millisecondes. Remarque Le temps d'exécution réel est exprimé en secondes. Trois zéros sont ajoutés pour convertir l'unité en millisecondes. Utilisez un moteur de recherche pour trouver un outil de conversion d'horodatage UNIX.
`id`	Le numéro de série de l'opération. Remarque Il est généré à partir de l'horodatage et d'un décalage interne DTS. Il peut vous aider à déterminer l'ordre des enregistrements.
`isDdl`	Indique si l'opération est une opération DDL. true : Oui. false : Non.
`mysqlType`	Le type de données du champ. Remarque Les paramètres des types de données, tels que la précision, ne sont pas pris en charge.
`old` et `data`	Les données avant ou après la modification. Remarque Pour les instances de synchronisation ou de migration créées avant le 20 mars 2022, la valeur de old correspond aux données après la modification, et la valeur de `data` correspond aux données avant la modification. Par défaut, la valeur de `old` inclut toutes les colonnes, pas seulement les colonnes modifiées. Pour s'aligner sur la communauté open source, pour les instances créées ou redémarrées le 20 mars 2022 ou ultérieurement, la valeur de `data` correspond aux données après la modification, et la valeur de `old` correspond aux données avant la modification.
`pkNames`	Le nom de la clé primaire.
`sql`	L'instruction SQL.
`sqlType`	Le type de champ transformé. La valeur est identique à celle de dataTypeNumber. Pour plus d'informations, consultez la section Correspondance entre les types de champs et les valeurs dataTypeNumber.
`table`	Le nom de la table.
`ts`	L'heure à laquelle l'opération a commencé à écrire les données dans la base de données de destination. Il s'agit d'un horodatage UNIX de 13 chiffres en millisecondes. Remarque Utilisez un moteur de recherche pour trouver un outil de conversion d'horodatage UNIX.
`type`	Le type d'opération, tel que DELETE, UPDATE ou INSERT. Remarque Pour les tâches de synchronisation ou de migration de données complètes, la valeur est fixée à INIT.
`gtid`	Identifiant global de transaction (GTID). Un GTID est globalement unique. Chaque transaction correspond à un GTID. Remarque DTS ne prend pas en charge la synchronisation du champ GTID. La valeur de ce champ est NULL par défaut.

Exemples

Mise à jour des données

Remarque

Pour les instances de synchronisation ou de migration créées avant le 20 mars 2022, lorsqu'une instruction DELETE d'une table source est synchronisée ou migrée vers Kafka, le champ old contient les données et le champ data est nul. Pour s'aligner sur la communauté open source, pour les instances créées ou redémarrées le 20 mars 2022 ou ultérieurement, le champ data contient les données et le champ old est nul.

Instances de synchronisation ou de migration créées avant le 20 mars 2022

{
    "old": [
        {
            "shipping_type": "aaa"
        }
    ], 
    "database": "dbname", 
    "es": 1600161894000, 
    "id": 58, 
    "isDdl": false, 
    "mysqlType": {
        "id": "bigint", 
        "shipping_type": "varchar"
    }, 
    "pkNames": [
        "id"
    ], 
    "sql": "", 
    "sqlType": {
        "id": -5, 
        "shipping_type": 12
    }, 
    "table": "tablename", 
    "ts": 1600161894771, 
    "type": "DELETE"
}

Instances de synchronisation ou de migration créées ou redémarrées le 20 mars 2022 ou ultérieurement

{
    "data": [
        {
            "id": "500000287", 
            "shipping_type": null
        }
    ], 
    "database": "dbname", 
    "es": 1600161894000, 
    "id": 58, 
    "isDdl": false, 
    "mysqlType": {
        "id": "bigint", 
        "shipping_type": "varchar"
    }, 
    "pkNames": [
        "id"
    ], 
    "sql": "", 
    "sqlType": {
        "id": -5, 
        "shipping_type": 12
    }, 
    "table": "tablename", 
    "ts": 1600161894771, 
    "type": "DELETE"
}

Opération DDL

{
    "database":"dbname", // The name of the database for synchronization or migration.
    "es":1600161894000, // The time when the source data was written to the binary log.
    "id":58, // The offset in the DTS cache.
    "isDdl":true, // Specifies whether to synchronize or migrate DDL statements.
    "sql":"eg:createxxx", // The DDL statement from the binary log.
    "table":"tablename", // The name of the table for synchronization or migration.
    "ts":1600161894771, // The time when DTS wrote the data to the destination.
    "type":"DDL"
}