If an invoked script must access servers, it needs credentials.
When invoked, a script can now be provided with the monitor
credentials of MaxScale using the variable CREDENTIALS.
It will be expanded like
user:password@[...]:N1,user:password@[...]:N2
for every server the monitor in question is monitoring. That is,
irrespective of whether it is a master or a slave, running or not.
Thus, a failover script could be specified like:
[MyMonitor]
type=monitor
module=mysqlmon
...
script=.../failover.sh --credentials=$CREDENTIALS --slaves=$SLAVELIST
events=master_down
Note, it may make sense to introduce specific failover (and switchover)
keywords, but with the above addition it is possible to start
experimenting with failover scripts.
The CHILDREN parameter expands to a list of server IPs and ports that are
direct descendants of the server that initiated the event.
Also added a note that the variables can expand to empty strings if
nothing matches the criteria of the variable.
The scripts now replace the PARENT variable with the IP and port of the
server that is the direct parent node of the server that initiated the
event. For master-slave clusters, this will be the master IP if the server
that triggered the event is a slave.
If the executed subprocess prefixes its output with either `error:`,
`warning:` or `info:`, the message will be logged on the appropriate
level. If no prefix is provided, the message is logged on the notice
level.
When the subprocess outputs a line, the message should be logged
immediately. This allows automated timestamps for the output of the
executed subprocess.
By moving the initialization into Worker::run, all threads, including the
main thread, are properly initialized. This was not noticed before as
qc_sqlite initialized the main thread in the process initialization
callback.
The enums exposed by the connector are not intended to be used by the
users of the library. The fact that the protocol, and other, modules used
it was in violation of how the library is intended to be used.
Adding an internal mapping into MaxScale also removes some of the
dependencies that the core has on the connector.
Cleaned up the MaxScale version of the mysql.h header by removing all
unused includes. This revealed a large amount of dependencies on these
removed includes in other files which needed to be fixed.
Also sorted all includes in changed files by type and alphabetical
order. Removed explicit revision history from modified files.
Basically it would be trivial to report far more operations
explicitly, but for the fact that the values in qc_query_op_t
currently, quite unnecessarily, form a bitmask.
In 2.2 that is no longer the case, so other operations will be
added there.
Apart from listeners, all DCBs will be assigned to the current
thread. This simplifies the addition of DCBs to worker threads.
Also performed a small cleanup of poll_add_dcb to make it more readable.
Thread-local non-POD types are not supported on CentOS 6 and thus they
need to be replaced with pointers to the relevant objects and initialized
at runtime.
In addition to this, functor objects don't appear to work as expected in
CentOS 6 and replacing them with a simple for-loop seems to work.
When the SSL fails to initialize, the errors from OpenSSL should be
logged. This helps to diagnose what is wrong if the error relates to the
certificate files or private keys.
Cleaned up the documentation and reformatted the parameter list of
listener creation to be made out of links.
Added some comments to the resource declarations in resource.cc to prevent
the order of them from being altered.
Added missing SSL parameters to servers resource output as well as added
the processing of these parameters when servers are created. It is
preferable to define servers as either encrypter or plain and to prevent
the modification of this at runtime.
The authentication errors were not sent as the connection was closed
immediately. The reason for this was the fact that if a client request
uploaded data with bad credentials, MaxScale would not send a response if
the connection was kept open. Closing the socket solved the hang but
caused confusing errors on the client side.
The libmicrohttpd library appears to require full processing of any data
uploaded by a client request before a request can be sent. With this
change, the clients receive proper authentication errors in all cases.
The enabled admins for the Linux users were shown as basic users. This was
caused by the separation of the two admin types.
Added tests that check that enabled Linux accounts show the correct type
in the output.
Now it is also possible to ensure that a DCB stays alive while
a task referring to it is posted from one worker to another.
That will be implemented in a subsequent commit.
The polling mechanism can now optionally be used for managing
the lifetime of an object placed into the poll set.
If a MXS_POLL_DATA has a non-null 'free', then the reference count
of the data will be increased before calling the handler and
decreased after. In that case, if the reference count reaches 0,
the free function will be called.
Note that the reference counts of *all* MXS_POLL_DATAs returned
by 'epoll_wait' will be increased before the events are delivered
to the handlers individually for each MXS_POLL_DATA, and then once
all events have been delivered, the reference count of each
MXS_POLL_DATA will be decreased.
This ensure that if there are interdependencies between different
MXS_POLL_DATAs returned by one call to 'epoll_wait', the case that
an MXS_POLL_DATA is deleted before its events have been delivered
can be avoided by using the reference count for lifetime management.
In subsequent commits, the reference count will be taken into use
in the lifetime management of DCBs.
When something fails inside dcb_connect we rewind the situation
properly, without calling any of the close functions intended for
shutting down a properly created DCB. That way they can be simplified
and once the reference counting is taken into use it is sufficient to
call dcb_dec_ref(dcb) instead of dcb_free_all_memory().
If a fake event is added to the current dcb, we arrange things so
that it is delivered immediately when the handling of the event(s)
during which the fake event was added, has been performed.
Otherwise the event is delivered via the event loop.
