ApsaraDB for ClickHouse:Migrasi ClickHouse yang dikelola sendiri ke ApsaraDB for ClickHouse Enterprise Edition

Pertimbangan

Langkah 1: Periksa kluster dan aktifkan tabel sistem

Sebelum memulai migrasi data, konfigurasikan file config.xml pada kluster yang dikelola sendiri untuk mengaktifkan migrasi inkremental. Konfigurasi bergantung pada apakah tabel sistem system.part_log dan system.query_log sudah diaktifkan atau belum.

<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 kompatibilitas kluster

Untuk memastikan kluster target sekompatibel mungkin dengan kluster yang dikelola sendiri, hubungkan ke kluster target dan ubah parameter compatibility agar sesuai dengan versi kluster yang dikelola sendiri.

Contoh:

SELECT currentProfiles(); // Dapatkan nama profil saat ini.
SELECT
    profile_name,
    setting_name,
    value
FROM system.settings_profile_elements
WHERE (setting_name = 'compatibility') AND (profile_name = 'xxxx'); // Periksa nilai pengaturan compatibility.
ALTER PROFILE XXXX SETTINGS compatibility = '23.8'; // Atur nilai compatibility.

Langkah 3: Buat tugas migrasi

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

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

3. Klik Create Migration Task.

4. Pilih instance sumber dan target.

   Parameter	Deskripsi	Contoh
   Task Name	Nama unik yang tidak peka huruf besar/kecil untuk tugas migrasi. Nama hanya boleh berisi huruf dan angka.	MigrationTask1229
   Source Cluster Name	Jalankan SELECT * FROM system.clusters; untuk mendapatkan nama kluster kluster yang dikelola sendiri.	default
   VPC IP Address	Alamat IP dan port untuk setiap shard dalam kluster, dipisahkan koma. Format: IP:PORT,IP:PORT,.... Anda dapat menggunakan 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; Deskripsi parameter: cluster_name: Nama kluster yang dikelola sendiri. replica_num=1 memilih set replika pertama. Anda juga dapat memilih set replika lain atau memilih satu replika dari setiap shard secara manual. Penting Anda tidak dapat menggunakan nama domain VPC atau alamat SLB kluster ClickHouse. Jika Anda menggunakan NAT untuk memetakan alamat IP dan port ke Alibaba Cloud, Anda harus mengonfigurasi alamat IP dan port yang dipetakan sesuai dengan pengaturan jaringan Anda.	192.168.0.5:9000,192.168.0.6:9000
   Database Account	Akun database untuk kluster yang dikelola sendiri.	test
   Database Password	Password untuk akun database kluster yang dikelola sendiri.	test******
   Source Instance Kernel Version	Klik Get Version.	22.8.5.29

5. Berdasarkan versi instans sumber, lakukan langkah berikut:

   • 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, lalu klik Next.

   • Jika pengambilan versi gagal: Hal ini dapat terjadi jika informasi instans sumber salah atau jaringan terputus. Ikuti petunjuk untuk menyelesaikan masalah, lalu klik Get Version lagi.

   Catatan

   Karena ketidakcocokan parameter antara edisi komunitas versi lama dan Edisi Perusahaan, jika versi instans sumber lebih lama dari 22.10, Anda harus menyinkronkan data dengan mendorongnya dari sumber ke target. Dalam skenario ini, Anda harus memetakan alamat IP instans target ke jaringan yang dikelola sendiri. Jika jaringan yang dikelola sendiri dan instans Edisi Perusahaan berada dalam VPC yang sama, atau terhubung melalui VPC Peering Connection, Anda dapat menggunakan alamat IP asli untuk koneksi.

6. Periksa konektivitas dan konfigurasi.

   1. Klik Start Check.

      Pemeriksaan memverifikasi item berikut:

      • Verifikasi konektivitas: Memverifikasi bahwa kluster yang dikelola sendiri dan instans target memiliki konektivitas jaringan penuh dan semua node dapat saling mengakses.

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

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

      • Pemeriksaan konfigurasi: Memverifikasi bahwa instans yang dikelola sendiri dan instans target menggunakan zona waktu yang sama, dan parameter compatibility instans target sesuai dengan versi instans sumber.

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

   3. Setelah pemeriksaan selesai, lanjutkan berdasarkan hasilnya.

      Anda dapat memilih Result level dan item pemeriksaan, lalu klik ikon untuk melihat hasil yang sesuai. Level hasil dijelaskan di bawah ini.

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

      • Warning: Ini adalah item non-blocking. Anda harus mengonfirmasi secara manual apakah peringatan tersebut memengaruhi workload atau tugas migrasi Anda. Anda dapat mengabaikan peringatan atau menyelesaikan masalah tersebut lalu mengklik Start Check lagi.

      • Error: Ini adalah item blocking. Anda harus menyelesaikan error menggunakan informasi yang disediakan, lalu mengklik Start Check lagi.

        Untuk informasi tentang pesan error dan solusinya, lihat FAQ.

