mirantis/dtr join¶

Add a new replica to an existing MSR cluster. Use SSH to log into any node that is already part of MKE.

Usage¶

docker run -it --rm \
  mirantis/dtr:2.8.13 join \
  --ucp-node <mke-node-name> \
  --ucp-insecure-tls

Description¶

This command creates a replica of an existing MSR on a node managed by Mirantis Kubernetes Engine (MKE).

For setting MSR for high-availability, create 3, 5, or 7 replicas of MSR.

Options¶

Option	Environment variable	Description
`--debug`	$DEBUG	Enable debug mode for additional logs.
`--existing-replica-id`	$MSR_REPLICA_ID	The ID of an existing MSR replica. To add, remove or modify MSR, you must connect to an existing healthy replica’s database.
`--help-extended`	$MSR_EXTENDED_HELP	Display extended help text for a given command.
`--replica-http-port`	$REPLICA_HTTP_PORT	The public HTTP port for the MSR replica. Default is `80`. This allows you to customize the HTTP port where users can reach MSR. Once users access the HTTP port, they are redirected to use an HTTPS connection, using the port specified with `--replica-https-port`. This port can also be used for unencrypted health checks.
`--replica-https-port`	$REPLICA_HTTPS_PORT	The public HTTPS port for the MSR replica. Default is `443`. This allows you to customize the HTTPS port where users can reach MSR. Each replica can use a different port.
`--replica-id`	$MSR_INSTALL_REPLICA_ID	Assign a 12-character hexadecimal ID to the MSR replica. Random by default.
`--replica-rethinkdb-cache-mb`	$RETHINKDB_CACHE_MB	The maximum amount of space in MB for RethinkDB in-memory cache used by the given replica. Default is auto. Auto is `(available_memory - 1024) / 2`. This config allows changing the RethinkDB cache usage per replica. You need to run it once per replica to change each one.
`--skip-network-test`	$MSR_SKIP_NETWORK_TEST	Don’t test if overlay networks are working correctly between MKE nodes. For high-availability, MSR creates an overlay network between MKE nodes and tests that it is working when joining replicas. Don’t use this option for production deployments.
`--ucp-ca`	$UCP_CA	Use a PEM-encoded TLS CA certificate for MKE. Download the MKE TLS CA certificate from `https://<mke-url>/ca`, and use `--ucp-ca "$(cat ca.pem)"`.
`--ucp-insecure-tls`	$UCP_INSECURE_TLS	Disable TLS verification for MKE. The installation uses TLS but always trusts the TLS certificate used by MKE, which can lead to MITM (man-in-the-middle) attacks. For production deployments, use `--ucp-ca "$(cat ca.pem)"` instead.
`--ucp-node`	$UCP_NODE	The hostname of the MKE node to use to deploy MSR. Random by default. You can find the hostnames of the nodes in the cluster in the MKE web interface, or by running docker node ls on a MKE manager node. Note that MKE and MSR must not be installed on the same node, and thus you should instead install MSR on worker nodes that will be managed by MKE.
`--ucp-password`	$UCP_PASSWORD	The MKE administrator password.
`--ucp-url`	$UCP_URL	The MKE URL including domain and port.
`--ucp-username`	$UCP_USERNAME	The MKE administrator username.
`--unsafe-join`	$MSR_UNSAFE_JOIN	Join a new replica even if the cluster is unhealthy.Joining replicas to an unhealthy MSR cluster leads to split-brain scenarios, and data loss. Don’t use this option for production deployments.
`--max-wait`	$MAX_WAIT	The maximum amount of time MSR allows an operation to complete within. This is frequently used to allocate more startup time to very large MSR databases. The value is a Golang duration string. For example, `"10m"` represents 10 minutes.