The storage module is abstracted with StorageFactory that is capable
of creating Storage instances. The latter contains the data and
provides the behaviour for using the actual storage implementation,
which sits behing a C API, conveniently.
The server test used the wrong name.
MySQL users test loaded multiple modules in one function call and wasn't
appropriate for an internal test suite test as it requires a working
installation.
The cache filter didn't set the library paths before trying to load
modules.
The binlogrouter was missing a NULL check which caused a crash.
Maxadmin now supports the runtime creation of listeners. The new 'default'
value can be used to signal values that don't need to be configured and
the default value should be used.
The config_runtime.h header contains functions that can be used to
manipulate the running configuration. Currently the header contains the
function to create, add, remove and destroy servers.
If an item cannot be put to the database, it is explicitly removed
to ensure that we cannot have the situation that a stale item is
continuously returned because the updating of the value fails for
whatever reason.
If a cached entry becomes stale, then if no extra measures are
taken then every thread hitting that item while it is being fetched
from the server will also refresh it, even though it obviously is
sufficient that one does it.
Now the knowledge that the item is being refreshed is recorded,
so that all other clients are simply returned the stale item. That
way, we'll hit the server once per stale item.
The rules and users are stored in thread-local pointers which removes the
need to hold global locks. This allows greater scalability but causes a
slightly larger memory footprint. Usually the increase in memory
consumption is trivial compared to the benefits in scaling.
Using a per-thread rule and user list allows changes to be applied
immediately without locking on the instance level.
The updating of the rules uses the new functinality described in the
debugcmd.h header. The module registers two functions at startup; one for
reloading rules and one for printing them. These custom functions can be
seen in the `maxadmin list functions` output.
The packet was generated with the wrong number of elements due to usage of
sizeof on an integer where the correct type was an uint8_t.
This only fixes the malformed packets but does not fix the root cause of
the problem. The affected rows and last insert ID are length encoded
integers which should be handled. The current code treats them as one byte
fields.
Since it's a cache, we do not need to retain the data from one
MaxScale invocation to the next. Consequently, we can turn off
write ahead logging completely if we simply wipe the RocksDB
database at each startup. In addition, the location of the
cache directory can now be specified explicitly, so it can be
placed, for instance, on a RAM disk.
The prepared statements were router according to the real type instead of
being router to the master. This was caused by the change in the route
target function.
This commit adds a free() to null_auth_free_client_data, which plugs
the memory leak in maxinfo.
Also, this commit fixes some segfaults when multiple threads are
running status_row() or variable_row(). The functions use
statically allocated index variables, which often go out-of-bounds
in concurrent use. This fix changes the indexes to thread-specific
variables, with allocating and deallocating. This does seem to slow
the functions down somewhat.
The code for the utility is now stored in a separate file. This also
removes the need to include testing headers from other directories.
Also added a function to reload rules that uses the newly modified rule
parsing mechanism. This can be used later on to update the rules at
runtime.
The maxadmin interface to add servers to objects now allows a maximum of
11 objects to be listed. This will make it simpler to add a server to both
a monitor and a service in one command.
The object names in the dbfwfilter weren't very descriptive and were not
that easy to comprehend. The same goes for function names which had
somewhat cryptic names.
This fix allows the gap detection and the writing of an IGNORABLE event
only if master_event_state == BLR_EVENT_DONE.
Note: The hole is not being created if the event is bigger than 16MB
With the use_sql_variables_in=master option, readwritesplit should route
all user variable modifications and reads with user variables to the
master.
Previously, the modification of user variables was grouped into generic
system variables which caused all modifications to system variables to go
to the master only. The router requires a finer grained distiction between
normal system variable modifications and user variable modifications.
With the improvements to the query classifier, readwritesplit now properly
routes all user variable operations to the master and other system
variable modifications to all servers.
With the advent of qc_get_field_info, columns can now be matched.
However, there is still some undeterminism caused by the table
information not containing contextual information (exactly where
is the table used).
Further, suppose table X contains the column A and table Y contains
the column B, then given a statement like
SELECT a, b from X, Z;
we cannot know whether a is in X or Z, or b in X or Z, without being
aware of the schema, which we currently are not.
Consequently, as long as MaxScale is not aware of the schema, some
heuristics must be applied. For instance, if exactly one table is
referred to, then we can assume that columns that are not explicitly
qualified are from that table.
The rule tests are currently rather rudimentary and need to be
expanded.
When a connection to the master fails, readwritesplit should always treat
it the same way. Previously, if a connection to the master was lost but it
hadn't lost the master status, the failure would be treated like a slave
server failure.
When a server is created in server_create, it sets the port to the default
of 3306 if no explicit port is defined. The code that called this function
still expected a minimum of three arguments: name, address and port.
When a service is added or removed from a service, a supplementary
configuration file is created. This allows MaxScale to survive restars and
unexpected downtime even if runtime changes to the servers of a service
have been made.
With these changes, it is possible to start MaxScale without any servers,
create servers, add the created servers to services and monitors and
restart Maxscale without losing the runtime configuration changes.