7. Periksa Struktur Database dan Tabel.

   Setelah pemeriksaan konektivitas dan konfigurasi lolos, lanjutkan untuk memeriksa struktur database dan tabel. Langkah ini terdiri dari tiga sub-langkah: Select databases to migrate, Select tables to migrate, dan Check database and table structures.

   Penting

   Sub-langkah Select databases to migrate dan Select tables to migrate bersifat opsional. Jika Anda ingin memigrasikan semua database dan tabel dari instans sumber, Anda dapat melewati dua sub-langkah ini dan langsung melanjutkan ke sub-langkah 3 (Check database and table structures).

   Sub-langkah 1: Pilih database yang akan dimigrasikan (Opsional)

   1. Klik Query Source. Sistem secara otomatis mengkueri semua database pada instans sumber.

   2. Selama kueri, Anda dapat mengklik Query Results untuk melihat hasil real-time.

   3. Setelah kueri selesai, pilih database yang akan dimigrasikan sesuai kebutuhan bisnis Anda. Setelah pemilihan selesai, klik Confirm.

   Sub-langkah 2: Select tables to migrate (Opsional)

   1. Setelah Anda memilih database, antarmuka untuk memilih tabel akan ditampilkan. Klik Query Source. Sistem secara otomatis mengkueri semua tabel dalam database yang dipilih.

   2. Selama kueri, Anda dapat mengklik Query Results untuk melihat hasil real-time.

   3. Setelah kueri selesai, pilih tabel yang akan dimigrasikan sesuai kebutuhan bisnis Anda. Setelah pemilihan selesai, klik Confirm.

   Catatan

   Secara default, semua tabel dipilih. Jika Anda hanya perlu memigrasikan tabel tertentu, hapus centang pada kotak pilih-semua untuk database yang sesuai, buka daftar dropdown, lalu pilih tabel yang Anda butuhkan.

   Sub-langkah 3: Check database and table structures

   1. Klik Start Check. Sistem memeriksa struktur database, struktur tabel, dan UDF untuk mengidentifikasi ketidakcocokan antara instans sumber dan target.

   2. Selama pemeriksaan, Anda dapat memfilter berdasarkan Result Level dan Check Item, lalu mengklik ikon Refresh untuk melihat hasil real-time.

   3. Hasil pemeriksaan diklasifikasikan ke dalam tiga level: success, warning, dan error.

      • Pemeriksaan berhasil: Klik Next untuk melanjutkan migrasi.

      • Peringatan muncul selama pemeriksaan

        Atur level hasil ke Warning dan temukan item pemeriksaan yang sesuai untuk meninjau detail peringatan.

        Penting

        Item pemeriksaan level Warning bersifat non-blocking. Anda harus mengonfirmasi apakah peringatan tersebut memengaruhi workload atau tugas migrasi Anda. Setelah konfirmasi, Anda memiliki dua opsi:

        • Abaikan peringatan dan klik Next untuk melanjutkan migrasi.

        • Selesaikan peringatan berdasarkan detail yang disediakan, lalu klik Start Check untuk memeriksa ulang struktur database dan tabel. Untuk informasi tentang pesan peringatan dan solusinya, lihat bagian FAQ topik ini.

      • Pemeriksaan gagal

        Atur level hasil ke Error dan temukan item pemeriksaan yang sesuai untuk meninjau detail error.

        Penting

        Item pemeriksaan level Error bersifat blocking. Anda harus menyelesaikan error berdasarkan detail yang disediakan, lalu klik Start Check untuk memeriksa ulang struktur database dan tabel. Untuk informasi tentang pesan error dan solusinya, lihat bagian FAQ topik ini.

8. Migrasi Struktur Database dan Tabel.

   1. Klik Start Migration.

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

   3. Setelah migrasi selesai, lanjutkan berdasarkan hasilnya.

      Untuk informasi tentang hasilnya, lihat Langkah 5.

