The test performs the following:
CREATE tbl (x INT PRIMARY KEY)
t1 t2
BEGIN BEGIN
INSERT INTO tbl VALUES (1)
SELECT * FROM tbl FOR UPDATE
That will cause t2 to wait.
INSERT INTO tbl VALUES (0)
That will cause t2 to be rolled back due to a deadlock.
Without transaction replay, the SELECT will return with an error.
With transaction replay, the deadlock error will be caught, the
transaction replayed and SELECT will return successfully.
As an error returned by the server is now stored inside RWBackend,
irrespective of whether it is returned solely or e.g. last after
a result set, there is no need to examine the GWBUF in rws, but
we can use the information that exists.
This is the base for Smart Router. Review and TODO comments are in the
code. This commit will be squashed several times so don't pay attention to this
specific commit message. I will add and remove TODO's in the code, rather
than save them in git commits. RBCommons will contain the history.
Before the MXS-2250 fix, the following ends with an error:
CREATE TEMPORARY TABLE t (f INT);
DESCRIBE t;
Reason is that the first is sent to the master (and the table will
not be replicated to slaves) and the latter to some slave.
When a statement like 'DESCRIBE tbl' is classified, the table
name will now be available so that a router can check whether the
table is a temporary one. In that case, the statement must be sent
to the master.
The command script is now stored in string form. Substitution is performed
using normal string methods instead of regular expressions, since all used
substitutions are simple string replacements. Tokenization is performed after
substitution.
By iterating over the servers and sending the master's charset we are
guaranteed a "known good" charset. This also solves the problem where a
deactivated server reference would be used as the charset and server
version source.
If the execution of a session command fails on a master, it is retried
again. If the master is not available, the response will be returned from
one of the slaves.
The retrying of a read on a slave should only be done when the failing
server is waiting for a result and it was the last server from which a
result was expected.
If the master fails when a session command is being executed with
delayed_retry enabled, a null query would get placed into the query
queue. This change simply prevents the crash and closes the session even
though the query could be retried.
The bug appears when a session command that is executed on the master
fails. The logic in the code doesn't take this case into consideration
when it processes failed connections.
