ApsaraDB for ClickHouse：Migrasi data dari kluster ClickHouse yang dikelola sendiri ke ApsaraDB for ClickHouse Enterprise Edition

Catatan

Langkah 1: Periksa kluster yang dikelola sendiri dan aktifkan tabel sistem

Sebelum migrasi data, modifikasi file config.xml berdasarkan apakah system.part_log dan system.query_log diaktifkan di kluster yang dikelola sendiri untuk mendukung migrasi inkremental.

<part_log>
    <database>system</database>
    <table>part_log</table>
    <partition_by>event_date</partition_by>
    <order_by>event_time</order_by>
    <ttl>event_date + INTERVAL 15 DAY DELETE</ttl>
    <flush_interval_milliseconds>7500</flush_interval_milliseconds>
</part_log>

<query_log>
    <database>system</database>
    <table>query_log</table>
    <partition_by>event_date</partition_by>
    <order_by>event_time</order_by>
    <ttl>event_date + INTERVAL 15 DAY DELETE</ttl>
    <flush_interval_milliseconds>7500</flush_interval_milliseconds>
</query_log>

Langkah 2: Konfigurasi kluster tujuan agar sesuai dengan versi kluster yang dikelola sendiri

Untuk memastikan kluster tujuan berperilaku semirip mungkin dengan kluster yang dikelola sendiri, hubungkan ke kluster tujuan dan atur parameter compatibility agar sesuai dengan versi kluster yang dikelola sendiri.

Contoh:

SELECT currentProfiles(); // Mendapatkan profil yang digunakan oleh pengguna
SELECT
    profile_name,
    setting_name,
    value
FROM system.settings_profile_elements
WHERE (setting_name = 'compatibility') AND (profile_name = 'xxxx'); // Menanyakan pengaturan compatibility
ALTER PROFILE XXXX SETTINGS compatibility = '23.8'; // Mengubah profil

Langkah 3: Buat tugas migrasi

1. Masuk ke Konsol ApsaraDB for ClickHouse. Pada halaman Clusters, pilih Enterprise Edition Clusters, lalu klik ID kluster yang dituju.

2. Pada panel navigasi kiri, pilih Data Migration and Synchronization > Migration from ClickHouse.

3. Klik Create Migration Task.

4. Pilih instans sumber dan tujuan.

   Item konfigurasi	Deskripsi	Contoh
   Task Name	Nama tugas hanya boleh berisi huruf dan angka. Nama bersifat tidak case-sensitive dan harus unik.	MigrationTask1229
   Source Cluster Name	Jalankan SELECT * FROM system.clusters; untuk mendapatkan nama kluster instans yang dikelola sendiri.	default
   VPC IP Address	Alamat IP dan port setiap shard di kluster, dipisahkan koma. Format: IP:PORT,IP:PORT,.... Jalankan pernyataan SQL berikut untuk mendapatkan alamat IP dan port kluster yang dikelola sendiri: SELECT shard_num, replica_num, host_address as ip, port FROM system.clusters WHERE cluster = '<cluster_name>' and replica_num = 1; Parameter: cluster_name: Nama kluster tujuan. replica_num=1 memilih replika pertama. Anda juga dapat memilih replika lain atau memilih satu replika per shard secara manual. Penting Jangan gunakan nama domain VPC atau alamat SLB ClickHouse. Jika pemetaan IP dan port diterapkan untuk Alibaba Cloud, konfigurasikan IP dan port yang dipetakan berdasarkan konektivitas jaringan.	192.168.0.5:9000,192.168.0.6:9000
   Database Account	Akun database kluster yang dikelola sendiri.	test
   Database Password	Password akun database untuk kluster yang dikelola sendiri.	test******
   Source Instance Kernel Version	Klik Get Version.	22.8.5.29

