Bug #56298 ndb_restore doesn't display correct StopGCP info.
Submitted: 26 Aug 2010 15:42 Modified: 12 Dec 2016 20:26
Reporter: Matthew Montgomery Email Updates:
Status: No Feedback Impact on me:
None 
Category:MySQL Cluster: Cluster (NDB) storage engine Severity:S3 (Non-critical)
Version:mysql-5.1-telco-7.1 OS:Any
Assigned to: MySQL Verification Team CPU Architecture:Any

[26 Aug 2010 15:42] Matthew Montgomery
Description:
Currently ndb_restore displays 0 for all StopGCP.  This prevents identifying the corresponding binlog position/epoch from the backup files themselves.

How to repeat:
ndb_mgm> START BACKUP SNAPSHOTEND WAIT COMPLETED 
Connected to Management Server at: localhost:1186
Waiting for completed, this may take several minutes
Node 5: Backup 3 started from node 1
Node 5: Backup 3 started from node 1 completed
 StartGCP: 1095443 StopGCP: 1095446
 #Records: 2072 #LogRecords: 0
 Data: 51732 bytes Log: 0 bytes
ndb_mgm> 
matt@silo:/data/mysql/sandbox/7.1.6/mysql-cluster$ ndb_restore -b3 -n5 BACKUP/BACKUP-3/
Backup Id = 3
Nodeid = 5
backup path = BACKUP/BACKUP-3/
Opening file 'BACKUP/BACKUP-3/BACKUP-3.5.ctl'
Backup version in files: ndb-6.3.11 ndb version: mysql-5.1.47 ndb-7.1.6
Stop GCP of Backup: 0  <-- WRONG NUMBER

NDBT_ProgramExit: 0 - OK
[30 Aug 2010 7:28] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/117087

3726 Jonas Oreland	2010-08-30
      ndb - bug#56298 - don't print stop GCP until you've read it from disk
[30 Aug 2010 7:39] Bugs System
Pushed into mysql-5.1-telco-7.0 5.1.47-ndb-7.0.18 (revid:jonas@mysql.com-20100830072544-6nai5wil0lfd6gva) (version source revid:jonas@mysql.com-20100830072544-6nai5wil0lfd6gva) (merge vers: 5.1.47-ndb-7.0.18) (pib:21)
[30 Aug 2010 7:45] Jonas Oreland
pushed to 7.0.18, 7.1.7
[30 Aug 2010 12:14] Jon Stephens
Documented in the NDB-7.0.18 and 7.1.7 changelogs, as follows:

      ndb_restore always reported 0 for the GCPStop (end point of the 
      backup). Now it provides useful binary log position and epoch 
      information.
[30 Aug 2010 16:42] MySQL Verification Team
Reported GCI of backup corresponds to neither Start GCP or Stop GCP.

## Backup consistent with end of backup.

matt@silo:/data/mysql/sandbox/7.1.8$ ndb_mgm -e "start backup snapshotend" 
Connected to Management Server at: localhost:1186
Waiting for completed, this may take several minutes
Node 5: Backup 2 started from node 1
Node 5: Backup 2 started from node 1 completed
 StartGCP: 1588 StopGCP: 1591
 #Records: 2053 #LogRecords: 0
 Data: 50312 bytes Log: 0 bytes
matt@silo:/data/mysql/sandbox/7.1.7$ ndb_restore -b 2 -n 5 -d mysql-cluster/BACKUP/BACKUP-2/
Backup Id = 2
Nodeid = 5
backup path = mysql-cluster/BACKUP/BACKUP-2/
Opening file 'mysql-cluster/BACKUP/BACKUP-2/BACKUP-2.5.ctl'
Backup version in files: ndb-6.3.11 ndb version: mysql-5.1.47 ndb-7.1.8
Stop GCP of Backup: 1590

NDBT_ProgramExit: 0 - OK

### Backup consistent with start of backup.

