ApsaraDB for ClickHouse:Migrasi dari ClickHouse yang dikelola sendiri ke Cloud ClickHouse

Selama migrasi

• Selama migrasi, proses merge dijeda di kluster tujuan tetapi berlanjut di kluster yang dikelola sendiri.

  Catatan

  Jika tugas migrasi berjalan lama, metadata berlebihan dapat menumpuk di kluster tujuan. Kami menyarankan agar durasi tugas migrasi tidak melebihi 5 hari. Tugas yang melebihi 5 hari akan dibatalkan secara otomatis.

• Kluster tujuan harus berupa kluster default. Jika kluster yang dikelola sendiri menggunakan nama berbeda, layanan secara otomatis mengonversi definisi cluster di tabel terdistribusi menjadi default.

Lingkup migrasi

• Objek yang didukung

  • Database, kamus data, dan tampilan materialisasi.

    • Layanan ini mendukung migrasi kamus data yang dibuat dengan SQL, tetapi tidak yang dibuat dengan XML.

      Untuk memverifikasi hal ini, jalankan pernyataan berikut: SELECT * FROM system.dictionaries WHERE (database = '') OR isNull(database);. Jika pernyataan tersebut mengembalikan baris apa pun, ini menunjukkan Anda memiliki kamus data yang dibuat menggunakan XML.

    • Saat kamus data mengakses layanan eksternal, pastikan layanan eksternal tersedia dan kluster ditambahkan ke daftar izinnya. Jika sumber data untuk kamus data adalah tabel internal di kluster ClickHouse saat ini dan parameter HOST dalam definisinya adalah alamat IP, akses ke kamus tersebut dapat gagal setelah migrasi karena perubahan alamat IP. Anda harus mengonfirmasi ulang HOST kluster ClickHouse saat ini dan membuat manual kamus data tersebut.

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

  • Data: Migrasi inkremental data dari tabel keluarga MergeTree.

• Objek dan data yang tidak didukung

  • Tabel mesin Kafka dan RabbitMQ, serta datanya.

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

  Penting

  Anda harus memigrasikan item yang tidak didukung di atas secara manual.

• Batasan volume data

  • Data dingin: Memigrasikan data dingin lambat. Untuk mencegah kegagalan akibat waktu migrasi lama, kami menyarankan membersihkan data dingin dari kluster yang dikelola sendiri agar volume total tidak melebihi 1 TB.

  • Data panas: Jika volume data panas melebihi 10 TB, tugas migrasi kemungkinan besar akan gagal.

  Jika volume data Anda melebihi batasan ini, pertimbangkan menggunakan solusi migrasi manual.

Langkah 1: Periksa kluster dan aktifkan tabel sistem

Sebelum memigrasikan data, modifikasi file config.xml di kluster yang dikelola sendiri untuk mengaktifkan migrasi inkremental. Modifikasi yang diperlukan bergantung pada apakah tabel system.part_log dan system.query_log diaktifkan.

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

Langkah 3: (Opsional) Aktifkan MaterializedMySQL engine

Jika kluster yang dikelola sendiri Anda berisi tabel yang menggunakan mesin MaterializedMySQL, jalankan pernyataan berikut untuk mengaktifkan mesin ini.

SET GLOBAL allow_experimental_database_materialized_mysql = 1;

Langkah 4: Catat dan bersihkan tabel mesin Kafka/RabbitMQ

Sebelum memulai migrasi, catat definisi semua tabel mesin Kafka/RabbitMQ dan tampilan materialisasi downstream-nya di kluster yang dikelola sendiri, tangani tabel implisit, lalu hapus tabel-tabel ini untuk menghindari kesalahan 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 tabel yang bergantung pada tabel ini
   dependencies_table: tabel yang bergantung pada tabel ini
   Dari dependencies_database dan dependencies_table, Anda dapat mengidentifikasi tampilan materialisasi yang bergantung pada tabel Kafka/RabbitMQ
   */
   SELECT * FROM system.tables WHERE engine IN ('RabbitMQ', 'Kafka');