5. Berdasarkan versi instans sumber, lakukan operasi yang sesuai:

   • Jika versi instans sumber 22.10 atau lebih baru, klik Next.

   • Jika versi instans sumber lebih lama dari 22.10, masukkan Destination Instance Information seperti diminta dan klik Next.

   • Jika pengambilan versi gagal, periksa kesalahan seperti informasi instans sumber salah atau masalah konektivitas jaringan. Perbaiki masalah tersebut dan klik Get Version lagi.

   Catatan

   Karena ketidakcocokan parameter antara edisi komunitas lama dan Edisi Perusahaan, jika versi instans sumber lebih lama dari 22.10, Anda harus menggunakan sinkronisasi push dari sumber ke tujuan. Dalam kasus ini, Anda harus memetakan IP tujuan ke jaringan yang dikelola sendiri. Jika jaringan yang dikelola sendiri dan instans Edisi Perusahaan berada di VPC yang sama atau terhubung melalui peering VPC, Anda dapat langsung menggunakan alamat IP aslinya.

6. Periksa konektivitas dan konfigurasi.

   1. Klik Start Check.

      Klik untuk melihat item pemeriksaan.

      • Verifikasi konektivitas: Konektivitas jaringan penuh antara instans yang dikelola sendiri dan tujuan, dengan akses timbal balik antar semua node.

      • Verifikasi izin akun: akun dan kata sandi sumber benar dan dapat terhubung ke instans sumber.

      • Pemeriksaan tabel sistem instans sumber: Instans yang dikelola sendiri harus memiliki tiga tabel sistem berikut: system.query_log, system.parts, dan system.part_log.

      • Pemeriksaan konfigurasi: Instans yang dikelola sendiri dan tujuan harus memiliki zona waktu yang sama, dan pengaturan compatibility instans tujuan harus sesuai dengan versi sumber.

   2. Selama pemeriksaan, klik ikon di pojok kanan atas untuk melihat progres real-time.

   3. Setelah pemeriksaan selesai, lanjutkan berdasarkan hasilnya.

      Pilih result level dan item pemeriksaan, lalu klik tombol untuk melihat detail. Hasil diinterpretasikan sebagai berikut:

      • Success: Jika semua pemeriksaan lolos, klik Next untuk melanjutkan.

      • Warning: Ini adalah masalah non-blocking. Pastikan apakah masalah tersebut memengaruhi bisnis atau migrasi Anda. Anda dapat mengabaikan peringatan atau memperbaiki masalah tersebut lalu klik Start Check lagi untuk memeriksa ulang.

      • Error: Ini adalah masalah blocking. Perbaiki error tersebut lalu klik Start Check lagi untuk memeriksa ulang.

        Untuk pesan error dan solusinya, lihat FAQ.

7. Periksa skema database dan tabel.

   1. Klik Start Check.

   2. Selama pemeriksaan, klik ikon di pojok kanan atas untuk melihat progres real-time.

   3. Setelah pemeriksaan selesai, lanjutkan berdasarkan hasilnya.

      Untuk interpretasi hasil, lihat Langkah 5.

8. Migrasi skema database dan tabel.

   1. Klik Start Migration.

   2. Selama migrasi, klik ikon di pojok kanan atas untuk melihat progres real-time.

   3. Setelah inspeksi selesai, Anda dapat melanjutkan ke langkah berikutnya berdasarkan hasil inspeksi.

      Untuk interpretasi hasil, lihat Langkah 5.

9. (Opsional) Periksa kompatibilitas SQL.

   Pemeriksaan kompatibilitas SQL memutar ulang pernyataan SQL dari instans yang dikelola sendiri di instans tujuan untuk memverifikasi kompatibilitas sintaksis lintas versi kernel. Putuskan apakah akan melakukan langkah ini berdasarkan kebutuhan Anda.

   • Untuk melewati, klik Skip.

   • Untuk melakukan pemeriksaan, pilih request replay time dan klik Start Check. Setelah pemeriksaan berhasil, klik Next. Untuk pemeriksaan yang gagal, lihat Langkah 5 untuk penyelesaian.

     Penting

     • Pemeriksaan ini hanya memvalidasi kompatibilitas sintaksis dan tidak memerlukan data. Untuk menguji dengan data, migrasikan sebagian data terlebih dahulu pada langkah berikutnya.

     • False positive dapat terjadi karena ketidakcocokan versi client dengan instans tujuan. Validasi pernyataan SQL secara manual jika diperlukan.

