Hologres:Replicação no nível de shard para uma única instância

Detalhes sobre a contagem de réplicas:

• Os dados são distribuídos entre shards. Cada shard gerencia um subconjunto dos dados. Em conjunto, todos os shards formam um conjunto de dados completo.

• Por padrão, cada shard possui apenas uma réplica, ou seja, replica_count = 1. Essa réplica é o shard líder. Aumente a contagem de réplicas para criar múltiplas réplicas dos mesmos dados. Essas réplicas adicionais são shards seguidores.

• O shard líder processa solicitações de escrita. As solicitações de leitura são balanceadas entre todas as réplicas, incluindo os shards líderes e seguidores. Ao consultar um shard seguidor, pode ocorrer uma latência de dados de 10 ms a 20 ms.

• Devido a uma política de anti-afinidade que impede a implantação de múltiplas réplicas do mesmo shard no mesmo nó worker, o valor de replica_count não deve exceder o número de nós workers. No Hologres V1.3.53 e posteriores, o sistema reporta um erro caso esse limite seja ultrapassado. Para verificar o número de nós workers conforme as especificações da instância, consulte Gerenciamento de instâncias.

• Para garantir uma carga computacional equilibrada entre os nós workers, ao aumentar a contagem de réplicas, diminua a contagem de shards. O desempenho ideal ocorre quando shard_count * replica_count = contagem de shards recomendada para a instância.

• O Hologres oferece suporte a alta disponibilidade (HA) para consultas desde a versão V1.3.45.

• Caso a página de monitoramento da sua instância apresente o seguinte:

  

  A utilização geral de recursos da instância não está alta, mas alguns nós workers apresentam uso elevado enquanto outros têm baixa utilização. Isso pode indicar distribuição desigual de consultas, em que a maioria das consultas é respondida por apenas alguns shards. Nesse cenário, aumente a contagem de réplicas para distribuí-las por mais workers. Essa estratégia melhora efetivamente a utilização de recursos e as consultas por segundo (QPS).

  Nota

  • A sincronização de metadados entre shards líderes e seguidores consome recursos. Quanto mais réplicas, maior o consumo. Portanto, não recomendamos o uso desse método para aumentar o QPS, a menos que você tenha confirmado que a utilização desigual de recursos decorre de uma distribuição irregular de consultas.

  • Além disso, existe uma latência de dados na ordem de milissegundos entre os shards líderes e os seguidores.

  Após aumentar a contagem de réplicas, os recursos de cada worker são utilizados de forma mais equilibrada sob as mesmas condições de consulta, conforme mostra a figura a seguir.

Comportamento

• Quando múltiplas réplicas de shard são configuradas, as réplicas de um shard são carregadas em vários workers, conforme ilustrado na figura a seguir. As consultas são então roteadas aleatoriamente para uma réplica de shard em um dos workers para processamento.

• Em cenários de consulta pontual (consulta de plano fixo), existe um mecanismo de nova tentativa para garantir que os resultados sejam retornados sempre que possível. Caso uma consulta não retorne resultado dentro de um determinado período, o sistema tenta executá-la novamente em uma réplica em outro worker.

Parâmetros

• hg_experimental_query_replica_mode: Define a política de shard para responder às consultas.

  Caso de uso	Padrão	Tipo	Valores válidos	Exemplo
  Todas as consultas	leader_follower	TEXT	leader_follower (padrão): Indica que tanto shards líderes quanto seguidores são usados proporcionalmente para responder às consultas. leader_only: Indica que apenas o shard líder responde às consultas. Com essa configuração, não é possível escalar horizontalmente o throughput ou alcançar alta disponibilidade, mesmo se replicas > 1. follower_only: Especifica que apenas shards seguidores respondem às consultas. Requer replicas > 3 para garantir que haja dois ou mais shards seguidores, aumentando assim o throughput e a alta disponibilidade.	-- 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: Define o peso do shard líder para responder às consultas.

  Caso de uso	Padrão	Tipo	Valores válidos	Exemplo
  Todas as consultas	100	INT	Máximo: 10000 Mínimo: 1 Padrão: 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;

  Quando o replica_count do grupo de tabelas de uma tabela for maior que 1 e a consulta for uma consulta pontual OLAP, os shards líderes e seguidores responderão à consulta em uma proporção específica, baseada nas configurações de hg_experimental_query_replica_mode e hg_experimental_query_replica_leader_weight. Isso ocorre nos seguintes cenários:

  • Cenário 1: Se o grupo de tabelas tiver replica_count maior que 1 e hg_experimental_query_replica_mode=leader_follower, o sistema roteia as consultas para o shard líder e para os shards seguidores. O roteamento baseia-se em um sistema de pesos. O peso do shard líder é definido pelo parâmetro hg_experimental_query_replica_leader_weight, cujo padrão é 100. Por padrão, o peso de cada shard seguidor também é 100. Por exemplo, se replica_count=4, cada shard terá um shard líder e três seguidores. A probabilidade de uma consulta ser roteada para qualquer um deles é de 25%.

  • Cenário 2: Quando o grupo de tabelas tiver replica_count>1 e hg_experimental_query_replica_mode=leader_only, o sistema usa apenas o shard líder para responder às consultas, independentemente do valor de replica_count.

  • Cenário 3: Quando o grupo de tabelas correspondente a uma tabela tiver replica_count>1 e hg_experimental_query_replica_mode='follower_only', o sistema utiliza apenas shards seguidores para responder às consultas. Por padrão, o peso de cada shard seguidor para responder a uma consulta é 100. Por exemplo, se replica_count=4, haverá um shard líder e três seguidores. Nesse caso, apenas os três shards seguidores são usados, e a probabilidade de atingir cada um deles é de um terço.

