A Cortex may be quickly deployed using pre-built docker containers which are built with each Synapse release.
The Cortex docker container is configured to allocate all local storage within the directory
may be mapped in as a volume.
It is strongly recommended that production deployments specify a specific container version such as
to make version updates an opt-in behavior.
The following example docker-compose.yml file will execute a cortex with an external storage volume mapped and ports mapped to expose the Cortex:
services: core_000: environment: - SYN_LOG_LEVEL=DEBUG - SYN_CORTEX_AUTH_PASSWD=secret image: vertexproject/synapse-cortex:master ports: - 443:4443 - 27492:27492 volumes: - ./core_000:/vertex/storage version: '3'
SYN_CORTEX_AUTH_PASSWD environment variable or
auth:passwd key in
cell.yaml will initialize the password
root user. Additional custom Cortex configuration may be done via additional environment variables or
options within the
You can now connect to the Cortex using the
python -m synapse.tools.cmdr tcp://root:secret@localhost:27492
Configuring A Mirror¶
A Cortex mirror replicates an entire Cortex to another host allowing it to act as a parallel query execution engine or hot-spare. Mirrors may be created in “tree” configurations where one mirror is used to synchronize several downstream mirrors to offload replication load from the main Cortex. Additionally, Cortex mirrors support write-back, allowing the mirror to appear to be read-write by passing edits to the upstream Cortex and awaiting synchronization to apply the change locally.
To deploy a Cortex mirror, you must first ensure that the
nexuslog:en setting on your Cortex is enabled in
This is enabled by default, but may be disabled in some high-performance custom configurations. The initial state of a
mirror is created by creating a backup of the Cortex using the standard synapse service backup tool:
python -m synapse.tools.backup /path/to/cortex /path/to/mirror/cortex
A single backup may be copied multiple times to deploy several mirrors. Once the backup is created, edit the
of the new mirror to include a telepath URL to the upstream Cortex:
The telepath URL must contain a valid user/password with global admin priviledges on the upstream Cortex.
mirror option is configured, the new mirror Cortex may be deployed normally and will stay synchronized
in near real-time provided it can maintain the network link.
Configuring A Remote Axon¶
By default a Cortex will initialize a local Axon for general object / blob storage. This allows certain Cortex functionality to work without additional configuration. The local Axon is not exposed in a remote fashion.
An Axon can instead be deployed as a remote server (see Axon Operations) and the Cortex can be configured to be aware
of it, by specifying the Axon’s Telepath URL in the
axon configuration parameter (see Cortex Configuration Options).
For example, if the remote Axon is listening on port
27592, and has a service user
core00, then the
cell.yaml file could have the following configuration:
--- axon: tcp://core00:secret@<axon_host_ip>:27592 ...
For interacting with byte storage inside of Storm, see $lib.bytes for APIs related to interacting with the Axon.