> ## Documentation Index
> Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# configurações de sessão de load_balancing_*

> Configurações de sessão do ClickHouse no grupo gerado por load_balancing_*.

export const SettingsInfoBlock = ({type, default_value, changeable_without_restart}) => {
  return <div className="not-prose" style={{
    display: "flex",
    flexWrap: "wrap",
    alignItems: "baseline",
    columnGap: "0.5rem",
    rowGap: "0.125rem",
    margin: "0.375rem 0",
    fontSize: "0.8125rem",
    lineHeight: "1.125rem"
  }}>
      <div style={{
    fontWeight: 600,
    opacity: 0.72
  }}>Tipo</div>
      <div style={{
    overflowWrap: "anywhere"
  }}>{type}</div>
      <div style={{
    fontWeight: 600,
    opacity: 0.72,
    marginInlineStart: "0.5rem"
  }}>Padrão</div>
      <div style={{
    overflowWrap: "anywhere"
  }}>{default_value}</div>
      {changeable_without_restart && <div style={{
    fontWeight: 600,
    opacity: 0.72,
    marginInlineStart: "0.5rem"
  }}>
          Pode ser alterado sem reiniciar
        </div>}
      {changeable_without_restart && <div style={{
    overflowWrap: "anywhere"
  }}>
          {changeable_without_restart}
        </div>}
    </div>;
};

Essas configurações estão disponíveis em [system.settings](/docs/pt-BR/reference/system-tables/settings) e são autogeradas a partir do [código-fonte](https://github.com/ClickHouse/ClickHouse/blob/master/src/Core/Settings.cpp).

<div id="load_balancing">
  ## load\_balancing
</div>

<SettingsInfoBlock type="LoadBalancing" default_value="random" />

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](/docs/pt-BR/reference/settings/session-settings/load-balancing#load_balancing-random) (por padrão)
* [Nearest hostname](/docs/pt-BR/reference/settings/session-settings/load-balancing#load_balancing-nearest_hostname)
* [Hostname levenshtein distance](/docs/pt-BR/reference/settings/session-settings/load-balancing#load_balancing-hostname_levenshtein_distance)
* [Hostname longest common prefix](/docs/pt-BR/reference/settings/session-settings/load-balancing#load_balancing-hostname_longest_common_prefix)
* [Hostname longest common suffix](/docs/pt-BR/reference/settings/session-settings/load-balancing#load_balancing-hostname_longest_common_suffix)
* [In order](/docs/pt-BR/reference/settings/session-settings/load-balancing#load_balancing-in_order)
* [First or random](/docs/pt-BR/reference/settings/session-settings/load-balancing#load_balancing-first_or_random)
* [Round robin](/docs/pt-BR/reference/settings/session-settings/load-balancing#load_balancing-round_robin)

Veja também:

* [distributed\_replica\_max\_ignored\_errors](/docs/pt-BR/reference/settings/session-settings/distributed-replica#distributed_replica_max_ignored_errors)

<div id="load_balancing-random">
  ### Random (padrão)
</div>

```sql theme={null}
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.

<div id="load_balancing-nearest_hostname">
  ### Hostname mais próximo
</div>

```sql theme={null}
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.

<div id="load_balancing-hostname_levenshtein_distance">
  ### Distância de Levenshtein do hostname
</div>

```sql theme={null}
load_balancing = hostname_levenshtein_distance
```

Assim como `nearest_hostname`, mas compara o hostname com base na [distância de Levenshtein](https://en.wikipedia.org/wiki/Levenshtein_distance). Por exemplo:

```text theme={null}
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
```

<div id="load_balancing-hostname_longest_common_prefix">
  ### Maior prefixo comum do hostname
</div>

```sql theme={null}
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`:

```text theme={null}
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`.

<div id="load_balancing-hostname_longest_common_suffix">
  ### Sufixo comum mais longo do hostname
</div>

```sql theme={null}
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`:

```text theme={null}
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`.

<div id="load_balancing-in_order">
  ### Na ordem definida
</div>

```sql theme={null}
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.

<div id="load_balancing-first_or_random">
  ### Primeiro ou aleatório
</div>

```sql theme={null}
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.

<div id="load_balancing-round_robin">
  ### Round Robin
</div>

```sql theme={null}
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).

<div id="load_balancing_first_offset">
  ## load\_balancing\_first\_offset
</div>

<SettingsInfoBlock type="UInt64" default_value="0" />

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