RFC: Deprecate MariaDB Support in 2022 and Remove in 2023

[mattlord]

Proposal

Deprecate official MariaDB support in Vitess 14.0 (~June 2022) and remove it entirely in 16.0 (~Feb 2023). This gives Vitess users approximately 2 years where they can continue to use Vitess with MariaDB and offers adequate time to transition to MySQL 8 (MySQL 5.7 is currently scheduled for EOL in 2023).

Reasoning

Note: MySQL and Percona Server for MySQL are considered fully equivalent in Vitess.

The reasons for proposing this are as follows:

• Vitess only officially supports MariaDB 10.0-10.3 today
  • MariaDB 10.3 is already nearly 4 years old (10.7 is the latest) and MariaDB 10.3 will be EOL next year (2023)
• MariaDB is a hard fork of MySQL and 10.X is a very different database than MySQL 8.X (which is quickly becoming the default with Vitess)
  • Even though MariaDB has often been described as a "drop in replacement" for MySQL, this is not true today with MariaDB 10.7 and MySQL 8.0
  • MySQL and MariaDB are now properly treated as independent database products in various places and in more and more distros (e.g. Ubuntu which supports MySQL 8.0) as the two diverge more and more with each passing year; e.g. at Amazon Web Services where they support both MySQL and MariaDB separately in RDS, at Google Cloud Services where MariaDB is not supported in CloudSQL, along with other places like DB-Engines and among domain experts when comparing the two at a technical level regarding modern SQL support or overall compatibility
• Though there was some outreach from the MariaDB Foundation last year to get Vitess working with more recent versions of MariaDB, that effort seems to have been abandoned
• MariaDB's GTID implementation — which is NOT compatible with MySQL which uses auto generated UUIDs for the unique host identifier — uses domain_id and server_id together as the "unique" host identifier while every MariaDB instance defaults to 0-1 for its unique host identifier which is in NO way unique. MariaDB's GTID implementation also do not use sets (MySQL uses GTID_EXECUTED and GTID_PURGED sets), but only the last seen sequence value from the given host identifier (so e.g. 0-1:20000 vs 15b57a66-e10d-11eb-a4de-7499a366173e:1-20000 in MySQL) — so you have no way to know if two servers have executed the same full set of GTIDs or not and you cannot easily detect drift and ensure consistency and correctness. When you combine these two things, this is a big problem for Vitess, which relies on fairly complex replication topologies. This makes MariaDB unsafe to use with Vitess VReplication, and you will run into problems (surfaced duplicate GTIDs are the least of your problems, the worse issue is undetected drift and inconsistencies within a shard). This is hardly the only problem with MariaDB usage in Vitess, but I assert that this alone makes MariaDB an unsafe and unsuitable choice.

And most importantly:

• Vitess is not well tested on MariaDB today within the project nor the user base
  • There are no known Vitess users with MariaDB in production (please let us know if you do!)

Given all of this, it seems reasonable to discontinue spending the limited human and capital resources available to the Vitess project — which would otherwise go toward fixing bugs and adding features in Vitess — in trying to maintain official MariaDB support (at least for 10.4+) going forward.

⚠️ While we would not officially support MariaDB as a database within Vitess, we would still want to maintain a clear migration path into Vitess for existing MariaDB installations.

Feedback

Please note that we want to do what's best for the Vitess project and its community, so your input is crucial! This is a proposal, it is not an announcement of a decision that's been made. If you have any questions, concerns, or other feedback please let us know!

[mreschke]

I am currently building a large Vitess cluster in MariaDB 10.3. It will be in large scale production. Should I back out now? I didn't know it wasn't well tested. Your docs page lists NO "known issues" with MariaDB but does with MySQL, so I figured MariaDB was more supported.

[epyonavenger]

We're in a similar place to @mreschke, currently looking into building a Vitess cluster centered on MariaDB.

I do not trust Oracle to not ruin (or ruin further, depending on your stance regarding their stewardship) MySQL at some point, and so we've been focused on building things in/around MariaDB.

