Questions fréquentes concernant la réplication des données au sein d'un même compte ou entre comptes différents, y compris les scénarios de réplication intra-région et inter-régions.
Puis-je spécifier un chemin d'accès ou un préfixe personnalisé pour le bucket de destination ?
Non. La réplication intra-région et inter-régions ne prend pas en charge les chemins de stockage personnalisés pour le bucket de destination. Le chemin de destination est déterminé par le chemin des données du bucket source configuré dans la règle de réplication des données.
Puis-je répliquer des objets en fonction de leur date de dernière modification ?
Non. Vous ne pouvez pas configurer une règle de réplication des données pour répliquer des objets selon une plage horaire spécifique de dernière modification. Toutefois, vous pouvez utiliser la fonctionnalité File Modified Time du service de migration en ligne pour y parvenir. Si vous spécifiez une plage horaire, seuls les fichiers modifiés durant cette période sont migrés.
Pourquoi ne puis-je pas créer de règle de réplication des données ?
-
Vérifiez que les autorisations requises sont accordées.
-
Autorisations manquantes pour un utilisateur RAM
-
Un utilisateur RAM ne peut pas cliquez sur OK lors de la création d'une règle de réplication des données dans la console.
Cause : L'autorisation
oss:PutBucketReplicationn'est pas accordée.Solution : Accordez l'autorisation
oss:PutBucketReplicationà l'utilisateur RAM.
-
Les rôles RAM personnalisés n'apparaissent pas dans la liste des rôles RAM lorsqu'un utilisateur RAM crée une règle de réplication des données.
Cause : L'autorisation
ram:ListRolesn'est pas accordée.Solution : Accordez l'autorisation
ram:ListRolesà l'utilisateur RAM.
Accorder des stratégies personnalisées à un utilisateur RAM.
-
-
Autorisations manquantes pour un rôle RAM
-
Réplication au sein du même compte
Accordez au rôle RAM les autorisations nécessaires pour effectuer la réplication entre les buckets source et de destination. Types de rôles.
-
Réplication entre comptes
Utilisez le compte A pour accorder à un rôle RAM les autorisations de réplication des données depuis le bucket source, et le compte B pour accorder à un rôle RAM les autorisations de réception des objets répliqués dans le bucket de destination. Autorisation de rôle.
-
-
-
Vérifiez si les buckets source et de destination ont le même statut de versioning.
Les buckets source et de destination doivent avoir le même statut de versioning : tous deux avec versioning activé ou tous deux sans versioning.
-
Vérifiez si l'endpoint ou les informations AccessKey sont corrects.
Si vous utilisez un SDK ou ossutil pour créer une règle de réplication des données, vérifiez les points suivants :
Vérifiez les endpoints régionaux des buckets source et de destination. Régions et endpoints.
Vérifiez la paire AccessKey. Afficher les informations AccessKey d'un utilisateur RAM.
Que faire si la console Resource Access Management (RAM) affiche des avertissements d'autorisation non valides lors de la création d'une stratégie de réplication ?
Lorsque vous utilisez l'éditeur visuel dans la console RAM pour créer une stratégie de réplication personnalisée contenant oss:ReplicateList et oss:ReplicateGet, la console peut afficher des avertissements indiquant une action non reconnue et une ressource non reconnue.
Ces avertissements surviennent car le dictionnaire d'actions de l'éditeur visuel n'inclut pas ces actions OSS internes. Ils n'affectent pas la validité de la stratégie.
Créez la stratégie en utilisant l'une des méthodes suivantes :
Basculez vers le mode Éditeur de script et saisissez le JSON de la stratégie. Ce mode n'affiche pas ces avertissements.
Utilisez la commande
aliyun ram CreatePolicydans l'interface de ligne de commande (CLI) pour créer la stratégie.
Après avoir créé la stratégie, créez une règle de réplication entre comptes dans la console OSS. Si vous parvenez à créer la règle, la stratégie est effective.
Pourquoi les objets ne sont-ils pas répliqués vers le bucket de destination ?
Si les objets n'apparaissent pas dans le bucket de destination après la configuration d'une règle de réplication des données, vérifiez les causes suivantes.
-
Le bucket source est mal configuré.
Vérifiez si le statut de la réplication des données est Activé.
-
Le préfixe est incorrect.
-
Pour répliquer des objets spécifiques, définissez le préfixe. Par exemple, si le préfixe est
log, seuls les objets tels quelog/date1.txtetlog/date2.txtsont répliqués. Les objets commedate3.txtne sont pas répliqués.RemarqueN'ajoutez pas d'astérisque (*) à la fin du préfixe, par exemple
log/*. Le préfixe ne peut pas contenir le nom du bucket. Pour répliquer tous les objets du bucket source vers le bucket de destination, laissez le champ de préfixe vide.
-
Vérifiez si la réplication des objets historiques est activée et si les objets manquants sont des objets historiques.
-
Vérifiez si les objets source sont eux-mêmes des réplicas provenant d'un autre bucket.
OSS ne réplique pas les objets qui sont eux-mêmes des réplicas issus d'une autre règle de réplication. Par exemple, si la réplication est configurée du bucket A vers le bucket B et du bucket B vers le bucket C, les réplicas du bucket B ne sont pas répliqués vers le bucket C.
-
Vérifiez si les objets sont chiffrés avec KMS. Si c'est le cas, activez la réplication pour les objets chiffrés avec KMS.
Si l'objet source ou le bucket de destination utilise SSE-KMS avec un ID CMK spécifié, sélectionnez Copy et configurez les paramètres suivants :
-
CMK ID : Spécifiez la clé KMS pour chiffrer l'objet de destination.
Créez d'abord une clé KMS dans la même région que le bucket de destination. Créer une clé.
-
RAM Role Name : Sélectionnez un rôle RAM pour effectuer le chiffrement KMS sur l'objet de destination.
New RAM Role : Crée un nouveau rôle RAM pour le chiffrement KMS. Le format du nom du rôle est
kms-replication-SourceBucketName-DestinationBucketName.AliyunOSSRole : Utilise le rôle AliyunOSSRole pour le chiffrement KMS sur l'objet de destination. OSS crée automatiquement ce rôle s'il n'existe pas.
RemarqueSi vous créez ou modifiez un rôle, accordez-lui l'autorisation
AliyunOSSFullAccess. Sinon, la réplication des données peut échouer.
Appelez HeadObject et GetBucketEncryption pour interroger le statut de chiffrement de l'objet source et du bucket de destination.
-
-
Vérifiez si la progression de la réplication est de 100 %.
La réplication des données est asynchrone et peut prendre de quelques minutes à plusieurs heures selon la taille des données. Une fois la progression à 100 %, vérifiez si l'objet apparaît dans le bucket de destination.
Pourquoi les suppressions d'objets ne sont-elles pas répliquées ?
-
Cause 1 : Une politique de rétention (WORM) est configurée pour le bucket de destination.
Avant l'expiration de la période de rétention, aucun utilisateur, y compris le propriétaire de la ressource, ne peut supprimer d'objets.
-
Cause 2 : Le comportement de suppression dépend du statut de versioning du bucket source et de la politique de réplication.
Versioning du bucket source
Méthode de requête
Politique de réplication des données
Résultat
Sans versioning
Une requête Delete est initiée.
Répliquer les ajouts et modifications
Seul l'objet du bucket source est supprimé. L'objet du bucket de destination n'est pas supprimé.
Répliquer les ajouts, modifications et suppressions
Les objets des buckets source et de destination sont tous deux supprimés.
Versioning activé
Une requête Delete est initiée sans ID de version d'objet.
Répliquer les ajouts et modifications
Aucun objet n'est supprimé de l'un ou l'autre bucket. OSS crée un marqueur de suppression dans le bucket source et réplique ce marqueur vers le bucket de destination.
Répliquer les ajouts, modifications et suppressions
Une requête Delete est initiée avec un ID de version d'objet.
Répliquer les ajouts et modifications
Seule la version d'objet du bucket source est supprimée. La version d'objet du bucket de destination n'est pas supprimée.
Répliquer les ajouts, modifications et suppressions
Les versions d'objet spécifiées des buckets source et de destination sont toutes deux supprimées.
Vérifier la cohérence des données
Exécutez le code suivant pour vérifier la cohérence des données entre les buckets source et de destination après la réplication.
import com.aliyun.oss.OSSClient;
import com.aliyun.oss.common.auth.*;
import com.aliyun.oss.model.*;
import com.aliyun.oss.OSSException;
import com.aliyuncs.exceptions.ClientException;
public class Demo {
public static void main(String[] args) throws ClientException {
// Obtain access credentials from environment variables. Before you run this sample code, make sure that the OSS_ACCESS_KEY_ID and OSS_ACCESS_KEY_SECRET environment variables are set.
EnvironmentVariableCredentialsProvider credentialsProvider = CredentialsProviderFactory.newEnvironmentVariableCredentialsProvider();
// Set srcEndpoint to the endpoint of the region where the source bucket is located.
String srcEndpoint = "https://oss-cn-hangzhou.aliyuncs.com";
OSSClient srcClient = new OSSClient(srcEndpoint , credentialsProvider);
// Specify the name of the source bucket.
String srcBucketName = "src-replication-bucket";
// Set destEndpoint to the endpoint of the region where the destination bucket is located.
String destEndpoint = "https://oss-cn-beijing.aliyuncs.com";
OSSClient destClient = new OSSClient(destEndpoint, credentialsProvider);
// Specify the name of the destination bucket.
String destBucketName = "dest-replication-bucket";
// If the source and destination buckets do not have versioning enabled, call listObjectsV2 to list the replicated objects from the source bucket.
// If versioning is enabled or suspended for the source and destination buckets, call listVersions to list the replicated objects from the source bucket.
ListObjectsV2Result result;
ListObjectsV2Request request = new ListObjectsV2Request(srcBucketName);
do {
result = srcClient.listObjectsV2(request);
for (OSSObjectSummary summary : result.getObjectSummaries())
{
String objectName = summary.getKey();
ObjectMetadata srcMeta;
try {
// Get the metadata of the source object.
srcMeta = srcClient.headObject(srcBucketName, objectName);
} catch (OSSException ossException) {
if (ossException.getErrorCode().equals("NoSuchKey")) {
continue;
} else {
System.out.println("head src-object failed: " + objectName);
}
continue;
}
ObjectMetadata destMeta;
try {
// Get the metadata of the object replicated to the destination bucket.
destMeta = destClient.headObject(destBucketName, objectName);
} catch (OSSException ossException) {
if (ossException.getErrorCode().equals("NoSuchKey")) {
System.out.println("dest-object not exist: " + objectName);
} else {
System.out.println("head dest-object failed: " + objectName);
}
continue;
}
// Check whether the CRC values of the source and destination objects are consistent.
Long srcCrc = srcMeta.getServerCRC();
String srcMd5 = srcMeta.getContentMD5();
if (srcCrc != null) {
if (destMeta.getServerCRC() != null) {
if (!destMeta.getServerCRC().equals(srcCrc)) {
System.out.println("crc not equal: " + objectName
+ " | srcCrc: " + srcCrc + " | destCrc: " + destMeta.getServerCRC());
}
continue;
}
}
// Check whether the MD5 values of the source and destination objects are consistent.
if (srcMd5!= null) {
if (destMeta.getContentMD5() != null) {
if (!destMeta.getContentMD5().equals(srcMd5)) {
System.out.println("md5 not equal: " + objectName
+ " | srcMd5: " + srcMd5 + " | destMd5: " + destMeta.getContentMD5());
}
continue;
}
}
// Check whether the ETag values of the source and destination objects are consistent.
if (srcMeta.getETag() == null || !srcMeta.getETag().equals(destMeta.getETag())) {
System.out.println("etag not equal: " + objectName
+ " | srcEtag: " + srcMeta.getETag() + " | destEtag: " + destMeta.getETag());
}
}
request.setContinuationToken(result.getNextContinuationToken());
request.setStartAfter(result.getStartAfter());
} while (result.isTruncated());
}
}
La réplication en chaîne est-elle prise en charge ?
Non. Les données répliquées du bucket A vers le bucket B ne sont pas ensuite répliquées du bucket B vers le bucket C.
Pour répliquer les données du bucket A vers le bucket C, configurez une règle de réplication distincte du bucket A vers le bucket C.
Si la réplication historique est toujours en cours pour les deux buckets, les nouvelles données écrites dans le bucket A pourraient être analysées par la tâche de réplication historique et répliquées vers le bucket C.
La réplication bidirectionnelle entre buckets crée-t-elle une boucle de réplication ?
Non. Les données répliquées ne sont jamais renvoyées vers leur origine. Les données répliquées de A vers B ne sont pas répliquées de retour vers A.
Les suppressions liées aux règles de cycle de vie sont-elles répliquées ?
Si la politique de réplication est Répliquer les ajouts et modifications, les objets supprimés par le cycle de vie dans le bucket source ne sont pas supprimés du bucket de destination.
-
Si la politique de réplication est Répliquer les ajouts, modifications et suppressions, les objets supprimés par le cycle de vie dans le bucket source sont également supprimés du bucket de destination.
RemarqueSi le bucket de destination contient encore des objets portant les mêmes noms que les objets source supprimés par le cycle de vie, il se peut qu'ils aient été écrits manuellement dans le bucket de destination.
Pourquoi la progression de la réplication historique est-elle bloquée à 0 % ?
-
La progression de la réplication n'est pas mise à jour en temps réel.
La progression de la réplication historique n'est mise à jour qu'après l'analyse de tous les fichiers. Pour les buckets contenant des centaines de millions d'objets, cela peut prendre plusieurs heures. Une progression de 0 % ne signifie pas que la réplication n'a pas commencé.
Confirmez si la réplication historique a démarré en vérifiant les variations de la capacité de stockage et du trafic du bucket de destination. Interroger l'utilisation au niveau du bucket.
-
La stratégie d'autorisation du bucket source est incorrecte.
OSS ne valide pas les autorisations lors de la création d'une règle de réplication. La règle est créée même avec des autorisations incorrectes, mais les données ne seront pas répliquées et la progression reste à 0 %.
Que faire si la réplication des données est lente ?
-
Augmenter la bande passante
La réplication est asynchrone et peut prendre de quelques minutes à plusieurs heures selon le volume de données. Si la réplication est lente en raison de limites de bande passante, contactez le support technique pour demander une augmentation de la bande passante.
-
Activer Replication Time Control (RTC)
Avec RTC activé, OSS réplique la plupart des objets en quelques secondes et 99,99 % d'entre eux en moins de 10 minutes. Les tâches avec RTC activé entraînent des frais de trafic de réplication des données. Utiliser Replication Time Control (RTC).
Comment suivre les opérations de réplication ?
Configurez une règle de notification d'événements avec les types d'événements ObjectReplication:ObjectCreated, ObjectReplication:ObjectRemoved et ObjectReplication:ObjectModified pour suivre les créations, mises à jour, suppressions et écrasements d'objets. Utiliser les notifications d'événements pour surveiller les modifications d'objets OSS en temps réel.
La réplication est-elle prise en charge sur les buckets avec versioning suspendu ?
Non. Les deux buckets doivent avoir le même statut de versioning : tous deux sans versioning ou tous deux avec versioning.
Les appels API KMS pour la réplication sont-ils facturés ?
Oui. Si le bucket de destination utilise le chiffrement KMS, vous êtes facturé pour les appels API KMS correspondants. Facturation de KMS 1.0.
Puis-je désactiver une règle de réplication ?
Oui. Vous pouvez cliquez sur Disable Replication à côté de la règle pour arrêter la réplication des données.
Les données déjà répliquées restent dans le bucket de destination, mais les nouvelles données écrites dans le bucket source ne sont plus répliquées.
La réplication modifie-t-elle l'ordre des fichiers ?
Non. La réplication préserve l'ordre de modification des fichiers.