全部产品
Search

搜索本产品

    Hologres：Replikasi level shard untuk instance Hologres

    文档中心

    Hologres：Replikasi level shard untuk instance Hologres

    更新时间：Jul 12, 2025

    Topik ini menjelaskan cara menggunakan fitur replikasi tingkat shard di Hologres.

    Ikhtisar

    Mulai dari Hologres V1.1, Anda dapat menentukan jumlah replika setiap shard dalam grup tabel untuk meningkatkan konkurensi dan ketersediaan query pada grup tabel tersebut. Untuk mengaktifkan fitur replikasi tingkat shard, tentukan jumlah replika saat membuat grup tabel atau modifikasi jumlah replika untuk grup tabel yang sudah ada. Replika baru adalah replika runtime yang menggunakan memori tanpa meningkatkan biaya penyimpanan.

    Jika ingin menentukan atau memodifikasi jumlah replika setiap shard, perhatikan hal-hal berikut:

    • Data pada instance Hologres didistribusikan berdasarkan shard. Setiap shard mengelola data yang berbeda, dan tidak ada duplikasi antara shard. Data di semua shard membentuk satu set data lengkap.

    • Secara default, setiap shard hanya memiliki satu replika. Dalam kasus ini, nilai parameter replica_count adalah 1. Replika ini berfungsi sebagai shard pemimpin (leader). Anda dapat memodifikasi parameter replica_count untuk menambah jumlah replika untuk setiap shard. Replika shard selain shard pemimpin berfungsi sebagai shard pengikut (follower).

    • Shard pemimpin bertanggung jawab atas semua permintaan tulis. Permintaan baca didistribusikan secara merata di antara shard pemimpin dan shard pengikut. Jika sebuah query dirutekan ke shard pengikut, query tersebut mungkin memiliki latensi 10 hingga 20 ms.

    • Nilai default parameter replica_count adalah 1, yang menonaktifkan fitur replikasi tingkat shard. Nilai lebih besar dari 1 mengaktifkan fitur ini, tetapi memerlukan lebih banyak sumber daya. Hanya satu replika yang dapat ditempatkan pada satu node komputasi karena fitur anti-afinitas. Nilai parameter replica_count harus kurang dari atau sama dengan jumlah node komputasi. Di Hologres V1.3.53 dan versi lebih baru, nilai maksimum parameter replica_count adalah jumlah node pekerja. Jika batas dilampaui, pesan kesalahan akan dilaporkan. Untuk informasi lebih lanjut tentang jumlah node komputasi untuk spesifikasi instance yang berbeda, lihat Manajemen Instance.

    • Untuk menyeimbangkan kemampuan komputasi node komputasi, Anda harus mengurangi jumlah shard saat Anda menambah jumlah replika untuk setiap shard. Untuk mencapai performa optimal, pastikan persamaan berikut terpenuhi: Nilai parameter shard_count × Nilai parameter replica_count = Jumlah shard yang direkomendasikan untuk instance Anda.

    • Hologres V1.3.45 dan versi lebih baru mendukung query dalam mode high-availability.

    • Masalah pemanfaatan CPU yang ditunjukkan pada gambar berikut mungkin terjadi pada instance Hologres Anda. Anda dapat melihat informasi pemanfaatan CPU instance Hologres Anda di halaman informasi pemantauan konsol Hologres.实例资源

      worker资源

      Gambar sebelumnya menunjukkan bahwa pemanfaatan CPU instance berada pada level sedang, tetapi pemanfaatan CPU salah satu node pekerja sangat rendah dan pemanfaatan CPU node pekerja lainnya sangat tinggi. Hal ini mungkin disebabkan oleh distribusi query yang tidak merata pada node pekerja. Sebagian besar query hanya dirutekan ke beberapa shard. Dalam kasus ini, Anda dapat menambah jumlah replika shard untuk memungkinkan lebih banyak node pekerja memiliki replika shard. Ini dapat secara efektif meningkatkan penggunaan sumber daya dan queries per second (QPS).

      Catatan

      • Sinkronisasi metadata antara shard pemimpin dan shard pengikut mengonsumsi sumber daya. Sejumlah besar replika shard mengonsumsi sejumlah besar sumber daya untuk sinkronisasi data. Kami merekomendasikan Anda meningkatkan QPS dengan menambah jumlah replika shard hanya jika pemanfaatan CPU yang tidak merata antara node pekerja disebabkan oleh distribusi query yang tidak merata.

      • Query data pada shard pemimpin atau shard pengikut memiliki latensi level milidetik.

      Setelah Anda menambah jumlah replika shard, sumber daya setiap node pekerja sepenuhnya dimanfaatkan, seperti yang ditunjukkan pada gambar berikut.worker资源平衡

    Batasan

    • Fitur replikasi tingkat shard hanya didukung mulai Hologres V1.1.

      Catatan

      Anda dapat memeriksa versi instance Hologres Anda di halaman detail instance di konsol Hologres. Jika versi instance Hologres Anda adalah V0.10 atau lebih lama, Anda dapat secara manual meningkatkan instance Anda atau bergabung dengan grup DingTalk Hologres untuk meminta insinyur meningkatkan instance Anda. Untuk informasi lebih lanjut, lihat bagian "Peningkatan Manual" di Peningkatan Instance dan Dapatkan dukungan online untuk Hologres.

    • Nilai parameter replica_count harus kurang dari atau sama dengan jumlah node komputasi. Anda dapat memeriksa jumlah node komputasi pada instance Hologres Anda di halaman detail instance konsol Hologres.

    Sintaksis

    • Query grup tabel dalam database

      Untuk menanyakan grup tabel dalam database saat ini, jalankan pernyataan berikut:

      select * from hologres.hg_table_group_properties ;

    • Query jumlah replika setiap shard untuk grup tabel

      • Pernyataan contoh

        select property_value from hologres.hg_table_group_properties where tablegroup_name = 'table_group_name' and property_key = 'replica_count';

      • Parameter

        Parameter

        Deskripsi

        table_group_name

        Nama grup tabel yang ingin Anda tanyakan.

        replica_count

        Properti yang ingin Anda tanyakan. Atur nilainya menjadi replica_count.

    • Aktifkan fitur replikasi tingkat shard

      • Pernyataan contoh

        Anda dapat mengaktifkan fitur replikasi tingkat shard dengan memodifikasi jumlah replika setiap shard untuk grup tabel.

        -- Modifikasi jumlah replika setiap shard untuk grup tabel.
