MySQL Cluster 7.6.2 dmr has been released (part 2/2)

[ This is part 2 of the announcement ]

Bugs Fixed

      * Partitioning: The output of EXPLAIN PARTITIONS
        (http://dev.mysql.com/doc/refman/5.7/en/explain.html)
        displayed incorrect values in the partitions column when
        run on an explicitly partitioned NDB
        (http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster.html)
        table having a large number of partitions.
        This was due to the fact that, when processing an EXPLAIN
        statement, mysqld
        (http://dev.mysql.com/doc/refman/5.7/en/mysqld.html)
        calculates the partition ID for a hash value as
        (hash_value % number_of_partitions), which is correct
        only when the table is partitioned by HASH, since other
        partitioning types use different methods of mapping hash
        values to partition IDs. This fix replaces the partition
        ID calculation performed by mysqld
        (http://dev.mysql.com/doc/refman/5.7/en/mysqld.html) with
        an internal NDB function which calculates the partition
        ID correctly, based on the table's partitioning type.
        (Bug #21068548)
        References: See also: Bug #25501895, Bug #14672885.

      * Microsoft Windows: When collecting information about CPUs
        on Windows, the Auto-Installer counted only physical
        cores, unlike on other platforms, where it collects
        information about both physical and virtual cores. Now
        the CPU information obtained on Windows is the same as
        that provided on other platforms. (Bug #85209, Bug
        #25636423)

      * When ndb_report_thresh_binlog_epoch_slip
(http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-options-variables.html#sysvar_ndb_report_thresh_binlog_epoch_slip) 

        was enabled, an event buffer status message with
        report_reason=LOW/ENOUGH_FREE_EVENTBUFFER was printed in
        the logs when event buffer usage was high and then
        decreased to a lower level. This calculation was based on
        total allocated event buffer memory rather than the limit
        set by ndb_eventbuffer_max_alloc
(http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-options-variables.html#sysvar_ndb_eventbuffer_max_alloc); 

        it was also printed even when the event buffer had unlimited
        memory (ndb_eventbuffer_max_alloc = 0, the default),
        which could confuse users. This is fixed as follows:

           + The calculation of ndb_eventbuffer_free_percent
(http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-options-variables.html#sysvar_ndb_eventbuffer_free_percent) 

             is now based on ndb_eventbuffer_max_alloc, rather than the 
amount actually allocated.

           + When ndb_eventbuffer_free_percent is set and
             ndb_eventbuffer_max_alloc is equal to 0, event
             buffer status messages using
             report_reason=LOW/ENOUGH_FREE_EVENTBUFFER are no
             longer printed.

           + When ndb_report_thresh_binlog_epoch_slip is set, an
             event buffer status message showing
             report_reason=BUFFERED_EPOCHS_OVER_THRESHOLD is
             written each 10 seconds (rather than every second)
             whenever this is greater than the threshold.
        (Bug #25726723)

      * A bulk update is executed by reading records and
        executing a transaction on the set of records, which is
        started while reading them. When transaction
        initialization failed, the transaction executor function
        was subsequently unaware that this had occurred, leading
        to SQL node failures. This issue is fixed by providing
        appropriate error handling when attempting to initialize
        the transaction. (Bug #25476474)
        References: See also: Bug #20092754.

      * CPU usage of the data node's main thread by the DBDIH
        master block as the end of a local checkpoint could
        approach 100% in certain cases where the database had a
        very large number of fragment replicas. This is fixed by
        reducing the frequency and range of fragment queue
        checking during an LCP. (Bug #25443080)

      * Execution of an online ALTER TABLE ... REORGANIZE
        PARTITION
(http://dev.mysql.com/doc/refman/5.7/en/alter-table-online-operations.html)
        statement on an NDB table having a primary key
        whose length was greater than 80 bytes led to
        restarting of data nodes, causing the reorganization to
        fail. (Bug #25152165)

      * Multiple data node failures during a partial restart of
        the cluster could cause API nodes to fail. This was due
        to expansion of an internal object ID map by one thread,
        thus changing its location in memory, while another
        thread was still accessing the old location, leading to a
        segmentation fault in the latter thread.
        The internal map() and unmap() functions in which this
        issue arose have now been made thread-safe. (Bug
        #25092498)
        References: See also: Bug #25306089.

      * The planned shutdown of an NDB Cluster having more than
        10 data nodes was not always performed gracefully. (Bug
        #20607730)

      * Dropped TRANS_AI signals that used the long signal format
        were not handled by the DBTC kernel block. (Bug #85606,
        Bug #25777337)
        References: See also: Bug #85519, Bug #27540805.

      * Iproved pushed join handling by eliminating unneeded
        FLUSH_AI attributes that passed an empty row to the DBSPJ
        kernel block, when a row should be passed to the SPJ API
        only; this reduces the set of AttrInfo projections that
        must be executed in order to produce the result. This
        also makes it possible to employ packed TRANSID_AI
        signals when delivering SPJ API results, which is more
        efficient. (Bug #85525, Bug #25741170)
        References: See also: Bug #85545, Bug #25750355.

      * Use of the long signal format (introduced in NDB 6.4) for
        an incoming TRANSID_AI message is supported by the
        BACKUP, DBTC, DBLQH, SUMA, DBSPJ, and DBUTIL NDB kernel
        blocks, but the DBTUP block produced long signals only
        when sending to DPSPJ or DBUTIL, and otherwise sent a
        series of short signals instead. Now DBTUP uses long
        signals for such messages whenever the receiving block
        supports this optimization. (Bug #85519, Bug #25740805)

      * To prevent a scan from returning more rows, bytes, or
        both than the client has reserved buffers for, the DBTUP
        kernel block reports the size of the TRANSID_AI it has
        sent to the client in the TUPKEYCONF signal it sends to
        the requesting DBLQH block. DBLQH is aware of the maximum
        batch size available for the result set, and terminates
        the scan batch if this has been exceeded.
        The DBSPJ block's FLUSH_AI attribute allows DBTUP to
        produce two TRANSID_AI results from the same row, one for
        the client, and one for DBSPJ, which is needed for key
        lookups on the joined tables. The size of both of these
        were added to the read length reported by the DBTUP
        block, which caused the controlling DBLQH block to
        believe that it had consumed more of the available
        maximum batch size than was actually the case, leading to
        premature termination of the scan batch which could have
        a negative impact on performance of SPJ scans. To correct
        this, only the actual read length part of an API request
        is now reported in such cases. (Bug #85408, Bug
        #25702850)

      * Data node binaries for Solaris 11 built using Oracle
        Developer Studio 12.5 on SPARC platforms failed with bus
        errors. (Bug #85390, Bug #25695818)

      * During the initial phase of a scan request, the DBTC
        kernel block sends a series of DIGETNODESREQ signals to
        the DBDIH block in order to obtain dictionary information
        for each fragment to be scanned. If DBDIH returned
        DIGETNODESREF, the error code from that signal was not
        read, and Error 218 Out of LongMessageBuffer was always
        returned instead. Now in such cases, the error code from
        the DIGETNODESREF signal is actually used. (Bug #85225,
        Bug #25642405)

      * If the user attempts to invoke ndb_setup.py
(http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-programs-ndb-setup-py.html) 

        while the Auto-Installer is still running---for example, after
        closing the terminal in which it was started and later
        opening a new terminal and invoking it in the new one---the
        program fails with the error Web server already running, which
        is expected behavior. In such cases, the mcc.pid file must
        first be removed prior to restarting the Auto-Installer (also
        expected behavior). Now when the program fails for this
        reason, the location of mcc.pid is included in the error
        message to simplify this task. (Bug #85169, Bug
        #25611093)

      * The planned shutdown of a data node after one or more
        data nodes in the same node group had failed was not
        always performed correctly. (Bug #85168, Bug #25610703)

      * There existed the possibility of a race condition between
        schema operations on the same database object originating
        from different SQL nodes; this could occur when one of
        the SQL nodes was late in releasing its metadata lock on
        the affected schema object or objects in such a fashion
        as to appear to the schema distribution coordinator that
        the lock release was acknowledged for the wrong schema
        change. This could result in incorrect application of the
        schema changes on some or all of the SQL nodes or a
        timeout with repeated waiting max ### sec for
        distributing... messages in the node logs due to failure
        of the distribution protocol. (Bug #85010, Bug #25557263)
        References: See also: Bug #24926009.

      * When a foreign key was added to or dropped from an NDB
        table using an ALTER TABLE
        (http://dev.mysql.com/doc/refman/5.7/en/alter-table.html)
        statement, the parent table's metadata was not updated,
        which made it possible to execute invalid alter
        operations on the parent afterwards.
        Until you can upgrade to this release, you can work
        around this problem by running SHOW CREATE TABLE
(http://dev.mysql.com/doc/refman/5.7/en/show-create-table.html)
        on the parent immediately after adding or dropping
        the foreign key; this statement causes the table's
        metadata to be reloaded. (Bug #82989, Bug #24666177)

      * Transactions on NDB
        (http://dev.mysql.com/doc/refman/5.7/en/mysql-cluster.html)
        tables with cascading foreign keys returned
        inconsistent results when the query cache was also
        enabled, due to the fact that mysqld
        (http://dev.mysql.com/doc/refman/5.7/en/mysqld.html) was
        not aware of child table updates. This meant that results
        for a later SELECT
        (http://dev.mysql.com/doc/refman/5.7/en/select.html) from
        the child table were fetched from the query cache, which
        at that point contained stale data.
        This is fixed in such cases by adding all children of the
        parent table to an internal list to be checked by NDB for
        updates whenever the parent is updated, so that mysqld
        (http://dev.mysql.com/doc/refman/5.7/en/mysqld.html) is
        now properly informed of any updated child tables that
        should be invalidated from the query cache. (Bug #81776,
        Bug #23553507)

      * Solaris; ndbmemcache: ndbmemcache was not built correctly
        on Solaris platforms when compiling NDB Cluster using
        Developer Studio. (Bug #85477, Bug #25730703)

      * NDB Disk Data: In some cases, setting dynamic in-memory
        columns of an NDB Disk Data table to NULL was not handled
        correctly. (Bug #79253, Bug #22195588)

      * NDB Replication: Execution of CREATE TABLE
        (http://dev.mysql.com/doc/refman/5.7/en/create-table.html
        ) could in some cases cause the replication slave SQL
        thread to hang. (Bug #85015, Bug #25654833)
        References: This issue is a regression of: Bug #83676,
        Bug #25042101.


On Behalf of the MySQL RE Team
Piotr Obrzut

-- 
MySQL Announce Mailing List
For list archives: http://lists.mysql.com/announce
To unsubscribe:    http://lists.mysql.com/announce