ApsaraDB for ClickHouse：Migrasi 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, Anda harus memodifikasi file `config.xml` untuk mengaktifkan migrasi inkremental. Modifikasi ini bergantung pada apakah `system.part_log` dan `system.query_log` telah diaktifkan di kluster yang dikelola sendiri.

<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 kompatibel dengan versi kluster yang dikelola sendiri

Untuk memastikan perilaku kluster tujuan sekompatibel mungkin dengan kluster yang dikelola sendiri, hubungkan ke kluster tujuan dan modifikasi parameter compatibility agar sesuai dengan nomor 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 nilai pengaturan compatibility.
ALTER PROFILE XXXX SETTINGS compatibility = '23.8'; // Memodifikasi profil.

Langkah 3: Buat tugas migrasi

1. Masuk ke Konsol ApsaraDB for ClickHouse. Pada halaman Clusters, klik tab Enterprise Edition Clusters, lalu klik ID kluster tujuan.

2. Di panel navigasi sebelah kiri, klik Data Migration and Synchronization > Migration from ClickHouse.

3. Klik Create Migration Task.

4. Pilih instans sumber dan tujuan.

   Konfigurasikan informasi untuk kluster yang dikelola sendiri dan klik Next.

   Item konfigurasi	Deskripsi	Contoh
   Task Name	Nama tugas migrasi. Hanya boleh berisi huruf besar, huruf kecil, dan angka. Nama 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 nomor port setiap shard di kluster, dipisahkan koma. Format: IP:PORT,IP:PORT,.... Anda dapat menggunakan pernyataan SQL berikut untuk mendapatkan alamat IP dan nomor 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; Deskripsi parameter: cluster_name: Nama kluster tujuan. replica_num=1 menunjukkan bahwa set replika pertama dipilih. Anda juga dapat memilih set replika lain atau memilih satu replika dari setiap shard. Penting Jangan gunakan nama domain VPC atau alamat SLB ClickHouse. Jika alamat IP dan nomor port dipetakan ke Alibaba Cloud setelah transformasi, konfigurasikan alamat IP dan nomor port yang sesuai 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 untuk akun database kluster yang dikelola sendiri.	test******

5. Periksa konektivitas dan konfigurasi.

   1. Klik Start Check.

      Klik untuk melihat item pemeriksaan.

      • Validasi konektivitas: Memeriksa apakah jaringan sepenuhnya terhubung antara instans yang dikelola sendiri dan instans tujuan serta apakah node di kedua ujung dapat saling mengakses.

      • Validasi izin akun: Memeriksa apakah akun dan kata sandi sumber benar dan dapat digunakan untuk menghubungkan ke instans sumber.

      • Pemeriksaan tabel sistem instans sumber: Memeriksa apakah instans yang dikelola sendiri memiliki tabel sistem system.query_log, system.parts, dan system.part_log.

      • Pemeriksaan konfigurasi: Memeriksa apakah instans yang dikelola sendiri dan instans tujuan memiliki zona waktu yang sama dan apakah item konfigurasi compatibility instans tujuan sama dengan versi sumber.

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

   3. Setelah pemeriksaan selesai, lakukan operasi selanjutnya berdasarkan hasilnya.

      Anda dapat memilih Result Level dan item pemeriksaan, lalu klik tombol untuk melihat hasil pemeriksaan yang sesuai. Hasil pemeriksaan dijelaskan sebagai berikut.

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

      • Peringatan: Ini adalah item non-blocking. Anda harus memastikan apakah peringatan tersebut akan memengaruhi bisnis atau tugas migrasi Anda. Anda dapat memilih untuk mengabaikan peringatan tersebut, atau menyelesaikan masalah berdasarkan isi peringatan lalu klik Start Check lagi.

      • Error: Ini adalah item blocking. Anda harus menyelesaikan masalah berdasarkan isi error lalu klik Start Check lagi.

        Untuk informasi selengkapnya tentang pesan error dan solusinya, lihat FAQ.

6. Periksa skema database dan tabel.

   1. Klik Start Check.

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

   3. Setelah pemeriksaan selesai, lakukan operasi selanjutnya berdasarkan hasil pemeriksaan.

      Untuk deskripsi hasil pemeriksaan, lihat Langkah 5.

