Partager via

Copier des données de MySQL à l’aide d’Azure Data Factory ou Synapse Analytics

  • Article

S’APPLIQUE À : Azure Data Factory Azure Synapse Analytics

Conseil

Essayez Data Factory dans Microsoft Fabric, une solution d’analyse tout-en-un pour les entreprises. Microsoft Fabric couvre tous les aspects, du déplacement des données à la science des données, en passant par l’analyse en temps réel, l’aide à la décision et la création de rapports. Découvrez comment démarrer un nouvel essai gratuitement !

Cet article décrit comment utiliser l’activité de copie dans des pipelines Azure Data Factory et Synapse Analytics pour copier des données à partir d’une base de données MySQL. Il s’appuie sur l’article Vue d’ensemble de l’activité de copie.

Notes

Pour copier des données depuis ou vers le service Azure Database pour MySQL, utilisez le connecteur spécialisé Azure Database pour MySQL.

Important

La version 2.0 du connecteur MySQL offre une meilleure prise en charge native de MySQL. Si vous utilisez la version 1.0 du connecteur MySQL dans votre solution, veuillez mettre à jour votre connecteur MySQL car la version 1.0 est en phase de fin de prise en charge. Pour plus de détails sur les différences entre la version 2.0 et la version 1.0, reportez-vous à cette section.

Fonctionnalités prises en charge

Ce connecteur MySQL est pris en charge pour les fonctionnalités suivantes :

Fonctionnalités prises en charge IR
Activité de copie (source/-) ① ②
Activité de recherche ① ②

① Runtime d’intégration Azure ② Runtime d’intégration auto-hébergé

Pour obtenir la liste des banques de données prises en charge en tant que sources ou récepteurs par l’activité de copie, consultez le tableau Banques de données prises en charge.

Ce connecteur prend en charge MySQL version 5.5, 5.6, 5.7, 8.0, 8.1 et 8.2 sous le connecteur MySQL version 2.0 et 5.6, 5.7 et 8.0 pour la version 1.0.

Prérequis

Si votre magasin de données se trouve dans un réseau local, un réseau virtuel Azure ou un cloud privé virtuel Amazon, vous devez configurer un runtime d’intégration auto-hébergé pour vous y connecter.

Si votre magasin de données est un service de données cloud managé, vous pouvez utiliser Azure Integration Runtime. Si l’accès est limité aux adresses IP qui sont approuvées dans les règles de pare-feu, vous pouvez ajouter les adresses IP Azure Integration Runtime dans la liste d’autorisation.

Vous pouvez également utiliser la fonctionnalité de runtime d’intégration de réseau virtuel managé dans Azure Data Factory pour accéder au réseau local sans installer et configurer un runtime d’intégration auto-hébergé.

Pour plus d’informations sur les mécanismes de sécurité réseau et les options pris en charge par Data Factory, consultez Stratégies d’accès aux données.

Le runtime d’intégration fournit un pilote MySQL intégré à partir de la version 3.7. Ainsi, vous n’avez pas besoin d’installer manuellement un pilote.

Prise en main

Pour effectuer l’activité Copie avec un pipeline, vous pouvez vous servir de l’un des outils ou kits SDK suivants :

Créer un service lié à MySQL à l’aide de l’interface utilisateur

Utilisez les étapes suivantes pour créer un service lié à MySQL dans l’interface utilisateur du portail Azure.

  1. Accédez à l’onglet Gérer dans votre espace de travail Azure Data Factory ou Synapse et sélectionnez Services liés, puis cliquez sur Nouveau :

  2. Recherchez MySQL et sélectionnez le connecteur MySQL.

    Sélectionnez le connecteur MySQL.

  3. Configurez les informations du service, testez la connexion et créez le nouveau service lié.

    Configurez un service lié à MySQL.

Informations de configuration des connecteurs

Les sections suivantes fournissent des informations sur les propriétés utilisées pour définir les entités Data Factory spécifiques du connecteur MySQL.

Propriétés du service lié

Si vous utilisez la version 2.0, les propriétés suivantes sont prises en charge pour le service lié MySQL :

Propriété Description Obligatoire
type La propriété type doit être définie sur : MySql Oui
driverVersion Version du pilote lorsque vous sélectionnez la version 2.0. La valeur est v2. Oui
server Nom de votre serveur MySQL. Oui
port Numéro de port à connecter au serveur MySQL. Non
database Votre nom de la base de données MySQL. Oui
username Votre nom d’utilisateur. Oui
mot de passe Mot de passe du nom d’utilisateur. Marquez ce champ comme SecureString pour le stocker en toute sécurité. Vous pouvez également référencer un secret stocké dans Azure Key Vault. Oui
sslMode Cette option spécifie si le pilote utilise le chiffrement TLS et la vérification lors de la connexion à MySQL. Par exemple, SSLMode=<0/1/2/3/4>.
Options : DISABLED (0) / PREFERRED (1) (par défaut) / REQUIRED (2) / VERIFY_CA (3) / VERIFY_IDENTITY (4)		 Oui
useSystemTrustStore Cette option indique s’il faut utiliser un certificat d’autorité de certification provenant du magasin de confiance du système ou d’un fichier PEM spécifié. Par exemple UseSystemTrustStore=<0/1> ;
Options : Enabled (1) / Disabled (0) (par défaut)		 Non
connectVia Runtime d’intégration à utiliser pour la connexion à la banque de données. Pour plus d’informations, consultez la section Conditions préalables. À défaut de spécification, le runtime d’intégration Azure par défaut est utilisé. Non
Propriétés de connexion supplémentaires
allowZeroDateTime La spécification de cette valeur de propriété sur true permet de récupérer la valeur 0000-00-00 de date spéciale « zéro » de la base de données. Si la valeur est définie sur false (valeur par défaut), les colonnes de date sont retournées en tant que valeurs DateHeure, ce qui signifie que 0000-00-00 ne peut pas être récupéré.

MySQL vous permet de stocker une valeur « zéro » de 0000-00-00 sous la forme d’une « date factice ». Dans certains cas, cette fonctionnalité est plus pratique que l’utilisation de valeurs nulles et utilise moins de données et d’espace d’index. Pour interdire 0000-00-00 dans mySQL, activez le mode NO_ZERO_DATE. Pour plus d’informations, consultez cet article.		 Non
connectionTimeout Durée d’attente (en secondes) d’une connexion au serveur avant l’arrêt de la tentative, et la génération d’une erreur. Non
convertZeroDateTime Définissez la valeur sur true pour renvoyer DateTime.MinValue pour les colonnes Date ou DateHeure qui ont des valeurs non autorisées. Non
guidFormat Détermine le type de colonne (le cas échéant) qui doit être lu en tant que GUID. Accédez à cet article pour obtenir la description de chaque type de colonne en recherchant cette propriété.

La version 2.0 traite Char(36) comme type GUID par défaut pour de meilleures performances. Le connecteur traite les champs Char(36) en tant que GUID pour faciliter la gestion des bases de données. Ce traitement simplifie les opérations telles que l’insertion, la mise à jour et la récupération des valeurs de GUID, en s’assurant qu’elles sont gérées de manière cohérente en tant qu’objets GUID dans le code de l’application au lieu de chaînes simples. Ce comportement est particulièrement utile dans les scénarios où les GUID sont utilisés comme clés primaires ou identificateurs uniques et offre de meilleures performances. Si vous n’avez pas besoin de ce paramètre par défaut, vous pouvez configurer guidFormat=none dans la propriété de connexion.		 Non
sslCert Le chemin d’accès au fichier de certificat SSL du client au format PEM. SslKey doit également être spécifié. Non
sslKey Le chemin d’accès à la clé privée SSL du client au format PEM. SslCert doit également être spécifié. Non
treatTinyAsBoolean Lorsque la valeur est vrai, les valeurs tinyint(1) sont retournées en tant que booléen. La définition de cette propriété sur false entraîne le renvoi de tinyint(1) en tant que SByte/Byte.

La version 2.0 traite tinyint(1) comme type booléen par défaut. Pour plus d’informations, consultez cet article. Pour permettre au connecteur de retourner un tiny en tant que numérique, définissez treatTinyAsBoolean=false dans les propriétés de connexion.		 Non

Exemple :

{
    "name": "MySQLLinkedService",
    "properties": {
        "type": "MySql",
        "typeProperties": {
             "server": "<server>",
             "port": 3306,
             "database": "<database>",
             "username": "<username>",
             "password": {
                "type": "SecureString",
                "value": "<password>"
             },
             "sslmode": <sslmode>,
             "usesystemtruststore": <UseSystemTrustStore>,
             "driverVersion": "v2"
        },
        "connectVia": {
            "referenceName": "<name of Integration Runtime>",
            "type": "IntegrationRuntimeReference"
        }
    }
}

Exemple : stockage du mot de passe dans Azure Key Vault

