I also imported a mysqldump from 5.7
@Chris_Bunge Did you import a mysqldump also?
Yes I did. I have other’s testing from my team with different database restores and they are seeing the same in Ubuntu 22.04 and looks like RHEL 8 is doing the same.
Seeing the same as others on Ubuntu 22.04 with large amounts of MDL conflicts and DML command without primary key which is eventually followed by a crash. This was a fresh install using a mysqldump from 5.7.
The above was running less than 24 hours before it crashed.
Loaded up the same test in RHEL 8. I do see all the same error messages in the log but i have yet to produce a crash. It’s been running for about 3 days so far.
Hi guys,
Thank you very much for your feedback. A few days ago, I opened a bug about this problem.
I know some work has been done to diagnose the issue. Please feel free to update the ticket with any relevant information that could help.
You can follow the bug status and attach additional information here:
https://jira.percona.com/browse/PXC-4148
Thank you!
Pep
2 Likes
Just testing with standard MySQL 8 we’re seeing issues with both 8.0.30 and 8.0.31. Seems 8.0.32 is the first fixed version since whatever is going on is actually addressed. (may absolve Percona specifically at that point)
I had the same problem with replication. Slave replication hung up with Waiting for dependent transaction to commit status. [Note] [MY-000000] [WSREP] MDL conflict db= table= ticket=1 solved by abort messages appeared in log from time to time.
I set slave_parallel_workers variable to 0, restarted the server and it solved the problem.
mysql> show variables like '%slave_parallel_workers%';
+------------------------+-------+
| Variable_name | Value |
+------------------------+-------+
| slave_parallel_workers | 4 |
+------------------------+-------+
1 row in set (0.02 sec)
mysql> set global slave_parallel_workers = 0;
root@hostname:/home# mysqlslap -u devuser -p --delimiter=";" --query="SELECT 1" --concurrency=5 --iterations=2 -vv
Still a lot of errors:
2023-03-02T15:00:07.245500-00:00 123 [Note] [MY-000000] [WSREP] MDL conflict db= table= ticket=10 solved by abort
2023-03-02T15:00:07.245699-00:00 122 [Note] [MY-000000] [WSREP] MDL conflict db= table= ticket=10 solved by abort
2023-03-02T15:00:11.021984-00:00 156 [Note] [MY-000000] [WSREP] MDL conflict db= table= ticket=1 solved by abort
2023-03-02T15:00:11.022187-00:00 154 [Note] [MY-000000] [WSREP] MDL conflict db= table= ticket=10 solved by abort
2023-03-02T15:00:11.022243-00:00 154 [Note] [MY-000000] [WSREP] MDL conflict db= table= ticket=10 solved by abort
2023-03-02T15:00:11.022331-00:00 156 [Note] [MY-000000] [WSREP] MDL conflict db= table= ticket=10 solved by abort
2023-03-02T15:00:11.022891-00:00 155 [Note] [MY-000000] [WSREP] MDL conflict db= table= ticket=1 solved by abort
2023-03-02T15:00:11.023220-00:00 156 [Note] [MY-000000] [WSREP] MDL conflict db= table= ticket=10 solved by abort
Looks like the fix is out…
Can anyone confirm?
1 Like
Yes. If you check the release notes, you can see that this version fixes: [PXC-4148] After upgrade to 8.0.30 errors: MDL conflict db= table= ticket=10 solved by abort - Percona JIRA
Thank you all for your help and patience.
Hi all,
I’m on version 8.0.32-24.2, updated from 5.7. Upon executing SQL statements which worked fine on 5.7, but give warnings about deprecation in 8.0, these errors without values for db and table appear, which makes them somewhat unhelpful. As some earlier in this thread, only one node is used for write operations, unless that node is marked down. Any idea where to look?