ApsaraDB for ClickHouse：FAQ

ApsaraDB for ClickHouse terutama memperbaiki bug stabilitas yang ditemukan pada versi komunitas dan menyediakan antrian sumber daya yang memungkinkan Anda mengonfigurasi prioritas penggunaan sumber daya pada tingkat peran pengguna.

Anda dapat menggunakan salah satu solusi berikut:

• Periksa koneksi jaringan. Anda dapat menjalankan perintah ping untuk memeriksa konektivitas jaringan. Anda juga dapat menjalankan perintah telnet untuk memeriksa apakah port database 3306 dan 8123 terbuka.

• Periksa apakah daftar putih telah dikonfigurasi untuk ClickHouse. Untuk informasi lebih lanjut, lihat Konfigurasikan daftar putih.

• Periksa apakah alamat IP client benar. Alamat IP komputer dalam jaringan perusahaan sering berubah, sehingga alamat IP yang ditampilkan mungkin salah. Anda dapat menggunakan layanan pencarian alamat IP profesional untuk menentukan alamat IP asal. Untuk informasi lebih lanjut, lihat whatsmyip.

Versi 20.3 dan 20.8 secara otomatis memverifikasi koneksi saat Anda membuat tabel eksternal. Jika tabel berhasil dibuat, berarti jaringan terhubung. Jika tabel tidak dapat dibuat, penyebab umumnya adalah sebagai berikut:

• Titik akhir tujuan dan kluster ClickHouse tidak berada dalam VPC yang sama, sehingga menyebabkan pemutusan jaringan.

• Titik akhir MySQL memiliki pengaturan daftar putih. Anda harus menambahkan alamat IP kluster ClickHouse ke daftar putih titik akhir MySQL.

Penyebab umum dan solusinya adalah sebagai berikut:

• Penyebab 1: Lingkungan VPC atau jaringan publik tidak dikonfigurasi dengan benar. Anda dapat menggunakan koneksi jaringan internal jika program dan kluster berada dalam VPC yang sama. Jika tidak berada dalam VPC yang sama, Anda harus mengaktifkan Titik akhir publik untuk terhubung.

  Solusi: Untuk informasi lebih lanjut tentang cara mengajukan Titik akhir publik, lihat Ajukan dan lepas Titik akhir publik.

• Penyebab 2: Daftar putih tidak dikonfigurasi untuk kluster.

  Solusi: Untuk informasi lebih lanjut tentang cara mengonfigurasi daftar putih, lihat Konfigurasikan daftar putih.

• Penyebab 3: Port yang diperlukan tidak terbuka di grup keamanan ECS.

  Solusi: Untuk informasi lebih lanjut tentang cara mengonfigurasi grup keamanan, lihat Operasi grup keamanan.

• Penyebab 4: Firewall jaringan perusahaan memblokir koneksi.

  Solusi: Modifikasi aturan firewall.

• Penyebab 5: Kata sandi dalam string koneksi mengandung karakter khusus, seperti !@#$%^&*()_+=. Karakter khusus ini mungkin tidak dikenali selama koneksi dan dapat menyebabkan kegagalan koneksi.

  Solusi: Anda harus melakukan escape karakter khusus dalam string koneksi. Aturan escape-nya adalah sebagai berikut:

  ! : %21
  @ : %40
  # : %23
  $ : %24
  % : %25
  ^ : %5e
  & : %26
  * : %2a
  ( : %28
  ) : %29
  _ : %5f
  + : %2b
  = : %3d

  Contoh: Jika kata sandinya adalah ab@#c, Anda harus melakukan escape karakter khusus dalam string koneksi. Kata sandinya menjadi ab%40%23c.

• Penyebab 6: Secara default, ApsaraDB for ClickHouse memasang instans SLB, yang merupakan layanan bayar sesuai penggunaan. Jika akun Anda memiliki pembayaran tertunda, instans ApsaraDB for ClickHouse Anda mungkin tidak dapat diakses.

  Solusi: Periksa apakah Akun Alibaba Cloud Anda memiliki pembayaran tertunda. Jika iya, segera lunasi saldo yang tertunda.

