I’m testing Everest with Rails which uses advisory locks and prepared statements. Right out of the box, attempting to create a database migration causes this error:
Percona-XtraDB-Cluster prohibits use of GET_LOCK with pxc_strict_mode = ENFORCING
Docs suggest this is the default behavior and should be left that way, for multinode clusters. But, this is also the default on a single node. What’s the reason for that? Is it still not advisable to use another mode on single node installs?
If you understand the risks, you can change the mode on single node installs. We default to ENFORCING in all cases because that is the best practice. There are several other things that strict_mode handles which are best practice.
OK - I’m asking specifically here about explicit table locking. Can you explain why this feature is considered dangerous in a multi-node cluster? Can pt-online-schema-change
be used instead in such setups?
It looks like switching to MASTER
would work for a single node install. Would it make sense to use MASTER
for one node, and ENFORCING
when a cluster is scaled out?
1 Like
Locks are not shared between nodes. You can acquire a lock on node1, and the same lock again on node2 and the same lock again on node3. This is why they are dangerous.
pt-osc works well with PXC because pt-osc does not use any table locks.