All Products
Search
Document Center

ApsaraDB for ClickHouse:Migrasi dari ClickHouse yang dikelola sendiri ke Edisi Community-Compatible ClickHouse

Last Updated:Mar 29, 2026

Kluster ClickHouse yang dikelola sendiri sulit diskalakan, mahal dalam pemeliharaan, dan tidak memiliki fitur disaster recovery tingkat enterprise. Topik ini menjelaskan cara memigrasikan data Anda ke kluster ApsaraDB for ClickHouse Edisi Community-Compatible.

Pilih metode migrasi

MetodeKelebihanKekuranganGunakan saat
Console migrationAntarmuka terpandu. Tidak perlu migrasi metadata secara manual.Hanya dapat memigrasikan seluruh kluster — tidak mendukung pemilihan per database, per tabel, atau data historis.Memigrasikan seluruh kluster dalam batas volume data.
Migrasi manualKontrol penuh atas database dan tabel mana yang akan dimigrasikan.Operasi kompleks. Migrasi metadata dilakukan secara manual.Memigrasikan database atau tabel tertentu; data dingin melebihi 1 TB; data panas melebihi 10 TB; atau kluster tidak memenuhi persyaratan migrasi melalui konsol.

Prasyarat

Sebelum memulai, pastikan Anda telah:

  • Memiliki kluster tujuan ApsaraDB for ClickHouse Edisi Community-Compatible dengan akun yang memiliki izin tertinggi. Lihat Manajemen akun untuk kluster Edisi Community-Compatible dan Ubah izin

  • Memiliki akun kluster ClickHouse yang dikelola sendiri dengan izin baca pada database dan tabel, serta izin menjalankan perintah SYSTEM

  • Memiliki konektivitas jaringan antara kluster tujuan dan kluster yang dikelola sendiri

Virtual Private Cloud (VPC) yang sama: Tambahkan alamat IP semua node kluster tujuan dan Blok CIDR IPv4 dari ID vSwitch-nya ke daftar putih kluster yang dikelola sendiri.

VPC berbeda, pusat data lokal, atau cloud lain: Pastikan konektivitas jaringan sebelum memigrasikan. Lihat Bagaimana cara menetapkan koneksi jaringan antara kluster tujuan dan sumber data?

Validasi terlebih dahulu di lingkungan pengujian

Sebelum memigrasikan data produksi, jalankan prosedur migrasi lengkap di lingkungan pengujian untuk memverifikasi kompatibilitas dan performa bisnis. Hal ini membantu mengidentifikasi masalah sebelum memengaruhi produksi.

  1. Buat tugas migrasi menggunakan langkah-langkah di bagian Migrasi melalui konsol atau Migrasi manual.

  2. Analisis kompatibilitas dan performa. Lihat Analisis dan solusi untuk hambatan kompatibilitas dan performa dalam migrasi ClickHouse yang dikelola sendiri ke cloud.

Migrasi melalui konsol

Migrasi melalui konsol menyediakan antarmuka terpandu dan menangani metadata secara otomatis, tetapi memiliki batasan berikut.

Batasan

  • Versi kluster tujuan harus 21.8 atau lebih baru.

  • Hanya mendukung migrasi penuh dan inkremental seluruh kluster. Database, tabel, atau snapshot data historis individual tidak dapat dipilih.

Batas volume data

Jenis dataBatasPerilaku jika melebihi
Data dinginTotal disarankan ≤ 1 TBMigrasi lambat; risiko tinggi kegagalan tugas
Data panas≤ 10 TBKemungkinan besar gagal

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

Apa yang dimigrasikan

Dimigrasikan:

  • Database, kamus data, dan materialized view

  • Skema tabel untuk semua mesin tabel kecuali Kafka dan RabbitMQ

  • Data dari tabel keluarga MergeTree (migrasi inkremental)

Tidak dimigrasikan:

  • Skema tabel Kafka dan RabbitMQ beserta datanya

  • Data dalam tabel non-MergeTree (tabel eksternal, tabel Log)

Penting

