0.1.27

Date: 29-04-2024

Tag: 0.1.27

Compatibility

VShard 0.1.27 is fully compatible with the previous VShard versions.

Functionality added or changed

• vshard.router.info() and vshard.storage.info() now expose identification_mode as it was specified in the config.
• vshard.storage.info() now contains uri field which contains the listen-URI of this instance and the user name which was used to configure the storage (#467).

Bugs fixed

• Router and storage, when had master = 'auto' in their configs, could be stuck unable to discover a new master when the old one would suddenly disappear without any info (tarantool/vshard-ee#4).

0.1.26

Date: 17-01-2024

Tag: 0.1.26

Compatibility

VShard 0.1.26 is fully compatible with the previous VShard versions.

Bugs fixed

• Fixed a bug in storage hot reload from earlier versions when named identification name_as_key was used in the config (gh-464).
• Fixed the instance URIs in logs containing invalid IPv6 addresses when IPv6 was used.

0.1.25

Date: 21-12-2023

Tag: 0.1.25

Compatibility

VShard 0.1.25 is fully compatible with the previous VShard versions.

Functionality added or changed

• Added support of master='auto' on the storage side. It makes the storages dynamically track who of them is the master (no election, only tracking and automatic role switch) (gh-429).
• Introduced rebalancer flag for replicas and replicasets to be able to choose manually who of them should run the rebalancer service (gh-432).
• Introduced rebalancer_mode which can be used to enforce manual or automatic rebalancer assignment, or turn the rebalancer off completely (gh-432).
• Config can be used with instance and replicaset names instead of UUIDs - for that there is a new option identification_mode. When specified as uuid_as_key (default) the behaviour is like in 0.1.24 and before. The value name_as_key unlocks the new behaviour (gh-426).

Bugs fixed

• Fixed a bug when bucket recovery and GC could sometimes do a bit more work than needed in case manual vshard.storage.bucket_send() was used (gh-434).
• Fixed a bug when vshard.storage.send() could false-positively fail in the end or the beginning of its work (gh-433).
• Fixed a bug that the router couldn't call storage functions implemented in C or having their Lua body stored in _func (gh-436).

0.1.24

Date: 24-05-2023

Tag: 0.1.24

Compatibility

VShard 0.1.24 is fully compatible with the previous VShard versions.

Functionality added or changed

• Added support of Tarantool 3.0 (gh-402).

Bugs fixed

• Fixed some router reload bugs (gh-141).
• Fixed a bug which could duplicate buckets, especially when
  vshard.storage.bucket_send() is used manually (gh-414).

0.1.23

Date: 05-04-2023

Tag: 0.1.23

Compatibility

VShard 0.1.23 is fully compatible with the previous VShard versions.

Functionality added or changed

• New key require('vshard')._VERSION stores the current VShard version as a
  string.

Bugs fixed

• Fixed a bug that deletion of any space didn't work if it wasn't truncated
  before (gh-400).

0.1.22

Date: 20-02-2023

Tag: 0.1.22

Compatibility

VShard 0.1.22 is fully compatible with the previous VShard versions.

Functionality added or changed

• A new trigger vshard.storage.on_bucket_event() to react on bucket events,
  such as move or GC (gh-372).

• vshard.router/storage.info() now accept an option {with_services = true}
  to get additional info about background services (such as discovery or
  rebalancer) that are working on the current instance (gh-107).

Bugs fixed

• Fixed a bug that the rebalancing could lead to inconsistency in buckets. In
  scope of the same bugfix all the updates in _bucket space are now severely
  restricted and validated (gh-377, gh-173).

• vshard.router/storage.cfg{} now can not be called from multiple fibers at
  the same time (gh-140).

• Fixed a bug that certain router error objects didn't have router_name field.

0.1.21

Date: 20-08-2022

Tag: 0.1.21

Compatibility

VShard 0.1.21 is fully compatible with the previous VShard versions.

Bugs fixed

• Fixed a bug that the rebalancing didn't work if the sharded spaces had
  unusual types like 'varbinary' (gh-327, gh-328).

• A pack of fixes for problems with accessing buckets on replicas. They were not
  properly protected against rebalancer and users could read too outdated data
  or even inconsistent data (gh-173).

• Fixed a bug that if vshard's connection netbox fibers were killed on router or
  storage, the connection could be not re-established on some Tarantool versions
  making the peer inaccessible from the given node at all (gh-341).

0.1.20

Compatibility

VShard 0.1.20 is fully compatible with the previous VShard versions. But since
this release VShard supports only Tarantool >= 1.10.1.

Functionality added or changed

• The configuration option collect_lua_garbage is deprecated. Now it doesn't
  do anything except printing a warning in the logs that it should not be used.

• The router now supports msgpack.object feature. It can be passed to all
  vshard.router.call...() and .map_call...() functions. They can also accept
  the netbox option return_raw to get an msgpack object in return (gh-312).

• The URIs in the config now support everything what can be passed to
  box.cfg.listen and netbox.connect(): number, string, table. There is also
  a new config option - <replica_object>.listen. It can be used to setup
  listen on multiple ports on storages and for SSL in Tarantool Enterprise
  (gh-325).

Bugs fixed

• Fixed a bug when router could raise a Lua exception about vshard.error being
  not defined if a storage was disabled (implicitly or via
  vshard.storage.disable()).

• Fixed a bug when router could raise a Lua exception about master_uuid
  variable being not defined when master='auto' feature was used.

• Fixed a bug when usage of memtx_use_mvcc_engine option in box.cfg could
  make bucket garbage collector not work. As a result, rebalancing also could
  stop working and there could be 'garbage' and 'sent' buckets visible in
  the monitoring (gh-314).

0.1.19

Compatibility

Fully compatible with 0.1.18.

Bugs fixed

• is_async in vshard.router.call() and other vshard.router.call* functions such as callbro/callbre/etc didn't work on Tarantool >= 2.8.2 (gh-294).

Functionality added or changed

• Until vshard.storage.cfg() is finished and box.info.status is 'loading' or 'orhpan', most of vshard.storage.* functions will throw a special error (gh-123).
• New functions vshard.storage.enable() and vshard.storage.disable() to control when the storage can accept requests (gh-298).

0.1.18

Compatibility

Fully compatible with 0.1.17.

Bugs fixed

• During rebalancing, even if all went fine, there were messages on the storages like "Starting ... buckets recovery step". They are not printed anymore unless there are really bucket transfers which somewhy need a recovery (gh-274).
• vshard.storage.buckets_count() on replicas could return an outdated value (gh-276).

Functionality added or changed

• vshard.storage.bucket_recv() now returns a very detailed error when a tuple couldn't be inserted into a space due to any reason. It also works for the built-in rebalancer - these errors are logged so it becomes easy to locate the spaces and tuples incompatible between replicasets during rebalancing (gh-275).
• The router supports automatic master discovery. For that in the config for the needed replicasets need to specify master = 'auto' in their root and drop all master = ... from their replica configs (gh-75).