Tous les produits
Search
Centre de documentation

Data Online Migration:Overview

Dernière mise à jour :Aug 10, 2026

ossimport est un outil de migration des données vers Object Storage Service (OSS). Vous pouvez déployer ossimport sur un serveur local ou une instance Elastic Compute Service (ECS) pour migrer des données depuis un stockage local ou un stockage cloud tiers vers OSS. Alibaba Cloud propose également le service Data Online Migration et la fonctionnalité de réplication entre régions, qui vous permettent de migrer vos données vers le cloud et de répliquer des données entre des buckets OSS via une interface graphique.

Important
  • ossimport ne vérifie pas les données après la migration et ne garantit donc ni la cohérence ni l'intégrité des données. Une fois la tâche de migration terminée, vérifiez la cohérence des données entre la source et la destination de la migration.

    Si vous supprimez les données sources sans avoir vérifié leur cohérence avec les données de destination, vous assumez l'entière responsabilité des pertes et conséquences qui en découlent.

  • Pour migrer des données depuis des sources tierces, nous vous recommandons d'utiliser le service Data Online Migration.

  • Pour répliquer des objets entre des buckets OSS en temps quasi réel, nous vous recommandons d'utiliser la fonctionnalité de réplication entre régions d'OSS.

Fonctionnalités

  • ossimport prend en charge une large gamme de sources de données, telles que les systèmes de fichiers locaux, Qiniu Cloud Object Storage (KODO), Baidu Object Storage (BOS), Amazon Simple Storage Service (Amazon S3), Azure Blob Storage, UPYUN Storage Service (USS), Tencent Cloud Object Service (COS), Kingsoft Standard Storage Service (KS3), les listes d'URL HTTP et HTTPS, ainsi qu'Alibaba Cloud OSS.

  • ossimport prend en charge les modes de déploiement autonome et distribué. Le mode autonome est simple à déployer et à utiliser. Le mode distribué convient aux migrations de données à grande échelle.

    Remarque

    En mode autonome, un seul bucket peut être migré à la fois.

  • ossimport prend en charge la reprise d'upload.

  • ossimport prend en charge la limitation du débit.

  • ossimport permet de migrer les objets modifiés après un instant donné et ceux dont le nom contient un préfixe spécifique.

  • ossimport prend en charge le téléchargement et l'upload concurrents des données.

Facturation

ossimport est gratuit. Toutefois, si vous utilisez ossimport pour migrer des données via Internet, des frais de trafic sortant et des frais de requête peuvent s'appliquer côté source de données, ainsi que des frais de requête côté OSS. Si l'accélération de transfert est activée pendant la migration, des frais supplémentaires d'accélération de transfert vous seront facturés.

Notes d'utilisation

  • Vitesse de migration

    La vitesse de migration d'ossimport varie en fonction de plusieurs facteurs, tels que la bande passante de lecture de la source de données, la bande passante du réseau local et la taille des fichiers à migrer. La migration de fichiers inférieurs à 200 Ko est lente en raison du grand nombre d'IOPS requis pour traiter de nombreux petits fichiers.

  • Migration de fichiers archivés

    Si vous souhaitez migrer des fichiers archivés, vous devez d'abord les restaurer avant de pouvoir les migrer.

  • Mise en mémoire tampon des données

    Lorsque vous utilisez ossimport pour migrer des données, les flux de données sont d'abord transférés vers la mémoire locale, puis uploadés vers la destination.

  • Conservation des données sources

    Pendant une tâche de migration de données, ossimport effectue uniquement des opérations de lecture sur les données sources. Il n'effectue aucune opération d'écriture. Cela garantit que les données sources ne sont ni modifiées ni supprimées.

  • Migration à l'aide d'ossutil

    Pour migrer des données dont la taille est inférieure à 30 To, nous vous recommandons d'utiliser ossutil. ossutil est un outil léger et facile à utiliser. Utilisez les options -u, --update, et --snapshot-path pour migrer les fichiers de manière incrémentielle. Pour plus d'informations, consultez Vue d'ensemble.

Environnement d'exécution

ossimport peut être déployé sur Linux ou Windows répondant aux exigences suivantes :

  • Windows 7 ou version ultérieure

  • CentOS 6 ou CentOS 7

  • Java 7 ou Java 8

Important

ossimport ne peut pas être déployé en mode distribué sur Windows.

Modes de déploiement

