Topik ini menjelaskan perilaku replikasi data—termasuk replikasi lintas wilayah (cross-region replication) dan Replikasi di Wilayah yang Sama (SRR)—saat digunakan bersama fitur-fitur seperti versioning, aturan siklus hidup (lifecycle rules), enkripsi sisi server (server-side encryption), dan kebijakan retensi (retention policies).
Replikasi data dengan pengendalian versi
Batasan berikut berlaku saat menggunakan replikasi data dengan versioning:
Aktifkan replikasi data hanya antara dua bucket yang memiliki status versioning yang sama, yaitu keduanya diaktifkan atau dinonaktifkan. Jangan mengubah status versioning bucket sumber atau tujuan selama proses sinkronisasi data berlangsung.
Jangan menjeda pengendalian versi untuk bucket sumber atau tujuan selama sinkronisasi data. Untuk menjeda pengendalian versi, Anda harus terlebih dahulu menghapus aturan replikasi data.
Ketika Anda menghapus objek dari bucket sumber yang telah diaktifkan versioning-nya, skenario berikut akan terjadi:
Jenis permintaan | Kebijakan sinkronisasi data | Hasil |
Permintaan Delete dikirim tanpa menentukan ID versi objek | Sinkronkan penambahan dan modifikasi | Objek tidak dihapus dari bucket sumber maupun tujuan. Sebagai gantinya, OSS membuat penanda hapus (delete marker) di bucket sumber. Penanda hapus ini kemudian direplikasi ke bucket tujuan. |
Sinkronkan penambahan, penghapusan, dan modifikasi | ||
Permintaan Delete dikirim dengan menentukan ID versi objek | Sinkronkan penambahan dan modifikasi | Objek hanya dihapus dari bucket sumber. Objek tidak dihapus dari bucket tujuan. |
Sinkronkan penambahan, penghapusan, dan modifikasi | Objek dihapus dari bucket sumber dan tujuan. |
Replikasi data dengan aturan siklus hidup
Replikasi data dengan versioning menghasilkan beberapa versi sebelumnya di bucket tujuan, yang meningkatkan konsumsi penyimpanan. Untuk mengurangi biaya penyimpanan, gunakan aturan siklus hidup (lifecycle rules) guna mengontrol biaya penyimpanan dan menerapkan kebijakan retensi data kustom.
Saat menggunakan replikasi data dengan aturan siklus hidup, perhatikan hal-hal berikut:
Replikasi data mereplikasi hasil penerapan aturan siklus hidup dari bucket sumber ke bucket tujuan, tetapi tidak mereplikasi aturan itu sendiri. Jika ingin bucket tujuan mengikuti aturan siklus hidup yang sama, Anda harus mengonfigurasi aturan identik pada bucket tujuan.
Replika objek di bucket tujuan mempertahankan waktu pembuatan objek aslinya di bucket sumber, bukan waktu saat objek direplikasi ke bucket tujuan.
Jika aturan siklus hidup menghapus objek di bucket sumber saat objek tersebut sedang dalam proses replikasi, replikasi objek tersebut mungkin tetap selesai. Dalam kasus ini, replika objek tetap disimpan di bucket tujuan.
Saat menggunakan replikasi lintas wilayah (cross-region replication) untuk bucket yang telah diaktifkan versioning-nya, penanda hapus (delete markers) dari bucket sumber direplikasi ke bucket tujuan. Operasi ini menjadikan penanda hapus sebagai versi terkini objek di bucket tujuan, sedangkan versi terkini sebelumnya menjadi versi noncurrent. Jika bucket tujuan memiliki aturan siklus hidup untuk menghapus versi noncurrent—misalnya, menghapusnya setelah satu hari—maka versi noncurrent objek tersebut akan dihapus secara permanen ketika kondisi tersebut terpenuhi. Oleh karena itu, berhati-hatilah saat mengonfigurasi aturan siklus hidup yang menghapus versi noncurrent untuk mencegah kehilangan data yang tidak disengaja di bucket tujuan.
Replikasi data dengan enkripsi sisi server
Replikasi data dalam akun yang sama mendukung objek yang tidak terenkripsi maupun objek yang dienkripsi menggunakan enkripsi sisi server dengan kunci yang dikelola oleh KMS atau kunci yang dikelola oleh OSS (SSE-OSS). Untuk informasi lebih lanjut, lihat Server-side encryption.
Saat menggunakan replikasi data dengan enkripsi sisi server, skenario berikut terjadi:
Status enkripsi objek sumber | Metode enkripsi bucket tujuan | Gunakan KMS untuk mengenkripsi objek tujuan | Metode enkripsi objek tujuan |
Tidak dienkripsi | Tidak dienkripsi | Tidak berpengaruh | Tetap tidak dienkripsi |
SSE-OSS | Tidak berpengaruh. | SSE-OSS | |
SSE-KMS, tanpa ID CMK yang ditentukan | Tidak berdampak | SSE-KMS, tanpa ID CMK yang ditentukan | |
SSE-KMS, dengan ID CMK1 yang ditentukan | Ya dengan SyncRole dan ID CMK2 dikonfigurasi | SSE-KMS, dengan ID CMK2 yang ditentukan | |
Tidak Mengonfigurasi SyncRole | SSE-KMS, dengan ID CMK1 yang ditentukan | ||
Enkripsi dengan kunci yang dikelola OSS (SSE-OSS) | Tidak ada batasan | Tidak berdampak | SSE-OSS |
Enkripsi dengan kunci yang dikelola KMS (SSE-KMS), tanpa ID CMK yang ditentukan | Tidak ada batasan | Ya dengan SyncRole dan ID CMK dikonfigurasi | SSE-KMS, dengan ID CMK yang ditentukan |
Tidak Mengonfigurasi SyncRole | SSE-KMS, tanpa ID CMK yang ditentukan | ||
Enkripsi dengan kunci yang dikelola KMS (SSE-KMS), dengan ID CMK yang ditentukan | Tidak ada batasan | Ya dengan SyncRole dan ID CMK dikonfigurasi | SSE-KMS, dengan ID CMK yang ditentukan |
Tidak dengan SyncRole dikonfigurasi | Tidak berlaku (Objek sumber tidak dapat direplikasi ke bucket tujuan) |
Replikasi data dengan kebijakan retensi
Setelah kebijakan retensi (WORM) untuk suatu bucket dikunci, Anda dapat mengunggah dan membaca objek di dalam bucket tersebut. Namun, Anda tidak dapat memodifikasi (menimpa) atau menghapus objek hingga periode retensinya berakhir.
Untuk informasi lebih lanjut tentang kebijakan retensi, lihat Retention policies.
Saat menggunakan replikasi data dengan kebijakan retensi, skenario berikut terjadi:
Apakah objek sumber dilindungi WORM? | Operasi yang diizinkan di bucket sumber | Apakah objek tujuan dilindungi WORM? | Apakah operasi tersebut direplikasi ke bucket tujuan? |
Tidak | Tambahkan objek | Ya | Tidak |
Timpa objek | Ya | Tidak | |
Hapus objek | Ya | Tidak | |
Tidak | Tambahkan objek | Tidak | Ya |
Timpa objek | Tidak | Ya | |
Hapus objek | Tidak | Ya | |
Ya | Tambahkan objek | Tidak berdampak. | Ya |