Tangani konten yang tidak didukung secara manual selama proses migrasi. Langkah-langkahnya termasuk dalam prosedur di bawah ini.

Dampak potensial

Kluster yang dikelola sendiri:

  • Peningkatan penggunaan CPU dan memori akibat operasi baca

  • Operasi DDL diblokir

Kluster tujuan:

  • Peningkatan penggunaan CPU dan memori akibat operasi tulis

  • Operasi DDL diblokir

  • Operasi DDL diblokir pada database dan tabel yang dimigrasikan (pembatasan ini tidak berlaku untuk database dan tabel lainnya)

  • Penggabungan (merges) dijeda pada database dan tabel yang dimigrasikan (penggabungan pada database dan tabel lain tidak terpengaruh)

  • Kluster melakukan restart saat awal dan akhir tugas migrasi

  • Setelah migrasi selesai, kluster menjalankan penggabungan frekuensi tinggi, yang meningkatkan penggunaan I/O dan latensi permintaan. Hitung durasi penggabungan yang diharapkan menggunakan Hitung waktu penggabungan pasca-migrasi.

Jika migrasi memakan waktu terlalu lama, metadata menumpuk di kluster tujuan. Selesaikan migrasi dalam waktu 5 hari setelah membuat tugas.

Prosedur

Langkah 1: Aktifkan tabel sistem di kluster yang dikelola sendiri

Migrasi melalui konsol memerlukan system.part_log dan system.query_log diaktifkan dan dikonfigurasi dengan benar di config.xml kluster yang dikelola sendiri.

Log tidak diaktifkan

Jika `system.part_log` dan `system.query_log` belum diaktifkan, tambahkan blok berikut ke config.xml:

system.part_log

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

system.query_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>

Log diaktifkan

Jika `system.part_log` dan `system.query_log` sudah diaktifkan, bandingkan konfigurasi yang ada dengan blok di atas. Jika berbeda, perbarui agar sesuai, lalu hapus dan buat ulang tabel-tabel tersebut:

system.part_log

system.query_log

DROP TABLE system.part_log;
DROP TABLE system.query_log;

Tabel akan dibuat ulang secara otomatis pada penyisipan data berikutnya.

Langkah 2: Atur kompatibilitas pada kluster tujuan

Konfigurasikan kluster tujuan agar menggunakan tingkat kompatibilitas yang sama dengan kluster yang dikelola sendiri. Hal ini meminimalkan perubahan yang diperlukan setelah migrasi.

  1. Periksa versi kedua kluster:

    SELECT version();
  2. Jika versinya berbeda, atur parameter kompatibilitas pada kluster tujuan agar sesuai dengan versi kluster yang dikelola sendiri. Contohnya:

    SET GLOBAL compatibility = '22.8';

Langkah 3 (Opsional): Aktifkan mesin MaterializedMySQL

Jika kluster yang dikelola sendiri memiliki tabel yang menggunakan mesin MaterializedMySQL, jalankan perintah berikut pada kluster tujuan:

SET GLOBAL allow_experimental_database_materialized_mysql = 1;
Komunitas ClickHouse tidak lagi memelihara mesin MaterializedMySQL. Setelah migrasi, gunakan Data Transmission Service (DTS) untuk menyinkronkan data MySQL ke tabel ReplacingMergeTree sebagai gantinya. Lihat Gunakan integrasi tanpa hambatan untuk menyinkronkan data dari ApsaraDB RDS for MySQL ke kluster ApsaraDB for ClickHouse dan Sinkronkan data dari ApsaraDB RDS for MySQL ke kluster ApsaraDB for ClickHouse.

