ajustes de sesión de load_balancing_* - ClickHouse Documentation

Estos ajustes están disponibles en system.settings y se generan automáticamente a partir del archivo fuente.

load_balancing

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:

Véase también:

distributed_replica_max_ignored_errors

Random (por defecto)

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.

Hostname más cercano

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.

Distancia de Levenshtein del hostname

load_balancing = hostname_levenshtein_distance

Igual que nearest_hostname, pero compara el hostname según la distancia de Levenshtein. Por ejemplo:

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

Prefijo común más largo del hostname

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:

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.

Sufijo común más largo del hostname

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:

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.

In Order

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.

Primero o aleatorio

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.

Round Robin

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

load_balancing_first_offset

Qué réplica debe recibir preferentemente una consulta cuando se usa la estrategia de balanceo de carga FIRST_OR_RANDOM.

​load_balancing

​Random (por defecto)

​Hostname más cercano

​Distancia de Levenshtein del hostname

​Prefijo común más largo del hostname

​Sufijo común más largo del hostname

​In Order

​Primero o aleatorio

​Round Robin

​load_balancing_first_offset