Passer au contenu principal

Paramètres de connexion

Pour une présentation détaillée de chaque option, avec les valeurs par défaut, les paramètres DSN, les bonnes pratiques et le dépannage, consultez la Référence de configuration.
Lors de l’ouverture d’une connexion, une structure Options peut être utilisée pour contrôler le comportement du client. Les paramètres suivants sont disponibles :
Exemple complet

TLS

À bas niveau, toutes les méthodes de connexion du client (DSN/OpenDB/Open) utilisent le paquet tls de Go pour établir une connexion sécurisée. Le client sait qu’il doit utiliser TLS si la structure Options contient un pointeur tls.Config non nul.
Exemple complet Cette configuration TLS.Config minimale suffit généralement pour se connecter au port natif sécurisé (généralement 9440) d’un serveur ClickHouse. Si le serveur ClickHouse ne dispose pas d’un certificat valide (expiré, avec un hostname incorrect, ou non signé par une autorité de certification racine reconnue publiquement), InsecureSkipVerify peut être défini sur true, mais cela est fortement déconseillé.
Exemple complet Si des paramètres TLS supplémentaires sont nécessaires, le code de l’application doit renseigner les champs souhaités dans la structure tls.Config. Cela peut inclure des suites de chiffrement spécifiques, l’utilisation forcée d’une version TLS particulière (comme 1.2 ou 1.3), l’ajout d’une chaîne de certificats d’une autorité de certification interne, l’ajout d’un certificat client (et d’une clé privée) si le serveur ClickHouse l’exige, ainsi que la plupart des autres options liées à une configuration de sécurité plus spécialisée.

Authentification

Indiquez une structure Auth dans les détails de connexion afin de définir un nom d’utilisateur et un mot de passe.
Exemple complet

Connexion à plusieurs nœuds

Plusieurs adresses peuvent être spécifiées dans la structure Addr.
Exemple complet Trois stratégies de connexion sont disponibles :
  • ConnOpenInOrder (par défaut) - les adresses sont utilisées dans l’ordre. Les adresses suivantes ne sont sollicitées qu’en cas d’échec de connexion aux adresses précédentes dans la liste. Il s’agit en pratique d’une stratégie de basculement.
  • ConnOpenRoundRobin - La charge est répartie entre les adresses selon une stratégie round-robin.
  • ConnOpenRandom - Un nœud est sélectionné aléatoirement dans la liste des adresses.
Ce comportement peut être contrôlé via l’option ConnOpenStrategy
Exemple complet

Pool de connexions

Le client maintient un pool de connexions et les réutilise entre les requêtes selon les besoins. À tout moment, le nombre de connexions utilisées ne dépassera pas MaxOpenConns, tandis que la taille maximale du pool est contrôlée par MaxIdleConns. Le client récupère une connexion dans le pool pour chaque exécution de requête, puis la remet dans le pool pour qu’elle soit réutilisée. Une connexion est utilisée pendant toute la durée de vie d’un batch et libérée lors de Send(). Rien ne garantit que la même connexion du pool sera utilisée pour les requêtes suivantes, sauf si l’utilisateur définit MaxOpenConns=1. Cela est rarement nécessaire, mais peut être requis lorsque des utilisateurs emploient des tables temporaires. Notez également que ConnMaxLifetime vaut par défaut 1 heure. Cela peut entraîner un déséquilibre de charge sur ClickHouse si des nœuds quittent le cluster. Cela peut se produire lorsqu’un nœud devient indisponible : les connexions se répartissent alors sur les autres nœuds. Par défaut, ces connexions persistent et ne sont pas renouvelées avant 1 heure, même si le nœud défaillant réintègre le cluster. Envisagez de réduire cette valeur en cas de forte charge. Le pool de connexions est activé pour Native (TCP) et pour le protocole HTTP.

Journalisation

Le client prend en charge la journalisation structurée via le paquet standard log/slog de Go, à l’aide du champ Logger dans Options. Les anciens champs Debug et Debugf sont obsolètes, mais fonctionnent toujours pour assurer la rétrocompatibilité (priorité : Debugf > Logger > no-op).
Vous pouvez également enrichir le logger avec un contexte applicatif :
Exemple complet

Compression

La prise en charge des méthodes de compression dépend du protocole sous-jacent utilisé. Pour le protocole natif, le client prend en charge la compression LZ4 et ZSTD. Celle-ci s’effectue uniquement au niveau des blocs. La compression peut être activée en incluant une configuration Compression dans la connexion.
Exemple complet D’autres techniques de compression sont disponibles lors de l’utilisation du transport HTTP : gzip, deflate et br. Consultez API Database/SQL - Compression pour plus d’informations.

TCP vs HTTP

Le transport se change via un simple paramètre de config — tout le reste de ce guide s’applique aux deux. Voici ce qui change : Pour basculer l’une ou l’autre API vers HTTP :
Dernière modification le 29 juin 2026