Earlier, if a service had multiple listeners you would have had
MaxScale> show dbusers MyService
User names: alice@% ...
User names: bob@% ...
That is, no indication of which listener is reporting what. With
this commit the result will be
User names (MyListener1): alice@% ...
User names (MyListener2): bob@% ...
Further, the diagnostics function of an authenticator is now expected
to write the list of users to the provided DCB, without performing any
other formatting. The formatting (printing "User names" and appending
a line-feed) is now handled by the handler for the MaxAdmin command
"show dbusers".
If local address has been specified, then all connections created
using mxs_mysql_real_connect() will use that same local address as
well.
A system test has not been created as our VMs do not have more than
one usable IP-address. Locally it has been verified to work as
expected.
The variable containing the number of workers must be updated
only after the workers have been successfully created.
Failure to do this led to crash in Worker::shutdown_all() if a
terminating signal was received after the worker initialization
had failed.
Instead of trying to figure out whether the kernel supports O_DIRECT
in conjunction with pipes, let's just use it and if it fails, try
without O_DIRECT.
Case in point, based on circumstantial evidence it seems that in a
container context, it may appear as if the kernel supports O_DIRECT
when it in reality does not. So better to use brute-force.
If a listener section specifies both a 'socket' and a 'port' the
creation will fail with a clear error message.
If 'address' and 'socket' is specified, there will be a warning that
the address is meaningless.
It is now impossible to create two listeners for a service that
would listen on the same port/socket (as before), but the error
message is now sensible and provides detailed information to the
user.
When MaxScale is starting, the loading of the listeners can take a while
if there are a large number of services and users to load. To signal this
to the user, progress messages should be logged after every service is
started.
When MaxScale is starting, the loading of the listeners can take a while
if there are a large number of services and users to load. To signal this
to the user, progress messages should be logged after every service is
started.
With a granularity of 1 second, the load will from a human
perspective reflect the current situation. That also means
that the maxadmin output shows "natural" steps; 1s, 1m and 1h.
By definition, the load is calculated using the following formula:
L = 100 * ((T - t) / T)
where T is a time period and t the time of that period that the worker
spends in epoll_wait(). So, if there is so much work that epoll_wait()
always returns immediately, then the load is 100 and if the thread
spends the entire period in epoll_wait(), then the load is 0.
The basic idea is that the timeout given to epoll_wait() is adjusted
so that epoll_wait() will always return roughly at 10 seconds interval.
By making a note of when we are about to enter epoll_wait() and when we
return from it, we have all the information we need for calculating the
load.
Due to the nature of things, we will not be able to calculate the load
at exact 10-second boundaries, but it will be pretty close. And the load
is always calculated using the true length of the period.
We will then calculate 1 minute load by averaging the load value for 6
consecutive 10-second periods and the 1 hour load by averaging the load
value of 60 consecutive 1 minute loads.
So, while the 10-second load represents the load of the most recently
measured 10-second period (and not the load of the most recent 10
seconds), the 1 minute load and the 1 hour load represents the load of
the most recent minute and hour respectively.
The output of `show threads` could have a negative historic thread load
average that could be explained by the overflow of the signed 32-bit
integer used to count the number of samples.
The time that each thread started to process an event for a DCB used an
old value that is no longer used. Updating this to DCB::last_read retains
the 2.0 behavior.
Previously, if the list contained servers that were not monitored by
the monitor yet were valid servers, an error value would be returned
and the monitor failed to start.
With this update, the non-monitored servers are simply ignored when
forming the final list.
Also, added printing of the list to diagnostics.
Now the users will be reloaded at most once during each
USERS_REFRESH_TIME period. Earlier they could be reloaded at
at most USERS_REFRESH_MAX_PER_TIME times, which in practice meant
that with repeated unauthorized login attempts they were reloaded
N times in rapid succession, without the situation being likely to
change in between.
The error regarding the refresh rate having been exceeded
error: [RWSplit] Refresh rate limit exceeded ...
has been turned into a warning. Further, the warning will be
logged at most once per refresh period that currently is 30s.
When a BEGIN statement is prepared using the binary protocol, it returns a
single OK packet. Due to a bug in the code that deals with multi-statement
results and EOF packets, the response was never sent to the client.
Also added back the error messages of failed session commands to the INFO
level. This way it's still possible to see why a session command fails but
the log isn't flooded by them in normal usage.
"servers_no_promotion" is a comma-separated list of servers
which cannot be chosen when selecting a new master during failover
(auto or manual), or when automatically selecting a new master
for switchover (currently disabled).
The servers in the list are redirected normally and can be promoted
by switchover when manually selecting a new master.
If the API versions do not match, MaxScale will treat this as an
error. The API versioning would allow backwards compatible changes but the
functionality to handle that is not implemented in MaxScale.
Updated API versions based on changes done to module APIs in 2.2.
With the flag --debug=enable-statement-logging it is now possible
to instruct MaxScale to log all SQL statements it sends to the
servers.
The format of the logged string looks like:
notice : SQL(127.0.0.1): 0, "SELECT ..."
First the fixed string "SQL", followed by the server address in
parenthesis followed by the actual return value of mysql_query(),
followed by the statement itself.
The "SQL" string makes the lines easy to grep for and having the
return value before the statement makes it easier to spot since
the length of the return value string does not wary much, but the
length of the statements do wary a lot.
Since a shutdown message will now be sent via the regular epoll route,
there is no need to regularily wake up from epoll in order to check
whether shutdown has been initiated, but we can simply wait in epoll_wait
until told to wake up.
* MXS-199: Support Causal Read in Read Write Splitting
* move most causal read logic into rwsplit router and get server type from monitor
* misc fix: remove new line
* refactor, move config to right place, replace ltrim with gwbuf_consume
* refacter a little for previous commit
* fix code style
In some cases you might want to use a specific address/interface
when connecting to a server instead of the default one. With the
global parameter 'local_address' it can now be specified which
address to use.