matt@silo:/data/mysql/sandbox/7.1.7$ ndb_mgm -e "start backup snapshotstart" 
Connected to Management Server at: localhost:1186
Waiting for completed, this may take several minutes
Node 5: Backup 3 started from node 1
Node 5: Backup 3 started from node 1 completed
 StartGCP: 1662 StopGCP: 1665
 #Records: 2053 #LogRecords: 0
 Data: 50312 bytes Log: 0 bytes
matt@silo:/data/mysql/sandbox/7.1.7$ ndb_restore -b 3 -n 5 -d mysql-cluster/BACKUP/BACKUP-3/
Backup Id = 3
Nodeid = 5
backup path = mysql-cluster/BACKUP/BACKUP-3/
Opening file 'mysql-cluster/BACKUP/BACKUP-3/BACKUP-3.5.ctl'
Backup version in files: ndb-6.3.11 ndb version: mysql-5.1.47 ndb-7.1.8
Stop GCP of Backup: 1664

NDBT_ProgramExit: 0 - OK
[30 Aug 2010 16:50] MySQL Verification Team
Also the "Stop GCP of Backup" displayed by ndb_restore should just be "GCP of Backup" since it on SNAPSHOTSTART Stop GCP is pointless. We care about the point to which the backup is consistent not really about where it starts or ends.
[12 Nov 2016 20:14] MySQL Verification Team
tested 7.4.11 - we display both startgcp and stopgcp of the backup

so considering this old one closed

Bogdan
[12 Nov 2016 20:21] MySQL Verification Team
ndb_mgm> start backup snapshotend
Waiting for completed, this may take several minutes
Node 2: Backup 2 started from node 1
Node 2: Backup 2 started from node 1 completed
 StartGCP: 33923 StopGCP: 33926
 #Records: 241232 #LogRecords: 0
 Data: 4834696 bytes Log: 0 bytes

ndb_mgm> quit
[root@localhost mysql]# bin/ndb_restore -b 2 -n 2 -d clusterdata/BACKUP/BACKUP-2/
Backup Id = 2
Nodeid = 2
backup path = clusterdata/BACKUP/BACKUP-2/
Opening file 'clusterdata/BACKUP/BACKUP-2/BACKUP-2.2.ctl'
File size 22152 bytes
Backup version in files: ndb-6.3.11 ndb version: mysql-5.6.29 ndb-7.4.11
Stop GCP of Backup: 33925

NDBT_ProgramExit: 0 - OK

(nothing happened between 33925 and 33926) so I'd say that's what we expected
[12 Nov 2016 20:22] MySQL Verification Team
ndb_mgm> START BACKUP SNAPSHOTEND WAIT COMPLETED
Waiting for completed, this may take several minutes
Node 2: Backup 1 started from node 1
Node 2: Backup 1 started from node 1 completed
 StartGCP: 33839 StopGCP: 33842
 #Records: 241232 #LogRecords: 0
 Data: 4834696 bytes Log: 0 bytes

[root@localhost mysql]# bin/ndb_restore -b 1 -n 2 -d clusterdata/BACKUP/BACKUP-1/
Backup Id = 1
Nodeid = 2
backup path = clusterdata/BACKUP/BACKUP-1/
Opening file 'clusterdata/BACKUP/BACKUP-1/BACKUP-1.2.ctl'
File size 22152 bytes
Backup version in files: ndb-6.3.11 ndb version: mysql-5.6.29 ndb-7.4.11
Stop GCP of Backup: 33841

NDBT_ProgramExit: 0 - OK

33841-33842, again I'd say this is ok
[12 Nov 2016 20:26] MySQL Verification Team
Looking closer this is identical behavior we had that Matthew is complaining about. Not sure where the complaining is coming from? I don't see a problem with this figures? We are getting the number where cluster is "consistent"
[13 Dec 2016 1:00] Bugs System
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".