maria:bb-11.3-mdev-32640-commented-global

Last commit made on 2024-02-06
Get this branch:
git clone -b bb-11.3-mdev-32640-commented-global https://git.launchpad.net/maria

Branch merges

Branch information

Name:
bb-11.3-mdev-32640-commented-global
Repository:
lp:maria

Recent commits

868a6eb... by Yuchen Pei <email address hidden>

MDEV-32640 [wip] add an in_place_update field to sys_var_charptr

1261570... by Yuchen Pei <email address hidden>

MDEV-28856 Add remaining Spider table options

MDEV-27106 added REMOTE_TABLE, REMOTE_DATABASE, REMOTE_SERVER spider
table options. In this commit, we add all remaining options for table
params that are not marked to be deprecated.

All these options are parsed as strings from sql statements and have
string values at the sql level, so that we can determine whether it is
specified by checking its nullness.

The string values are further parsed by Spider into their actual types
in the SPIDER_SHARE, including string list, bounded nonnegative int,
bounded nonnegative int list, nonnegative longlong, boolean, and key
hints. Except for string lists, all other types are validated during
this parsing process.

Most of the options are backward compatible, i.e. they accept any
values that is accepted by there corresponding param parser. The only
exception is the index hint IDX which corresponds to the idxNNN param
name. For example,

'idx000 "f PRIMARY", idx001 "u k1"'

translates to

IDX="f PRIMARY u k1".

We include a test with all options specified, and tests involving
spider table options of all actual types.

Any table options, if present, will cause comments to be ignored with
a warning. The warning can be disabled by setting a new spider
global/session system variable spider_suppress_comment_ignored_warning
to 1.

Another global/session variable introduced is spider_ignore_comments,
which if set to 1, will cause COMMENT and CONNECTION strings to be
ignored unconditionally, whether or not table options are specified.

c507678... by THIRUNARAYANAN BALATHANDAYUTHAPANI

MDEV-28699 Shrink temporary tablespaces without restart

- Introduced the variable "innodb_truncate_temporary_tablespace_now"
to shrink the temporary tablespace.

Steps for shrinking the temporary tablespace:

1) Find the last used extent in temporary tablespace
by iterating through the BITMAP in extent descriptor pages

2) If the last used extent is lesser than user specified size
then set desired target size to user specified size

3) Store the page contents of "to be modified" extent
descriptor pages, latches the "to be modified" extent
descriptor pages and check for buffer pool memory availability

4) Update the FSP_SIZE and FSP_FREE_LIMIT in header page

5) Remove the "to be truncated" pages from FSP_FREE and
FSP_FREE_FRAG list

6) Reset the bitmap in the last descriptor pages for the
"to be truncated" pages.

7) Clear the freed range in temporary tablespace which
are to be truncated.

8) Evict the "to be truncated" temporary tablespace pages
from LRU list.

9) In case of multiple files, calculate the truncated last
file size and do truncation in last file

10) Commit the mini-transaction for shrinking the tablespace

7b842f1... by Marko Mäkelä

Merge 11.2 into 11.3

d0f8dfb... by Yuchen Pei <email address hidden>

Merge branch '11.1' into 11.2

c4a506f... by Yuchen Pei <email address hidden>

MDEV-32525 Validate --redirect_url supplied as server flag

Like sql_mode, we factor out of ON_CHECK function for export, to be
used in get_options() during server startup, for validation of
--redirect_url value.

5af70de... by Yuchen Pei <email address hidden>

MDEV-15935 Adding global/session system var redirect_url

Adding a global/session var `redirect_url' of string type. The initial
value is empty. Can be supplied in mysqld with --redirect-url or set
in --init-connect. A valid redirect_url should be of the format

{mysql,mariadb}://host[:port]

where <host> is an arbitrary string not containing colons, and <port>
is a number between 0 and 65535 inclusive.

The variable will be used by the server to notify clients that they
should connect to another server, specified by the value of the
variable, if not empty.

The notification is done by the inclusion of the variable in
session_track_system_variable.

6151bde... by Yuchen Pei <email address hidden>

cleanup: string sys_var types

Merge sys_var_charptr with sys_var_charptr_base, as well as merge
Sys_var_session_lexstring into Sys_var_lexstring. Also refactored
update methods of sys_var_charptr accordingly.

Because the class is more generic, session_update() calls
sys_var_charptr::session_update() which does not assume a buffer field
associated with THD, but instead call strdup/free, we get rid of
THD::default_master_connection_buff accordingly. This also makes THD
smaller by ~192 bytes, and there can be many thousands of concurrent
THDs.

d16817c... by Sergei Golubchik

typo fixed. it's wsrep-causal-reads

0c1bf5e... by Brandon Nesterenko

MDEV-27247: Add keywords "SQL_BEFORE_GTIDS" and "SQL_AFTER_GTIDS" for START SLAVE UNTIL

New Feature:
============
This patch extends the START SLAVE UNTIL command with options
SQL_BEFORE_GTIDS and SQL_AFTER_GTIDS to allow user control of
whether the replica stops before or after a provided GTID state. Its
syntax is:

START SLAVE UNTIL (SQL_BEFORE_GTIDS|SQL_AFTER_GTIDS)=”<gtid_list>”

When providing SQL_BEFORE_GTIDS=”<gtid_list>”, for each domain
specified in the gtid_list, the replica will execute transactions up
to the GTID found, and immediately stop processing events in that
domain (without executing the transaction of the specified GTID).
Once all domains have stopped, the replica will stop. Events
originating from domains that are not specified in the list are not
replicated.

START SLAVE UNTIL SQL_AFTER_GTIDS=”<gtid_list>” is an alias to the
default behavior of START SLAVE UNTIL master_gtid_pos=”<gtid_list>”.
That is, the replica will only execute transactions originating from
domain ids provided in the list, and will stop once all transactions
provided in the UNTIL list have all been executed.

Example:
=========
If a primary server has a binary log consisting of the following GTIDs:

0-1-1
1-1-1
0-1-2
1-1-2
0-1-3
1-1-3

If a fresh replica (i.e. one with an empty GTID position,
@@gtid_slave_pos='') is started with SQL_BEFORE_GTIDS, i.e.

START SLAVE UNTIL SQL_BEFORE_GTIDS=”1-1-2”

The resulting gtid_slave_pos of the replica will be “1-1-1”.
This is because the replica will execute only events from domain 1
until it sees the transaction with sequence number 2, and
immediately stop without executing it.

If the replica is started with SQL_AFTER_GTIDS, i.e.

START SLAVE UNTIL SQL_AFTER_GTIDS=”1-1-2”

then the resulting gtid_slave_pos of the replica will be “1-1-2”.
This is because it will only execute events from domain 1 until it
has executed the provided GTID.

Reviewed By:
============
Kristian Nielson <email address hidden>