Skip to content

Releases: vitessio/vitess

Vitess v2.0.0-alpha2

28 Aug 20:07
@enisoc enisoc
v2.0.0-alpha2
b057b35
Compare
Choose a tag to compare
Vitess v2.0.0-alpha2 Pre-release
Pre-release

Changes since v2.0.0-alpha1

  • Fix for breaking API change in grpc-go (#1052).
Assets 2
Loading

Vitess v2.0.0-alpha1

25 Aug 20:17
@enisoc enisoc
v2.0.0-alpha1
20afe43
Compare
Choose a tag to compare
Vitess v2.0.0-alpha1 Pre-release
Pre-release

This is the first alpha cut for the 2.0.0 release.

Changes since 1.0

  • In addition to the manual deployment
    option, Vitess can now be scaled dynamically in any cloud platform supported
    by Kubernetes, including
    Google Container Engine and
    AWS.
  • Docker images available for both manual and cloud deployments:
  • Official client libraries for:
    • Java
    • Python
    • PHP
    • Go
    • NOTE: Error handling is still being refactored as of alpha1.
  • Using new gRPC framework built on HTTP/2.
    • For Vitess server-to-server communication.
    • For Java and Go client communication.
  • Underlying DB nodes can run either:
    • MariaDB 10.0, or
    • MySQL 5.6
  • Consistent datastore used for cluster management can be:
    • etcd 2.0
    • ZooKeeper
    • Pluggable interface available for adding more.
  • New responsive admin dashboard (on vtctld).
    • Client-side AngularJS app with Material Design.
  • Built-in Backup/Restore
    for disaster recovery and provisioning.
    • New replica instances automatically restore from latest backup, and then
      catch up to master.
    • Queries from the app are automatically routed only to healthy, caught-up
      replicas.
    • Restore mechanism is routinely exercised as part of normal provisioning,
      so you know it'll work when you really need it.
    • NOTE: Currently this requires a network mount. We plan to add plugins for
      direct access to blob stores like Google Cloud Storage and Amazon S3.
  • Streaming, filtered data copy for transparent dynamic resharding.
    • Resharding now requires no additional disk space on the source machine,
      so it works even when existing data fills up more than half of the largest
      available node size.
  • GTID-based MySQL failovers (also known as reparenting)
    allow old masters to be seamlessly reparented back into the replication stream
    as replicas.
    • This makes failover a routine, automated operation, allowing downtime-free
      workflows such as:
      • Reparent to another replica.
      • Upgrade the old master by restarting it.
      • Reparent to upgraded master.
      • Upgrade remaining replicas one at a time.
Assets 2
Loading