Allocating the session before a DCB guarantees that at no point will a DCB
have a null session. This further clarifies the concept of the session and
also allows the listener reference to be moved there.
Ideally, the session itself would allocate and assign the client DCB but
since the Listener is the only one who does it, it's acceptable for now.
Whenever a client DCB is accepted, a session for it is allocated. This
simplifies the handling of shared data between DCBs by allowing it to be
placed inside the session object. Currently, the data is stashed away in
the client DCB.
Allocating DCB with new allows the use of C++ objects in the DCB
struct. Also the explicit poll field can be replaced by inheriting from
MXB_POLL_DATA.
The value would otherwise be assigned outside of it and in some cases not
at all. Now all DCBs (apart from internal ones) have a valid SERVICE
pointer.
The SERV_LISTENER pointer should not be in the DCBs but in the
session. This way the listener is an attribute of a session instead of a
connection. If this is implemented, the authenticator data can be more
easily shared.
The admin files are now created with 640 permissions and automatically
created directories now properly set the permissions for the group as
well. All files and directories created by avrorouter and binlogrouter
also now correctly limit the read and write permissions only to the owner
and the group.
Drop the requirement that GTID based replication is used for
the BinLog Galera "failover" mechanism. There is no reason for
that restriction; it works just as well with file+position based
replication.
The binlogrouter uses buffers across worker threads which is no longer OK
in 2.3. The correct solution would be to store data in something other
than a GWBUF (e.g. std::vector) and protect the sharing with a mutex. The
current solution simply works around the assertions by using macros
instead of functions.
This column will be used to store the relative path of the file
where a particular event can be found.
Unless the path is stored, BLR will not be able to find an event based
on the gtid if BRL is connected to a node in a Galera cluster and updates
are made to nodes other than that node as in that case, the GTID domain id
and server id, will not identify the correct directory.
The full path is not stored in the column binlog_file as the path
would in that case (without other modifications) be visible to the
client.
This only deactivates some of the more heavy-handed features. All files have
been formatted with the new settings, which seems to have only affected lines
which were not formatted before.
Changes to the ChangeMasterOptions made it non-trivial so it cannot be
safely memset anymore. The maxavrocheck was missing the linkage to the
maxscale-common library.
See script directory for method. The script to run in the top level
MaxScale directory is called maxscale-uncrustify.sh, which uses
another script, list-src, from the same directory (so you need to set
your PATH). The uncrustify version was 0.66.
If secondary masters are defined, MASTER_USE_GTID=Slave_pos must
be specified for the default master.
If MASTER_USE_GTID is specified, only Slave_pos is allowed as
value.
The variable storing the configuration index renamed from
'current_config' to 'config_index'.
In the code the same terminology is used as in the documentation.
"Default" is is used for referring to the default connections
(earlier "primary" was used) and the secondary connections are
referred to as "secondary" (earlier "alternative" was also used).
- When specifying a configuration, if it already exists use
the existing configuration as the default, thus allowing you
to change only a specific configuration value.
- When specifying a new alternative configuration, use the
primary (aka first) configuration as the base.
- If MASTER_HOST is changed on the primary (first, nameless)
configuration, then all configurations are erased.
- At "SLAVE START", always start from the first configuration.