ossimport prend en charge les modes de déploiement autonome et distribué.

  • Le déploiement autonome convient à la migration de données dont la taille est inférieure à 30 To. Pour déployer ossimport en mode autonome, téléchargez le package ossimport pour le déploiement autonome. Vous pouvez déployer ossimport sur un appareil capable d'accéder aux données à migrer et au bucket OSS vers lequel vous souhaitez migrer les données.

  • Le déploiement distribué convient à la migration de données dont la taille est supérieure à 30 To. Pour déployer ossimport en mode distribué, téléchargez le package ossimport pour le déploiement distribué. Vous pouvez déployer ossimport sur plusieurs appareils capables d'accéder aux données à migrer et au bucket OSS vers lequel vous souhaitez migrer les données.

    Remarque

    Pour réduire le temps nécessaire à la migration de grandes quantités de données, déployez ossimport sur plusieurs instances ECS situées dans la même région que votre bucket OSS et connectez le serveur source à un Virtual Private Cloud (VPC) via Express Connect. Ainsi, vous pouvez utiliser les instances ECS pour migrer les données via le VPC à une vitesse plus élevée.

    Vous pouvez également utiliser ossimport pour transmettre des données via Internet. Dans ce cas, la vitesse de transmission dépend de la bande passante de votre machine locale.

Mode autonome

Les modules Master, Worker, Tracker et Console sont compressés dans ossimport2.jar et s'exécutent sur le même appareil. Le système ne comporte qu'un seul worker.

Le code suivant illustre la structure des fichiers en mode autonome :

ossimport
├── bin
│ └── ossimport2.jar  # The JAR package that contains the Master, Worker, Tracker, and Console modules.
├── conf
│ ├── local_job.cfg   # The Job configuration file in standalone deployment.
│ └── sys.properties  # The configuration file that contains system parameters.
├── console.bat         # The Windows command line tool used to run commands step by step.
├── console.sh          # The Linux command line tool used to run commands step by step.
├── import.bat          # The script that runs migration tasks on Windows with a few clicks based on the conf/local_job.cfg configuration file. The script encapsulates all steps of a migration task, including starting the migration task, migrating data, verifying data, and retrying the migration task.
├── import.sh           # The script that runs migration tasks on Linux with a few clicks based on the conf/local_job.cfg configuration file. The script encapsulates all steps of a migration task, including starting the migration task, migrating data, verifying data, and retrying the migration task.
├── logs                # The directory that contains logs.
└ ── README.md # The file that provides instructions on how to use ossimport. We recommend that you read this file before you use ossimport.
  • import.bat et import.sh sont des scripts permettant d'exécuter des tâches de migration en quelques clics. Exécutez ces scripts après avoir modifié le fichier de configuration local_job.cfg.

  • console.bat et console.sh sont des outils en ligne de commande permettant d'exécuter les commandes étape par étape.

  • Exécutez les scripts ou les commandes dans le répertoire ossimport, qui contient les fichiers *.bat et *.sh.

Mode distribué

L'architecture d'ossimport en mode distribué se compose d'un master et de plusieurs workers. La structure suivante illustre cette architecture :

Master --------- Job --------- Console
    |
    |
   TaskTracker
    |_____________________
    |Task     | Task      | Task
    |         |           |
Worker      Worker      Worker

Paramètre

Description

Master

Le master divise une tâche de migration en plusieurs sous-tâches en fonction de la taille des données et du nombre de fichiers. Vous pouvez spécifier la taille des données et le nombre de fichiers dans le fichier sys.properties. Le master divise une tâche de migration en plusieurs sous-tâches en suivant les étapes ci-dessous :

  1. Le master parcourt la liste complète des fichiers à migrer depuis le stockage local ou le stockage cloud tiers.

  2. Le master répartit les fichiers en plusieurs sous-tâches selon la taille des données et le nombre de fichiers. Chaque sous-tâche est responsable de la migration ou de la vérification d'une partie des fichiers.

Worker

  • Un worker migre les fichiers et vérifie les données pour les sous-tâches. Un worker extrait des fichiers spécifiques de la source de données et les upload vers le répertoire spécifié dans OSS. Vous pouvez configurer la source de données et le bucket OSS de destination dans le fichier de configuration job.cfg ou local_job.cfg.

  • Les workers prennent en charge la limitation du débit et un nombre personnalisé de sous-tâches concurrentes pour la migration des données. Vous pouvez configurer ces paramètres dans le fichier de configuration sys.properties.

TaskTracker

Le TaskTracker distribue les sous-tâches et suit leur statut. Le TaskTracker est abrégé en tracker.

Console

La console interagit avec les utilisateurs, reçoit les commandes saisies et affiche les résultats. La console prend en charge les commandes de gestion du système, notamment deploy, start et stop, ainsi que les commandes de gestion des tâches, telles que submit, retry et clean.

Job

La tâche de migration de données soumise par les utilisateurs. Une tâche correspond à un fichier de configuration job.cfg.

