Bug #54717 ndb_restore cannot restore metadata when backup has too many fragments
Submitted: 22 Jun 2010 20:49 Modified: 15 Aug 2017 14:53
Reporter: Andrew Hutchings Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Cluster: Cluster (NDB) storage engine Severity:S4 (Feature request)
Version:mysql-5.1-telco-7.0 OS:Any
Assigned to: Bernd Ocklin CPU Architecture:Any
Tags: 7.0

[22 Jun 2010 20:49] Andrew Hutchings
Description:
It is not possible to restore a backup with tables containing many fragments to a cluster which cannot take so many fragments.

Failure seen in ndb_restore:

Create table `database/def/table` failed: 1224: Too many fragments
Restore: Failed to restore table: `database/def/table` ... Exiting

A typical case where you would see this is taking a backup from a production environment and restoring into a smaller development environment.

How to repeat:
1. create a table with 32 fragments
2. backup
3. try to restore on a single node ndbd
[10 Dec 2010 21:51] Bogdan Kecman
I cannot reproduce this with 7.1.9 at all
[30 Sep 2015 21:14] David Ashman
Just ran into this on 7.3.10. This bug report was the first result in a google search :(

Trying to restore a backup from a 16-node cluster to a 4-node cluster.

$ ndb_restore -m -A -n 1 -b 1 -c manager01 --backup-path=/ndbbackup/BACKUP/BACKUP-1
Nodeid = 1
Backup Id = 1
backup path = /ndbbackup/BACKUP/BACKUP-1
Opening file '/ndbbackup/BACKUP/BACKUP-1/BACKUP-1.1.ctl'
File size 30720 bytes
Backup version in files: ndb-6.3.11 ndb version: mysql-5.6.25 ndb-7.3.10
Stop GCP of Backup: 75095
Connected to ndb!!
Created hashmap: DEFAULT-HASHMAP-3840-128
Created hashmap: DEFAULT-HASHMAP-240-128
Created hashmap: DEFAULT-HASHMAP-3840-64
Create table `xxxxx/def/xxxxx` failed: 1224: Too many fragments
Restore: Failed to restore table: `xxxxx/def/xxxxx` ... Exiting 

NDBT_ProgramExit: 1 - Failed
[15 Aug 2017 14:53] Jon Stephens
Fixed together with BUG#80846 in NDB 7.5.2 by WL#9020 / WL#7551. Closed.