Upgrade/downgrade a remote cluster #968
Assignees
Labels
feature
A new functionality
Comments
mandesero
added a commit
to mandesero/tt
that referenced
this issue
Nov 20, 2024
This patch adds the ability to update the schema on a remote replicaset. Part of tarantool#968
mandesero
added a commit
to mandesero/tt
that referenced
this issue
Nov 20, 2024
This patch adds the ability to update the schema on a remote replicaset. Part of tarantool#968
mandesero
added a commit
to mandesero/tt
that referenced
this issue
Nov 20, 2024
This patch adds the ability to update the schema on a remote replicaset. Part of tarantool#968
mandesero
added a commit
to mandesero/tt
that referenced
this issue
Nov 20, 2024
This patch adds the ability to update the schema on a remote replicaset. Closes tarantool#968
mandesero
added a commit
to mandesero/tt
that referenced
this issue
Nov 21, 2024
This patch adds the ability to update the schema on a remote replicaset. Closes tarantool#968
mandesero
added a commit
to mandesero/tt
that referenced
this issue
Nov 22, 2024
Closes tarantool#968 @TarantoolBot document Title: `tt replicaset downgrade` downgrades database schema. The `tt replicaset downgrade` command allows for a automate downgrade of each replicaset in a Tarantool cluster. The process is performed sequentially on the master instance and its replicas to ensure data consistency. Below are the steps involved: For Each Replicaset: - **On the Master Instance**: 1. Run the following commands in sequence to downgrade the schema and take a snapshot: ```lua box.schema.downgrade(<..version..>) box.snapshot() ``` - **On Each Replica**: 1. Wait for the replica to apply all transactions produced by the `box.schema.downgrade` command executed on the master. This is done by monitoring the vector clocks (vclock) to ensure synchronization. 2. Once the repica has caught up, run the following command to take a snapshot: ```lua box.snapshot() ``` > **Error Handling**: If any errors occur during the downgrade process, the operation will halt, and an error report will be generated. --- - Timeout for Synchronization Replicas will wait for synchronization for a maximum of `Timeout` seconds. The default timeout is set to 5 seconds, but this can be adjusted manually using the `--timeout` option. **Example:** ```bash $ tt replicaset downgrade [<APP_NAME> | <URI>] -v 3.0.0 ``` - Selecting Replicasets for Downgrade You can specify which replicaset(s) to downgrade by using the `--replicaset` or `-r` option to target specific replicaset names. **Example:** ```bash $ tt replicaset upgrade [<APP_NAME> | <URI>] -v 3.0.0 replicaset <RS_NAME_1> -r <RS_NAME_2> ... ``` This provides flexibility in downgrading only the desired parts of the cluster without affecting the entire system.
mandesero
added a commit
to mandesero/tt
that referenced
this issue
Nov 22, 2024
This patch adds the ability to update the schema on a remote replicaset. Part of tarantool#968
mandesero
added a commit
to mandesero/tt
that referenced
this issue
Nov 22, 2024
Closes tarantool#968 @TarantoolBot document Title: `tt replicaset downgrade` downgrades database schema. The `tt replicaset downgrade` command allows for a automate downgrade of each replicaset in a Tarantool cluster. The process is performed sequentially on the master instance and its replicas to ensure data consistency. Below are the steps involved: For Each Replicaset: - **On the Master Instance**: 1. Run the following commands in sequence to downgrade the schema and take a snapshot: ```lua box.schema.downgrade(<..version..>) box.snapshot() ``` - **On Each Replica**: 1. Wait for the replica to apply all transactions produced by the `box.schema.downgrade` command executed on the master. This is done by monitoring the vector clocks (vclock) to ensure synchronization. 2. Once the repica has caught up, run the following command to take a snapshot: ```lua box.snapshot() ``` > **Error Handling**: If any errors occur during the downgrade process, the operation will halt, and an error report will be generated. --- - Timeout for Synchronization Replicas will wait for synchronization for a maximum of `Timeout` seconds. The default timeout is set to 5 seconds, but this can be adjusted manually using the `--timeout` option. **Example:** ```bash $ tt replicaset downgrade [<APP_NAME> | <URI>] -v 3.0.0 ``` - Selecting Replicasets for Downgrade You can specify which replicaset(s) to downgrade by using the `--replicaset` or `-r` option to target specific replicaset names. **Example:** ```bash $ tt replicaset upgrade [<APP_NAME> | <URI>] -v 3.0.0 replicaset <RS_NAME_1> -r <RS_NAME_2> ... ``` This provides flexibility in downgrading only the desired parts of the cluster without affecting the entire system.
mandesero
added a commit
to mandesero/tt
that referenced
this issue
Nov 22, 2024
Closes tarantool#968 @TarantoolBot document Title: `tt replicaset downgrade` downgrades database schema. The `tt replicaset downgrade` command allows for a automate downgrade of each replicaset in a Tarantool cluster. The process is performed sequentially on the master instance and its replicas to ensure data consistency. Below are the steps involved: For Each Replicaset: - **On the Master Instance**: 1. Run the following commands in sequence to downgrade the schema and take a snapshot: ```lua box.schema.downgrade(<..version..>) box.snapshot() ``` - **On Each Replica**: 1. Wait for the replica to apply all transactions produced by the `box.schema.downgrade` command executed on the master. This is done by monitoring the vector clocks (vclock) to ensure synchronization. 2. Once the repica has caught up, run the following command to take a snapshot: ```lua box.snapshot() ``` > **Error Handling**: If any errors occur during the downgrade process, the operation will halt, and an error report will be generated. --- - Timeout for Synchronization Replicas will wait for synchronization for a maximum of `Timeout` seconds. The default timeout is set to 5 seconds, but this can be adjusted manually using the `--timeout` option. **Example:** ```bash $ tt replicaset downgrade [<APP_NAME> | <URI>] -v 3.0.0 ``` - Selecting Replicasets for Downgrade You can specify which replicaset(s) to downgrade by using the `--replicaset` or `-r` option to target specific replicaset names. **Example:** ```bash $ tt replicaset upgrade [<APP_NAME> | <URI>] -v 3.0.0 replicaset <RS_NAME_1> -r <RS_NAME_2> ... ``` This provides flexibility in downgrading only the desired parts of the cluster without affecting the entire system.
mandesero
added a commit
to mandesero/tt
that referenced
this issue
Nov 22, 2024
Closes tarantool#968 @TarantoolBot document Title: `tt replicaset downgrade` downgrades database schema. The `tt replicaset downgrade` command allows for a automate downgrade of each replicaset in a Tarantool cluster. The process is performed sequentially on the master instance and its replicas to ensure data consistency. Below are the steps involved: For Each Replicaset: - **On the Master Instance**: 1. Run the following commands in sequence to downgrade the schema and take a snapshot: ```lua box.schema.downgrade(<..version..>) box.snapshot() ``` - **On Each Replica**: 1. Wait for the replica to apply all transactions produced by the `box.schema.downgrade` command executed on the master. This is done by monitoring the vector clocks (vclock) to ensure synchronization. 2. Once the repica has caught up, run the following command to take a snapshot: ```lua box.snapshot() ``` > **Error Handling**: If any errors occur during the downgrade process, the operation will halt, and an error report will be generated. --- - Timeout for Synchronization Replicas will wait for synchronization for a maximum of `Timeout` seconds. The default timeout is set to 5 seconds, but this can be adjusted manually using the `--timeout` option. **Example:** ```bash $ tt replicaset downgrade [<APP_NAME> | <URI>] -v 3.0.0 ``` - Selecting Replicasets for Downgrade You can specify which replicaset(s) to downgrade by using the `--replicaset` or `-r` option to target specific replicaset names. **Example:** ```bash $ tt replicaset upgrade [<APP_NAME> | <URI>] -v 3.0.0 replicaset <RS_NAME_1> -r <RS_NAME_2> ... ``` This provides flexibility in downgrading only the desired parts of the cluster without affecting the entire system.
mandesero
added a commit
to mandesero/tt
that referenced
this issue
Nov 22, 2024
Closes tarantool#968 @TarantoolBot document Title: `tt replicaset downgrade` downgrades database schema. The `tt replicaset downgrade` command allows for a automate downgrade of each replicaset in a Tarantool cluster. The process is performed sequentially on the master instance and its replicas to ensure data consistency. Below are the steps involved: For Each Replicaset: - **On the Master Instance**: 1. Run the following commands in sequence to downgrade the schema and take a snapshot: ```lua box.schema.downgrade(<..version..>) box.snapshot() ``` - **On Each Replica**: 1. Wait for the replica to apply all transactions produced by the `box.schema.downgrade` command executed on the master. This is done by monitoring the vector clocks (vclock) to ensure synchronization. 2. Once the repica has caught up, run the following command to take a snapshot: ```lua box.snapshot() ``` > **Error Handling**: If any errors occur during the downgrade process, the operation will halt, and an error report will be generated. --- - Timeout for Synchronization Replicas will wait for synchronization for a maximum of `Timeout` seconds. The default timeout is set to 5 seconds, but this can be adjusted manually using the `--timeout` option. **Example:** ```bash $ tt replicaset downgrade [<APP_NAME> | <URI>] -v 3.0.0 ``` - Selecting Replicasets for Downgrade You can specify which replicaset(s) to downgrade by using the `--replicaset` or `-r` option to target specific replicaset names. **Example:** ```bash $ tt replicaset upgrade [<APP_NAME> | <URI>] -v 3.0.0 replicaset <RS_NAME_1> -r <RS_NAME_2> ... ``` This provides flexibility in downgrading only the desired parts of the cluster without affecting the entire system.
mandesero
added a commit
to mandesero/tt
that referenced
this issue
Nov 25, 2024
This patch adds the ability to update the schema on a remote replicaset. Part of tarantool#968
mandesero
added a commit
to mandesero/tt
that referenced
this issue
Nov 25, 2024
Part of tarantool#968 @TarantoolBot document Title: `tt replicaset upgrade` supports upgrade database schema on remote replica sets `tt replicaset upgrade` now allows upgrade database schema on remote replica sets within a Tarantool cluster. The feature enables to perform upgrades by targeting specific instances of each replica set. **Usage Example**: Cluster configuration: ``` • router-001 • router-001-a localhost:3305 rw • storage-001 • storage-001-a localhost:3301 rw • storage-001-b localhost:3302 read • storage-002 • storage-002-a localhost:3303 rw • storage-002-b localhost:3304 read ``` To update the schema across this cluster: 1. Update each replica set individually. 2. Select one instance from each replica set to run the command. **Commands**: ```bash $ tt replicaset upgrade tcp://client:secret@127.0.0.1:3301 • storage-001: ok $ tt replicaset upgrade tcp://client:secret@127.0.0.1:3304 • storage-002: ok $ tt replicaset upgrade tcp://client:secret@127.0.0.1:3305 • router-001: ok ```
mandesero
added a commit
to mandesero/tt
that referenced
this issue
Nov 26, 2024
Part of tarantool#968 @TarantoolBot document Title: `tt replicaset upgrade` supports upgrade database schema on remote replica sets `tt replicaset upgrade` now allows upgrade database schema on remote replica sets within a Tarantool cluster. The feature enables to perform upgrades by targeting specific instances of each replica set. **Usage Example**: Cluster configuration: ``` • router-001 • router-001-a localhost:3305 rw • storage-001 • storage-001-a localhost:3301 rw • storage-001-b localhost:3302 read • storage-002 • storage-002-a localhost:3303 rw • storage-002-b localhost:3304 read ``` To update the schema across this cluster: 1. Update each replica set individually. 2. Select one instance from each replica set to run the command. **Commands**: ```bash $ tt replicaset upgrade tcp://client:secret@127.0.0.1:3301 • storage-001: ok $ tt replicaset upgrade tcp://client:secret@127.0.0.1:3304 • storage-002: ok $ tt replicaset upgrade tcp://client:secret@127.0.0.1:3305 • router-001: ok ```
mandesero
added a commit
to mandesero/tt
that referenced
this issue
Nov 26, 2024
Part of tarantool#968 @TarantoolBot document Title: `tt replicaset upgrade` supports upgrade database schema on remote replica sets `tt replicaset upgrade` now allows upgrade database schema on remote replica sets within a Tarantool cluster. The feature enables to perform upgrades by targeting specific instances of each replica set. **Usage Example**: Cluster configuration: ``` • router-001 • router-001-a localhost:3305 rw • storage-001 • storage-001-a localhost:3301 rw • storage-001-b localhost:3302 read • storage-002 • storage-002-a localhost:3303 rw • storage-002-b localhost:3304 read ``` To update the schema across this cluster: 1. Update each replica set individually. 2. Select one instance from each replica set to run the command. **Commands**: ```bash $ tt replicaset upgrade tcp://client:secret@127.0.0.1:3301 • storage-001: ok $ tt replicaset upgrade tcp://client:secret@127.0.0.1:3304 • storage-002: ok $ tt replicaset upgrade tcp://client:secret@127.0.0.1:3305 • router-001: ok ```
mandesero
added a commit
to mandesero/tt
that referenced
this issue
Nov 26, 2024
Part of tarantool#968 @TarantoolBot document Title: `tt replicaset upgrade` supports upgrade database schema on remote replica sets `tt replicaset upgrade` now allows upgrade database schema on remote replica sets within a Tarantool cluster. The feature enables to perform upgrades by targeting specific instances of each replica set. **Usage Example**: Cluster configuration: ``` • router-001 • router-001-a localhost:3305 rw • storage-001 • storage-001-a localhost:3301 rw • storage-001-b localhost:3302 read • storage-002 • storage-002-a localhost:3303 rw • storage-002-b localhost:3304 read ``` To update the schema across this cluster: 1. Update each replica set individually. 2. Select one instance from each replica set to run the command. **Commands**: ```bash $ tt replicaset upgrade tcp://client:secret@127.0.0.1:3301 • storage-001: ok $ tt replicaset upgrade tcp://client:secret@127.0.0.1:3304 • storage-002: ok $ tt replicaset upgrade tcp://client:secret@127.0.0.1:3305 • router-001: ok ```
mandesero
added a commit
to mandesero/tt
that referenced
this issue
Nov 26, 2024
Part of tarantool#968 @TarantoolBot document Title: `tt replicaset upgrade` supports upgrade database schema on remote replica sets `tt replicaset upgrade` now allows upgrade database schema on remote replica sets within a Tarantool cluster. The feature enables to perform upgrades by targeting specific instances of each replica set. **Usage Example**: Cluster configuration: ``` • router-001 • router-001-a localhost:3305 rw • storage-001 • storage-001-a localhost:3301 rw • storage-001-b localhost:3302 read • storage-002 • storage-002-a localhost:3303 rw • storage-002-b localhost:3304 read ``` To update the schema across this cluster: 1. Update each replica set individually. 2. Select one instance from each replica set to run the command. **Commands**: ```bash $ tt replicaset upgrade tcp://client:secret@127.0.0.1:3301 • storage-001: ok $ tt replicaset upgrade tcp://client:secret@127.0.0.1:3304 • storage-002: ok $ tt replicaset upgrade tcp://client:secret@127.0.0.1:3305 • router-001: ok ```
mandesero
added a commit
to mandesero/tt
that referenced
this issue
Nov 27, 2024
Part of tarantool#968 @TarantoolBot document Title: `tt replicaset upgrade` supports upgrade database schema on remote replica sets `tt replicaset upgrade` now allows upgrade database schema on remote replica sets within a Tarantool cluster. The feature enables to perform upgrades by targeting specific instances of each replica set. **Usage Example**: Cluster configuration: ``` • router-001 • router-001-a localhost:3305 rw • storage-001 • storage-001-a localhost:3301 rw • storage-001-b localhost:3302 read • storage-002 • storage-002-a localhost:3303 rw • storage-002-b localhost:3304 read ``` To update the schema across this cluster: 1. Update each replica set individually. 2. Select one instance from each replica set to run the command. **Commands**: ```bash $ tt replicaset upgrade tcp://client:secret@127.0.0.1:3301 • storage-001: ok $ tt replicaset upgrade tcp://client:secret@127.0.0.1:3304 • storage-002: ok $ tt replicaset upgrade tcp://client:secret@127.0.0.1:3305 • router-001: ok ```
oleg-jukovec
pushed a commit
that referenced
this issue
Nov 27, 2024
Part of #968 @TarantoolBot document Title: `tt replicaset upgrade` supports upgrade database schema on remote replica sets `tt replicaset upgrade` now allows upgrade database schema on remote replica sets within a Tarantool cluster. The feature enables to perform upgrades by targeting specific instances of each replica set. **Usage Example**: Cluster configuration: ``` • router-001 • router-001-a localhost:3305 rw • storage-001 • storage-001-a localhost:3301 rw • storage-001-b localhost:3302 read • storage-002 • storage-002-a localhost:3303 rw • storage-002-b localhost:3304 read ``` To update the schema across this cluster: 1. Update each replica set individually. 2. Select one instance from each replica set to run the command. **Commands**: ```bash $ tt replicaset upgrade tcp://client:secret@127.0.0.1:3301 • storage-001: ok $ tt replicaset upgrade tcp://client:secret@127.0.0.1:3304 • storage-002: ok $ tt replicaset upgrade tcp://client:secret@127.0.0.1:3305 • router-001: ok ```
mandesero
added a commit
to mandesero/tt
that referenced
this issue
Nov 27, 2024
Closes tarantool#968 @TarantoolBot document Title: `tt replicaset downgrade` downgrades database schema. The `tt replicaset downgrade` command allows for a automate downgrade of each replicaset in a Tarantool cluster. The process is performed sequentially on the master instance and its replicas to ensure data consistency. Below are the steps involved: For Each Replicaset: - **On the Master Instance**: 1. Run the following commands in sequence to downgrade the schema and take a snapshot: ```lua box.schema.downgrade(<..version..>) box.snapshot() ``` - **On Each Replica**: 1. Wait for the replica to apply all transactions produced by the `box.schema.downgrade` command executed on the master. This is done by monitoring the vector clocks (vclock) to ensure synchronization. 2. Once the repica has caught up, run the following command to take a snapshot: ```lua box.snapshot() ``` > **Error Handling**: If any errors occur during the downgrade process, the operation will halt, and an error report will be generated. --- - Specify the schema version for downgrade The `tt replicaset downgrade` command requires specifying the target version for the schema downgrade. This version should be provided using the `--version` (or `-v`) option. The version must follow the `x.x.x` format, where `x` represents a numerical value. To view the list of available downgrade versions, execute the following command in Tarantool: ```lua box.schema.downgrade_versions() ``` **Example:** ```bash $ tt replicaset downgrade [<APP_NAME> | <URI>] --version 3.0.0 ``` - Timeout for Synchronization Replicas will wait for synchronization for a maximum of `Timeout` seconds. The default timeout is set to 5 seconds, but this can be adjusted manually using the `--timeout` option. **Example:** ```bash $ tt replicaset downgrade [<APP_NAME> | <URI>] -v 3.0.0 --timeout 10 ``` - Selecting Replicasets for Downgrade You can specify which replicaset(s) to downgrade by using the `--replicaset` or `-r` option to target specific replicaset names. **Example:** ```bash $ tt replicaset downgrade [<APP_NAME> | <URI>] -v 3.0.0 replicaset <RS_NAME_1> -r <RS_NAME_2> ... ``` This provides flexibility in downgrading only the desired parts of the cluster without affecting the entire system.
mandesero
added a commit
to mandesero/tt
that referenced
this issue
Nov 27, 2024
Closes tarantool#968 @TarantoolBot document Title: `tt replicaset downgrade` downgrades database schema. The `tt replicaset downgrade` command allows for a automate downgrade of each replicaset in a Tarantool cluster. The process is performed sequentially on the master instance and its replicas to ensure data consistency. Below are the steps involved: For Each Replicaset: - **On the Master Instance**: 1. Run the following commands in sequence to downgrade the schema and take a snapshot: ```lua box.schema.downgrade(<..version..>) box.snapshot() ``` - **On Each Replica**: 1. Wait for the replica to apply all transactions produced by the `box.schema.downgrade` command executed on the master. This is done by monitoring the vector clocks (vclock) to ensure synchronization. 2. Once the repica has caught up, run the following command to take a snapshot: ```lua box.snapshot() ``` > **Error Handling**: If any errors occur during the downgrade process, the operation will halt, and an error report will be generated. --- - Specify the schema version for downgrade The `tt replicaset downgrade` command requires specifying the target version for the schema downgrade. This version should be provided using the `--version` (or `-v`) option. The version must follow the `x.x.x` format, where `x` represents a numerical value. To view the list of available downgrade versions, execute the following command in Tarantool: ```lua box.schema.downgrade_versions() ``` **Example:** ```bash $ tt replicaset downgrade [<APP_NAME> | <URI>] --version 3.0.0 ``` - Timeout for Synchronization Replicas will wait for synchronization for a maximum of `Timeout` seconds. The default timeout is set to 5 seconds, but this can be adjusted manually using the `--timeout` option. **Example:** ```bash $ tt replicaset downgrade [<APP_NAME> | <URI>] -v 3.0.0 --timeout 10 ``` - Selecting Replicasets for Downgrade You can specify which replicaset(s) to downgrade by using the `--replicaset` or `-r` option to target specific replicaset names. **Example:** ```bash $ tt replicaset downgrade [<APP_NAME> | <URI>] -v 3.0.0 replicaset <RS_NAME_1> -r <RS_NAME_2> ... ``` This provides flexibility in downgrading only the desired parts of the cluster without affecting the entire system.
mandesero
added a commit
to mandesero/tt
that referenced
this issue
Nov 27, 2024
Closes tarantool#968 @TarantoolBot document Title: `tt replicaset downgrade` downgrades database schema. The `tt replicaset downgrade` command allows for a automate downgrade of each replicaset in a Tarantool cluster. The process is performed sequentially on the master instance and its replicas to ensure data consistency. Below are the steps involved: For Each Replicaset: - **On the Master Instance**: 1. Run the following commands in sequence to downgrade the schema and take a snapshot: ```lua box.schema.downgrade(<..version..>) box.snapshot() ``` - **On Each Replica**: 1. Wait for the replica to apply all transactions produced by the `box.schema.downgrade` command executed on the master. This is done by monitoring the vector clocks (vclock) to ensure synchronization. 2. Once the repica has caught up, run the following command to take a snapshot: ```lua box.snapshot() ``` > **Error Handling**: If any errors occur during the downgrade process, the operation will halt, and an error report will be generated. --- - Specify the schema version for downgrade The `tt replicaset downgrade` command requires specifying the target version for the schema downgrade. This version should be provided using the `--version` (or `-v`) option. The version must follow the `x.x.x` format, where `x` represents a numerical value. To view the list of available downgrade versions, execute the following command in Tarantool: ```lua box.schema.downgrade_versions() ``` **Example:** ```bash $ tt replicaset downgrade [<APP_NAME> | <URI>] --version 3.0.0 ``` - Timeout for Synchronization Replicas will wait for synchronization for a maximum of `Timeout` seconds. The default timeout is set to 5 seconds, but this can be adjusted manually using the `--timeout` option. **Example:** ```bash $ tt replicaset downgrade [<APP_NAME> | <URI>] -v 3.0.0 --timeout 10 ``` - Selecting Replicasets for Downgrade You can specify which replicaset(s) to downgrade by using the `--replicaset` or `-r` option to target specific replicaset names. **Example:** ```bash $ tt replicaset downgrade [<APP_NAME> | <URI>] -v 3.0.0 replicaset <RS_NAME_1> -r <RS_NAME_2> ... ``` This provides flexibility in downgrading only the desired parts of the cluster without affecting the entire system.
mandesero
added a commit
to mandesero/tt
that referenced
this issue
Nov 27, 2024
Closes tarantool#968 @TarantoolBot document Title: `tt replicaset downgrade` downgrades database schema. The `tt replicaset downgrade` command allows for a automate downgrade of each replicaset in a Tarantool cluster. The process is performed sequentially on the master instance and its replicas to ensure data consistency. Below are the steps involved: For Each Replicaset: - **On the Master Instance**: 1. Run the following commands in sequence to downgrade the schema and take a snapshot: ```lua box.schema.downgrade(<..version..>) box.snapshot() ``` - **On Each Replica**: 1. Wait for the replica to apply all transactions produced by the `box.schema.downgrade` command executed on the master. This is done by monitoring the vector clocks (vclock) to ensure synchronization. 2. Once the repica has caught up, run the following command to take a snapshot: ```lua box.snapshot() ``` > **Error Handling**: If any errors occur during the downgrade process, the operation will halt, and an error report will be generated. --- - Specify the schema version for downgrade The `tt replicaset downgrade` command requires specifying the target version for the schema downgrade. This version should be provided using the `--version` (or `-v`) option. The version must follow the `x.x.x` format, where `x` represents a numerical value. To view the list of available downgrade versions, execute the following command in Tarantool: ```lua box.schema.downgrade_versions() ``` **Example:** ```bash $ tt replicaset downgrade [<APP_NAME> | <URI>] --version 3.0.0 ``` - Timeout for Synchronization Replicas will wait for synchronization for a maximum of `Timeout` seconds. The default timeout is set to 5 seconds, but this can be adjusted manually using the `--timeout` option. **Example:** ```bash $ tt replicaset downgrade [<APP_NAME> | <URI>] -v 3.0.0 --timeout 10 ``` - Selecting Replicasets for Downgrade You can specify which replicaset(s) to downgrade by using the `--replicaset` or `-r` option to target specific replicaset names. **Example:** ```bash $ tt replicaset downgrade [<APP_NAME> | <URI>] -v 3.0.0 replicaset <RS_NAME_1> -r <RS_NAME_2> ... ``` This provides flexibility in downgrading only the desired parts of the cluster without affecting the entire system.
mandesero
added a commit
to mandesero/tt
that referenced
this issue
Nov 27, 2024
Closes tarantool#968 @TarantoolBot document Title: `tt replicaset downgrade` downgrades database schema. The `tt replicaset downgrade` command allows for a automate downgrade of each replicaset in a Tarantool cluster. The process is performed sequentially on the master instance and its replicas to ensure data consistency. Below are the steps involved: For Each Replicaset: - **On the Master Instance**: 1. Run the following commands in sequence to downgrade the schema and take a snapshot: ```lua box.schema.downgrade(<..version..>) box.snapshot() ``` - **On Each Replica**: 1. Wait for the replica to apply all transactions produced by the `box.schema.downgrade` command executed on the master. This is done by monitoring the vector clocks (vclock) to ensure synchronization. 2. Once the repica has caught up, run the following command to take a snapshot: ```lua box.snapshot() ``` > **Error Handling**: If any errors occur during the downgrade process, the operation will halt, and an error report will be generated. --- - Specify the schema version for downgrade The `tt replicaset downgrade` command requires specifying the target version for the schema downgrade. This version should be provided using the `--version` (or `-v`) option. The version must follow the `x.x.x` format, where `x` represents a numerical value. To view the list of available downgrade versions, execute the following command in Tarantool: ```lua box.schema.downgrade_versions() ``` **Example:** ```bash $ tt replicaset downgrade [<APP_NAME> | <URI>] --version 3.0.0 ``` - Timeout for Synchronization Replicas will wait for synchronization for a maximum of `Timeout` seconds. The default timeout is set to 5 seconds, but this can be adjusted manually using the `--timeout` option. **Example:** ```bash $ tt replicaset downgrade [<APP_NAME> | <URI>] -v 3.0.0 --timeout 10 ``` - Selecting Replicasets for Downgrade You can specify which replicaset(s) to downgrade by using the `--replicaset` or `-r` option to target specific replicaset names. **Example:** ```bash $ tt replicaset downgrade [<APP_NAME> | <URI>] -v 3.0.0 replicaset <RS_NAME_1> -r <RS_NAME_2> ... ``` This provides flexibility in downgrading only the desired parts of the cluster without affecting the entire system.
mandesero
added a commit
to mandesero/tt
that referenced
this issue
Nov 27, 2024
Closes tarantool#968 @TarantoolBot document Title: `tt replicaset downgrade` downgrades database schema. The `tt replicaset downgrade` command allows for a automate downgrade of each replicaset in a Tarantool cluster. The process is performed sequentially on the master instance and its replicas to ensure data consistency. Below are the steps involved: For Each Replicaset: - **On the Master Instance**: 1. Run the following commands in sequence to downgrade the schema and take a snapshot: ```lua box.schema.downgrade(<..version..>) box.snapshot() ``` - **On Each Replica**: 1. Wait for the replica to apply all transactions produced by the `box.schema.downgrade` command executed on the master. This is done by monitoring the vector clocks (vclock) to ensure synchronization. 2. Once the repica has caught up, run the following command to take a snapshot: ```lua box.snapshot() ``` > **Error Handling**: If any errors occur during the downgrade process, the operation will halt, and an error report will be generated. --- - Specify the schema version for downgrade The `tt replicaset downgrade` command requires specifying the target version for the schema downgrade. This version should be provided using the `--version` (or `-v`) option. The version must follow the `x.x.x` format, where `x` represents a numerical value. To view the list of available downgrade versions, execute the following command in Tarantool: ```lua box.schema.downgrade_versions() ``` **Example:** ```bash $ tt replicaset downgrade [<APP_NAME> | <URI>] --version 3.0.0 ``` - Timeout for Synchronization Replicas will wait for synchronization for a maximum of `Timeout` seconds. The default timeout is set to 5 seconds, but this can be adjusted manually using the `--timeout` option. **Example:** ```bash $ tt replicaset downgrade [<APP_NAME> | <URI>] -v 3.0.0 --timeout 10 ``` - Selecting Replicasets for Downgrade You can specify which replicaset(s) to downgrade by using the `--replicaset` or `-r` option to target specific replicaset names. **Example:** ```bash $ tt replicaset downgrade [<APP_NAME> | <URI>] -v 3.0.0 replicaset <RS_NAME_1> -r <RS_NAME_2> ... ``` This provides flexibility in downgrading only the desired parts of the cluster without affecting the entire system.
mandesero
added a commit
to mandesero/tt
that referenced
this issue
Nov 28, 2024
Closes tarantool#968 @TarantoolBot document Title: `tt replicaset downgrade` downgrades database schema. The `tt replicaset downgrade` command allows for a automate downgrade of each replicaset in a Tarantool cluster. The process is performed sequentially on the master instance and its replicas to ensure data consistency. Below are the steps involved: For Each Replicaset: - **On the Master Instance**: 1. Run the following commands in sequence to downgrade the schema and take a snapshot: ```lua box.schema.downgrade(<..version..>) box.snapshot() ``` - **On Each Replica**: 1. Wait for the replica to apply all transactions produced by the `box.schema.downgrade` command executed on the master. This is done by monitoring the vector clocks (vclock) to ensure synchronization. 2. Once the repica has caught up, run the following command to take a snapshot: ```lua box.snapshot() ``` > **Error Handling**: If any errors occur during the downgrade process, the operation will halt, and an error report will be generated. --- - Specify the schema version for downgrade The `tt replicaset downgrade` command requires specifying the target version for the schema downgrade. This version should be provided using the `--version` (or `-v`) option. The version must follow the `x.x.x` format, where `x` represents a numerical value. To view the list of available downgrade versions, execute the following command in Tarantool: ```lua box.schema.downgrade_versions() ``` **Example:** ```bash $ tt replicaset downgrade [<APP_NAME> | <URI>] --version 3.0.0 ``` - Timeout for Synchronization Replicas will wait for synchronization for a maximum of `Timeout` seconds. The default timeout is set to 5 seconds, but this can be adjusted manually using the `--timeout` option. **Example:** ```bash $ tt replicaset downgrade [<APP_NAME> | <URI>] -v 3.0.0 --timeout 10 ``` - Selecting Replicasets for Downgrade You can specify which replicaset(s) to downgrade by using the `--replicaset` or `-r` option to target specific replicaset names. **Example:** ```bash $ tt replicaset downgrade [<APP_NAME> | <URI>] -v 3.0.0 replicaset <RS_NAME_1> -r <RS_NAME_2> ... ``` This provides flexibility in downgrading only the desired parts of the cluster without affecting the entire system.
mandesero
added a commit
to mandesero/tt
that referenced
this issue
Nov 28, 2024
Closes tarantool#968 @TarantoolBot document Title: `tt replicaset downgrade` downgrades database schema. The `tt replicaset downgrade` command allows for a automate downgrade of each replicaset in a Tarantool cluster. The process is performed sequentially on the master instance and its replicas to ensure data consistency. Below are the steps involved: For Each Replicaset: - **On the Master Instance**: 1. Run the following commands in sequence to downgrade the schema and take a snapshot: ```lua box.schema.downgrade(<..version..>) box.snapshot() ``` - **On Each Replica**: 1. Wait for the replica to apply all transactions produced by the `box.schema.downgrade` command executed on the master. This is done by monitoring the vector clocks (vclock) to ensure synchronization. 2. Once the repica has caught up, run the following command to take a snapshot: ```lua box.snapshot() ``` > **Error Handling**: If any errors occur during the downgrade process, the operation will halt, and an error report will be generated. --- - Specify the schema version for downgrade The `tt replicaset downgrade` command requires specifying the target version for the schema downgrade. This version should be provided using the `--version` (or `-v`) option. The version must follow the `x.x.x` format, where `x` represents a numerical value. To view the list of available downgrade versions, execute the following command in Tarantool: ```lua box.schema.downgrade_versions() ``` **Example:** ```bash $ tt replicaset downgrade [<APP_NAME> | <URI>] --version 3.0.0 ``` - Timeout for Synchronization Replicas will wait for synchronization for a maximum of `Timeout` seconds. The default timeout is set to 5 seconds, but this can be adjusted manually using the `--timeout` option. **Example:** ```bash $ tt replicaset downgrade [<APP_NAME> | <URI>] -v 3.0.0 --timeout 10 ``` - Selecting Replicasets for Downgrade You can specify which replicaset(s) to downgrade by using the `--replicaset` or `-r` option to target specific replicaset names. **Example:** ```bash $ tt replicaset downgrade [<APP_NAME> | <URI>] -v 3.0.0 replicaset <RS_NAME_1> -r <RS_NAME_2> ... ``` This provides flexibility in downgrading only the desired parts of the cluster without affecting the entire system.
mandesero
added a commit
to mandesero/tt
that referenced
this issue
Nov 28, 2024
Closes tarantool#968 @TarantoolBot document Title: `tt replicaset downgrade` downgrades database schema. The `tt replicaset downgrade` command allows for a automate downgrade of each replicaset in a Tarantool cluster. The process is performed sequentially on the master instance and its replicas to ensure data consistency. Below are the steps involved: For Each Replicaset: - **On the Master Instance**: 1. Run the following commands in sequence to downgrade the schema and take a snapshot: ```lua box.schema.downgrade(<..version..>) box.snapshot() ``` - **On Each Replica**: 1. Wait for the replica to apply all transactions produced by the `box.schema.downgrade` command executed on the master. This is done by monitoring the vector clocks (vclock) to ensure synchronization. 2. Once the repica has caught up, run the following command to take a snapshot: ```lua box.snapshot() ``` > **Error Handling**: If any errors occur during the downgrade process, the operation will halt, and an error report will be generated. --- - Specify the schema version for downgrade The `tt replicaset downgrade` command requires specifying the target version for the schema downgrade. This version should be provided using the `--version` (or `-v`) option. The version must follow the `x.x.x` format, where `x` represents a numerical value. To view the list of available downgrade versions, execute the following command in Tarantool: ```lua box.schema.downgrade_versions() ``` **Example:** ```bash $ tt replicaset downgrade [<APP_NAME> | <URI>] --version 3.0.0 ``` - Timeout for Synchronization Replicas will wait for synchronization for a maximum of `Timeout` seconds. The default timeout is set to 5 seconds, but this can be adjusted manually using the `--timeout` option. **Example:** ```bash $ tt replicaset downgrade [<APP_NAME> | <URI>] -v 3.0.0 --timeout 10 ``` - Selecting Replicasets for Downgrade You can specify which replicaset(s) to downgrade by using the `--replicaset` or `-r` option to target specific replicaset names. **Example:** ```bash $ tt replicaset downgrade [<APP_NAME> | <URI>] -v 3.0.0 replicaset <RS_NAME_1> -r <RS_NAME_2> ... ``` This provides flexibility in downgrading only the desired parts of the cluster without affecting the entire system.
mandesero
added a commit
to mandesero/tt
that referenced
this issue
Nov 28, 2024
Closes tarantool#968 @TarantoolBot document Title: `tt replicaset downgrade` downgrades database schema. The `tt replicaset downgrade` command allows for a automate downgrade of each replicaset in a Tarantool cluster. The process is performed sequentially on the master instance and its replicas to ensure data consistency. Below are the steps involved: For Each Replicaset: - **On the Master Instance**: 1. Run the following commands in sequence to downgrade the schema and take a snapshot: ```lua box.schema.downgrade(<..version..>) box.snapshot() ``` - **On Each Replica**: 1. Wait for the replica to apply all transactions produced by the `box.schema.downgrade` command executed on the master. This is done by monitoring the vector clocks (vclock) to ensure synchronization. 2. Once the repica has caught up, run the following command to take a snapshot: ```lua box.snapshot() ``` > **Error Handling**: If any errors occur during the downgrade process, the operation will halt, and an error report will be generated. --- - Specify the schema version for downgrade The `tt replicaset downgrade` command requires specifying the target version for the schema downgrade. This version should be provided using the `--version` (or `-v`) option. The version must follow the `x.x.x` format, where `x` represents a numerical value. To view the list of available downgrade versions, execute the following command in Tarantool: ```lua box.schema.downgrade_versions() ``` **Example:** ```bash $ tt replicaset downgrade [<APP_NAME> | <URI>] --version 3.0.0 ``` - Timeout for Synchronization Replicas will wait for synchronization for a maximum of `Timeout` seconds. The default timeout is set to 5 seconds, but this can be adjusted manually using the `--timeout` option. **Example:** ```bash $ tt replicaset downgrade [<APP_NAME> | <URI>] -v 3.0.0 --timeout 10 ``` - Selecting Replicasets for Downgrade You can specify which replicaset(s) to downgrade by using the `--replicaset` or `-r` option to target specific replicaset names. **Example:** ```bash $ tt replicaset downgrade [<APP_NAME> | <URI>] -v 3.0.0 replicaset <RS_NAME_1> -r <RS_NAME_2> ... ``` This provides flexibility in downgrading only the desired parts of the cluster without affecting the entire system.
oleg-jukovec
pushed a commit
that referenced
this issue
Nov 29, 2024
Closes #968 @TarantoolBot document Title: `tt replicaset downgrade` downgrades database schema. The `tt replicaset downgrade` command allows for a automate downgrade of each replicaset in a Tarantool cluster. The process is performed sequentially on the master instance and its replicas to ensure data consistency. Below are the steps involved: For Each Replicaset: - **On the Master Instance**: 1. Run the following commands in sequence to downgrade the schema and take a snapshot: ```lua box.schema.downgrade(<..version..>) box.snapshot() ``` - **On Each Replica**: 1. Wait for the replica to apply all transactions produced by the `box.schema.downgrade` command executed on the master. This is done by monitoring the vector clocks (vclock) to ensure synchronization. 2. Once the repica has caught up, run the following command to take a snapshot: ```lua box.snapshot() ``` > **Error Handling**: If any errors occur during the downgrade process, the operation will halt, and an error report will be generated. --- - Specify the schema version for downgrade The `tt replicaset downgrade` command requires specifying the target version for the schema downgrade. This version should be provided using the `--version` (or `-v`) option. The version must follow the `x.x.x` format, where `x` represents a numerical value. To view the list of available downgrade versions, execute the following command in Tarantool: ```lua box.schema.downgrade_versions() ``` **Example:** ```bash $ tt replicaset downgrade [<APP_NAME> | <URI>] --version 3.0.0 ``` - Timeout for Synchronization Replicas will wait for synchronization for a maximum of `Timeout` seconds. The default timeout is set to 5 seconds, but this can be adjusted manually using the `--timeout` option. **Example:** ```bash $ tt replicaset downgrade [<APP_NAME> | <URI>] -v 3.0.0 --timeout 10 ``` - Selecting Replicasets for Downgrade You can specify which replicaset(s) to downgrade by using the `--replicaset` or `-r` option to target specific replicaset names. **Example:** ```bash $ tt replicaset downgrade [<APP_NAME> | <URI>] -v 3.0.0 replicaset <RS_NAME_1> -r <RS_NAME_2> ... ``` This provides flexibility in downgrading only the desired parts of the cluster without affecting the entire system.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Context
The new database upgrading/downgrading tool is proposed in #924 -- see more background context here.
Since I've filed this issue, I've consulted with @psergee and @oleg-jukovec and found that a support of remote instances requires some separate work. This is why the separate issue is created.
Proposal
Add some way to work with remote instances in upgrading/downgrading commands.
If it requires to write some file with URLs, logins, passwords -- OK. It does the job.
I think that the optimal solution would be extracting these URLs/logins/passwords from a cluster configuration written in the tarantool 3.x format.
It works even for upgrading from 1.10 to 2.11: we use the cluster configuration for
tt, while tarantool instances are configured on its own. (Moreover, in a future we may have a tooling that converts cartridge configuration to 3.x configuration and it would simplify the things.)Also tracked in TNTP-363
Part of TNTP-41
The text was updated successfully, but these errors were encountered: