We took a backup from Percona XtraDB 5.6 with the mysqldump application and restored it to XtraDB 8.0, and we ran the applications this way. However, in some cases we experience deadlock-like problems.
Could the source of these problems be because we did not perform gradual DB migration between versions 5.6 - 5.7 - 8.0?
Finally, we want to do another upgrade. First, we will upgrade the database to structure only, from 5.6 to 5.7 and finally to 8.0. Finally, we want to back up only the data of the database running in version 8.0 in the live system and transfer it to the new environment.
Q: Are you writing to more than 1 node at a time? If so, the best practice is not to do that. Use only 1 node for writing.
A: We use single node for writing one at a time.
You can see the conflict error I mentioned today in the attachment.
Generally, when I see this error, no bootstrap server is active in the Cluster and we have to restart all nodes.
The error you show is a data conflict error. The UPDATE query succeeded on 2 of the 3 nodes, but on this node the UPDATE was invalid due to the data being different. This caused the node to abort and shut down.
This should be your process:
Stop Mysql on new node1/2/3. Erase data.
Take a new dump from old mysql.
Bootstrap new node1.
Import data
Start new node2. This will SST from node1. Wait until complete.
Start enw node3. This will SST from node1/2. Wait until complete.
Now your cluster is online and all data is exactly the same on all 3 nodes. Use the built-in processes for initializing a cluster (ie SST). Having the same data on all 3 nodes will prevent these types of data-related crashes.