9. (Opsional) Periksa kompatibilitas SQL.

   Pemeriksaan kompatibilitas SQL memutar ulang pernyataan SQL dari instans yang dikelola sendiri pada instans target untuk memverifikasi kompatibilitas sintaks antar versi kernel yang berbeda.

   • Untuk melewati langkah ini, klik skip.

   • Untuk melakukan pemeriksaan ini, pilih Request replay time lalu klik Start Check. Jika pemeriksaan lolos, klik Next. Jika pemeriksaan gagal, lihat Langkah 5 untuk solusinya.

     Penting

     • Database dan tabel instans tidak berisi data, sehingga pemeriksaan ini hanya memvalidasi kompatibilitas sintaks. Untuk menguji dengan data, Anda dapat memigrasikan beberapa data pada langkah berikutnya.

     • Ketidaksesuaian antara versi klien yang digunakan untuk pemutaran ulang SQL dan instans target dapat menyebabkan false positive. Jika terjadi error, jalankan pernyataan SQL secara manual untuk memverifikasi hasilnya.

10. Catat dan bersihkan tabel mesin Kafka/RabbitMQ.

    Sebelum memulai sinkronisasi, catat definisi tabel mesin Kafka/RabbitMQ dan materialized view downstream-nya pada kluster yang dikelola sendiri, tangani tabel implisit, lalu hapus tabel-tabel tersebut untuk menghindari exception migrasi.

    1. Login ke kluster yang dikelola sendiri dan kueri semua tabel mesin Kafka dan RabbitMQ beserta dependensi downstream-nya.

       /*
       create_table_query: definisi tabel
       dependencies_database: database dari tabel dependen downstream
       dependencies_table: nama tabel dependen downstream
       Dari dependencies_database dan dependencies_table, Anda dapat mengidentifikasi materialized view yang bergantung pada tabel Kafka/RabbitMQ.
       */
       SELECT * FROM system.tables WHERE engine IN ('RabbitMQ', 'Kafka');

    2. Lihat definisi materialized view dan periksa apakah tabel targetnya adalah tabel implisit.

       /*
       Lihat definisi materialized view.
       Jika tabel target materialized view adalah tabel implisit, perhatikan hal berikut:
       Menghapus materialized view juga akan menghapus tabel implisit, yang menyebabkan kehilangan data.
       Contoh: Dalam CREATE MATERIALIZED VIEW [db.]table_name [TO[db.]name], jika TO tidak ditentukan,
       sistem secara otomatis membuat tabel implisit, yang mungkin dalam format '.inner_id.<TABLE_UUID>' atau '.inner.<TABLE>'.
       */
       SELECT * FROM system.tables WHERE database='<DATABASE>' AND name = '<MATERIALIZED_VIEW_NAME>';

    3. Jika tabel target materialized view adalah tabel implisit, ganti namanya menjadi nama baru untuk mencegah kehilangan data saat materialized view dihapus nanti.

       -- Ganti nama tabel target implisit untuk mempertahankan data
       RENAME TABLE <DATABASE>.`.inner_id.<TABLE_UUID>` TO <DATABASE>.<new_target_table_name>;

    4. Hapus tabel mesin Kafka/RabbitMQ dan materialized view downstream-nya.

       -- Hapus materialized view terlebih dahulu
       DROP TABLE <DATABASE>.<MATERIALIZED_VIEW_NAME>;
       -- Lalu hapus tabel mesin Kafka/RabbitMQ
       DROP TABLE <DATABASE>.<KAFKA_OR_RABBITMQ_TABLE_NAME>;

    Penting

    Pastikan untuk menyimpan semua pernyataan DDL yang dicatat. Anda akan membutuhkannya untuk membuat ulang tabel-tabel ini di kluster yang dikelola sendiri dan kluster target nanti. Jika Anda melakukan operasi RENAME, gunakan klausa TO untuk mengarahkan ke tabel target yang diganti namanya saat membuat ulang materialized view.

