Bagian ini menjelaskan masalah umum dan solusi terkait replikasi data, termasuk replikasi dalam akun yang sama, lintas akun, wilayah yang sama, dan lintas wilayah.
Mengapa saya tidak dapat membuat aturan replikasi data?
Periksa apakah izin yang diperlukan telah diberikan.
Pengguna RAM kekurangan izin yang diperlukan.
Di Konsol, pengguna RAM tidak dapat mengklik OK untuk membuat aturan replikasi data.
Penyebab: Izin oss:PutBucketReplication hilang.
Solusi: Berikan izin oss:PutBucketReplication kepada pengguna RAM.
Ketika pengguna RAM membuat aturan replikasi data di konsol, peran yang dibuat secara kustom tidak ditampilkan dalam daftar peran otorisasi.
Penyebab: Izin ram:ListRoles hilang.
Solusi: Berikan izin ram:ListRoles kepada pengguna RAM.
Untuk informasi lebih lanjut, lihat Memberikan Kebijakan Akses Kustom kepada Pengguna RAM.
Peran RAM kekurangan izin yang diperlukan.
Replikasi dalam akun yang sama.
Untuk replikasi dalam akun yang sama, Anda harus memberikan izin peran untuk melakukan operasi replikasi antara Bucket sumber dan tujuan. Untuk informasi lebih lanjut tentang cara membuat dan memberikan izin kepada peran RAM, lihat Jenis-jenis Peran.
Replikasi lintas akun
Untuk replikasi lintas akun, Akun A harus memberikan izin kepada peran untuk mereplikasi data dari Bucket sumber, dan Akun B harus memberikan izin kepada peran untuk menerima objek yang direplikasi di Bucket tujuan. Untuk informasi lebih lanjut tentang pembuatan dan otorisasi peran RAM, lihat Otorisasi Peran.
Periksa apakah status Pengendalian Versi Bucket konsisten.
Status Pengendalian Versi Bucket sumber dan tujuan harus sama. Ini berarti bahwa Pengendalian Versi harus diaktifkan atau dinonaktifkan untuk kedua Bucket.
Periksa apakah Endpoint atau Informasi AccessKey benar.
Saat Anda membuat aturan replikasi data menggunakan SDK atau ossutil, periksa konfigurasi berikut:
Periksa apakah Endpoint wilayah tempat Bucket sumber dan tujuan berada sudah benar. Untuk informasi lebih lanjut, lihat Wilayah dan Endpoint OSS.
Periksa apakah AccessKey yang digunakan untuk membangun hubungan replikasi sudah benar. Untuk informasi lebih lanjut, lihat Lihat Pasangan Kunci Akses Pengguna RAM.
Mengapa data tidak direplikasi ke Bucket tujuan?
Jika replika objek tidak muncul di Bucket tujuan setelah Anda mengonfigurasi aturan replikasi data untuk Bucket sumber, lakukan pemecahan masalah berdasarkan kemungkinan penyebab berikut.
Periksa apakah Bucket sumber dikonfigurasikan dengan benar.
Periksa apakah status replikasi data adalah Diaktifkan.
Periksa apakah awalan sudah benar.
Replikasi objek tertentu: Untuk mereplikasi hanya objek tertentu dari Bucket sumber, atur parameter Prefix ke awalan file target. Misalnya, jika Anda mengatur Prefix ke log, hanya objek dengan nama yang dimulai dengan log, seperti log/date1.txt dan log/date2.txt, yang akan direplikasi. Objek yang tidak cocok dengan awalan yang ditentukan, seperti date3.txt, tidak akan direplikasi.
CatatanAwalan tidak boleh diakhiri dengan tanda bintang (*) atau berisi nama Bucket.
Replikasi semua objek: Untuk mereplikasi semua objek dari Bucket sumber, biarkan parameter Prefix kosong.
Konfirmasikan apakah replikasi data historis dikonfigurasikan dan jika file historis tidak disinkronkan.
Konfirmasikan apakah file di Bucket sumber direplikasi dari Bucket lain menggunakan replikasi wilayah yang sama atau lintas wilayah.
Jika sebuah objek di Bucket adalah replika dari aturan replikasi lain, OSS tidak akan mereplikasi objek ini lagi. Misalnya, jika Anda mengonfigurasi replikasi dari Bucket A ke Bucket B dan dari Bucket B ke Bucket C, replika objek dari Bucket A tidak akan direplikasi dari Bucket B ke Bucket C.
Konfirmasikan apakah file dienkripsi menggunakan KMS. Jika ya, Anda harus memilih opsi Replikasi objek yang dienkripsi dengan KMS.
Jika objek sumber atau Bucket tujuan dienkripsi dengan enkripsi sisi server dengan kunci yang dikelola oleh KMS (SSE-KMS) dan ID kunci master pelanggan (CMK) ditentukan, Anda harus memilih Replicate dan mengonfigurasi parameter berikut:
KMS Key To Use: Menentukan kunci KMS yang digunakan untuk mengenkripsi objek tujuan.
Anda harus terlebih dahulu membuat kunci KMS di wilayah yang sama dengan Bucket tujuan di platform KMS. Untuk informasi lebih lanjut, lihat Buat Kunci.
Authorization Role: Peran RAM yang berwenang untuk melakukan enkripsi KMS pada objek tujuan.
Create Role: Membuat peran RAM untuk mengenkripsi objek tujuan menggunakan KMS. Nama peran harus menggunakan format
kms-replication-SourceBucketName-DestinationBucketName.AliyunOSSRole: Peran yang digunakan untuk mengenkripsi objek tujuan dengan KMS. Jika peran ini tidak ada, OSS secara otomatis membuatnya ketika Anda memilih opsi ini.
CatatanJika Anda membuat peran atau memodifikasi izin peran, pastikan bahwa izin
AliyunOSSFullAccessdiberikan kepada peran tersebut. Jika tidak, replikasi data mungkin gagal.
Anda dapat memanggil operasi HeadObject dan GetBucketEncryption untuk menanyakan status enkripsi objek sumber dan Bucket tujuan, masing-masing.
Periksa apakah kemajuan replikasi adalah 100%.
Replikasi data bersifat asinkron dan terjadi hampir real-time. Waktu yang diperlukan untuk mereplikasi data ke Bucket tujuan bisa berkisar dari beberapa menit hingga beberapa jam, tergantung pada ukuran data. Jika objek yang akan direplikasi besar, tunggu hingga replikasi selesai. Setelah Anda memastikan bahwa kemajuan replikasi data adalah 100%, periksa apakah objek tersebut ada di Bucket tujuan.
Mengapa data tidak dihapus dari Bucket tujuan secara sinkron?
Penyebab 1: Kebijakan Retensi Write-Once-Read-Many (WORM) dikonfigurasikan untuk Bucket tujuan.
Sebelum periode retensi yang ditentukan dalam kebijakan berakhir, tidak ada pengguna, termasuk pemilik sumber daya, yang dapat menghapus objek di Bucket.
Penyebab 2: Apakah data dihapus dari Bucket tujuan bergantung pada status Pengendalian Versi Bucket sumber dan kebijakan replikasi data yang dikonfigurasikan.
Status Versioning Bucket Sumber
Metode permintaan
Kebijakan replikasi data
Hasil
Pengendalian versi dinonaktifkan
Permintaan Hapus diajukan
Replikasi data yang dibuat/dimodifikasi
Hanya objek di Bucket sumber yang dihapus. Objek di Bucket tujuan tidak dihapus.
Replikasi data yang dibuat/dihapus/dimodifikasi
Objek di Bucket sumber dan tujuan dihapus secara sinkron.
Pengendalian versi diaktifkan
Permintaan Hapus diajukan tanpa menentukan ID versi objek
Replikasi data yang dibuat/dimodifikasi
Objek di Bucket sumber dan tujuan tidak dihapus. OSS membuat penanda hapus di Bucket sumber, dan penanda hapus direplikasi ke Bucket tujuan.
Replikasi data yang dibuat/dihapus/dimodifikasi
Permintaan Hapus diajukan dengan ID versi objek ditentukan
Replikasi data yang dibuat/dimodifikasi
Hanya objek di Bucket sumber yang dihapus. Objek di Bucket tujuan tidak dihapus.
Replikasi data yang dibuat/dihapus/dimodifikasi
Objek di Bucket sumber dan tujuan dihapus secara sinkron.
Bagaimana cara memverifikasi konsistensi data antara Bucket sumber dan tujuan setelah replikasi selesai?
Anda dapat menggunakan kode berikut untuk memverifikasi konsistensi data antara Bucket sumber dan 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 sampel ini, pastikan variabel lingkungan OSS_ACCESS_KEY_ID dan OSS_ACCESS_KEY_SECRET telah diatur.
EnvironmentVariableCredentialsProvider credentialsProvider = CredentialsProviderFactory.newEnvironmentVariableCredentialsProvider();
// Atur srcEndpoint ke Endpoint wilayah tempat Bucket berada.
String srcEndpoint = "https://oss-cn-hangzhou.aliyuncs.com";
OSSClient srcClient = new OSSClient(srcEndpoint , credentialsProvider);
// Tentukan nama Bucket sumber.
String srcBucketName = "src-replication-bucket";
// Atur destEndpoint ke Endpoint wilayah tempat Bucket 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 Pengendalian versi dinonaktifkan untuk Bucket sumber dan tujuan, panggil operasi listObjectsV2 untuk mencantumkan file yang direplikasi di Bucket sumber.
// Jika Pengendalian versi diaktifkan atau ditangguhkan untuk Bucket sumber dan tujuan, panggil operasi listVersions untuk mencantumkan file yang direplikasi 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 file yang direplikasi di Bucket 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 file yang direplikasi ke 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 file yang direplikasi di Bucket sumber dan tujuan sama.
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 nilai MD5 file yang direplikasi di Bucket sumber dan tujuan sama.
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 file yang direplikasi di Bucket sumber dan tujuan sama.
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 transitif didukung?
Tidak, tidak didukung. Misalnya, jika aturan replikasi data dikonfigurasikan dari Bucket A ke Bucket B dan aturan lain dikonfigurasikan dari Bucket B ke Bucket C, data dari Bucket A hanya direplikasi ke Bucket B, bukan ke Bucket C.
Jika Anda ingin mereplikasi data dari Bucket A ke Bucket C, Anda juga harus mengonfigurasikan aturan replikasi data dari Bucket A ke Bucket C.
Jika replikasi data historis diaktifkan untuk Bucket A dan Bucket B, data baru yang ditulis ke Bucket A mungkin dipindai oleh tugas replikasi historis dan direplikasi ke Bucket C sebelum replikasi data historis selesai.
Apakah ada risiko loop replikasi dalam sinkronisasi dua arah untuk Bucket OSS?
Tidak, tidak ada. Setelah hubungan replikasi dua arah dikonfigurasikan antara Bucket A dan Bucket B, data yang direplikasi dari Bucket A ke Bucket B tidak direplikasi kembali ke Bucket A. Ini berlaku untuk data baru dan historis. Demikian pula, data yang direplikasi dari Bucket B ke Bucket A tidak direplikasi kembali ke Bucket B.
Jika file di Bucket sumber dihapus berdasarkan aturan siklus hidup, apakah file-file ini juga dihapus dari Bucket tujuan?
Jika kebijakan replikasi data untuk Bucket sumber diatur ke Replicate Created/modified Data, file yang dihapus dari Bucket sumber oleh aturan siklus hidup tidak juga dihapus dari Bucket tujuan.
Jika kebijakan replikasi untuk Bucket sumber diatur ke Replicate Created/deleted/modified Data, file yang dihapus dari Bucket sumber oleh aturan siklus hidup juga dihapus dari Bucket tujuan.
CatatanJika Anda menemukan file di Bucket tujuan yang dihapus dari Bucket sumber oleh aturan siklus hidup, itu tidak selalu berarti bahwa kebijakan Replicate Created/deleted/modified Data tidak efektif. Hal ini bisa terjadi jika Anda secara manual menulis file dengan nama yang sama ke Bucket tujuan.
Mengapa kemajuan replikasi data historis tetap pada 0% untuk waktu yang lama?
Kemajuan replikasi tidak diperbarui secara real-time.
Kemajuan replikasi data historis tidak diperbarui secara real-time. Kemajuan hanya diperbarui setelah semua file dipindai. Jika Bucket Anda berisi banyak file, seperti ratusan juta, Anda mungkin perlu menunggu beberapa jam agar kemajuan diperbarui. Bilah kemajuan yang belum diperbarui tidak berarti bahwa data historis tidak sedang direplikasi ke Bucket tujuan.
Anda dapat memeriksa perubahan kapasitas penyimpanan Bucket tujuan dan lalu lintas replikasi untuk memastikan apakah data historis dari Bucket sumber sedang direplikasi. Untuk informasi lebih lanjut tentang cara melihat kapasitas penyimpanan dan lalu lintas replikasi Bucket, lihat Kueri Penggunaan Bucket.
Kebijakan otorisasi untuk Bucket sumber salah.
Saat Anda membuat aturan replikasi data, kebijakan otorisasi Bucket sumber tidak diperiksa. Akibatnya, aturan dapat dibuat, tetapi data tidak direplikasi ke Bucket tujuan, dan kemajuan replikasi tetap pada 0%.
Untuk mengonfigurasi kebijakan akses yang benar, lihat Izin Replikasi Data.
Apa yang harus saya lakukan jika replikasi data lambat?
Tingkatkan bandwidth
Replikasi data bersifat asinkron dan terjadi hampir real-time. Dapat memakan waktu beberapa menit hingga beberapa jam untuk mentransfer data dari Bucket sumber ke Bucket tujuan, tergantung pada ukuran data. Jika proses replikasi memakan waktu terlalu lama, periksa apakah tugas replikasi tertunda karena batasan bandwidth. Jika masalah disebabkan oleh bandwidth yang tidak mencukupi, kami sarankan Anda menghubungi Dukungan Teknis untuk meminta peningkatan bandwidth guna mengoptimalkan efisiensi replikasi.
Aktifkan kontrol waktu replikasi (RTC).
Setelah Anda mengaktifkan RTC, OSS mereplikasi sebagian besar objek yang Anda unggah dalam hitungan detik dan mereplikasi 99,99% objek dalam waktu 10 menit. Setelah Anda mengaktifkan RTC, Anda akan dikenakan biaya untuk lalu lintas replikasi data yang dihasilkan oleh aturan replikasi untuk mana RTC diaktifkan. Untuk informasi lebih lanjut, lihat Gunakan Kontrol Waktu Replikasi (RTC).
Bagaimana cara mengetahui operasi replikasi data apa yang dilakukan pada Bucket sumber dan tujuan?
Anda dapat memperoleh informasi tentang perubahan di Bucket sumber dan tujuan selama replikasi data, seperti pembuatan objek, pembaruan, penghapusan, dan penimpaan. Untuk melakukannya, konfigurasikan aturan notifikasi acara dan atur jenis acara ke ObjectReplication:ObjectCreated, ObjectReplication:ObjectRemoved, dan ObjectReplication:ObjectModified. Untuk informasi lebih lanjut, lihat Gunakan Notifikasi Acara untuk Memproses Perubahan Objek OSS secara Real-Time.
Apakah replikasi data didukung untuk Bucket yang Pengendalian versinya ditangguhkan?
Tidak, tidak didukung. Anda hanya dapat mengaktifkan replikasi data untuk dua Bucket yang keduanya memiliki Pengendalian Versi yang dinonaktifkan atau diaktifkan.
Jika Bucket tujuan dienkripsi menggunakan KMS, apakah saya dikenakan biaya untuk panggilan API algoritma enkripsi KMS?
Ya, Anda dikenakan biaya. Jika Bucket tujuan dienkripsi menggunakan KMS, Anda dikenakan biaya untuk panggilan API algoritma enkripsi KMS. Untuk informasi lebih lanjut tentang biaya, lihat Penagihan KMS.
Bisakah saya menonaktifkan replikasi data setelah diaktifkan?
Ya, Anda bisa. Klik Disable Replication di sebelah kanan aturan.
Setelah replikasi dinonaktifkan, data yang direplikasi tetap ada di Bucket tujuan. Data tambahan di Bucket sumber tidak lagi direplikasi ke Bucket tujuan.