call hg_set_table_group_property ('<table_group_name>', 'replica_count', '<replica_count>');

      • Parameter

        Parameter

        Deskripsi

        hg_set_table_group_property

        Modifikasi parameter replica_count grup tabel.

        • nama_grup_tabel: Masukkan nama grup tabel yang ingin Anda modifikasi.

        • replica_count: Jumlah replika untuk grup tabel. Nilai ini harus kurang dari atau sama dengan jumlah node komputasi, dan biasanya diatur ke 2.

        • Apakah akan mengaktifkan replikasi: Nilai default adalah 1, yang menunjukkan bahwa replikasi tidak diaktifkan. Nilai lebih besar dari 1 menunjukkan bahwa replikasi diaktifkan.

    • Nonaktifkan fitur replikasi tingkat shard

      • Pernyataan contoh

        -- Modifikasi parameter replica_count untuk menonaktifkan fitur replikasi tingkat shard.
call hg_set_table_group_property ('table_group_name', 'replica_count', '1');

      • Parameter

        Parameter

        Deskripsi

        hg_set_table_group_property

        Fungsi yang digunakan untuk memodifikasi jumlah replika setiap shard untuk grup tabel.

        • table_group_name: nama grup tabel yang ingin Anda kelola.

        • replica_count: jumlah replika setiap shard untuk grup tabel.

        • Jika Anda mengatur parameter replica_count ke nilai default 1, fitur replikasi tingkat shard dinonaktifkan. Nilai lebih besar dari 1 menentukan bahwa fitur replikasi tingkat shard diaktifkan.

    • Periksa metadata shard yang dimuat ke setiap node pekerja

      Setelah Anda mengonfigurasi beberapa replika untuk setiap shard, Anda dapat memeriksa metadata shard yang dimuat ke setiap node pekerja dengan menjalankan pernyataan SQL berikut:

      SELECT * FROM hologres.hg_worker_info;
      Catatan

      Sebelum metadata shard dimuat ke node pekerja, nilai parameter worker_id untuk node pekerja ini mungkin kosong.

      Gambar berikut menunjukkan hasil yang dikembalikan.

      查看加载情况

      Dalam contoh ini, data dalam tabel grup tabel olap_replica_2 didistribusikan ke dua shard bernama Shard 0 dan Shard 1. Metadata Shard 0 dan Shard 1 dimuat ke 7tn8k dan 9c8sl node pekerja.

    Konfigurasikan kebijakan shard untuk mencapai ketersediaan tinggi dan throughput tinggi query

    Deskripsi

    • Dalam contoh ini, beberapa replika dikonfigurasikan untuk shard. Replika shard dimuat ke beberapa node pekerja. Query dirutekan secara acak ke replika shard pada node pekerja, seperti yang ditunjukkan pada gambar berikut.image

    • Jika query titik waktu habis, sistem dapat merutekan query titik ke replika shard node pekerja lain. Ini memastikan bahwa hasil dikembalikan untuk query titik. Query titik diproses menggunakan rencana tetap.

    Parameter

    • hg_experimental_query_replica_mode: kebijakan shard yang digunakan untuk merutekan query.

      Skenario

      Nilai default

      Tipe nilai

      Nilai valid

      Contoh

      Semua query

      leader_follower

      TEXT

      • leader_follower: Query dirutekan ke shard pemimpin dan shard pengikut berdasarkan rasio tertentu. Ini adalah nilai default.

      • leader_only: Query hanya dirutekan ke shard pemimpin. Dalam kasus ini, bahkan jika nilai parameter replica_count lebih besar dari 1, throughput dan ketersediaan tidak dapat ditingkatkan.

      • follower_only: Query hanya dirutekan ke shard pengikut. Dalam kasus ini, Anda harus mengatur parameter replica_count ke nilai lebih besar dari 3. Dengan cara ini, dua atau lebih shard pengikut ada, dan throughput serta ketersediaan dapat ditingkatkan. 

      -- Konfigurasi level sesi