11. Mulai Sinkronisasi.

    1. Klik Start Sync.

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

       Selama sinkronisasi, gunakan operasi Stop, Restart, dan Cancel Migration untuk mengontrol proses migrasi. Klik untuk melihat detail tentang operasi ini.

       Tindakan	Deskripsi	Dampak	Kasus penggunaan
       Stop	Segera menghentikan migrasi data dan melanjutkan untuk memigrasikan struktur database dan tabel yang tersisa.	Data mungkin tidak sepenuhnya dimigrasikan. Sebelum memulai ulang migrasi, Anda harus menghapus data yang telah dimigrasikan dari kluster target untuk menghindari duplikasi data.	Menghentikan tugas migrasi secara manual setelah semua data dimigrasikan. Menguji dengan migrasi data parsial tanpa harus menghentikan penulisan di kluster yang dikelola sendiri.
       Restart	Jika terjadi error selama langkah pemeriksaan atau migrasi, operasi ini mencoba ulang langkah yang gagal setelah Anda menyelesaikan masalahnya.	Tidak ada	Melanjutkan tugas dari titik kegagalan setelah menyelesaikan error migrasi.
       Cancel Migration	Secara paksa membatalkan tugas dan melewati semua langkah berikutnya. Penting Setelah pembatalan, tugas migrasi terkunci, sehingga Anda tidak dapat memodifikasi proses migrasi. Anda dapat menggunakan tombol Previous, Next, atau Refresh untuk melihat hasil langkah yang telah selesai.	Tugas migrasi dihentikan secara paksa. Struktur database dan tabel serta konfigurasi instans target mungkin tidak lengkap dan tidak dapat digunakan untuk workload produksi. Sebelum memulai ulang migrasi, Anda harus menghapus data yang telah dimigrasikan dari kluster target untuk menghindari duplikasi data.	Tugas migrasi berdampak negatif pada kluster yang dikelola sendiri, dan Anda perlu segera mengakhirinya untuk melanjutkan penulisan.

    3. Pada kluster yang dikelola sendiri, gunakan pernyataan DDL yang disimpan sebelumnya untuk membuat ulang tabel mesin Kafka/RabbitMQ dan materialized view downstream-nya. Setelah dibuat ulang, data inkremental akan kembali mengalir dan secara otomatis disinkronkan ke kluster target.

       Penting

       Jika sebelumnya Anda melakukan operasi RENAME pada tabel target implisit, gunakan klausa TO untuk mengarahkan ke tabel target yang diganti namanya saat membuat ulang materialized view. Untuk informasi lebih lanjut, lihat CREATE MATERIALIZED VIEW.

       CREATE MATERIALIZED VIEW [db.]table_name [TO[db.]name]

       .

       -- Buat ulang tabel mesin Kafka/RabbitMQ di kluster yang dikelola sendiri
       CREATE TABLE <DATABASE>.<KAFKA_OR_RABBITMQ_TABLE_NAME> (...)
       ENGINE = Kafka/RabbitMQ
       SETTINGS ...;
       
       -- Buat ulang materialized view (mengarah ke tabel target yang diganti namanya)
       CREATE MATERIALIZED VIEW <DATABASE>.<MATERIALIZED_VIEW_NAME> TO <DATABASE>.<new_target_table_name>
       AS SELECT ... FROM <DATABASE>.<KAFKA_OR_RABBITMQ_TABLE_NAME>;

    4. Saat proses mencapai tahap Migrate data, beralihlah ke tab Migrate data dan klik ikon untuk melihat Migration Progress dan Estimated remaining time.

       Nilai apakah migrasi dapat diselesaikan

       Keberhasilan migrasi bergantung pada kecepatan migrasi relatif terhadap kecepatan penulisan kluster yang dikelola sendiri.

       • Tabel berikut menyajikan data uji kecepatan migrasi:

         Ukuran part rata-rata	Tipe instans sumber	Tipe disk sumber	Tipe instans target	Media penyimpanan target	Node kluster	Kecepatan per node	Kecepatan migrasi keseluruhan
         402,54 MB	8C32G	PL1	16CCU	OSS	16	47 MB/dtk	752,34 MB/dtk
         402,54 MB	80C384G	PL3	48CCU	ESSD_L2	8	197,74 MB/dtk	1581,95 MB/dtk

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

         Kecepatan migrasi data bergantung pada faktor-faktor seperti ukuran part (dalam pengujian kami, kami mengamati kecepatan migrasi cepat untuk ukuran part rata-rata antara 100 MB hingga 10 GB), tipe instans, tipe disk, dan karakteristik workload. Oleh karena itu, data uji ini hanya sebagai referensi. Untuk menentukan kecepatan penulisan aktual kluster target, periksa throughput disk-nya. Untuk informasi lebih lanjut tentang cara melihat throughput disk, lihat Lihat informasi pemantauan kluster.

         • Jika kecepatan penulisan kluster target lebih lambat daripada kluster yang dikelola sendiri: Migrasi cenderung gagal. Kami menyarankan untuk membatalkan tugas dan melakukan migrasi manual.

         • Jika kecepatan penulisan kluster target lebih cepat daripada kluster yang dikelola sendiri: Untuk meningkatkan tingkat keberhasilan, kami menyarankan untuk memastikan bahwa waktu migrasi, dihitung sebagai Volume Data / (Kecepatan Migrasi - Kecepatan Penulisan Kluster yang Dikelola Sendiri), tidak lebih dari 5 hari.

       Penting

       • Anda harus memantau secara ketat Migration Progress. Berdasarkan Estimated remaining time, Anda perlu secara proaktif menghentikan penulisan ke kluster yang dikelola sendiri dan menangani tabel yang menggunakan mesin Kafka dan RabbitMQ.

       • Proses latar belakang secara otomatis membatalkan tugas apa pun yang berjalan lebih dari 5 hari. Jika tugas migrasi Anda memerlukan waktu lebih lama, kirim tiket untuk meminta penyesuaian ambang batas.

       Perkirakan kapan harus menghentikan penulisan ke kluster yang dikelola sendiri dan melakukan cutover

       Saat perkiraan waktu migrasi kurang dari 10 menit atau progres migrasi mencapai 99%, lakukan operasi berikut untuk menyelesaikan cutover:

       1. Hentikan penulisan bisnis. Pada kluster yang dikelola sendiri, hapus tabel mesin Kafka/RabbitMQ dan materialized view downstream-nya yang sebelumnya telah dibuat ulang.

          -- Hapus materialized view terlebih dahulu
          DROP TABLE <DATABASE>.<MATERIALIZED_VIEW_NAME>;
          -- Lalu hapus tabel mesin Kafka/RabbitMQ
          DROP TABLE <DATABASE>.<KAFKA_OR_RABBITMQ_TABLE_NAME>;

       2. Tunggu hingga progres migrasi mencapai 100% dan migrasi benar-benar selesai.

       3. Hubungkan ke kluster target dan gunakan pernyataan DDL yang disimpan sebelumnya untuk membuat ulang tabel mesin Kafka/RabbitMQ dan materialized view downstream-nya.

          Penting

          Jika sebelumnya Anda melakukan operasi RENAME pada tabel target implisit, gunakan klausa TO untuk mengarahkan ke tabel target yang diganti namanya saat membuat ulang materialized view. Untuk informasi lebih lanjut, lihat CREATE MATERIALIZED VIEW.

          -- Buat ulang tabel mesin Kafka/RabbitMQ di kluster target
          CREATE TABLE <DATABASE>.<KAFKA_OR_RABBITMQ_TABLE_NAME> (...)
          ENGINE = Kafka/RabbitMQ
          SETTINGS ...;
          
          -- Buat ulang materialized view (mengarah ke tabel target yang diganti namanya)
          CREATE MATERIALIZED VIEW <DATABASE>.<MATERIALIZED_VIEW_NAME> TO <DATABASE>.<new_target_table_name>
          AS SELECT ... FROM <DATABASE>.<KAFKA_OR_RABBITMQ_TABLE_NAME>;

       4. Verifikasi bahwa pipa data di kluster target berfungsi dengan baik dan data mengalir seperti yang diharapkan.

    5. Saat Migration Progress mencapai 100% dan Anda memastikan bahwa penulisan ke instans sumber telah dihentikan, klik Stop untuk mengakhiri migrasi data dan melanjutkan ke langkah berikutnya.

       

    6. Setelah sinkronisasi selesai, klik Completed.

       Penting

       Setelah langkah Start Synchronization selesai, tugas migrasi terkunci, dan Anda tidak dapat memodifikasi proses migrasi. Anda masih dapat menggunakan tombol Previous, Next, atau Refresh untuk melihat hasil langkah yang telah selesai.

Langkah 4: Migrasi data untuk tabel non-MergeTree

Selama tugas migrasi, tabel non-MergeTree hanya mendukung migrasi struktur tabel (misalnya, tabel MySQL) atau tidak mendukung migrasi sama sekali (misalnya, tabel Log). Oleh karena itu, setelah tugas migrasi selesai, kluster target mungkin berisi tabel dengan struktur tetapi tanpa data bisnis. Anda harus memigrasikan data bisnis secara manual sebagai berikut:

1. Login ke kluster self-built dan identifikasi 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 target dan gunakan fungsi remote untuk memigrasikan data.