It's possible we could pivot to MySQL, but if we're dancing with big corporate gorillas, it's possible we'd want to re-evaluate.

[derekperkins]

@mreschke is MariaDB a hard requirement for you? Good point about the known issues, that's definitely due to lack of usage.

@epyonavenger how important is upgrading to newer versions past 10.3?

[epyonavenger]

@derekperkins I think as long as a version is still receiving updates and patches, it's probably ok. If it ever falls completely out of support, or stops working on our OSes, we'd run into trouble.

As far as I know, we don't have any hard dependencies on features of newer MariaDB, but I will double-check with that DBA team.

EDIT: Ah, ok, I'm not being clear here, let me outline a little more...

I feel like Vitess is likely to keep advancing (good!) and that often brings about new requirements and dependencies (also fine), so the only concern I'd have is that those don't conflict with the version of MariaDB that is supported, which if it is being patched and updated, should be ok, but if it were ever EoL-ed, we'd probably start seeing issues crop up.

Hopefully that's clearer.

[mattlord]

@epyonavenger then I would encourage you to use Percona Server for MySQL, which is fully compatible. MariaDB is simply a very different database than MySQL today.

@mreschke I think that you should take what was noted here into account, given that MariaDB 10.3 will be EOL next year and 10.4 does not work with Vitess today (for basic and critical things like PlannedReparentShard) and that MariaDB 10.7 is a drastically different database than MySQL 8 (where the Vitess project contributors spend a majority of their time when it comes to adding support for / leveraging database features). And that even with 10.3 there are major potential issues with MariaDB, e.g. its GTID implementation (which uses server_id and domain_id vs. UUIDs in MySQL) has no uniqueness property, which can cause havoc in large complex environments like Vitess (specifically around vreplication). And that other things in the ecosystem like the Vitess Operator for k8s do not officially support MariaDB.

I would encourage you both to think about your business needs and end goals. If Vitess may fit that well then I would focus your time and effort on leveraging Vitess and let it (vttablets) manage the backing database stores as much as possible (the more tightly they are coupled the better things will generally work).

And please keep in mind that Vitess is an open source (CNCF) project, so if you or other parties wanted to contribute to supporting MariaDB long term that would alter the calculus too. At the moment, however, attempting to do so would have a dramatic opportunity cost for every Vitess user, including yourselves, as supporting two different databases with each existing and new feature (both in Vitess and the database servers) would slow the project down dramatically w/o additional contributors helping to do so. That's what is driving this (difficult) decision today.

[epyonavenger]

@mattlord Looking into Percona is definitely an interesting idea, I'd have to look into how good of an open-source citizen they are, but it's hard to be worse than Oracle.

So far as the last paragraph goes, understanding that y'all are an open source project, I would think there'd be more interest in supporting MariaDB over MySQL, since Oracle is no great ally of the community. Then again, they do have bags of money to throw around, so if they're the ones funding the work (directly or indirectly), I can definitely understand why it'd fall one way vs. the other.

In any case, like I said, the Percona suggestion is an interesting one if folks are comfortable with that. Ideally, I like to have Plan A and Plan B, so being able to swap between Percona or MariaDB would be nice, but as you said, unless I'm willing and able to pony up the extra labor to support both, it is what it is.

I do appreciate the time taken to answer questions and offer suggestions though.

[derekperkins]

@epyonavenger FWIW, we've been running Percona for years and think it's great. They track Oracle MySQL exactly, contributing upstream patches where appropriate, and providing open source versions for many of the enterprise plugins, so if you don't like what Oracle is doing, then they aren't going to be significantly different. Personally, I think Oracle has felt the pressure from Postgres/Maria in 8.0 and have really stepped up the speed of feature releases, and I don't have any concerns for the long term viability of MySQL.

[epyonavenger]

@derekperkins I like what I'm seeing from Percona so far, so next thing will probably be deploying some test instances. As for Oracle, hard to be optimistic, given what happened to poor VirtualBox, but hey, you could be right. Sometimes villains get redemption arcs.

[mreschke]

