Data Transmission Service:Migrasi lintas akun

Batasan database sumber

• Kebutuhan bandwidth: Server yang menghosting database sumber harus memiliki bandwidth keluar yang mencukupi. Jika tidak, kecepatan migrasi data akan terpengaruh.

• Versi 2.8 Tair (Redis OSS-compatible) tidak didukung sebagai sumber.

• Jika hanya menjalankan migrasi penuh (tanpa inkremental), hentikan operasi tulis ke sumber selama migrasi untuk mencegah ketidakkonsistenan data.

• Saat memigrasikan dari sumber Edisi Dasar ke tujuan dengan arsitektur kluster, gunakan hanya operasi single-key. Perintah multi-key yang mencakup beberapa slot akan mengembalikan:

  CROSSSLOT Keys in request don't hash to the same slot

• DTS menyisipkan kunci dengan awalan DTS_REDIS_TIMESTAMP_HEARTBEAT ke sumber untuk melacak timestamp pembaruan. Jika sumber menggunakan arsitektur kluster, kunci ini disisipkan ke setiap shard. Kunci ini difilter selama migrasi dan kedaluwarsa setelah tugas selesai.

• Jika sumber adalah instans hanya baca atau akun DTS tidak memiliki izin SETEX, latensi yang dilaporkan mungkin tidak akurat.

• Untuk meningkatkan stabilitas migrasi, tingkatkan parameter repl-backlog-size dalam redis.conf.

• Jika sumber adalah instans Tair Edisi Perusahaan dengan Storage Medium diatur ke Persistent Memory, atur parameter appendonly ke yes. Untuk detailnya, lihat Prosedur.

• Jika sumber adalah instans anak dari Global Distributed Cache, DTS hanya memigrasikan instans anak tersebut. Instans anak lainnya tidak didukung.

Batasan lainnya

• Baik sumber maupun tujuan tidak mendukung instans penyimpanan kapasitas Tair (Redis OSS-compatible) Edisi Perusahaan.

• Jika enkripsi data transparan (TDE) diaktifkan pada salah satu instans, DTS tidak dapat melakukan migrasi.

• Jika tujuan kehabisan memori, kebijakan penggantian default (maxmemory-policy) adalah volatile-lru, yang dapat menyebabkan ketidakkonsistenan data. Untuk mencegah kehilangan data diam-diam, atur kebijakan penggantian tujuan ke noeviction. Dengan noeviction, operasi tulis gagal saat memori penuh dan tugas berhenti, tetapi tidak ada data yang dihapus diam-diam. Untuk detail kebijakan, lihat Pengantar kebijakan penggantian data Redis.

• Jika instans tujuan menggunakan arsitektur kluster dan salah satu shard mencapai batas memorinya, atau jika instans kehabisan ruang penyimpanan, tugas DTS gagal dengan error out-of-memory (OOM).

• Operasi penskalaan (menambah atau menghapus shard), perubahan spesifikasi, atau modifikasi titik akhir atau port pada salah satu instans selama migrasi akan mengganggu tugas. Jika hal ini terjadi, hapus semua data yang telah disinkronkan dari tujuan dan konfigurasi ulang tugas tersebut.

• Setelah event failover (termasuk alih bencana master/standby) pada tujuan, data mungkin hanya ditulis ke memori tanpa replikasi ke secondary, menyebabkan kehilangan data.

• Jika instans migrasi mencakup tugas penuh dan inkremental, me-restart instans tersebut dapat menyebabkan DTS menjalankan ulang kedua tugas tersebut.

• Me-restart instans migrasi dapat menyebabkan perintah non-idempoten (seperti INCRBY atau LPUSH) dieksekusi berulang kali, menyebabkan ketidakkonsistenan data.

• Untuk skrip Lua yang dipanggil melalui EVAL atau EVALSHA, DTS tidak dapat memastikan eksekusi berhasil selama migrasi inkremental.

• Untuk struktur data List, DTS tidak membersihkan data tujuan yang sudah ada saat menggunakan psync atau sync, yang dapat menghasilkan entri duplikat.

• Jika kunci di sumber memiliki kebijakan kedaluwarsa, jumlah kunci yang terlihat di tujuan (misalnya, melalui INFO) mungkin lebih rendah daripada sumber. Kunci tanpa kebijakan kedaluwarsa atau kunci yang belum kedaluwarsa konsisten antara sumber dan tujuan.

• Ketika Access Method diatur ke Public IP Address, Instance Mode tidak mendukung Cluster.

• Jalankan migrasi selama jam sepi. Migrasi penuh mengonsumsi sumber daya baca dan tulis pada kedua instans.

• Setelah migrasi penuh, ruang penyimpanan tujuan akan lebih besar daripada sumber karena operasi INSERT konkuren.

• DTS mencoba memulihkan tugas yang gagal secara otomatis hingga tujuh hari. Sebelum mengalihkan trafik ke tujuan, hentikan atau rilis tugas tersebut, atau cabut izin tulis akun DTS menggunakan REVOKE untuk mencegah tugas yang dipulihkan menimpa data tujuan.

• Jika instans Tair (Redis OSS-compatible) yang dienkripsi TLS terlibat, hubungkan ke DTS menggunakan SSL-encrypted (TLSv1.3 tidak didukung). Menghubungkan dengan SSL-encrypted ke sumber Alibaba Cloud Instance saat ini tidak didukung.