Langkah 4: Buat tugas migrasi

  1. Login ke konsol ApsaraDB for ClickHouse.

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

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

  4. Klik Create Migration Task.

  5. Konfigurasikan pengaturan koneksi kluster sumber: Untuk mendapatkan alamat IP dan port kluster sumber: replica_num = 1 memilih set replika pertama. Anda dapat memilih set replika lain sesuai kebutuhan.

    Migrasi lintas akun atau lintas wilayah

    Instans ClickHouse Alibaba Cloud lintas akun atau lintas wilayah: ``sql SELECT shard_num, replica_num, host_address AS ip, port FROM system.clusters WHERE cluster = 'default' AND replica_num = 1; ``

    Migrasi instans non-Alibaba Cloud

    Instans ClickHouse non-Alibaba Cloud: ``sql SELECT shard_num, replica_num, host_address AS ip, port FROM system.clusters WHERE cluster = '<cluster_name>' AND replica_num = 1; ``

    Parameter kluster sumber

    Pengaturan kluster sumber:

    FieldDeskripsiContoh
    Source Access MethodPilih Express Connect, VPN Gateway, Smart Access Gateway, or Self-managed ClickHouse Clusters on an ECS Instance.
    Cluster NameNama untuk kluster sumber. Hanya angka dan huruf kecil.source
    Source Cluster NameNama kluster internal dari SELECT * FROM system.clusters;.default
    VPC IP AddressPasangan TCP IP:PORT untuk setiap shard, dipisahkan koma. Jangan gunakan nama domain VPC atau alamat SLB. Format: IP:PORT,IP:PORT,...192.168.0.5:9000,192.168.0.6:9000
    Database AccountAkun untuk kluster sumber.test
    Database PasswordKata sandi untuk akun kluster sumber.

    Parameter kluster tujuan

    Pengaturan kluster tujuan:

    FieldDeskripsi
    Database AccountAkun untuk kluster tujuan.
    Database PasswordKata sandi untuk akun kluster tujuan.

    image

  6. Klik Test Connection and Proceed. Jika pengujian gagal, perbaiki pengaturan koneksi dan coba lagi.

  7. Tinjau konten migrasi dan klik Next: Pre-detect and Start Synchronization.

  8. Sistem menjalankan tiga pemeriksaan awal. Jika semua pemeriksaan lolos: Jika pemeriksaan gagal, ikuti panduan penanganan error di Pesan error pra-periksa dan solusinya.

    1. Baca prompt dampak dengan cermat.

    2. Klik Completed untuk membuat dan memulai tugas.

    Item PemeriksaanPersyaratan
    Instance Status DetectionTidak ada tugas manajemen yang sedang berjalan (scale-out, upgrade, atau downgrade) pada kedua kluster.
    Storage Space DetectionRuang penyimpanan kluster tujuan ≥ 1,2× ruang yang digunakan oleh kluster self-managed.
    Local Table and Distributed Table DetectionSetiap tabel lokal di kluster self-managed harus memiliki tepat satu tabel terdistribusi yang sesuai.

    image

Langkah 5: Evaluasi apakah migrasi dapat diselesaikan

Lewati langkah ini jika kecepatan penulisan kluster sumber kurang dari 20 MB/detik.

Jika kecepatan penulisan kluster sumber melebihi 20 MB/detik, periksa apakah kluster tujuan mampu mengimbangi:

  1. Lihat metrik Disk throughput pada kluster tujuan. Lihat Lihat informasi pemantauan kluster.

  2. Bandingkan kecepatan penulisan:

    • Kecepatan penulisan tujuan > kecepatan penulisan sumber: migrasi kemungkinan besar succeed. Lanjutkan ke Langkah 6.

    • Kecepatan penulisan tujuan < kecepatan penulisan sumber: migrasi kemungkinan besar gagal. Batalkan tugas dan gunakan Migrasi manual sebagai gantinya.

Langkah 6: Pantau tugas migrasi

  1. Login ke konsol ApsaraDB for ClickHouse.

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

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

  4. Pantau status tugas dan kolom Running Information.

Penting

Lacak perkiraan waktu tersisa yang ditampilkan di kolom Running Information. Saat tugas hampir selesai, ikuti Langkah 7 untuk menghentikan penulisan dan menangani tabel Kafka dan RabbitMQ.

Untuk melihat detail tugas, klik View Details di kolom Actions. Halaman detail menampilkan skema tabel yang dimigrasikan, struktur database, dan pesan error apa pun.

