MariaDB Upgrade – Can Upgrade from MariaDB 5.5 to MariaDB 10.3 Directly?

Use current_pos to switchover master. Use slave_pos for a regular replication.

current_pos - last change in GTID domain

slave_pos - last replicated change applied by SQL thread or parallel workers on the replica.

So, imagine your ordinary replica (node2) switched to a master. slave_pos not incrementing, because changes are applied directly without any replication. Then you need to reconfigure cluster and make the new master become replica again.

What you will see on node2?

SHOW global variables like '%pos%'?

you will see, that slave_pos stopped incrementing on the moment of switchover, current_pos incrementing correctly.

In order node2 to become replica you must use current_pos, after the workload switched to a new master.

Summarizing:

slave_pos

• use this option when you don't pretend to write to the replica
• you don't want the transaction id part of the GTID to increment on the slave
• you are adding a new slave to the cluster and would like to start replicating from the GTID.slave_pos

current_pos

• use this when you do write to the slave and want to increment GTID transaction id
• when a master need to become a new slave

If you do sudo su - to root, are you able to log in without a password? If not, you can always log in by skipping the grant tables. See e.g. step 2 and 3 in this tutorial.

Once inside, you need to change the authentication plugin back to 'mysql_native_password' for the root@localhost user:

ALTER USER root@localhost IDENTIFIED VIA mysql_native_password;
SET PASSWORD = PASSWORD('foo');

See documentation on this here.