mysql/mysql-server

(cherry picked from commit 06db648de3b080bae518a083dd122ea10b058c04)

…SYNC_DELAY"

This reverts commit 5654f5ec294f3d8ea087029ba9b47ad3eb2835b3.

--SUPER-READ-ONLY OPTION

Post push fix to address test issue.

Fix a memory leak on Gcs_view handling on gcs_event_handlers.cc.

…OF CMAKE

When upgrading to cmake3.8 bulding of MSI packages failed because the WiX
toolkit is not found.

Solution: Search in ProgramFiles(x86) in addition to existing search paths.

Post push handled windows build issues and doxygen warnings.

… ARE FEEDING DATA INTO IT

Post push fix to add "have_debug.inc" to a gr_stop_async_on_stop_gr test case.

Handled failing builds due to missing sstream header file.

Description:
At present not all scenarios of Group membership changes are logged.
When member join or member leaves, customers cannot identify same by looking
at logs. View changes are not logged. Present logging does not assist DBAs with
corrective measures during network partitions or inform DBAs when member
re-connects.
Also at some places we are logging internal debug messages which cannot be decoded
by DBAs.
Important member related configuration is also not logged.

Resolution:
Logging has been analyzed for:
1. View changes
2. Member join
3. Member leave(graceful and crash)
4. Member unreachable
5. Member re-connect
6. Removal of debug messages
7. Member configuration has been extended with Member_id, member_uuid,
   single_primary_mode, and group_replication_auto_increment_increment
8. Improvements in single-primary mode status reporting and member
   leaving/joining logging
New messages have been added and change to existing messages where required has
been done.

… ARE FEEDING DATA INTO IT

Issue
=====
If a member that has asynchronous channels feeding data into it - either on
multi-primary deploy or the primary on single-primary deploy - does stop, all
asynchronous channels must be stopped to avoid that changes are made locally
(not replicated to the group).

Even when super_read_only it is set on STOP GROUP_REPLICATION, that will not
affect already running asynchronous which can still do changes.

Solution
========
When group replication stops, due to error or due to executing stop
group_replication command, all asynchronous channels are stopped.

Problem: When sync_binlog=0, sync stage in binlog group commit is
         never reached. But still each binlog group is waiting for
         BINLOG_GROUP_COMMIT_SYNC_DELAY seconds before entering into
         sync stage.

Fix: Now the code is changed in such a way that the waiting logic considers
     sync_binlog=0 case and skips delay logic in such case.

… COMMAND

Package redhat-rpm-config adds some convenience macros when building
on RHEL6 and later. Recommend package when rebuilding rpm package.

RHEL5 is EOL, remove from comment.

Change based on contribution from Simon Mudd, bug#87098.

Add option to skip automatic init, making it possible to opt-out.
Default is still to perform init.

To skip init, create file /etc/sysconfig/mysql with contents like:

NO_INIT=true

…IALIZE

Since MySQL 5.7 mysql_install_db has been deprecated, mysqld --initialize is
now preferred. Switch mysqld_multi.sh.

Based on contribution from tigerb, bug#87080.

Change is 5.7 specific, MySQL 8 was fixed by:
 WL#9071: Remove mysql_install_db and server --bootstrap option

                       COL), NAME_CONST('NAME', NULL))

Backport of Bug#19143243 fix.

NAME_CONST item can return NULL_ITEM type in case of incorrect arguments.
NULL_ITEM has special processing in Item_func_in function.
In Item_func_in::fix_length_and_dec an array of possible comparators is
created. Since NAME_CONST function has NULL_ITEM type, corresponding
array element is empty. Then NAME_CONST is wrapped to ITEM_CACHE.
ITEM_CACHE can not return proper type(NULL_ITEM) in Item_func_in::val_int(),
so the NULL_ITEM is attempted compared with an empty comparator.
The fix is to disable the caching of Item_name_const item.

Desciption:

This test create a group of two members, where one member is put in a UNREACHABLE state
and then INSERT is executed which gets blocked, then when we try to execute UNINSTALL
command it returns an error that plugin cannot be uninstalled now.

But if the UNINSTALL is executed before the plugin receives INSERT query, the plugin
will be able to UNINSTALL successfully, that results in a test failure as is
expecting UNINSTALL to fail with error ER_PLUGIN_CANNOT_BE_UNINSTALLED.

Solution:

To prevent the uninstall getting executed successfully, we wait for server to receive
the INSERT, before executing the UNINSTALL of Group Replication plugin.

              LAST BYTE ONLY (YASSL)


Description:- TLS cipher negociation happens incorrectly
leading to the use of a different

Analysis:- YaSSL based MySQL server will compare only the
last byte of each cipher sent in the Client Hello message.
This can cause TLS connections to fail, due to the server
picking a cipher which the client doesn't actually support.

Fix:- A fix for detecting cipher suites with non leading
zeros is included as YaSSL only supports cipher suites with
leading zeros.

NOT WRITABLE

Problem: C-library function freopen() is not atomic. It closes the
stream given as argument before trying (and thereby checking if it is
possible) to open the file which the stream is to be associated with. So
in the event that the open() fails, the user is left without a working
stream where the error message for the failed open can go. Likewise, any
buffered messages not yet written to the stream are also lost.

Solution: Stop using freopen() and re-implement my_freopen() using
fopen(), fileno() and dup2(). That way any error from open() (or
fileno()) is caught before doing anything which affects the stream.
According to the man-page, dup2() is atomic.

--SUPER-READ-ONLY OPTION