• Jika tugas gagal, staf dukungan DTS akan mencoba memulihkannya dalam waktu delapan jam. Pemulihan dapat melibatkan me-restart tugas atau menyesuaikan parameter tugas. Hanya parameter tugas DTS yang dimodifikasi—bukan parameter database. Untuk parameter yang dapat disesuaikan, lihat Modifikasi parameter instans.

Kasus khusus untuk sumber Redis yang dikelola sendiri

Saat Access Method sumber bukan Alibaba Cloud Instance:

• Alih bencana master/standby pada sumber menyebabkan kegagalan tugas.

• DTS menghitung latensi dengan membandingkan timestamp catatan terakhir yang dimigrasikan dengan waktu saat ini. Jika sumber tidak memiliki aktivitas DML dalam periode yang lama, latensi yang ditampilkan mungkin tidak akurat. Jalankan operasi DML pada sumber untuk memperbarui latensi. Jika memigrasikan seluruh database, gunakan tabel heartbeat yang menulis data setiap detik.

• Perubahan titik akhir Redis selama migrasi (misalnya, karena migrasi instans atau alih bencana master/standby) dapat menyebabkan percobaan ulang, penundaan, kegagalan, atau ketidakkonsistenan data. Pantau status tugas dan konfigurasi ulang jika muncul perilaku tidak normal.

Langkah 1: Buka daftar tugas migrasi

Masuk menggunakan akun tujuan dan navigasi ke daftar tugas migrasi data menggunakan salah satu metode berikut:

Langkah 2: Buat tugas

Klik Create Task untuk membuka halaman konfigurasi tugas.

Langkah 3: Konfigurasikan database sumber dan tujuan

Konfigurasikan parameter untuk kedua database sumber dan tujuan:

Nama tugas

Database sumber

Database tujuan

Langkah 4: Uji konektivitas

Klik Test Connectivity and Proceed di bagian bawah halaman.

Pastikan rentang IP layanan DTS telah ditambahkan ke pengaturan keamanan kedua instans. Lihat Tambahkan alamat IP server DTS ke daftar putih.

Jika salah satu instans dikelola sendiri (Access Method bukan Alibaba Cloud Instance), klik Test Connectivity di dialog CIDR Blocks of DTS Servers.

Langkah 5: Konfigurasikan objek migrasi

Di halaman Configure Objects, atur parameter berikut:

Parameter	Deskripsi
Migration Types	Pilih keduanya Full Data Migration dan Incremental Data Migration untuk migrasi tanpa downtime. Pilih hanya Full Data Migration jika akun DTS tidak memiliki izin SYNC/PSYNC pada sumber.
Processing Mode of Conflicting Tables	Precheck and Report Errors: Pemeriksaan awal memverifikasi bahwa tujuan kosong. Jika tidak, tugas tidak dimulai. Ignore Errors and Proceed: Melewati pemeriksaan tujuan kosong. Jika kunci di tujuan memiliki nama yang sama dengan kunci sumber, data sumber akan menimpa tujuan. Hal ini dapat menyebabkan kehilangan data—lanjutkan dengan hati-hati.
Source Objects	Klik objek di kotak Source Objects, lalu klik untuk memindahkannya ke Selected Objects. Pilih seluruh database atau gunakan penyaringan data untuk kunci tertentu.
Selected Objects	Untuk memetakan database (DB 0–255) atau menyaring berdasarkan awalan kunci, klik kanan database di Selected Objects dan konfigurasikan di dialog Edit Schema. Lihat Pemetaan skema dan Atur kondisi filter.

Klik Next Advanced Settings dan konfigurasikan hal berikut:

Klik Next Data Verification untuk mengonfigurasi verifikasi data. Untuk detail selengkapnya, lihat Mengonfigurasi tugas verifikasi data.

Langkah 6: Jalankan pemeriksaan awal

Klik Next: Save Task Settings and Precheck.

Untuk melihat pratinjau parameter API untuk konfigurasi ini, arahkan kursor ke tombol dan klik Preview OpenAPI parameters.

DTS menjalankan pemeriksaan awal sebelum memulai migrasi. Tugas hanya dimulai setelah pemeriksaan awal berhasil.

Jika pemeriksaan awal gagal, klik View Details di sebelah item yang gagal, perbaiki masalahnya, dan jalankan kembali pemeriksaan awal.

Jika muncul peringatan: untuk item yang tidak dapat dilewati, perbaiki masalah dan jalankan ulang. Untuk item yang dapat dilewati, klik Confirm Alert Details > Ignore > OK > Precheck Again. Mengabaikan peringatan dapat menyebabkan ketidakkonsistenan data.

Langkah 7: Beli dan mulai

1. Saat Success Rate mencapai 100%, klik Next: Purchase Instance.

2. Di halaman Purchase, pilih kelas instans:

   Parameter	Deskripsi
   Resource Group Settings	Pilih kelompok sumber daya untuk instans ini. Default: kelompok sumber daya default. Lihat Apa itu Resource Management?.
   Instance Class	Pilih spesifikasi berdasarkan volume dan kecepatan migrasi Anda. Lihat Spesifikasi tautan migrasi data.

3. Baca dan terima Data Transmission Service (Pay-as-you-go) Service Terms.

4. Klik Buy and Start, lalu klik OK di dialog konfirmasi.

Pantau kemajuan migrasi di halaman migrasi data.

Jika tugas mencakup migrasi penuh dan inkremental, tugas tersebut ditampilkan sebagai Incremental Data Migration di halaman daftar tugas migrasi.