Anda dapat menggunakan salah satu solusi berikut:

• Pisahkan file di OSS menjadi file-file yang lebih kecil sebelum mengimpornya.

• Tingkatkan memori instans Anda. Untuk informasi lebih lanjut tentang cara meningkatkan memori, lihat Skalabilitas vertikal dan horizontal untuk kluster Edisi Kompatibel-Komunitas.

Penyebab umum dan solusinya adalah sebagai berikut:

• Penyebab 1: Pengaturan parameter tidak tepat. ClickHouse cocok untuk operasi penulisan yang menggunakan batch besar dan proses konkuren sedikit. Dalam kebanyakan kasus, ukuran batch bisa mencapai puluhan ribu atau bahkan ratusan ribu. Ukuran batch tergantung pada ukuran baris Anda. Anda dapat memperkirakan ukuran baris sekitar 100 byte per baris, tetapi Anda perlu menghitungnya berdasarkan karakteristik data aktual Anda.

  Solusi: Kami merekomendasikan jumlah proses konkuren tidak melebihi 10. Anda dapat mencoba menyesuaikan parameter yang berbeda.

• Penyebab 2: Spesifikasi instans ECS dari grup sumber daya eksklusif untuk DataWorks rendah. Misalnya, jika CPU dan memori sumber daya eksklusif terlalu kecil, jumlah proses konkuren dan bandwidth keluar terbatas. Jika ukuran batch terlalu besar dan memori terlalu kecil, garbage collection (GC) Java mungkin dipicu dalam proses DataWorks.

  Solusi: Periksa spesifikasi instans ECS di log output DataWorks.

• Penyebab 3: Data dibaca secara lambat dari sumber data.

  Solusi: Cari `totalWaitReaderTime` dan `totalWaitWriterTime` di log output DataWorks. Jika `totalWaitReaderTime` jauh lebih besar daripada `totalWaitWriterTime`, bottleneck berada di sisi pembacaan, bukan sisi penulisan.

• Penyebab 4: Titik akhir publik digunakan. Bandwidth Titik akhir publik terbatas dan tidak dapat mendukung impor dan ekspor data berkinerja tinggi.

  Solusi: Ganti Titik akhir publik dengan Titik akhir VPC.

• Penyebab 5: Terdapat data kotor. Tanpa data kotor, data ditulis dalam batch. Namun, jika ditemukan data kotor, operasi penulisan batch saat ini gagal dan kembali ke penulisan baris demi baris. Hal ini menghasilkan banyak bagian data dan secara signifikan mengurangi kecepatan penulisan.

  Anda dapat menggunakan salah satu metode berikut untuk memeriksa data kotor:

  • Periksa pesan error. Jika pesan yang dikembalikan berisi Cannot parse, berarti terdapat data kotor.

    Kodenya adalah sebagai berikut:

    SELECT written_rows, written_bytes, query_duration_ms, event_time, exception
    FROM system.query_log
    WHERE event_time BETWEEN '2021-11-22 22:00:00' AND '2021-11-22 23:00:00' AND lowerUTF8(query) LIKE '%insert into <table_name>%' and type != 'QueryStart' and exception_code != 0
    ORDER BY event_time DESC LIMIT 30;

  • Periksa jumlah baris dalam batch. Jika jumlah barisnya 1, berarti terdapat data kotor.

    Kodenya adalah sebagai berikut:

    SELECT written_rows, written_bytes, query_duration_ms, event_time
    FROM system.query_log
    WHERE event_time BETWEEN '2021-11-22 22:00:00' AND '2021-11-22 23:00:00' AND lowerUTF8(query) LIKE '%insert into <table_name>%' and type != 'QueryStart'
    ORDER BY event_time DESC LIMIT 30;

  Solusi: Hapus atau modifikasi data kotor di sumber data.

Anda dapat menggunakan metode berikut untuk memecahkan masalah:

1. Periksa tabel sistem `query_log` untuk melihat apakah terjadi error selama impor. Jika terjadi error, kemungkinan terjadi kehilangan data.

