Bug #80750 Excessive recreation of Ndb objects due to false failure of Thd_ndb::valid_ndb

• Submitted: 15 Mar 2016 14:01
• Modified: 21 Mar 2016 15:16
• Reporter: Ole John Aske
• Status: Closed
• Category: MySQL Cluster: Cluster (NDB) storage engine
• Severity: S3 (Non-critical)
• Version: 7.4.10
• OS: Any
• CPU Architecture: Any

[15 Mar 2016 14:01] Ole John Aske

Description:
The Thd_ndb object has the member variable ::m_connect_count. When the Thd_ndb objects is constructed, m_connect_count is assigned to 'connection->get_connect_count()', where 'connect_count' is the number of disconnect/reconnects as seen by the 'connect' objects.

This is used by Thd_ndb::valid_ndb() as a way to validate that Thd_ndb::ndb still is a valid connection. This is used by check_ndb_in_thd(THD* thd..), mostly related to schema operations, in order to ensure than we have a 'fresh' Ndb objects. If check_ndb_in_thd() find a 'non fresh' Ndb object, Thd_ndb::recycle_ndb() is called which will destruct the existing Ndb and construct a new one. This has considerable overhead, both related to the memory alloc, and as trp_client::close() / ::open() has to be called as part of Ndb destruct/construct.

Unfortunately, Thd_ndb::recycle_ndb() does not assign an updated 'connection_count' when a new Ndb objects is created. This cause ::valid_ndb() to also fail every time it is called after an initial failure. Bringing us into as state where we are potentially creating a new Ndb object for every operation validating the Thd_ndb.

No user visible failure has been observed (yet) due to this, except possible some extra slowness related to the excessive trp_client::close and ::open()

How to repeat:
Observed as part of investigating Thd_ndb::valid_ndb() behaviour as part of other bug fixing.

Suggested fix:
Refresh m_connection_count as part of ::recycle_ndb()

[21 Mar 2016 15:16] Jon Stephens

Documented fix in the NDB 7.4.11 and 7.5.2 changelogs as follows:

    An internal function used to validate connections failed to
    update the connection count when creating a new Ndb object. This
    had the potential to creating a new Ndb object for every
    operation validating the connection, which could have an impact
    on performance, particularly when performing schema operations.

Closed.