Setelah tugas berakhir (status: Completed atau Canceled), halaman View Details akan dikosongkan. Untuk melihat skema tabel yang dimigrasikan setelah itu, jalankan:
SELECT `database`, `name`, `engine_full`
FROM `system`.`tables`
WHERE `database` NOT IN ('system', 'INFORMATION_SCHEMA', 'information_schema');

Status tugas:

StatusDeskripsi
RunningMenyiapkan lingkungan dan resource.
InitializationMenginisialisasi tugas migrasi.
Configuration MigrationMemigrasikan konfigurasi kluster.
Schema MigrationMemigrasikan database, tabel keluarga MergeTree, dan tabel terdistribusi.
Data MigrationMemigrasikan data secara inkremental dari tabel keluarga MergeTree.
Other Schema MigrationMemigrasikan materialized view dan skema tabel non-MergeTree.
Data CheckMemverifikasi bahwa volume data di tujuan sesuai dengan kluster yang dikelola sendiri.
Post-configurationMembersihkan lingkungan migrasi dan mengaktifkan kembali penulisan ke kluster sumber.
CompletedMigrasi selesai.
CanceledMigrasi dibatalkan.

Langkah 7: Hentikan penulisan dan tangani tabel Kafka dan RabbitMQ

Sebelum mengalihkan traffic bisnis ke kluster tujuan, hentikan semua penulisan ke kluster yang dikelola sendiri dan buat secara manual tabel Kafka dan RabbitMQ di tujuan.

  1. Di kluster yang dikelola sendiri, identifikasi tabel yang perlu diproses:

    SELECT * FROM system.tables WHERE engine IN ('RabbitMQ', 'Kafka');
  2. Dapatkan DDL untuk setiap tabel:

    SHOW CREATE TABLE <target_table_name>;
  3. Di kluster tujuan, jalankan pernyataan DDL untuk membuat tabel tersebut. Lihat Hubungkan ke kluster ClickHouse menggunakan DMS untuk instruksi koneksi.

  4. Di kluster yang dikelola sendiri, hapus tabel Kafka dan RabbitMQ.

Penting

Saat menghapus tabel Kafka, hapus juga semua materialized view yang mereferensikannya. Jika tidak, tugas migrasi akan gagal.

Langkah 8: Selesaikan migrasi

Setelah penulisan ke kluster yang dikelola sendiri dihentikan, finalisasi migrasi. Ini akan memigrasikan data yang tersisa, menjalankan pemeriksaan volume data, dan memigrasikan skema database dan tabel yang belum selesai.

Penting

Selesaikan langkah ini dalam waktu 5 hari setelah membuat tugas migrasi. Tugas yang berjalan lebih lama akan mengakumulasi metadata berlebih di kluster tujuan, yang memperlambat migrasi. Jika pemeriksaan volume data gagal, batalkan tugas dan buat yang baru.

  1. Login ke konsol ApsaraDB for ClickHouse.

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

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

  4. Di kolom Actions untuk tugas tersebut, klik Complete Migration.

  5. Di kotak dialog, klik OK.

Langkah 9: Migrasi data untuk tabel non-MergeTree

Tugas migrasi hanya menyalin skema tabel untuk tabel non-MergeTree (tabel eksternal, tabel Log), tetapi tidak menyalin datanya. Migrasikan data tersebut secara manual.

  1. Di kluster yang dikelola sendiri, identifikasi tabel yang perlu migrasi data secara manual:

    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. Di kluster tujuan, migrasikan data menggunakan fungsi remote. Lihat Migrasi data menggunakan fungsi remote di bagian Migrasi manual.

Operasi lainnya

Saat tugas migrasi selesai, statusnya berubah menjadi Completed, tetapi daftar mungkin tidak langsung diperbarui. Muat ulang halaman untuk melihat status terbaru.