• hg_experimental_query_replica_fixed_plan_ha_mode: Especifica o modo de alta disponibilidade para cenários de consulta pontual (consulta de plano fixo).

  Caso de uso	Padrão	Tipo	Valores válidos	Exemplo
  Consulta pontual (consulta de plano fixo)	any	TEXT	any (Padrão): Distribui consultas aleatoriamente para réplicas de shard com base no escopo de shard definido por hg_experimental_query_replica_mode e no peso definido por hg_experimental_query_replica_leader_weight. leader_first: Valor padrão. Esta configuração só entra em vigor quando hg_experimental_query_replica_mode está definido como leader_follower. Prioriza o envio de consultas para o shard líder e recorre a um shard seguidor apenas se o shard líder estiver indisponível, como em caso de timeout. off: A consulta é executada apenas uma vez, sem novas tentativas.	-- 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: Define o tempo limite para a consulta inicial no modo de alta disponibilidade para consultas pontuais (consultas de plano fixo). Se ocorrer um timeout, a consulta é enviada para outro shard disponível para nova tentativa. Por exemplo, hg_experimental_query_replica_fixed_plan_first_query_timeout_ms=60 indica que, se uma consulta não retornar resultado em 60 ms, o sistema tentará novamente em outro worker.

  Caso de uso	Padrão	Tipo	Valores válidos	Exemplo
  Todas as consultas	60	INT	Máximo: 10000 Mínimo: 0 Padrão: 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;

Caso de uso 1: Alto throughput com múltiplas réplicas

• Cenário: Você observa pelo monitoramento que a utilização geral de recursos da instância não está alta, mas alguns nós workers apresentam uso intenso enquanto outros estão subutilizados. Provavelmente isso se deve a uma distribuição desigual de consultas, em que a maioria é processada por poucos shards. Nessa situação, aumente o número de réplicas de shard para colocar réplicas em mais workers, melhorando efetivamente a utilização de recursos e o QPS.

• Procedimento:

  1. Aumente a contagem de réplicas:

     Por exemplo, se você tiver um grupo de tabelas chamado tg_replica no seu banco de dados, use a seguinte instrução SQL para definir sua contagem de réplicas como 2.

     -- Set the replica count of the 'tg_replica' table group to 2.
     call hg_set_table_group_property ('tg_replica', 'replica_count', '2');

     O sistema utiliza a seguinte configuração padrão:

     • hg_experimental_query_replica_mode=leader_follower

     • hg_experimental_query_replica_leader_weight=100

     Após aumentar a contagem de réplicas, o sistema distribui aleatoriamente as consultas para os nós workers que hospedam o shard líder e os shards seguidores. Isso resolve o problema em que o QPS não consegue aumentar devido a hotspots de consulta.

  2. Verifique se os workers carregaram os shards:

     Execute o comando abaixo para checar se os shards foram carregados nos workers:

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

     O resultado inclui as colunas worker_id, table_group_name e shard_id.

     A configuração foi bem-sucedida se a saída mostrar o mesmo shard_id carregado em múltiplos worker_ids.

Caso de uso 2: Alta disponibilidade com múltiplas réplicas

• Cenário: Evitar falhas de consulta causadas por failover de um único shard.

• Procedimento:

  1. Aumente a contagem de réplicas:

     Por exemplo, se você tiver um grupo de tabelas chamado tg_replica no seu banco de dados, use a seguinte instrução SQL para definir sua contagem de réplicas como 2.

     -- Set the replica count of the 'tg_replica' table group to 2.
     call hg_set_table_group_property ('tg_replica', 'replica_count', '2');

     O sistema utiliza a seguinte configuração padrão:

     • 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

     Após aumentar a contagem de réplicas:

     • Para cenários OLAP, o sistema distribui aleatoriamente as consultas para os nós workers dos shards líderes e seguidores. O processo Master verifica periodicamente a disponibilidade de cada shard e remove automaticamente os shards indisponíveis da lista de candidatos a consulta. Assim que um shard volta a ficar disponível, ele é readicionado à lista. Leva 5 segundos para detectar um shard indisponível e 10 segundos para remover o worker correspondente do frontend (FE). Portanto, podem ocorrer falhas de consulta por até 15 segundos durante esse processo de detecção e recuperação. As consultas retomam normalmente logo em seguida.

     • Para cenários de consulta de plano fixo, o mecanismo de nova tentativa evita falhas de consulta durante um failover de worker, embora o tempo de resposta possa aumentar.

     • Para alguns cenários de consulta de plano fixo sensíveis à consistência de leitura após escrita e que não toleram a latência entre o shard líder e um seguidor, defina o parâmetro hg_experimental_query_replica_fixed_plan_ha_mode como leader_first. Isso significa que, para consultas de plano fixo, o shard líder será sempre usado para responder primeiro. Se a consulta ao shard líder atingir o tempo limite, um shard seguidor será então utilizado para responder.

       Nota

       Neste caso, o cenário de plano fixo não consegue resolver gargalos de QPS causados por hotspots de consulta.

  2. Verifique se os workers carregaram os shards:

     Execute o comando abaixo para checar se os shards foram carregados nos workers:

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

     Se o mesmo shard estiver carregado por múltiplos workers, a configuração foi bem-sucedida.