Considering Vitess for production

[Sheran Gunasekera]

Hello,

Given all that's been said about Vitess being used in production, I still get a lot of mixed messages. I'm at that stage now in my system where I am considering read shards. I don't really want to go down the rabbit hole where MySQL tuning is concerned and so I want to start using Vitess. My concern here is that I am going to bet a business on Vitess that has thousands of transactions per day. Can anyone give me a reason not to use Vitess in production?

Thanks,

Sheran

[Anthony Yeh]

Hi Sheran,

There was some outdated info in the main GitHub README. I've removed the old or redundant stuff, now that vitess.io is our recommended source. If you have any specifics on other mixed messages you're seeing, let us know and we can elaborate on them. In the meantime, I'll give you a rundown of what I think are the main points to be aware of when considering Vitess in production.

First, I want to clarify that Vitess doesn't take the place of "MySQL tuning", depending on how you define that. The overall performance, for example, is going to depend very strongly on how much you can squeeze out of the underlying mysqld instances to which Vitess sends queries. The main thing Vitess will do for you is help you keep both your application logic and cluster operations simple, while your underlying MySQL deployment becomes more and more complicated.

So is Vitess production-ready? Vitess has been running in production at YouTube for many years, so I'd say the core technology is well-tested. The question is whether our experience can be reproduced externally. We don't see any reason it can't, but we aren't the ones who can answer that question - someone besides us would have to speak up.

Putting on my best "external user" hat, here are the points I think are most relevant to someone besides us who is trying to run Vitess:

Stable versions: Vitess development moves very quickly, and it's not clear to an outsider which points in the commit history are considered stable. We plan to start making stable release cuts once a few currently-moving pieces are in place - namely MySQL 5.6 support, smarter planned failovers, and cloud backup/restore. As a first step, we've divorced some of our Docker images (vitess/bootstrap and vitess/lite) from the automated build process, so they are now built manually at a known-good point, and don't change with every push to GitHub master.

Support: Like any free, open-source project, we don't guarantee anything. However, there are ~10 people working on Vitess full-time, and we are enthusiastic about helping out on this mailing list as time permits. We work in the open so that others in the industry can benefit from and contribute to Vitess, so fostering the community is part of our mission.

Requests: If you run into a bug, or have a feature request, file an issue on GitHub. If it's something that affects us as well, we'll likely work on it. If it's a good use case, but we aren't motivated to work on it ourselves, we'll welcome contributions, and respond to questions from contributors as time permits.

Documentation: This is admittedly our weakest area, but recently we've made progress on the "getting started" docs precisely because people gave us feedback on their experiences with trying it. The more input we get about what needs attention next, the better we can prioritize our efforts.

Let us know if you have any further questions!

Anthony

--
You received this message because you are subscribed to the Google Groups "vitess" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vitess+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.