OperasiFungsinyaDampakGunakan saat
Stop MigrationMenghentikan migrasi data segera. Melewati pemeriksaan volume data dan memigrasikan skema yang tersisa.Kluster tujuan melakukan restart.Memigrasikan sebagian data untuk pengujian tanpa menghentikan penulisan ke kluster yang dikelola sendiri.
Cancel MigrationMembatalkan tugas secara paksa. Melewati pemeriksaan volume data dan tidak memigrasikan skema yang tersisa.Kluster tujuan melakukan restart. Skema database dan tabel mungkin tidak lengkap. Hapus data yang dimigrasikan dari tujuan sebelum mencoba ulang.Migrasi memengaruhi kluster yang dikelola sendiri dan Anda perlu segera menghentikannya serta mengaktifkan kembali penulisan.

Hentikan migrasi

Hentikan migrasi:

  1. Login ke konsol ApsaraDB for ClickHouse.

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

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

  4. Di kolom Actions, klik Stop Migration dan konfirmasi.

Batalkan migrasi

Batalkan migrasi:

  1. Login ke konsol ApsaraDB for ClickHouse.

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

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

  4. Di kolom Actions, klik Cancel Migration dan konfirmasi.

Migrasi manual

Gunakan migrasi manual ketika Anda memerlukan kontrol granular: memilih database atau tabel tertentu, memigrasikan volume data dingin atau panas yang besar, atau menangani kluster yang tidak dapat menggunakan alat migrasi konsol.

Metode 1: Perintah BACKUP dan RESTORE

Lihat Gunakan perintah BACKUP dan RESTORE untuk backup dan restore data.

Metode 2: INSERT INTO SELECT dengan fungsi remote

Metode dua langkah ini memigrasikan skema tabel terlebih dahulu, lalu datanya.

Langkah 1: Migrasi skema tabel (DDL)

Instal clickhouse-client dengan versi yang sama dengan kluster ApsaraDB for ClickHouse tujuan. Lihat clickhouse-client untuk instruksi unduhan.

  1. Daftar database di kluster yang dikelola sendiri:

    clickhouse-client \
      --host="<old_host>" --port="<old_port>" \
      --user="<old_username>" --password="<old_password>" \
      --query="SHOW databases" > database.list

    Database system tidak perlu dimigrasikan.

  2. Daftar tabel di kluster yang dikelola sendiri. Gunakan salah satu pendekatan berikut:

    Tabel dengan nama yang diawali .inner. adalah representasi internal dari materialized view dan tidak perlu dimigrasikan.
    clickhouse-client \
      --host="<old_host>" --port="<old_port>" \
      --user="<old_username>" --password="<old_password>" \
      --query="SHOW tables from <database_name>" > table.list

    Atau kueri semua database dan tabel sekaligus:

    SELECT DISTINCT database, name FROM system.tables WHERE database != 'system';
  3. Ekspor DDL untuk semua tabel dalam sebuah database:

    clickhouse-client \
      --host="<old_host>" --port="<old_port>" \
      --user="<old_username>" --password="<old_password>" \
      --query="SELECT concat(create_table_query, ';') FROM system.tables WHERE database='<database_name>' FORMAT TabSeparatedRaw" > tables.sql
  4. Buat database target di kluster tujuan, lalu impor DDL-nya:

    ParameterDeskripsi
    <old_host id="49bc4df282xmg"></old_host>Alamat kluster yang dikelola sendiri.
    <old_port></old_port>Port kluster yang dikelola sendiri.
    <old_username></old_username>Akun dengan izin DML baca/tulis, pengaturan, dan DDL.
    <old_password id="349ed6d40fai6"></old_password>Kata sandi untuk akun tersebut.
    <new_host>Alamat kluster ApsaraDB for ClickHouse tujuan.
    <new_port>Port kluster ApsaraDB for ClickHouse tujuan.
    <new_username>Akun dengan izin DML baca/tulis, pengaturan, dan DDL.
    <new_password>Kata sandi untuk akun tersebut.
    clickhouse-client \
      --host="<new_host>" --port="<new_port>" \
      --user="<new_username>" --password="<new_password>" \
      -d '<database_name>' --multiquery < tables.sql

Langkah 2: Migrasi data

Tersedia tiga opsi. Gunakan fungsi remote (Opsi A) jika memungkinkan, karena mendukung migrasi tingkat partisi dan mengurangi penggunaan resource.

Opsi A: Migrasi data menggunakan fungsi remote

