ApsaraDB for ClickHouse：Skala kluster ApsaraDB for ClickHouse

Constraints

• Perubahan spesifikasi ZooKeeper hanya didukung untuk kluster yang dibuat setelah 1 Desember 2021. Untuk informasi harga, lihat Pricing for ZooKeeper specifications of the Community-Compatible Edition.

• Upgrade kapasitas penyimpanan atau tipe penyimpanan tidak merestart kluster (berlaku hanya untuk kluster yang dibuat setelah 1 Desember 2021). Mengubah spesifikasi kluster atau spesifikasi ZooKeeper akan merestart kluster.

• Server Specifications atau ZooKeeper Specifications tidak dapat diubah secara bersamaan dengan Upgrade Storage Capacity atau Storage Type.

• Mengubah spesifikasi ZooKeeper selama jam sibuk dapat menyebabkan ketidakkonsistenan antara metadata tabel dan data aktual. Lakukan perubahan ini selama jam sepi atau saat operasi write dihentikan.

Impact by cluster type

Procedure

1. Login ke ApsaraDB for ClickHouse console.

2. Di pojok kiri atas, pilih wilayah tempat kluster Anda berada.

3. Pada halaman Clusters, klik tab Clusters of Community-compatible Edition.

4. Temukan kluster target. Di kolom Actions, klik Change.

5. Pada kotak dialog Change, pilih Scale Up atau Scale Down, lalu klik OK.

6. Pada halaman Upgrade/Downgrade, pilih konfigurasi yang diinginkan. Secara default, kluster memiliki layanan ZooKeeper dengan 4 core dan 8 GB memori. Untuk memeriksa bottleneck sumber daya, buka halaman Monitoring and Alerting dan lihat metrik ZooKeeper di panel Cluster Monitoring. Upgrade spesifikasi ZooKeeper jika nilai default tidak mencukupi.

7. Klik Buy Now dan selesaikan pembayaran.

8. Pada halaman The order is complete, klik Console.

9. Periksa status kluster di kolom Status pada daftar Clusters of Community-compatible Edition.

   • Perubahan Storage Capacity berlaku langsung. Status kluster tetap Running.

   • Perubahan Server Specifications atau ZooKeeper Specifications memerlukan waktu 10 hingga 15 menit. Status berubah dari Changing Specification menjadi Running saat operasi selesai.

Post-scaling behavior

Setelah mengubah spesifikasi kluster atau ZooKeeper, kluster akan restart. Durasi restart tergantung pada jumlah database, tabel, dan volume cold data. Operasi merge frekuensi tinggi mungkin berjalan selama periode tertentu setelah perubahan, meningkatkan penggunaan I/O dan berpotensi meningkatkan latency permintaan. Untuk informasi tentang perkiraan durasi merge, lihat Calculate the merge duration after migration.

Scale-out methods

Scale-in methods

Migration scope

Selama scale-out dengan migrasi data atau standard scale-in, data berikut dimigrasikan ke konfigurasi kluster baru.

Didukung:

• Database, dictionary, dan materialized view

• Skema tabel untuk semua tabel kecuali tabel engine Kafka dan RabbitMQ

• Data dari tabel keluarga engine MergeTree (migrasi inkremental)

Tidak didukung:

• Tabel engine Kafka dan RabbitMQ beserta datanya

• Data dari tabel non-MergeTree (seperti tabel eksternal dan tabel engine keluarga Log)

Constraints

• Operasi DDL dilarang selama seluruh proses scale-out atau scale-in.

• Penggunaan CPU dan memori meningkat selama operasi. Estimasi overhead: kurang dari 5 core dan 20 GB memori per node.

• Setelah penskalaan, operasi merge frekuensi tinggi berlanjut selama periode tertentu, meningkatkan penggunaan I/O dan berpotensi meningkatkan latency permintaan. Untuk informasi tentang perkiraan durasi merge, lihat Calculate the merge duration after migration.

• Setelah scale out, alamat IP internal node kluster berubah. Jika aplikasi Anda terhubung ke alamat IP node tertentu, ambil kembali blok CIDR VPC. Untuk detailnya, lihat Obtain the VPC CIDR block of a cluster.

Step 1: Handle Kafka and RabbitMQ engine tables

Lewati langkah ini jika kluster Anda tidak memiliki tabel engine Kafka atau RabbitMQ.

1. Login ke kluster. Untuk petunjuk koneksi, lihat Connect to a ClickHouse cluster using DMS.

2. Cari tabel engine Kafka dan RabbitMQ:

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

3. Backup pernyataan CREATE TABLE untuk setiap tabel:

      SHOW CREATE TABLE <table_name>;

4. Hapus tabel engine Kafka dan RabbitMQ. > Important: Saat menghapus tabel Kafka, hapus juga materialized view yang mereferensinya. Jika tidak, operasi scale-out atau scale-in akan gagal.

Step 2: Back up data from non-MergeTree tables

Lewati langkah ini jika kluster Anda tidak memiliki tabel non-MergeTree yang datanya perlu dipertahankan.

