同一アカウントおよびクロスアカウントでのデータレプリケーション (同一リージョンおよびクロスリージョンのシナリオを含む) に関するよくある質問です。
送信先バケットにカスタムパスまたはプレフィックスを指定できますか。
いいえ。同一リージョンレプリケーションおよびクロスリージョンレプリケーションでは、送信先バケットのカスタムストレージパスはサポートされていません。送信先パスは、データレプリケーションルールで設定されたソースバケットのデータパスによって決まります。
オブジェクトを最終更新時刻に基づいてレプリケートできますか。
いいえ。特定の最終更新時刻の範囲に基づいてオブジェクトをレプリケートするようにデータレプリケーションルールを設定することはできません。ただし、オンライン移行サービス の [ファイルの変更時刻] 機能を使用すると、これを実現できます。時刻範囲を指定すると、その期間内に変更されたファイルのみが移行されます。
データレプリケーションルールを作成できないのはなぜですか。
必要な権限が付与されているか確認してください。
RAM ユーザーの権限が不足している
RAM ユーザーは、コンソールでデータレプリケーションルールを作成するとき、OK をクリックできません。
原因:
oss:PutBucketReplication権限が付与されていません。解決策: RAM ユーザーに
oss:PutBucketReplication権限を付与します。
RAM ユーザーがデータレプリケーションルールを作成する際に、カスタムの RAM ロールが RAM ロールリストに表示されません。
原因:
ram:ListRoles権限が付与されていません。解決策: RAM ユーザーに
ram:ListRoles権限を付与します。
「RAM ユーザーへのカスタムポリシーの付与」をご参照ください。
RAM ロールの権限が不足している
ソースバケットと送信先バケットのバージョニングステータスが同じであるか確認してください。
ソースバケットと送信先バケットは、両方ともバージョニングが有効であるか、両方ともバージョニングが無効である必要があります。
エンドポイントまたは AccessKey の情報が正しいか確認してください。
SDK または ossutil を使用してデータレプリケーションルールを作成する場合は、以下を確認してください:
ソースバケットと送信先バケットのリージョンエンドポイントを確認します。「リージョンとエンドポイント」をご参照ください。
AccessKey ペアを確認します。「RAM ユーザーの AccessKey 情報の表示」をご参照ください。
レプリケーションポリシーを作成する際に、Resource Access Management (RAM) コンソールに不正な承認の警告が表示された場合はどうすればよいですか。
[RAM コンソール]の[ビジュアルエディター]を使用して oss:ReplicateList と oss:ReplicateGet を含むカスタムレプリケーションポリシーを作成すると、コンソールに[認識されないアクション]と[認識されないリソース]の警告が表示される場合があります。
これらの警告は、ビジュアルエディターのアクション辞書にこれらの内部 OSS アクションが含まれていないために発生します。この警告はポリシーの有効性には影響しません。
次のいずれかの方法でポリシーを作成してください:
スクリプトエディター モードに切り替えて、ポリシーの JSON を入力します。このモードでは、これらの警告は表示されません。
コマンドラインインターフェイス (CLI) で
aliyun ram CreatePolicyコマンドを使用して、ポリシーを作成します。
ポリシーを作成した後、OSS コンソール でクロスアカウントレプリケーションルールを作成します。ルールを作成できれば、ポリシーは有効です。
オブジェクトが送信先バケットにレプリケートされないのはなぜですか。
データレプリケーションルールを設定した後、オブジェクトが送信先バケットに表示されない場合は、次の原因を確認してください。
ソースバケットの設定が正しくありません。
データレプリケーションのステータスが [有効] になっているか確認してください。
プレフィックスが正しくありません。
特定のオブジェクトをレプリケートするには、プレフィックスを設定します。たとえば、プレフィックスが
logの場合、log/date1.txtやlog/date2.txtなどのオブジェクトのみがレプリケートされます。date3.txtのようなオブジェクトはレプリケートされません。説明プレフィックスの末尾に、
log/*のようにアスタリスク (*) を追加しないでください。プレフィックスにバケット名を含めることはできません。ソースバケットから送信先バケットにすべてのオブジェクトをレプリケートするには、プレフィックスフィールドを空のままにします。
履歴オブジェクトのレプリケーションが有効になっているか、また、レプリケートされないオブジェクトが履歴オブジェクトであるかを確認してください。
ソースオブジェクトが別のバケットからのレプリカであるか確認してください。
OSS は、それ自体が別のレプリケーションルールからのレプリカであるオブジェクトをレプリケートしません。たとえば、バケット A からバケット B へ、およびバケット B からバケット C へのレプリケーションが設定されている場合、バケット B 内のレプリカはバケット C にはレプリケートされません。
オブジェクトが KMS 暗号化されているか確認してください。もしそうであれば、KMS 暗号化オブジェクトのレプリケーションを有効にしてください。
ソースオブジェクトまたは宛先バケットで、指定された CMK ID の SSE-KMS が使用されている場合、コピー を選択し、以下のパラメーターを設定します。
[CMK ID]:送信先オブジェクトを暗号化するための KMS キーを指定します。
まず、送信先バケットと同じリージョンに KMS キーを作成します。「キーの作成」をご参照ください。
[RAM ロール名]:送信先オブジェクトで KMS 暗号化を実行するための RAM ロールを選択します。
[新しい RAM ロール]: KMS 暗号化用に新しい RAM ロールを作成します。ロール名の形式は
kms-replication-SourceBucketName-DestinationBucketNameです。AliyunOSSRole:送信先オブジェクトの KMS 暗号化に AliyunOSSRole ロールを使用します。このロールが存在しない場合、OSS は自動的に作成します。
説明ロールを作成または変更する場合は、そのロールに
AliyunOSSFullAccess権限を付与してください。そうしないと、データレプリケーションが失敗する可能性があります。
HeadObject API と GetBucketEncryption API を呼び出して、ソースオブジェクトと送信先バケットの暗号化ステータスを照会します。
レプリケーションの進捗が 100% であるか確認してください。
データレプリケーションは非同期であり、データサイズによっては数分から数時間かかることがあります。進捗が 100% に達した後、オブジェクトが送信先バケットに表示されるか確認してください。
オブジェクトの削除がレプリケートされないのはなぜですか。
原因 1:送信先バケットに保持ポリシー (WORM) が設定されている。
保持期間が満了する前は、リソース所有者を含むどのユーザーもオブジェクトを削除できません。
原因 2:削除の挙動は、ソースバケットのバージョニングステータスとレプリケーションポリシーに依存します。
ソースバケットのバージョニング
リクエストメソッド
データレプリケーションポリシー
結果
バージョニング無効
削除リクエスト
追加と変更をレプリケート
ソースバケット内のオブジェクトのみが削除されます。送信先バケット内のオブジェクトは削除されません。
追加、変更、削除をレプリケート
ソースバケットと送信先バケットの両方でオブジェクトが削除されます。
バージョニング有効
オブジェクトバージョン ID を指定しない削除リクエスト
追加と変更をレプリケート
どちらのバケットからもオブジェクトは削除されません。OSS はソースバケットに削除マーカーを作成し、その削除マーカーを送信先バケットにレプリケートします。
追加、変更、削除をレプリケート
オブジェクトバージョン ID を指定した削除リクエスト
追加と変更をレプリケート
ソースバケット内のオブジェクトバージョンのみが削除されます。送信先バケット内のオブジェクトバージョンは削除されません。
追加、変更、削除をレプリケート
ソースバケットと送信先バケットの両方で、指定されたオブジェクトバージョンが削除されます。
データ整合性の検証
レプリケーション後、次のコードを実行してソースバケットと送信先バケット間のデータ整合性を検証してください。
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 {
// 環境変数からアクセス資格情報を取得します。このサンプルコードを実行する前に、OSS_ACCESS_KEY_ID および OSS_ACCESS_KEY_SECRET 環境変数が設定されていることを確認してください。
EnvironmentVariableCredentialsProvider credentialsProvider = CredentialsProviderFactory.newEnvironmentVariableCredentialsProvider();
// srcEndpoint をソースバケットが配置されているリージョンのエンドポイントに設定します。
String srcEndpoint = "https://oss-cn-hangzhou.aliyuncs.com";
OSSClient srcClient = new OSSClient(srcEndpoint , credentialsProvider);
// ソースバケットの名前を指定します。
String srcBucketName = "src-replication-bucket";
// destEndpoint を送信先バケットが配置されているリージョンのエンドポイントに設定します。
String destEndpoint = "https://oss-cn-beijing.aliyuncs.com";
OSSClient destClient = new OSSClient(destEndpoint, credentialsProvider);
// 送信先バケットの名前を指定します。
String destBucketName = "dest-replication-bucket";
// ソースバケットと送信先バケットでバージョニングが有効になっていない場合、listObjectsV2 を呼び出してソースバケットからレプリケートされたオブジェクトを一覧表示します。
// ソースバケットと送信先バケットでバージョニングが有効または一時停止されている場合、listVersions を呼び出してソースバケットからレプリケートされたオブジェクトを一覧表示します。
ListObjectsV2Result result;
ListObjectsV2Request request = new ListObjectsV2Request(srcBucketName);
do {
result = srcClient.listObjectsV2(request);
for (OSSObjectSummary summary : result.getObjectSummaries())
{
String objectName = summary.getKey();
ObjectMetadata srcMeta;
try {
// ソースオブジェクトのメタデータを取得します。
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 {
// 送信先バケットにレプリケートされたオブジェクトのメタデータを取得します。
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;
}
// ソースオブジェクトと送信先オブジェクトの CRC 値が一致するかどうかを確認します。
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;
}
}
// ソースオブジェクトと送信先オブジェクトの MD5 値が一致するかどうかを確認します。
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;
}
}
// ソースオブジェクトと送信先オブジェクトの ETag 値が一致するかどうかを確認します。
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());
}
}
連鎖レプリケーションはサポートされていますか。
いいえ。バケット A からバケット B にレプリケートされたデータは、バケット B からバケット C にはレプリケートされません。
バケット A からバケット C にデータをレプリケートするには、バケット A からバケット C への別のレプリケーションルールを設定する必要があります。
両方のバケットで履歴オブジェクトのレプリケーションがまだ進行中の場合、バケット A に書き込まれた新しいデータが履歴オブジェクトのレプリケーションタスクによってスキャンされ、バケット C にレプリケートされる可能性があります。
バケット間の双方向レプリケーションはレプリケーションループを作成しますか。
いいえ。レプリケートされたデータが元の場所に送り返されることはありません。A から B にレプリケートされたデータは、A にはレプリケートされません。
ライフサイクルルールによる削除はレプリケートされますか。
レプリケーションポリシーが [追加と変更をレプリケート] の場合、ソースバケットでライフサイクルルールによって削除されたオブジェクトは、送信先バケットからは削除されません。
レプリケーションポリシーが [追加、変更、削除をレプリケート] の場合、ソースバケットでライフサイクルルールによって削除されたオブジェクトは、送信先バケットからも削除されます。
説明ライフサイクルルールによって削除されたソースオブジェクトと同じ名前のオブジェクトが送信先バケットにまだ存在する場合、それらは手動で送信先バケットに書き込まれた可能性があります。
履歴オブジェクトのレプリケーションの進捗が 0% のままなのはなぜですか。
レプリケーションの進捗はリアルタイムでは更新されません。
履歴オブジェクトのレプリケーションの進捗は、すべてのオブジェクトがスキャンされた後にのみ更新されます。数億個のオブジェクトを持つバケットの場合、これには数時間かかることがあります。進捗が 0% であっても、レプリケーションが開始されていないわけではありません。
送信先バケットのストレージ容量とトラフィックの変化を確認して、履歴オブジェクトのレプリケーションが開始されたかどうかを確認してください。「バケットレベルの使用量の照会」をご参照ください。
ソースバケットの認可ポリシーが正しくありません。
OSS はレプリケーションルール作成時に権限を検証しません。権限が正しくなくてもルールは作成されますが、データはレプリケートされず、進捗は 0% のままになります。
「データレプリケーションに必要な権限」をご参照ください。
データレプリケーションが遅い場合はどうすればよいですか。
帯域幅の増加
レプリケーションは非同期であり、データ量によっては数分から数時間かかることがあります。帯域幅の制限によりレプリケーションが遅い場合は、テクニカルサポートに連絡して帯域幅の増加をリクエストしてください。
レプリケーション時間制御 (RTC) の有効化
RTC を有効にすると、OSS はほとんどのオブジェクトを数秒以内に、99.99% を 10 分以内にレプリケートします。RTC が有効なタスクでは、データレプリケーションのトラフィック料金が発生します。「レプリケーション時間制御 (RTC) の使用」をご参照ください。
レプリケーション操作を追跡する方法
イベントタイプ ObjectReplication:ObjectCreated、ObjectReplication:ObjectRemoved、および ObjectReplication:ObjectModified を含むイベント通知ルールを設定することで、オブジェクトの作成、更新、削除、上書きを追跡できます。「イベント通知を使用した OSS オブジェクトの変更のリアルタイム監視」をご参照ください。
バージョニングが一時停止されたバケットでのレプリケーションはサポートされていますか。
いいえ。両方のバケットは、両方ともバージョニングが無効であるか、両方ともバージョニングが有効である必要があります。
レプリケーションのための KMS API 呼び出しは課金対象ですか。
はい。送信先バケットが KMS 暗号化を使用している場合、対応する KMS API 呼び出しに対して課金されます。「KMS 1.0 の課金」をご参照ください。
レプリケーションルールを無効にできますか。
はい。ルールの横にあるレプリケーションの無効化をクリックして、データレプリケーションを停止できます。
既存のレプリケートされたデータは送信先バケットに残りますが、ソースバケットに書き込まれた新しいデータはレプリケートされなくなります。
レプリケーションによってオブジェクトの順序は変わりますか。
いいえ。レプリケーションはオブジェクトの変更順序を保持します。