ApsaraDB for ClickHouse：Migrasi data dari instans ClickHouse yang dikelola sendiri ke kluster ApsaraDB for ClickHouse edisi Community-Compatible

Batasan

Versi kluster tujuan harus 21.8 atau lebih baru.

Catatan

• Selama migrasi:

  • Proses merge untuk database dan tabel yang sedang dimigrasikan di kluster tujuan dijeda. Proses merge di kluster yang dikelola sendiri tidak dijeda.

    Catatan

    Jika migrasi data memakan waktu terlalu lama, jumlah metadata yang menumpuk di kluster tujuan akan berlebihan. Kami menyarankan agar tugas migrasi tidak berjalan lebih dari 5 hari.

  • Kluster tujuan harus menggunakan kluster default. Jika kluster yang dikelola sendiri menggunakan nama berbeda, definisi kluster di tabel terdistribusi akan dikonversi secara otomatis menjadi default.

• Konten migrasi:

  • Konten yang didukung untuk migrasi:

    • Database, kamus data, dan materialized view.

    • Skema tabel: Semua skema tabel kecuali tabel engine Kafka dan RabbitMQ.

    • Data: Migrasi inkremental data dari tabel keluarga MergeTree.

  • Konten yang tidak didukung untuk migrasi:

    • Tabel dan data tabel engine Kafka dan RabbitMQ.

    • Data dari tabel non-MergeTree, seperti tabel eksternal dan tabel Log.

    Penting

    Selama proses migrasi, Anda harus menangani konten yang tidak didukung secara manual sesuai langkah yang disediakan.

  • Volume data untuk migrasi:

    • Data dingin: Migrasi data dingin relatif lambat. Kami menyarankan Anda membersihkan sebanyak mungkin data dingin dari kluster yang dikelola sendiri agar volume total tidak melebihi 1 TB. Jika tidak, waktu migrasi yang lama dapat menyebabkan tugas gagal.

    • Data panas: Jika volume data panas melebihi 10 TB, kemungkinan besar tugas migrasi akan gagal. Kami tidak menyarankan menggunakan solusi ini untuk migrasi dalam kasus tersebut.

    Jika volume data Anda melebihi batas ini, gunakan solusi Migrasi manual sebagai gantinya.

Dampak pada kluster

• Kluster yang dikelola sendiri:

  • Membaca data dari kluster yang dikelola sendiri meningkatkan penggunaan CPU dan memori.

  • Operasi DDL tidak diizinkan.

• Kluster tujuan:

  • Menulis data ke kluster tujuan meningkatkan penggunaan CPU dan memori.

  • Operasi DDL tidak diizinkan.

  • Operasi DDL tidak diizinkan pada database dan tabel yang sedang dimigrasikan. Pembatasan ini tidak berlaku untuk database dan tabel lainnya.

  • Proses merge dihentikan untuk database dan tabel yang sedang dimigrasikan. Proses merge tidak dihentikan untuk database dan tabel lainnya.

  • Kluster melakukan restart sebelum tugas migrasi dimulai dan melakukan restart lagi setelah tugas selesai.

  • Setelah migrasi selesai, kluster mengalami periode operasi merge berfrekuensi tinggi. Hal ini meningkatkan penggunaan I/O dan latensi permintaan bisnis. Kami menyarankan Anda merencanakan potensi dampak peningkatan latensi permintaan bisnis. Anda harus menghitung durasi spesifik operasi merge. Untuk informasi selengkapnya tentang perhitungan ini, lihat Hitung waktu merge setelah migrasi.

Prosedur

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

SET GLOBAL allow_experimental_database_materialized_mysql = 1;

Langkah 5: Evaluasi apakah migrasi dapat diselesaikan

Jika kecepatan tulis kluster sumber kurang dari 20 MB/detik, Anda dapat melewati langkah ini.

Jika kecepatan tulis kluster sumber lebih dari 20 MB/detik, kecepatan tulis teoretis satu node di kluster tujuan juga harus lebih dari 20 MB/detik. Untuk memastikan kecepatan tulis kluster tujuan dapat mengimbangi kecepatan tulis kluster sumber dan migrasi dapat berhasil, Anda harus memeriksa kecepatan tulis aktual kluster tujuan untuk mengevaluasi kelayakan migrasi. Ikuti langkah-langkah berikut:

1. Anda dapat melihat Disk throughput kluster tujuan untuk menentukan kecepatan tulis aktualnya. Untuk informasi selengkapnya tentang cara melihat Disk throughput, lihat Lihat informasi pemantauan kluster.

2. Tentukan hubungan antara kecepatan tulis kluster tujuan dan sumber.

   1. Jika kecepatan tulis Kluster tujuan lebih besar dari kecepatan tulis Kluster sumber, migrasi kemungkinan besar akan berhasil. Lanjutkan ke Langkah 6.

   2. Jika kecepatan tulis kluster tujuan kurang dari kecepatan tulis kluster sumber: Migrasi memiliki kemungkinan tinggi untuk gagal. Kami menyarankan Anda membatalkan tugas migrasi dan menggunakan migrasi manual untuk memigrasikan data.

Langkah 6: Pantau tugas migrasi dan perkirakan kapan harus menghentikan penulisan ke kluster yang dikelola sendiri

1. Login ke Konsol ApsaraDB for ClickHouse.

2. Di daftar Instans Edisi Komunitas, klik ID kluster tujuan.

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

