MySQL Forums
Forum List  »  Announcements

MySQL Cluster 7.5.0 has been released (part 2/3)
Posted by: Balasubramanian Kandasamy
Date: February 05, 2016 02:09AM


[This is part 2 of the announcement] 

     * Important Change; Cluster API: The following NDB API
       methods were not actually implemented and have been removed from
       the sources:

          + Datafile
          (http://dev.mysql.com/doc/ndbapi/en/ndb-datafile.html)
          methods: getNode()
          (http://dev.mysql.com/doc/ndbapi/en/ndb-datafile-met
          hods.html#ndb-datafile-getnode), setNode()
          (http://dev.mysql.com/doc/ndbapi/en/ndb-datafile-met
          hods.html#ndb-datafile-setnode), and getFileNo()
          (http://dev.mysql.com/doc/ndbapi/en/ndb-datafile-met
          hods.html#ndb-datafile-getfileno)

          + Undofile
          (http://dev.mysql.com/doc/ndbapi/en/ndb-undofile.html)
          methods: getNode()
          (http://dev.mysql.com/doc/ndbapi/en/ndb-undofile-met
          hods.html#ndb-undofile-getnode), setNode()
          (http://dev.mysql.com/doc/ndbapi/en/ndb-undofile-met
          hods.html#ndb-undofile-setnode), and getFileNo()
          (http://dev.mysql.com/doc/ndbapi/en/ndb-undofile-met
          hods.html#ndb-undofile-getfileno)

          + Table (http://dev.mysql.com/doc/ndbapi/en/ndb-table.html)
          methods: getObjectType()
          (http://dev.mysql.com/doc/ndbapi/en/ndb-table-method
          s.html#ndb-table-getobjecttype) and setObjectType()
          (http://dev.mysql.com/doc/ndbapi/en/ndb-table-method
          s.html#ndb-table-setobjecttype)

     * A serious regression was inadvertently introduced in
       MySQL Cluster NDB 7.4.8 whereby local checkpoints and thus
       restarts often took much longer than expected. This occurred due
       to the fact that the setting for MaxDiskWriteSpeedOwnRestart
       (http://dev.mysql.com/doc/refman/5.6/en/mysql-cluster-ndb
       d-definition.html#ndbparam-ndbd-maxdiskwritespeedownrestart) was
       ignored during restarts and the value of
       MaxDiskWriteSpeedOtherNodeRestart
       (http://dev.mysql.com/doc/refman/5.6/en/mysql-cluster-ndb
       d-definition.html#ndbparam-ndbd-maxdiskwritespeedothernod
       erestart), which is much lower by default than the default for
       MaxDiskWriteSpeedOwnRestart, was used instead. This issue
       affected restart times and performance only and did not have any
       impact on normal operations. (Bug #22582233)


     * The epoch for the latest restorable checkpoint provided
       in the cluster log as part of its reporting for EventBufferStatus
       events (see MySQL Cluster: Messages in the Cluster Log
       (http://dev.mysql.com/doc/refman/5.6/en/mysql-cluster-log
       s-cluster-log.html)) was not well defined and thus unreliable;
       depending on various factors, the reported epoch could be the one
       currently being consumed, the one most recently consumed, or the
       next one queued for consumption.  This fix ensures that the
       latest restorable global checkpoint is always regarded as the one
       that was most recently completely consumed by the user, and thus
       that it was the latest restorable global checkpoint that existed
       at the time the report was generated. (Bug #22378288)

     * Added the --ndb-allow-copying-alter-table option for
       mysqld. Setting this option (or the equivalent system variable
       ndb_allow_copying_alter_table) to OFF keeps ALTER TABLE
       (http://dev.mysql.com/doc/refman/5.6/en/alter-table.html)
       statements from performing copying operations. The default value
       is ON. (Bug #22187649) References: See also Bug #17400320.

     * Attempting to create an NDB
       (http://dev.mysql.com/doc/refman/5.6/en/mysql-cluster.html)
       table having greater than the maximum supported combined width
       for all BIT
       (http://dev.mysql.com/doc/refman/5.6/en/bit-type.html) columns
       (4096) caused data node failure when these columns were defined
       with COLUMN_FORMAT DYNAMIC. (Bug #21889267)

     * Creating a table with the maxmimum supported number of
       columns (512) all using COLUMN_FORMAT DYNAMIC led to data node
       failures. (Bug #21863798)

     * In a MySQL Cluster with multiple LDM instances, all
       instances wrote to the node log, even inactive instances on other
       nodes. During restarts, this caused the log to be filled with
       messages from other nodes, such as the messages shown here:
       2015-06-24 00:20:16 [ndbd] INFO     -- We are adjusting Max Disk
       Write Speed, a restart is ongoing now ...  2015-06-24 01:08:02
       [ndbd] INFO     -- We are adjusting Max Disk Write Speed, no
       restarts ongoing anymore

       Now this logging is performed only by the active LDM instance.
       (Bug #21362380)

     * Backup block states were reported incorrectly during
       backups. (Bug #21360188) References: See also Bug #20204854, Bug
       #21372136.

     * For a timeout in GET_TABINFOREQ while executing a CREATE
       INDEX (http://dev.mysql.com/doc/refman/5.6/en/create-index.html)
       statement, mysqld returned Error 4243 (Index not found) instead
       of the expected Error 4008 (Receive from NDB failed).  The fix
       for this bug also fixes similar timeout issues for a number of
       other signals that are sent the DBDICT kernel block as part of
       DDL operations, including ALTER_TAB_REQ, CREATE_INDX_REQ,
       DROP_FK_REQ, DROP_INDX_REQ, INDEX_STAT_REQ, DROP_FILE_REQ,
       CREATE_FILEGROUP_REQ, DROP_FILEGROUP_REQ, CREATE_EVENT,
       WAIT_GCP_REQ, DROP_TAB_REQ, and LIST_TABLES_REQ, as well as
       several internal functions used in handling NDB
       (http://dev.mysql.com/doc/refman/5.6/en/mysql-cluster.html)
       schema operations. (Bug #21277472) References: See also Bug
       #20617891, Bug #20368354, Bug #19821115.

     * Previously, multiple send threads could be invoked for
       handling sends to the same node; these threads then competed for
       the same send lock. While the send lock blocked the additional
       send threads, work threads could be passed to other nodes.  This
       issue is fixed by ensuring that new send threads are not
       activated while there is already an active send thread assigned
       to the same node. In addition, a node already having an active
       send thread assigned to it is no longer visible to other, already
       active, send threads; that is, such a node is longer added to the
       node list when a send thread is currently assigned to it. (Bug
       #20954804, Bug #76821)

     * Queueing of pending operations when the redo log was
       overloaded (DefaultOperationRedoProblemAction
       (http://dev.mysql.com/doc/refman/5.6/en/mysql-cluster-api
       -definition.html#ndbparam-api-defaultoperationredoproblem action)
       API node configuration parameter) could lead to timeouts when
       data nodes ran out of redo log space (P_TAIL_PROBLEM errors). Now
       when the redo log is full, the node aborts requests instead of
       queuing them. (Bug #20782580) References: See also Bug #20481140.

     * An NDB event buffer can be used with an Ndb
       (http://dev.mysql.com/doc/ndbapi/en/ndb-ndb.html) object to
       subscribe to table-level row change event streams.  Users
       subscribe to an existing event; this causes the data nodes to
       start sending event data signals (SUB_TABLE_DATA) and epoch
       completion signals (SUB_GCP_COMPLETE) to the Ndb object.
       SUB_GCP_COMPLETE_REP signals can arrive for execution in
       concurrent receiver thread before completion of the internal
       method call used to start a subscription.  Execution of
       SUB_GCP_COMPLETE_REP signals depends on the total number of SUMA
       buckets (sub data streams), but this may not yet have been set,
       leading to the present issue, when the counter used for tracking
       the SUB_GCP_COMPLETE_REP signals (TOTAL_BUCKETS_INIT) was found
       to be set to erroneous values. Now TOTAL_BUCKETS_INIT is tested
       to be sure it has been set correctly before it is used. (Bug
       #20575424) References: See also Bug #20561446, Bug #21616263.

     * NDB
       (http://dev.mysql.com/doc/refman/5.6/en/mysql-cluster.html)
       statistics queries could be delayed by the error delay set for
       ndb_index_stat_option
       (http://dev.mysql.com/doc/refman/5.6/en/mysql-cluster-opt
       ions-variables.html#sysvar_ndb_index_stat_option) (default 60
       seconds) when the index that was queried had been marked with
       internal error. The same underlying issue could also cause
       ANALYZE TABLE
       (http://dev.mysql.com/doc/refman/5.6/en/analyze-table.html) to
       hang when executed against an NDB table having multiple indexes
       where an internal error occured on one or more but not all
       indexes.  Now in such cases, any existing statistics are returned
       immediately, without waiting for any additonal statistics to be
       discovered. (Bug #20553313, Bug #20707694, Bug #76325)

     * Memory allocated when obtaining a list of tables or
       databases was not freed afterward. (Bug #20234681, Bug #74510)
       References: See also Bug #18592390, Bug #72322.

     * Added the BackupDiskWriteSpeedPct
       (http://dev.mysql.com/doc/refman/5.6/en/mysql-cluster-ndb
       d-definition.html#ndbparam-ndbd-backupdiskwritespeedpct) data
       node parameter. Setting this parameter causes the data node to
       reserve a percentage of its maximum write speed (as determined by
       the value of MaxDiskWriteSpeed
       (http://dev.mysql.com/doc/refman/5.6/en/mysql-cluster-ndb
       d-definition.html#ndbparam-ndbd-maxdiskwritespeed)) for use in
       local checkpoints while performing a backup.
       BackupDiskWriteSpeedPct is interpreted as a percentage which can
       be set between 0 and 90 inclusive, with a default value of 50.
       (Bug #20204854) References: See also Bug #21372136.

     * After restoring the database schema from backup using
       ndb_restore, auto-discovery of restored tables in transactions
       having multiple statements did not work correctly, resulting in
       Deadlock found when trying to get lock; try restarting
       transaction errors.  This issue was encountered both in the mysql
       client, as well as when such transactions were executed by
       application programs using Connector/J and possibly other MySQL
       APIs.  Prior to upgrading, this issue can be worked around by
       executing SELECT TABLE_NAME, TABLE_SCHEMA FROM
       INFORMATION_SCHEMA.TABLES WHERE ENGINE = 'NDBCLUSTER' on all SQL
       nodes following the restore operation, before executing any other
       statements. (Bug #18075170)

     * Using ndb_mgm STOP -f to force a node shutdown even when
       it triggered a complete shutdown of the cluster, it was possible
       to lose data when a sufficient number of nodes were shut down,
       triggering a cluster shutodwn, and the timing was such that SUMA
       handovers had been made to nodes already in the process of
       shutting down. (Bug #17772138)

     * When using a sufficiently large value for
       TransactionDeadlockDetectionTimeout
       (http://dev.mysql.com/doc/refman/5.6/en/mysql-cluster-ndb
       d-definition.html#ndbparam-ndbd-transactiondeadlockdetect
       iontimeout) and the default value for sort_buffer_size
       (http://dev.mysql.com/doc/refman/5.6/en/server-system-var
       iables.html#sysvar_sort_buffer_size), executing SELECT
       (http://dev.mysql.com/doc/refman/5.6/en/select.html) * FROM
       ndbinfo.cluster_operations
       (http://dev.mysql.com/doc/refman/5.6/en/mysql-cluster-ndb
       info-cluster-operations.html) ORDER BY transid with multiple
       concurrent conflicting or deadlocked transactions, each
       transaction having several pending operations, caused the SQL
       node where the query was run to fail. (Bug #16731538, Bug #67596)

     * The ndbinfo.config_params
       (http://dev.mysql.com/doc/refman/5.6/en/mysql-cluster-ndb
       info-config-params.html) table is now read-only. (Bug #11762750,
       Bug #55383)

     * NDB failed during a node restart due to the status of the
       current local checkpoint being set but not as active, even though
       it could have other states under such conditions. (Bug #78780,
       Bug #21973758)

     * ndbmtd checked for signals being sent only after a full
       cycle in run_job_buffers, which is performed for all job buffer
       inputs. Now this is done as part of run_job_buffers itself, which
       avoids executing for extended periods of time without sending to
       other nodes or flushing signals to other threads. (Bug #78530,
       Bug #21889088)

     * When attempting to enable index statistics, creation of
       the required system tables, events and event subscriptions often
       fails when multiple mysqld processes using index statistics are
       started concurrently in conjunction with starting, restarting, or
       stopping the cluster, or with node failure handling. This is
       normally recoverable, since the affected mysqld process or
       processes can (and do) retry these operations shortly thereafter.
       For this reason, such failures are no longer logged as warnings,
       but merely as informational events.  (Bug #77760, Bug #21462846)

     * It was possible to end up with a lock on the send buffer
       mutex when send buffers became a limiting resource, due either to
       insufficient send buffer resource configuration, problems with
       slow or failing communications such that all send buffers became
       exhausted, or slow receivers failing to consume what was sent. In
       this situation worker threads failed to allocate send buffer
       memory for signals, and attempted to force a send in order to
       free up space, while at the same time the send thread was busy
       trying to send to the same node or nodes. All of these threads
       competed for taking the send buffer mutex, which resulted in the
       lock already described, reported by the watchdog as Stuck in
       Send.  This fix is made in two parts, listed here:

         1. The send thread no longer holds the global send thread mutex
         while getting the send buffer mutex; it now releases the global
         mutex prior to locking the send buffer mutex. This keeps worker
         threads from getting stuck in send in such cases.

         2. Locking of the send buffer mutex done by the send threads
         now uses a try-lock. If the try-lock fails, the node to make
         the send to is reinserted at the end of the list of send nodes
         in order to be retried later. This removes the Stuck in Send
         condition for the send threads.  (Bug #77081, Bug #21109605)

     * Disk Data: A unique index on a column of an NDB
       (http://dev.mysql.com/doc/refman/5.6/en/mysql-cluster.html)
       table is implemented with an associated internal ordered index,
       used for scanning. While dropping an index, this ordered index
       was dropped first, followed by the drop of the unique index
       itself. This meant that, when the drop was rejected due to (for
       example) a constraint violation, the statement was rejected but
       the associated ordered index remained deleted, so that any
       subsequent operation using a scan on this table failed.  We fix
       this problem by causing the unique index to be removed first,
       before removing the ordered index; removal of the related ordered
       index is no longer performed when removal of a unique index
       fails. (Bug #78306, Bug #21777589)

    * Cluster Replication: While the binary log injector thread
       was handling failure events, it was possible for all NDB tables
       to be left indefinitely in read-only mode. This was due to a race
       condition between the binlog injector thread and the utility
       thread handling events on the ndb_schema table, and to the fact
       that, when handling failure events, the binlog injector thread
       places all NDB tables in read-only mode until all such events are
       handled and the thread restarts itself.  When the binlog inject
       thread receives a group of one or more failure events, it drops
       all other existing event operations and expects no more events
       from the utility thread until it has handled all of the failure
       events and then restarted itself. However, it was possible for
       the utility thread to continue attempting binary log setup while
       the injector thread was handling failures and thus attempting to
       create the schema distribution tables as well as event
       subscriptions on these tables. If the creation of these tables
       and event subscriptions occurred during this time, the binlog
       injector thread's expectation that there were no further event
       operations was never met; thus, the injector thread never
       restarted, and NDB tables remained in read-only as described
       previously.  To fix this problem, the Ndb
       (http://dev.mysql.com/doc/ndbapi/en/ndb-ndb.html) object that
       handles schema events is now definitely dropped once the
       ndb_schema table drop event is handled, so that the utility
       thread cannot create any new events until after the injector
       thread has restarted, at which time, a new Ndb object for
       handling schema events is created. (Bug #17674771, Bug #19537961,
       Bug #22204186, Bug #22361695)


* To be continued in part 3....

Options: ReplyQuote


Subject
Views
Written By
Posted
MySQL Cluster 7.5.0 has been released (part 2/3)
2061
February 05, 2016 02:09AM


Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.