{
    "name": "MySQLLinkedService",
    "properties": {
        "type": "MySql",
        "typeProperties": {
            "server": "<server>",
            "port": 3306,
            "database": "<database>",
            "username": "<username>",
            "sslmode": <sslmode>,
            "usesystemtruststore": <UseSystemTrustStore>,
            "password": { 
                "type": "AzureKeyVaultSecret", 
                "store": { 
                    "referenceName": "<Azure Key Vault linked service name>", 
                    "type": "LinkedServiceReference" 
                }, 
                "secretName": "<secretName>" 
            },
            "driverVersion": "v2"
        },
        "connectVia": {
            "referenceName": "<name of Integration Runtime>",
            "type": "IntegrationRuntimeReference"
        }
    }
}

Si vous utilisez la version 1.0, les propriétés suivantes sont prises en charge :

Propriété Description Obligatoire
type La propriété type doit être définie sur : MySql Oui
connectionString Spécifiez les informations nécessaires pour vous connecter à l’instance d’Azure Database pour MySQL.
Vous pouvez également définir un mot de passe dans Azure Key Vault et extraire la configuration password de la chaîne de connexion. Pour plus d’informations, reportez-vous aux exemples suivants et à l’article Stocker des informations d’identification dans Azure Key Vault.		 Oui
connectVia Runtime d’intégration à utiliser pour la connexion à la banque de données. Pour plus d’informations, consultez la section Conditions préalables. À défaut de spécification, le runtime d’intégration Azure par défaut est utilisé. Non

Voici un exemple de chaîne de connexion typique : Server=<server>;Port=<port>;Database=<database>;UID=<username>;PWD=<password>. Selon votre cas de figure, vous pouvez définir d’autres propriétés :

Propriété Description Obligatoire
sslMode Cette option spécifie si le pilote utilise le chiffrement TLS et la vérification lors de la connexion à MySQL. Par exemple, SSLMode=<0/1/2/3/4>.
Options : DISABLED (0) / PREFERRED (1) (par défaut) / REQUIRED (2) / VERIFY_CA (3) / VERIFY_IDENTITY (4)		 Oui
SSLCert Chemin d’accès complet et nom d’un fichier. pem contenant le certificat SSL utilisé pour prouver l’identité du client.
Pour spécifier une clé privée à des fins de chiffrement de ce certificat avant de l’envoyer au serveur, utilisez la propriété SSLKey.		 Oui, si vous utilisez la vérification SSL bidirectionnelle.
SSLKey Chemin d’accès complet et nom d’un fichier contenant la clé privée utilisée pour chiffrer le certificat côté client lors de la vérification SSL bidirectionnelle. Oui, si vous utilisez la vérification SSL bidirectionnelle.
useSystemTrustStore Cette option indique s’il faut utiliser un certificat d’autorité de certification provenant du magasin de confiance du système ou d’un fichier PEM spécifié. Par exemple UseSystemTrustStore=<0/1> ;
Options : Enabled (1) / Disabled (0) (par défaut)		 Non

Exemple :

{
    "name": "MySQLLinkedService",
    "properties": {
        "type": "MySql",
        "typeProperties": {
            "connectionString": "Server=<server>;Port=<port>;Database=<database>;UID=<username>;PWD=<password>"
        },
        "connectVia": {
            "referenceName": "<name of Integration Runtime>",
            "type": "IntegrationRuntimeReference"
        }
    }
}

Propriétés du jeu de données

Pour obtenir la liste complète des sections et propriétés disponibles pour la définition de jeux de données, consultez l’article sur les jeux de données. Cette section fournit la liste des propriétés prises en charge par le jeu de données MySQL.

Pour copier des données à partir de MySQL, les propriétés suivantes sont prises en charge :

Propriété Description Obligatoire
type La propriété type du jeu de données doit être définie sur : MySqlTable Oui
tableName Nom de la table dans la base de données MySQL. Non (si « query » dans la source de l’activité est spécifié)

Exemple

{
    "name": "MySQLDataset",
    "properties":
    {
        "type": "MySqlTable",
        "typeProperties": {},
        "schema": [],
        "linkedServiceName": {
            "referenceName": "<MySQL linked service name>",
            "type": "LinkedServiceReference"
        }
    }
}

Si vous utilisiez un dataset typé RelationalTable, il reste pris en charge tel quel, mais nous vous suggérons d’utiliser désormais le nouveau dataset.

Propriétés de l’activité de copie

Pour obtenir la liste complète des sections et des propriétés disponibles pour la définition des activités, consultez l’article Pipelines. Cette section fournit la liste des propriétés prises en charge par la source MySQL.

MySQL en tant que source

Pour copier des données à partir de MySQL, les propriétés prises en charge dans la section source de l'activité de copie sont les suivantes :

