Releases: tarantool/migrations
Releases · tarantool/migrations
1.0.2: rolling upgrade fix
Overview
This release fixes module work for rolling upgrade over existing cluster without state space (migrations 0.x or clean cluster).
Fixed
- State space bootstrap on cluster rolling upgrade (gh-77)
1.0.1: license introduction
Overview
This release adds license to the module.
Added
- BSD License.
1.0.0: per-replicaset state
Overview
This release introduces new approach to storing migration state: per-replicaset instead of clusterwide. New approach fixes the issue when new replicaset did not applied the migrations that are already applied on the remaining part of cluster.
To start using 1.0.0 instead of 0.x.x module on existing application, one must first call move_migrations_state
through HTTP or Lua API to move current cluster migration state from Cartridge clusterwide configuration to per-replicaset utility spaces. See README.md for upgrade and downgrade scenarios.
Fixed
- Migrations do not apply to newly added replica sets in the cluster (gh-65). Applied migration names are moved from the cluster-wide configuration to the space on each node.
Added
- An API for moving existing migration names from the cluster configuration to a space.
- API for getting applied migrations list for the cluster.
0.7.0: check enabled roles
0.6.0
0.5.0
0.4.2
Fixed
- Fetch schema from a replicaset leader to apply on the clusterwide config even when
migrations.up()
is called on a replica (gh-56). The local schema on the replica may be not the most actual due to replication lag. - Issue a warning into log when
register_sharding_key()
is called with{'bucket_id'}
key (gh-49). It is likely a mistake: sharding key is a set of fields, which are used to calculatebucket_id
, not thebucket_id
itself.