全部產品
Search
文件中心

Hologres:單一實例Shard級多副本

更新時間:Jul 11, 2024

本文將為您介紹在Hologres中Shard層級的Replication使用。

功能概述

從Hologres V1.1版本開始,支援通過設定Table Group副本數的方式來提高某個Table Group查詢並發能力和可用性。您可以在建立Table Group的時候通過顯式指定的replica count或者修改已有的replica count來開啟Replication的功能。新增的副本屬於記憶體層級的運行時副本,不會增加額外儲存成本。

關於replica count的說明具體如下:

  • 資料是按Shard分布的,不同Shard管理不同的資料,不同Shard之間的資料沒有重複,所有的Shard在一起是一份完整的資料。

  • 預設情況下每一個Shard只有一個副本,即replica count = 1,其對應的屬性為leader。您可以通過調整replica count的值,使相同的資料有多個副本,其他副本的屬性為follower。

  • 寫請求由Leader Shard負責,讀請求會均衡由多個Follower Shard(也包含leader Shard)共同服務。當使用Follower Shard查詢時,資料可能會出現10~20ms層級延遲。

  • replica count預設值是1,表示不啟用Replication。大於1表示開啟Replication,replica count數字越大,對資源的消耗也越大。由於Replica布局具有反親和特性,即多個replica不可以布局在同一個計算節點上,因此replica count參數應小於等於計算節點數。從Hologres V1.3.53版本開始,replica count上限為worker個數,如若超過則會報錯。有關不同規格擁有的計算節點數,參考執行個體規格概述

  • 考慮到計算節點計算力的均衡性,在增加Replication時,應該同步縮小shard_count,保持shard_count * replica count = 預設執行個體推薦shard數時,具備最好的效能。

  • Hologres從V1.3.45版本開始,支援查詢高可用。

  • 若您發現您的執行個體監控資訊頁面出現了類似如下圖的情況:執行個體資源

    worker資源

    執行個體整體資源使用率不高,但是僅有小部分Worker計算資源使用率很高,其他Worker計算資源使用率很低,那麼有可能是查詢不均導致的,即大部分的查詢僅用了其中幾個Shard回答查詢,此時您可以增加Shard的副本數量,讓更多的Worker上有Shard的副本,該操作可以有效提高資源使用率和QPS。

    說明
    • Leader Shard和Follower Shard之間同步中繼資料需要消耗一定的資源,且副本數越多,消耗的資源越多。所以若非定位到是因為查詢不均導致資源使用不均衡,否則不建議使用該方式提升QPS。

    • 同時Leader Shard和Follower Shard會存在毫秒級的資料延遲。

    當增加replica後,同樣的查詢條件下,各個Worker的資源已經得到了充分的利用,如下所示。worker資源平衡

使用限制

  • 在Hologres中使用Shard層級的Replication時,僅Hologres V1.1及以上版本支援。

    說明

    您可以在Hologres管控台的執行個體詳情頁查看當前執行個體版本,如果您的執行個體是V0.10以下版本,請您使用自助升級或加入HologresDingTalk交流群反饋,詳情請參見如何擷取更多的線上支援?

  • replica_count必須小於等於計算節點數量。您可以在Hologres的管理主控台的執行個體詳情頁面中查看執行個體節點數量。

文法說明

  • 查詢當前DB的Table Group

    您可以使用如下文法查看當前DB有哪些Table Group。

    select * from hologres.hg_table_group_properties ;
  • 查詢已有Table Group的replica count

    • 文法樣本

      select property_value from hologres.hg_table_group_properties where tablegroup_name = 'table_group_name' and property_key = 'replica_count';
    • 參數說明

      參數

      說明

      table_group_name

      請輸入您需要查詢的Table Group名稱。

      replica_count

      此處為固定參數名稱,無需修改。

  • 開啟Replication

    通過以下命令調整Table Group的副本數量。

    -- 調整Table Group的副本數量
    call hg_set_table_group_property ('<table_group_name>', 'replica_count', '<replica_count>');

    replica_count:設定目標Table Group的副本數量,replica_count應小於計算節點數。

  • 關閉Replication

    • 文法樣本

      -- 修改replica_count,關閉replication
      call hg_set_table_group_property ('table_group_name', 'replica_count', '1');
    • 參數說明

      參數

      說明

      hg_set_table_group_property

      修改Table Group的replica_count。

      • table_group_name:請輸入您需要修改的Table Group名稱。

      • replica_count:設定目標Table Group的副本數量。

      • 設定是否開啟Replication:1為預設值,表示不啟用read replica功能。大於1的數值表示啟用read replica功能。

  • 查看載入情況

    當您設定多replica之後,可以通過如下SQL查看每個Worker載入Shard的情況。

    SELECT * FROM hologres.hg_worker_info;
    說明

    當Worker未完成Shard中繼資料載入之前,worker_id列可能為空白。

    樣本返回結果如下:

    查看載入情況

    olap_replica_2有2個Shard,shard_id分別是0和1,分別在7tn8k9c8slWorker上都有一份資料。

設定查詢高可用和高吞吐策略

行為說明

  • 當設定了Shard多副本時,如下圖所示,Shard的副本會被載入到多個Worker上,此時查詢會隨機使用某個Worker上的Shard副本回答查詢。image

  • 對於點查(Fixed Plan查詢)情境,為了保證點查情境盡量能夠返回結果,在點查情境下會進行查詢重試,當查詢超過一定時間未返回,會使用另一個Worker上的Shard再重試查詢。

相關參數說明

  • hg_experimental_query_replica_mode:指定回答查詢的Shard策略。

    使用情境

    預設值

    取實值型別

    可選值

    使用樣本

    所有查詢

    leader_follower

    TEXT

    • leader_follower(預設):表示會按照比例使用Leader Shard和Follower Shard回答查詢。

    • leader_only:表示僅使用Leader Shard回答查詢,在該設定下即使replica數 > 1,也無法實現擴充吞吐和高可用的能力。

    • follower_only:表示僅使用Follower Shard回答查詢,在該設定下需要replica數 > 3,此時一個Follower Shard>=2,才能實現擴充吞吐和高可用的能力。

    -- session 層級設定
    SET hg_experimental_query_replica_mode = leader_follower;
    
    -- 資料庫層級設定
    ALTER DATABASE <database_name> 
    SET hg_experimental_query_replica_mode = leader_follower;

  • hg_experimental_query_replica_leader_weight:指定回答查詢Leader Shard的權重。

    使用情境

    預設值

    取實值型別

    可選值

    使用樣本

    所有查詢

    100

    INT

    • 最大值:10000

    • 最小值:1

    • 預設值:100

    -- session 層級設定
    SET hg_experimental_query_replica_leader_weight = 100;
    
    -- 資料庫層級設定
    ALTER DATABASE <database_name> 
    SET hg_experimental_query_replica_leader_weight = 100;

    當表對應的Table Group的replica_count >1,且查詢是OLAP點查情境,查詢根據hg_experimental_query_replica_modehg_experimental_query_replica_leader_weight設定的使用Leader Shard和Follower Shard按照一定比例回答查詢。存在如下情境:

    • 情境1:當表對應的Table Group的replica_count>1hg_experimental_query_replica_mode=leader_follower,系統會根據Leader Shard回答查詢的權重(hg_experimental_query_replica_leader_weight參數值預設為100),將查詢路由到Leader Shard 和 Follower Shard進行查詢,預設情況下每個Follower Shard回答查詢的權重為100。例如replica_count=4,此時每個Shard有1個Leader Shard和3個Follower Shard,命中每個Leader Shard和Follower Shard的機率都是25%

    • 情境2:當表對應的Table Group的replica_count>1hg_experimental_query_replica_mode=leader_only,無論replica_count是多少,系統僅使用Leader Shard回答查詢。

    • 情境3:當表對應的Table Group的replica_count>1hg_experimental_query_replica_mode='follower_only',系統僅使用Follower Shard回答查詢,預設情況下每個Follower Shard回答查詢的權重為100。例如replica_count=4,此時每個Shard有1個Leader Shard和3個Follower Shard,此時只會使用3個Follower Shard回答查詢,命中每個Follower Shard的機率是三分之一。

  • hg_experimental_query_replica_fixed_plan_ha_mode:指定點查(Fixed Plan查詢)情境下高可用的模式策略。

    使用情境

    預設值

    取實值型別

    可選值

    使用樣本

    點查(Fixed Plan查詢)

    any

    TEXT

    • any(預設值):按照hg_experimental_query_replica_mode設定的Shard範圍和hg_experimental_query_replica_leader_weight設定的權重將查詢隨機分發到Shard副本回答查詢。

    • leader_first:預設值,僅在hg_experimental_query_replica_mode值設為leader_follower時生效,表示優先發送查詢到Leader Shard,僅在Leader Shard不可用(如逾時)時才發送查詢到Follower Shard。

    • off:表示不執行重試,僅做一次查詢。

    -- session 層級設定
    SET hg_experimental_query_replica_fixed_plan_ha_mode = any;
    
    -- 資料庫層級設定
    ALTER DATABASE <database_name> 
    SET hg_experimental_query_replica_fixed_plan_ha_mode = any;

  • hg_experimental_query_replica_fixed_plan_first_query_timeout_ms:指定點查(Fixed Plan查詢)情境下高可用的模式時,表示首次查詢的逾時時間,逾時後查詢將被發送至另一個可用的Shard來重試。例如hg_experimental_query_replica_fixed_plan_first_query_timeout_ms=60表示如果查詢60ms並未返回結果,系統會換一個Worker進行重試。

    使用情境

    預設值

    取實值型別

    可選值

    使用樣本

    所有查詢

    60

    INT

    • 最大值:10000

    • 最小值:0

    • 預設值:60

    -- session 層級設定
    SET hg_experimental_query_replica_fixed_plan_first_query_timeout_ms = 60;
    
    -- 資料庫層級設定
    ALTER DATABASE <database_name> 
    SET hg_experimental_query_replica_fixed_plan_first_query_timeout_ms = 60;
    

