… under row format

  Description
  ============
  bug#88847, this issue is related to invisible indexes feature which we ported
  from 8.0 upstream. Invisible index is not considered by slave SQL row applier
  when searching index to use, and choosed anyway as long as the index is fit for
  update.

  Solution:
  ============
  Make slave SQL applier thread respecting invisible indexes and don't choose them
  when searching index to use.

…n when slave apply binlog

  Description
  -----------
  In row binlog format, slave chose index when apply binlog use such order:
  1) primary key
  2) unique key without null columns
  3) normal index or unique key with null columns

  Actually, in situation 3 we should chose index with auto_increment column
  first, after this patch, the new order is
  1) primary key
  2) unique key without null columns
  3) normal index with auto_increment columns
  4) normal index without auto_increment columns or unique key with null columns

   Supply CPU_time metric to help analysis.

…ue an error

A new built-in function RAISE_ERROR('diagnostic-string') is needed to
let mysql users fail current statement with the desired
diagnostic-string error message and reserved sql error code.

DB2 does in its' RAISE_ERROR() function, where the function accepts
parameters of sql state and msg, and Oracle's RAISE_APPLICATION_ERROR
has similar function.

In our implementation, raise_error() accepts parameter of msg and
optional sql state, both are strings. NULL value input is not allowed
for either one, and only validate sql state is allowed.

Here are samples:

--error ER_SP_BAD_SQLSTATE

select raise_error(NULL, 'null sql state not allowed');

--error ER_MALFORMED_MESSAGE select raise_error('70001', NULL);

--error ER_SP_BAD_SQLSTATE

select raise_error('00001', 'invalid sql state');

--error ER_SP_BAD_SQLSTATE

select raise_error('666666', 'length of sql state exceeds 5');

--error ER_INTENTIONAL_ERROR

select raise_error('70001', 'this is a sample error msg');

--error ER_INTENTIONAL_ERROR

select raise_error('this is a sample error msg');

--error ER_INTENTIONAL_ERROR
select raise_error('only error message applied');

…ngine data

Alter TokuDB table comment should not using copying algorithm and
rebuild whole engine data, only FRM definition should be changed.

Make `ha_tokudb::check_if_supported_inplace_alter()` return
`HA_ALTER_INPLACE_EXCLUSIVE_LOCK` while altering comment, and mysql
server will invoke `ha_tokudb::inplace_alter_table` which will do
nothing for altering comment.

Besides table comment, there are many other create options that
should be ignored by TokuDB, and they are all handled in this patch.

Btw, this patch has been pushed to TokuDB upstream.

This patch also contains a postfix for bug#88847, which handles
cases when UK or Key with auto-inc fileld is invisible.

… per FT

TokuDB has status to expose the compression ratio:

    mysql> show global status like 'tokudb%COMPRESSION_RATIO';
    +---------------------------------------+----------+
    | Variable_name                         | Value    |
    +---------------------------------------+----------+
    | Tokudb_LEAF_NODE_COMPRESSION_RATIO    | 5.850260 |
    | Tokudb_NONLEAF_NODE_COMPRESSION_RATIO | 0.564453 |
    | Tokudb_OVERALL_NODE_COMPRESSION_RATIO | 4.528809 |
    +---------------------------------------+----------+

but this a global level ratio, and sometimes the users may be interested
in table level compression ratio.

This patch address this request by exposing FT level compresstion ratio
through information_schema.TokuDB_fractal_tree_info table. We add two
columns, leaf_compress_ratio and internal_compress_ratio, which indicate
the compression ratio of leaf nodes and internal nodes accordingly.

Limitations, the comppression ratio infos are maintained in memeory, and
will lost when server is restarted or ft get evicted from memory.
Maybe in future there infos will be persisted in ft file, when this feature
is accepted by PerconaFT upstream.

…ion tables

This patch is ported from MySQL upstream (commit id: 9414c7).

Bug#25687813 REPLICATION REGRESSION WITH RBR AND PARTITIONED TABLES

PROBLEM
-------

While applying update the slave is trying to initialize all partitions
before reading from rnd_pos() call. This is done for each row update
because of which the performance is getting effected.

FIX
---

Initialize only the partition on which rnd_pos() is called.

Signed-off-by: Michael Seibt <github@roboschmie.de>

Fix typo