Task

La sous-tâche qui migre une partie des fichiers. Une tâche de migration peut être divisée en plusieurs sous-tâches en fonction de la taille des données et du nombre de fichiers. L'unité minimale de division d'une tâche de migration en sous-tâches est le fichier. Un fichier n'est pas attribué à plusieurs sous-tâches.

En déploiement distribué, vous pouvez démarrer plusieurs appareils et exécuter un seul worker sur chaque appareil pour migrer les données. Les sous-tâches sont attribuées équitablement aux workers, et un worker exécute plusieurs sous-tâches.

Le code suivant illustre la structure des fichiers en mode distribué :

ossimport
├── bin
│ ├── console.jar     # The JAR package for the Console module.
│ ├── master.jar      # The JAR package for the Master module.
│ ├── tracker.jar     # The JAR package for the Tracker module.
│ └── worker.jar      # The JAR package for the Worker module.
├── conf
│ ├── job.cfg         # The Job configuration file template.
│ ├── sys.properties  # The configuration file that contains system parameters.
│ └── workers         # The list of workers.
├── console.sh          # The command-line tool. Only Linux is supported.
├── logs                # The directory that contains logs.
└ ── README.md # The file that provides instructions on how to use ossimport. We recommend that you read this file before you use ossimport.

Fichiers de configuration