2. Tentukan apakah mesin tabel mendukung deduplikasi. Misalnya, jika Anda menggunakan mesin ReplacingMergeTree, jumlah baris di ClickHouse mungkin lebih kecil daripada di Hive.

3. Konfirmasi ulang keakuratan jumlah baris di Hive. Jumlah baris sumber mungkin telah ditentukan secara salah.

Anda dapat menggunakan metode berikut untuk memecahkan masalah:

1. Periksa tabel sistem `query_log` untuk melihat apakah terjadi error selama impor. Jika terjadi error, kemungkinan terjadi kehilangan data.

2. Tentukan apakah mesin tabel mendukung deduplikasi. Misalnya, jika Anda menggunakan mesin ReplacingMergeTree, jumlah baris di ClickHouse mungkin lebih kecil daripada di Kafka.

3. Periksa apakah parameter `kafka_skip_broken_messages` dikonfigurasi untuk tabel eksternal Kafka. Jika parameter ini ada, pesan Kafka yang gagal diurai mungkin dilewati. Hal ini menyebabkan jumlah total baris di ClickHouse lebih kecil daripada di Kafka.

Anda dapat menggunakan salah satu solusi berikut:

• Migrasikan data dengan mengekspor file menggunakan client ClickHouse. Untuk informasi lebih lanjut, lihat Migrasikan data dari instans ClickHouse yang dikelola sendiri ke instans ApsaraDB for ClickHouse Edisi Kompatibel-Komunitas.

• Migrasikan data menggunakan fungsi `remote`.

  INSERT INTO <destination_table> SELECT * FROM remote('<connection_string>', '<database>', '<table>', '<username>', '<password>');

Solusi: Sinkronkan ulang data MySQL. Untuk melakukannya, ikuti langkah-langkah berikut:

1. Hapus tabel yang berhenti menyinkronkan.

   DROP TABLE <table_name> ON cluster default;

   Catatan

   table_name adalah nama tabel yang berhenti menyinkronkan. Jika tabel memiliki tabel terdistribusi, Anda harus menghapus tabel lokal dan tabel terdistribusi.

2. Mulai ulang proses sinkronisasi.

   ALTER database <database_name> ON cluster default MODIFY SETTING skip_unsupported_tables = 1;

   Catatan

   <database_name> adalah database di ApsaraDB for ClickHouse yang sedang disinkronkan.

Penyebab umum dan solusinya adalah sebagai berikut:

• Penyebab 1: Penggunaan memori tinggi.

  Solusi: Sesuaikan parameter `max_insert_threads` untuk mengurangi potensi penggunaan memori.

• Penyebab 2: Anda menggunakan pernyataan INSERT INTO SELECT untuk mengimpor data dari satu kluster ClickHouse ke kluster lain.

  Solusi: Migrasikan data dengan mengimpor file. Untuk informasi lebih lanjut, lihat Migrasikan data dari instans ClickHouse yang dikelola sendiri ke instans ApsaraDB for ClickHouse Edisi Kompatibel-Komunitas.

Server ClickHouse memiliki pelacak memori untuk setiap thread kueri. Pelacak untuk semua thread dalam kueri yang sama melapor ke `pelacak memori untuk kueri`. Di atasnya terdapat `pelacak memori untuk total`. Anda dapat menggunakan salah satu solusi berikut berdasarkan situasi Anda:

• Jika Anda mengalami error Memory limit (for query), berarti kueri menggunakan terlalu banyak memori (70% dari total memori instans) dan gagal. Dalam hal ini, Anda dapat melakukan peningkatan vertikal untuk meningkatkan memori instans.

• Jika Anda mengalami error Memory limit (for total), berarti total penggunaan memori instans telah melebihi batas (90% dari total memori instans). Dalam hal ini, Anda dapat mencoba mengurangi konkurensi kueri. Jika masalah tetap ada, tugas asinkron latar belakang mungkin menggunakan banyak memori. Hal ini sering terjadi pada tugas penggabungan primary key setelah penulisan. Anda perlu melakukan peningkatan vertikal untuk meningkatkan memori instans.

Konkurensi kueri maksimum default untuk server adalah 100. Anda dapat memodifikasinya di konsol. Untuk memodifikasi nilai parameter yang sedang berjalan, ikuti langkah-langkah berikut:

