Managing replica sets

Displaying status of all replica sets

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

Displaying status of a single replica set

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.

Promoting in clusters with local YAML configurations

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 to rw 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

Promoting in Cartridge clusters

tt replicaset promote promotes instances in Cartridge clusters as follows:

• disabled or eventual failover mode: the command changes the instance failover priority.

  Important

  In these cases, consistency is not guaranteed and replication conflicts may occur.

• eventual or raft failover mode: the command calls cartridge.failover_promote() and waits until the instance transitions to the read-write mode. If the -f/--force option is specified, the force_inconsistency option of cartridge.failover_promote is set to true.

$ tt replicaset promote my-cartridge-app:storage-001-a --force

Learn more about Cartridge failover modes.

Demoting in clusters with local YAML configurations

tt replicaset demote can demote instances in Tarantool clusters with local YAML configurations with failover modes off and election.

In the off failover mode, tt replicaset demote sets the instance’s database.mode to ro and reloads the configuration.

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

vshard bootstrap

$ 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

Bootstrapping a Cartridge cluster

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

Bootstrapping an instance

When called with the instance name, tt replicaset bootstrap joins the instance to the replica set specified in the --replicaset option:

$ tt replicaset bootstrap --replicaset replicaset cartridge_app:instance1

Managing roles in clusters with local YAML configurations

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

Managing roles in Cartridge clusters

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.