Les fichiers de configuration sys.properties et local_job.cfg sont disponibles en mode autonome. Les fichiers de configuration sys.properties, job.cfg et workers sont disponibles en mode distribué. Les fichiers de configuration local_job.cfg et job.cfg contiennent les mêmes paramètres. Le fichier de configuration workers est exclusif au mode distribué.

  • sys.properties : les paramètres système.

    Paramètre

    Description

    Remarques

    workingDir

    Le répertoire de travail.

    Le répertoire dans lequel le package est décompressé. Ne modifiez pas ce paramètre en mode autonome. En mode distribué, le répertoire de travail doit être identique sur chaque appareil.

    workerUser

    Le nom d'utilisateur SSH utilisé pour se connecter à l'appareil sur lequel réside un worker.

    • Si le paramètre privateKeyFile est spécifié, la valeur du paramètre privateKeyFile est utilisée.

    • Si le paramètre privateKeyFile n'est pas spécifié, les valeurs des paramètres workerUser et workerPassword sont utilisées.

    • Ne modifiez pas ce paramètre en mode autonome.

    workerPassword

    Le mot de passe SSH utilisé pour se connecter à l'appareil sur lequel réside un worker.

    Ne modifiez pas ce paramètre en mode autonome.

    privateKeyFile

    Le chemin du fichier de clé privée.

    • Si vous avez déjà établi une connexion SSH, vous pouvez spécifier ce paramètre. Sinon, laissez ce paramètre vide.

    • Si le paramètre privateKeyFile est spécifié, la valeur de privateKeyFile est utilisée.

    • Si le paramètre privateKeyFile n'est pas spécifié, les valeurs des paramètres workerUser et workerPassword sont utilisées.

    • Ne modifiez pas ce paramètre en mode autonome.

    sshPort

    Le port SSH.

    La valeur par défaut est 22. Dans la plupart des cas, nous vous recommandons de conserver la valeur par défaut. Ne modifiez pas ce paramètre en mode autonome.

    workerTaskThreadNum

    Le nombre maximal de threads pour qu'un worker exécute des sous-tâches.

    • Ce paramètre est lié à la mémoire de l'appareil et aux conditions réseau. Nous vous recommandons de définir ce paramètre sur 60.

    • La valeur peut être augmentée pour les machines physiques. Par exemple, vous pouvez définir ce paramètre sur 150. Si la bande passante réseau est déjà saturée, n'augmentez pas davantage la valeur.

    • Si les conditions réseau sont mauvaises, réduisez la valeur. Par exemple, vous pouvez définir ce paramètre sur 30. Cela permet d'éviter les erreurs de délai d'expiration causées par la compétition pour les ressources réseau.

    workerMaxThroughput(KB/s)

    Le débit maximal pour la migration des données par un worker.

    Ce paramètre peut être utilisé pour la limitation du débit. La valeur par défaut est 0, ce qui signifie qu'aucune limitation n'est imposée.

    dispatcherThreadNum

    Le nombre de threads pour la distribution des sous-tâches et la vérification de l'état par le tracker.

    Si vous n'avez pas d'exigences particulières, conservez la valeur par défaut.

    workerAbortWhenUncatchedException

    Indique s'il faut ignorer l'erreur ou terminer la sous-tâche en cas d'erreur inconnue.

    Par défaut, l'erreur est ignorée en cas d'erreur inconnue.

    workerRecordMd5

    Indique s'il faut utiliser l'élément de métadonnées x-oss-meta-md5 pour enregistrer le hachage MD5 des fichiers à migrer. Par défaut, le hachage MD5 n'est pas enregistré.

    La valeur de ce paramètre est utilisée pour vérifier l'intégrité des données.

  • job.cfg : les configurations pour les tâches de migration de données. Les fichiers de configuration local_job.cfg et job.cfg diffèrent par leur nom mais contiennent les mêmes paramètres.

    Paramètre

    Description

    Remarques

    jobName

    Le nom de la tâche de migration. La valeur est de type STRING.

    • Un nom de tâche identifie de manière unique une tâche. Un nom de tâche peut contenir des lettres, des chiffres, des traits de soulignement (_) et des tirets (-), et doit comporter entre 4 et 128 caractères. Vous pouvez soumettre plusieurs tâches ayant des noms différents.

    • Si vous soumettez une tâche portant le même nom qu'une tâche existante, le système indique que la tâche existe déjà. Avant de nettoyer la tâche existante, vous n'êtes pas autorisé à soumettre la tâche avec le même nom.

    jobType

    Le type de la tâche de migration. La valeur est de type STRING.

    • Valeur par défaut : import.

    isIncremental

    Indique s'il faut activer le mode de migration incrémentielle. La valeur est de type BOOLEAN.

    • Valeur par défaut : false.

    • Si ce paramètre est défini sur true, ossimport effectue une analyse des données à des intervalles spécifiés par incrementalModeInterval pour détecter les données incrémentielles, puis migre les données incrémentielles détectées vers OSS.

    incrementalModeInterval

    L'intervalle de migration en secondes en mode de migration incrémentielle. La valeur est de type INTEGER.

    Ce paramètre est valide si le paramètre isIncremental est défini sur true. L'intervalle minimal est de 900 secondes. Nous vous recommandons de définir le paramètre sur une valeur non inférieure à 3600 pour éviter les pics de requêtes et les frais supplémentaires.

    importSince

    La condition temporelle pour la tâche de migration de données. Les données dont l'heure de dernière modification est postérieure à la valeur de ce paramètre sont migrées. La valeur est de type INTEGER. Unité : secondes.

    • L'horodatage doit être au format UNIX. Un horodatage UNIX représente le nombre de secondes écoulées depuis le jeudi 1er janvier 1970 à 00:00:00. Vous pouvez exécuter la commande date +%s pour interroger l'horodatage UNIX.

    • La valeur par défaut est 0, ce qui signifie que toutes les données sont migrées.

    srcType

    Le type de source de migration. La valeur est de type STRING et respecte la casse.

    Valeurs valides :

    • local : migre les données du stockage local vers OSS. Si cette valeur est spécifiée, indiquez le paramètre srcPrefix et laissez les paramètres srcAccessKey, srcSecretKey, srcDomain et srcBucket vides.

    • oss : migre les données d'un bucket OSS vers un autre bucket OSS.

    • qiniu : migre les données de KODO vers OSS.

    • bos : migre les données de BOS vers OSS.

    • ks3 : migre les données de KS3 vers OSS.

    • s3 : migre les données de Amazon S3 vers OSS.

    • youpai : migre les données de USS vers OSS.

    • http : migre les données depuis des listes d'URL HTTP ou HTTPS vers OSS.

    • cos : migre les données de COS vers OSS.

    • azure : migre les données d'Azure Blob Storage vers OSS.

    srcAccessKey

    L'ID AccessKey utilisé pour accéder à la source. La valeur est de type STRING.

    • Si le paramètre srcType est défini sur oss, qiniu, baidu, ks3 ous3, spécifiez l'ID AccessKey utilisé pour accéder à la source.

    • Si le paramètre srcType est défini sur local ou http, ignorez ce paramètre.

    • Si le paramètre srcType est défini sur youpai ou azure, spécifiez le nom de compte utilisé pour accéder à la source.

    srcSecretKey

    La clé secrète AccessKey utilisée pour accéder à la source. La valeur est de type STRING.

    • Si le paramètre srcType est défini sur oss, qiniu, baidu, ks3 ou s3, spécifiez la clé secrète AccessKey utilisée pour accéder à la source.

    • Si le paramètre srcType est défini sur local ou http, ignorez ce paramètre.

    • Si le paramètre srcType est défini sur youpai, spécifiez le mot de passe de l'opérateur utilisé pour accéder à la source.

    • Si le paramètre srcType est défini sur azure, spécifiez la clé de compte utilisée pour accéder à la source.

    srcDomain

    L'endpoint source.

    • Si le paramètre srcType est défini sur local ou http, ignorez ce paramètre.

    • Si le paramètre srcType est défini sur oss, spécifiez l'endpoint qui n'inclut pas le nom du bucket. Vous pouvez obtenir l'endpoint depuis la console OSS.

    • Si le paramètre srcType est défini sur qiniu, spécifiez le nom de domaine du bucket. Vous pouvez obtenir le nom de domaine depuis la console KODO.

    • Si le paramètre srcType est défini sur bos, spécifiez le nom de domaine BOS, tel que http://bj.bcebos.com ou http://gz.bcebos.com.

    • Si le paramètre srcType est défini sur ks3, spécifiez le nom de domaine KS3, tel que http://kss.ksyun.com, http://ks3-cn-beijing.ksyun.com ou http://ks3-us-west-1.ksyun.coms.

    • Si le paramètre srcType est défini sur S3, spécifiez l'endpoint correspondant à la région Amazon S3.

    • Si le paramètre srcType est défini sur youpai, spécifiez le nom de domaine USS, tel que http://v0.api.upyun.com (ligne optimale identifiée automatiquement), http://v1.api.upyun.com (ligne China Telecom), http://v2.api.upyun.com (ligne China Unicom) ou http://v3.api.upyun.com (ligne China Mobile).

    • Si le paramètre srcType est défini sur cos, spécifiez la région où réside le bucket COS. Exemple : ap-guangzhou.

    • Si le paramètre srcType est défini sur cos, spécifiez le suffixe d'endpoint dans la chaîne de connexion Azure Blob Storage. Exemple : core.chinacloudapi.cn.

    srcBucket

    Le nom du bucket ou du conteneur source.

    • Si le paramètre srcType est défini sur local ou http, ignorez ce paramètre.

    • Si le paramètre srcType est défini sur azure, spécifiez le nom du conteneur source.

    • Si le paramètre srcType est défini sur une valeur autre que local et azure, spécifiez le nom du bucket.

    srcPrefix

    Le préfixe source. La valeur est de type STRING. Ce paramètre est vide par défaut.

    • Si le paramètre srcType est défini sur local, spécifiez le chemin complet se terminant par une barre oblique (/). Si le chemin contient deux niveaux de répertoire ou plus, séparez-les par des barres obliques (/). Exemples : c:/example/ et /data/example/ .

      Important

      Les chemins tels que c:/example//, /data//example/ et /data/example// ne sont pas valides.

    • Si le paramètre srcType est défini sur oss, qiniu, bos, ks3, youpai ou s3, spécifiez le préfixe des objets à migrer, sans inclure le nom du bucket, par exemple data/to/oss/.

    • Pour migrer tous les objets, laissez le paramètre srcPrefix vide.

    destAccessKey

    L'ID AccessKey utilisé pour accéder au bucket OSS de destination. La valeur est de type STRING.

    Vous pouvez obtenir l'ID AccessKey utilisé pour accéder au bucket OSS de destination depuis la console OSS.

    destSecretKey

    La clé secrète AccessKey utilisée pour accéder au bucket OSS de destination. La valeur est de type STRING.

    Vous pouvez obtenir la clé secrète AccessKey utilisée pour accéder au bucket OSS de destination depuis la console OSS.

    destDomain

    L'endpoint de destination. La valeur est de type STRING.

    Vous pouvez obtenir l'endpoint de destination qui n'inclut pas le nom du bucket depuis la console OSS. Pour plus d'informations, consultez Régions et endpoints.

    destBucket

    Le bucket de destination. La valeur est de type STRING.

    Le nom du bucket OSS de destination. Le nom ne peut pas se terminer par une barre oblique (/).

    destPrefix

    Le préfixe de nom des objets migrés dans le bucket OSS de destination.

    • Ce paramètre est vide par défaut. Si vous conservez la valeur par défaut, les objets migrés sont stockés dans le répertoire racine du bucket de destination.

    • Pour migrer les données vers un répertoire spécifique dans OSS, terminez le préfixe par une barre oblique (/). Exemple : data/in/oss/.

    • Les noms d'objets OSS ne peuvent pas commencer par une barre oblique (/). Ne définissez pas le paramètre destPrefix sur une valeur commençant par une barre oblique (/).

    • Un fichier local dont le chemin est au format srcPrefix+relativePath est migré vers un chemin OSS au format destDomain/destBucket/destPrefix+relativePath.

    • Un objet dont le chemin est au format srcDomain/srcBucket/srcPrefix+relativePath dans le cloud est migré vers un chemin OSS au format destDomain/destBucket/destPrefix+relativePath.

    taskObjectCountLimit

    Le nombre maximal de fichiers dans chaque sous-tâche. La valeur est de type INTEGER. La valeur par défaut est 10000.

    Ce paramètre affecte le niveau de concurrence des sous-tâches que vous souhaitez exécuter. Dans la plupart des cas, définissez ce paramètre sur une valeur calculée selon la formule suivante : Nombre total de fichiers / Nombre total de workers / Nombre de threads de migration (workerTaskThreadNum). La valeur maximale est 50000. Si le nombre total de fichiers est inconnu, conservez la valeur par défaut.

    taskObjectSizeLimit

    La taille maximale des données en octets pour chaque sous-tâche. La valeur est de type INTEGER. La taille maximale par défaut est de 1 Go.

    Ce paramètre affecte le niveau de concurrence des sous-tâches que vous souhaitez exécuter. Dans la plupart des cas, définissez ce paramètre sur une valeur calculée selon la formule suivante : Taille totale des données / Nombre total de workers / Nombre de threads de migration (workerTaskThreadNum). Si la taille totale des données est inconnue, conservez la valeur par défaut.

    isSkipExistFile

    Indique s'il faut ignorer les objets déjà existants lors de la migration des données. La valeur est de type BOOLEAN.

    Une valeur true indique que les objets sont ignorés en fonction de leur taille et de leur heure de dernière modification. Une valeur false indique que les objets déjà existants sont écrasés. La valeur par défaut est false.

    scanThreadCount

    Le nombre de threads qui analysent les fichiers en parallèle. La valeur est de type INTEGER.

    • Valeur par défaut : 1.

    • Valeurs valides : 1 à 32.

    Ce paramètre affecte l'efficacité de l'analyse des fichiers. Si vous n'avez pas d'exigences particulières, conservez la valeur par défaut.

    maxMultiThreadScanDepth

    La profondeur maximale des répertoires pour l'analyse parallèle. La valeur est de type INTEGER.

    • Valeur par défaut : 1.

    • Valeurs valides : 1 à 16.

    • Une valeur de 1 indique une analyse parallèle dans les répertoires de premier niveau.

    • Si vous n'avez pas d'exigences particulières, conservez la valeur par défaut. Une valeur élevée peut entraîner des échecs de tâche.

    appId

    L'ID d'application de COS. La valeur est de type INTEGER.

    Ce paramètre est valide si le paramètre srcType est défini sur cos.

    httpListFilePath

    Le chemin absolu du fichier de liste d'URL HTTP. La valeur est de type STRING.

    • Ce paramètre est valide si le paramètre srcType est défini sur http. Si la source est une liste d'URL HTTP, vous devez spécifier ce paramètre. Exemple : c:/example/http.list.

    • Une URL HTTP dans le fichier doit être divisée en deux parties séparées par un ou plusieurs espaces. La première partie est le préfixe, et la seconde est le chemin relatif de l'objet dans OSS après la migration de l'objet hébergé à l'URL. Par exemple, le fichier de liste d'URL HTTP situé dans le chemin c:/example/http.list contient les URL suivantes :

      http://xxx.xxx.com/aa/  bb.jpg
      http://xxx.xxx.com/cc/  dd.jpg

      Si vous définissez le paramètre destPrefix sur ee/, les objets migrés vers OSS auront les noms suivants :

      ee/bb.jpg
          ee/dd.jpg
  • workers : disponible uniquement en mode distribué. Spécifiez une adresse IP par ligne. Exemple :

    192.168.1.6
    192.168.1.7
    192.168.1.8
    • Dans l'exemple précédent, 192.168.1.6 sur la première ligne est le master. Autrement dit, 192.168.1.6 est l'adresse IP de l'appareil sur lequel le master, les workers et le tracker sont démarrés. La console s'exécute également sur cet appareil.

    • Assurez-vous que le même nom d'utilisateur, la même méthode de connexion et le même répertoire de travail sont utilisés pour tous les workers.

