Cluster Replication: Incompatible Change: Two major changes have taken place with regard to the MySQL Cluster system tables. These are:

For more information, see Section 17.6.4, “MySQL Cluster Replication Schema and Tables”. (Bug#14612)

Cluster Replication: Incompatible Change: The cluster database is no longer used. The tables formerly found in the cluster database are now in the mysql database, and have been renamed as ndb_binlog_index, ndb_apply_status, and ndb_schema.

Incompatible Change: The prepared_stmt_count system variable has been converted to the Prepared_stmt_count global status variable (viewable with the SHOW GLOBAL STATUS statement). (Bug#23159)

Incompatible Change: Previously, you could create a user-defined function (UDF) or stored function with the same name as a built-in function, but could not invoke the UDF. Now an error occurs if you try to create such a UDF. The server also now generates a warning if you create a stored function with the same name as a built-in function. It is not considered an error to create a stored function with the same name as a built-in function because you can invoke the function using db_name.func_name() syntax. However, the server now generates a warning in this case.

See Section 8.2.4, “Function Name Parsing and Resolution”, for the rules describing how the server interprets references to different kinds of functions. (Bug#22619, Bug#18239)

MySQL Cluster: Backup messages are now printed to the Cluster log. (Bug#24544)

MySQL Cluster: Setting the configuration parameter LockPagesInMainMemory had no effect. (Bug#24461)

MySQL Cluster: The error message Management server closed connection, when recorded in the MySQL error log, now includes a timestamp indicating when the error took place. (Bug#21519)

MySQL Cluster: It is now possible to create a unique hashed index on a column that is not defined as NOT NULL.

Unique indexes on columns in NDB tables do not store null values because they are mapped to primary keys in an internal index table (and primary keys cannot contain nulls).

Normally, an additional ordered index is created when one creates unique indexes on NDB table columns; this can be used to search for NULL values. However, if USING HASH is specified when such an index is created, no ordered index is created.

The reason for permitting unique hash indexes with null values is that, in some cases, the user wants to save space if a large number of records are pre-allocated but not fully initialized. This also assumes that the user will not try to search for null values. Since MySQL does not support indexes that are not allowed to be searched in some cases, the NDB storage engine uses a full table scan with pushed conditions for the referenced index columns to return the correct result.

A warning is returned if one creates a unique nullable hash index, since the query optimizer should be provided a hint not to use it with NULL values if this can be avoided. (Bug#21507)

MySQL Cluster: (Disk Data): The output of mysqldump now includes by default all tablespace and logfile group definitions used by any tables or databases that are dumped.

(Bug#20839)

DROP TRIGGER now supports an IF EXISTS clause. (Bug#23703)

Direct and indirect usage of stored routines, user-defined functions, and table references is now prohibited in CREATE EVENT and ALTER EVENT statements.

See Section 12.1.11, “CREATE EVENT Syntax”, and Section 12.1.2, “ALTER EVENT Syntax”, for more specific information. (Bug#22830)

The XPath operators < and >, as implemented in the ExtractValue() function, operated in reverse.

With this fix, all standard XPath comparison operators should now be supported correctly for use with the ExtractValue() and UpdateXML() functions. (Bug#22823)

For the mysql client, display of result set metadata now is enabled with the --column-type-info option rather than with --debug-info/-T.

mysqladmin, mysqlcheck, mysqldump, mysqlimport, and mysqlshow now accept the --debug-info option, which displays debugging information and memory and CPU usage statistics at program exit.

Performance: Evaluation of subqueries that require the filesort algorithm were allocating and freeing the sort_buffer_size buffer many times, resulting in slow performance. Now the buffer is allocated once and reused. (Bug#21727)

MySQL Cluster: Replication: (Replication): If errors occurred during purging of the binary logs, extraneous rows could remain left in the binlog_index table. (Bug#15021)

MySQL Cluster: The failure of a data node failure during a schema operation could lead to additional node failures. (Bug#24752)

MySQL Cluster: A committed read could be attempted before a data node had time to connect, causing a timeout error. (Bug#24717)

MySQL Cluster: The simultaneous shutdown of mysqld and ndbd processes caused unnecessary locking. (Bug#24655)

MySQL Cluster: The failure of the master node in a node group during the allocation of node IDs could cause ndb_mgmd to hang. (Bug#24543)

MySQL Cluster: In certain rare cases, a data node could crash due to a typographical error in the MySQL Cluster source code. (Bug#24476)

MySQL Cluster: Creating a new tables containing a BLOB column when the server was short of memory could cause the server to crash. (Bug#24470)

MySQL Cluster: Sudden disconnection of an SQL or data node could lead to shutdown of data nodes with the error failed ndbrequire. (Bug#24447)

MySQL Cluster: Any statement following the execution of CREATE TABLE ... LIKE ndb_table (where ndb_table was a table using the NDB storage engine), would cause the mysql client to hang. (Bug#24301)

MySQL Cluster: (Disk Data): Excessive fragmentation of Disk Data files (including log files and data files) could occur during the course of normal use. (Bug#24143)

MySQL Cluster: When the management client command ALL RESTART -i was executed while one data node was not running, all data nodes in the cluster were shut down. (Bug#24105)

MySQL Cluster: A query using an index scan followed by a delete operation, and then a rollback could cause one or more data nodes to crash. (Bug#24039)

MySQL Cluster: (Disk Data): Under some circumstances, a DELETE from a Disk Data table could cause mysqld to crash. (Bug#23542)

MySQL Cluster: It was possible for the sum of the MaxNoOfTables, MaxNoOfOrderedIndexes, and MaxNoOfUniqueHashIndexes configuration parameters, plus the number of system tables to exceed the maximum value for a Uint32 number. In such a case, the cluster's data nodes failed to start, and no reason for this could easily be determined from the error messages provided. (Bug#22548)

MySQL Cluster: A value equal to or greater than the allowed maximum for LongMessageBuffer caused all data nodes to crash. (Bug#22547)

MySQL Cluster: Multiple occurrences of error conditions were logged with duplicat error messages rather than being reported with a single error message stating that the error was encountered N times. (Bug#22313)

MySQL Cluster: Given a table mytbl in a database mydb on a MySQL Server acting as an SQL node in a MySQL Cluster, then, following multiple ALTER TABLE mytbl ENGINE=engine statements — first, to change the storage engine used for a table to NDB, and then again to change the table to use a non-NDB storage engine — a DROP DATABASE mydb statement executed on any SQL node in the cluster would cause mydb to be dropped on all SQL nodes in the cluster, even if mydb contained non-NDB tables. (Bug#21495)

MySQL Cluster: An incorrect error message was displayed in the event that the value of the MaxNoOfOrderedIndexes parameter was set too low. (Bug#20065)

MySQL Cluster: An incorrect error message was displayed in the event that the value of the DataMemory parameter was insufficient for the amount of data to be stored by the cluster. (Bug#19808)

MySQL Cluster: Some values of MaxNoOfTriggers could cause the server to become inaccessible following startup of the data nodes. (Bug#19454)

MySQL Cluster: If the value set for MaxNoOfAttributes is excessive, a suitable error message is now returned. (Bug#19352)

MySQL Cluster: Different error messages were returned for similar cases involving failure to allocate memory for Cluster operations. (Bug#19203)

MySQL Cluster: A unique constraint violation was not ignored by an UPDATE IGNORE statement when the constraint violation occurred on a nonprimary key. (Bug#18487, Bug#24303)

Replication: With row-based binary logging, replicated multiple-statement transaction deadlocks did not return the correct error code, causing the slave SQL thread to stop rather than roll back and re-execute. (Bug#23831)

Replication: Changes to character set variables prior to an action on a replication-ignored table were forgotten by slave servers. (Bug#22877)

Replication: On slave servers, transactions that exceeded the lock wait timeout failed to roll back properly. (Bug#20697)

Replication: SQL statements close to the size of max_allowed_packet could produce binary log events larger than max_allowed_packet that could not be read by slave servers. (Bug#19402)

Disk Data: ndb_restore sometimes failed when attempting to restore Disk Data tables due to data node failure caused by accessing uninitialized memory. (Bug#24331)

Disk Data: It was possible to execute a statement for creating a Disk Data table that referred to a nonexistent tablespace, in which case the table created was actually an in-memory NDB table. Such a statement now fails instead, with an appropriate error message. (Bug#23576)

Cluster API: Using BIT values with any of the comparison methods of the NdbScanFilter class caused data nodes to fail. (Bug#24503)

Cluster API: Some MGM API function calls could yield incorrect return values in certain cases where the cluster was operating under a very high load, or experienced timeouts in inter-node communications. (Bug#24011)

In some cases, a function that should be parsed as a user-defined function was parsed as a stored function. (Bug#24736)

Some unnecessary Valgrind warnings were removed from the server. (Bug#24488, Bug#24533)

The server source code had multiple exportable definitions of the field_in_record_is_null() function. These are now all declared static. (Bug#24190)

The loose index scan optimization for GROUP BY with MIN or MAX was not applied within other queries, such as CREATE TABLE ... SELECT ..., INSERT ... SELECT ..., or in the FROM clauses of subqueries. (Bug#24156)

Subqueries for which a pushed-down condition did not produce exactly one key field could cause a server crash. (Bug#24056)

The size of MEMORY tables and internal temporary tables was limited to 4GB on 64-bit Windows systems. (Bug#24052)

LAST_DAY('0000-00-00') could cause a server crash. (Bug#23653)

A trigger that invoked a stored function could cause a server crash when activated by different client connections. (Bug#23651)

The stack size for NetWare binaries was increased to 128KB to prevent problems caused by insufficient stack size. (Bug#23504)

If elements in a nontop-level IN subquery were accessed by an index and the subquery result set included a NULL value, the quantified predicate that contained the subquery was evaluated to NULL when it should return a non-NULL value. (Bug#23478)

When applying the group_concat_max_len limit, GROUP_CONCAT() could truncate multi-byte characters in the middle. (Bug#23451)

mysql_affected_rows() could return values different from mysql_stmt_affected_rows() for the same sequence of statements. (Bug#23383)

Calculation of COUNT(DISTINCT), AVG(DISTINCT), or SUM(DISTINCT) when they are referenced more than once in a single query with GROUP BY could cause a server crash. (Bug#23184)

With row-based binary logging, for CREATE TABLE IF NOT EXISTS LIKE temporary_table statements, the IF NOT EXISTS clause was not logged. (Bug#22762)

BENCHMARK(), ENCODE(), DECODE(), and FORMAT() could only accept a constant for some parameters, and could not be used in prepared statements. (Bug#22684)

Queries using a column alias in an expression as part of an ORDER BY clause failed, an example of such a query being SELECT mycol + 1 AS mynum FROM mytable ORDER BY 30 - mynum. (Bug#22457)

Using EXPLAIN caused a server crash for queries that selected from INFORMATION_SCHEMA in a subquery in the FROM clause. (Bug#22413)

Instance Manager option-parsing code caused memory-allocation errors. (Bug#22242)

Trailing spaces were not removed from Unicode CHAR column values when used in indexes. This resulted in excessive usage of storage space, and could affect the results of some ORDER BY queries that made use of such indexes.

(Bug#22052)

With row-based binary logging, CREATE TABLE IF NOT EXISTS SELECT statements were not logged properly. (Bug#22027)

In some cases, the parser failed to distinguish a user-defined function from a stored function. (Bug#21809)

Inserting a default or invalid value into a spatial column could fail with Unknown error rather than a more appropriate error. (Bug#21790)

Through the C API, the member strings in MYSQL_FIELD for a query that contains expressions may return incorrect results. (Bug#21635)

View columns were always handled as having implicit derivation, leading to illegal mix of collation errors for some views in UNION operations. Now view column derivation comes from the original expression given in the view definition. (Bug#21505)

INET_ATON() returned a signed BIGINT value, not an unsigned value. (Bug#21466)

For debug builds, mysqladmin shutdown displayed an extraneous skipped 9 bytes from file: socket (3) message. (Bug#21428)

For renaming of views, encoding of table name to file names was not performed. (Bug#21370)

CREATE FUNCTION X() and CREATE FUNCTION Y() failed with a syntax error instead of warning the user that these function names are already used (for GIS functions). (Bug#21025)

CONCURRENT did not work correctly for LOAD DATA INFILE. (Bug#20637)

With lower_case_table_names set to 1, SHOW CREATE TABLE printed incorrect output for table names containing Turkish I (LATIN CAPITAL LETTER I WITH DOT ABOVE). (Bug#20404)

A query with a subquery that references columns of a view from the outer SELECT could return an incorrect result if used from a prepared statement. (Bug#20327)

For queries that select from a view, the server was returning MYSQL_FIELD metadata inconsistently for view names and table names. For view columns, the server now returns the view name in the table field and, if the column selects from an underlying table, the table name in the org_table field. (Bug#20191)

Invalidating the query cache caused a server crash for INSERT INTO ... SELECT statements that selected from a view. (Bug#20045)

For a cast of a DATETIME value containing microseconds to DECIMAL, the microseconds part was truncated without generating a warning. Now the microseconds part is preserved. (Bug#19491)

The server could send incorrect column count information to the client for queries that produce a larger number of columns than can fit in a two-byte number. (Bug#19216)

For some problems relating to character set conversion or incorrect string values for INSERT or UPDATE, the server was reporting truncation or length errors instead. (Bug#18908)

Constant expressions and some numeric constants used as input parameters to user-defined functions were not treated as constants. (Bug#18761)

Attempting to use a view containing DEFINER information for a nonexistent user resulted in an error message that revealed the definer account. Now the definer is revealed only to superusers. Other users receive only an access denied message. (Bug#17254)

IN() and CHAR() can return NULL, but did not signal that to the query processor, causing incorrect results for IS NULL operations. (Bug#17047)

Warnings were generated when explicitly casting a character to a number (for example, CAST('x' AS SIGNED)), but not for implicit conversions in simple arithmetic operations (such as 'x' + 0). Now warnings are generated in all cases. (Bug#11927)

Metadata for columns calculated from scalar subqueries was limited to integer, double, or string, even if the actual type of the column was different. (Bug#11032)