There was an idea. An idea to make Vitess self-reliant. An idea to get rid of the friction between Vitess and external fault-detection-and-repair tools. An idea that gave birth to VTOrc… Both VTOrc and Orchestrator are tools for managing MySQL instances. If I were to describe these tools using a metaphor, I would say that they are kinda like the monitor of a class of students. They are responsible for keeping the MySQL instances in check and fixing them up in case they misbehave, just like how a monitor ensures that no mischief happens in the classroom.

Update June 12, 2023: This component has been deprecated in v17 and will be removed in v18! We recommend that you instead use VTOrc with the semi_sync durability policy. Introduction # MySQL group replication is a new replication mechanism that was released in 2016. Group replication involves establishing a group of nodes that are coordinated automatically via Group Communication System (GCS) protocols, an implementation of Paxos. For a transaction to commit, a majority of the group has to agree on the order of a given transaction in the global sequence of transactions.

We are pleased to announce the general availability of Vitess 14. Major Themes # In this new release, major improvements have been made in several areas of Vitess, including usability and reliability. Online DDL is now GA. Gen4 planner is the new default planner. VTAdmin and VTOrc are officially in beta with Vitess 14. Usability # Command-Line Syntax Deprecation # This release marks the beginning of Vitess standardizing its command-line and flags syntax.

Kubecon+CloudNativeCon EU 2022 # When: May 16-20 Who: Deepthi Sigireddi, Harshit Gangal, Manan Gupta What: Vitess project booth, maintainer talk, office hours Event Details # May 16-17 were co-located events. We were there for the main conference which was May 18-20. There were 7000+ attendees. The Vitess team were attending in their capacity as project maintainers to staff a booth in the Project Pavilion, hold office hours and to give a talk.

Vitess supports managed, non-blocking schema migrations based on VReplication, aptly named vitess migrations. Vitess migrations are powerful, revertible, and failure agnostic. They take an asynchronous approach, which is more lightweight on the database server. The asynchronous approach comes with an implementation challenge: how to cut-over with minimal impact to the user/app and risk free of data loss. In this post we take a deep dive into the cut-over logic used in vitess migrations.

The Vitess maintainers are pleased to announce the general availability of Vitess 13. Major Themes # In this release, Vitess maintainers have made significant progress in several areas, including query serving and cluster management. Compatibility # This release comes with major compatibility improvements. We added support for a large number of character sets and improved our evaluation engine to perform more evaluations at the VTGate level. Gen4 planner is no longer experimental and we have used it to add support for a number of previously unsupported complex queries.

The Vitess maintainers are pleased to announce the general availability of Vitess 13. Major Themes # In this release, Vitess maintainers have made significant progress in several areas, including query serving and cluster management. Compatibility # This release comes with major compatibility improvements. We added support for a large number of character sets and improved our evaluation engine to perform more evaluations at the VTGate level. Gen4 planner is no longer experimental and we have used it to add support for a number of previously unsupported complex queries.

What is Schema Tracking? # In a distributed relational database system, like Vitess, a central component is responsible for serving queries across multiple shards. For Vitess, it is VTGate. One of the challenges this component faces is being aware of the underlying SQL schema being used. This awareness facilitates query planning. Table schemas are stored in MySQL’s information_schema, meaning that they are located in a VTTablet’s MySQL instance and not in VTGate.

Background # A critical vulnerability CVE-2021-44228 in the Apache Log4j logging library was disclosed on Dec 9. The project provided release 2.15.0 with a patch that mitigates the impact of this CVE. It was quickly found that the initial patch was insufficient, and an additional CVE CVE-2021-45046 followed. This has been fixed in release 2.16.0. Who is affected? # The bulk of vitess code is in golang, and is unaffected by these vulnerabilities.

Past - Frameworks without scale # Over the past couple of decades, there has been a steady rise in the complexity of the development stacks that the developers across the globe have been using. The web has advanced from being just HTML files, to also include CSS and JavaScript with their own multitudes of frameworks like Redwood, Next.js, and Angular, among many others. The number of library dependencies that each project has has also shot up, leading to package managers like npm gaining popularity.