Exemples de fichiers de configuration

Le tableau suivant fournit des liens vers des exemples de fichiers de configuration pour les tâches de migration de données en mode distribué. Le nom du fichier de configuration en mode autonome est local_job.cfg, qui contient les mêmes éléments de configuration que le fichier de configuration en mode distribué.

|
**Scénario de migration**
|
**Fichier de configuration**
|
**Description**
| | --- | --- | --- | |
Migrer des données du stockage local vers OSS
|
[job.cfg](https://github.com/aliyun/ossimport/blob/master/conf/local/job.cfg)
|
Définissez le paramètre srcPrefix sur un chemin absolu se terminant par une barre oblique (/). Exemples : `D:/work/oss/data/` et `/home/user/work/oss/data/`.
| |
Migrer des données de KODO vers OSS
|
[job.cfg](https://github.com/aliyun/ossimport/blob/master/conf/qiniu/job.cfg)
|
Vous pouvez laisser les paramètres srcPrefix et destPrefix vides. Si vous souhaitez spécifier les paramètres, terminez les valeurs par une barre oblique (/). Exemple : `destPrefix=docs/`.
| |
Migrer des données de BOS vers OSS
|
[job.cfg](https://github.com/aliyun/ossimport/blob/master/conf/bos/job.cfg)
|
Vous pouvez laisser les paramètres srcPrefix et destPrefix vides. Si vous souhaitez spécifier les paramètres, terminez les valeurs par une barre oblique (/). Exemple : `destPrefix=docs/`.
| |
Migrer des données de Amazon S3 vers OSS
|
[job.cfg](https://github.com/aliyun/ossimport/blob/master/conf/s3/job.cfg)
|
Pour plus d'informations, consultez [Endpoints de service AWS](http://docs.aws.amazon.com/general/latest/gr/rande.html#s3_region).
| |
Migrer des données de USS vers OSS
|
[job.cfg](https://github.com/aliyun/ossimport/tree/master/conf/youpai)
|
Définissez le paramètre srcAccessKey sur le compte opérateur et le paramètre srcSecretKey sur le mot de passe correspondant.
| |
Migrer des données de COS vers OSS
|
[job.cfg](https://github.com/aliyun/ossimport/blob/master/conf/cos/job.cfg)
|
Spécifiez le paramètre srcDomain en fonction de l'exigence pour COS V4. Exemple : `srcDomain=sh`. Vous pouvez laisser le paramètre srcPrefix vide. Si vous souhaitez spécifier le paramètre, commencez et terminez la valeur par une barre oblique (`/`). Exemple : `srcPrefix=/docs/`.
| |
Migrer des données d'Azure Blob Storage vers OSS
|
[job.cfg](https://github.com/aliyun/ossimport/tree/master/conf/blob)
|
Définissez le paramètre srcAccessKey sur le compte de stockage et le paramètre srcSecretKey sur la clé d'accès. Définissez le paramètre srcDomain sur le suffixe d'endpoint dans la chaîne de connexion Azure Blob Storage. Exemple : `core.chinacloudapi.cn`.
| |
Migrer des données entre des buckets OSS
|
[job.cfg](https://github.com/aliyun/ossimport/blob/master/conf/oss/job.cfg)
|
Cette méthode convient pour migrer des objets ayant des préfixes différents dans leurs noms, entre des buckets situés dans différentes régions ou entre des buckets appartenant à différentes classes de stockage. Nous vous recommandons de déployer ossimport sur des instances ECS et d'utiliser des endpoints internes pour minimiser les coûts de trafic.
|





















































Paramètres avancés

  • Limiter le trafic

    Dans le fichier de configuration sys.properties, le paramètre workerMaxThroughput(KB/s) spécifie le débit maximal pour la migration des données par un worker. Dans les scénarios de limitation du débit, tels que la limitation côté source et la limitation réseau, définissez ce paramètre sur une valeur inférieure à la bande passante maximale disponible de votre appareil, en fonction de vos besoins métier. Après la modification, redémarrez le service pour que la modification prenne effet.

    En mode distribué, modifiez le fichier de configuration sys.properties dans le répertoire $OSS_IMPORT_WORK_DIR/conf pour chaque worker et redémarrez le service.

    Pour limiter le trafic, modifiez le fichier de configuration sys.properties de manière planifiée à l'aide de crontab et redémarrez le service pour que la modification prenne effet.

  • Modifier le nombre de sous-tâches concurrentes

    • Dans le fichier de configuration sys.properties, le paramètre workerTaskThreadNum spécifie le nombre de sous-tâches concurrentes qu'un worker peut exécuter. Si les conditions réseau sont médiocres et qu'un worker doit traiter un grand nombre de sous-tâches, une erreur de délai d'expiration se produit. Pour résoudre ce problème, modifiez la configuration en réduisant le nombre de sous-tâches concurrentes, puis redémarrez le service.

    • Dans le fichier de configuration sys.properties, le paramètre workerMaxThroughput(KB/s) spécifie le débit maximal pour la migration des données par un worker. Dans les scénarios de limitation du débit, tels que la limitation côté source et la limitation réseau, définissez ce paramètre sur une valeur inférieure à la bande passante maximale disponible de votre appareil, en fonction de vos besoins métier.

    • Dans le fichier de configuration job.cfg, le paramètre taskObjectCountLimit spécifie le nombre maximal de fichiers dans chaque sous-tâche. La valeur par défaut est 10000. Cette configuration de paramètre affecte le nombre de sous-tâches. L'efficacité de l'exécution des sous-tâches concurrentes se dégrade si le nombre de sous-tâches est faible.

    • Dans le fichier de configuration job.cfg, le paramètre taskObjectSizeLimit spécifie la taille maximale des données pour chaque sous-tâche. La taille maximale par défaut pour chaque sous-tâche est de 1 Go. Cette configuration de paramètre affecte le nombre de sous-tâches. L'efficacité de l'exécution des sous-tâches concurrentes se dégrade si le nombre de sous-tâches est faible.

      Important
      • Avant de démarrer la migration des données, configurez les paramètres dans les fichiers de configuration.

      • Après avoir modifié les paramètres dans le fichier de configuration sys.properties, redémarrez le serveur local ou l'instance ECS sur laquelle ossimport est déployé pour que la modification prenne effet.

      • Une fois les tâches de migration configurées dans les fichiers job.cfg soumises, les paramètres des fichiers job.cfg ne peuvent plus être modifiés.

  • Vérifier les données sans les migrer

    ossimport vous permet de vérifier uniquement les données sans effectuer d'opération de migration. Pour ignorer la migration des données et vérifier uniquement les données, définissez le paramètre jobType dans le fichier job.cfg ou local_job.cfg sur audit au lieu de import et configurez les autres paramètres de la même manière que pour la migration des données.

  • Spécifier le mode de migration incrémentielle des données

    En mode de migration incrémentielle des données, ossimport migre les données complètes existantes après le démarrage d'une tâche de migration et migre les données incrémentielles à intervalles réguliers. La migration des données complètes démarre après la soumission de la tâche. Ensuite, les données incrémentielles sont migrées à intervalles réguliers. Le mode de migration incrémentielle convient à la sauvegarde et à la synchronisation des données.

    Les éléments de configuration suivants sont disponibles pour le mode de migration incrémentielle des données :

    • Dans le fichier de configuration job.cfg, le paramètre isIncremental spécifie s'il faut activer le mode de migration incrémentielle des données. Valeurs valides : true et false. Valeur par défaut : false.

    • Dans le fichier de configuration job.cfg, le paramètre incrementalModeInterval spécifie l'intervalle en secondes auquel la migration incrémentielle des données est effectuée. Cet élément de configuration prend effet uniquement si le paramètre isIncremental est défini sur true. La valeur minimale est 900. Nous vous recommandons de ne pas définir ce paramètre sur une valeur inférieure à 3600. Sinon, un grand nombre de requêtes seraient gaspillées, entraînant des frais supplémentaires.

  • Filtrer les données à migrer

    Vous pouvez définir des conditions de filtrage pour migrer les objets répondant à des critères spécifiques. ossimport vous permet d'utiliser le préfixe et l'heure de dernière modification pour spécifier les objets à migrer.

    • Dans le fichier de configuration job.cfg, le paramètre srcPrefix spécifie le préfixe des données sources à migrer. Ce paramètre est vide par défaut.

      • Si vous définissez le paramètre srcType sur local, définissez ce paramètre sur le chemin du répertoire local. Vous devez spécifier le chemin complet se terminant par une barre oblique (/). Si le chemin contient deux niveaux de répertoire ou plus, séparez-les par des barres obliques (/). Exemples : c:/example/ ou /data/example/.

      • Si vous définissez le paramètre srcType sur oss, qiniu, bos, ks3, youpai ou s3, définissez ce paramètre sur le préfixe de nom des objets sources sans le nom du bucket. Exemple : data/to/oss/. Pour migrer toutes les données de la source, laissez le paramètre srcPrefix vide.

    • Dans le fichier de configuration job.cfg, le paramètre importSince spécifie l'heure de dernière modification en secondes des données sources. Le paramètre importSince spécifie l'horodatage au format UNIX. Il s'agit du nombre de secondes écoulées depuis le jeudi 1er janvier 1970 à 00:00:00. Vous pouvez exécuter la commande date +%s pour interroger l'horodatage UNIX. La valeur par défaut est 0, ce qui signifie que toutes les données seront migrées. En mode de migration incrémentielle, ce paramètre est valide uniquement pour la migration des données complètes. Dans un mode de migration autre que la migration incrémentielle, ce paramètre est valide pour l'ensemble de la tâche de migration.

      • Si l'heure de dernière modification d'un objet est antérieure à la valeur du paramètre importSince, l'objet n'est pas migré.

      • Si l'heure de dernière modification d'un objet est postérieure à la valeur du paramètre importSince, l'objet est migré.