1. Login ke konsol ApsaraDB for ClickHouse.

2. Pada halaman Cluster List, pilih List of Community Edition Instances, lalu klik ID kluster target.

3. Di panel navigasi sebelah kiri, klik Parameter Configuration.

4. Pada halaman Konfigurasi Parameter, klik tombol edit di sebelah Operating parameter value untuk parameter max_concurrent_queries.

5. Masukkan nilai target di kotak pop-up dan klik Confirm.

6. Klik Submit parameters.

7. Klik Submit parameters.

Anda dapat menggunakan salah satu solusi berikut:

• Periksa apakah ini kluster multi-node. Untuk kluster multi-node, Anda harus membuat tabel terdistribusi, menulis data ke dalamnya, dan mengkuerinya untuk mendapatkan hasil yang konsisten. Jika tidak, setiap kueri mengakses data dari shard yang berbeda, sehingga menghasilkan hasil yang tidak konsisten. Untuk informasi lebih lanjut tentang cara membuat tabel terdistribusi, lihat Buat tabel terdistribusi.

• Periksa apakah ini kluster master-replica. Kluster master-replica memerlukan tabel dengan mesin tabel seri Replicated untuk menyinkronkan data antar replika. Jika tidak, setiap kueri mengakses replika yang berbeda, sehingga menghasilkan hasil yang tidak konsisten. Untuk informasi lebih lanjut tentang cara membuat tabel dengan mesin tabel seri Replicated, lihat Mesin tabel.

Penyebab umum dan solusinya adalah sebagai berikut:

• Penyebab 1: Masalah dalam proses pembuatan tabel. Kluster ClickHouse terdistribusi tidak memiliki semantik DDL terdistribusi native. Jika Anda menggunakan create table untuk membuat tabel di kluster ClickHouse yang dikelola sendiri, kueri mungkin mengembalikan pesan sukses, tetapi tabel hanya dibuat di server tempat Anda saat ini terhubung. Jika Anda terhubung kembali ke server yang berbeda, Anda tidak akan melihat tabel ini.

  Solusi:

  1. Saat membuat tabel, gunakan pernyataan create table <table_name> on cluster default. Deklarasi on cluster default menyiarkan pernyataan ini ke semua node di kluster default untuk dieksekusi. Kode berikut memberikan contoh:

     CREATE TABLE test ON cluster default (a UInt64) Engine = MergeTree() ORDER BY tuple();

  2. Buat mesin tabel terdistribusi pada tabel `test`. Pernyataan pembuatan tabel adalah sebagai berikut:

     CREATE TABLE test_dis ON cluster default AS test Engine = Distributed(default, default, test, cityHash64(a));

• Penyebab 2: Masalah konfigurasi tabel penyimpanan ReplicatedMergeTree. Mesin tabel ReplicatedMergeTree adalah versi yang ditingkatkan dari mesin tabel MergeTree dengan sinkronisasi master-replica. Instans single-replica hanya dapat membuat tabel MergeTree. Instans master-replica hanya dapat membuat tabel ReplicatedMergeTree.

  Solusi: Saat membuat tabel pada instans master-replica, gunakan ReplicatedMergeTree('/clickhouse/tables/{database}/{table}/{shard}', '{replica}') atau ReplicatedMergeTree() untuk mengonfigurasi mesin tabel ReplicatedMergeTree. Konfigurasi ReplicatedMergeTree('/clickhouse/tables/{database}/{table}/{shard}', '{replica}') bersifat tetap dan tidak perlu dimodifikasi.

Untuk memastikan data digabung dengan benar berdasarkan primary key, dua prasyarat berikut harus dipenuhi:

• Bidang `PARTITION BY` yang ditentukan dalam tabel penyimpanan harus disertakan dalam klausa ORDER BY. Data dari partisi yang berbeda tidak digabung berdasarkan primary key.

• Bidang algoritma hash yang ditentukan dalam tabel terdistribusi harus disertakan dalam klausa ORDER BY. Data dari node yang berbeda tidak digabung berdasarkan primary key.

