Topik ini menjawab pertanyaan umum mengenai replikasi data dalam akun yang sama dan lintas akun di Object Storage Service (OSS), mencakup skenario dalam satu wilayah maupun lintas wilayah, serta menyediakan panduan troubleshooting.
Mengapa saya tidak dapat membuat aturan replikasi data?
Periksa apakah Anda memiliki izin yang diperlukan.
Izin Pengguna RAM tidak lengkap
Saat menggunakan konsol sebagai Pengguna RAM untuk membuat aturan replikasi data, Anda tidak dapat mengklik OK.
Penyebab: Izin oss:PutBucketReplication tidak tersedia.
Solusi: Berikan izin oss:PutBucketReplication kepada Pengguna RAM tersebut.
Saat menggunakan konsol sebagai Pengguna RAM untuk membuat aturan replikasi data, daftar Nama Peran RAM tidak menampilkan peran RAM kustom.
Penyebab: Izin ram:ListRoles tidak tersedia.
Solusi: Berikan izin ram:ListRoles kepada Pengguna RAM tersebut.
Untuk informasi lebih lanjut, lihat Menyambungkan kebijakan kustom ke Pengguna RAM.
Izin Peran RAM tidak lengkap
Replikasi dalam akun yang sama
Untuk replikasi dalam akun yang sama, Anda harus memberikan izin kepada peran RAM agar dapat mereplikasi data antara bucket sumber dan bucket tujuan. Untuk informasi lebih lanjut mengenai cara membuat dan memberi otorisasi peran RAM, lihat Memilih peran RAM.
Replikasi lintas akun
Untuk replikasi lintas akun, Anda harus memberikan izin di kedua akun—sumber dan tujuan. Akun sumber harus memberikan izin peran RAM untuk mereplikasi data dari bucket sumber, dan akun tujuan harus memberikan izin untuk menerima objek di bucket tujuan. Untuk informasi lebih lanjut mengenai cara membuat dan memberi otorisasi peran RAM, lihat Metode.
Periksa apakah status versioning bucket konsisten.
Bucket sumber dan bucket tujuan harus memiliki status versioning yang sama (baik diaktifkan maupun dinonaktifkan).
Periksa apakah informasi endpoint atau access key benar.
Saat membuat aturan replikasi data menggunakan SDK atau ossutil, periksa konfigurasi berikut:
Verifikasi bahwa endpoint untuk wilayah bucket sumber dan bucket tujuan sudah benar. Untuk informasi lebih lanjut, lihat Wilayah dan endpoint.
Verifikasi bahwa access key yang digunakan untuk menetapkan hubungan replikasi sudah benar. Untuk informasi lebih lanjut, lihat Melihat detail pasangan access key.
Mengapa objek tidak direplikasi ke bucket tujuan?
Jika objek tidak direplikasi ke bucket tujuan setelah Anda mengonfigurasi aturan replikasi data, periksa kemungkinan penyebab berikut.
Verifikasi konfigurasi bucket sumber.
Periksa apakah status replikasi data diatur ke Enabled.
Periksa apakah awalan (prefix) sudah benar.
Replikasi objek tertentu: Untuk mereplikasi objek tertentu dari bucket sumber ke bucket tujuan, atur prefix sesuai dengan awalan objek yang diinginkan. Misalnya, jika Anda mengatur prefix menjadi
log, hanya objek yang namanya diawali denganlog, sepertilog/date1.txtdanlog/date2.txt, yang akan direplikasi. Objek yang tidak sesuai dengan prefix, sepertidate3.txt, tidak akan direplikasi.CatatanPrefix tidak boleh diakhiri dengan tanda bintang (*), misalnya
log/*, dan tidak boleh berisi nama bucket.Replikasi semua objek: Untuk mereplikasi semua objek dari bucket sumber ke bucket tujuan, biarkan prefix kosong.
Periksa apakah Anda telah mengonfigurasi replikasi untuk objek yang sudah ada. Objek yang sudah ada tidak akan direplikasi kecuali opsi ini diaktifkan.
Periksa apakah objek di bucket sumber merupakan hasil replikasi dari bucket lain.
Jika suatu objek di bucket merupakan replika yang dibuat oleh konfigurasi replikasi lain, Object Storage Service (OSS) tidak akan mereplikasi ulang objek tersebut. Misalnya, jika Anda mengonfigurasi replikasi dari bucket A ke bucket B, lalu dari bucket B ke bucket C, OSS tidak akan mereplikasi objek dari bucket B ke bucket C yang awalnya direplikasi dari bucket A.
Periksa apakah objek dienkripsi menggunakan Key Management Service (KMS). Jika iya, Anda harus mengaktifkan replikasi untuk objek yang dienkripsi KMS.
Jika enkripsi sisi server dengan kunci yang dikelola KMS (SSE-KMS) digunakan untuk objek sumber atau bucket tujuan, Anda harus mengaktifkan replication of KMS-encrypted objects dan mengonfigurasi parameter berikut:
KMS Key: Tentukan kunci KMS untuk mengenkripsi objek tujuan.
Anda harus membuat kunci KMS di wilayah yang sama dengan bucket tujuan terlebih dahulu. Untuk informasi lebih lanjut, lihat Membuat CMK.
RAM Role: Otorisasi peran RAM untuk melakukan enkripsi KMS pada objek tujuan.
New RAM Role: Buat peran RAM baru untuk melakukan enkripsi KMS pada objek tujuan. Nama peran menggunakan format
kms-replication-SourceBucketName-DestinationBucketName.AliyunOSSRole: Gunakan peran AliyunOSSRole untuk melakukan enkripsi KMS pada objek tujuan. Jika Anda belum membuat peran AliyunOSSRole, OSS akan membuatnya secara otomatis saat Anda memilih opsi ini.
CatatanJika Anda membuat peran atau mengubah izin peran, sambungkan kebijakan
AliyunOSSFullAccesske peran tersebut. Jika tidak, replikasi data dapat gagal.
Anda dapat memanggil operasi HeadObject dan GetBucketEncryption untuk mengecek status enkripsi objek sumber dan bucket tujuan, secara berturut-turut.
Periksa apakah progres replikasi telah mencapai 100%.
Replikasi data bersifat asinkron dan terjadi hampir secara real time. Waktu yang dibutuhkan untuk mereplikasi data ke bucket tujuan dapat berkisar dari beberapa menit hingga beberapa jam, tergantung pada volume data. Jika Anda mereplikasi objek besar, tunggu hingga progres replikasi mencapai 100% sebelum memeriksa apakah objek tersebut muncul di bucket tujuan.
Mengapa objek tidak dihapus dari bucket tujuan setelah dihapus dari bucket sumber?
Alasan 1: Bucket tujuan memiliki kebijakan retensi yang diaktifkan.
Sebelum periode retensi dalam kebijakan retensi berakhir, tidak ada pengguna—termasuk pemilik sumber daya—yang dapat menghapus objek dari bucket tersebut.
Alasan 2: Apakah objek dihapus dari bucket tujuan bergantung pada status versioning bucket sumber dan kebijakan replikasi data yang dikonfigurasi.
Status versioning bucket sumber
Jenis permintaan
Kebijakan replikasi data
Hasil
Versioning dinonaktifkan
Permintaan penghapusan diajukan
Add/Change
Objek hanya dihapus dari bucket sumber, bukan dari bucket tujuan.
Add/Delete/Change
Objek dihapus dari kedua bucket—sumber dan tujuan.
Versioning diaktifkan
Permintaan penghapusan diajukan tanpa menentukan ID versi objek
Add/Change
Objek tidak dihapus dari kedua bucket. Sebagai gantinya, OSS membuat penanda hapus di bucket sumber, dan penanda hapus ini direplikasi ke bucket tujuan.
Add/Delete/Change
Permintaan penghapusan diajukan dengan ID versi objek tertentu
Add/Change
Objek hanya dihapus dari bucket sumber, bukan dari bucket tujuan.
Add/Delete/Change
Objek dihapus dari kedua bucket—sumber dan tujuan.
Bagaimana cara memverifikasi konsistensi data antara bucket sumber dan bucket tujuan setelah replikasi selesai?
Anda dapat menjalankan kode berikut untuk memverifikasi konsistensi data antara bucket sumber dan bucket tujuan setelah replikasi selesai.
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 {
// Dapatkan kredensial akses dari variabel lingkungan. Sebelum menjalankan kode ini, pastikan variabel lingkungan OSS_ACCESS_KEY_ID dan OSS_ACCESS_KEY_SECRET telah disetel.
EnvironmentVariableCredentialsProvider credentialsProvider = CredentialsProviderFactory.newEnvironmentVariableCredentialsProvider();
// Ganti srcEndpoint dengan endpoint wilayah tempat bucket sumber berada.
String srcEndpoint = "https://oss-cn-hangzhou.aliyuncs.com";
OSSClient srcClient = new OSSClient(srcEndpoint , credentialsProvider);
// Tentukan nama bucket sumber.
String srcBucketName = "src-replication-bucket";
// Ganti destEndpoint dengan endpoint wilayah tempat bucket tujuan berada.
String destEndpoint = "https://oss-cn-beijing.aliyuncs.com";
OSSClient destClient = new OSSClient(destEndpoint, credentialsProvider);
// Tentukan nama bucket tujuan.
String destBucketName = "dest-replication-bucket";
// Jika bucket sumber dan tujuan tidak memiliki versioning yang diaktifkan, panggil listObjectsV2 untuk mencantumkan objek di bucket sumber.
// Jika versioning diaktifkan atau ditangguhkan untuk bucket sumber dan tujuan, panggil listVersions untuk mencantumkan objek di bucket sumber.
ListObjectsV2Result result;
ListObjectsV2Request request = new ListObjectsV2Request(srcBucketName);
do {
result = srcClient.listObjectsV2(request);
for (OSSObjectSummary summary : result.getObjectSummaries())
{
String objectName = summary.getKey();
ObjectMetadata srcMeta;
try {
// Dapatkan metadata objek sumber.
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 {
// Dapatkan metadata objek yang direplikasi di bucket tujuan.
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;
}
// Periksa apakah nilai CRC objek sumber dan tujuan konsisten.
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;
}
}
// Periksa apakah hash MD5 objek sumber dan tujuan konsisten.
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;
}
}
// Periksa apakah ETag objek sumber dan tujuan konsisten.
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());
}
}
Apakah replikasi berantai didukung?
Tidak. Misalnya, jika Anda mengonfigurasi aturan replikasi data dari bucket A ke bucket B, dan aturan lain dari bucket B ke bucket C, data dari bucket A hanya direplikasi ke bucket B, bukan ke bucket C.
Untuk mereplikasi data dari bucket A ke bucket C, Anda juga harus mengonfigurasi aturan replikasi data dari bucket A ke bucket C.
Jika baik bucket A maupun bucket B telah mengaktifkan replikasi objek historis, dan replikasi historis masih berlangsung, pekerjaan replikasi historis tersebut mungkin memindai beberapa data baru yang ditulis ke bucket A lalu mereplikasinya ke bucket C.
Apakah replikasi dua arah antara bucket OSS menimbulkan risiko replikasi melingkar?
Tidak. Jika Anda mengonfigurasi replikasi dua arah antara bucket A dan bucket B, data yang direplikasi dari bucket A ke bucket B tidak akan direplikasi kembali dari B ke A. Aturan yang sama berlaku untuk data yang direplikasi dari B ke A.
Jika objek di bucket sumber dihapus oleh aturan siklus hidup, apakah objek tersebut juga dihapus dari bucket tujuan?
Jika kebijakan replikasi data untuk bucket sumber diatur ke Add/Change, objek yang dihapus dari bucket sumber oleh aturan siklus hidup tidak dihapus dari bucket tujuan.
Jika kebijakan replikasi data untuk bucket sumber diatur ke Add/Delete/Change, objek yang dihapus dari bucket sumber oleh aturan siklus hidup juga dihapus dari bucket tujuan.
CatatanJika Anda menemukan objek di bucket tujuan yang telah dihapus dari bucket sumber oleh aturan siklus hidup, hal ini tidak berarti kebijakan Add/Delete/Change tidak efektif. Kemungkinan Anda secara manual menulis objek dengan nama yang sama ke bucket tujuan.
Mengapa progres replikasi untuk data yang sudah ada tetap 0% dalam waktu lama?
Progres replikasi tidak diperbarui secara real time
OSS hanya memperbarui progres replikasi untuk data yang sudah ada setelah memindai semua objek. Jika bucket Anda berisi jumlah objek yang sangat besar, misalnya ratusan juta, pembaruan progres dapat memakan waktu beberapa jam. Progres 0% tidak selalu berarti replikasi belum dimulai.
Anda dapat memeriksa apakah data yang sudah ada dari bucket sumber telah mulai direplikasi ke bucket tujuan dengan memantau perubahan kapasitas penyimpanan dan trafik replikasi bucket tujuan. Untuk informasi lebih lanjut mengenai cara memantau metrik ini, lihat Melihat penggunaan sumber daya bucket.
Kebijakan izin bucket sumber salah
OSS saat ini tidak memvalidasi izin bucket sumber saat Anda membuat aturan replikasi data. Hal ini memungkinkan Anda berhasil membuat aturan, tetapi tidak ada data yang direplikasi ke bucket tujuan, sehingga progres replikasi tetap 0%.
Untuk mengonfigurasi kebijakan izin yang benar, lihat Izin yang diperlukan untuk replikasi data.
Apa yang dapat saya lakukan jika replikasi data lambat?
Tingkatkan bandwidth
Replikasi data bersifat asinkron dan terjadi hampir secara real time. Waktu yang dibutuhkan untuk mentransfer data dari bucket sumber ke bucket tujuan dapat berkisar dari beberapa menit hingga beberapa jam, tergantung pada volume data. Jika replikasi memakan waktu terlalu lama, periksa adanya batasan bandwidth yang mungkin menyebabkan penundaan. Jika bandwidth menjadi masalah, hubungi technical support untuk meminta peningkatan bandwidth dan meningkatkan kinerja replikasi.
Aktifkan Replication Time Control (RTC)
Saat Anda mengaktifkan Replication Time Control (RTC), OSS mereplikasi sebagian besar objek dalam hitungan detik dan 99,99% objek dalam waktu 10 menit. Setelah mengaktifkan RTC, Anda akan dikenai biaya atas trafik replikasi data yang dihasilkan oleh tugas yang diaktifkan RTC. Untuk informasi lebih lanjut, lihat Menggunakan Replication Time Control (RTC).
Bagaimana cara melacak operasi replikasi yang dilakukan pada bucket sumber dan tujuan?
Anda dapat mengonfigurasi aturan notifikasi event dan mengatur jenis event menjadi ObjectReplication:ObjectCreated, ObjectReplication:ObjectRemoved, dan ObjectReplication:ObjectModified. Hal ini memungkinkan Anda menerima notifikasi mengenai perubahan objek di bucket sumber dan tujuan selama replikasi, seperti pembuatan, pembaruan, penghapusan, dan penimpaan objek. Untuk informasi lebih lanjut, lihat Menggunakan notifikasi event untuk memantau perubahan objek secara real time.
Apakah replikasi data didukung untuk bucket dengan versioning yang ditangguhkan?
Tidak. Anda hanya dapat mengonfigurasi replikasi data antara dua bucket yang keduanya memiliki versioning dinonaktifkan atau keduanya memiliki versioning diaktifkan.
Jika bucket tujuan menggunakan enkripsi KMS, apakah saya dikenai biaya atas panggilan API kriptografi KMS?
Ya. Jika bucket tujuan menggunakan enkripsi KMS, Anda akan dikenai biaya atas panggilan API kriptografi KMS. Untuk informasi lebih lanjut, lihat Penagihan KMS.
Dapatkah saya menonaktifkan aturan replikasi data setelah diaktifkan?
Ya. Anda dapat menghentikan replikasi data dengan mengklik Disable Replication di samping aturan tersebut.
Setelah Anda menonaktifkan aturan tersebut, bucket tujuan tetap menyimpan semua data yang sebelumnya telah direplikasi, tetapi OSS tidak lagi mereplikasi data baru dari bucket sumber.
Apakah replikasi mengubah urutan objek?
Tidak, replikasi tidak mengubah urutan modifikasi objek.