@mattlord well said. You should definitely add a paragraph about this in your docs. Docs are misleading and they appear to say MariaDB is fully supported (as in preferred since MySQL lists "limitations"). At this point I have two options. A). Stick with Percona 8 and Vetiss and hope Oracle maintains good open stewardship, or B). Go with MariaDB and their sharding spider engine with MaxScale or ProxySQL. Though I'd like to think vitess does more than what spider+maxscale offers? Leaning more toward plan A at the moment, really want to give vitess a go.

[mreschke]

@derekperkins MariaDB is not a "hard" requirement. I simply prefer its openness and feature advancements over Oracles stewardship and history. Oracle is keeping features to EE only, although MariaDB with things like MaxScale are doing the same. I plan to give vitess a go with Percona 8.0 for our production prototype next month. I believe better upfront docs on your site about the stance on MaraDB would prevent newcomers a world of pain in the future. At least notes on how MySQL is preferred, better tested and supported etc...

[mattlord]

@mreschke and @epyonavenger I think you'll be quite happy with Percona Server for MySQL. Many of the largest sites/services/apps you use on a daily bases are using MySQL (Oracle and/or Percona): Twitter, Facebook, LinkedIn, Pinterest, Uber, Tesla, GM, Stripe, Shopify, Square, PayPal, AirBnB, Netflix, Disney, Hulu, Etsy, Ebay, Yelp, Workday, WeWork, most likely your bank unless you use DBS which is one of MariaDB's flagship customers, Lufthansa, United, New Relic, PagerDuty, SoundCloud, Booking.com, Orbitz, Zillow, Box, Dropbox, Roblox, Activision/Blizzard games, the network equipment you're going through (Cisco, F5, Juniper, etc), BBC, New York Times, and many other news orgs, the companies providing your cell phone services, to government services... to YouTube, and this very site that we're having this discussion on. I could go on all day. Whether you realize it or not, your business almost certainly already depends on MySQL (Oracle and/or Percona) from all of the products and services you rely on.

I have no interest to argue or quibble here, but I'll just say that I've been in this ecosystem for nearly 20 years (starting at MySQL AB in 2003) and suffice it to say I have a very different perspective on this matter than you have expressed here. 🙂

