Managing replica sets
$ tt replicaset COMMAND {APPLICATION[:APP_INSTANCE] | URI} [OPTIONS ...]
# or
$ tt rs COMMAND {APPLICATION[:APP_INSTANCE] | URI} [OPTIONS ...]
tt replicaset
(or tt rs
) manages a Tarantool replica set.
COMMAND
is one of the following:
$ tt replicaset status {APPLICATION[:APP_INSTANCE] | URI} [OPTIONS ...]
# or
$ tt rs status {APPLICATION[:APP_INSTANCE] | URI} [OPTIONS ...]
tt replicaset status
(tt rs status
) shows the current status of a replica set.
To view the status of all replica sets of an application in the current tt
environment, run tt replicaset status
with the application name:
$ tt replicaset status myapp
To view the status of a single replica set of an application, run tt replicaset status
with a name or a URI of an instance from this replica set:
$ tt replicaset status myapp:storage-001-a
For a replica outside the current tt
environment, specify its URI and access credentials:
$ tt replicaset status 192.168.10.10:3301 -u myuser -p p4$$w0rD
Learn about other ways to provide user credentials in Authentication.
$ tt replicaset promote {APPLICATION:APP_INSTANCE | URI} [OPTIONS ...]
# or
$ tt rs promote {APPLICATION:APP_INSTANCE | URI} [OPTIONS ...]
tt replicaset promote
(tt rs promote
) promotes the specified instance,
making it a leader of its replica set.
This command works on Tarantool clusters with a local YAML
configuration and Cartridge clusters.
Note
To promote an instance in a Tarantool cluster with a centralized configuration, use tt cluster replicaset promote.
tt replicaset promote
works on Tarantool clusters with local YAML configurations
with failover modes
off
, manual
, and election
.
In failover modes off
or manual
, this command updates the cluster
configuration file according to the specified arguments and reloads it:
off
failover mode: the command sets database.mode torw
on the specified instance.Important
If failover is
off
, the command doesn’t consider the modes of other replica set members, so there can be any number of read-write instances in one replica set.manual
failover mode: the command updates the leader option of the replica set configuration. Other instances of this replica set become read-only.
Example:
$ tt replicaset promote my-app:storage-001-a
If some members of the affected replica set are running outside the current tt
environment, tt replicaset promote
can’t ensure the configuration reload on
them and reports an error. You can skip this check by adding the -f
/--force
option:
$ tt replicaset promote my-app:storage-001-a --force
In the election
failover mode, tt replicaset promote
initiates the new leader
election by calling box.ctl.promote() on the specified instance. The
--timeout
option can be used to specify the election completion timeout:
$ tt replicaset promote my-app:storage-001-a --timeout=10
Important
The Tarantool Cartridge framework is deprecated and is not compatible with Tarantool 3.0 and later. This command is added for backward compatibility with earlier versions.
tt replicaset promote
promotes instances in Cartridge clusters as follows:
disabled
oreventual
failover mode: the command changes the instance failover priority.Important
In these cases, consistency is not guaranteed and replication conflicts may occur.
eventual
orraft
failover mode: the command callscartridge.failover_promote()
and waits until the instance transitions to the read-write mode. If the-f
/--force
option is specified, theforce_inconsistency
option of cartridge.failover_promote is set totrue
.
$ tt replicaset promote my-cartridge-app:storage-001-a --force
Learn more about Cartridge failover modes.
$ tt replicaset demote APPLICATION:APP_INSTANCE [OPTIONS ...]
# or
$ tt rs demote APPLICATION:APP_INSTANCE [OPTIONS ...]
tt replicaset demote
(tt rs demote
) demotes an instance in a Tarantool
cluster with a local YAML configuration.
Note
To demote an instance in a Tarantool cluster with a centralized configuration, use tt cluster replicaset demote.
tt replicaset demote
can demote instances in Tarantool clusters with local
YAML configurations with failover modes
off
and election
.
Note
In clusters with manual
failover mode, you can demote a read-write instance
by promoting a read-only instance from the same replica set with tt replicaset promote
.
In the off
failover mode, tt replicaset demote
sets the instance’s database.mode
to ro
and reloads the configuration.
Important
If failover is off
, the command doesn’t consider the modes of other
replica set members, so there can be any number of read-write instances in one replica set.
If some members of the affected replica set are running outside the current tt
environment, tt replicaset demote
can’t ensure the configuration reload on
them and reports an error. You can skip this check by adding the -f
/--force
option:
$ tt replicaset demote my-app:storage-001-a --force
In the election
failover mode, tt replicaset demote
initiates a leader
election in the replica set. The specified instance’s replication.election_mode
is changed to voter
for this election, which guarantees that another instance
is elected as a new replica set leader.
The --timeout
option can be used to specify the election completion timeout:
$ tt replicaset demote my-app:storage-001-a --timeout=10
$ tt replicaset expel APPLICATION:APP_INSTANCE [OPTIONS ...]
# or
$ tt rs expel APPLICATION[:APP_INSTANCE] [OPTIONS ...]
tt replicaset expel
(tt rs expel
) expels an instance from the cluster.
$ tt replicaset expel myapp:storage-001-b
The command supports the --config
, --cartridge
, and --custom
options
that force the use of a specific orchestrator.
To expel an instance from a Cartridge cluster:
$ tt replicaset expel my-cartridge-app:storage-001-b --cartridge
$ tt replicaset vshard COMMAND {APPLICATION[:APP_INSTANCE] | URI} [OPTIONS ...]
# or
$ tt rs vshard COMMAND {APPLICATION[:APP_INSTANCE] | URI} [OPTIONS ...]
# or
$ tt rs vs COMMAND {APPLICATION[:APP_INSTANCE] | URI} [OPTIONS ...]
tt replicaset vshard
(tt rs vs
) manages vshard in the cluster.
It has the following subcommands:
$ tt replicaset vshard bootstrap {APPLICATION[:APP_INSTANCE] | URI} [OPTIONS ...]
# or
$ tt rs vshard bootstrap {APPLICATION[:APP_INSTANCE] | URI} [OPTIONS ...]
# or
$ tt rs vs bootstrap {APPLICATION[:APP_INSTANCE] | URI} [OPTIONS ...]
tt replicaset vshard bootstrap
(tt rs vs bootstrap
) bootstraps vshard
in the cluster.
$ tt replicaset vshard bootstrap myapp
With a URI and credentials:
$ tt replicaset vshard bootstrap 192.168.10.10:3301 -u myuser -p p4$$w0rD
You can specify the application name or the name of any cluster instance. The command
automatically finds a vshard
router in the cluster and calls vshard.router.bootstrap() on it.
The command supports the --config
, --cartridge
, and --custom
options
that force the use of a specific orchestrator.
To bootstrap vshard
in a Cartridge cluster:
$ tt replicaset vshard bootstrap my-cartridge-app --cartridge
Important
The Tarantool Cartridge framework is deprecated and is not compatible with Tarantool 3.0 and later. This command is added for backward compatibility with earlier versions.
$ tt replicaset bootstrap APPLICATION[:APP_INSTANCE] [OPTIONS ...]
# or
$ tt rs bootstrap APPLICATION[:APP_INSTANCE] [OPTIONS ...]
tt replicaset bootstrap
(tt rs bootstrap
) bootstraps a Cartridge cluster or
an instance. The command works within the current tt
environment and uses
application and instance names.
Note
tt replicasets bootstrap
effectively duplicates two other commands:
- When called with an application name: tt cartridge replicasets setup
- When called with an instance name: tt cartridge replicasets join
To bootstrap the cartridge_app
application using its default replica sets file
replicasets.yml
:
$ tt replicaset bootstrap cartridge_app
To use another file with replica set configuration, provide a path to it in the --file
option:
$ tt replicaset bootstrap cartridge_app --file replicasets1.yml
To additionally bootstrap vshard after the cluster bootstrap, add --bootstrap-vshard
:
$ tt replicaset bootstrap --bootstrap-vshard cartridge_app
$ tt replicaset rebootstrap APPLICATION:APP_INSTANCE [-y | --yes]
# or
$ tt rs rebootstrap APPLICATION:APP_INSTANCE [-y | --yes]
tt replicaset rebootstrap
(tt rs rebootstrap
) rebootstraps an instance:
stops it, removes instance artifacts, starts it again.
To rebootstrap the storage-001
instance of the myapp
application:
$ tt replicaset rebootstrap myapp:storage-001
To automatically confirm reboostrap, add the -y
/--yes
option:
$ tt replicaset rebootstrap myapp:storage-001 -y
$ tt replicaset roles [add|remove] APPLICATION[:APP_INSTANCE] ROLE_NAME [OPTIONS ...]
# or
$ tt rs roles [add|remove] APPLICATION[:APP_INSTANCE] ROLE_NAME [OPTIONS ...]
tt replicaset roles
(tt rs roles
) manages application roles
in the cluster.
This command works on Tarantool clusters with a local YAML
configuration and Cartridge clusters. It has two subcommands:
add
adds a roleremove
removes a role
Note
To manage roles in a Tarantool cluster with a centralized configuration, use tt cluster replicaset roles.
When called on clusters with local YAML configurations, tt replicaset roles
subcommands add or remove the corresponding lines from the configuration file
and reload the configuration.
Use the --global
, --group
, --replicaset
, --instance
options to specify
the configuration scope to add or remove roles. For example, to add a role to
all instances in a replica set:
$ tt replicaset roles add my-app roles.my-role --replicaset storage-a
You can also manage roles of a specific instance by specifying its name after the application name:
$ tt replicaset roles add my-app:router-001 roles.my-role
To remove a role defined in the global configuration scope:
$ tt replicaset roles remove my-app roles.my-role --global
If some instances of the affected scope are running outside the current tt
environment, tt replicaset roles
can’t ensure the configuration reload on
them and reports an error. You can skip this check by adding the -f
/--force
option:
$ tt replicaset roles add my-app roles.my-role --replicaset storage-a --force
Important
The Tarantool Cartridge framework is deprecated and is not compatible with Tarantool 3.0 and later. This command is added for backward compatibility with earlier versions.
When called on Cartridge clusters, tt replicaset roles
subcommands add or remove
Cartridge cluster roles.
Cartridge cluster roles are defined per replica set. Thus, you can use the
--replicaset
and --group
options to define a role’s scope. In this case,
a group is a vshard group.
To add a role to a Cartridge cluster replica set:
$ tt replicaset roles add my-cartridge-app my-role --replicaset storage-001
To remove a role from a vshard group:
$ tt replicaset roles remove my-cartridge-app my-role --group cold-data
Learn more about Cartridge cluster roles.
You can specify the orchestrator to use for the application when calling tt replicaset
commands. The following options are available:
--config
for applications that use YAML cluster configuration (Tarantool 3.x or later).--cartridge
for Cartridge applications (Tarantool 2.x).--custom
for any other orchestrators used on Tarantool 2.x clusters.
$ tt replicaset status myapp --config
$ tt replicaset promote my-cartridge-app:storage-001-a --cartridge
If an actual orchestrator that the application uses does not match the specified option, an error is raised.
Use one of the following ways to pass the credentials of a Tarantool user when connecting to the instance by its URI:
The
-u
(--username
) and-p
(--password
) options:$ tt replicaset status 192.168.10.10:3301 -u myuser -p p4$$w0rD
The connection string:
$ tt replicaset status myuser:p4$$w0rD@192.168.10.10:3301
Environment variables
TT_CLI_USERNAME
andTT_CLI_PASSWORD
:$ export TT_CLI_USERNAME=myuser $ export TT_CLI_PASSWORD=p4$$w0rD $ tt replicaset status 192.168.10.10:3301
-
--bootstrap-vshard
¶
Applicable to:
bootstrap
Additionally bootstrap vshard when bootstrapping a Cartridge application.
-
--cartridge
¶
Force the Cartridge orchestrator for Tarantool 2.x clusters.
-
--config
¶
Force the YAML configuration orchestrator for Tarantool 3.0 or later clusters.
-
--custom
¶
Force a custom orchestrator for Tarantool 2.x clusters.
-
--file
STRING
¶ Applicable to:
bootstrap
A file with Cartridge replica sets configuration. Default:
instances.yml
in the application directory.See also: Bootstrapping a Cartridge cluster
-
-f
,
--force
¶
Applicable to:
promote
,demote
,roles
Skip operation on instances not running in the same environment.
-
-G
,
--global
¶
Applicable to:
roles
on Tarantool 3.x and laterApply the operation to the global configuration scope, that is, to all instances.
-
-g
,
--group
STRING
¶ Applicable to:
roles
A name of the configuration group to which the operation applies.
-
-i
,
--instance
STRING
¶ Applicable to:
roles
A name of the instance to which the operation applies. Not applicable to Cartridge clusters. Learn more in Managing roles in Cartridge clusters.
-
-r
,
--replicaset
STRING
¶ Applicable to:
bootstrap
,roles
A name of the replica set to which the operation applies.
See also: Bootstrapping an instance
-
-u
,
--username
STRING
¶ A Tarantool user for connecting to the instance using a URI.
-
-p
,
--password
STRING
¶ The user’s password.
-
--sslcertfile
STRING
¶ The path to an SSL certificate file for encrypted connections for the URI case.
-
--sslkeyfile
STRING
¶ The path to a private SSL key file for encrypted connections for the URI case.
-
--sslcafile
STRING
¶ The path to a trusted certificate authorities (CA) file for encrypted connections for the URI case.
-
--sslciphers
STRING
¶ The list of SSL cipher suites used for encrypted connections for the URI case, separated by colons (
:
).
-
--timeout
UINT
¶ Applicable to:
promote
,demote
,expel
,vshard
,bootstrap
The timeout for completing the operation, in seconds. Default:
3
forpromote
,demote
,expel
,roles
10
forvshard
andbootstrap
-
--with-integrity-check
STRING
¶ Enterprise Edition
This option is supported by the Enterprise Edition only.
Applicable to:
promote
,demote
,expel
,roles
Generate hashes and signatures for integrity checks.
-
-y
,
--yes
¶
Applicable to:
rebootstrap
Automatically confirm rebootstrap.