10. Mulai sinkronisasi.

    1. Klik Start Sync.

    2. Selama sinkronisasi, klik ikon di pojok kanan atas untuk melihat progres real-time.

       Anda dapat mengontrol proses migrasi menggunakan operasi berikut: Stop, Restart, dan Cancel Migration. Klik untuk melihat makna dan dampak operasi.

       Operasi	Definisi Fitur	Dampak	Skenario
       Stop	Segera menghentikan migrasi data tetapi tetap melanjutkan migrasi skema tabel yang tersisa.	Beberapa data mungkin tidak termigrasi sepenuhnya. Sebelum memulai ulang migrasi, bersihkan data yang telah dimigrasikan di kluster tujuan untuk menghindari duplikasi.	Hentikan tugas migrasi setelah migrasi data penuh. Uji setelah memigrasikan sebagian data tanpa menghentikan penulisan ke kluster yang dikelola sendiri.
       Restart	Mencoba ulang langkah saat ini setelah menyelesaikan error yang terjadi selama migrasi skema atau data.	Tidak ada	Lanjutkan migrasi dari titik henti setelah memperbaiki error.
       Cancel migration	Membatalkan tugas secara paksa dan melewati langkah-langkah berikutnya. Penting Setelah pembatalan, tugas migrasi menjadi terkunci dan tidak dapat diubah. Gunakan tombol Previous, Next, atau Refresh untuk melihat hasil langkah.	Migrasi dihentikan. Instans tujuan mungkin memiliki skema atau konfigurasi yang tidak lengkap dan tidak dapat digunakan untuk bisnis. Sebelum memulai ulang migrasi, bersihkan data yang telah dimigrasikan di kluster tujuan untuk menghindari duplikasi.	Mengakhiri migrasi dengan cepat untuk melanjutkan penulisan ke kluster yang dikelola sendiri.

    3. Saat proses mencapai Migrate Data, beralihlah ke tab Migrate Data dan klik tombol untuk melihat Migration Progress dan estimated remaining time.

       Klik untuk mempelajari cara mengevaluasi apakah migrasi dapat diselesaikan.

       Keberhasilan migrasi bergantung pada hubungan antara kecepatan migrasi dan kecepatan penulisan kluster yang dikelola sendiri.

       • Kecepatan migrasi uji sebagai berikut:

         Ukuran part rata-rata	Tipe instans sumber	Tipe disk sumber	Tipe instans tujuan	Media penyimpanan tujuan	Jumlah node kluster	Kecepatan migrasi per node	Kecepatan migrasi keseluruhan
         402.54MB	8C32G	PL1	16CCU	OSS	16	47MB/s	752.34MB/s
         402.54MB	80C384G	PL3	48CCU	ESSD_L2	8	197.74MB/s	1581.95MB/s

       • Bandingkan kecepatan penulisan kluster tujuan dan kluster yang dikelola sendiri:

         Kecepatan migrasi bergantung pada faktor seperti ukuran part (dalam pengujian, ukuran part rata-rata antara 100 MB hingga 10 GB mempertahankan kecepatan tinggi), tipe instans, tipe disk, dan karakteristik data. Oleh karena itu, data uji hanya sebagai referensi. Tentukan kecepatan penulisan aktual kluster tujuan dengan memantau throughput disk-nya. Untuk informasi selengkapnya, lihat Lihat informasi pemantauan kluster.

         • Jika kecepatan penulisan kluster tujuan lebih rendah daripada kecepatan penulisan kluster yang dikelola sendiri, migrasi memiliki tingkat kegagalan tinggi. Batalkan tugas migrasi dan gunakan migrasi manual.

         • Jika kecepatan penulisan kluster tujuan lebih tinggi daripada kecepatan penulisan kluster yang dikelola sendiri, lanjutkan. Untuk meningkatkan tingkat keberhasilan, pastikan durasi migrasi yang dihitung sebagai volume data / (kecepatan migrasi - kecepatan penulisan kluster yang dikelola sendiri) adalah lima hari atau kurang.

       Penting

       Pantau Migration Progress secara ketat. Berdasarkan estimated remaining time, hentikan penulisan ke kluster yang dikelola sendiri dan tangani tabel mesin Kafka dan RabbitMQ.

       Klik untuk mempelajari cara memperkirakan kapan harus menghentikan penulisan ke kluster yang dikelola sendiri.

       Untuk memastikan kelengkapan data setelah migrasi, hentikan penulisan bisnis dan hapus tabel Kafka dan RabbitMQ sebelum alih bencana trafik. Lakukan langkah-langkah berikut:

       1. Login ke kluster yang dikelola sendiri dan jalankan pernyataan berikut untuk menanyakan tabel yang perlu ditangani:

          SELECT * FROM system.tables WHERE engine IN ('RabbitMQ', 'Kafka');

       2. Lihat pernyataan CREATE TABLE untuk tabel target:

          SHOW CREATE TABLE <aim_table_name>;

       3. Hubungkan ke kluster tujuan dan jalankan pernyataan CREATE TABLE yang diperoleh pada langkah sebelumnya.

       4. Login ke kluster yang dikelola sendiri dan hapus tabel mesin Kafka dan RabbitMQ yang telah dimigrasikan.

          Penting

          Saat menghapus tabel Kafka, hapus juga materialized view yang mereferensikannya. Jika tidak, migrasi materialized view gagal, menyebabkan seluruh migrasi gagal.

    4. Saat Migration Progress mencapai 100% dan Anda memastikan bahwa instans sumber telah menghentikan penulisan, klik Stop untuk mengakhiri migrasi dan melanjutkan.

       

    5. Setelah sinkronisasi selesai, klik Completed.

       Penting

       Setelah langkah "Start synchronization" selesai, tugas migrasi menjadi terkunci dan tidak dapat diubah. Gunakan tombol Previous, Next, atau Refresh untuk melihat hasil langkah.