Jalankan perintah berikut di kluster tujuan:

  1. (Opsional) Kurangi lalu lintas jaringan dengan mengaktifkan kompresi ZSTD:

    SET network_compression_method = 'ZSTD';

    Untuk memeriksa pengaturan saat ini:

    SELECT * FROM system.settings WHERE name = 'network_compression_method';
  2. Migrasikan data tabel per tabel, opsional dengan filter partisi:

    Untuk versi 20.8, coba gunakan remoteRaw terlebih dahulu. Jika migrasi gagal, minta upgrade versi minor. ``sql INSERT INTO <new_database>.<new_table> SELECT * FROM remoteRaw('<old_endpoint>', <old_database>.<old_table>, '<username>', '<password>') [WHERE _partition_id = '<partition_id>'] SETTINGS max_execution_time = 0, max_bytes_to_read = 0, log_query_threads = 0, max_result_rows = 0; ``
    Penting

    Selalu gunakan titik akhir internal VPC, bukan titik akhir publik.

    Parameter:

    ParameterDeskripsi
    <new_database>Nama database target di kluster tujuan.
    <new_table>Nama tabel target di kluster tujuan.
    <old_endpoint></old_endpoint>Titik akhir sumber (lihat format di bawah).
    <old_database id="55418a01cduev"></old_database>Nama database sumber.
    <old_table></old_table>Nama tabel sumber.
    <username>Akun kluster sumber.
    <password>Kata sandi kluster sumber.
    max_execution_timeWaktu maksimum eksekusi kueri. 0 = tanpa batas.
    max_bytes_to_readByte maksimum yang dibaca dari sumber. 0 = tanpa batas.
    log_query_threadsCatat info thread untuk kueri. 0 = dinonaktifkan.
    max_result_rowsBaris maksimum dalam hasil. 0 = tanpa batas.
    _partition_idID partisi untuk filter. Filter berdasarkan partisi mengurangi penggunaan resource (disarankan).

    Format titik akhir untuk `<old_endpoint>`:

    ClickHouse yang dikelola sendiri
    ApsaraDB for ClickHouse

    Gunakan titik akhir VPC dari instans sumber, bukan titik akhir publik.

    Penting

    Port 3306 dan 9000 adalah nilai tetap.

    • Instans Edisi Community-compatible:

      • Format titik akhir: alamat internal VPC:3306

      • Contoh: cc-2zeqhh5v7y6q*****.clickhouse.ads.aliyuncs.com:3306

    • Instans Edisi Enterprise:

      • Format titik akhir: alamat internal VPC:9000

      • Contoh: cc-bp1anv7jo84ta*****clickhouse.clickhouseserver.rds.aliyuncs.com:9000

    Jenis sumberFormatContoh
    ClickHouse yang dikelola sendiriIP:Port TCP192.168.0.5:9000
    ApsaraDB for ClickHouse Edisi Community-CompatibleVPC_internal_address:3306cc-2zeqhh5v7y6q*****.clickhouse.ads.aliyuncs.com:3306
    ApsaraDB for ClickHouse EnterpriseVPC_internal_address:9000cc-bp1anv7jo84ta*****clickhouse.clickhouseserver.rds.aliyuncs.com:9000
    INSERT INTO <new_database>.<new_table>
    SELECT *
    FROM remote('<old_endpoint>', <old_database>.<old_table>, '<username>', '<password>')
    [WHERE _partition_id = '<partition_id>']
    SETTINGS max_execution_time = 0, max_bytes_to_read = 0, log_query_threads = 0, max_result_rows = 0;

    Untuk mencari ID partisi dan jumlah part:

    SELECT partition_id, count(*) AS part_count
    FROM clusterAllReplicas(default, system, parts)
    WHERE `database` = '<old_database>' AND `table` = '<old_table>'
    GROUP BY partition_id;

Ekspor dan impor file

Opsi B: Ekspor dan impor melalui file CSV

Ekspor dari kluster yang dikelola sendiri:

clickhouse-client \
  --host="<old_host>" --port="<old_port>" \
  --user="<old_username>" --password="<old_password>" \
  --query="SELECT * FROM <database_name>.<table_name> FORMAT CSV" > table.csv

