The new `force=yes` option closes all connections to the server that is
being put into maintenance mode. This will immediately close all open
connections to the server without allowing results to return.
Given the assumption that queries are rarely 16MB long and that
realistically the only time that happens is during a large dump of data,
we can limit the size of a single read to at most one MariaDB/MySQL packet
at a time. This change allows the network throttling to engage a lot
sooner and reduces the maximum overshoot of throtting to 16MB.
The load_persisted_configs parameter now controls whether persisted
runtime changes are loaded on startup. The changes are still generated as
it persists the current state of MaxScale making problem analysis easier.
The function allocated a constant-sized chunk of memory for all messages
which was excessive as well as potentially dangerous when used with large
strings.
Given the following query:
PREPARE ps FROM 'PREPARE ps2 FROM \'SELECT 1\'';
The debug assertion is hit even though this is valid, albeit unsupported,
SQL. An optimization would be to ignore the query if the prepared
statement type is another prepared statement.
When a single GWBUF was split into two with gwbuf_split, the new GWBUF
would point to the start of the shared data and the old one to the
end. Data-wise, this is fine but as the parsing info for queries is stored
in the shared buffer it causes problems when multiple packets get read in
one network payload. The end result would be that only the first query in
the lot would get parsed and the rest would get the same classification as
the first one.
To properly fix this without the need to deep clone the buffer would
require a reorganization of the buffer mechanism in MaxScale.
This commit alone doesn't fix the queued query routing problems in
readwritesplit. The commit from 2.2 which fixes the ordering problems with
queued queries is also required for a fully functional queued query
mechanism.
Always storing runtime configuration changes prevents problems when the
change causes another parameter to change. One example of this is
transaction_replay that implicitly enables other parameters.
If a DCB was closed and a hangup event was sent to it via
dcb_hangup_foreach shortly after it was closed, the DCB would still
receive it even if it was closed. To prevent this, events must only be
delivered to DCBs if they haven't been closed.
If the routing of a session command fails due to problems with the backend
connections, a more verbose error message is logged. The added status
information in the Backend class makes tracking the original cause of the
problem a lot easier due to knowing where, when and why the connection was
closed.
Both the replication lag and the message printing state are saved in SERVER,
although the values are mostly used by readwritesplit. A log message is printed
both when a server goes over the limit and when it comes back below.
Because of concurrency issues, a message may be printed multiple times before
different threads detect the new message state.
Documentation updated to explain the change.
There is a race condition between the addition of the DCB into epoll and
the execution of the event that initiates the protocol pointer for the DCB
and sends the handshake to the client. If a hangup event would occur
before the handshake would be sent, it would be possible that the DCB
would get freed before the code that sends the handshake is executed.
By picking the worker who owns the DCB before the DCB is placed into the
owner's epoll instance, we make sure no events arrive on the DCB while the
control is transferred from the accepting worker to the owning
worker.
When poll_add_dcb was called for a DCB that once was polling system but
was subsequently removed, the DCB would appear twice in the worker's list
of DCBs. This caused a hang when the DCB was the last one in the worker's
list and dcb_foreach_local would be called.
To prevent the aforementioned problem, the DCBs are now added and removed
directly to and from the workers instead of indirectly via poll_add_dcb
and poll_remove_dcb.
The process of appending to a std::string always includes a size check in
case the internal storage needs to expand. Given that we know a
canonicalized version of a query string is never larger than the original
string and that we pre-allocate enough memory to cope with the worst-case
scenario, the extra logic in std::string::push_back is unnecessary and an
extra cost. Writing directly into the string avoids this cost and improves
the performance.
Switched from default character type functions to ones that use lookup
tables. Eliminated the internal state and replaced with in-place iteration
of the query. Added code to allow single-lookup detection of normal
characters.
The log message should now contain enough information to more easily debug
any configuration issues that result from updating the main config file
after runtime changes have been done.
Also fixed the theoretical race condition in detection of persisted
configuration files by only checking for their existence once.
All global parameters are now handled by the runtime configuration
modification code. The parameters that are trivial to update can now be
updated at runtime. All other global parameters cause a new error message
to be returned stating that the parameter in question cannot be modified
at runtime.
Also updated the list of modifiable parameters in MaxCtrl. This list
should not be stored in MaxCtrl and should be created by MaxScale at
runtime.
Since we know the worst-case size of a canonical statement is the size of
the query string, we can reduce the number of memory allocations to one in
the get_canonical function.
The deleter for std::unique_ptr<GWBUF> was not included in that file which
caused it to be deleted with the default deleter. The same should apply to
std::unique_ptr<json_t> as well.