Langkah 4: Migrasi data bisnis untuk tabel non-MergeTree

Selama migrasi, tabel non-MergeTree hanya mendukung migrasi skema (seperti tabel MySQL) atau tidak dimigrasikan sama sekali (seperti tabel Log). Setelah migrasi, beberapa tabel di kluster tujuan mungkin memiliki skema tetapi tidak memiliki data. Selesaikan migrasi data secara manual sebagai berikut:

1. Login ke kluster yang dikelola sendiri dan jalankan pernyataan berikut untuk mengidentifikasi tabel non-MergeTree yang memerlukan migrasi data:

   SELECT
       `database` AS database_name,
       `name` AS table_name,
       `engine`
   FROM `system`.`tables`
   WHERE (`engine` NOT LIKE '%MergeTree%') AND (`engine` != 'Distributed') AND (`engine` != 'MaterializedView') AND (`engine` NOT IN ('Kafka', 'RabbitMQ')) AND (`database` NOT IN ('system', 'INFORMATION_SCHEMA', 'information_schema')) AND (`database` NOT IN (
       SELECT `name`
       FROM `system`.`databases`
       WHERE `engine` IN ('MySQL', 'MaterializedMySQL', 'MaterializeMySQL', 'Lazy', 'PostgreSQL', 'MaterializedPostgreSQL', 'SQLite')
   ))

2. Login ke kluster tujuan dan gunakan fungsi remote untuk migrasi data.