1. Identifikasi tabel non-MergeTree yang datanya perlu dimigrasikan:

      SELECT
          `database` AS database_name,
          `name` AS table_name,
          `engine`
      FROM `system`.`tables`
      WHERE (`engine` NOT LIKE '%MergeTree%')
        AND (`engine` != 'Distributed')
        AND (`engine` != 'MaterializedView')
        AND (`engine` NOT IN ('Kafka', 'RabbitMQ'))
        AND (`database` NOT IN ('system', 'INFORMATION_SCHEMA', 'information_schema'))
        AND (`database` NOT IN (
            SELECT `name`
            FROM `system`.`databases`
            WHERE `engine` IN ('MySQL', 'MaterializedMySQL', 'MaterializeMySQL',
                               'Lazy', 'PostgreSQL', 'MaterializedPostgreSQL', 'SQLite')
        ))

2. Backup data dari tabel yang diidentifikasi. Untuk petunjuknya, lihat Back up data to OSS.

Step 3: Scale out or scale in from the console

1. Login ke ApsaraDB for ClickHouse console.

2. Di pojok kiri atas, pilih wilayah tempat kluster Anda berada.

3. Pada halaman Clusters, pilih tab Clusters of Community-compatible Edition.

4. Temukan kluster target. Di kolom Actions, klik Change.

5. Pada kotak dialog Change, pilih Scale Out atau Scale In, lalu klik OK.

6. Pada jendela pemeriksaan, tinjau status pemeriksaan. Jendela Scale Out secara default memilih Migration Expansion. Untuk menggunakan Simple Expansion, klik Previous, pilih Simple Expansion di kotak dialog Scale-out, lalu klik Next. Penyebab umum kegagalan pemeriksaan:

   • Jika pemeriksaan lolos, klik Next.

   • Jika pemeriksaan gagal, perbaiki masalah yang dilaporkan dan klik Retry Check. Klik Next setelah pemeriksaan lolos.

   Failure	Resolution
   Missing unique distributed table	Tabel lokal tidak memiliki tabel terdistribusi yang sesuai. Buat satu.
   Corresponding distributed table is not unique	Tabel lokal memiliki lebih dari satu tabel terdistribusi. Pertahankan hanya satu.
   Kafka/RabbitMQ engine tables exist	Hapus tabel-tabel ini terlebih dahulu (lihat Langkah 1).
   Non-replicated *MergeTree tables in a master-replica instance	Data tidak konsisten antar replica. Selesaikan ketidakkonsistenan tersebut.
   Distributed and local table columns are inconsistent	Selaraskan definisi kolom.
   Table is missing on some nodes	Buat tabel yang sesuai di semua shard. Untuk tabel dalam materialized view, ganti nama tabel dalam tersebut dan bangun ulang materialized view. Untuk detailnya, lihat The inner table of a materialized view is inconsistent across shards.

7. Pada halaman Upgrade/Downgrade, konfigurasikan jumlah Server Nodes dan jendela penangguhan write. Persyaratan jendela penangguhan write:

   • Atur waktu penangguhan write minimal 30 menit.

   • Operasi harus selesai dalam 5 hari. Tanggal akhir Stopping Data Writing untuk kluster sumber tidak boleh lebih dari tanggal saat ini ditambah 5 hari.

   • Atur jendela penangguhan write selama jam sepi untuk mengurangi dampak bisnis.

8. Klik Buy Now dan selesaikan pembayaran.

9. Pada halaman The order is complete, klik Console.

10. Periksa status kluster di kolom Status pada daftar Clusters of Community-compatible Edition. Operasi selesai saat status berubah dari Scaling menjadi Running. Operasi scale-out atau scale-in memerlukan waktu minimal 30 menit. Durasi tepatnya tergantung pada volume data.

Step 4: Recreate Kafka and RabbitMQ engine tables

Lewati langkah ini jika Anda tidak menghapus tabel engine Kafka atau RabbitMQ di Langkah 1.

Login ke kluster dan jalankan pernyataan CREATE TABLE yang telah Anda backup di Langkah 1. Untuk petunjuk koneksi, lihat Connect to a ClickHouse cluster using DMS.

Step 5: Restore data to non-MergeTree tables

Lewati langkah ini jika Anda tidak melakukan backup data tabel non-MergeTree di Langkah 2.

Login ke kluster dan impor data yang telah Anda backup di Langkah 2. Untuk petunjuknya, lihat Import data from OSS.

Post-scaling behavior

• Merge operations: Operasi merge frekuensi tinggi berlanjut selama periode tertentu setelah operasi, meningkatkan penggunaan I/O dan berpotensi meningkatkan latency permintaan. Untuk informasi tentang perkiraan durasi merge, lihat Calculate the merge duration after migration.

• IP addresses: Setelah scale out, alamat IP internal node kluster berubah. Perbarui konfigurasi aplikasi Anda jika terhubung ke IP node tertentu. Untuk detailnya, lihat Obtain the VPC CIDR block of a cluster.

• Verify data: Setelah operasi selesai dan status kluster kembali ke Running, verifikasi bahwa data dan tabel Anda utuh.