4. Di halaman daftar migrasi instans, Anda dapat melakukan operasi berikut:

   • Lihat status dan informasi fase berjalan tugas migrasi.

     Penting

     Pantau dengan cermat Running Information tugas tujuan. Berdasarkan perkiraan waktu tersisa di kolom Running Information, ikuti Langkah 7 untuk menghentikan penulisan ke kluster yang dikelola sendiri dan menangani tabel engine Kafka dan RabbitMQ.

   • Klik View Details di kolom Tindakan untuk membuka halaman detail tugas. Halaman ini mencakup detail berikut:

     Catatan

     Jika tugas migrasi berakhir (statusnya Selesai atau Dibatalkan), konten di halaman Lihat Detail di konsol akan dihapus. Anda dapat melihat daftar skema tabel yang dimigrasikan di kluster tujuan dengan menjalankan pernyataan SQL berikut.

     SELECT `database`, `name`, `engine_full` FROM `system`.`tables` WHERE `database` NOT IN ('system', 'INFORMATION_SCHEMA', 'information_schema');

     • Semua skema tabel yang dimigrasikan dan status keberhasilan migrasinya.

     • Semua struktur database yang dimigrasikan dan status keberhasilan migrasinya.

     • Semua pesan kesalahan untuk migrasi database dan tabel yang gagal.

   Tabel berikut menjelaskan status tugas migrasi dan fungsinya masing-masing.

   Status Tugas	Deskripsi Fungsi
   Sedang berjalan	Menyiapkan lingkungan dan resource untuk migrasi.
   Inisialisasi	Menginisialisasi tugas migrasi.
   Migrasi Konfigurasi	Memigrasikan konfigurasi kluster.
   Migrasi Skema	Memigrasikan semua database, bersama tabel keluarga MergeTree dan tabel Distributed.
   Migrasi Data	Memigrasikan data secara inkremental dari tabel keluarga MergeTree.
   Migrasi Skema Lainnya	Memigrasikan materialized view dan skema tabel non-MergeTree.
   Pemeriksaan Data	Memeriksa apakah volume data tabel yang telah selesai di kluster tujuan konsisten dengan volume data di kluster yang dikelola sendiri. Jika tidak, tugas mungkin tidak selesai. Kami menyarankan untuk memulai ulang migrasi.
   Pasca-konfigurasi	Konfigurasi sistem kluster tujuan setelah migrasi selesai, seperti membersihkan situs migrasi dan mengaktifkan penulisan ke instans sumber.
   Selesai	Tugas migrasi selesai.
   Dibatalkan	Tugas migrasi telah dibatalkan.

Langkah 7: Hentikan penulisan ke kluster yang dikelola sendiri dan tangani tabel engine Kafka dan RabbitMQ

Sebelum mengalihkan layanan bisnis Anda ke kluster baru, Anda harus memastikan tidak ada data baru yang ditulis ke instans yang dikelola sendiri untuk menjamin integritas data setelah migrasi. Untuk melakukannya, Anda harus menghentikan operasi tulis bisnis dan menghapus tabel Kafka dan RabbitMQ. Ikuti langkah-langkah berikut:

1. Masuk ke kluster yang dikelola sendiri dan jalankan pernyataan berikut untuk mengkueri tabel yang perlu diproses.

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

2. Anda dapat melihat pernyataan pembuatan tabel untuk tabel target.

   SHOW CREATE TABLE <target_table_name>;

3. Login ke kluster tujuan dan eksekusi pernyataan pembuatan tabel yang Anda dapatkan pada langkah sebelumnya. Untuk informasi selengkapnya tentang cara login ke kluster tujuan, lihat Hubungkan ke kluster ClickHouse menggunakan DMS.

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

   Penting

   Saat menghapus tabel Kafka, Anda juga harus menghapus materialized view yang mereferensinya. Jika tidak, migrasi materialized view tidak dapat diselesaikan, yang menyebabkan seluruh tugas migrasi gagal.

Langkah 8: Selesaikan tugas migrasi

Operasi Complete menyelesaikan migrasi setelah Anda menghentikan penulisan ke kluster yang dikelola sendiri. Operasi ini menyelesaikan migrasi data yang tersisa, melakukan pemeriksaan volume data, dan memigrasikan skema database dan tabel yang tersisa. Anda dapat melihat data yang dimigrasikan di detail tugas.

1. Login ke Konsol ApsaraDB for ClickHouse.

2. Di halaman Clusters, pilih Clusters of Community-compatible Edition dan klik ID kluster target.

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

4. Di kolom Actions untuk tugas migrasi tujuan, klik Complete Migration.

5. Di kotak dialog Complete Migration, klik OK.

Langkah 9: Migrasikan data bisnis dari tabel non-MergeTree

Tugas migrasi hanya mendukung migrasi skema tabel non-MergeTree, seperti tabel eksternal dan tabel Log. Setelah tugas migrasi selesai, tabel-tabel ini di kluster tujuan hanya berisi skema tabel tanpa data bisnis. Anda harus memigrasikan data bisnis secara manual. Ikuti langkah-langkah berikut:

1. Login ke kluster yang dikelola sendiri dan jalankan pernyataan berikut untuk melihat tabel non-MergeTree yang datanya perlu dimigrasikan.

   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 migrasikan data tabel menggunakan fungsi remote. Untuk informasi selengkapnya, lihat Migrasi data menggunakan fungsi remote.

Operasi lainnya

Saat tugas migrasi selesai, Migration Status berubah menjadi Selesai. Namun, daftar tugas tidak langsung diperbarui. Kami menyarankan Anda memperbarui halaman secara berkala untuk memeriksa status tugas.

Metode 1: Migrasi menggunakan perintah BACKUP dan RESTORE

Untuk informasi selengkapnya, lihat Gunakan perintah BACKUP dan RESTORE untuk backup dan restore data.

Metode 2: Migrasi menggunakan pernyataan INSERT FROM SELECT