2. Lihat definisi tampilan materialisasi untuk memeriksa apakah tabel targetnya adalah tabel implisit.

   /*
   Lihat definisi tampilan materialisasi.
   Jika tabel target tampilan materialisasi adalah tabel implisit, beri perhatian khusus:
   Menghapus tampilan materialisasi juga akan menghapus tabel implisit, menyebabkan kehilangan data.
   Contoh: Jika CREATE MATERIALIZED VIEW [db.]table_name [TO[db.]name] tidak menentukan TO,
   sistem secara otomatis membuat tabel implisit, 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 tampilan materialisasi adalah tabel implisit, RENAME tabel target ke nama baru untuk mencegah kehilangan data saat tampilan materialisasi di-drop nanti.

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

4. Hapus tabel mesin Kafka/RabbitMQ dan tampilan materialisasi downstream-nya.

   -- Drop tampilan materialisasi terlebih dahulu
   DROP TABLE <DATABASE>.<MATERIALIZED_VIEW_NAME>;
   -- Lalu drop tabel mesin Kafka/RabbitMQ
   DROP TABLE <DATABASE>.<KAFKA_OR_RABBITMQ_TABLE_NAME>;

Langkah 5: Buat tugas migrasi data

1. Login ke Konsol ApsaraDB for ClickHouse.

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

3. Di panel navigasi kiri, pilih Data Migration and Synchronization > Migration from ClickHouse.

4. Di halaman tugas migrasi, klik Create Migration Task.

   1. Konfigurasikan instans sumber dan tujuan.

      Konfigurasikan pengaturan berikut dan klik Test Connectivity and Proceed.

      Catatan

      Jika pengujian koneksi berhasil, lanjutkan ke langkah berikutnya. Jika pengujian koneksi gagal, konfigurasi ulang instans sumber dan tujuan berdasarkan petunjuk.

      Parameter kluster sumber

      Parameter	Deskripsi	Contoh
      Source Access Method	Pilih Express Connect, VPN Gateway, Smart Access Gateway, or Self-managed ClickHouse Clusters on an ECS Instance.	Express Connect, VPN Gateway, Smart Access Gateway, or Self-managed ClickHouse Clusters on an ECS Instance
      Cluster Name	Nama kluster sumber. Nama hanya boleh berisi angka dan huruf kecil.	source
      Source Cluster Name	Jalankan SELECT * FROM system.clusters; untuk mendapatkan Source Cluster Name.	default
      VPC IP Address	Alamat IP dan PORT (alamat TCP) setiap shard di kluster, dipisahkan koma. Penting Anda tidak dapat menggunakan nama domain VPC atau alamat SLB kluster ApsaraDB for ClickHouse. Format: IP:PORT,IP:PORT,...... Metode untuk mendapatkan alamat IP dan PORT kluster bervariasi tergantung skenario migrasi data. Migrasi lintas akun atau lintas wilayah 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 = 'default' and replica_num = 1; Di sini, replica_num=1 memilih set replika pertama. Anda juga dapat memilih set replika lain atau memilih satu replika dari setiap shard. Migrasi ClickHouse non-Alibaba Cloud Jika alamat IP tidak dapat dengan mudah dipetakan ke Alibaba Cloud, 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; Parameter dijelaskan sebagai berikut: cluster_name: nama kluster tujuan. replica_num=1 memilih set replika pertama. Anda juga dapat memilih set replika lain atau memilih satu replika dari setiap shard. Jika alamat IP dan port dipetakan ke Alibaba Cloud melalui terjemahan jaringan, Anda harus mengonfigurasi alamat IP dan port yang dipetakan sesuai.	192.168.0.5:9000,192.168.0.6:9000
      Database Account	Akun database kluster sumber.	test
      Database Password	Kata sandi untuk akun database kluster sumber.	test******

      Parameter kluster tujuan

      Parameter	Deskripsi	Contoh
      Database Account	Akun database kluster tujuan.	test
      Database Password	Kata sandi untuk akun database kluster tujuan.	test******

   2. Konfirmasi konten migrasi.

      Tinjau dengan cermat informasi tentang data yang akan dimigrasikan di halaman, lalu klik Next: Pre-detect and Start Synchronization.

   3. Sistem menjalankan pemeriksaan awal pada tautan migrasi di latar belakang dan memulai tugas.

      Sistem menjalankan Instance Status Detection, Storage Space Detection, dan Local Table and Distributed Table Detection pada kluster sumber dan tujuan.

      • Jika pemeriksaan awal berhasil:

        Setelah pemeriksaan awal berhasil, halaman menunjukkan bahwa tiga pemeriksaan telah lulus: Instance status check, Storage space check, dan Local table and distributed table check. Bagian atas halaman menunjukkan perkiraan waktu migrasi 2 menit, dan menjelaskan dampak selama migrasi:

        • Instans sumber dapat dibaca dan ditulis tetapi operasi DDL tidak dapat dilakukan.

        • Instans tujuan dapat dibaca tetapi tabel yang dimigrasikan tidak dapat ditulis.

        • Saat waktu tersisa kurang dari 10 menit, Anda harus berhenti menulis untuk memicu akhir migrasi.

        • Tabel non-MergeTree hanya menyimpan struktur tabel tanpa migrasi data setelah penskalaan.

        1. Tinjau dengan cermat bagaimana proses migrasi data memengaruhi instans.

        2. Klik Completed.

           Penting

           • Setelah Anda mengklik Selesai, sistem membuat dan memulai tugas, dan statusnya berubah menjadi Berjalan. Anda dapat melihat tugas di daftar tugas.

           • Setelah membuat tugas, Anda harus memantaunya. Di tahap akhir migrasi, Anda harus menghentikan operasi tulis ke kluster yang dikelola sendiri dan memigrasikan skema database dan tabel yang tersisa. Untuk informasi lebih lanjut, lihat Pantau tugas migrasi dan hentikan penulisan ke kluster yang dikelola sendiri.

      • Jika pemeriksaan awal gagal: Ikuti petunjuk dalam pesan kesalahan dan jalankan kembali tugas migrasi data. Tabel berikut menjelaskan item pemeriksaan awal dan persyaratannya. Untuk informasi lebih lanjut tentang pesan kesalahan pemeriksaan awal dan solusinya, lihat Kesalahan pemeriksaan awal migrasi dan solusinya.

        Item pemeriksaan	Persyaratan
        Instance Status Detection	Tugas migrasi data tidak dapat dimulai jika tugas manajemen (seperti skala-keluar, upgrade, atau downgrade) sedang berjalan di kluster sumber atau tujuan.
        Storage Space Detection	Ruang penyimpanan tersedia kluster tujuan harus minimal 1,2 kali ruang penyimpanan yang digunakan kluster yang dikelola sendiri.
        Local Table and Distributed Table Detection	Jika tabel lokal di kluster yang dikelola sendiri tidak memiliki tabel terdistribusi yang sesuai atau memiliki lebih dari satu tabel terdistribusi, pemeriksaan gagal. Untuk mengatasinya, hapus tabel terdistribusi yang berlebihan atau buat tabel terdistribusi unik untuk tabel lokal tersebut.

Langkah 8: Bangun ulang tabel mesin Kafka/RabbitMQ di kluster yang dikelola sendiri

Setelah tugas migrasi memasuki fase migrasi data (yaitu, migrasi skema tabel selesai), gunakan pernyataan DDL yang disimpan sebelumnya untuk membangun ulang tabel mesin Kafka/RabbitMQ dan tampilan materialisasi downstream-nya di kluster yang dikelola sendiri. Setelah dibangun ulang, data inkremental kembali mengalir dan secara otomatis disinkronkan ke kluster tujuan.

-- Bangun ulang tabel mesin Kafka/RabbitMQ di kluster yang dikelola sendiri
CREATE TABLE <DATABASE>.<KAFKA_OR_RABBITMQ_TABLE_NAME> (...)
ENGINE = Kafka/RabbitMQ
SETTINGS ...;

-- Bangun ulang tampilan materialisasi (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>;

Langkah 9: Hentikan penulisan dan lakukan cutover

Saat perkiraan waktu migrasi tersisa kurang dari 10 menit atau progres migrasi mencapai 99%, lakukan langkah cutover berikut:

1. Hentikan penulisan bisnis. Di kluster yang dikelola sendiri, hapus tabel mesin Kafka/RabbitMQ yang dibangun ulang sebelumnya dan tampilan materialisasi downstream-nya.

   -- Drop tampilan materialisasi terlebih dahulu
   DROP TABLE <DATABASE>.<MATERIALIZED_VIEW_NAME>;
   -- Lalu drop tabel mesin Kafka/RabbitMQ
   DROP TABLE <DATABASE>.<KAFKA_OR_RABBITMQ_TABLE_NAME>;

2. Tunggu hingga progres migrasi mencapai 100% dan migrasi selesai sepenuhnya.

3. Hubungkan ke kluster tujuan dan gunakan pernyataan DDL yang disimpan sebelumnya untuk membangun ulang tabel mesin Kafka/RabbitMQ dan tampilan materialisasi downstream-nya.

   Penting

   Jika Anda melakukan operasi RENAME pada tabel target implisit sebelumnya, gunakan klausa TO yang mengarah ke tabel target yang diganti namanya saat membangun ulang tampilan materialisasi.

   -- Bangun ulang tabel mesin Kafka/RabbitMQ di kluster tujuan
   CREATE TABLE <DATABASE>.<KAFKA_OR_RABBITMQ_TABLE_NAME> (...)
   ENGINE = Kafka/RabbitMQ
   SETTINGS ...;

   -- Bangun ulang tampilan materialisasi (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 tujuan berfungsi dengan baik dan data mengalir secara normal.

Langkah 10: Selesaikan migrasi

Setelah menghentikan penulisan ke kluster yang dikelola sendiri, Anda dapat Complete the task. Langkah ini memigrasikan data yang tersisa, melakukan pemeriksaan volume data, dan memigrasikan skema database dan tabel yang tersisa. Anda dapat melihat konten yang dimigrasikan di detail tugas.

1. Login ke Konsol ApsaraDB for ClickHouse.

2. Di halaman Clusters, pilih Clusters of Community-compatible Edition, lalu klik ID kluster tujuan.

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

4. Untuk tugas migrasi target, klik Complete Migration di kolom Actions.

5. Di kotak dialog Complete Migration, klik OK.

Langkah 11: Migrasikan data untuk tabel non-MergeTree

Tugas migrasi hanya memigrasikan skema tabel non-MergeTree (seperti tabel eksternal dan tabel Log), membuatnya di kluster tujuan tanpa data bisnis apa pun. Anda harus memigrasikan data bisnis secara manual. Ikuti langkah-langkah 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 memigrasikan data tabel. Untuk petunjuk detail, lihat Migrasi data menggunakan fungsi remote.

Operasi lainnya

Saat tugas migrasi selesai, Migration Status berubah menjadi Completed. Daftar tugas tidak segera diperbarui, jadi segarkan halaman secara berkala untuk melihat status terbaru.

Metode 1: Gunakan perintah BACKUP dan RESTORE

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

Metode 2: Gunakan pernyataan INSERT FROM SELECT