Menggunakan replikasi tingkat shard di Hologres - Hologres

Topik ini menjelaskan cara menggunakan replikasi tingkat shard di Hologres.

Cara kerja

Mulai dari Hologres V1.1, Anda dapat meningkatkan konkurensi kueri dan ketersediaan kelompok tabel dengan mengatur jumlah replika. Replikasi dapat diaktifkan dengan menentukan jumlah replika saat membuat kelompok tabel atau dengan memodifikasi jumlah replika pada kelompok yang sudah ada. Replika tambahan tersebut merupakan salinan dalam memori dan tidak menimbulkan biaya penyimpanan.

Detail mengenai jumlah replika:

Data didistribusikan ke berbagai shard. Setiap shard mengelola sebagian data, dan secara bersama-sama membentuk set data lengkap.
Secara default, setiap shard hanya memiliki satu replika, yaitu replica_count = 1. Replika ini adalah leader shard. Anda dapat menambah jumlah replika untuk membuat beberapa salinan data yang sama. Replika tambahan ini disebut follower shard.
Permintaan tulis ditangani oleh leader shard, sedangkan permintaan baca diseimbangkan di antara semua replika, termasuk leader dan follower shard. Saat melakukan kueri ke follower shard, Anda mungkin mengalami latensi data sebesar 10 ms hingga 20 ms.
Karena kebijakan anti-affinity yang mencegah beberapa replika dari shard yang sama ditempatkan pada node pekerja yang sama, nilai replica_count tidak boleh melebihi jumlah node pekerja. Di Hologres V1.3.53 dan versi setelahnya, sistem akan melaporkan error jika batas ini dilampaui. Untuk informasi jumlah node pekerja sesuai spesifikasi instans, lihat Instance management.
Untuk memastikan beban komputasi merata di seluruh node pekerja, saat menambah jumlah replika, sebaiknya Anda mengurangi jumlah shard. Performa optimal tercapai ketika shard_count * replica_count = jumlah shard yang direkomendasikan untuk instans.
Hologres mendukung high availability (HA) untuk kueri mulai dari V1.3.45.
Jika halaman pemantauan instans Anda menampilkan hal berikut:

Penggunaan sumber daya keseluruhan instans tidak tinggi, tetapi beberapa node pekerja menunjukkan penggunaan sumber daya tinggi sementara yang lain rendah. Hal ini kemungkinan disebabkan oleh distribusi kueri yang tidak merata, di mana sebagian besar kueri dijawab hanya oleh beberapa shard. Dalam kasus ini, Anda dapat menambah jumlah replika agar replika tersebar di lebih banyak node pekerja. Strategi ini secara efektif dapat meningkatkan pemanfaatan sumber daya dan queries per second (QPS).
Catatan
- Sinkronisasi metadata antara leader shard dan follower shard mengonsumsi sumber daya. Semakin banyak replika yang Anda miliki, semakin banyak sumber daya yang dikonsumsi. Oleh karena itu, kami tidak merekomendasikan metode ini untuk meningkatkan QPS kecuali Anda telah memastikan bahwa ketidakseimbangan penggunaan sumber daya disebabkan oleh distribusi kueri yang tidak merata.
- Selain itu, terdapat latensi data dalam skala milidetik antara leader shard dan follower shard.
Setelah Anda menambah jumlah replika, sumber daya setiap node pekerja dimanfaatkan lebih merata dalam kondisi kueri yang sama, seperti yang ditunjukkan pada gambar berikut.

Batasan

Replikasi tingkat shard hanya didukung di Hologres V1.1 dan versi setelahnya.

Catatan
Anda dapat memeriksa versi instans saat ini di halaman detail instans di Konsol Hologres. Jika instans Anda lebih lama dari V0.10, lihat Instance upgrades untuk instruksi peningkatan atau bergabunglah dengan grup DingTalk Hologres untuk dukungan. Untuk informasi lebih lanjut, lihat How to get online support?.
Nilai replica_count harus kurang dari atau sama dengan jumlah node pekerja. Anda dapat melihat jumlah node pekerja untuk instans Anda di halaman detail instans di Konsol Hologres.

Manage shard replication

Query table groups in the current database
Gunakan pernyataan berikut untuk melihat kelompok tabel di database saat ini:
```
select * from hologres.hg_table_group_properties ;
```
Query the replica count of an existing table group
- Contoh
```
select property_value from hologres.hg_table_group_properties where tablegroup_name = 'table_group_name' and property_key = 'replica_count';
```
- Parameter
  
  Parameter
  
  Description
  
  table_group_name
  
  Nama kelompok tabel target.
  
  replica_count
  
  Ini adalah nama parameter tetap dan tidak boleh diubah.

