The most complicated part to deal with was the existing and none existing data. In fact GTID sets must be compatible.
Let me explain that with some examples:
Example 1 – empty servers
If you have empty servers with GTID enabled, manually creating credentials to connect to each MySQL instances will generate GTIDs that will prevent nodes to join the cluster. Before 8.0.17 if you were doing this, you had to explicitly avoid to write the users in binary log.
Example 2 – servers with data but purged binary logs
When you want to add a new servers to a cluster, before 8.0.17 when the new server (joiner) wants to join the cluster, this is a very high summary of what they say:
- joiner: hello I don't have any GTID - group: ok we are now at trx (gtid sequence) 1000, you will then need from 1 to 1000, let's see if somebody part of the group as those trx - member1: no, I don't, I've purged my inital binlogs, I've from 500 - member2: no, I don't, the first binlog I've starts with gtid 600 - joiner: damn ! I can't join then, bye !
And this is the same when you prepare a new member with a backup, you need to be sure that next gtid since the backup was made is still available at least in one of the members.
My colleague Ivan blogged about that too.
Since MySQL 8.0.17, all this is not necessary anymore, the clone plugin can handle the provisioning automatically. If we take the second example above, instead of saying bye , the joiner will copy all the data (clone) from another member directly, without calling an external shell script or program, but directly in the server using the clone plugin !
10 minutes to install MySQL and setup an InnoDB Cluster
Let’s see this in action:
Since MySQL InnoDB Cluster is out, we received a lot of very good feedback, but the main feature request was always the same: automatic provisioning ! This is now part of the reality ! Wooohoooo \o/
And of course it’s all integrated directly into MySQL.