RENAME TABLE is now fully supported and works as expected. With the fix to
table versioning, the new table name will receive the latest version
number.
The table versions are now stored in memory and are only resolved on
startup. This simplifies things and removes the need to know where the
data is stored as that information is not available to the Rpl class.
This adds preliminary support for renaming tables. There is still a
problem where the table version will always be set to 1 on a rename. This
should not be done and the version should be set to the largest value that
ever was for that table.
When lazy_connect is enabled and the first query is `SET autocommit=0`, a
master connection can be created. If it is, then the m_current_master
pointer must also be updated.
Also fixed the case where a failure to connect to one slave would cause
the connection attempts to stop too early.
TIMESTAMP2, DATETIME2 and TIME2 values with decimal parts are now
correctly converted into their string forms. Previously the decimal part
was ignored but most of the code required to extract it was in place.
The unsigned integers that would previously be interpreted as negative
values are now correctly converted into their corresponding avro
values. Due to a limitation in the Avro file format, 64-bit unsigned
integers cannot be represented in their unsigned form.
Since both the signed and unsigned versions of a 32-bit integer cannot fit
into a single Avro int, the type for these was changed to long. This is a
backwards incompatible change which means files generated with older
versions will not convert unsigned values correctly.
The unsignedness of a column is now retained in the Column type as well as
the JSON schema. This allows correct conversion of unsigned integer types
which will be done in a later commit.
This allows the same verbose information to be logged in the cases where
it is of use. Mostly this information can be used to figure out why a
certain session was closed.
By doing the reconnection only when a new query arrives, we prevent the
excessive reconnecting that is done when a server's actual and monitored
states are in conflict.
Authenticators and monitors now use SSL when configured. The fix has two parts:
1) Removed the extra SSLConfig inside SSLProvider, as SSLContext already contains
the config.
2) When inputting parameter values to mysql_ssl_set(), empty strings are converted
to NULL-pointers as the function expects those for unused values.
If a master failed during an ongoing session command history replay, it
would be treated as if a normal session command failed which would result
in the already executed session command being re-executed on all servers
at the wrong logical position.
To fix this, the history replay must be distinguished from normal session
command execution. When a connection replaying the history fails, the
query routing simply needs to be attempted again.
If session command execution during server reconnection caused a query to
be queued, the query would be put on the tail end of the queue. This would
cause queries to be reordered if the queue wasn't empty. The correct thing
to do would be to put the next pending query back at the front of the
queue.
If a master reconnection occurred after the session command history was
disabled due to the limit being exceeded, a debug assertion would be hit
in prepare_target. This assert makes sure that a connection can be safely
created to the server which means that in release mode builds the session
state would be inconsistent on the new master.
As this is an unrecoverable situation, the session should stop immediately
even if delayed_retry is enabled. Currently the session will continue
until the delayed retry timeout is hit. This happens due to the fact that
the delayed retry mechanism handles all errors in a similar way.
When a query returns a WSREP error, most of the time it is not something
the client application is expecting. To prevent this from affecting the
client, it can be treated the same way a transaction rollback is treated:
ignore the error and try again.
The expected response counter was not decremented if a transaction replay
was started. This caused the connections to hang which in turn caused the
failure of the mxs1507_trx_stress test case.
If the slave's response differs from the master and the slave sent an
error packet, log the contents of the error. This should make it obvious
as to what caused the failure.
The assertion in routeQuery that expects there to be at least one ongoing
query would be triggered if a query was received after a master had failed
but before the session would close. To make sure the internal logic stays
consistent, the error handler should only decrement the expected response
count if the session can continue.
This could end up in infinite mutual recursion if no responses are
expected. Although this does not happen now that MXS-2587 is fixed, the
code should not even be there.
If a transaction replay fails, no queries must be routed before the
connection is closed. This could happen if the client received the error
from the replay failure and closes the connection before the fake hangup
generated by the replay failure is processed.