Impor ke kluster tujuan:

clickhouse-client \
  --host="<new_host>" --port="<new_port>" \
  --user="<new_username>" --password="<new_password>" \
  --query="INSERT INTO <database_name>.<table_name> FORMAT CSV" < table.csv
Opsi C: Streaming melalui pipe Linux

Salurkan ekspor dan impor dalam satu perintah tanpa file perantara:

clickhouse-client \
  --host="<old_host>" --port="<old_port>" \
  --user="<username>" --password="<password>" \
  --query="SELECT * FROM <database_name>.<table_name> FORMAT CSV" | \
clickhouse-client \
  --host="<new_host>" --port="<new_port>" \
  --user="<username>" --password="<password>" \
  --query="INSERT INTO <database_name>.<table_name> FORMAT CSV"

Pesan error pra-periksa dan solusinya

Pesan errorPenyebabSolusi
Tabel terdistribusi unik tidak ditemukan atau sharding_key tidak diatur.Tabel lokal di kluster yang dikelola sendiri tidak memiliki tabel terdistribusi yang sesuai.Buat tabel terdistribusi untuk tabel lokal sebelum memigrasikan.
Tabel terdistribusi yang sesuai tidak unik.Tabel lokal memiliki beberapa tabel terdistribusi.Hapus tabel terdistribusi tambahan, simpan hanya satu.
Tabel MergeTree pada kluster multi-replika.Kluster yang dikelola sendiri adalah kluster multi-replika dengan tabel non-replikasi.Lihat Tabel non-replikasi dalam kluster multi-replika di bagian FAQ.
Tabel cadangan data di kluster tujuan.Tujuan sudah memiliki data di tabel yang sesuai.Hapus tabel yang sesuai dari kluster tujuan.
Kolom tabel terdistribusi dan tabel lokal bertentangan.Definisi kolom di tabel terdistribusi dan tabel lokal tidak cocok.Bangun ulang tabel terdistribusi agar sesuai dengan tabel lokal.
Penyimpanan tidak mencukupi.Ruang penyimpanan tidak mencukupi di kluster tujuan.Upgrade disk kluster tujuan. Total ruang tujuan harus ≥ 1,2× ruang yang digunakan oleh kluster yang dikelola sendiri. Lihat Upgrade/Downgrade dan scale-out/scale-in kluster community-compatible.
Tabel sistem tidak ditemukan.Tabel sistem yang diperlukan tidak ada di kluster yang dikelola sendiri.Perbarui config.xml untuk mengaktifkan tabel sistem yang diperlukan. Lihat Langkah 1: Aktifkan tabel sistem.
Tabel tidak lengkap di berbagai node.Tabel tidak ada di beberapa shard.Buat tabel di semua shard. Untuk tabel internal materialized view, ubah nama tabel internal dan bangun ulang materialized view. Lihat Tabel internal materialized view tidak konsisten di berbagai shard.

Hitung waktu penggabungan pasca-migrasi

Setelah migrasi, kluster tujuan menjalankan penggabungan frekuensi tinggi. Hal ini meningkatkan penggunaan I/O dan latensi permintaan. Jika workload Anda sensitif terhadap latensi, pertimbangkan untuk upgrade tipe instans atau tingkat performa ESSD guna memperpendek periode ini. Lihat Scaling vertikal, scale-out, dan scale-in kluster community-compatible.

Rumus ini berlaku untuk kluster single-replika maupun master-replika:

Total waktu penggabungan = MAX(waktu penggabungan data panas, waktu penggabungan data dingin)

  • Waktu penggabungan data panas = data panas per node × 2 ÷ MIN(bandwidth tipe instans, bandwidth disk × n)

  • Waktu penggabungan data dingin = (data dingin ÷ node) ÷ MIN(bandwidth tipe instans, bandwidth baca OSS) + (data dingin ÷ node) ÷ MIN(bandwidth tipe instans, bandwidth tulis OSS)

Cara mendapatkan setiap nilai:

