MySQL Bugs: #66277: GRANT|REVOKE does not replicate

Bug #66277	GRANT\|REVOKE does not replicate
Submitted:	9 Aug 2012 12:09	Modified:	9 Aug 2012 12:40
Reporter:	Peter Laursen (Basic Quality Contributor)	Email Updates:
Status:	Duplicate	Impact on me:	None
Category:	MySQL Server: Replication	Severity:	S2 (Serious)
Version:	any	OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
Preconditions: 
1) row-based or mixed replication setup
2) probably some specific setting for binlogging control (like "--binlog-ignore-db" or "binlog_do_db") is also required. 

USE `this_is_not_mysql`;
GRANT|REVOKE ...;

.. and binlog has not recorded anything for the GRANT|REVOKE.

I am sorry if this is a duplicate.  It was reported by a customer of ours.  He told a few days ago that he would file a bug report here, but I am not able to find it, so maybe he did not.

If this is not a duplicate and you need more details we can try to detail the test case.

How to repeat:
See above.

Suggested fix:
GRANT|REVOKE should be marked as unsafe for row-based replication?

GRANT|REVOKE is an 'abstraction' for what actual data manipulations are performed.  It is not directly/explicitly addressing any specific table or database.  Besides in 5.6.6 there was (as I understand changelogs) introduced an option to have user privileges stored in a file and not in `mysql` database.

I could also imagine that this could casue problems/inconsistencies for users using the PAM plugin for authentication (but I don't know details about it too well).

Looks like a duplicate of Bug #50460. Similar request ended up as a verified FR, Bug #61767.

I was informed that the bug report posted by our customer is http://bugs.mysql.com/bug.php?id=65923. Why is this one marked as private when Bug #50460 and Bug #61767 are not?

Peter,

it was your customer who initially marked bug #65923 as private.