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.
If all but one server in a cluster fail and `failover` is enabled for
mysqlmon, the last server would be used as if it were a master. With this
change, the restrictions on failover also require that the last server is
not configured as a slave.
This change will prevent unintended failovers from happening when network
connectivity is bad. It also allows external actors to clear the slave
configuration from the last remaining server to signal MaxScale that the
server can be used as a master.
maxrows returns empty resultset instead of OK.
The response with coulmndefs is sent then an EOF without flags is added.
Limitations: in case of MULTI_RESULT sets only the first one coulmndefs
is sent with EOF
As before, the cache will be used if there is no ongoing transaction
(includes autocommit being on), or if there is an explicitly read-
only transaction.
In addition, the cache will be used and populated during any other
transaction as long as only pure read statements are executed. After
first non-read statement, the use of the cache is disabled.
The autocommit state is now included in the result returned
from session_trx_is_active(), so it need not be checked separately.
This is preparatory work for MXS-1136 that will change the approach
so that the cache is used and populated in a non readonly transaction
*until* the first non-read statement is encountered.
The thread id is copied to a local variable to avoid having
__tls_get_addr from unnecessarily being called over and over
again. Together that used to amount to some 1% of the execution
time.