情境設定建議

情境1:多副本高吞吐情境

  • 情境描述:發現監控出現了類似如下的情況,執行個體整體資源使用率不高,但是僅有小部分Worker計算資源使用率很高,其他Worker計算資源使用率很低,判斷有可能是查詢不均導致的,即大部分的查詢僅用了其中幾個Shard回答查詢,此時您可以增加Shard的副本數量,使更多的Worker上有Shard的副本,該操作可以有效提高資源使用率和QPS。

  • 具體操作:

    1. 增加副本數量:

      例如出現資料庫中有一個名為tg_replica的Table Group,您可以使用如下SQL將其副本數量設定為2。

      -- 針對將名為tg_replica的table group的副本數量設定為2
      call hg_set_table_group_property ('tg_replica', 'replica_count', '2');

      由於系統預設配置如下:

      • hg_experimental_query_replica_mode=leader_follower

      • hg_experimental_query_replica_leader_weight=100

      所以增加副本數量後,系統會將查詢隨機分發到Leader Shard和Follower Shard對應的Worker節點上,以解決因為查詢熱點導致的QPS無法增加的問題。

    2. 檢查Worker是否載入了Shard:

      使用如下命令檢查Worker是否載入了Shard。

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

      樣本返回結果如下:

      image

      如上圖所示,同一個Shard被多個Worker載入,表示設定成功。

情境2:多副本高可用情境

  • 情境描述:您希望解決因為單Shard Failover時導致查詢不可用情況。

  • 具體操作:

    1. 增加副本數量:

      例如出現資料庫中有一個名為tg_replica的Table Group,您可以使用如下SQL將其副本數量設定為2。

      -- 針對將名為tg_replica的table group的副本數量設定為2
      call hg_set_table_group_property ('tg_replica', 'replica_count', '2');

      由於系統預設配置如下:

      • 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

      所以增加副本數量後:

      • 此時對於OLAP情境,系統會將查詢隨機分發到Leader Shard和Follower Shard對應的Worker節點上。查詢的同時,Master會定期檢測每個Shard的是否可用,系統會主動將停用Shard剔除查詢備選Shard,當Shard重新可用後,再加入查詢備選Shard。由於發現Shard不可用需要5秒,且摘除Worker對應的FE需要10秒,所以在系統發現問題到摘除節點恢複查詢需要15秒,即有15秒的查詢失敗期間,15秒後即可正常查詢。

      • 對於Fixed Plan情境,由於系統有重試機制,若一個Worker發生Failover,當時的查詢回應時間變長,但是不會失敗。

      • 對於一些Fixed Plan查詢情境,對於資料寫入即可查的行為敏感,無法容忍Leader Shard和Follower Shard之間延遲的情境,可以將hg_experimental_query_replica_fixed_plan_ha_mode設定為leader_first。表示在Fixed Plan下,查詢始終先用Leader Shard回答查詢,當Leader Shard查詢逾時時,再使用Follower Shard回答查詢。

        說明

        此時Fixed Plan情境就不具有解決因為查詢熱點導致的QPS無法增加問題的能力。

    2. 檢查Worker是否載入了Shard:

      使用如下命令檢查Worker是否載入了Shard。

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

      樣本返回結果如下:

      image

      如上圖所示,同一個Shard被多個Worker載入,表示設定成功。

常見問題

  • 問題描述:按照情境1的情境設定參數後,查詢並未分發到Follower Shard。Hologres管理主控台監控資訊上仍然是設定多副本之前的Worker負載很高。

  • 原因分析:Hologres V1.3版本之前存在hg_experimental_enable_read_replicaGUC,用於控制Follower Shard是否能參數查詢,且預設關閉。您可以使用如下SQL檢查該參數是否開啟。如果傳回值是on表示開啟,傳回值是off表示關閉。

    SHOW hg_experimental_enable_read_replica;
  • 解決方案:如果hg_experimental_enable_read_replica是關閉的,您可以使用如下SQL在資料庫層級開啟。

    ALTER DATABASE <database_name> SET hg_experimental_enable_read_replica = on;

    其中database_name為資料庫名稱