All prepare commands are executed in every backend server currently connected.
All executes are routed to master. If stmt type was recorded in prepare phase in rwsplit router, read-only stmts could be routed to slaves.
COM_STMT_PREPARE gets arbitrary number of response packets from backend database. Since statements are prepared in every backend server and only one multi-packet response can be replied to client, redundant multi-packet responses are discarded. This is done in router. Mechanisms from session command handling are utilized with little changes: router must identify when response consists of multiple packets so that it knows to calculate the number of packets in response and that it is able to discard correct number of packets.
Information to the reply-handling router is provided by backend protocol, which includes a ordered list of commands of commands sent to protocol-owning backend server. A command is stored to protocol struct in mysql_backend.c:gw_MySQLWrite_backend if the statement buffer's type has GWBUF_TYPE_SINGLE_STMT set in mysql_client.c:route_by_statement. GWBUF_TYPE_SINGLE_STATEMENT indicates that there is single statement in the buffer, as opposite to Read Connection router, which accepts streaming input from client.
Added server command list structure which is included in MySQLProtocol. It holds command and number of response packets the command causes backend server to send as a response. Added set of functions related to protocol command and response packets counting etc.
cloesSession was called in session.c:session_free if all DCBs had been removed their references to session. closeSession, however, is function which handles closing router. Router is responsible for closing all backend DCBs (=connections). Thus, calling sessionClose after all backend connections had been removed already is unnecessary and causes assertion traps.
Simply removed the call.
Added depth level 0 for each cluster node, this way the algorithm for
root master selection will the same as in mysql replication:
the root master is server at lowest replication depth with MASTER bit
set
Here for Galera we assume all the servers are at the same level, that’s
0
New rules for selecting Master/Slaves are based on MySQL depth in the
replication tree.
The only Master is the root server with SERVER_MASTER bit set
All other servers even with both SLAVE and MASTER bit will be selected
as slaves
