Bug #82851 mysqldump excludes only the old ndb apply and schema tables

• Submitted: 3 Sep 2016 9:52
• Modified: 6 Oct 2016 13:14
• Reporter: Daniël van Eeden (OCA)
• Status: Verified
• Category: MySQL Server: mysqldump Command-line Client
• Severity: S3 (Non-critical)
• Version: 7.5
• OS: Any
• CPU Architecture: Any
• Tags: cluster, ndb

[3 Sep 2016 9:52] Daniël van Eeden

Description:
From storage/ndb/tools/restore/Restore.cpp:
#define OLD_NDB_APPLY_TABLE "apply_status"

From sql/ha_ndbcluster_tables.h
#define NDB_APPLY_TABLE "ndb_apply_status"

From client/mysqldump.c:
1006   /* Don't copy internal log tables */
1007   if (my_hash_insert(&ignore_table,
1008                      (uchar*) my_strdup(PSI_NOT_INSTRUMENTED,
1009                                         "mysql.apply_status", MYF(MY_WME))) ||
1010       my_hash_insert(&ignore_table,
1011                      (uchar*) my_strdup(PSI_NOT_INSTRUMENTED,
1012                                         "mysql.schema", MYF(MY_WME))) ||
1013       my_hash_insert(&ignore_table,
1014                      (uchar*) my_strdup(PSI_NOT_INSTRUMENTED,
1015                                         "mysql.general_log", MYF(MY_WME))) ||
1016       my_hash_insert(&ignore_table,
1017                      (uchar*) my_strdup(PSI_NOT_INSTRUMENTED,
1018                                         "mysql.slow_log", MYF(MY_WME))))
1019     return(EX_EOM);

How to repeat:
Compare code

Suggested fix:
1. Remove mysql.apply_status from the mysqldump code
2. Update the mysqldump code to also ignore mysql.ndb_apply_status
3. Keep the current situation if this is on purpose, but add a comment noting that apply_status is an *OLD* NDB table.

[3 Sep 2016 10:01] Daniël van Eeden

From commit e82587980037d3c27d84411c332d812d47f424bd

+  /* Don't copy cluster internal log tables */
+  if (my_hash_insert(&ignore_table,
+                     (byte*) my_strdup("mysql.apply_status", MYF(MY_WME))) ||
+      my_hash_insert(&ignore_table,
+                     (byte*) my_strdup("mysql.schema", MYF(MY_WME))))
+    return(EX_EOM);
+
+  if ((ho_error= handle_options(argc, argv, my_long_options, get_one_option)))
+    return(ho_error);

So looks like the comment was changed and both apply_status and schema are cluster tables.

From storage/ndb/tools/restore/Restore.cpp:
#define OLD_NDB_SCHEMA_TABLE "schema"

From sql/ha_ndbcluster_tables.h:
#define NDB_SCHEMA_TABLE "ndb_schema"

[5 Oct 2016 21:50] MySQL Verification Team

Hi Daniël,
I'm not following the problem. You are talking about 5.7 source but latest GA mysql cluster 7.4 does not use 5.7 mysqld at all. 

The development version 7.5 is using 5.7 but latest 5.7.13 at this point in time, so not sure where you get 5.7.14 in relation to MySQL Cluster?

Anyhow I'm testing latest 7.4 and 7.5 and I don't see any issues in how mysqldump functions? (you are talking about mysqldump right, not mysqlbackup, mysqlbackup is a commercial binary from mysql that's not released with source)

kind regards
Bogdan

[6 Oct 2016 8:18] Daniël van Eeden

> I'm not following the problem. You are talking about 5.7 source but latest GA 
> mysql cluster 7.4 does not use 5.7 mysqld at all. 
This is also in the cluster-7.5 branch. It probably is in (almost) all previous versions also.

> The development version 7.5 is using 5.7 but latest 5.7.13 at this point in 
> time, so not sure where you get 5.7.14 in relation to MySQL Cluster?
I was looking in mysqldump.cc in the 5.7 branch because of Bug #83270

> Anyhow I'm testing latest 7.4 and 7.5 and I don't see any issues in how 
> mysqldump functions? (you are talking about mysqldump right, not mysqlbackup, 
> mysqlbackup is a commercial binary from mysql that's not released with source)
Yes I ment mysqldump. So s/mysqlbackup/mysqldump/g

There is no issue with how mysqldump works, but the code looks wrong:
- mysql.apply_status and mysql.schema are ignored.
- mysql.ndb_apply_status and mysql.ndb_schema are not ignored.

Why are they only excluded from a dump if they use the old names?

[6 Oct 2016 8:38] Daniël van Eeden

I pasted the wrong bug number.. this is the correct one:
Bug #82848 	Restarting a slave after seeding it with a mysqldump loses it's position

[6 Oct 2016 13:14] MySQL Verification Team

hi, yes that clears it up .. could be related to 82848 .. I'm verifying this and linking to 82848

thanks for your work
Bogdan Kecman