SET hg_experimental_query_replica_mode = leader_follower;

-- Konfigurasi level database
ALTER DATABASE <database_name> 
SET hg_experimental_query_replica_mode = leader_follower;

    • hg_experimental_query_replica_leader_weight: bobot shard pemimpin berdasarkan mana query dirutekan.

      Skenario

      Nilai default

      Tipe nilai

      Nilai valid

      Contoh

      Semua query

      100

      INT

      • Nilai maksimum: 10000.

      • Nilai minimum: 1.

      • Nilai default: 100.

      -- Konfigurasi level sesi
SET hg_experimental_query_replica_leader_weight = 100;

-- Konfigurasi level database
ALTER DATABASE <database_name> 
SET hg_experimental_query_replica_leader_weight = 100;

      Untuk query titik pemrosesan analitik online (OLAP), jika Anda mengatur parameter replica_count ke nilai lebih besar dari 1 untuk grup tabel tabel tempat Anda ingin mengkueri data, query dirutekan ke shard pemimpin dan shard pengikut berdasarkan nilai parameter hg_experimental_query_replica_mode dan hg_experimental_query_replica_leader_weight. Contoh:

      • Contoh 1: Jika Anda mengatur parameter replica_count ke nilai lebih besar dari 1 untuk grup tabel tabel tempat Anda ingin mengkueri data, dan menambahkan konfigurasi hg_experimental_query_replica_mode=leader_follower, sistem merutekan query ke shard pemimpin dan shard pengikut berdasarkan nilai parameter hg_experimental_query_replica_leader_weight. Secara default, nilai parameter hg_experimental_query_replica_leader_weight adalah 100, dan bobot setiap shard pengikut juga 100. Jika Anda mengatur parameter replica_count ke 4, 1 shard pemimpin dan 3 shard pengikut tersedia untuk setiap shard. Dalam kasus ini, shard pemimpin dan setiap shard pengikut memiliki probabilitas 25% untuk mendapatkan query.

      • Contoh 2: Jika Anda mengatur parameter replica_count ke nilai lebih besar dari 1 untuk grup tabel tabel tempat Anda ingin mengkueri data, dan mengatur parameter hg_experimental_query_replica_mode ke leader_only, sistem hanya merutekan query ke shard pemimpin.

      • Contoh 3: Jika Anda mengatur parameter replica_count ke nilai lebih besar dari 1 untuk grup tabel tabel tempat Anda ingin mengkueri data, dan mengatur parameter hg_experimental_query_replica_mode ke follower_only, sistem hanya merutekan query ke shard pengikut. Secara default, bobot setiap shard pengikut adalah 100. Jika Anda mengatur parameter replica_count ke 4, 1 shard pemimpin dan 3 shard pengikut tersedia untuk setiap shard. Dalam kasus ini, query dirutekan ke tiga shard pengikut, dan setiap shard pengikut memiliki probabilitas 1/3 untuk mendapatkan query.

    • hg_experimental_query_replica_fixed_plan_ha_mode: kebijakan high-availability yang digunakan untuk merutekan query titik. Query titik diproses menggunakan rencana tetap.

      Skenario

      Nilai default

      Tipe nilai

      Nilai valid

      Contoh

      Query titik (diproses menggunakan rencana tetap)

      any

      TEXT

      • any: Query dirutekan ke replika shard berdasarkan nilai parameter hg_experimental_query_replica_mode dan hg_experimental_query_replica_leader_weight. Ini adalah nilai default.

      • leader_first: Nilai ini hanya berlaku jika parameter hg_experimental_query_replica_mode diatur ke leader_follower. Nilai ini menentukan bahwa query diprioritaskan dirutekan ke shard pemimpin. Jika shard pemimpin tidak tersedia karena alasan seperti timeout, query dirutekan ke shard pengikut.

      • off: Query hanya dirutekan sekali. 

      -- Konfigurasi level sesi