Perintah OPTIMIZE umum dan deskripsinya adalah sebagai berikut:

Penyebab umum dan solusinya adalah sebagai berikut:

• Penyebab 1: Kedaluwarsa data TTL ditangani selama fase penggabungan primary key. Jika bagian data tidak digabung berdasarkan primary key dalam waktu lama, data kedaluwarsa tidak dapat dihapus.

  Solusi:

  • Picu tugas penggabungan secara manual menggunakan OPTIMIZE FINAL atau OPTIMIZE PARTITION.

  • Atur parameter seperti `merge_with_ttl_timeout` dan `ttl_only_drop_parts` saat membuat tabel untuk meningkatkan frekuensi penggabungan bagian data yang berisi data kedaluwarsa.

• Penyebab 2: TTL tabel telah dimodifikasi atau ditambahkan, dan bagian data yang ada tidak memiliki informasi TTL atau memiliki informasi yang salah. Hal ini juga dapat mencegah penghapusan data kedaluwarsa.

  Solusi:

  • Buat ulang informasi TTL menggunakan perintah ALTER TABLE ... MATERIALIZE TTL.

  • Perbarui informasi TTL menggunakan OPTIMIZE PARTITION.

Modifikasi pada tabel lokal dapat dijalankan langsung. Untuk memodifikasi tabel terdistribusi, prosedurnya bervariasi tergantung situasi:

• Jika tidak ada data yang ditulis, Anda dapat memodifikasi tabel lokal terlebih dahulu, lalu memodifikasi tabel terdistribusi.

• Jika data sedang ditulis, Anda harus menangani berbagai jenis operasi secara berbeda:

  Jenis	Prosedur
  Tambahkan kolom `Nullable`	Modifikasi tabel lokal. Modifikasi tabel terdistribusi.
  Modifikasi tipe data kolom (jika tipe dapat dikonversi)
  Hapus kolom `Nullable`	Modifikasi tabel terdistribusi. Modifikasi tabel lokal.
  Tambahkan kolom non-`Nullable`	Hentikan penulisan data. Jalankan `SYSTEM FLUSH DISTRIBUTED` pada tabel terdistribusi. Modifikasi tabel lokal. Modifikasi tabel terdistribusi. Lanjutkan penulisan data.
  Hapus kolom non-`Nullable`
  Modifikasi nama kolom

Anda dapat menggunakan salah satu solusi berikut:

• Tunggu hingga operasi selesai.

• Coba hentikan kueri di konsol.

Penyebab umum dan solusinya adalah sebagai berikut:

• Penyebab 1: Client ClickHouse mengurai sintaksis, dan set global on cluster default adalah sintaksis yang ditambahkan oleh server. Jika client belum diperbarui ke versi yang selaras dengan server, sintaksis ini diblokir oleh client.

  Solusi:

  • Gunakan alat yang tidak mengurai sintaksis di sisi client, seperti driver JDBC, DataGrip, atau DBeaver.

  • Tulis program JDBC untuk menjalankan pernyataan tersebut.

• Penyebab 2: Dalam set global on cluster default key = value;, `value` adalah string, tetapi tanda kutipnya hilang.

  Solusi: Tambahkan tanda kutip di kedua sisi nilai bertipe string.

Anda dapat menggunakan kode berikut untuk melihat ruang disk yang digunakan oleh masing-masing tabel:

SELECT table, formatReadableSize(sum(bytes)) as size, min(min_date) as min_date, max(max_date) as max_date FROM system.parts WHERE active GROUP BY table; 

Berikut adalah kode contoh:

SELECT * FROM system.disks;

Berikut adalah kode contoh:

SELECT * FROM system.parts WHERE disk_name = 'cold_disk';

Berikut adalah kode contoh:

ALTER TABLE table_name MOVE PARTITION partition_expr TO DISK 'cold_disk';

Penyebab umumnya adalah sebagai berikut:

• Kueri memicu error OOM.

• Perubahan konfigurasi memicu restart.

• Instans di-restart setelah peningkatan atau penurunan.

Tabel sistem umum dan fungsinya adalah sebagai berikut:

