[MDEV-5701] "flush privileges" statement not replicated Created: 2014-02-18  Updated: 2014-06-21  Resolved: 2014-06-21

Status: Closed
Project: MariaDB Server
Component/s: None
Affects Version/s: 5.5.35-galera
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Giuseppe Iannello Assignee: Nirbhay Choubey (Inactive)
Resolution: Fixed Votes: 0
Labels: None


 Description   

Scenario: increasing username size limit to 80 chars (https://mariadb.com/kb/en/create-user/)

Connect to node01 (out of 3 nodes), execute the ALTER TABLE/FLUSH PRIVILEGES.
Check on node02 and node03: table schema is the same as on node01 (myisam replication is enabled).
Create a user with name longer than 16 chars.

Expected result: the user is created on all the nodes.
Actual result: the user is created only on node01, the following error appears in node02 and node03

140218 13:57:37 [ERROR] Slave SQL: Error 'String 'xxxxxxxx.xxxxxxxx' is too long for user name (should be no longer than 16)' on query. Default database: ''. Query: 'create user 'xxxxxxxx.xxxxxxxx'@'localhost' identified via pam', Error_code: 1470
140218 13:57:37 [Warning] WSREP: RBR event 1 Query apply warning: 1, 747464080
140218 13:57:37 [Warning] WSREP: Ignoring error for TO isolated action: source: d6415d69-97ba-11e3-b256-4a2b07b481ae version: 3 local: 0 state: APPLYING flags: 65 conn_id: 2166950 trx_id: -1 seqnos (l: 18071684, g: 747464080, s: 747464079, d: 747464079, ts: 280370647792084)

Solution: execute FLUSH PRIVILEGES on all the nodes of the cluster after ALTER TABLE.

I'm not sure that replicating FLUSH PRIVILEGES across the cluster is correct, but in that case the documentation should be updated.



 Comments   
Comment by Nirbhay Choubey (Inactive) [ 2014-06-21 ]

Hi giannello, You got it right! FLUSH PRIVILEGES is not replicated, so one has to run the command
on all the nodes after ALTER TABLE.

Comment by Nirbhay Choubey (Inactive) [ 2014-06-21 ]

Added under limitations : https://mariadb.com/kb/en/mariadb-galera-cluster-known-limitations/

Generated at Thu Feb 08 07:06:23 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.