Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.2.9, 10.1(EOL), 10.2(EOL)
-
None
-
CentOS 7 x86_64
-
10.2.11, 10.1.30
Description
simple_password_check settings on both master and slave
[mariadb]
|
plugin-load-add=simple_password_check.so
|
|
simple_password_check_minimal_length = 10 |
simple_password_check_other_characters = 1 |
simple_password_check_letters_same_case = 1 |
simple_password_check_digits = 1 |
On master side, create an user with invalid password
CREATE USER USR_RO@'10.1.1.26' IDENTIFIED BY 'bsg9#d.cem#!85'; – No Upper Case Letter
ERROR 1819 (HY000): Your password does not satisfy the current policy requirements
The user was not created on master server, but for some reason binlog has written to disk.
On slave side, replication slave stops
Query caused different errors on master and slave. Error on master: message (format)='Your password does not satisfy the current policy requirements' error code=1819 ; Error on slave: actual message='no error', error code=0. Default database: ''. Query: 'CREATE USER USR_RO@'10.1.1.26' IDENTIFIED BY 'bsg9#d.cem#!85''
Meanwhile, I can see the new user has been created on slave server, the behaviour is strange.
Attachments
Issue Links
- relates to
-
MDEV-14716 Wrong binlog entries for a multi-user CREATE USER statement
-
- Confirmed
-
Due to various considerations, some statements are written into the binary log even when they fail. In this case, CREATE USER is written into the binary log on master. The binlog event gets the error code 1819 (ER_NOT_VALID_PASSWORD). The expectation is that the slave will hit the same error while trying to execute the statement. However, you apparently don't have the simple_password_check plugin on the slave, so the password does not violate any restrictions, the statement works all right ("no error" on the slave), which causes the replication failure.
Reasons for writing erroneous statements into the binary log are different, depending on the statement. I don't know reasoning for single CREATE USER, it looks like the change was made in the scope of
MDEV-7288, so I'll assign it to bar to confirm whether it was intentional. Meanwhile, the obvious workaround seems to be to have the same configuration on the slave as the master has, including smple_password_check plugin.