Enable replication

Contoh

Gunakan pernyataan berikut untuk menyesuaikan jumlah replika kelompok tabel:

-- Adjust the replica count of a table group.
call hg_set_table_group_property ('<table_group_name>', 'replica_count', '<replica_count>');

Parameter

Parameter

Description

hg_set_table_group_property

Modifies the replica_count of a table group.

table_group_name: Nama kelompok tabel yang ingin Anda modifikasi.
replica_count: Jumlah replika yang diinginkan untuk kelompok tabel. Nilainya tidak boleh melebihi jumlah node pekerja. Nilai umum adalah 2.
Default-nya adalah 1 (replikasi dinonaktifkan). Nilai lebih dari 1 mengaktifkan replikasi.

Disable replication

Contoh

-- Modify replica_count to disable replication.
call hg_set_table_group_property ('table_group_name', 'replica_count', '1');

Parameter

Parameter

Description

hg_set_table_group_property

Modifies the replica_count of a table group.

table_group_name: Nama kelompok tabel yang ingin Anda modifikasi.
replica_count: Jumlah replika yang diinginkan untuk kelompok tabel.
Default-nya adalah 1 (replikasi dinonaktifkan). Nilai lebih dari 1 mengaktifkan replikasi.

Check the loading status
Setelah Anda mengatur beberapa replika, Anda dapat menjalankan pernyataan SQL berikut untuk melihat status pemuatan shard di setiap node pekerja:
```
SELECT * FROM hologres.hg_worker_info;
```
Catatan
Kolom worker_id mungkin kosong sebelum node pekerja selesai memuat metadata shard.

Hasil kueri mencakup kolom worker_id, table_group_name, dan shard_id. Selain olap_replica_2, hasil juga berisi informasi distribusi shard untuk kelompok tabel lain seperti olap_replica_2_tg_inte.

Untuk kelompok tabel olap_replica_2 yang memiliki dua shard dengan nilai shard_id 0 dan 1, salinan data untuk setiap shard ada di kedua node pekerja 7tn8k dan 9c8sl.

Query routing for high availability and throughput

Behavior

Saat beberapa replika shard dikonfigurasi, replika suatu shard dimuat ke beberapa node pekerja, seperti yang ditunjukkan pada gambar berikut. Kueri kemudian diarahkan secara acak ke replika shard di salah satu node pekerja untuk diproses.
Untuk skenario kueri titik (fixed-plan query), mekanisme retry diterapkan untuk memastikan hasil selalu dikembalikan jika memungkinkan. Jika kueri tidak mengembalikan hasil dalam periode tertentu, kueri tersebut diulang di replika pada node pekerja lain.

Parameters

hg_experimental_query_replica_mode: Menentukan kebijakan shard untuk menjawab kueri.

Use case

Default

Type

Valid values

Example

All queries

leader_follower

TEXT

leader_follower (default): Menunjukkan bahwa baik leader shard maupun follower shard digunakan secara proporsional untuk menjawab kueri.
leader_only: Menunjukkan bahwa hanya leader shard yang digunakan untuk menjawab kueri. Dengan pengaturan ini, Anda tidak dapat meningkatkan throughput atau mencapai high availability, meskipun replicas > 1.
follower_only: Menentukan bahwa hanya follower shard yang digunakan untuk menjawab kueri, dan memerlukan replicas > 3 untuk memastikan tersedia dua atau lebih follower shard guna meningkatkan throughput dan high availability.

-- Session-level setting
SET hg_experimental_query_replica_mode = leader_follower;

-- Database-level setting
ALTER DATABASE <database_name> 
SET hg_experimental_query_replica_mode = leader_follower;

hg_experimental_query_replica_leader_weight: Menentukan bobot untuk leader shard yang menjawab kueri.

Use case

Default

Type

Valid values

Example

All queries

100

INT

Maksimum: 10000
Minimum: 1
Default: 100

-- Session-level setting
SET hg_experimental_query_replica_leader_weight = 100;

-- Database-level setting
ALTER DATABASE <database_name> 
SET hg_experimental_query_replica_leader_weight = 100;

Ketika replica_count Table Group suatu tabel lebih dari 1 dan kuerinya merupakan kueri OLAP titik, Leader Shard dan Follower Shard menjawab kueri dalam rasio tertentu berdasarkan pengaturan hg_experimental_query_replica_mode dan hg_experimental_query_replica_leader_weight. Hal ini terjadi dalam skenario berikut:

Scenario 1: Jika kelompok tabel memiliki replica_count lebih dari 1 dan hg_experimental_query_replica_mode=leader_follower, sistem mengarahkan kueri ke leader shard dan follower shard berdasarkan sistem pembobotan. Bobot untuk leader shard ditentukan oleh parameter hg_experimental_query_replica_leader_weight, yang default-nya 100. Secara default, bobot untuk setiap follower shard juga 100. Misalnya, jika replica_count=4, setiap shard memiliki satu leader shard dan tiga follower shard. Probabilitas kueri diarahkan ke salah satunya adalah 25%.
Scenario 2: Ketika kelompok tabel memiliki replica_count>1 dan hg_experimental_query_replica_mode=leader_only, sistem hanya menggunakan leader shard untuk menjawab kueri, terlepas dari nilai replica_count.
Scenario 3: Ketika kelompok tabel memiliki replica_count>1 dan hg_experimental_query_replica_mode='follower_only', sistem hanya menggunakan follower shard untuk menjawab kueri. Secara default, bobot setiap follower shard untuk menjawab kueri adalah 100. Misalnya, jika replica_count=4, terdapat satu leader shard dan tiga follower shard. Dalam kasus ini, hanya tiga follower shard yang digunakan untuk menjawab kueri, dan probabilitas mengenai setiap follower shard adalah sepertiga.

hg_experimental_query_replica_fixed_plan_ha_mode: Menentukan mode high-availability untuk skenario kueri titik (fixed-plan query).

Use case

Default

Type

Valid values

Example

Point query (fixed-plan query)

any

TEXT

any (Default): Mendistribusikan kueri secara acak ke replika shard berdasarkan cakupan shard yang ditentukan oleh hg_experimental_query_replica_mode dan bobot yang ditentukan oleh hg_experimental_query_replica_leader_weight.
leader_first: Nilai default. Pengaturan ini hanya berlaku ketika hg_experimental_query_replica_mode diatur ke leader_follower. Pengaturan ini memprioritaskan pengiriman kueri ke leader shard dan hanya beralih ke follower shard jika leader shard tidak tersedia, misalnya karena timeout.
off: Kueri hanya dilakukan sekali tanpa retry.

-- Session-level setting
SET hg_experimental_query_replica_fixed_plan_ha_mode = any;

-- Database-level setting
ALTER DATABASE <database_name> 
SET hg_experimental_query_replica_fixed_plan_ha_mode = any;

hg_experimental_query_replica_fixed_plan_first_query_timeout_ms: Menentukan timeout untuk kueri awal dalam mode high-availability untuk kueri titik (fixed-plan query). Jika terjadi timeout, kueri dikirim ke shard lain yang tersedia untuk diulang. Misalnya, hg_experimental_query_replica_fixed_plan_first_query_timeout_ms=60 berarti jika kueri tidak mengembalikan hasil dalam 60 ms, sistem akan mengulang kueri di worker lain.

Use case

Default

Type

Valid values

Example

All queries

INT

Maksimum: 10000
Minimum: 0
Default: 60

-- Session-level setting
SET hg_experimental_query_replica_fixed_plan_first_query_timeout_ms = 60;

-- Database-level setting
ALTER DATABASE <database_name> 
SET hg_experimental_query_replica_fixed_plan_first_query_timeout_ms = 60;

Use cases

Use case 1: High throughput with multiple replicas

Scenario: Dari pemantauan, Anda mengamati bahwa penggunaan sumber daya keseluruhan instans tidak tinggi, tetapi beberapa node pekerja memiliki penggunaan sumber daya tinggi sementara yang lain kurang dimanfaatkan. Hal ini kemungkinan disebabkan oleh distribusi kueri yang tidak merata, di mana sebagian besar kueri diproses oleh beberapa shard saja. Dalam kasus ini, Anda dapat menambah jumlah replika shard agar replika ditempatkan di lebih banyak node pekerja, yang secara efektif meningkatkan pemanfaatan sumber daya dan QPS.
Procedure:
1. Tingkatkan jumlah replika:
  
  Misalnya, jika Anda memiliki kelompok tabel bernama tg_replica di database Anda, Anda dapat menggunakan pernyataan SQL berikut untuk mengatur jumlah replikanya menjadi 2.
```
-- Set the replica count of the 'tg_replica' table group to 2.
call hg_set_table_group_property ('tg_replica', 'replica_count', '2');
```
  Sistem menggunakan konfigurasi default berikut:
  - hg_experimental_query_replica_mode=leader_follower
  - hg_experimental_query_replica_leader_weight=100
  Setelah Anda menambah jumlah replika, sistem mendistribusikan kueri secara acak ke node pekerja yang meng-host leader shard dan follower shard. Hal ini mengatasi masalah ketidakmampuan meningkatkan QPS akibat hotspot kueri.
