The 3 node Percona Xtradb cluster has been flooding the mysqld.log with the below warning messages.
[Warning] WSREP: Percona-XtraDB-Cluster doesn’t recommend use of DML command on a table (morpheusdb.account_usage_metadata_tag) without an explicit primary key with pxc_strict_mode = PERMISSIVE
How can we fix this?
@ecmpflex Morpheus doesnt do any internal testing with Percona or provide recomendation for a Percona HA setup. I would recommend leveraging the percona docs/community. Here is a link around strict mode. Percona XtraDB Cluster strict mode - Percona XtraDB Cluster
Another option is to speak to your account manager on options to work with professional services to migrate to InnoDB cluster that is internally tested.
No that’s not correct! Morpheus did recommend us to go for the Percona XtraDB cluster and they also said that is the only supported DB by them. And this implementation was done by the Morpheus authorized professional services 3 years back. Thanks.
What version of MySQL is your cluster using?
Re the log writes: log rotation and/or log compression may help mitigate in the short term, but setting pxc_strict_mode to disabled as per the link provided will stop the log writes.
Definitely consider InnoDB as @rboyd suggested.
Thanks Ollie!
Server version: 5.7.31-34-57-log Percona XtraDB Cluster (GPL), Release rel34, Revision d76a6e8, WSREP version 31.45, wsrep_31.45
Yes, we are managing currently with log rotation and compression for now but this behavior seems to be new and exhaustive.
What we are looking for is the root cause and a permanent fix.
Re InnoDB, yes we do consider that and in discussion with our CSM asking for guidance to achieve this.
You didn’t say what Morpheus version you are using - and I didn’t ask sorry - but as the product evolves the database schema employed will evolve. It could be that a migration on upgrade has caused the increased logging. I don’t know, but it’s a reasonable guess.
I think not logging is the best temporary fix for the moment. An upgrade to InnoDB Cluster and MySQL 8.0 is probably the better long term fix as I believe MySQL 5.7 is now EOL.
Our Professional Services team can assist you if needed.
No problem 
We are on v. 8.0.2 for almost 3 months now. But we noticed this behavior for the last couple of weeks so I doubt the upgrade could be the cause. As I said we will consider the upgrade for InnoDB and MySQL 8.
Thanks.
