The addition of field types and lengths wasn't added to the avrorouter
ALTER TABLE handler. This caused crashes when an alter table was done and
new rows were inserted afterwards.
The type and name parsing functions could move outside of allocated memory
as they didn't check for the terminating null character. Also fixed the
printf format string used when the list of used tables is being created.
Fixed CDC testing connector to abort on error and added some extra output
to the cdc_datatypes test.
The schema generator program needs to add the real_type and length fields
if the data types define them.
Also fixed a bug where the real_type and length fields were checked for
generated fields.
The avro schema allows custom properties to be defined for the schema
fields. The avrorouter stored extra information about the table into the
schema for later use.
Currently, this information is only generated by the avrorouter
itself. Further improvements to the schema generator scripts need to be
done.
When the binlog has been read, it needs to be treated as if the
transaction or row limit has been hit. This will cause all tables to be
flushed to disk before the files are indexed.
When a MariaDB 10.0 DATETIME field with a custom length was defined, the
field offsets weren't calculated properly.
As there is no metadata for pre-10.1 DATETIME types with decimal
precision, the metadata (i.e. decimal count) needs to be gathered from the
CREATE TABLE statement. This information is then used to calculate the
correct field length when the value is decoded.
This change does not fix the incorrect interpretation of the old DATETIME
value. The converted values are still garbled due to the fact that the
value needs to be shifted out of the decimal format before it can be
properly converted.
The fixed length string processing assumed that the string lengths were
contained in the first byte. This is not true for large fixed length
strings that take more than 255 bytes to store. This consists of
multi-byte character strings that can take up to 1024 bytes to store.
Printing all output as raw bytes allows MaxScale to control the formatting
process. This also removes the need to convert the bytes to Python strings
and the need to parse the JSON.
The order of the servers in the service definition could break the
master_accept_reads functionality.
When the first server defined in the service is a slave, it will always be
picked as the first candidate for reads. The master would only be
considered as a candidate for reads if no previous candidate was
available. For this reason, the master_accept_reads only worked when the
first server in the list was the master.
The Avro C API fails to write bytes of size zero. A workaround is to write
a single zero byte for each NULL field of type bytes.
Also added an option to configure the Avro block size in case very large
records are written.
The rotations of binlogs weren't detected as the file names weren't
compared.
Moved the indexing of the binlogs to the end of the binlog
processing. This way the files can be flushed multiple times before they
are indexed.
The old DATETIME format wasn't processed properly which caused a
corruption of following events.
A BLOB type value could be non-NULL but still have no data. In this case,
the value should be stored as a null Avro value.
The DECIMAL value type is now properly handled in Avrorouter. It is
processed into an Avro double value when before it was ignored and
replaced with a zero integer.
Backported to the 2.0 branch.
The backtick was copied to the field name and converted to an underscore
when the name was transformed into a valid Avro identifier. This caused
one extra character to appear in the field name in the Avro schema files.
As the cdc_kafka_producer script is an example, it should flush the
producer after every new record. This should make it easier to see that
events from MaxScale are sent to Kafka.
The firewall filter should allow COM_PING and other similar commands to
pass through as they are mainly used to check the status of the backend
server or to display statistics. The COM_PROCESS_KILL is the exception as
it affects the state of the backend server. This is better controlled with
permissions in the server than in the firewall filter.
Commands that require special grants aren't allowed to pass as they are
mainly for maintenance purposes and these should not be done through the
firewall.
There's no need to process the JSON twice as the Kafka producer is
expected to be used with the Python CDC client which already splits the
JSON with newlines.
Some of the JSON errors weren't handled which could cause problems when a
malformed schema definition is read.
Also added more error messages for situations when opening of the files
fails.
When a DCB error occurs, the handleError entry point of the routers is
called. The caller of this entry point expects that the error handler
marks the DCB as handled. The aforementioned behavior is wrong as the
error handler should not keep track of whether the handler was already
called.
Closing the DCB and the backend reference that uses it at the same time
makes the error handling code clearer and removes some of the assumptions
that the code made. It will cause the DCB to be closed in multiple places
but the logic of why a DCB is being closed is more visible from the code.
This change should remove all cases where a DCB is closed without a
tightly coupled backend reference.
If the `error_on_write` mode is used when a master loses the master state,
the backend would not get closed. This would allow masters that appear
back to be used which is not intended.
