configurações de sessão de load_balancing_*

Essas configurações estão disponíveis em system.settings e são autogeradas a partir do código-fonte.

Especifica o algoritmo de seleção de réplicas usado no processamento de consultas distribuídas.

O ClickHouse oferece suporte aos seguintes algoritmos para escolher réplicas:

• Random (por padrão)
• Nearest hostname
• Hostname levenshtein distance
• Hostname longest common prefix
• Hostname longest common suffix
• In order
• First or random
• Round robin

Veja também:

• distributed_replica_max_ignored_errors

load_balancing = random

O número de erros é contabilizado para cada réplica. A consulta é enviada para a réplica com menos erros e, se houver várias nessa situação, para qualquer uma delas. Desvantagens: a proximidade do servidor não é levada em conta; se as réplicas tiverem dados diferentes, você também obterá dados diferentes.

load_balancing = nearest_hostname

O número de erros é contado para cada réplica. A cada 5 minutos, o número de erros é dividido por 2 usando divisão inteira. Assim, o número de erros para um período recente é calculado com suavização exponencial. Se houver uma réplica com o valor mínimo de erros (isto é, se erros tiverem ocorrido recentemente nas outras réplicas), a consulta será enviada a ela. Se houver várias réplicas com o mesmo valor mínimo de erros, a consulta será enviada para a réplica com o hostname mais semelhante ao hostname do servidor no arquivo de configuração (pelo número de caracteres diferentes nas mesmas posições, até o valor mínimo do comprimento de ambos os hostname).

Por exemplo, example01-01-1 e example01-01-2 diferem em uma posição, enquanto example01-01-1 e example01-02-2 diferem em duas posições. Esse método pode parecer primitivo, mas não requer dados externos sobre a topologia da rede e não compara endereços IP, o que seria complicado no caso dos nossos endereços IPv6.

Assim, se houver réplicas equivalentes, será priorizada a mais próxima pelo nome. Também podemos assumir que, ao enviar uma consulta para o mesmo servidor, na ausência de falhas, uma consulta distribuída também irá para os mesmos servidores. Portanto, mesmo que dados diferentes estejam nas réplicas, a consulta retornará, em sua maior parte, os mesmos resultados.

load_balancing = hostname_levenshtein_distance

Assim como nearest_hostname, mas compara o hostname com base na distância de Levenshtein. Por exemplo:

example-clickhouse-0-0 ample-clickhouse-0-0
1

example-clickhouse-0-0 example-clickhouse-1-10
2

example-clickhouse-0-0 example-clickhouse-12-0
3

load_balancing = hostname_longest_common_prefix

Assim como nearest_hostname, mas dá preferência à réplica cujo hostname compartilha o prefixo comum mais longo com o hostname local (quanto maior o prefixo comum, maior a prioridade). Diferentemente de nearest_hostname, que conta os caracteres diferentes posição por posição, esta estratégia não se confunde com hostnames cujos segmentos numéricos têm comprimentos diferentes. Por exemplo, para o hostname local sfe301:

sfe301 sde301
1

sfe301 sfe10101
3

sfe301 sde505
1

Aqui, sfe10101 é preferido porque compartilha o prefixo comum mais longo (sfe, comprimento 3) com sfe301.

Réplicas com o mesmo comprimento de prefixo comum são escolhidas aleatoriamente. Em particular, quando nenhuma réplica compartilha nenhum prefixo com o hostname local (todos os comprimentos de prefixo comum são zero), essa estratégia se comporta exatamente como random.

load_balancing = hostname_longest_common_suffix

Assim como hostname_longest_common_prefix, mas compara o sufixo comum mais longo em vez do prefixo. Isso é útil quando a identidade do data center é codificada como sufixo do hostname. Por exemplo, para o hostname local et46gtghn.qc.localdomain:

et46gtghn.qc.localdomain tr676ddgh.td.localdomain
12

et46gtghn.qc.localdomain ab999.qc.localdomain
15

Aqui, ab999.qc.localdomain é preferido porque compartilha o sufixo comum mais longo (.qc.localdomain, comprimento 15) com et46gtghn.qc.localdomain.

Réplicas com o mesmo comprimento de sufixo comum são escolhidas aleatoriamente. Em particular, quando nenhuma réplica compartilha qualquer sufixo com o hostname local (todos os comprimentos de sufixo comum são zero), essa estratégia se comporta exatamente como random.

load_balancing = in_order

As réplicas com o mesmo número de erros são acessadas na mesma ordem em que foram especificadas na configuração. Esse método é apropriado quando você sabe exatamente qual réplica é preferível.

load_balancing = first_or_random

Esse algoritmo escolhe a primeira réplica do conjunto ou uma réplica aleatória se a primeira estiver indisponível. Ele é eficaz em topologias de replicação cruzada, mas inútil em outras configurações.

O algoritmo first_or_random resolve o problema do algoritmo in_order. Com in_order, se uma réplica ficar indisponível, a próxima recebe uma carga dobrada, enquanto as demais réplicas continuam lidando com o volume usual de tráfego. Ao usar o algoritmo first_or_random, a carga é distribuída de forma uniforme entre as réplicas que ainda estão disponíveis.

É possível definir explicitamente qual é a primeira réplica usando a configuração load_balancing_first_offset. Isso dá mais controle para redistribuir a carga das consultas entre as réplicas.

load_balancing = round_robin

Este algoritmo usa uma política round-robin entre réplicas com o mesmo número de erros (apenas as consultas com a política round_robin são levadas em conta).

Réplica para a qual uma consulta deve ser enviada preferencialmente quando a estratégia de balanceamento de carga FIRST_OR_RANDOM é usada.