NilaiCara mendapatkan
Data panas per nodeDisk Usage - Single-Node Statistics di Lihat informasi pemantauan kluster.
Data dinginCold storage usage di Lihat informasi pemantauan kluster.
Jumlah nodeSELECT count() FROM system.clusters WHERE cluster = 'default' AND replica_num = 1;
n (disk per node)SELECT count() FROM system.disks WHERE type = 'local';
bandwidth diskThroughput maksimum per disk (MB/detik) di tabel tingkat performa ESSD.
Bandwidth baca OSSTotal Bandwidth Unduh Intranet dan Internet di tabel bandwidth OSS.
Bandwidth tulis OSSTotal Bandwidth Unggah Intranet dan Internet di tabel bandwidth OSS.

Instance type bandwidth reference (nilai minimum):

SpesifikasiBandwidth (MB/s)
Standard 8-core 32 GB250
Standard 16-core 64 GB375
Standard 24-core 96 GB500
Standard 32-core 128 GB625
Standard 64-core 256 GB1.250
Standard 80-core 384 GB2.000
Standard 104-core 384 GB2.000
Bandwidth aktual bervariasi tergantung tipe mesin. Nilai-nilai ini adalah referensi minimum.

FAQ

Terlalu banyak partisi untuk satu blok INSERT

Error: Too many partitions for single INSERT block (more than 100)

Setiap INSERT membuat part data di berbagai partisi. Ketika satu INSERT menulis ke lebih dari max_partitions_per_insert_block partisi (default: 100), ClickHouse menolak operasi tersebut untuk mencegah degradasi performa selama penggabungan dan kueri.

Perbaiki dengan mengurangi jumlah partisi per INSERT, atau tingkatkan batas jika tidak bisa dihindari:

SET GLOBAL ON CLUSTER DEFAULT max_partitions_per_insert_block = <value>;
Pertahankan nilai ini serendah mungkin. Nilai default 100 adalah rekomendasi komunitas. Kembalikan ke nilai default setelah impor batch selesai.

Koneksi dari tujuan ke kluster yang dikelola sendiri gagal

Kluster yang dikelola sendiri kemungkinan memiliki firewall atau daftar putih yang dikonfigurasi. Tambahkan IPv4 CIDR Block dari ID vSwitch kluster tujuan ke daftar putih kluster yang dikelola sendiri. Untuk instruksi mencari Blok CIDR, lihat bagian Prasyarat.

Tabel non-replikasi dalam kluster multi-replika

Mengapa tabel non-replikasi diblokir: Di kluster multi-replika, alat migrasi memilih satu replika sebagai sumber data. Jika terdapat tabel MergeTree non-replikasi, setiap replika mungkin menyimpan data berbeda — memigrasikan dari satu replika saja menyebabkan kehilangan data.

Contohnya: jika replika r0 menyimpan baris 1, 2, dan 3, sedangkan replika r1 menyimpan baris 4 dan 5, memigrasikan dari r0 akan kehilangan baris 4 dan 5.

image

Solusi:

Jika Anda dapat menghapus tabel non-replikasi tersebut, hapus dari sumber. Jika tidak, ganti dengan tabel ReplicatedMergeTree:

  1. Login ke kluster sumber.

  2. Buat tabel ReplicatedMergeTree dengan skema yang sama seperti tabel non-replikasi (ubah hanya mesinnya).

  3. Migrasikan data dari setiap replika ke tabel Replicated baru. Jalankan perintah berikut di setiap node replika:

    INSERT INTO <destination_database>.<new_replicated_table>
    SELECT *
    FROM remote('<node_IP>:3003', '<source_database>', '<non_replicated_table>', '<username>', '<password>')
    [WHERE _partition_id = '<partition_id>']
    SETTINGS max_execution_time = 0, max_bytes_to_read = 0, log_query_threads = 0;

    Dapatkan alamat IP node dengan SELECT * FROM system.clusters;.

  4. Tukar nama tabel:

    EXCHANGE TABLES <source_database>.<non_replicated_table> AND <destination_database>.<new_replicated_table> ON CLUSTER default;