Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Bug#33824058 NDB_BUG17624736 FAILS IN PB2 #2
* PROBLEM The test "ndb.ndb_bug17624736" was constantly failing in [daily|weekly]-8.0-cluster branches in PB2, whether on `ndb-ps` or `ndb-default-big` profile test runs. The high-level reason for the failure was the installation of a duplicate entry in the Data Dictionary in respect to the `engine`-`se_private_id` pair, even when the previous table definition should have been dropped. * LOW-LEVEL EXPLANATION When data nodes fail and need to reorganize, the MySQL servers connected start to synchronize the schema definition in their own Data Dictionary. The `se_private_id` for NDB tables installed in the DD is the same as the NDB table ID, hereafter refered to as just ID, and thus a pair `engine`-`se_private_id` is installed in the `tables.engine`. It is common tables to be updated with different IDs, such as when an ALTER table or a DROP/CREATE occurs. The previous table definition, gotten by table full qualified name ("schema.table" format), is usually sufficient to be dropped and hence the new table to be installed with the new ID, since it is assumed that no other table definition is installed with that ID. However, on the synchronization phase, if the data node failure caused a previous table definition *of a different table than the one to be installed* to still exist with the ID to be installed, then that old definition won't be dropped and thus a duplicate entry warning will be logged on the THD. Example: t1 - id=13,version=1 t2 - id=15,version=1 <failures and synchronization> t1 = id=9,version=2 t2 = id=13,version=2 (previous def=15, but ndbcluster-13 still exists) One of the reasons for the error is that on `Ndb_dd_client::install_table` the name is used to fetch the previous definition while on `Ndb_dd_client::store_table` the ID is used instead. Also, `Ndb_dd_client::install_table` should be able to drop the required table definitions on the DD in order to install the new one, as dictated by the data nodes. It was just dropping the one found by the name of the table to be installed. * SOLUTION The solution was to add procedures to check if the ID to be installed is different than the previous, then it must be checked if an old table definition already exists with that ID. If it does, drop it also. Additionally, some renaming (`object_id` to `spi`, refering to `se_private_id`) and a new struct were employed to make it simpler to keep the pair (ID-VERSION) together and respectively install these on the new table's definition SE fields. Change-Id: Ie671a5fc58646e02c21ef1299309303f33173e95
- Loading branch information