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

> Fournit un accès en temps réel aux tables d'une base de données sur un serveur ClickHouse distant en y acheminant les requêtes `SELECT` et `INSERT`.

# Remote

Les moteurs de base de données `Remote` et `RemoteSecure` fournissent un accès en temps réel aux tables d’une base de données située sur un serveur ClickHouse distant via le protocole TCP natif. Ils constituent les équivalents ClickHouse-à-ClickHouse des moteurs de base de données [`MySQL`](/docs/fr/reference/engines/database-engines/mysql) et [`PostgreSQL`](/docs/fr/reference/engines/database-engines/postgresql).

La liste des tables et leur structure sont récupérées à la demande depuis le serveur distant (via `SHOW TABLES` et `DESCRIBE TABLE` en interne), de sorte que la base de données reflète toujours l’état actuel du serveur distant. Chaque table est exposée comme un stockage [`Distributed`](/docs/fr/reference/engines/table-engines/special/distributed) sur un cluster ad hoc créé à partir des adresses fournies, qui transmet les requêtes `SELECT` et `INSERT` au serveur distant.

Cela est utile pour fédérer plusieurs clusters ClickHouse ou pour connecter un cluster ClickHouse plus important à `clickhouse-local` ou à un cluster plus petit.

<div id="creating-a-database">
  ## Création d’une base de données
</div>

<Tabs>
  <Tab title="Remote" id="remote">
    `Remote` se connecte via le port TCP non chiffré (`tcp_port`, `9000` par défaut) lorsque le port est omis.

    ```sql theme={null}
    CREATE DATABASE remote_db
    ENGINE = Remote('addresses_expr', 'database'[, 'user'[, 'password']]);
    ```
  </Tab>

  <Tab title="RemoteSecure" id="remote-secure">
    `RemoteSecure` se connecte via une connexion TLS sécurisée, en utilisant le port TCP sécurisé (`tcp_port_secure`, `9440` par défaut) lorsque le port est omis.

    ```sql theme={null}
    CREATE DATABASE remote_db
    ENGINE = RemoteSecure('addresses_expr', 'database'[, 'user'[, 'password']]);
    ```
  </Tab>
</Tabs>

**Paramètres du moteur**

* `addresses_expr` — Une adresse de serveur distant ou une expression générant plusieurs adresses, sous la forme `host` ou `host:port`. L’expression d’adresse prend en charge les mêmes motifs de globbing que la fonction de table [`remote`](/docs/fr/reference/functions/table-functions/remote) (par exemple, `{a,b,c}`, `{N..M}` et `{a|b}` pour développer plusieurs segments et répliques). Lorsque le port est omis, `Remote` utilise le port TCP non chiffré (`tcp_port`, `9000` par défaut) et `RemoteSecure` utilise le port TCP sécurisé (`tcp_port_secure`, `9440` par défaut).
* `database` — Le nom de la base de données sur le serveur distant.
* `user` — Le nom de l’utilisateur distant. Facultatif, par défaut : `default`.
* `password` — Le mot de passe de l’utilisateur distant. Facultatif, par défaut : vide.

Les adresses et les identifiants sont stockés dans la définition de la base de données, de sorte que le mot de passe est masqué dans `SHOW CREATE DATABASE`. Comme avec la fonction de table `remote`, une adresse pointant vers le serveur courant est traitée comme un segment local : `SELECT` et `INSERT` sont exécutés directement sous l’utilisateur courant — qui doit donc disposer des privilèges correspondants sur la base de données sous-jacente et ses tables — et les identifiants stockés ne sont utilisés que pour les serveurs réellement distants. Si la réplique locale d’un segment ne possède pas la base de données ou une table, la recherche bascule vers les répliques distantes du segment, comme le fait une table [`Distributed`](/docs/fr/reference/engines/table-engines/special/distributed). Dans ce cas, `SHOW CREATE TABLE` affiche les adresses de repli effectives (les répliques locales étant retirées de leurs segments) au lieu de celles configurées, de sorte que la définition de table `Remote(...)` générée reconstruit l’objet qui traite réellement les requêtes.

