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
| Metode | Kelebihan | Kekurangan | Gunakan saat |
|---|---|---|---|
| Console migration | Antarmuka 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 manual | Kontrol 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.
Untuk melihat alamat IP node:
SELECT * FROM system.clusters;Untuk mendapatkan ID vSwitch: buka halaman Cluster Information kluster tujuan dan temukan bagian Network Information di konsol ApsaraDB for ClickHouse
Untuk melihat Blok CIDR IPv4: cari berdasarkan ID vSwitch di daftar vSwitch
Untuk mengonfigurasi daftar putih: lihat Konfigurasi daftar putih alamat IP
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.
Buat tugas migrasi menggunakan langkah-langkah di bagian Migrasi melalui konsol atau Migrasi manual.
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 data | Batas | Perilaku jika melebihi |
|---|---|---|
| Data dingin | Total disarankan ≤ 1 TB | Migrasi lambat; risiko tinggi kegagalan tugas |
| Data panas | ≤ 10 TB | Kemungkinan 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)
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.
Periksa versi kedua kluster:
SELECT version();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
Login ke konsol ApsaraDB for ClickHouse.
Pada halaman Clusters, pilih Clusters of Community-compatible Edition dan klik ID kluster tujuan.
Di panel navigasi kiri, klik Data Migration and Synchronization > Migrate from ClickHouse.
Klik Create Migration Task.
Konfigurasikan pengaturan koneksi kluster sumber: Untuk mendapatkan alamat IP dan port kluster sumber:
replica_num = 1memilih 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:
Field Deskripsi Contoh Source Access Method Pilih Express Connect, VPN Gateway, Smart Access Gateway, or Self-managed ClickHouse Clusters on an ECS Instance. — Cluster Name Nama untuk kluster sumber. Hanya angka dan huruf kecil. sourceSource Cluster Name Nama kluster internal dari SELECT * FROM system.clusters;.defaultVPC IP Address Pasangan 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:9000Database Account Akun untuk kluster sumber. testDatabase Password Kata sandi untuk akun kluster sumber. — Parameter kluster tujuan
Pengaturan kluster tujuan:
Field Deskripsi Database Account Akun untuk kluster tujuan. Database Password Kata sandi untuk akun kluster tujuan. 
Klik Test Connection and Proceed. Jika pengujian gagal, perbaiki pengaturan koneksi dan coba lagi.
Tinjau konten migrasi dan klik Next: Pre-detect and Start Synchronization.
Sistem menjalankan tiga pemeriksaan awal. Jika semua pemeriksaan lolos: Jika pemeriksaan gagal, ikuti panduan penanganan error di Pesan error pra-periksa dan solusinya.
Baca prompt dampak dengan cermat.
Klik Completed untuk membuat dan memulai tugas.
Item Pemeriksaan Persyaratan Instance Status Detection Tidak ada tugas manajemen yang sedang berjalan (scale-out, upgrade, atau downgrade) pada kedua kluster. Storage Space Detection Ruang penyimpanan kluster tujuan ≥ 1,2× ruang yang digunakan oleh kluster self-managed. Local Table and Distributed Table Detection Setiap tabel lokal di kluster self-managed harus memiliki tepat satu tabel terdistribusi yang sesuai. 
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:
Lihat metrik Disk throughput pada kluster tujuan. Lihat Lihat informasi pemantauan kluster.
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
Login ke konsol ApsaraDB for ClickHouse.
Pada halaman Clusters, pilih Clusters of Community-compatible Edition dan klik ID kluster tujuan.
Di panel navigasi kiri, klik Data Migration and Synchronization > Migrate from ClickHouse.
Pantau status tugas dan kolom Running Information.
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:
| Status | Deskripsi |
|---|---|
| Running | Menyiapkan lingkungan dan resource. |
| Initialization | Menginisialisasi tugas migrasi. |
| Configuration Migration | Memigrasikan konfigurasi kluster. |
| Schema Migration | Memigrasikan database, tabel keluarga MergeTree, dan tabel terdistribusi. |
| Data Migration | Memigrasikan data secara inkremental dari tabel keluarga MergeTree. |
| Other Schema Migration | Memigrasikan materialized view dan skema tabel non-MergeTree. |
| Data Check | Memverifikasi bahwa volume data di tujuan sesuai dengan kluster yang dikelola sendiri. |
| Post-configuration | Membersihkan lingkungan migrasi dan mengaktifkan kembali penulisan ke kluster sumber. |
| Completed | Migrasi selesai. |
| Canceled | Migrasi 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.
Di kluster yang dikelola sendiri, identifikasi tabel yang perlu diproses:
SELECT * FROM system.tables WHERE engine IN ('RabbitMQ', 'Kafka');Dapatkan DDL untuk setiap tabel:
SHOW CREATE TABLE <target_table_name>;Di kluster tujuan, jalankan pernyataan DDL untuk membuat tabel tersebut. Lihat Hubungkan ke kluster ClickHouse menggunakan DMS untuk instruksi koneksi.
Di kluster yang dikelola sendiri, hapus tabel Kafka dan RabbitMQ.
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.
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.
Login ke konsol ApsaraDB for ClickHouse.
Pada halaman Clusters, pilih Clusters of Community-compatible Edition dan klik ID kluster tujuan.
Di panel navigasi kiri, klik Data Migration and Synchronization > Migrate from ClickHouse.
Di kolom Actions untuk tugas tersebut, klik Complete Migration.
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.
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') ))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.
| Operasi | Fungsinya | Dampak | Gunakan saat |
|---|---|---|---|
| Stop Migration | Menghentikan 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 Migration | Membatalkan 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:
Login ke konsol ApsaraDB for ClickHouse.
Pada halaman Clusters, pilih Clusters of Community-compatible Edition dan klik ID kluster tujuan.
Di panel navigasi kiri, klik Data Migration and Synchronization > Migrate from ClickHouse.
Di kolom Actions, klik Stop Migration dan konfirmasi.
Batalkan migrasi
Batalkan migrasi:
Login ke konsol ApsaraDB for ClickHouse.
Pada halaman Clusters, pilih Clusters of Community-compatible Edition dan klik ID kluster tujuan.
Di panel navigasi kiri, klik Data Migration and Synchronization > Migrate from ClickHouse.
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.
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.listDatabase
systemtidak perlu dimigrasikan.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.listAtau kueri semua database dan tabel sekaligus:
SELECT DISTINCT database, name FROM system.tables WHERE database != 'system';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.sqlBuat database target di kluster tujuan, lalu impor DDL-nya:
Parameter Deskripsi <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:
(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';Migrasikan data tabel per tabel, opsional dengan filter partisi:
Untuk versi 20.8, coba gunakan
remoteRawterlebih 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;``PentingSelalu gunakan titik akhir internal VPC, bukan titik akhir publik.
Parameter:
Parameter Deskripsi <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.
PentingPort 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 sumber Format Contoh ClickHouse yang dikelola sendiri IP:Port TCP192.168.0.5:9000ApsaraDB for ClickHouse Edisi Community-Compatible VPC_internal_address:3306cc-2zeqhh5v7y6q*****.clickhouse.ads.aliyuncs.com:3306ApsaraDB for ClickHouse Enterprise VPC_internal_address:9000cc-bp1anv7jo84ta*****clickhouse.clickhouseserver.rds.aliyuncs.com:9000INSERT 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.csvImpor 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.csvOpsi 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 error | Penyebab | Solusi |
|---|---|---|
| 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:
| Nilai | Cara mendapatkan |
|---|---|
| Data panas per node | Disk Usage - Single-Node Statistics di Lihat informasi pemantauan kluster. |
| Data dingin | Cold storage usage di Lihat informasi pemantauan kluster. |
| Jumlah node | SELECT count() FROM system.clusters WHERE cluster = 'default' AND replica_num = 1; |
| n (disk per node) | SELECT count() FROM system.disks WHERE type = 'local'; |
| bandwidth disk | Throughput maksimum per disk (MB/detik) di tabel tingkat performa ESSD. |
| Bandwidth baca OSS | Total Bandwidth Unduh Intranet dan Internet di tabel bandwidth OSS. |
| Bandwidth tulis OSS | Total Bandwidth Unggah Intranet dan Internet di tabel bandwidth OSS. |
Instance type bandwidth reference (nilai minimum):
| Spesifikasi | Bandwidth (MB/s) |
|---|---|
| Standard 8-core 32 GB | 250 |
| Standard 16-core 64 GB | 375 |
| Standard 24-core 96 GB | 500 |
| Standard 32-core 128 GB | 625 |
| Standard 64-core 256 GB | 1.250 |
| Standard 80-core 384 GB | 2.000 |
| Standard 104-core 384 GB | 2.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.
Solusi:
Jika Anda dapat menghapus tabel non-replikasi tersebut, hapus dari sumber. Jika tidak, ganti dengan tabel ReplicatedMergeTree:
Login ke kluster sumber.
Buat tabel ReplicatedMergeTree dengan skema yang sama seperti tabel non-replikasi (ubah hanya mesinnya).
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;.Tukar nama tabel:
EXCHANGE TABLES <source_database>.<non_replicated_table> AND <destination_database>.<new_replicated_table> ON CLUSTER default;