SET hg_experimental_query_replica_fixed_plan_ha_mode = any;

-- Konfigurasi level database
ALTER DATABASE <database_name> 
SET hg_experimental_query_replica_fixed_plan_ha_mode = any;

    • hg_experimental_query_replica_fixed_plan_first_query_timeout_ms: ambang batas yang menentukan timeout query titik pertama kali dalam skenario high-availability. Setelah ambang timeout tercapai atau dilampaui, query titik dirutekan ke shard lain yang tersedia. Query titik diproses menggunakan rencana tetap. Misalnya, hg_experimental_query_replica_fixed_plan_first_query_timeout_ms=60 menentukan bahwa jika tidak ada hasil yang dikembalikan untuk query dalam 60 ms, sistem merutekan query ke shard pada node pekerja lain.

      Skenario

      Nilai default

      Tipe nilai

      Nilai valid

      Contoh

      Semua query

      60

      INT

      • Nilai maksimum: 10000.

      • Nilai minimum: 0.

      • Nilai default: 60.

      -- Konfigurasi level sesi
SET hg_experimental_query_replica_fixed_plan_first_query_timeout_ms = 60;

-- Konfigurasi level database
ALTER DATABASE <database_name> 
SET hg_experimental_query_replica_fixed_plan_first_query_timeout_ms = 60;

    Saran untuk skenario berbeda

    Skenario 1: Multi-replika untuk throughput tinggi

    • Deskripsi skenario: Informasi pemantauan menunjukkan bahwa pemanfaatan CPU instance berada pada level sedang, tetapi pemanfaatan CPU salah satu node pekerja sangat rendah dan pemanfaatan CPU node pekerja lainnya sangat tinggi. Hal ini mungkin disebabkan oleh distribusi query yang tidak merata pada node pekerja. Sebagian besar query hanya dirutekan ke beberapa shard. Dalam kasus ini, Anda dapat menambah jumlah replika shard untuk memungkinkan lebih banyak node pekerja memiliki replika shard. Ini dapat secara efektif meningkatkan pemanfaatan sumber daya dan QPS.

    • Prosedur

      1. Tambah jumlah replika shard:

        Dalam contoh ini, grup tabel bernama tg_replica ada dalam database. Jalankan pernyataan SQL berikut untuk mengatur jumlah replika menjadi 2.

        -- Atur jumlah replika untuk tabel dalam grup tabel tg_replica menjadi 2.
call hg_set_table_group_property ('tg_replica', 'replica_count', '2');

        Sistem memiliki pengaturan default berikut:

        • hg_experimental_query_replica_mode=leader_follower

        • hg_experimental_query_replica_leader_weight=100

        Setelah Anda menambah jumlah replika, sistem secara acak merutekan query ke node pekerja yang sesuai dengan shard pemimpin dan shard pengikut. Dengan cara ini, QPS dapat meningkat bahkan untuk query data panas.

      2. Periksa apakah replika shard dimuat ke setiap node pekerja:

        Jalankan pernyataan berikut untuk memeriksa apakah replika shard dimuat ke setiap node pekerja:

        SELECT * FROM hologres.hg_worker_info WHERE table_group_name = 'tg_replica';

        Gambar berikut menunjukkan hasil yang dikembalikan.

        image

        Gambar sebelumnya menunjukkan bahwa satu replika shard dimuat ke beberapa node pekerja. Pengaturan tersebut telah berlaku.

    Skenario 2: Multi-replika untuk ketersediaan tinggi

    • Deskripsi skenario: Anda ingin menyelesaikan masalah bahwa query gagal ketika shard tempat query dilakukan mengalami kegagalan.

    • Prosedur:

      1. Tambah jumlah replika shard:

        Dalam contoh ini, grup tabel bernama tg_replica ada dalam database. Jalankan pernyataan SQL berikut untuk mengatur jumlah replika menjadi 2.

        -- Atur jumlah replika untuk tabel dalam grup tabel tg_replica menjadi 2.