Lorsque l’expression d’adresse décrit plusieurs segments, chaque table proxy lit les données de tous ces segments, mais les métadonnées — la liste des tables et leur structure — proviennent d’un segment arbitraire (un segment local est privilégié), comme avec la fonction de table [`remote`](/docs/fr/reference/functions/table-functions/remote), afin qu’une énumération ne nécessite qu’une seule requête plutôt qu’une requête par segment. Les segments d’un cluster doivent donc proposer le même ensemble de tables ; une table présente sur certains segments seulement est exposée via un proxy dont les requêtes échouent alors sur les segments qui ne la possèdent pas. Un `INSERT` dans une table d’une base de données à plusieurs segments envoie chaque ligne vers un segment aléatoire (les tables proxy `Distributed` comportent une clé de sharding `rand()` implicite) ; pour fixer le segment d’une requête, définissez [`insert_shard_id`](/docs/fr/reference/settings/session-settings/insert#insert_shard_id). La clé implicite ne distribue que les lignes insérées : en lecture, la table se comporte comme une table `Distributed` sans clé de sharding (en particulier, [`optimize_skip_unused_shards`](/docs/fr/reference/settings/session-settings/optimize-skip#optimize_skip_unused_shards) et [`force_optimize_skip_unused_shards`](/docs/fr/reference/settings/session-settings/force-optimize#force_optimize_skip_unused_shards) ne la considèrent pas comme une clé d’élagage des segments). `SHOW CREATE TABLE` inclut cette clé dans la définition de table `Remote(...)` générée, de sorte qu’une table recréée à partir de celle-ci accepte également les requêtes `INSERT` sur plusieurs segments.

Les collections nommées sont également prises en charge :

```sql theme={null}
CREATE DATABASE remote_db
ENGINE = Remote(my_named_collection, database = 'default');
```

<div id="notes">
  ## Remarques
</div>

* Le moteur constitue une vue en lecture directe du serveur distant : les instructions DDL `CREATE TABLE`, `DROP TABLE`, `ALTER` et similaires appliquées à la base de données `Remote` ne sont pas prises en charge. Gérez directement le schéma sur le serveur distant.
* Les droits d'accès sont appliqués sur le serveur distant pour l'utilisateur distant configuré et, localement, par les privilèges habituels sur la base de données et ses tables.
* Une table d'un segment local que l'utilisateur n'est pas autorisé à voir est signalée comme absente plutôt que comme interdite. Une base de données `Remote` ne peut donc pas être utilisée pour sonder les noms des tables d'une base de données locale sur laquelle l'utilisateur ne dispose d'aucun privilège. Cela s'applique à l'énumération (`SHOW TABLES`, `EXISTS TABLE`) comme à la résolution (`DESCRIBE TABLE`, `SHOW CREATE TABLE`, `SELECT`), et une telle table n'est pas non plus accessible via les répliques distantes de son segment : le basculement décrit ci-dessus ne se produit que lorsque la réplique locale ne possède réellement pas la table.
* L'énumération des tables d'une base de données présente sur la réplique locale d'un segment inclut également les tables présentes uniquement sur les répliques distantes de ce segment, afin que `SHOW TABLES` et `system.tables` concordent avec `EXISTS TABLE`, `DESCRIBE TABLE` et `SELECT`, qui basculent vers ces répliques. Lorsqu'aucune réplique distante ne répond, la liste de la réplique locale est renvoyée telle quelle, car elle constitue déjà la réponse d'une réplique disponible.
* Si le serveur distant est indisponible, l'énumération de ses tables (`SHOW TABLES`, `system.tables`) renvoie l'erreur de connexion plutôt qu'une liste vide, tout comme `EXISTS TABLE` et `SELECT` sur la même base de données. Notez qu'un `SELECT` sur `system.tables` couvrant toutes les bases de données échoue également lorsqu'une telle base de données est inaccessible.
* Une base de données `Remote` peut pointer vers une autre base de données `Remote` sur le même serveur. L'énumération et la description des tables d'une telle chaîne ne nécessitent aucun privilège sur la base de données intermédiaire : elle ne contient ni données ni métadonnées propres, et chaque saut vérifie déjà les droits de l'appelant sur les objets qu'il relaie à son tour. En revanche, la lecture et l'écriture des données nécessitent `SELECT` / `INSERT` à chaque saut de la chaîne, car la requête est réellement exécutée sur la table de la base de données intermédiaire, exactement comme pour une table `Distributed` reposant sur une autre table `Distributed`. La règle de visibilité décrite ci-dessus s'applique à toute la chaîne : une table que la base de données intermédiaire masque à l'appelant n'est pas non plus accessible via les répliques distantes de la base de données externe. Si la base de données intermédiaire de la réplique locale ne peut pas atteindre sa propre cible, la réplique locale du segment externe ne peut pas répondre du tout — exactement comme si la réplique elle-même était hors service — et la base de données externe bascule vers les répliques distantes du segment.

<div id="example">
  ## Exemple
</div>

Créez une base de données `Remote` qui pointe vers la base de données `system` d’un serveur distant, puis lisez son contenu :

```sql theme={null}
CREATE DATABASE remote_system
ENGINE = Remote('127.0.0.1:9000', 'system', 'default', '');
```

```sql theme={null}
SHOW TABLES FROM remote_system LIKE 'one';
```

```text theme={null}
┌─name─┐
│ one  │
└──────┘
```

```sql theme={null}
SELECT * FROM remote_system.one;
```

```text theme={null}
┌─dummy─┐
│     0 │
└───────┘
```