Hi,
we upgraded our some pxc 3-node clusters from 8.0.27, 8.0.29 to 8.0.30-22.md
After that in error.log we are getting a lot of errors:
2023-01-16T09:22:01.962511-00:00 161616 [Note] [MY-000000] [WSREP] MDL conflict db= table= ticket=1 solved by abort
2023-01-16T09:22:01.962661-00:00 161617 [Note] [MY-000000] [WSREP] MDL conflict db= table= ticket=10 solved by abort
2023-01-16T10:22:02.064383-00:00 162676 [Note] [MY-000000] [WSREP] MDL conflict db= table= ticket=1 solved by abort
2023-01-16T10:22:02.064711-00:00 162677 [Note] [MY-000000] [WSREP] MDL conflict db= table= ticket=10 solved by abort
2023-01-16T11:59:55.946132-00:00 163948 [Note] [MY-000000] [WSREP] MDL conflict db= table= ticket=10 solved by abort
2023-01-16T13:35:52.337620-00:00 165300 [Note] [MY-000000] [WSREP] MDL conflict db= table= ticket=1 solved by abort
2023-01-16T13:35:52.337849-00:00 165301 [Note] [MY-000000] [WSREP] MDL conflict db= table= ticket=10 solved by abort
Is there any way to see reasons for this?
we have wsrep_log_conflicts=ON
I tried:
set global wsrep_debug=1;
set global wsrep_provider_options=“cert.log_conflicts=ON”;
didn’t help, still a lot of errors witout table name:
[Note] [MY-000000] [WSREP] MDL conflict db= table= ticket=10 solved by abort
P.S. before 8.0.30 we have sertification errors like:
TRANSACTION 59238092, ACTIVE 0 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT
MySQL thread id 18, OS thread handle 140076065289984, query id 32898852 Applying batch of row changes (update)
TRANSACTION 59238089, ACTIVE 0 sec
, undo log entries 1
MySQL thread id 161585, OS thread handle 140059226334976, query id 32898850 10.1.2.158 grafana wsrep: replicating and certifying write set(-1)
COMMIT
2023-01-16T09:19:16.667847-00:00 18 [Note] [MY-000000] [WSREP] --------- CONFLICT DETECTED --------
2023-01-16T09:19:16.667889-00:00 18 [Note] [MY-000000] [WSREP] cluster conflict due to high priority abort for threads:
No, we are not doing any DDL. Just the same application work as in previous pxc versions 8.0.27 and 8.0.29
mysql> SHOW VARIABLES LIKE 'wsrep_OSU_method';
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| wsrep_OSU_method | TOI |
+------------------+-------+
Are you writing on all the nodes or just on one? Usually these are normal conflicts when multiple nodes receive writes. This situation can lead to concurrency conflicts that are resolved by the cluster and, much more important, that need to be handled properly by the application.
This was happening on the first node before i added subsequent nodes. I’m not sure how there could be constant concurrency conflicts with just one node up.
What is the version of PXC that you installed? The same as in the original post? Please also provide additional information about the operating system version.
Hello
We have the same problem on an updated node (versions 8.0.30-22.1.el8) of a 3-node pcx cluster. Two remaining non-updated nodes (versions 8.0.26-16.1.el8) do not write errors to the log. OS oracle linux 8 (5.4.17-2136.305.5.4.el8uek.x86_64)