Problem:
========
After upgrading MySQL server from 5.7.17 to 5.7.18
'mysqlrplsync' utility tool fails with following error.

ERROR: Query failed. 1290 (HY000): The MySQL server is
running with the --super-read-only option so it cannot
execute this statement

When this occurs, the Slave_SQL_Running on the slave server
stops running and needs to be manually started again. The
slave server does have the super-read-only option set to
true. When running MySQL 5.7.17 this wasn't an issue.

Analysis:
========
When replication information repository is set to 'TABLE'
few replication specific administration commands listed
below, will try to update the repository tables.

1) START SLAVE
2) STOP SLAVE
3) CHANGE MASTER
4) RESET SLAVE
5) RESET MASTER
6) SET GLOBAL GTID_PURGED
7) FLUSH BINARY LOGS
8) 'gtid_executed' TABLE compression thread.

First three commands were fixed as part of Bug#22097534:
SUPER_READ_ONLY ABORTS STOP SLAVE IF
RELAY_LOG_INFO_REPOSITORY=TABLE, DBG CRASH

The reset of the commands were fixed as part of
Bug#22857926: ASSERTION `! IS_SET()' AT SQL_ERROR.CC:38 IN
READ_ONLY MODE FOR MANY RPL CMDS.

During the Bug#22857926 fix, the previous Bug#22097534 fix
specific changes were reverted a new approach was taken.

The new approach used a flag named 'ignore_global_read_lock'
whose intention is to ignore the read only option and allow
commits to replication specific system tables.  If this flag
is set then the additional check for 'read only' option is
not done.

But the above fix works fine only when 'AUTOCOMMIT=ON'.  In
the case of AUTOCOMMIT=OFF the 'ignore_global_read_lock'
flag is not set. Hence commands fail to ignore read_only
restriction.

STOP SLAVE command behavior explained in detail:

STOP SLAVE command is an IMPLICIT COMMIT command, i.e
parser will append an explicit BEGIN and COMMIT for this
command.

BEGIN
STOP SLAVE;
COMMIT;

STOP SLAVE command will try to stop both the applier thread
and receiver thread and update their positions in
'slave_relay_log_info' and 'slave_master_info' tables.

Case: AUTOCOMMIT=ON.

1) BEGIN

2) Update 'slave_relay_log_info' table and commit as a real
transaction.

System_table_access::close_table will invoke
ha_commit_trans with 'ignore_global_read_lock=true'.

Since autocommit is 'ON' each statement will do a complete
commit and clean up the transaction context.

3) Update 'slave_master_info' also does the same.

4) COMMIT.

COMMIT will invoke 'trans_commit_implicit'. It will check
if there any active transactions which needs to be committed
implicitly. Since step 2-3 are real commit transactions this
final commit has nothing to do. It will exit without
proceeding further.

Case: AUTOCOMMIT=OFF.

1) BEGIN

2) Update 'slave_relay_log_info' table. This transaction is
considered as a multi statement transaction mode, it will
not commit on its own. It will wait for final COMMIT
execution.

3) Update 'slave_master_info' also does the same.

4) COMMIT.

COMMIT will invoke 'trans_commit_implicit'.

It will check if there any active transactions which needs
to be committed . Since there are active transaction
sessions from step 2-3 'ha_commit_trans' will be called as
shown below.

'trans_commit_implicit' will invoke
ha_commit_trans (thd,all=true,ignore_global_read_lock=false)

This will not pass the read_only check and the command will
fail.

This issue happens for commands that update info tables
other than 'gtid_executed' table. In case of 'gtid_executed'
table irrespective of autocommit variable all the
transactions are considered as 'real' transactions and they
will do complete commit.

Fix:
===
Introduced a new variable, to flag the sql command under
execution to ignore the read_only/super_read_only. If the
variable is set then the command is allowed to execute even
though read_only/super_read_only is enabled otherwise
command is blocked.

Description: Certificates generated by mysql server and
             mysql_ssl_rsa_setup do not use X509v3 and
             related extensions.

Solution: Added X509v3 extension.

…GROUP REPLICATION START

Bug#26037344 THE DELAYED PLUGIN INITIALIZATION THREAD IS LEFT RUNNING WHEN IT IS NOT NEEDED

Client complaints existed about how group replication would make
connections hang on server start if the plugin was also
starting. i.e., joining the group.
To solve this we reworked the delayed initialization mechanism used on
server starts, so it only blocks connections until the server is in
read mode, not waiting for the member to join the group as before.
This rework also solves the issue of the thread responsible for this
task being initialized and running even when not needed.

               A HOST WITH AHOSTNAME OF 69 CHARACTERS

DESCRIPTION:
===========
When a connection is made from a host with a hostname
length of more than HOSTNAME_LENGTH characters,
MySQL crashes with a buffer overflow.

ANALYSIS:
========
If the hostname of the connecting host is greater than
HOSTNAME_LENGTH (60 chars), copying the hostname to the
performance schema table field which is limited to
HOSTNAME_LENGTH characters results in a crash.

FIX:
===
The fix is to truncate the hostname to HOSTNAME_LENGTH
number of characters before adding them to the performance
schema tables which record host information and details.
This makes sure that the client connection is established
successfully.

Analysis
========
CREATE TABLE of InnoDB table with a partition name
which exceeds the path limit can cause the server
to exit.

During the preparation of the partition name,
there was no check to identify whether the complete
path name for partition exceeds the max supported
path length, causing the server to exit during
subsequent processing.

Fix
===
During the preparation of partition name, check and report
an error if the partition path name exceeds the maximum path
name limit.

This is a 5.5 patch.