cb50622...
by
Julius Goryavsky <email address hidden>
MDEV-28423 continuation: Galera progress reporting + rolling updates
A new feature to support progress reporting (including progress
reporting in the JSON format) that was added in 10.9 can crash the
rolling update scenario if the old version donor node does not pass
the "total" tag in the MAGIC_FILE to the joiner node. The "grep"
utility that is used to extract this tag in this case will return
an empty string, which will then be substituted into the "if"
statement, resulting in a syntactically invalid construct.
This commit corrects this issue.
Also, when using the previous fixes (from MDEV-28423 and from
MDEV-28593), authentication errors are possible in case of mixing
versions at the opposite sides - if the donor is newer than joiner,
due to incorrect reading of the new MAGIC_FILE format by older node
versions (from the joiners side). This problem is also fixed here,
taking advantage of the fact that older versions are still able
to read GUID coordinates even if multiple strings are passed to
them at the end.
In addition, the new progress reporting exchanges the length of
the transmitted data between the donor and the joiner before the
start of the transfer, but does not use this information on the
joiner side, which can lead to incorrect calculation of progress
by the joiner (not synchronous with calculations from the donor
side) if from the joiner side reporting works in compatibility
mode with older versions. This commit moves the construction
of the command line for progress reporting to a point where
we already know the size and can use that knowledge.
Also, to facilitate SST script support in the future, the
script code now has been made unified between all versions
from 10.3 to 10.9.
136578b...
by
Julius Goryavsky <email address hidden>
MDEV-28583 continuation: rc handling in Galera SST scripts
Careful protection against unexpected termination inside signal
handlers (even if for some complex reason the "rm" utility will
return a non-zero error code due to failures) and, conversely,
removing unnecessary protection outside signal handlers, as this
can mask errors in script or in server operation.
9d4f20e...
by
Julius Goryavsky <email address hidden>
MDEV-28583: Galera: binlogs disappear after rsync IST
This commit sends a flag indicating the presence of the "--bypass"
option from the donor node to the joiner nodes during rsync IST,
because without such a flag it is impossible to distinguish IST
from the SST on the joiner nodes (in IST/SST scripts, because the
"--bypass" option is still not passed to scripts from server code).
Specifically, this fixes an issue with binary logs disappearing
after IST (via rsync). There are also changes to diagnostic messages
here that will make it easier to diagnose script-related problems
in the future when debugging and when checking the logs. This commit
also adds more robust signal handlers - to handle exceptions during
script execution. These handlers won't mask some crashes and it
also unifies exit codes between different scripts. These changes
have already been helpful to debugging "bypass" flag handling.
a3c46b1...
by
Julius Goryavsky <email address hidden>
MDEV-28423: Galera IST is failing on Joiner node
This commit fixes an issue with IST handling in
version 10.9 which is a regression after MDEV-26971
and related to trying to get a non-existent "total"
tag on the IST branch (this tag is only defined in
SST mode).
e03e722...
by
Michael Widenius <email address hidden>
Fixed warning from UBSAN
The warning comes from copying POSITION objects where 'type' is not
initialized. This does not affect any production code as when 'type'
was compared/used, it was always initialized.
Removed by initializing the type variable in the constructor
MDEV-28471 mysql_install_db.exe does not work with --innodb-page-size=64K
The error message "InnoDB: innodb_page_size=65536 requires innodb_buffer_pool_size >= 20MiB current 10MiB" is the relevant one.
The root cause:
mysql_install_db bootstraps with --innodb-buffer-pool-size=10M.
Small bufferpool is here by design - bootstrap should succeed,
even if there is not much RAM available, bootstrap does not need that much
memory.
For pagesize 64K specifically, Innodb thinks it needs a larger bufferpool,
and thus it lets the bootstrap process die (although the expected behavior
in this case would be to adjust value, give warning and continue)
The workaround:
- pass --innodb-buffer-pool-size=20M, which is suitable for all page sizes.
- check the same limit in MSI custom action.
MDEV-28342: sys.create_synonym_db fails when a temporary table masks a base table
- This commit rely on MDEV-28391
- When temporary table shadows the base table, error is raised (it can be changed if needed),
since the procedure is relying on creating the views and view cannot be created from the temporary table.
MDEV-28073 Query performance degradation in newer MariaDB versions when using many tables
The issue was that best_extension_by_limited_search() had to go through
too many plans with the same cost as there where many EQ_REF tables.
Fixed by shortcutting EQ_REF (AND REF) when the result only contains one
row. This got the optimization time down from hours to sub seconds.
The only known downside with this patch is that in some cases a table
with ref and 1 record may be used before on EQ_REF table. The faster
optimzation phase should compensate for this.