2. Periksa apakah node pekerja telah memuat shard:
  
  Gunakan perintah berikut untuk memeriksa apakah shard telah dimuat di node pekerja:
```
SELECT * FROM hologres.hg_worker_info WHERE table_group_name = 'tg_replica';
```
  Hasil mencakup kolom worker_id, table_group_name, dan shard_id.
  
  Konfigurasi berhasil jika output menunjukkan shard_id yang sama dimuat di beberapa worker_id.

Use case 2: High availability with multiple replicas

Scenario: Mencegah kegagalan kueri akibat failover pada satu shard.
Procedure:
1. Tingkatkan jumlah replika:
  
  Misalnya, jika Anda memiliki kelompok tabel bernama tg_replica di database Anda, Anda dapat menggunakan pernyataan SQL berikut untuk mengatur jumlah replikanya menjadi 2.
```
-- Set the replica count of the 'tg_replica' table group to 2.
call hg_set_table_group_property ('tg_replica', 'replica_count', '2');
```
  Sistem menggunakan konfigurasi 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:
  
  Untuk skenario OLAP, sistem mendistribusikan kueri secara acak ke node pekerja leader dan follower shard. Proses Master secara berkala memeriksa ketersediaan setiap shard dan secara otomatis menghapus shard yang tidak tersedia dari daftar kandidat kueri. Begitu shard tersedia kembali, shard tersebut ditambahkan kembali ke daftar. Diperlukan waktu 5 detik untuk mendeteksi shard yang tidak tersedia dan 10 detik untuk menghapus node pekerja terkait dari frontend (FE). Oleh karena itu, kegagalan kueri mungkin terjadi hingga 15 detik selama proses deteksi dan pemulihan ini. Kueri kembali normal setelahnya.
  
  Untuk skenario fixed-plan query, mekanisme retry mencegah kegagalan kueri selama failover node pekerja, meskipun waktu respons mungkin meningkat.
  
  Untuk beberapa skenario fixed-plan query yang sensitif terhadap konsistensi read-after-write dan tidak dapat mentoleransi latensi antara leader shard dan follower shard, Anda dapat mengatur parameter hg_experimental_query_replica_fixed_plan_ha_mode ke leader_first. Artinya, untuk kueri fixed-plan, leader shard selalu digunakan terlebih dahulu untuk menjawab kueri. Jika kueri ke leader shard mengalami timeout, follower shard kemudian digunakan untuk menjawab kueri.
  
  Catatan
  Dalam kasus ini, skenario fixed-plan tidak dapat mengatasi bottleneck QPS akibat hotspot kueri.
2. Periksa apakah node pekerja telah memuat shard:
  
  Gunakan perintah berikut untuk memeriksa apakah shard telah dimuat di node pekerja:
```
SELECT * FROM hologres.hg_worker_info WHERE table_group_name = 'tg_replica';
```
  Jika shard yang sama dimuat oleh beberapa node pekerja, konfigurasi berhasil.

Troubleshooting

Problem: Setelah mengonfigurasi parameter seperti yang dijelaskan dalam Use case 1, kueri tidak didistribusikan ke follower shard. Beban node pekerja yang ditampilkan di Konsol Hologres tetap tinggi seperti sebelum Anda mengonfigurasi beberapa replika.
Di versi Hologres sebelum V1.3, parameter GUC hg_experimental_enable_read_replica digunakan untuk mengontrol apakah follower shard dapat berpartisipasi dalam kueri, dan parameter ini dinonaktifkan secara default. Anda dapat menggunakan pernyataan SQL berikut untuk memeriksa apakah parameter ini diaktifkan. Jika nilai yang dikembalikan adalah on, parameter tersebut aktif. Jika nilai yang dikembalikan adalah off, parameter tersebut dinonaktifkan.
```
SHOW hg_experimental_enable_read_replica;
```
Untuk mengatasi masalah ini, jika hg_experimental_enable_read_replica dinonaktifkan, Anda dapat menggunakan pernyataan SQL berikut untuk mengaktifkannya di tingkat database.
```
ALTER DATABASE <database_name> SET hg_experimental_enable_read_replica = on;
```
Ganti database_name dengan nama database Anda.

Parameter	Description
table_group_name	Nama kelompok tabel target.
replica_count	Ini adalah nama parameter tetap dan tidak boleh diubah.