MariaDB and others match grants first by exact hostname/IP and then by
wildcard. If there are no exact matches, the wildcard grant should be
picked. This can be tested by having different passwords for localhost and
remote address.
The SQLite based authentication should first check for an exact match and
then only after that should it try to match the hostname to a wildcard
grant.
The get_users function now combines the functionality of the old get_users
and get_all_users. This removes large parts of similar code.
Removed the listener resources as MySQLAuth was the only one that used it.
The user data is now stored inside a SQLite3 database. By storing the data
inside a database, we remove the restriction that the previous hashtable
based implementation had.
Currently the only situation where a user needs to be authenticated after
the initial authentication is when a COM_CHANGE_USER is being
executed. This was previously handled by directly calling a function in
the MySQLAuth authenticator.
The new entry in the API of the authenticators is very specific to MySQL
and should be reviewed once other protocols are added.
When the real root master server went down, it still received the master
status bit due to how the replication tree was built. The bit should only
be set for servers that are running.
Also fixed a false state change event when the master status bit was
manually cleared from the downed root master server.
The order of the servers in the service definition could break the
master_accept_reads functionality.
When the first server defined in the service is a slave, it will always be
picked as the first candidate for reads. The master would only be
considered as a candidate for reads if no previous candidate was
available. For this reason, the master_accept_reads only worked when the
first server in the list was the master.
GCC on CentOS6 thinks there is an array-bounds error in the sqlite
code. As that code is outside our hands, it is easiest to instruct
GCC not to treat it as an error.
If one queried in MySQL MaxInfo 'show sessions' or 'show clients',
MaxScale would go in an endless loop and finally crash when memory
ran out. The reason is the rather confusing callback-based dcb-
iterating code. Adding one line fixes the issue, although the iteration
is still rather awkward with calling dcb_foreach for every session/
client.
The Avro C API fails to write bytes of size zero. A workaround is to write
a single zero byte for each NULL field of type bytes.
Also added an option to configure the Avro block size in case very large
records are written.
The rotations of binlogs weren't detected as the file names weren't
compared.
Moved the indexing of the binlogs to the end of the binlog
processing. This way the files can be flushed multiple times before they
are indexed.
The old DATETIME format wasn't processed properly which caused a
corruption of following events.
A BLOB type value could be non-NULL but still have no data. In this case,
the value should be stored as a null Avro value.
When MaxScale is started, it will attempt to create the PID directory. If
the directory does not exist and MaxScale is able to create it, MaxScale
will successfully start whereas it previously failed to do so.
If MaxScale lacks the permissions to create the directory, an error
message is printed to the user explaining the reason why MaxScale fails to
start.
The resultset of SELECTs that use functions whose result will
always vary or whose result depend upon the user executing the
query should not be cached. The list of functions is the same
as that specified for the query cache of MariaDB:
https://mariadb.com/kb/en/mariadb/query-cache/
If user or system variables are used in a SELECT statement, then
the result will not be cached. That ensures that the wrong result
will not be returned.