It sounds like you have an emotional disdain for Oracle Corporation, and that I can understand (although I don't believe the MySQL organization there deserves that). In that case Percona is exactly what you'd want as they are excellent open source citizens that so many in this space rely on (e.g. XtraBackup and Percona Toolkit's Online Schema Change have been widely used in the MySQL ecosystem for around 15 years), they have impeccable credentials and an impeachable reputation, they track upstream and contribute to make it better in countless ways. I'm happy to hear that both of you will explore using Percona Server for MySQL 8 with Vitess! ❤️

[mattlord]

@mreschke you make a very good point about the docs. Please let me know if you have any input on related updates here: vitessio/website#949

[paulocoghi]

We are planning on using Vitess, but MariaDB is our only option because of our past experience on high traffic customers.

We found that MariaDB offers more performance, lower latency and more resilience on the same hardware than MySQL

For this reason, I would vote to set MariaDB as the new default instead of MySQL. But since this vote could be unrealistic for many of you, I would at least vote to maintain support for MariaDB.

At least on our particular scenario, we can confirm that the results from MariaDB performance comparisons are realistic:
https://mariadb.com/resources/blog/benchmark-mariadb-vs-mysql-on-commodity-cloud-hardware/

We can see on it that, on the same hardware, MariaDB can be almost 4x faster than MySQL while providing almost 4x lower latency.

Just my 2c.

[mattlord]

Hi @paulocoghi!

We are planning on using Vitess, but MariaDB is our only option because of our past experience on high traffic customers.

A large percentage of the most highly trafficked sites in the world are using MySQL/Percona (including github.com). 🙂 As noted before, MariaDB is not safe to use with Vitess due to its poor GTID implementation (it has no uniqueness properties). I would strongly recommend against it. You WILL encounter problems, especially if you plan to use VReplication, which undergirds a lot of critical Vitess functionality.

In our experience with high traffic sites, we found that MariaDB offers more performance, lower latency and more resilience on the same hardware than MySQL

Your experience and findings differ from others.

For this reason, I would vote to set MariaDB as the new default instead of MySQL. But since this vote could be unrealistic for many of you, I would at least vote to maintain support for MariaDB.

As already noted, the cost of supporting it would be pretty massive going forward (please see the discussion above). Are you interested in contributing to that effort?

We confirmed that the results from MariaDB performance comparisons are true: https://mariadb.com/resources/blog/benchmark-mariadb-vs-mysql-on-commodity-cloud-hardware/

"Benchmarketing" is not terribly relevant, IMO. I don't doubt that if you repeated the same exact steps you would see the same results. Benchmarks like this are simply misleading rather than lies.

As we can see on it, on the same hardware, MariaDB can be up to 4x faster than MySQL while providing up to 4x lower latency.

As you might imagine, MySQL releases benchmarks where it's much faster than MariaDB and can also be repeated if you follow the same steps. 🙂

[paulocoghi]

Thanks @mattlord for your important considerations!

[mattlord]

@paulocoghi thank you for the feedback! You got me thinking...

It's worth pointing out that the only people that have objected, to date, are those that have NOT yet extensively used Vitess with MariaDB (like yourself, they're thinking about it or exploring it). Those that have tried to go that route have run into problems (you can search the Vitess Slack for it). In addition to trying to ensure the best use of the CNCF project's limited resources, I'm actually hoping to head off problems for Vitess users here. Toward that end, I added another bullet point to the issue/RFC description which highlights one of the more critical problems with MariaDB (though hardly the only one). I'll copy it here:

• MariaDB's GTID implementation — which is NOT compatible with MySQL which uses auto generated UUIDs for the unique host identifier — uses domain_id and server_id together as the "unique" host identifier while every MariaDB instance defaults to 0-1 for its unique host identifier which is in NO way unique. MariaDB's GTID implementation also do not use sets (MySQL uses GTID_EXECUTED and GTID_PURGED sets), but only the last seen sequence value from the given host identifier (so e.g. 0-1:20000 vs 15b57a66-e10d-11eb-a4de-7499a366173e:1-20000 in MySQL) — so you have no way to know if two servers have executed the same full set of GTIDs or not and you cannot easily detect drift and ensure consistency and correctness. When you combine these two things, this is a big problem for Vitess, which relies on fairly complex replication topologies. This makes MariaDB unsafe to use with Vitess VReplication, and you will run into problems (surfaced duplicate GTIDs are the least of your problems, the worse issue is undetected drift and inconsistencies within a shard). This is hardly the only problem with MariaDB usage in Vitess, but I assert that this alone makes MariaDB an unsafe and unsuitable choice.

I cannot and will not say that your opinions or experiences are invalid and I do not wish to debate whether MySQL or MariaDB is "better" (based on whatever you value most). But what I am saying, with confidence born of experience with Vitess, is that I believe — for the project and its users — this is the best path forward (the only thing that could potentially change the calculation is a large community effort to add and maintain full MariaDB support, but there's been no interest in that to date).

I hope this helps a little bit. I really do want you to use Vitess and find success with it! ❤️

[mreschke]

@mattlord Working on a new Vitess system using MySQL. My assumption would be that MySQL 8 is a better choice over MySQL 5.7 simply because it's newer. But in your docs, you mention "We recommend MySQL 5.7 if your installation method provides a choice". Is 5.7 still the best choice vs 8? If so, why exactly? Due to the discussions above, we won't be going down the MariaDB route. Thanks for updating your docs.

[mattlord]

Hi @mreschke!

We should be recommending MySQL 8.0 for new installations (e.g https://vitess.io/docs/overview/supported-databases/). Where did you see this note about 5.7?

Best Regards

[mreschke]

@mattlord so far through the docs, I only see two...

https://vitess.io/docs/13.0/get-started/local/
"We recommend MySQL 5.7 if your installation method provides a choice"

https://vitess.io/docs/13.0/user-guides/configuration-basic/planning/
"The most common deployments use MySQL 5.7"
which could read
"The most common deployments use MySQL 5.7, although MySQL 8.0 is the recommended version."

[mattlord]

Thanks, @mreschke! I opened a PR for those pages. And we'd love to have you involved if you're interested. There's an Edit this page button at the bottom of each page. It's all markdown in a GitHub repo and we're always happy to see new faces. 🙂

[ehcpdeveloper]

I was considering Vitess for Cluster/Shard management, but after ı see that it will not going to support Mariadb, I will have to give up on this. I do not trust Oracle.

[mattlord]

Hi @ehcpdeveloper !

I was considering Vitess for Cluster/Shard management, but after ı see that it will not going to support Mariadb, I will have to give up on this. I do not trust Oracle.

Nobody is asking or requiring that you trust Oracle, so I'm not sure how that's really relevant (related to this, please see the discussion about Percona above). I also read an implied assertion in this that you trust MariaDB (Corp). If so, then you could instead try their product that is in the same general space as Vitess: Xpand (from their purchase of Clustrix). Be aware, however, that it's closed source commercial software (not to mention that I'm unaware of any meaningful customer success stories). The other IP that they own is MaxScale which is... also not FOSS (although source is available under the BSL). Given MariaDB, Corp's behavior to date, and the fact that they are planning to go public which I would assume means they will not become MORE open, I'm not sure that this implied trust (maybe I'm misreading the subtext) is warranted or wise.

In any event, you are free to do whatever you like and I wish you the best with whatever you do. I just wanted to let you know that your input was seen and heard.

[TheOnlyMarkus]

Had read this while discussion in one go I got the feeling that contrary to OPs assertion "This is a proposal, it is not an announcement of a decision that's been made." the decision was already made upon creating this RFC.

Your experience and findings differ from others

Yes @mattlord your experience and findings differ from others.

Your unwillingness to solve the two major compatibility problems with current MariaDB version is biasing this whole discussion to an extend that most people reading your statements belief them without question.

I have been a software developer for many, many years (like you) and have witnessed many technological changes over the years and made decisions to migrate to newer and more powerful open source software, taking into account various circumstances, but what I never did was to think problem-oriented, but always solution-oriented.

Just to be sure that this is not taken up wrongly: I am grateful for all the work your team has done over the years to get such an essential software as Vitess running in as many environments as possible.

[derekperkins]

Your unwillingness to solve the two major compatibility problems with current MariaDB version is biasing this whole discussion to an extend that most people reading your statements belief them without question.

@TheOnlyMarkus I feel like that's an unfair characterization of the issue. As with any OSS project, there is a limited amount of developer resources. MariaDB is actively moving away from MySQL compatibility. The point of this issue was to give an opportunity for others to step up, as @mattlord stated: "the only thing that could potentially change the calculation is a large community effort to add and maintain full MariaDB support, but there's been no interest in that to date."

This issue isn't trying to compare MySQL vs MariaDB, it is just acknowledging that they can't be treated the same anymore. It's fundamentally no different from PostgreSQL compatibility, which is the highest upvoted issue in all of Vitess. It's not technically impossible, just significantly more overhead, that based on the current usage of Vitess would be better spent adding features and improving performance.

[FelipoAntonoff]

Hi, I read above the comments, but if the concern of MySQL is Oracle, I would recommend that PostgreSQL be adopted as the main database in Vitess, it has been very popular in recent years and it exists, it has the most SQL support and features, very community large, fully Open Source and very well maintained with constant updates and documentation.

Many Open Source systems are favoring it as the main or only accepted database, not least due to the concern of MySQL, but also mainly due to its resources and great development.

Now I have no idea what the complexity would be and if it would be in the interest of the majority to make this change a little more radical, in any case it seems to me that PostgreSQL will be the database used in most of the more serious projects or those that need more complete SQL resources .
Percona also has a PostgreSQL version https://www.percona.com/software/postgresql-distribution and maintains 100% compatibility, just like they do with MySQL.

As for MariaDB, I've been using it for years, but I don't mind going to MySQL or PostgreSQL, even many systems already use ORM that handles both easily.

So I also agree that it is better to avoid a lot of effort if it is to serve a small user base and MariaDB has a much lower % of use, the use was more relevant when it had almost total compatibility with MySQL like Percona Server MySQL that focuses only on small improvements and plugins.

We can get an idea of ​​the use of SQL databases on this site https://db-engines.com/en/ranking/relational+dbms, MySQL being the most used and then PostgreSQL, which probably in the long term is likely to be be the most used and indicated.

[derekperkins]

@FelipoAntonoff Postgres compatibility is a huge undertaking, and not one the Vitess team is currently planning to tackle

• RFC: Postgres support #7084 (comment)

[FelipoAntonoff]

I understand, it really doesn't seem like an easy task, who knows if they had used it at the beginning of the project because it is probably the most complete Open Source SQL database, but MySQL is also a great option, in fact both will cover basically almost every use case .

[marf]

Hello,
we are currently using a MariaDB cluster with MaxScale and want to switch to vitess, I understand MariaDB is not supported anymore (we use version 10.6), but is it at least possible to migrate the data from our MariaDB cluster to Vitess (with MySQL 8.0) using MoveTables?

Since there is a problem with the difference in GTID and VReplication I do not understand if it would be possible or not.

[mattlord]

Hi @marf,

Yes, we do want to support importing from MariaDB. We have tests for this today:

• https://github.com/vitessio/vitess/blob/main/.github/workflows/cluster_endtoend_vreplication_across_db_versions.yml

• vitess/go/test/endtoend/vreplication/vreplication_test.go

  Lines 378 to 385 in 16bbc2b

  	// TestMoveTablesMariaDBToMySQL tests that MoveTables works between a MariaDB source
  	// and a MySQL target as while MariaDB is not supported in Vitess v14+ we want
  	// MariaDB users to have a way to migrate into Vitess.
  	func TestMoveTablesMariaDBToMySQL(t *testing.T) {
  	sourceKsOpts["DBTypeVersion"] = "mariadb-10.10"
  	targetKsOpts["DBTypeVersion"] = "mysql-8.0"
  	testVreplicationWorkflows(t, true /* only do MoveTables */, "")
  	}

So we're testing with 10.10 and are able to import into Vitess (with MySQL 8.0).

[knielsen]

I am trying to understand this part of the rationale:

"every MariaDB instance defaults to 0-1 for its unique host identifier which is in NO way unique."

But it is a requirement in replication to configure a unique value of server_id in each server, and this server_id value then provides the unique host id, regardless of the domain_id value.

Is the problem this requirement in MariaDB for the user to explicitly configure a unique value for server_id? But this seems to be the case for MySQL also, so not sure why this is a problem specific to MariaDB:

https://dev.mysql.com/doc/refman/8.0/en/replication-options.html
"For servers that are used in a replication topology, you must specify a unique server ID for each replication server"

I do understand the difference between MySQL GTID's concept of "GTID sets" vs. MariaDB GTID's strict GTID ordering within a domain_id. But I don't understand what the problem with missing unique host identifier is?

[mattlord]

@knielsen with MariaDB it would require that Vitess ensure that each instance has a unique ID across the entire cluster and at least a large part of its lifespan. MySQL, on the other hand, automatically generates a server UUID — which as a core property is supposed to be universally unique — for itself. You can try it yourself... start up a mysqld instance. Then another if you like. During the mysqld --initialize[-insecure] phase it generates a UUID for itself and stores it in <datadir>/auto.cnf. For example:

❯ cat /opt/vtdataroot/vt_0000000100/data/auto.cnf
[auto]
server-uuid=b47a035e-dccf-11ee-acdc-4e98108879c7

You linked to the legacy server-id which can easily be randomly generated as in MySQL it's not used in uniquely identifying GTIDs (it only needs to be unique within the current set of mysqld instances replicating within a shard at any point in time which can easily be accomplished with a hashing scheme). In MariaDB, the domain_id is simply an extension of that legacy server_id value. In MySQL GTID sets are based on the server_uuid value and not server_id.

[mattlord]

@knielsen Hopefully that makes sense. What it means is that with MariaDB Vitess is responsible for generating and maintaining the unique identifier -- a combination of the server_id and domain_id -- used in GTID replication (Vitess only supports GTID based replication with row binlog format). With MySQL it all happens automatically and the uniqueness of each instance is guaranteed over time. To give you an example, if we started a mysqld and a mariadbd instance without specifying a config file we'd end up with GTIDs on each one like this:

• MySQL: b47a035e-dccf-11ee-acdc-4e98108879c7:1-100
• MariaDB: 0-1:100

[knielsen]

Ok, thanks for the explanation.
Yes, I understand MySQL UUID, and the MariaDB requirement for external (user/application) allocation of unique server_id.
What I didn't know was that Vitess gets away with duplicate server_id for MySQL instances despite what the docs say, so thanks for that explanation. I guess MySQL in practice will be happy as long as we don't connect a slave to a master where the server_id's are the same?
With MariaDB only 32 bits are available for uniqueness, which makes globally unique allocation more tricky than with the 128 bits available for UUID.

[mattlord]

@knielsen

MySQL in practice will be happy as long as we don't connect a slave to a master where the server_id's are the same?

Exactly. The uniqueness requirements are far lower so a random value is good enough. That's what we do in Vitess:

vitess/go/vt/mysqlctl/cmd.go

Lines 30 to 52 in 96e0a62

	// CreateMysqldAndMycnf returns a Mysqld and a Mycnf object to use for working with a MySQL
	// installation that hasn't been set up yet.
	func CreateMysqldAndMycnf(tabletUID uint32, mysqlSocket string, mysqlPort int, collationEnv *collations.Environment) (*Mysqld, *Mycnf, error) {
	mycnf := NewMycnf(tabletUID, mysqlPort)
	// Choose a random MySQL server-id, since this is a fresh data dir.
	// We don't want to use the tablet UID as the MySQL server-id,
	// because reusing server-ids is not safe.
	//
	// For example, if a tablet comes back with an empty data dir, it will restore
	// from backup and then connect to the primary. But if this tablet has the same
	// server-id as before, and if this tablet was recently a primary, then it can
	// lose data by skipping binlog events due to replicate-same-server-id=FALSE,
	// which is the default setting.
	if err := mycnf.RandomizeMysqlServerID(); err != nil {
	return nil, nil, fmt.Errorf("couldn't generate random MySQL server_id: %v", err)
	}
	if mysqlSocket != "" {
	mycnf.SocketFile = mysqlSocket
	}
	dbconfigs.GlobalDBConfigs.InitWithSocket(mycnf.SocketFile, collationEnv)
	return NewMysqld(&dbconfigs.GlobalDBConfigs), mycnf, nil
	}

vitess/go/vt/mysqlctl/mycnf_gen.go

Lines 158 to 186 in 96e0a62

	// RandomizeMysqlServerID generates a random MySQL server_id.
	//
	// The value assigned to ServerID will be in the range [100, 2^31):
	// - It avoids 0 because that's reserved for mysqlbinlog dumps.
	// - It also avoids 1-99 because low numbers are used for fake
	// connections. See NewBinlogConnection() in binlog/binlog_connection.go
	// for more on that.
	// - It avoids the 2^31 - 2^32-1 range, as there seems to be some
	// confusion there. The main MySQL documentation at:
	// http://dev.mysql.com/doc/refman/5.7/en/replication-options.html
	// implies serverID is a full 32 bits number. The semi-sync log line
	// at startup '[Note] Start semi-sync binlog_dump to slave ...'
	// interprets the server_id as signed 32-bit (shows negative numbers
	// for that range).
	// Such an ID may also be responsible for a mysqld crash in semi-sync code,
	// although we haven't been able to verify that yet. The issue for that is:
	// https://github.com/vitessio/vitess/issues/2280
	func (cnf *Mycnf) RandomizeMysqlServerID() error {
	// rand.Int(_, max) returns a value in the range [0, max).
	bigN, err := rand.Int(rand.Reader, big.NewInt(1<<31-100))
	if err != nil {
	return err
	}
	n := bigN.Uint64()
	// n is in the range [0, 2^31 - 100).
	// Add back 100 to put it in the range [100, 2^31).
	cnf.ServerID = uint32(n + 100)
	return nil
	}

[montywi]

From that above script, it looks like you need a unique server id per server to be able to identify the server.
MariaDB has had this a long time internally for aria tables and we could trivially expose this id if needed.
(It is stored in aria_log_control, with should not be a problem, but if it is we can store that also in separate config file).
Would that help?

Another note is that with the upcoming MariaDB catalog feature, you can have different server_id's for each catalog.
This will allow users to create even more existing typologies than what is possible with MySQL.
As catalogs will offer a great saving for DBAS companies, I expect this to be a very popular extension for them.

[montywi]

"so you have no way to know if two servers have executed the same full set of GTIDs"

If you are using --domain_id and --gtid-strict-mode, then comparing the last set of GTID's in MariaDB will tell you if the
servers are consistent.
In MySQL 8.0.26 and above, there can be gaps in GTID's. How does Vitess handle these?

[mattlord]

"so you have no way to know if two servers have executed the same full set of GTIDs"

If you are using --domain_id and --gtid-strict-mode, then comparing the last set of GTID's in MariaDB will tell you if the servers are consistent. In MySQL 8.0.26 and above, there can be gaps in GTID's. How does Vitess handle these?

But it doesn't AFAIUI. It's a position and not a set. It can tell if you if two servers are at the same position currently — meaning the last transaction that they executed from each unique {server-id,domain-id} instance (which as also discussed, is not guaranteed to be unique in any way) — but not that they have applied the same set of transactions across each of those instances. It's a pretty big gap in metadata to know that a server executed 1-1:1000 vs 1-1:1-1000. It's making an assumption that e.g. 500 was actually executed. It only tells you that both share the same last executed transaction.

Gaps in GTID sequences are not necessarily a problem. If there are errant transactions — meaning a GTID exists on the replica but not on the primary — then that is flagged by Vitess (vtorc) and that replica is not considered as a primary candidate.

This RFC is closed and the decision made and implemented. I'm happy to discuss various things in MariaDB vs MySQL, but this is not really the right place for it. The bottom line is that MySQL and MariaDB are different databases today and the Vitess project (maintainers) does not have the resources to support both today in an equivalent way (it actually never did) and into the future as new things are added. I would recommend opening a new issue/RFC where a proposal is made as to how this calculation might change. The GTID management difference is merely one example of how the two databases are different and how it would require a lot of work in Vitess to handle both in an equivalently intelligent way — both for existing features and new ones as Vitess has to do backups and restores, parse and generate binlogs, orchestrate servers, parse queries, execute commands and process outputs etc, all of which are different in various ways small or large between them today (that's before we even get to the k8s operator).

[gnat]

Interesting note for people following: Xpand (clustrix) has seemingly been abandoned by MariaDB, see:

• mariadb-corporation/MaxScale@93e5a78
• https://github.com/search?q=repo%3Amariadb-corporation%2FMaxScale+xpand&type=commits

Aside from importing into Vitess + MySQL, seems like no options at this point for MariaDB users. I wonder if Xpand has any chance of being open sourced or transferred to the MariaDB foundation.

[montywi]

With gtid-strict-mode you will know that no 500 is in the data set. If not, the replication would have stopped at 499 when it noticed that 500 did not exists.

Note you don't have the guarantee with MySQL either that data is consistent.

• MySQL 8.0.26 and above can have gaps and different servers can have different gaps. I don't know if these gaps are recorded or not.
• Server id's are not necessary unique as a backup:ed server would have the same uid, but not necessary same data
• MySQL GTID information does not guarantee data consistency. Just because GTID is identical does not guarantee that the data has been applied in the same order on two slaves (which means data on disk is not consistent).