Description:
The GET_LOCK mechanism does not work across an ndb cluster that utilizes multiple mysqld processes. Each mysqld maintains its own named lock database.
People choose mysql ndb cluster as a clustering technology. It's very non-intuitive that this would be a limitation of GET_LOCK.
Short term:
1. The GET_LOCK documentation should be very, very clear that this is not supported.
2. The NDB limitations documentation should be very, very clear that this is not supported.
Longer term:
I think GET_LOCK, or something very similar, that worked across the NDB cluster would be well-received by mysql ndb cluster users.
How to repeat:
set up an NDB cluster with > 1 mysqld processes participating
start mysql connecting to mysqld-process-1 and use "select GET_LOCK("mylock",1);"
start mysql connecting to mysqld-process-2 and use "select GET_LOCK("mylock",1);"
both GET_LOCKs will succeed
This query:
select * from performance_schema.metadata_locks;
on both mysqld-1 and mysqld-2 will return the lock named "mylock" and show that it is owned by a different session/connection/process/whatever.
Suggested fix:
1. fix the documentation, put this in huge red letters in GET_LOCK and ndb cluster limitations section
2. add something like GET_LOCK that works across an ndb cluster if you can't retrofit GET_LOCK to actually work across the ndb cluster
Description: The GET_LOCK mechanism does not work across an ndb cluster that utilizes multiple mysqld processes. Each mysqld maintains its own named lock database. People choose mysql ndb cluster as a clustering technology. It's very non-intuitive that this would be a limitation of GET_LOCK. Short term: 1. The GET_LOCK documentation should be very, very clear that this is not supported. 2. The NDB limitations documentation should be very, very clear that this is not supported. Longer term: I think GET_LOCK, or something very similar, that worked across the NDB cluster would be well-received by mysql ndb cluster users. How to repeat: set up an NDB cluster with > 1 mysqld processes participating start mysql connecting to mysqld-process-1 and use "select GET_LOCK("mylock",1);" start mysql connecting to mysqld-process-2 and use "select GET_LOCK("mylock",1);" both GET_LOCKs will succeed This query: select * from performance_schema.metadata_locks; on both mysqld-1 and mysqld-2 will return the lock named "mylock" and show that it is owned by a different session/connection/process/whatever. Suggested fix: 1. fix the documentation, put this in huge red letters in GET_LOCK and ndb cluster limitations section 2. add something like GET_LOCK that works across an ndb cluster if you can't retrofit GET_LOCK to actually work across the ndb cluster