> ## 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.

# ajustes de sesión de load_balancing_*

> Ajustes de sesión de ClickHouse del grupo generado 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"
  }}>Predeterminado</div>
      <div style={{
    overflowWrap: "anywhere"
  }}>{default_value}</div>
      {changeable_without_restart && <div style={{
    fontWeight: 600,
    opacity: 0.72,
    marginInlineStart: "0.5rem"
  }}>
          Modificable sin reiniciar
        </div>}
      {changeable_without_restart && <div style={{
    overflowWrap: "anywhere"
  }}>
          {changeable_without_restart}
        </div>}
    </div>;
};

Estos ajustes están disponibles en [system.settings](/docs/es/reference/system-tables/settings) y se generan automáticamente a partir del [archivo fuente](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 el algoritmo de selección de réplicas que se utiliza para el procesamiento distribuido de consultas.

ClickHouse admite los siguientes algoritmos de selección de réplicas:

* [Random](/docs/es/reference/settings/session-settings/load-balancing#load_balancing-random) (de forma predeterminada)
* [Hostname más cercano](/docs/es/reference/settings/session-settings/load-balancing#load_balancing-nearest_hostname)
* [Distancia de Levenshtein del hostname](/docs/es/reference/settings/session-settings/load-balancing#load_balancing-hostname_levenshtein_distance)
* [Prefijo común más largo del hostname](/docs/es/reference/settings/session-settings/load-balancing#load_balancing-hostname_longest_common_prefix)
* [Sufijo común más largo del hostname](/docs/es/reference/settings/session-settings/load-balancing#load_balancing-hostname_longest_common_suffix)
* [In order](/docs/es/reference/settings/session-settings/load-balancing#load_balancing-in_order)
* [Primero o aleatorio](/docs/es/reference/settings/session-settings/load-balancing#load_balancing-first_or_random)
* [Round robin](/docs/es/reference/settings/session-settings/load-balancing#load_balancing-round_robin)

Véase también:

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

<div id="load_balancing-random">
  ### Random (por defecto)
</div>

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

Se cuenta el número de errores de cada réplica. La consulta se envía a la réplica con menos errores y, si hay varias, a cualquiera de ellas.
Desventajas: no se tiene en cuenta la proximidad del servidor; si las réplicas tienen datos distintos, también obtendrá datos distintos.

<div id="load_balancing-nearest_hostname">
  ### Hostname más cercano
</div>

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

El número de errores se contabiliza para cada réplica. Cada 5 minutos, el número de errores se divide de forma entera entre 2. Así, el número de errores se calcula para un periodo reciente con suavizado exponencial. Si hay una réplica con el número mínimo de errores (es decir, si se produjeron errores recientemente en las otras réplicas), la consulta se envía a esa réplica. Si hay varias réplicas con el mismo número mínimo de errores, la consulta se envía a la réplica cuyo hostname sea más similar al hostname del servidor en el archivo de configuración (según el número de caracteres distintos en posiciones idénticas, hasta la longitud mínima de ambos hostnames).

Por ejemplo, example01-01-1 y example01-01-2 difieren en una posición, mientras que example01-01-1 y example01-02-2 difieren en dos posiciones.
Este método puede parecer primitivo, pero no requiere datos externos sobre la topología de red y no compara direcciones IP, lo que sería complicado con nuestras direcciones IPv6.

Así, si hay réplicas equivalentes, se prefiere la más cercana por nombre.
También podemos asumir que, al enviar una consulta al mismo servidor, en ausencia de fallos, una consulta distribuida también irá a los mismos servidores. Por lo tanto, aunque se alojen datos distintos en las réplicas, la consulta devolverá en su mayor parte los mismos resultados.

<div id="load_balancing-hostname_levenshtein_distance">
  ### Distancia de Levenshtein del hostname
</div>

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

Igual que `nearest_hostname`, pero compara el hostname según la [distancia de Levenshtein](https://en.wikipedia.org/wiki/Levenshtein_distance). Por ejemplo:

```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">
  ### Prefijo común más largo del hostname
</div>

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

Igual que `nearest_hostname`, pero se prioriza la réplica cuyo hostname comparte el prefijo común más largo con el hostname local (cuanto más largo sea el prefijo común, mayor será la prioridad). A diferencia de `nearest_hostname`, que cuenta los caracteres diferentes posición por posición, esta estrategia no se ve afectada por hostnames cuyos segmentos numéricos tienen longitudes distintas. Por ejemplo, para el hostname local `sfe301`:

```text theme={null}
sfe301 sde301
1

sfe301 sfe10101
3

sfe301 sde505
1
```

Aquí se prefiere `sfe10101` porque comparte con `sfe301` el prefijo común más largo (`sfe`, longitud 3).

Las réplicas con la misma longitud de prefijo común se eligen al azar. En particular, cuando ninguna réplica comparte ningún prefijo con el hostname local (todas las longitudes de prefijo común son cero), esta estrategia se comporta exactamente igual que `random`.

<div id="load_balancing-hostname_longest_common_suffix">
  ### Sufijo común más largo del hostname
</div>

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

Igual que `hostname_longest_common_prefix`, pero se compara el *sufijo* común más largo en lugar del prefijo. Esto es útil cuando la identidad del centro de datos está codificada como un sufijo del hostname. Por ejemplo, para el hostname local `et46gtghn.qc.localdomain`:

```text theme={null}
et46gtghn.qc.localdomain tr676ddgh.td.localdomain
12

et46gtghn.qc.localdomain ab999.qc.localdomain
15
```

Aquí se prefiere `ab999.qc.localdomain` porque comparte el sufijo común más largo (`.qc.localdomain`, longitud 15) con `et46gtghn.qc.localdomain`.

Las réplicas con igual longitud del sufijo común se eligen al azar. En particular, cuando ninguna réplica comparte sufijo alguno con el hostname local (todas las longitudes del sufijo común son cero), esta estrategia se comporta exactamente igual que `random`.

<div id="load_balancing-in_order">
  ### In Order
</div>

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

Se accede a las réplicas con el mismo número de errores en el mismo orden en que se especifican en la configuración.
Este método es adecuado cuando se sabe exactamente qué réplica es preferible.

<div id="load_balancing-first_or_random">
  ### Primero o aleatorio
</div>

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

Este algoritmo elige la primera réplica del conjunto o una réplica aleatoria si la primera no está disponible. Es eficaz en topologías de replicación cruzada, pero no resulta útil en otras configuraciones.

El algoritmo `first_or_random` resuelve el problema del algoritmo `in_order`. Con `in_order`, si una réplica deja de estar disponible, la siguiente recibe una carga doble, mientras que las demás réplicas siguen manejando la cantidad habitual de tráfico. Al usar el algoritmo `first_or_random`, la carga se distribuye de forma uniforme entre las réplicas que siguen disponibles.

Es posible definir explícitamente cuál es la primera réplica mediante el ajuste `load_balancing_first_offset`. Esto ofrece más control para reequilibrar la carga de las consultas entre las réplicas.

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

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

Este algoritmo aplica una política round-robin entre réplicas con el mismo número de errores (solo se tienen en cuenta las consultas con la política `round_robin`).

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

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

Qué réplica debe recibir preferentemente una consulta cuando se usa la estrategia de balanceo de carga FIRST\_OR\_RANDOM.