MySQL Server Usage for NDB Cluster 23.5.8.4 NDB Cluster Backup Troubleshooting Important 23.5.8.5 Taking an NDB Backup with Parallel Data Nodes 23.5.9 MySQL Server Usage for NDB Cluster 4496 mysqld  is the traditional MySQL server process. To be used with NDB Cluster,  mysqld  needs to be built with support for the  NDB  storage engine, as it is in the precompiled binaries available from https://dev.mysql.com/downloads/. If you build MySQL from source, you must invoke  CMake  with the  - DWITH_NDBCLUSTER=1  option to include support for  NDB . In NDB 8.0.16 and later,  ndb_restore  automatically checks for the presence of the subdirectories just described; if it finds them, it attempts to restore the backup in parallel. For information about restoring backups taken with multiple LDMs, see Section 23.4.23.3, “Restoring from a backup taken in parallel” . Backups using multiple LDMs create subdirectories, one per LDM, under the directory  BACKUP/ BACKUP- backup_id /  (which in turn resides under the  BackupDataDir ) on each data node; these subdirectories are named  BACKUP- backup_id -PART-1-OF- N / ,  BACKUP- backup_id -PART-2- OF- N / , and so on, up to  BACKUP- backup_id -PART- N -OF- N / , where  backup_id  is the backup ID used for this backup and  N  is the number of LDMs per data node. Each of these subdirectories contains the usual backup files  BACKUP- backup_id -0. node_id .Data ,  BACKUP- backup_id . node_id .ctl , and BACKUP-backup_id.node_id.log , where  node_id  is the node ID of this data node. Once all data nodes are using multiple LDMs, you can take the parallel backup using the  START BACKUP command in the NDB management client just as you would if the data nodes were running  ndbd  (or ndbmtd  in single-threaded mode); no additional or special syntax is required, and you can specify a backup ID, wait option, or snapshot option in any combination as needed or desired. Depending on the number of LDMs and other factors, you may also need to increase NoOfFragmentLogParts . If you are using large Disk Data tables, you may also need to increase DiskPageBufferMemory . As with single-threaded backups, you also want or need to make adjustments to settings for  BackupDataBufferSize ,  BackupMemory , and other configuration parameters relating to backups (see Backup parameters). Beginning with NDB 8.0.16, it is possible to take a backup with multiple local data managers (LDMs) acting in parallel on the data nodes. For this to work, all data nodes in the cluster must use multiple LDMs, and each data node must use the same number of LDMs. This means that all data nodes must run  ndbmtd ( ndbd  is single-threaded and thus always has only one LDM) and they must be configured to use multiple LDMs before taking the backup; ndbmtd by default runs in single-threaded mode. You can cause them to use multiple LDMs this by choosing an appropriate setting for one of the multi-threaded data node configuration parameters  MaxNoOfExecutionThreads  or  ThreadConfig . Keep in mind that changing these parameters requires a restart of the cluster; this can be a rolling restart. NDB  does not support repeatable reads, which can cause problems with the restoration process. Although the backup process is “hot” , restoring an NDB Cluster from backup is not a 100% “hot”  process. This is due to the fact that, for the duration of the restore process, running transactions get nonrepeatable reads from the restored data. This means that the state of the data is inconsistent while the restore is in progress. You should also make sure that there is sufficient space on the hard drive partition of the backup target. If you have set  BackupDataBufferSize  and  BackupLogBufferSize  and their sum is greater than 4MB, then you must also set  BackupMemory  as well. If an error code is returned when issuing a backup request, the most likely cause is insufficient memory or disk space. You should check that there is enough memory allocated for the backup.