A Tester class that simplifies the creation of various cache tests.
It provides the basic mechanisms for reading statements from MySQL/
MariaDB test files, for converting statements into equivalent
cache items (key + statement) and for running various tasks in
separate threads for a specific amount of time.
RocksDB returns success when deleting a non-existing key. To deal
with that the book-keeping of LRUStorage is used and the real
underlying storage is used only if LRUStorage thinks a particular
key exists.
If no message is logged, it will be very hard to figure out where some
configurations are coming from. For this reason, it's good to log a
message whenever a persistent configuration change is taken into use.
Readwritesplit should route all queries from cloned sessions to the
master. This allows batch statements to be safely routed.
Native readwritesplit sessions only support batched writes as batched
reads aren't very common. Once readwritesplit supports batched reads, the
special handling for cloned DCBs can be removed.
The memory barrier is not needed here. Declaring poll_msg as volatile
should help with preveting some unwanted optimizations. Most likely
even that is unnecessary.
This came up when testing maxadmin "show servers", which is
surprisingly slow compared to the other commands. This change does
not help because the slowness is caused by the polling loop sleeping.
In a more busy environment the command would probably complete faster.
This should be looked at later.
Now also rudimentary tests the LRU mechanism, which at the same
time makes the name a misnomer. These will be split into separate
programs to allow tests to be run individually.
With the addition of filter capabilities, the tee filter should work with
all sorts of routers that require at most the RCAP_TYPE_CONTIGUOUS_INPUT
capability.
Due to a recent discovery of the server's capability to process multiple
requests, the filter can safely send data from one service to another
without waiting for the earlier replies.
This also fixes a minor problem with the cloning of DCBs where the backend
DCBs could end up in the wrong thread's pool.
The detailed output of the new help command was a bit too densely packed
for some commands.
Added missing values for the `alter server` command help output.
The document wraps paragraphs at 80 characters and uses triple backtick
bloks for code sections instead of indentation.
Also fixed a few typos and reworded some parts.
MXS-1060. In MaxAdmin, running "list services" will now list the
backends of each service. When running "show services", the backend
names are now printed (previously just the addresses and protocols).
Binlog server option ‘encryption_key_file=’ can now use the same key
file the MariaDB 10.1 server might have in my.cnf:
‘file_key_management_filename=‘
Note: the file content must be in clear, no key encryption.
In order to be able to test the LRU mechanism properly you need
to be able to access the head and tail from the outside. The same
is regarding the size and items in the cache. In order to be able
to test that the guarantees are upheld, you need to be able to
access those values from the outside.
It would seem that the likelyhood of different threads accessing
the same items at the same time is greater if each thread continuosly
loops across all items from beginning to finish. That will also ensure
that head and tail surely are accessed. In addition, some function names
have been disambiguated.
If the underlying storage does not support max_count and/or max_size
and it accordinly is decorated with LRUStorage, then create the real
storage as single-threaded. Since LRUStorage will do locking it is of
no use to do locking in the real storage as well.
Here we create a number of threads and then randomly start getting
putting and deleting values. The intent is to test that the locking
behaviour of the storage modules is correctly implemented.
0 is now the default of all cache configuration parameters and in
all cases the meaning is the same; that is, no limit. Internally
all limits but ttl are now for the sake of consistency 64-bit.
Smoke test for detecting errors in key generation. The input file
is a number of .test-files from the server combined into a single
one. We simply check that a unique key is generated for each
statement.
Diagnostics can be required on both instance and session level,
so both cases need to be handled explicitly.
In addition, some reinterpret_casts were changed into static_casts.
Reinterpret_cast needs to be used with the instance, which is a
void** but static_cast is sufficient for the session, which is void*.
The capability for reading MySQL/MariaDB .test-files has now been
factored out from the compare.cc test program. That way, the
functionality can be used from other test programs as well.
When the listeners were created twice, MaxScale would crash when the users
were loaded. This is caused by the fact that the DCB for the listener is
NULL for failed listeners.
If a slave fails while a non-critical read is being executed, the read is
retried on a different server. This is controlled by the new
`retry_failed_reads` option.
Only selects done that are done outside of a transaction and with
autocommit enabled are retried.
It is possible that a session is in the dummy state (a transient state)
when a backend write occurs. The check for the client protocol NULL-ness
should extend to the client DCB itself.
1. MaxAdmin now defaults to Emacs-mode. To activate Vim-mode, give
the option 'i' when starting.
2. "history" and "source"-commands are parsed correctly.
3. Added a check to DoSource() so that empty commands are not sent.
MaxScale doesn't respond to empty commands which would cause MaxAdmin
to wait forever.
MXS-873 To prevent monitors and MaxAdmin from interfering with each other,
changes to the server status flags now happen under a lock. To avoid
interfering with monitor logic, the monitors now acquire locks to all
of their servers at the start of the monitor loop and release them
before sleeping.
The binlogrouter needs to manipulate the protocol structures in order for
the resultset buffering to work correctly. If the state isn't manipulated
for COM_QUERY statements, the resultsets aren't buffered and will be
routed in separate buffers.
The backend MySQL protocol module now supports a new routing capability
which allows result sets to be gathered into one buffer before they are
routed onward. This should not be used by modules that expect large
result sets as the result set is buffered in memory.
Adding a limit on how large of a result set could be buffered would allow
relatively safe use of this routing capability without compromising the
stability of the system.
A destroyed monitor should not have any servers added to it. This allows
the servers that once were monitored by a destroyed monitor to be added to
new monitors.
Adding a server to multiple monitors is forbidden. This should be detected
and reported to the end user.
The information provided by the config_runtime system to the client isn't
as detailed as it could be. Some sort of an error message stack should be
added so that client facing interfaces could properly report the reason
for the failure. Currently the only way to detect the reason of the
failure is to parse the log files.