7. Migrasi skema database dan tabel.

   1. Klik Start Migration.

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

   3. Setelah pemeriksaan selesai, lakukan operasi selanjutnya berdasarkan hasil pemeriksaan.

      Untuk deskripsi hasil pemeriksaan, lihat Langkah 5.

8. (Opsional) Periksa kompatibilitas SQL.

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

   • Jika Anda tidak perlu melakukan langkah ini, klik Skip.

   • Untuk melakukan langkah ini, pilih Request Replay Time, lalu klik Start Check. Setelah pemeriksaan lolos, klik Next. Untuk informasi tentang cara menangani pemeriksaan yang gagal, lihat Langkah 5.

     Penting

     • Database dan tabel instans tidak memiliki data. Fitur ini hanya memverifikasi kompatibilitas sintaks. Jika Anda memerlukan data, Anda dapat terlebih dahulu melakukan langkah berikutnya untuk memigrasikan sebagian data.

     • Hasil positif palsu dapat terjadi karena versi client yang digunakan untuk memutar ulang pernyataan SQL tidak cocok dengan instans tujuan. Jika hasilnya abnormal, Anda dapat mengeksekusi pernyataan SQL tersebut sendiri untuk validasi.

9. Mulai sinkronisasi.

   1. Klik Start Sync.

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

      Selama sinkronisasi, Anda dapat melakukan operasi Stop, Restart, dan Cancel Migration untuk mengontrol alur migrasi. Klik untuk melihat deskripsi, dampak, dan informasi lain tentang operasi ini.

      Operasi	Makna fitur	Dampak	Skenario
      Stop	Segera menghentikan migrasi data dan memigrasikan skema database dan tabel yang tersisa.	Data mungkin tidak sepenuhnya dimigrasikan. Sebelum memulai ulang migrasi, Anda harus menghapus data yang telah dimigrasikan di kluster tujuan untuk menghindari duplikasi data.	Setelah semua data dimigrasikan, hentikan tugas migrasi secara aktif. Anda ingin menguji setelah memigrasikan sebagian data tetapi tidak ingin menghentikan penulisan ke kluster yang dikelola sendiri.
      Restart	Jika terjadi pengecualian selama proses pemeriksaan dan pembersihan database dan tabel lain, migrasi data, atau migrasi skema database dan tabel yang tersisa, pelanggan dapat menangani masalah berdasarkan pesan error. Langkah saat ini akan diulang, dan langkah-langkah berikutnya akan berjalan normal.	Tidak ada	Terjadi pengecualian selama proses migrasi. Pelanggan ingin mencoba ulang dari titik gangguan setelah menyelesaikan masalah berdasarkan prompt.
      Cancel Migration	Membatalkan tugas secara paksa dan melewati langkah-langkah berikutnya.	Tugas migrasi dihentikan secara paksa. Skema database dan tabel serta konfigurasi instans tujuan mungkin tidak lengkap dan tidak dapat digunakan untuk bisnis. Sebelum memulai ulang migrasi, Anda harus menghapus data yang telah dimigrasikan di kluster tujuan untuk menghindari duplikasi data.	Tugas migrasi telah memengaruhi kluster yang dikelola sendiri, dan Anda ingin mengakhiri migrasi serta mengaktifkan penulisan sesegera mungkin.

   3. Saat proses mencapai langkah Migrate Data, beralihlah ke tab Migrate Data dan klik tombol untuk melihat Migration Progress dan Estimated Remaining Time.

      Klik untuk mempelajari cara menilai apakah migrasi dapat diselesaikan.

      Apakah migrasi dapat diselesaikan bergantung pada hubungan antara kecepatan migrasi dan kecepatan penulisan kluster yang dikelola sendiri.

      • Tabel berikut menunjukkan data uji kecepatan migrasi:

        Ukuran rata-rata bagian tabel data	Tipe instans sumber	Spesifikasi disk sumber	Tipe instans tujuan	Media penyimpanan tujuan	Jumlah node kluster	Kecepatan migrasi per node	Kecepatan migrasi keseluruhan
        402,54 MB	8 vCPU, 32 GB	PL1	16 CCU	OSS	16	47 MB/dtk	752,34 MB/dtk
        402,54 MB	80 vCPU, 384 GB	PL3	48 CCU	ESSD_L2	8	197,74 MB/dtk	1581,95 MB/dtk

      • Tentukan hubungan antara kecepatan penulisan kluster tujuan dan kecepatan penulisan kluster yang dikelola sendiri:

        Kecepatan migrasi data terkait dengan faktor-faktor seperti ukuran part, tipe instans, spesifikasi disk, dan atribut data bisnis. Dalam eksperimen uji, kecepatan migrasi yang cepat dipertahankan ketika ukuran rata-rata part berada di antara 100 MB dan 10 GB. Oleh karena itu, data uji ini hanya untuk referensi. Anda harus menentukan kecepatan penulisan aktual kluster tujuan dengan melihat throughput disk-nya. Untuk informasi selengkapnya tentang cara melihat throughput disk, lihat Lihat informasi pemantauan kluster.

        • Jika kecepatan penulisan kluster tujuan kurang dari kecepatan penulisan kluster yang dikelola sendiri, migrasi kemungkinan besar akan gagal. Kami menyarankan Anda membatalkan tugas migrasi dan melakukan migrasi manual.

        • Jika kecepatan penulisan kluster tujuan lebih besar dari kecepatan penulisan kluster yang dikelola sendiri, Anda dapat melanjutkan ke langkah berikutnya. Untuk meningkatkan tingkat keberhasilan migrasi, kami menyarankan agar waktu migrasi yang diperlukan, dihitung sebagai Volume Data / (Kecepatan Migrasi - Kecepatan Penulisan Instans yang Dikelola Sendiri), adalah 5 hari atau kurang.

      Penting

      Anda harus memantau secara ketat Migration Progress tugas tersebut. Berdasarkan Estimated Remaining Time, Anda harus secara proaktif menghentikan penulisan ke kluster yang dikelola sendiri dan menangani tabel mesin Kafka dan RabbitMQ.

      Klik untuk mempelajari cara memperkirakan kapan harus berhenti menulis data ke kluster yang dikelola sendiri.

      Sebelum beralih bisnis Anda, Anda harus memastikan tidak ada data baru yang dihasilkan di instans yang dikelola sendiri untuk menjamin integritas data setelah migrasi. Oleh karena itu, Anda perlu menghentikan penulisan bisnis dan menghapus tabel Kafka dan RabbitMQ. Operasi spesifiknya adalah sebagai berikut:

      1. Masuk ke kluster yang dikelola sendiri dan gunakan pernyataan berikut untuk menanyakan tabel yang perlu Anda proses.

         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 eksekusi pernyataan CREATE TABLE yang Anda peroleh pada langkah sebelumnya.

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

         Penting

         Saat Anda menghapus tabel Kafka, Anda juga harus menghapus tampilan materialisasi yang mereferensikan tabel Kafka tersebut. Jika tidak, migrasi tampilan materialisasi tidak dapat diselesaikan, yang menyebabkan seluruh migrasi gagal.

   4. Saat Migration Progress mencapai 100% dan Anda telah memastikan bahwa instans sumber telah berhenti menerima penulisan, klik tombol Stop untuk mengakhiri proses migrasi dan melanjutkan ke langkah berikutnya.

      

   5. Setelah sinkronisasi selesai, klik Completed.

Langkah 4: Migrasi data bisnis dari tabel non-MergeTree

Tugas migrasi hanya mendukung migrasi skema tabel untuk beberapa tabel non-MergeTree, seperti tabel MySQL. Untuk tabel lain, seperti tabel Log, migrasi sama sekali tidak didukung. Oleh karena itu, setelah tugas migrasi selesai, kluster tujuan mungkin berisi tabel yang hanya memiliki skema tanpa data bisnis. Anda harus memigrasikan data bisnis tersebut sendiri. Operasi spesifiknya adalah sebagai berikut:

1. Masuk ke kluster yang dikelola sendiri dan lihat tabel non-MergeTree yang datanya perlu Anda migrasikan.

   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. Masuk ke kluster tujuan dan lakukan migrasi data menggunakan fungsi remote.