All Products
Search

This Product

    Lindorm:Sinkronisasi dan migrasi data HBase

    Document Center

    Lindorm:Sinkronisasi dan migrasi data HBase

    Last Updated:Jul 17, 2026

    Jika Anda ingin melakukan migrasi atau sinkronisasi data dari kluster HBase yang dikelola sendiri atau kluster ApsaraDB untuk HBase ke Lindorm wide table engine, Anda dapat menggunakan Lindorm Tunnel Service (LTS) untuk menyelesaikan migrasi data historis dan sinkronisasi data real-time. Topik ini menjelaskan skenario penggunaan, fitur, keunggulan migrasi, batasan penggunaan, serta tugas migrasi terkait sinkronisasi dan migrasi data HBase.

    Skenario penggunaan

    • Migrasi HBase yang dikelola sendiri ke cloud: Migrasikan data HBase ke Lindorm.

    • Migrasi lintas wilayah: Misalnya, migrasi dari wilayah Tiongkok (Qingdao) ke wilayah Tiongkok (Beijing).

    • Pemisahan bisnis: Migrasikan sebagian bisnis ke kluster baru.

    Fitur dan keunggulan

    Fitur

    • Mendukung migrasi tanpa downtime dari HBase 1.x dan 2.x ke Lindorm.

    • Mendukung migrasi skema tabel, sinkronisasi data real-time, dan migrasi data historis.

    • Mendukung migrasi tingkat database, tingkat namespace, dan tingkat tabel.

    • Mendukung penggantian nama tabel selama migrasi.

    • Mendukung penentuan rentang waktu, rentang rowkey, dan kolom tertentu untuk migrasi.

    • Menyediakan OpenAPI untuk membuat tugas migrasi.

    Keunggulan migrasi

    • Migrasi data tanpa downtime yang menyelesaikan migrasi data historis sekaligus sinkronisasi data inkremental real-time.

    • Selama migrasi, HBase yang dikelola sendiri tidak berinteraksi langsung dengan kluster HBase sumber. LTS hanya membaca HDFS dari kluster sumber, sehingga secara efektif mengurangi dampak terhadap bisnis online di kluster sumber.

    • Penyalinan data pada lapisan file lebih efisien dibandingkan migrasi data pada lapisan API, biasanya menghemat lebih dari 50% traffic.

    • Satu node tunggal dapat mencapai kecepatan migrasi hingga 150 MB/s. Jumlah node mendukung skalabilitas horizontal untuk memenuhi kebutuhan migrasi data tingkat TB atau PB.

    • Menyediakan mekanisme retry error yang komprehensif, pemantauan waktu nyata terhadap kecepatan dan progres tugas, serta mendukung peringatan saat tugas gagal.

    • Secara otomatis menyinkronkan skema untuk memastikan konsistensi partisi.

    Batasan

    • Migrasi ke HBase yang dikelola sendiri tidak didukung.

    • Kluster yang mengaktifkan Kerberos tidak didukung.

    • Instans ApsaraDB untuk HBase single-node tidak didukung.

    • Instans ApsaraDB untuk HBase dalam jaringan klasik tidak didukung karena keterbatasan jaringan.

    • Migrasi atau sinkronisasi ke instans mandiri Lindorm tidak didukung.

    • Sinkronisasi data inkremental diimplementasikan berdasarkan HBase WAL untuk sinkronisasi data asinkron. Data yang dimuat melalui bulkload dan data yang tidak ditulis ke WAL tidak akan disinkronkan.

    • Hanya LTS versi 3.8.10 ke atas yang mendukung migrasi indeks pencarian dalam tabel.

    Tindakan pencegahan

    • Sebelum migrasi, pastikan kapasitas HDFS pada kluster tujuan mencukupi untuk mencegah kapasitas penuh selama proses migrasi.

    • Jika kluster sumber adalah kluster HBase yang dikelola sendiri atau kluster ApsaraDB untuk HBase, sebelum mengirimkan sinkronisasi inkremental, kami menyarankan agar Anda mengatur waktu retensi log kluster sumber menjadi lebih dari 12 jam untuk menyediakan waktu pemrosesan dan pemulihan yang cukup jika terjadi pengecualian selama sinkronisasi. Cara modifikasi: Ubah nilai parameter hbase.master.logcleaner.ttl dalam file hbase-site.xml, lalu restart HMaster setelah perubahan. Satuan parameter hbase.master.logcleaner.ttl adalah milidetik (ms). Perhatikan konversi satuan saat mengatur nilai. Sebagai contoh, hbase.master.logcleaner.ttl=43200000 berarti waktu retensi log diatur menjadi 12 jam.

      Catatan

      Jika kluster sumber adalah kluster Lindorm, Anda tidak perlu mengubah waktu retensi log.

    • Anda tidak perlu membuat tabel di kluster tujuan. Layanan sinkronisasi LTS secara otomatis membuat tabel yang identik dengan tabel di kluster sumber, termasuk informasi partisinya. Tabel tujuan yang dibuat pengguna mungkin memiliki partisi yang sangat tidak konsisten dengan tabel sumber, yang dapat menyebabkan sering terjadi split dan compaction pada tabel tujuan setelah migrasi. Jika volume data tabel sangat besar, proses ini bisa memakan waktu sangat lama.

    • Jika tabel sumber memiliki coprocessor, pastikan kluster tujuan berisi paket JAR yang sesuai dengan coprocessor tersebut saat membuat tabel tujuan.

    • Setelah sinkronisasi inkremental diaktifkan, jika data tidak dikonsumsi, log akan disimpan selama 48 jam secara default. Setelah melewati timeout, hubungan subscription akan dibatalkan secara otomatis dan data yang disimpan juga akan dihapus secara otomatis.

    Prasyarat

    Buat tugas

    1. Masuk ke LTS.

    2. Di panel navigasi sebelah kiri, pilih Lindorm/HBase Migration > Quick Migration.

    3. Klik Create a task.

    4. Pada kotak teks Task Name (Optional), masukkan nama tugas. Nama tugas hanya mendukung karakter Inggris dan angka. Parameter ini opsional. Jika tidak ditentukan, ID tugas akan digunakan sebagai nama tugas secara default.

    5. Atur Source Cluster dan Destination Cluster sesuai petunjuk.

    6. Pilih Operation yang diperlukan.

      • Table Schema Migration: Membuat tabel di kluster tujuan (dengan skema dan informasi partisi yang konsisten). Jika tabel sudah ada di kluster tujuan, proses ini akan dilewati.

      • Real-time Data Replication: Menyinkronkan data inkremental real-time dari kluster sumber.

      • Historical Data Migration: Migrasi fisik penuh tingkat file.

    7. Pada bagian Tables to Synchronize/Migrate, masukkan tabel utama yang akan dimigrasikan.

    8. Pilih operasi pada tabel indeks.

    9. (Opsional) Konfigurasi Advanced Configurations.

    10. Klik Create.

    Lihat tugas dan detail tugas

    1. Di panel navigasi sebelah kiri, pilih Lindorm/HBase Migration > Quick Migration > untuk melihat daftar tugas.

    2. Klik nama tugas untuk melihat status eksekusi tugas tersebut.

    Peralihan

    1. Tunggu hingga tugas migrasi penuh selesai. Latensi migrasi inkremental relatif kecil (beberapa detik atau ratusan milidetik).

    2. Aktifkan verifikasi sampling data LTS. Untuk tabel besar, rasio sampling sebaiknya tidak terlalu besar agar tidak memengaruhi bisnis online.

    3. Lakukan verifikasi bisnis.

    4. Lakukan alih bencana bisnis.

    FAQ

    Skenario apa saja yang menyebabkan data tidak dikonsumsi?

    Melepaskan kluster LTS secara langsung tanpa menghentikan tugas, menangguhkan tugas sinkronisasi, atau pemblokiran akibat exception pada tugas.

    Apa yang harus saya lakukan jika tugas migrasi gagal?

    Ada banyak kemungkinan penyebab kegagalan tugas migrasi, seperti ketidakstabilan jaringan dan konflik layanan. LTS memiliki mekanisme retry bawaan dan akan mencoba ulang secara otomatis setelah tugas gagal. Jika tetap gagal setelah percobaan ulang, hubungi dukungan teknis Lindorm (ID DingTalk: s0s3eg3).