Parameter tingkat pengguna sesuai dengan beberapa item konfigurasi dalam file `users.xml`. Anda dapat menjalankan pernyataan contoh berikut:

SET global ON cluster default ${key}=${value};

Anda dapat menambahkannya ke pengaturan saat menjalankan pernyataan. Berikut adalah kode contoh:

settings max_memory_usage = XXX;

Jika kluster Anda adalah kluster master-replica atau kluster multi-node single-replica, penggunaan CPU dan memori node penulisan akan lebih tinggi daripada node lain saat Anda melakukan banyak operasi penulisan. Setelah data disinkronkan ke node lain, penggunaan CPU dan memori akan seimbang.

• Deskripsi masalah:

  Bagaimana cara melihat informasi log sistem detail untuk memecahkan error atau mengidentifikasi potensi masalah.

• Solusi:

  1. Periksa parameter `text_log.level` kluster dan lakukan operasi berikut:

     1. Jika `text_log.level` kosong, `text_log` tidak diaktifkan. Anda dapat mengatur `text_log.level` untuk mengaktifkan `text_log`.

     2. Jika `text_log.level` tidak kosong, periksa apakah level `text_log` memenuhi kebutuhan Anda saat ini. Jika tidak, Anda dapat memodifikasi parameter ini untuk mengatur level `text_log`.

     Untuk informasi lebih lanjut tentang cara melihat dan memodifikasi parameter `text_log.level`, lihat Konfigurasikan parameter config.xml.

  2. Login ke database tujuan. Untuk informasi lebih lanjut, lihat Hubungkan ke database.

  3. Jalankan pernyataan berikut untuk analisis:

     SELECT * FROM system.text_log;

Jika kluster target dan sumber data menggunakan VPC yang sama dan berada dalam wilayah yang sama, periksa apakah keduanya telah menambahkan alamat IP satu sama lain ke daftar putih mereka. Jika belum, tambahkan alamat IP tersebut ke daftar putih.

• Untuk informasi lebih lanjut tentang cara menambahkan alamat IP ke daftar putih di ClickHouse, lihat Konfigurasikan daftar putih.

• Untuk informasi lebih lanjut tentang cara menambahkan alamat IP ke daftar putih untuk sumber data lain, lihat dokumentasi produk terkait.

Jika kluster target dan sumber data tidak memenuhi kondisi di atas, Anda dapat memilih solusi jaringan yang sesuai untuk menangani masalah jaringan. Kemudian, tambahkan alamat IP satu sama lain ke daftar putih.

Ya, Anda dapat memigrasikan kluster ApsaraDB for ClickHouse Edisi Kompatibel-Komunitas ke kluster Edisi Perusahaan.

Ada dua metode utama untuk memigrasikan data antara kluster Edisi Perusahaan dan Edisi Kompatibel-Komunitas: menggunakan fungsi `remote` atau menggunakan ekspor dan impor file. Untuk informasi lebih lanjut, lihat Migrasikan data dari instans ClickHouse yang dikelola sendiri ke instans ApsaraDB for ClickHouse Edisi Kompatibel-Komunitas.

Instans Edisi Perusahaan baru versi 24.5 atau lebih baru menggunakan analyzer baru sebagai mesin kueri default. Analyzer baru menawarkan kinerja kueri yang lebih baik tetapi mungkin tidak kompatibel dengan beberapa sintaksis SQL lama, yang dapat menyebabkan error penguraian. Jika Anda mengalami error ini, Anda dapat menjalankan pernyataan berikut untuk kembali ke analyzer lama. Untuk informasi lebih lanjut tentang analyzer baru, lihat Analyzer baru diaktifkan secara default.

SET allow_experimental_analyzer = 0;

Fitur jeda tidak didukung untuk kluster Edisi Komunitas ClickHouse, tetapi tersedia untuk kluster Edisi Perusahaan. Untuk menjeda kluster Edisi Perusahaan, buka halaman daftar kluster Edisi Perusahaan. Di pojok kiri atas, pilih wilayah tujuan, temukan kluster target, lalu klik >Jeda di kolom Actions kluster target.