Propriété Description Obligatoire
type La propriété type de la source d’activité de copie doit être définie sur : MySqlSource Oui
query Utiliser la requête SQL personnalisée pour lire les données. Par exemple : "SELECT * FROM MyTable". Non (si « tableName » est spécifié dans dataset)

Exemple :

"activities":[
    {
        "name": "CopyFromMySQL",
        "type": "Copy",
        "inputs": [
            {
                "referenceName": "<MySQL input dataset name>",
                "type": "DatasetReference"
            }
        ],
        "outputs": [
            {
                "referenceName": "<output dataset name>",
                "type": "DatasetReference"
            }
        ],
        "typeProperties": {
            "source": {
                "type": "MySqlSource",
                "query": "SELECT * FROM MyTable"
            },
            "sink": {
                "type": "<sink type>"
            }
        }
    }
]

Si vous utilisiez une source de données typée RelationalSource, elle reste prise en charge telle quelle, mais nous vous suggérons d’utiliser désormais la nouvelle source.

Mappage de type de données pour MySQL

Lors de la copie de données de MySQL, les mappages suivants sont utilisés entre les types de données MySQL et les types de données intermédiaires utilisés par le service en interne. Pour découvrir comment l’activité de copie mappe le schéma et le type de données la source au récepteur, voir Mappages de schémas et de types de données.

Type de données MySQL Type de données de service intermédiaire (pour la version 2.0) Type de données de service intermédiaire (pour la version 1.0)
bigint Int64 Int64
bigint unsigned Decimal Decimal
bit(1) UInt64 Boolean
bit(M), M>1 UInt64 Byte[]
blob Byte[] Byte[]
bool Boolean
(Si TreatTinyAsBoolean=false, il est mappé en tant que SByte. TreatTinyAsBoolean a la valeur True par défaut)		 Int16
char String String
date Datetime Datetime
datetime Datetime Datetime
decimal Decimal Decimal, String
double Double Double
double precision Double Double
enum String String
float Single Single
int Int32 Int32
int unsigned Int64 Int64
integer Int32 Int32
integer unsigned Int64 Int64
JSON String -
long varbinary Byte[] Byte[]
long varchar String String
longblob Byte[] Byte[]
longtext String String
mediumblob Byte[] Byte[]
mediumint Int32 Int32
mediumint unsigned Int64 Int64
mediumtext String String
numeric Decimal Decimal
real Double Double
set String String
smallint Int16 Int16
smallint unsigned Int32 Int32
text String String
time TimeSpan TimeSpan
timestamp Datetime Datetime
tinyblob Byte[] Byte[]
tinyint SByte
(tinyint(1) est mappé vers Boolean)		 Int16
tinyint unsigned Int16 Int16
tinytext String String
varchar String String
year Int Int

Propriétés de l’activité Lookup

Pour en savoir plus sur les propriétés, consultez Activité Lookup.

Mettre à niveau le connecteur MySQL

Voici les étapes qui vous aident à mettre à niveau votre connecteur MySQL :

  1. Dans la page Modifier le service lié, sélectionnez 2.0 sous version et configurez le service lié en faisant référence à propriétés du service lié.

  2. Le mappage de type de données pour la version 2.0 est différent de celui de la version 1.0. Pour découvrir le mappage de type de données version 2.0, consultez mappage de type de données pour MySQL.

  3. La version 2.0 prend en charge d’autres versions de MySQL. Pour plus d’informations, consultez Fonctionnalités prises en charge.

Cette section présente les meilleures pratiques pour le connecteur MySQL version 2.0.

Nous ne pouvons pas charger la clé SSL

  • Symptômes: si vous utilisez le connecteur MySQL version 2.0 avec la clé SSL comme propriété de connexion, vous pouvez rencontrer le message d’erreur suivant : Could not load the client key from your_pem_file: Unrecognized PEM header: -----BEGIN PRIVATE KEY-----

  • Cause: la version 2.0 ne peut pas déchiffrer le format PCKS#8.

  • Recommandation : convertissez le format PEM en PCKS#1.

Le tableau ci-dessous présente les différences de mappage de types de données entre MySQL à l’aide de la version 2.0 et de la version 1.0.

Type de données MySQL Type de données de service intermédiaire (à l’aide de la version 2.0) Type de données de service intermédiaire (à l’aide de la version 1.0)
bit(1) UInt64 Boolean
bit(M), M>1 UInt64 Byte[]
bool Boolean Int16
JSON Chaîne Byte[]

Contenu connexe

Pour obtenir une liste des magasins de données pris en charge comme sources et récepteurs par l’activité de copie, consultez la section sur les magasins de données pris en charge.