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:
Category:MySQL Server: Replication Severity:S2 (Serious)
Version:any OS:Any
Assigned to: CPU Architecture:Any

[9 Aug 2012 12:09] Peter Laursen
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`;

.. 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.
[9 Aug 2012 12:18] Peter Laursen
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).
[9 Aug 2012 12:36] Valeriy Kravchuk
Looks like a duplicate of Bug #50460. Similar request ended up as a verified FR, Bug #61767.
[9 Aug 2012 12:40] Peter Laursen
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?
[22 Jan 2013 11:46] Sveta Smirnova

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