It took me awhile to get back here and for that i apologize, but i ran an upgrade on a newly built galera cluster on aws, identical to my existing ones, using saltstack, and with my normal dataset, which is fairly small, but from what saw should not matter all that much as long as your rolling upgrades, advice i took from here, are done in fairly quick succession, it went smoothly. I found that stopping, uninstalling and installing took about 5-10 minutes, and i added time to that to run CRUD statements at each step to ensure that simple data exchanges between 10.1 and 10.2 were compatible. So the not-so-exciting set of steps i went through, on each server, was:

• sudo apt install percona-xtrabackup-24
  • this uninstalls the percona-xtrabackup package (2.3.9 on my machine)
• sudo /etc/init.d/mysql stop
• sudo apt remove -y mariadb-server
• sudo vim /etc/apt/sources.list.d/maria.list
  • Replace URL with: http://mirrors.accretive-networks.net/mariadb/repo/10.2/ubuntu xenial main
  • Worth noting that the signing key does not change, i ran an accept key on one and it didn't update
• sudo apt update
• sudo apt install -y mariadb-server
  • Adding a password at this step is user choice, i chose not to as having root password less in my environment for 30 minutes is not a big deal, they are well protected and root is only allowed from localhost.
• sudo /etc/init.d/mysql start
• mysql -u root -e "show variables like 'wsrep_%'"

Here I spent a few minutes with the error log on the upgraded server (and 1 non-upgraded servers) to ensure that it looked like a normal rolling restart of the 3 DB servers, basically quitting and joining the cluster. If you manage a galera cluster, i'm sure you know what these logs should look like.

I then would run CRUD operations on all three servers into a tables to ensure replication was fine between versions when there was 1 on 10.2, then 2, then all three.

I know this is not much for documentation, but i feel good enough about it, that i'm likely to do it in my staging environment shortly. BTW as the sentence above state, i have three in the cluster and to reiterate, it took about 30-45 minutes, taking my time. Using saltstack for config mgmt i could easily automate this, but i'd rather have 1 bad node than not look at it and have a bad DB cluster.

HTH,
Jeff

It could be noted that there are problems with Galera replication with some of the recent 10.2 releases, e.g.:

• 10.2.9:
  • MDEV-13950: mysqld_safe could not start Galera node after upgrade ...
• 10.2.10:
  • MDEV-14255: Broken SST on Debian in 10.2.10
  • MDEV-14256: MariaDB 10.2.10 can't SST with xtrabackup-v2

Hopefully, 10.2.11 will be released soon and all will be well!

Thanks Karl, good points.

To be complete

• I was using Ubuntu 16.04.3 LTS, kernel version: 4.4.0-97-generic, so i didn't run into MDEV-13950
• I should have referenced MDEV-14256 when i noted to install percona-xtrabackup-24
  • I performed this upgrade the day 10.2.10 was released to apt.
• Data load is low enough, in my current world, and the migration quick enough, not to be concerned with MDEV-14256, if it applies to 16.04
  • Our business is very much tied to certain hours of the day and could likely avoid this all together if performing the upgrade off hours, which would be the plan.

I should also add i did make a logical backup, but this being a cluster was not overly concerned and would have stopped, had the first node failed (which I once ran into in an upgrade of maria i think the 10.0 series) I love clusters!

Again, appreciate the follow up.

Just wanted to follow up one last time that performing these steps in both my staging and production environments proved to be sufficient from 10.1.10 -> 10.2.12, running a script that was inserting data at a regular interval so i could check consistency after the node i was working on came back up.