call hg_set_table_group_property ('tg_replica', 'replica_count', '2');

        Sistem memiliki pengaturan default berikut:

        • hg_experimental_query_replica_mode=leader_follower

        • hg_experimental_query_replica_fixed_plan_ha_mode=any

        • hg_experimental_query_replica_fixed_plan_first_query_timeout_ms=60

        Setelah Anda menambah jumlah replika, sistem melakukan operasi yang berbeda dalam skenario yang berbeda:

        • Dalam skenario OLAP, sistem secara acak merutekan query ke node pekerja yang sesuai dengan shard pemimpin dan shard pengikut. Saat Anda menanyakan data, node master secara berkala memeriksa apakah setiap replika shard tersedia. Sistem menghapus replika shard yang tidak tersedia dan merutekan query ke replika shard yang tersedia. Ketika replika shard yang tidak tersedia kembali tersedia, sistem dapat merutekan query ke replika shard tersebut. Sistem membutuhkan waktu 5 detik untuk mendeteksi apakah replika shard tersedia dan 10 detik untuk menghapus node FE yang sesuai dengan node pekerja tempat replika shard yang tidak tersedia dimuat. Secara total, sistem membutuhkan waktu 15 detik untuk mendeteksi masalah dan melanjutkan query. Setelah 15 detik, query dapat dilakukan sesuai harapan.

        • Dalam skenario rencana tetap, sistem menyediakanmekanisme ulang. Jika node pekerja gagal, query dapat dirutekan ke replika shard node pekerja lain. Query dapat selesai, tetapi waktu respons meningkat.

        • Dalam beberapa skenario rencana tetap di mana data harus dikueri segera setelah ditulis, Anda dapat mengatur parameter hg_experimental_query_replica_fixed_plan_ha_mode ke leader_first untuk mencegah latensi panjang shard pengikut. Dalam konfigurasi ini, query diprioritaskan dirutekan ke shard pemimpin. Jika query pada shard pemimpin habis waktu, query dirutekan ke shard pengikut.

          Catatan

          Dalam kasus ini, QPS tidak dapat ditingkatkan untuk query data panas.

      2. Periksa apakah replika shard dimuat ke setiap node pekerja.

        Jalankan pernyataan berikut untuk memeriksa apakah replika shard dimuat ke setiap node pekerja:

        SELECT * FROM hologres.hg_worker_info WHERE table_group_name = 'tg_replica';

        Gambar berikut menunjukkan hasil yang dikembalikan.

        image

        Gambar sebelumnya menunjukkan bahwa satu replika shard dimuat ke beberapa node pekerja. Pengaturan tersebut telah berlaku.

    Pertanyaan Umum

    • Deskripsi masalah: Setelah saya mengonfigurasi parameter seperti yang dijelaskan dalam Skenario 1, query tidak dirutekan ke shard pengikut. Informasi pemantauan di konsol Hologres menunjukkan bahwa node pekerja dengan beban tinggi masih memiliki beban tinggi setelah konfigurasi.

    • Penyebab: Untuk versi sebelum Hologres V1.3, parameter Grand Unified Configuration (GUC) hg_experimental_enable_read_replica disediakan untuk menentukan apakah query dapat dirutekan ke shard pengikut. Nilai default adalah off. Anda dapat menjalankan pernyataan SQL berikut untuk memeriksa apakah parameter GUC diatur ke on. Nilai on menentukan bahwa query dapat dirutekan ke shard pengikut. Nilai off menentukan bahwa query tidak dapat dirutekan ke shard pengikut.

      SHOW hg_experimental_enable_read_replica;

    • Solusi: Jika nilai parameter hg_experimental_enable_read_replica adalah off, Anda dapat menjalankan pernyataan SQL berikut untuk mengatur parameter GUC ke on di level database.

      ALTER DATABASE <database_name> SET hg_experimental_enable_read_replica = on;

      Ganti database_name dengan nama database Anda.