Remote Tables and cluster()

A query can read tables of another Berserk cluster that your admins have connected as a remote site (Querying Other Clusters covers the setup). The query runs on your cluster; the remote reads its share of the data and sends back partial results, so aggregations, joins and every other operator work as they do on local tables.

Mapped remote tablesCopy Anchor Link

The usual way: an admin maps a remote table into your database under a local name, and you use that name as any table of your own.

union Logs, EuLogs
| summarize errors = countif(severity == "ERROR") by bin(timestamp, 5m)

A local table always wins over a remote table of the same name.

cluster()Copy Anchor Link

Where the admin allowed it for a site, a query can name any of the site's tables directly:

cluster('eu').database('logs').Logs
| where timestamp > ago(1h)
| count

• cluster('site') names a remote site as your cluster knows it, not a hostname.
• .database('name') is required, and names a database at the remote site.
• The reference names one table; patterns and union * stay on your own cluster.
• It does not count toward your query's own database, so it combines with local tables freely:

union Logs, cluster('eu').database('logs').Logs
| summarize count() by bin(timestamp, 1h)

A site whose registration does not allow cluster() refuses it with an error that names the site; its mapped tables still work.

AccessCopy Anchor Link

The remote decides which of its databases your cluster may read. A query that reaches a database the remote did not grant fails, naming the site and the database.